保険代理店の LINE に写真付きで届く事故・住所や車の変更・質問の連絡を、種類と急ぎ具合で分けて担当の募集人へ回す

処理の起点を決める

シナリオは2つに分けます。

受信と分類を分けるのは、連絡が分かれて届くためです。 1通ごとに分類すると、「すみません」だけの1通目が「その他」になり、写真が届くたびに別の受付ができてしまいます。 受信の記録に1通ずつ書いておき、同じ契約者から最後の1通が届いて3分たったら、ひとまとまりとして分類します。

ただし、事故を示す語だけは受信の時点で拾います。 3分と5分の待ちを、事故の連絡に負わせないためです。

webhook は、受け取ったら早く応答を返します。 LINE の公式の資料は、webhook のイベントを非同期に処理することを勧めています。シナリオ1では写真の保存と記録だけを行い、重い分類はシナリオ2に回します。

入力データを集める

質を決めるのは、顧客台帳の LINE のユーザーIDの列です。 ここが空だと、分類ができても誰の担当かが分からず、 事務の担当が表示名から探す元の作業に戻ります。契約者が友だち追加したあと、最初に契約者番号か電話番号の下4桁を送ってもらい、 事務の担当が台帳と照らして結び付けます。

事故を示す語の一覧は、広めに取ります。

語の一覧で拾い過ぎても、通知が1件増えるだけです。 拾い漏れのほうが重いので、分類の結果が accident なのに語の一覧で拾えていなかった連絡を、月に1回見て一覧に足します。

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

写真は、メッセージのIDで LINE から取り出し、代理店のドライブに保存します。 保存先のフォルダは、受付の日付とユーザーIDで分けます。保存したファイルのリンクを受信の記録に書き、 分類のときはドライブから読み直します。

文は、webhook で受け取ったときにしか取れません。 公式の資料では、文は webhook のメッセージに入っていて、あとからもう一度取り直す API は無いとされています。シナリオ1が止まっていた間の文は、管理画面で人が拾うしかありません。

写真は、Claude API に渡す前に大きさをそろえます。 Claude API に直接送る画像は、base64 にした状態で1枚10MBまで、 形式は JPEG・PNG・GIF・WebP です。1回に20枚を超える画像を送ると、1枚あたりの寸法の上限が厳しくなり、縦横2000ピクセル以下にするか、20枚以下に収めるよう案内されています。1件の写真は多くても10枚ほどなので、長い辺を2000ピクセル以下にして送ります。

AIへ渡す前に整形する

1. ユーザーIDで台帳を引く … 契約者が特定できなければ、分類はしても通知の先を事務の担当にします
2. まとまりを作る … 同じユーザーIDで未分類の通を集め、最後の1通から3分たったものを1件にします
3. 写真の形式と大きさの確認 … JPEG・PNG・GIF・WebP 以外は分類に渡さず、写真が届いた事実だけを書きます。長い辺を2000ピクセル以下にします
4. 動画・音声・ファイル … 保存だけ行い、分類には渡しません。「動画あり」と受付の一覧に書きます
5. 事故を示す語の照合 … シナリオ1で済ませた結果を、まとまりに引き継ぎます
6. 文の中の口座番号・カード番号 … 数字の並びの形で見つけたら、Claude API へ渡す文では伏せます。口座の変更の連絡だと分かれば足ります

6番目は、分類に要らない情報を外へ出さないためです。 口座の変更の連絡では、契約者が番号をそのまま書いてくることがあります。種類を決めるのに番号は要らないので、 伏せてから渡します。元の文は受信の記録に残り、募集人はそちらを見ます。

AIに処理させる

させるのは、ひとまとまりの文と写真から、連絡の種類、急ぎ具合、写真に写っているものの種類、要点を出すことです。

種類と急ぎ具合の組み合わせは、ルーターでの経路の分け方とそろえます。

車の入れ替えを「今日中」にするのは、新しい車に乗り始める前に手続きが要るためです。 納車日の書かれていない連絡は「通常」とし、募集人が聞き返します。

3行目と4行目は、事故の写真で特に効きます。 事故の写真には、けがをした人や相手の運転手が写ることがあります。分類に要るのは「車の損傷の写真がある」という事実だけで、写っている人の様子は記録に残しません。

指示内容を固定する

あなたは損害保険の代理店で、契約者から LINE で届いた連絡を仕分ける事務の担当です。
1人の契約者から短い間に届いた文と写真を、まとめて渡します。
目的は、どの募集人が、どれだけ急いで見るべきかを決めることです。

【連絡の種類（category）】次のどれか1つを選んでください。
accident（事故） / address_change（住所・連絡先の変更） / vehicle_change（車の入れ替え）
/ bank_change（口座の変更） / cancel_consult（解約・中断の相談）
/ coverage_question（補償の質問） / other（その他）

【急ぎ具合（urgency）】now（今すぐ） / today（今日中） / normal（通常）
- 事故の連絡は、内容にかかわらず now にしてください。
- 車の入れ替えで、納車が今日か明日と書かれていれば today にしてください。

【写真の種類（photo_types）】写真ごとに次から選んでください。
vehicle_damage / vehicle_certificate / driver_license / building_damage / document / other

【厳守事項】
- 補償の対象になるか、過失がどちらにあるか、損害がどれくらいかは書かないでください。
- 写真に人が写っていても、その人のけがの様子や、誰であるかを書かないでください。
- 車検証や免許証の番号、口座の番号を書き写さないでください。
- 文に書かれていないことを推測で補わないでください。文が無く写真だけなら、
  summary は「写真のみ」とし、写真の種類だけを書いてください。
- 種類に迷ったら other を選び、confidence を low にしてください。
- 契約者への返事の文は書かないでください。

【契約者の契約の種類】{policy_types}
【届いた文（届いた順）】{messages}
【写真】（このあとに写真を届いた順に渡します）

「事故は内容にかかわらず now」を明記するのは、 何も言わないと、モデルは「駐車場で軽くこすっただけ」のような文を「通常」にするからです。軽いかどうかの見立ては、この構成ではさせないので、急ぎ具合も見立てずに決めます。

写真は、文の前ではなく後ろに置いています。 Claude の公式の資料では、画像を文の前に置くほうがよい結果になりやすいとされていますが、この構成では届いた順の文を先に読ませ、写真を「この文の写真」として見せるほうが、種類を取り違えにくいと考えました。試行の段階で、両方の並べ方を比べて決めてください。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。 Claude API の構造化出力は output_config.format に type: "json_schema" とスキーマを入れて指定し、category・urgency・photo_types は enum で縛ります。

{
  "category": "accident",
  "urgency": "now",
  "photo_types": ["vehicle_damage", "vehicle_damage", "other"],
  "summary": "駐車場で車の左後ろをぶつけた。どうすればよいかの問い合わせ",
  "missing_info": ["相手の有無", "けが人の有無"],
  "confidence": "high | low"
}

1つ目の理由は、ルーターで分けられることです。 Make のルーターは、経路ごとに条件を付けて流れを分け、どの条件にも当たらないものをフォールバックの経路で受けます。 経路は順に処理されるので、事故の経路をいちばん上に置きます。 confidence が low のものと、契約者が特定できないものはフォールバックへ流し、事務の担当が見ます。

2つ目は、missing_info で募集人の最初の一言を決められることです。 事故なら「相手はいますか、けがをした人はいますか」、車の入れ替えなら「新しい車の車検証の写真を送ってください」。募集人は通知を見た時点で、何を聞き返せばよいかが分かります。

公式の資料では、enum の値が大文字・小文字だけ違って返ることがあるとされています。 ルーターの条件は、小文字にそろえてから比べます。

受付の一覧は、次の形になります。

システムへ連携する

契約者への返事は、代理店が決めた定型の文だけです。 受付の返事は「受け付けました。担当の募集人から連絡します」、事故の語を拾ったときは、契約の保険会社の事故の受付の番号を案内する文です。保険会社ごとの番号は、顧客台帳の契約の種類から選びます。AIが書いた文は、契約者に送りません。

保険会社の代理店システムへは、何もつなぎません。 住所や車の変更の手続きは、募集人が契約者に確かめてから行います。

人が確認する

募集人は、通知を受けたら分類を確かめてから対応します。 分類が違っていたら、受付の一覧の種類を直します。

1. 「今すぐ」の通知は、見た時点で契約者に連絡する … 事故の連絡では、保険会社の事故の受付への連絡が済んでいるかを最初に確かめます
2. 通常の通知は、その日のうちに見る … missing_info を見て、聞き返すことを決めます
3. 事務の担当は、フォールバックに落ちたものを1日2回見る … 契約者が特定できないもの、自信が低いもの、動画やファイル
4. 分類を直したら記録する … どの種類からどの種類へ直したか

4番目の記録は、プロンプトと事故の語の一覧を直す材料にします。 「質問」とされたものが実は「解約の相談」だった、が続けば、種類の説明を指示に足します。

夜と休日の「今すぐ」は、誰が見るかを決めておきます。 定型の返事で事故の受付の番号は案内されますが、代理店として翌朝まで誰も見ない状態は残ります。 当番の募集人を決めて通知を流すかは、代理店の体制で決めます。

例外に対処する

3行目のために、管理画面のチャットは閉じません。 この構成は管理画面の作業を減らすものですが、webhook が届かなかったときの最後の受け皿として、事務の担当が1日1回、管理画面と受付の一覧の件数を照らします。

記録を残す

• 受信した文の原文、ユーザーID、日時（1通ずつ）
• 写真のファイル（代理店のドライブ）と、取り出した日時
• Claude API に渡した内容（伏せた後の文と写真のリンク）と、返ってきたJSON
• 通知した先と日時、募集人が対応を始めた日時
• 募集人が分類を直した記録
• 事故の語で即時通知した件数と、分類が accident だった件数の対応

最後の行で、語の一覧の拾い漏れと拾い過ぎが分かります。 拾い漏れ（分類は事故なのに語で拾えていない）は一覧に語を足し、拾い過ぎは気にしません。