保険代理店のWebの見積依頼フォームから、見積に要る項目がそろっているかを保険の種類ごとに確かめ、足りない項目を聞く返信の下書きと見積の準備票を作る

処理の起点を決める

フォームの送信を起点に、1件ずつ動かします。 見積依頼は、満期が近い人ほど急いでいます。まとめて朝に処理すると、夜に送った人への返事が翌日の昼になります。 送信のたびに動かせば、営業事務が出社した時点で準備票と下書きがそろっています。

メールの通知ではなく、Webhook を起点にするのには理由があります。 フォームの通知メールは本文に項目を並べた文章で、保険の種類や連絡先を取り出すのに一手間かかります。 Webhook なら、選択式の項目は最初から項目として届きます。

Catch Hook は本文を解析して項目に分けます。JSON の配列が届くと、要素ごとに Zap が動くので、フォームの側は1件を1つのオブジェクトで送る設定にします。

入力データを集める

質を決めるのは、確認表です。 確認表は、取扱う保険会社の見積の画面で入力を求められる項目をもとに、代理店が自分で決めた一覧です。たとえば自動車保険なら次のような行が並びます。

「証券で確かめる」の列が、この構成の要です。 等級や満期日は、顧客が書いていても記憶で書いていることがあります。この列に○がある項目は、書いてあっても needs_document にして、証券の写しを送ってもらうか、証券を見て答えてもらうよう聞きます。

火災保険の確認表には、所在地、建物の構造、築年月、延床面積、用途、補償の対象（建物／家財）、地震保険の希望などを並べます。 項目と聞き方は、代理店の取扱う保険会社と商品に合わせて決めてください。

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

確認表は、保険の種類ごとに1行にまとめて持ちます。 Lookup Spreadsheet Row は、指定した列で値が一致する行を探す動きで、1行を返します。項目を1行ずつ持つと、1回の検索で取れるのが1項目だけになります。 1つのセルに、その種類の項目を JSON の形で並べておくと、1回で全項目が取れます。

担当表は、主の列と補助の列の2つの条件で引きます。 Lookup Spreadsheet Row は補助の検索列を指定でき、両方に合う行を返します。一致する行が無いときの動きを決められるので、担当が見つからないときは受付の責任者の行を返すようにします。

AIへ渡す前に整形する

1. 保険の種類が「その他」なら、AIに渡さない … 確認表が無いので、受付の一覧に載せて人に回します
2. 自由記入欄が空なら、AIに渡さない … 確認表の必須項目をすべて missing として下書きを作ります
3. 全角・半角と改行をそろえる … 「Ｒ７」「令和7年」「2025/」のような日付の書き方は、ここでは直さず、AIに原文のまま渡します
4. 添付の有無を印にする … フォームで証券や車検証の写しを受け付けている場合、この構成では画像を読みません。 添付がある依頼には印を付け、人が見ます
5. 同じ人からの重複を見る … メールアドレスと保険の種類が同じ依頼が直近24時間にあれば、受付の一覧で印を付けます

3番目で日付を直さないのは、意図してのことです。 「来月まで」のような書き方を規則で日付に直すと、あいまいな値が確かな値に見えてしまいます。 あいまいかどうかの判断はAIの区分に任せ、根拠の原文を残します。

AIに処理させる

させるのは、確認表の項目ごとに、自由記入欄から値を抜き出し、4つの区分のどれかを付け、根拠にした原文を書き出すことです。

1行目がいちばん起きやすい失敗です。 「免許を取って20年、無事故です」と書いてあると、生成AIは等級を20と埋めがちです。等級は運転歴ではなく、前の契約の実績で決まります。 書いていなければ missing、書いてあれば needs_document で、どちらも証券で確かめます。

3行目も同じです。 「マンションの3階」から構造の区分を埋めると、見積の金額が変わる値を、確かめないまま準備票に入れることになります。

指示内容を固定する

Analyze and Return Data の指示の欄に、次のように書きます。

あなたは損害保険の代理店で、Webの見積依頼を受け付ける担当です。
依頼の自由記入欄を読み、確認表の項目ごとに値を抜き出してください。

【区分の選び方】
- filled ........... 値が具体的に書かれており、1つに決まる
- missing .......... 書かれていない
- unclear .......... 書かれているが、値が1つに決まらない
                     （「くらい」「たぶん」「来月まで」「〜だったと思う」など）
- needs_document ... 書かれているが、確認表で document_check が true の項目
迷ったときに filled を選ばないでください。

【厳守事項】
- 書かれていない値を推測しないでください。運転歴から等級を、
  建物の種類から構造の区分を、年齢から運転者の範囲を決めないでください。
- あいまいな書き方を、確かな値に直さないでください。
  「来月まで」を日付にせず、原文のまま value に入れて unclear にしてください。
- evidence には、根拠にした文を自由記入欄からそのまま写してください。
- 保険の商品、補償の組み方、保険料の目安を書かないでください。
- 確認表に無い項目について書かれていたら、other_notes に原文のまま
  入れてください。
- 自由記入欄が見積の依頼でない（苦情、事故の連絡など）と判断した場合は、
  項目を抜き出さず request_kind に種類を書いてください。

【保険の種類】{product_type}
【確認表】{checklist}
【自由記入欄】{free_text}

「迷ったときに filled を選ばない」が、この指示の要です。 filled になった項目は、聞き返しの下書きに載りません。誤って filled にした項目は、顧客にも聞かれず、営業事務も見落とし、見積の段で初めて分かります。

「事故の連絡なら抜き出さない」を入れているのは、フォームに見積以外が届くからです。 事故の連絡が見積依頼として処理されると、急ぎの連絡が準備票の列に埋もれます。

出力形式を固定する

Analyze and Return Data の出力の項目を、次のように定義します。 見やすさのため JSON の形で示します。

{
  "request_kind": "quote | accident_report | complaint | other",
  "product_type": "auto | fire | business_liability",
  "items": [
    { "key": "", "label": "", "value": "",
      "status": "filled | missing | unclear | needs_document",
      "evidence": "" }
  ],
  "missing_keys": [""],
  "confirm_keys": [""],
  "other_notes": ""
}

missing_keys には missing の項目のキーを、confirm_keys には unclear と needs_document の項目のキーを並べます。request_kind と product_type は必須の項目にします。

1つ目の理由は、request_kind で Paths の分かれ道を決められることです。 quote 以外は準備票を作らず、すぐに受付の責任者へ知らせます。

2つ目は、missing_keys と confirm_keys から下書きを組み立てられることです。 キーごとに確認表の聞き方の文面を引き、「次の点をお知らせください」の下に並べます。confirm_keys の文面には、「ご記入いただいた内容（〇〇）を、保険証券でご確認ください」と原文を添えます。

組み立てた下書きは、たとえば次のようになります。

〇〇様

自動車保険のお見積のご依頼をいただき、ありがとうございます。
お見積の作成にあたり、次の点をお知らせください。

【まだご記入のない点】
・運転される方の範囲：主に運転される方と、ほかに運転される方の続柄
・使用目的：日常・レジャー、通勤・通学、業務のどれに近いか

【保険証券でご確認いただきたい点】
・現在のご契約の満期日（ご記入：「来月まで」）
・ノンフリート等級（ご記入：「15等級くらい」）
  保険証券の写しをこのメールに添付してお送りいただいても結構です。

3つ目は、evidence で営業事務の確認が速くなることです。 準備票の各項目の横に根拠の原文が並ぶので、自由記入欄を読み直さずに、抜き出しが合っているかを確かめられます。

システムへ連携する

Gmail は Create Draft までにし、Send Email は使いません。 送るのは営業事務が下書きを確かめてからです。顧客に届く文面は、保険の募集の一部です。 確かめないまま送る経路を、最初から作りません。

Paths は、1つのグループに最大10本の分かれ道を持て、どの規則にも当たらないときに動く Fallback を置けます。 出力が欠けたものは Fallback に流し、人に回します。Paths も Professional 以上のプランで使えます。

準備票の満期日までの日数は、受付の一覧のシートの式で数えます。 needs_document の満期日でも、30日を切っていれば準備票の行に色を付け、聞き返しと並行して募集人が電話をかける目印にします。

人が確認する

1. 満期の近いものを先に見る … 30日を切っているものは、聞き返しのメールと並行して募集人が電話します
2. 準備票の filled の値を根拠の原文と見比べる … とくに車名・型式、所在地、延床面積の写し間違いを見ます
3. 下書きを確かめて送る … 聞き方の文面が依頼の内容に合っているか、聞かなくてよい項目が混ざっていないかを見ます
4. 抜き出しの誤りを記録する … どの項目で、どの区分を誤ったかを残します

2番目で filled を見るのは、AIが「迷ったら filled にしない」を守っていても、写し間違いは起きるからです。 型式の英数字の1文字違いは、見積の画面で別の車になります。

目標は、300件をならして1件4分です。 書き漏れの無い依頼は準備票を流し見て知らせるだけで、聞き返しのある依頼は下書きを直して送るまでを見込んでいます。

例外に対処する

上の3行目を見積として流すと、この構成でいちばん困ることになります。 事故の連絡は、フォームしか連絡手段を知らない人から届くことがあります。見積の列に並べず、その場で人に知らせます。

記録を残す

• 受け取った依頼の全文と、送信日時
• AIの出力の全文（項目ごとの値、区分、根拠）
• 下書きの文面と、営業事務が送った文面（直した箇所が分かるように）
• 抜き出しの誤りの記録 … どの項目で、どの区分を誤ったか
• 依頼から最初の返信までの時間と、聞き返しの回数

3つ目で「送った文面」を残すのは、直した箇所が確認表の改善の材料になるからです。 同じ項目で毎回文面を直しているなら、確認表の聞き方の文面を直します。

最後の行が、この構成の物差しです。 聞き返しが1回で済んだ割合が増えていれば、確認表と区分の付け分けが効いています。