事故の連絡内容から保険金請求の受付票と必要書類の案内を作る

処理の起点を決める

Webフォームと電話： Google Apps Script のインストール可能なトリガーには、Googleフォームの送信で動く「フォーム送信トリガー」があります。契約者向けフォームと、電話の受付メモを貼る社内用フォームの両方に設定します。電話も社内用フォームを通すと、経路を同じ処理に揃えられます。

メール： インストール可能なトリガーの種類に、メール受信で動くものはありません。そこで最短1分間隔で動かせる時間主導型トリガーで、5分ごとに専用アドレスの未処理メールを探します。

インストール可能なトリガーは、作成した人のアカウントで動きます。 誰のアカウントで動かすかを決め、異動や退職で止まらないようにしてください。

入力データを集める

生成AIに渡すのは連絡文と受付日時だけで、表はスクリプトが引きます。 対応表は次の形です（書類の名称と要否は保険会社ごとに異なり、行は例です）。

交通事故証明書は、警察に届け出た事故について交付されます。 届出がないと交付されないため、「警察への届出」が不明なら早めに確かめます。

データの取得方法を決める

メール： GmailApp の search(query) で Gmail の検索条件に合うスレッドを探し、getMessagesForThread(thread) でメッセージを取り出します。処理したスレッドは台帳に記録し、二重に拾わないようにします。

契約一覧： 契約管理の台帳から日次でスプレッドシートに書き出して参照します。書き出しの可否と形式は利用中のシステムによるため、利用環境に応じた個別確認が必要です。

Gemini API の呼び出し： UrlFetchApp の fetch(url, params) で、method: 'post'、headers（APIキー）、payload（連絡文・指示・JSONスキーマ）を指定して送ります。初回は外部へのリクエストを許可する権限（script.external_request）の承認が必要です。muteHttpExceptions: true にすると失敗時も例外で止まらず応答を受け取れるので、失敗した連絡を落とさず「未処理」として台帳に残せます。

AIへ渡す前に整形する

1. 引用と署名の除去 … 返信メールの引用部分にある古い日付を、事故日と取り違えないようにします
2. 続報の検出 … 同じスレッドや同じ契約者から数日内に届いたものは、既存の受付への紐付け候補として見せます。自動では統合しません
3. 契約の照合 … 証券番号のハイフンや全角・半角を揃えて契約一覧と照合します。AIにはさせません。 候補が1件に絞れなければ人に回します
4. けが・通院の記載 … 外部AIに渡してよいかを先に決めます（第13章）。渡さない場合、フォームの「けが人」欄が「いる」の連絡はAI処理から外します。メール本文は事前に見分けられないため、メール経路ごと対象外にするしかありません
5. 添付ファイル … 写真や見積書はAIに渡さず、添付の有無だけを記録します

AIに処理させる

足りない項目の判定は必須項目表で行います。 事故の種類ごとに聞く項目を表で決め、スクリプトが「不明」の項目と突き合わせます。AIには、決まった項目の質問文だけを2回目の呼び出しで書かせます。聞く項目が担当者やAIの出力でぶれません。

指示内容を固定する

あなたは損害保険代理店の事故受付担当を支援する担当者です。
事故の連絡文を読み、受付票の項目を抜き出してください。

【厳守事項】
- 連絡文に書かれていない項目は「不明」としてください。推測で埋めないでください。
- 補償の対象になるか、保険金が支払われるかを一切書かないでください。
  判断するのは保険会社です。
- 必要な書類を挙げないでください。書類は別の表から案内します。
- 過失の割合や、どちらに責任があるかを書かないでください。
- けがは、連絡文の言葉だけを injury_note に写してください。
  程度や診断名を推測したり言い換えたりしないでください。
- 「昨日の夕方」のような相対的な日時は日付に直さず、そのまま写して
  unclear_points に入れてください。
- 項目ごとに、根拠になった連絡文の一部を evidence にそのまま引用してください。

【受付日時】{received_at}
【連絡文】{message_text}

「補償を書かない」「書類を挙げない」の2行が重要です。 生成AIは親切に「車両保険に加入されていれば対象になる可能性があります」と書き足すおそれがあり、届けば代理店が見通しを示したことになります。出力の検査でも弾きます。

出力形式を固定する

{
  "accident_type_candidate": "自動車 | 火災 | 水漏れ | 賠償 | その他 | 不明",
  "policy_number_text": "",
  "accident_datetime_text": "",
  "accident_location": "",
  "situation_summary": "",
  "counterparty": { "exists": "あり | なし | 不明", "name": "", "contact": "" },
  "injury": { "exists": "あり | なし | 不明", "injury_note": "" },
  "police_report": { "status": "届出済み | 未届 | 不明", "station": "" },
  "repair_shop": "",
  "unclear_points": [],
  "evidence": [{ "field": "", "quote": "" }]
}

Gemini API の構造化出力では、JSONスキーマに沿った構文上正しいJSONが返ります。enum で値を固定すれば「たぶんあり」のような値は返りません。ただし公式ドキュメントは、値が正しいかはアプリ側で検証するよう案内しています。スクリプトで次を検査します。

• evidence の引用が連絡文の中にそのまま存在するか。なければ、その項目は作られた値として人に回す
• 「補償」「支払」「対象になります」などの表現がないか

スキーマに「補償の可否」や「必要書類」の欄を作らないでください。 欄があれば、AIはそこを埋めます。

システムへ連携する

受付台帳： 1行1件で、受付番号、契約者、保険会社、事故の種類（候補と確定）、抜き出した項目、足りない項目、状態（未確認／案内済み／報告済み）を並べます。

書類の引き当て： 保険会社、事故の種類、「相手あり」などの条件で対応表を引き、書類と対応表の更新日を台帳に書きます。事故の種類を直したら書類を引き直す操作を用意します。

案内メール： GmailApp の createDraft(recipient, subject, body, options) で下書きを作ります。本文は、受付番号とあいさつ（ひな形）、受け付けた内容（AIの抜き出し）、追加で教えてほしいこと（AIの質問文）、ご用意いただく書類（対応表）、「お支払いの可否や金額は保険会社が確認のうえご案内します」という注意書き（ひな形）の順です。AIが書くのは2つ目と3つ目だけです。 メールアドレスが分からない電話の連絡は、電話か郵送での案内に回します。

保険会社への事故報告： 代理店向けシステムへの登録方法は保険会社ごとに違います。APIで自動登録できる前提にはせず、利用環境に応じた個別確認が必要です。 台帳に、保険会社ごとの入力画面の順に項目を並べた転記用の欄を作ります。

人が確認する

全件、人が確認します。運用が安定しても自動送信にしません。

事故の種類を誤ると書類がすべて変わり、案内メールは代理店の発言として届き、けがや相手方の情報も含むためです。

• 台帳の横に連絡文の原文を並べ、引用箇所に色を付ける
• 「不明」の項目と、引用が原文に見つからなかった項目を目立たせる
• 事故の種類が「候補」のままなら、下書きを送れない状態にする

例外に対処する

記録を残す

• 連絡文の原文、受付日時、経路
• AIの出力（検査前）と、検査で弾いた理由
• 書類を引いた対応表の行と更新日
• 人が直した項目と、直す前後の値
• 送った案内メールの最終版、送信者、送信日時

直した記録が精度の実測値になります。 「事故の種類を2割直している」と分かれば、改善すべき所が決まります。