保険代理店の事務担当から出る「この契約の変更・解約にはどの書類と手続きが要るか」の質問に、保険会社ごとの事務手引と通達を根拠にチャットで答え、手引に無いものを保険会社へ照会する

処理の起点を決める

起点は、事務担当か募集人が手続きチャットに質問を送ったことです。 チャットは社員の ID でログインした人が使え、所属の店舗から、回したときの連絡先を決めます。

証券番号を必須にします。 顧客の名前だけでは契約を決められないからです。証券番号が手元に無いときは「分からない」を選べますが、その場合は保険会社と種目を選択肢で選ばせ、回答の上に「契約を確かめていません」と表示します。

1件の質問は、1つのセッションで最後まで続けます。 「では住所も一緒に変える場合は」のような続けての質問は同じセッションでつなぎ、別の契約の話は新しいセッションで始めます。 前の契約の保険会社が言い換えの中に残るからです。

入力データを集める

質を決めるのは、通達のメタデータです。 通達ごとに保険会社、種目、手続き、適用開始日、置き換わる手引の章を付けます。これが無いと、手引の古い記載と通達の新しい記載が同じ重さで並び、どちらを根拠に答えたかが運次第になります。

事務手引を取り込む前に、各保険会社との取り決めを確かめます。 代理店委託契約や情報の取扱いの取り決めで、手引を代理店の外のサービスに置くことがどう扱われているかは会社によって違います。認められていない会社の手引は取り込まず、その会社の質問はすべて業務課に回します。

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

事務手引・通達・条文・過去の照会の回答は、Cloud Storage に置いてデータストアに取り込みます。 保険会社の代理店向けの画面からPDFを取る作業は、業務課が通達の届いた日に行います。 取り方は保険会社ごとに違い、自動で取れるかは各社の画面の仕様によるため、ここは手作業を前提にします。

絞り込みの式は、会社と種目と日付で書きます。 項目を索引可能にしておけば、insurer: ANY("C") AND line: ANY("auto") AND valid_from <= "2026-10-08" AND valid_to >= "2026-10-08" のように、その会社のその種目で、今日効いている文書だけを引けます。日付は ISO 8601 の形式でそろえます。

通達で置き換わった手引の箇所には、通達の適用開始日を終了日として書きます。 こうしておくと、古い記載は絞り込みの時点で外れ、モデルに渡りません。 通達が「当面の間」としか書いていないときは、終了日を空にして業務課が見直す一覧に載せます。

AIへ渡す前に整形する

1. 手引を手続きの章で分ける … 数百ページの手引を、手続きの見出しで分けて取り込みます
2. 必要書類の表を見出し付きで残す … 「必要書類」「署名者」の表は、表のまま取り込みます
3. 通達にメタデータを付ける … 保険会社、種目、手続き、適用開始日、置き換わる章を書きます
4. 置き換わった手引の箇所に終了日を付ける … 通達の適用開始日を終了日として書きます
5. 条文を取り込む … 保険法の解除と受取人の変更の条を、条の見出しを付けて取り込みます
6. 過去の照会の回答を整える … 顧客の氏名と証券番号を消し、保険会社・種目・手続きと回答の日付を付けます
7. 見出しを断片に含める … データストアの作成時に分割を有効にし、includeAncestorHeadings を有効にします

4番目が、この構成でいちばん効きます。 手引そのものを書き換えることはできないので、置き換わった箇所を日付で外すしかありません。通達が届いた日にこれをやるかどうかで、(b)の差し戻しが減るかが決まります。

7番目は、データストアを作る前に決めます。 分割はデータストアの作成のあとでは有効にも無効にもできず、見出しを含める設定は既定では無効です。 「必要書類」の表は、見出しが無いとどの手続きの書類か分かりません。 分割の大きさは100〜500トークンで、既定は500です。

AIに処理させる

させるのは、決まった保険会社・種目・手続きの事務手引と通達から、必要な書類・署名する人・本人確認書類・送り先を見つけ、事務担当が顧客に頼む順に並べて返すことです。 会社を決めること、回すかどうかは、中継プログラムが行います。

answer メソッドの設定は次のようにします。

3行目がいちばん起きやすい失敗です。 会社で絞り込んでいても、その会社の手引に該当の記載が無いと、モデルは過去の照会の回答から別の会社の例を引いて「一般的には」と書きます。 過去の照会の回答にも保険会社のメタデータを付け、同じ絞り込みに掛けます。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは保険代理店の業務課の担当者として、
店舗の事務担当と募集人から、契約の変更・解約の手続きの質問に答えます。
読むのは、顧客に送る書類を準備している社員です。短く答えてください。

【前提】
検索の文の最初に、保険会社、種目、手続きの種類、
契約者と被保険者が同じ人か、受取人の続柄が並んでいます。
保険会社と種目はすでに決まっています。その会社の文書だけを使って答えてください。

【答え方】
1. 最初に、顧客に送る書類を、様式の名前のとおりに並べてください。
2. 次に、それぞれの書類に署名する人を書いてください。
3. 本人確認書類が要る場合は、手引に書かれた種類を書いてください。
4. 通達で変わった点があれば、通達の番号と適用開始日を書いてください。
5. 根拠にした手引の章と通達の番号を書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  他の保険会社の手続きや一般的な知識で補わないでください。
- 「一般的には」「多くの保険会社では」と書かないでください。
- 手引にない書類を足したり、書類を省いてよいと書いたりしないでください。
- 解約の返戻金や保険料の額を書かないでください。
- 他の保険への切り替えについて意見を書かないでください。
- 該当する記載が見つからないときは、
  「この保険会社の手引と通達に該当する記載が見つかりません。業務課から保険会社へ照会します」
  とだけ書いてください。

「一般的には、と書かない」が、この指示の要です。 他社の文書で補うことを禁じるだけでは、モデルは会社名を出さずに一般論として同じ内容を書きます。 乗合の代理店では、その一般論がどの会社にも当てはまらないことがあります。書き方そのものを禁じ、記載が無ければ照会に回します。

検索の文は、中継プログラムが組み立てます。 例えば「保険会社：C社、種目：生命（定期）、手続き：受取人の変更、契約者と被保険者：同じ、新しい受取人：子。必要な書類と署名する人は何か」のように、条件を先に並べ、事務担当の質問の文を最後に足します。 顧客の氏名と証券番号は渡しません。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、チャットと記録に渡します。

{
  "inquiry_id": "",
  "session_id": "",
  "branch": "",
  "contract": { "policy_no_hash": "", "insurer": "", "line": "", "contract_date": "", "verified": true },
  "procedure": "change | holder_or_beneficiary | vehicle_replace | cancellation | other",
  "conditions": { "holder_is_insured": true, "beneficiary_relation": "", "requested_by": "holder | insured | heir | guardian | other" },
  "status": "answered | escalated | skipped",
  "escalate_reason": "switching | holder_deceased | guardian | not_in_manual | insurer_mismatch | not_verified | skipped | user_request | none",
  "answer_text": "",
  "documents": [ { "form_name": "", "signers": [""], "source": "" } ],
  "refs": [ { "insurer": "", "doc_type": "manual | notice | statute | inquiry", "title": "", "section": "", "valid_from": "", "uri": "" } ],
  "inquiry_draft": "",
  "feedback": "resolved | escalated_after | returned_by_insurer | none"
}

1つ目の理由は、refs の insurer を検査に使えることです。 根拠の文書の保険会社が、contract の保険会社と1件でも違えば、回答を出さずに insurer_mismatch で回します。 他社の書類で答えるという失敗を、文の読み方に頼らずに止められます。

2つ目は、inquiry_draft で照会が速くなることです。 答えられなかったときに、保険会社・種目・手続き・関係者の続柄を並べた照会の下書きを、中継プログラムがひな形から作ります。 業務課の担当者は聞き直さずに保険会社へ照会でき、届いた回答は過去の照会の回答として取り込みます。

3つ目は、feedback の returned_by_insurer で差し戻しを数えられることです。 書類が保険会社から戻ったら事務担当が付け、どの会社のどの手続きで差し戻しが多いかが分かります。通達の取り込みが遅れている会社を見つける材料になります。

システムへ連携する

保険会社の代理店向けの画面には、つなぎません。 手続きの入力は事務担当が各社の画面で行い、チャットは書類の案内までです。 契約管理の仕組みの照会のしかたは製品によって違い、この部分は個別の実装が必要です。

人が確認する

事務担当は、回答を読んだあと、根拠の手引と通達のページを開いて確かめてから、顧客へ書類を送ります。 回答の上には、契約管理の仕組みから引いた保険会社・種目と、適用した通達の日付を並べて表示します。

1. 契約が合っているかを見る … 保険会社と種目が、顧客から聞いた契約と同じかを確かめます
2. 署名する人を見る … 契約者と被保険者が別の人の契約では、同意の署名の欄を顧客に必ず伝えます
3. 評価を付ける … 解決した／業務課へ回した／保険会社から差し戻された、を選びます

2番目を軽く見ないでください。 死亡保険の受取人の変更は、被保険者の同意がなければ効力を生じません。書類が揃っていても、同意の署名が無ければ手続きは成り立ちません。

業務課の担当者は、回ってきた質問と照会票だけを見ます。 switching は募集人に乗り換えの説明の記録を確かめ、記録が無ければ手続きを止めます。

目標は、300件をならして1件5分です。 チャットで解決した質問の記録の確認と、回ってきた質問を担当者が判断し照会する時間の平均です。

例外に対処する

5行目の照会の結果は、必ず取り込みます。 保険会社から届いた回答を過去の照会の回答としてデータストアに入れると、同じ質問は次から照会せずに答えられます。 取り込むときは、回答の日付を適用開始日として付けます。

記録を残す

• 質問の文、選んだ聞き返しの値、日時、所属の店舗
• 契約管理の仕組みから引いた保険会社・種目・契約日（証券番号はハッシュで残す）
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（回答、出典、根拠のスコア、回答しなかった理由）
• 回す・回さないの判定と、その理由、照会票と保険会社からの回答
• そのとき効いていた通達の番号と適用開始日

最後の行は、差し戻しの原因を確かめるときに効きます。 保険会社から「様式が古い」と戻ってきたときに、当時の回答がどの通達を根拠にしていたかを並べて見られるようにしておきます。