保険代理店が送った満期案内への顧客の返信を「継続・条件の変更希望・解約・質問」に分類し、募集人ごとのフォロー一覧と返信の下書きを作る

処理の起点を決める

15分ごとにシナリオを動かし、Gmail の Watch emails で新しい返信を拾います。 Make のシナリオの実行の間隔は、一定の間隔、1回だけ、毎日、平日、毎週、毎月、指定した日、手動から選べ、一定の間隔の既定は15分です。間隔の下限は契約しているプランによります。

1日1回のまとめ処理にしないのは、解約の返信を当日のうちに募集人へ届けたいからです。 第3章の（c）は、ここで解きます。営業時間外の返信は、翌朝の最初の実行で拾われます。

拾う条件は、件名に「満期案内」を含むこと、未読であること、処理済みのラベルが付いていないことの3つです。Gmail の検索の書き方で subject:満期案内 is:unread -label:満期返信済 のように書けます。処理が終わったら、Update email labels で処理済みのラベルを付け、Mark as read で既読にします。ラベルを付けるのは成功したときだけにします。 途中で止まった返信は、次の実行でもう一度拾われます。

件名を書き換えた返信は、この条件では拾えません。 そこで、送信元のアドレスが台帳にある契約者のメールを拾う2本目の条件を、1日2回の別のシナリオで回します。拾い漏れを、照合の側から補う形です。

入力データを集める

質を決めるのは、いちばん下の2つです。 区分の定義が無ければ、「保険料が上がった理由を知りたい。高ければ他社にする」という返信が、質問なのか解約なのかが読む人で分かれます。この代理店では、解約を口にしていれば質問の要素があっても解約にする、と決めて表に書きます。 AIもその表を読んで分類します。

AIに渡すのは、返信の本文と、照合した契約の保険の種類と満期日だけです。 証券番号、住所、車両の情報、保険料はAIに渡しません。分類に要らないからです。

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

照合の順は、案内番号が先、メールアドレスが後です。 メールアドレスから引くと、同じ契約者が自動車保険と火災保険を持っているときに複数の契約が当たります。 案内番号は案内1通に1つなので、1件に決まります。

メールアドレスで複数の契約が当たったときは、満期日が今日から90日以内のものに絞ります。 それでも複数残れば、照合を決めずに multiple として人へ回します。AIに契約を選ばせません。 本文に「車の保険」と書いてあっても、2台持っている契約者もいます。

Search Rows の件数の上限は5件にし、超えたら照合を止めます。 アドレスの列が空の行に当たって全件が返る事故を防ぐためです。

AIへ渡す前に整形する

1. 引用された元の案内を外す … 返信には、送った満期案内の全文が引用されて付いてきます。「>」で始まる行と、「満期案内」の定型の書き出し以降を切ります
2. 署名を外す … 契約者の会社の署名や免責の文を外します。電話番号はフォロー一覧の側に台帳から入れます
3. 長さを確かめる … 引用を外した本文が極端に短い（「了解」「OK」だけ）ものも、そのまま分類に回します。短い返信ほど継続であることが多く、外さないでください
4. 添付の有無を記録する … 車検証や見積書の写真が付いてくることがあります。添付はAIに渡さず、has_attachment として一覧に出します
5. 自動応答を外す … 「不在にしています」の自動応答は、件名と本文の定型で見分け、分類に回さずに件数だけ記録します
6. 同じスレッドの2通目を見分ける … スレッドIDがフォロー一覧にすでにあれば、新しい行を足さず、既存の行に「追加の返信あり」を付けます

1番目がいちばん効きます。 引用を残したまま渡すと、案内文の中の「ご継続の場合は」「解約をご希望の場合は」という文言を根拠に分類します。契約者が書いたのは「お願いします」の一言だけなのに、根拠の文が案内文になります。

AIに処理させる

させるのは、返信の本文を読んで区分を1つ選び、区分の判断に使った文と、変更・質問の中身を書き出すことです。

区分と変更の要素を分けているのが、第3章の（b）への答えです。 「継続でお願いします。住所が変わりました」は、区分が「継続」で、変更の要素に「住所の変更」が入ります。フォロー一覧では、変更の要素が空でない継続を、条件の変更希望と同じ色で出します。

急ぎの度合いの規則は次のとおりです。解約は常に高。 条件の変更希望は、満期日まで30日以内なら高、それ以外は中。質問と継続は、満期日まで14日以内なら中、それ以外は低です。満期日までの日数はワークフローの側で計算して渡し、AIには日付の計算をさせません。

2行目と3行目は、保険業法との関係で外せません。 保険業法第294条の2は、保険募集人に、顧客の意向を把握し、これに沿った保険契約の締結等の提案、契約の内容の説明、そして顧客の意向と契約の内容が合致していることを顧客が確認する機会の提供を求めています。条件の変更や他社との比較の相談に、AIが補償や保険料を答えると、この手順の外で話が進みます。

指示内容を固定する

Make an API Call で Messages API を呼ぶとき、system に次のように書きます。

あなたは損害保険代理店の営業事務で、満期案内に対して契約者から届いた
返信メールを仕分ける担当です。入力は、引用と署名を取り除いた返信の本文と、
その契約の保険の種類、満期日までの日数です。

【区分（1つだけ選ぶ）】
- continue ..... 今の内容のまま継続したい
- change ....... 継続はするが、何かを変えたい（車両の入替、補償の見直しなど）
- cancel ....... 継続しない、他社にする、解約したい
- question ..... 継続するかを決める前に、聞きたいことがある
- unclear ...... 上のどれとも決められない
解約や他社への切り替えを口にしていれば、質問が含まれていても cancel。
継続を口にしていても、何かを変えたいと書いていれば change。

【厳守事項】
- evidence には、区分を決めた本文の文をそのまま写してください。
  元の案内文の言葉を根拠にしないでください。
- 書かれていないことを補わないでください。解約の理由が書かれていなければ
  cancel_reason は「記載なし」としてください。
- 変更の要素は、本文に書かれたものだけを change_items に入れてください。
- 保険料・補償の範囲・手続きの可否について、答えや見込みを書かないでください。
- 契約がどれかを推測しないでください。入力にある契約の情報だけを使ってください。
- 急ぎの度合いは、次の規則で選んでください。
  cancel は high。change は 満期日まで30日以内なら high、それ以外は medium。
  continue と question は 14日以内なら medium、それ以外は low。
- 迷ったときは unclear を選び、confidence を low にしてください。
- 満期の返信ではない（事故の連絡、請求の相談など）と判断したときは、
  is_renewal_reply を false にしてください。

【区分の定義と迷いやすい例】{category_table}
【保険の種類】{product_type}　【満期日までの日数】{days_to_expiry}
【返信の本文】{reply_body}

「元の案内文の言葉を根拠にしない」を書くのは、前処理で引用を外しきれない返信があるからです。 契約者が引用の中に書き込む返信（「→継続します」）もあり、引用を全部外すと本文が消えます。根拠の文の側でも縛り、二重に守ります。

事故の連絡を見分けさせるのは、満期案内のスレッドに事故を知らせてくる契約者がいるからです。 is_renewal_reply が false のものは一覧に入れず、事故の受付の担当へ即時に知らせます。

出力形式を固定する

構造化出力で、次の形のJSONを返させます。

{
  "is_renewal_reply": true,
  "category": "continue | change | cancel | question | unclear",
  "confidence": "high | medium | low",
  "evidence": [""],
  "change_items": ["vehicle | address | coverage | payment | driver_scope | other"],
  "question_summary": "",
  "cancel_reason": "",
  "urgency": "high | medium | low",
  "contact_preference": "",
  "draft_reply": ""
}

1つ目の理由は、Router の条件を category の値で書けることです。 自由文で返されると、「継続のご意向です」「継続希望」と書き方が揺れ、条件に当たらない返信が出ます。値が決まっていれば、どの経路にも当たらないのは unclear と想定外の出力だけになり、それはフォールバックが拾います。

2つ目は、change_items で一覧の色分けができることです。 continue でも change_items が空でなければ、変更の手続きが要ります。

3つ目は、evidence で確認が速くなることです。 営業事務は本文を開かずに、根拠の文と区分が合っているかを一覧で見られます。

フォロー一覧には、次の列で1行ずつ足します。

照合の結果の列を持つのは、by_address で照合したものを人が一度見るためです。 家族のアドレスから返信が来ると、別の契約者に当たることがあります。

システムへ連携する

下書きは、Create a draft email で Gmail の下書きに置くだけにします。 送信のモジュールは使いません。下書きには、元の返信のスレッドで返すように、件名に「Re:」を付け、案内番号を残します。

下書きの中身は区分ごとの型に沿わせます。継続は「継続のご意向を承りました。お手続きの書類は担当の◯◯からお送りします」、変更と質問は「ご連絡ありがとうございます。担当の◯◯から、◯営業日以内にお電話またはメールでご連絡します」、解約は「ご連絡ありがとうございます。お手続きのご案内のため、担当の◯◯からご連絡します」です。どの型にも、保険料や補償の答えを入れません。

満期管理の台帳には書き込みません。 台帳は保険会社の代理店システムから作っている写しで、ここを書き換えると、次の取り込みで上書きされるか、写しと元が食い違います。 状態はフォロー一覧の側で持ちます。

人が確認する

1. 解約と照合できなかった返信を先に見る … チャットに届いたものから、その日のうちに確かめます
2. フォロー一覧で区分と根拠の文を見比べる … 根拠の文が区分と合っていれば次へ。合わないものだけ本文を開きます
3. by_address と multiple の照合を確かめる … 台帳で契約を決め、一覧の行を直します
4. 下書きを直して送る … 担当者名と連絡の目安を確かめ、送信は営業事務が行います
5. 募集人が契約者に連絡する … 意向を聞き、変更・解約・継続の手続きを進め、一覧の状態を更新します
6. 区分を直したら記録する … どの区分からどの区分へ直したかを残します

2番目で本文を開く数が、この構成の物差しです。 目標は、240件をならして1件4分です。区分と照合の確認に2分、下書きの確認と送信に2分という見込みです。本文を開く返信が3割を超える月は、区分の定義の表か、前処理の引用の外し方を見直します。

5番目は、この構成の外の仕事です。 募集人が契約者と話して意向を聞く時間は、Before にも After にも入れていません。

例外に対処する

上から3行目までが、例外の大半を占めます。 どれもAIの問題ではなく、案内の送り方と台帳の整い方の問題です。 案内番号を件名の先頭に置き、「件名を変えずにご返信ください」と案内文に一行入れるだけで、by_address の件数は減ります。

記録を残す

• 返信のメールID、スレッドID、受信日時と、照合の結果
• AIに渡した本文（引用と署名を外した後）と、返ってきたJSONの全文
• 下書きの文面と、人が直して送った文面
• 人が区分を直した記録 … どの区分からどの区分へ、なぜ直したか
• 解約の返信を受けてから、募集人が連絡するまでの時間
• 満期日の時点での最終の結果（継続・変更して継続・解約）

最後の2行が、この構成の物差しです。 解約の返信から連絡までの時間が縮み、連絡した解約のうち、条件を見直して継続になったものがどれだけあるかを並べると、仕分けを急いだ意味が見えます。区分を直した記録は、区分の定義の表を直す材料になります。