保険代理店の募集人から届く引受可否の質問に、保険会社の引受規定と通達を根拠にチャットで答え、規定に無いものを管理者経由で照会する

処理の起点を決める

募集人がボットに質問を書いたときに動きます。 最初に保険会社・商品・始期日を選んでもらい、3つがそろうまで質問欄を開きません。 保険会社を選ばずに質問できる作りにすると、3社の規定が混ざった答えになります。

保険会社は「A社」「B社」「C社」「比較したい」から選びます。「比較したい」を選んだときは、3社の規定をそれぞれ別の検索で引き、答えを保険会社ごとに分けて返します。 1回の検索で3社をまとめて引くと、ある社の条件を別の社の答えに混ぜて書くことがあるためです。

始期日は、日付で入れてもらいます。 「来月」「4月から」のような書き方は受け付けません。始期日が改定日の前か後かで、検索する規定の版が変わるからです。 始期日が決まっていない見込みの段階なら、「本日時点で効いている規定」で検索し、答えの冒頭にその旨を書きます。

1つの会話は、同じ保険会社・商品・始期日のまま続けます。 answer メソッドはセッションを使った複数回のやり取りに対応し、前の質問を踏まえて言い換えて検索します。保険会社を変えるときは会話を新しく始めます。 前の社の質問を踏まえた言い換えが混ざるためです。

入力データを集める

質を決めるのは、通達の扱いです。 通達は、規定集の一部を書き換える内容を数ページで伝えてきます。通達を規定集と同じ重みで検索に入れると、古い規定集の記述と新しい通達の記述の両方が根拠に出ます。 通達には、どの規定集のどの章を書き換えるかと、適用を始める始期日を必ずメタデータで付けます。

照会の答えは、そのままでは載せません。 保険会社が個別に認めた答えは、その契約についての判断です。管理者が一般の取扱いとして使えると判断し、保険会社にも確かめたものだけを、社内のFAQとして書き起こして載せます。

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

文書は Cloud Storage のフォルダに置き、メタデータの JSONL と一緒にデータストアへ取り込みます。 1文書ごとに次のメタデータを付けます。

絞り込みに使う項目は、データストアのスキーマで「Indexable」にします。 指定しないと、メタデータを付けていても絞り込みに使えません。絞り込みの式は ANY() による完全一致と AND・OR・NOT で書け、日時の項目は ISO 8601 の形式で比較の演算子を使えます。

insurer: ANY("b") AND product: ANY("auto") AND status: ANY("published")
AND effective_from <= "2026-11-01T00:00:00Z" AND effective_to > "2026-11-01T00:00:00Z"

始期日は2つの比較で挟みます。 effective_from だけで絞ると、改定前の古い版も残ります。新しい版が効き始めたら、古い版の effective_to にその日を入れます。 PDFを消さずに版を重ねて持てるので、改定の前後で始期日の違う契約に、それぞれ正しい版で答えられます。

取り込みは1回だけか、定期の同期（1日・3日・5日の間隔）かを選べます。通達は届いた日に反映したいので、差し替えたあとに手動で取り込みます。

AIへ渡す前に整形する

1. 選択値の確認 … 保険会社・商品・始期日が、決まった値の一覧と日付の形式に合うかを確かめます
2. 個人情報の除去 … 質問の文面から、お客さまの氏名、電話番号、証券番号らしい文字列、登録番号（ナンバー）を伏せてから検索にかけます
3. 照会に回す規則の照合 … 「例外」「今回だけ」「事故歴」「前回断られた」「特別に」などの語と、引受審査の結果を尋ねる言い回しを見ます
4. 絞り込みの式の組み立て … 選択値から式を作ります。募集人の書いた文字を式に混ぜません
5. 取り込み前の文書の確認 … 新しいPDFを置くとき、通達なら書き換える規定集と章、適用の始期日がメタデータに入っているかを確かめます

2番目を省かないでください。 募集人はお客さまの名前やナンバーをそのまま書いてきますが、規定を探すのには要りません。

レイアウトパーサーと分割の設定は、データストアを作る時点で決めます。 分割（チャンク）は、データストアを作った後に有効・無効を切り替えられません。また、パーサーの設定を後から変えても、すでに取り込んだ文書は解析し直されません。 分割の大きさは100〜500トークンで、既定は500です。分割した塊に見出しを含める設定は、既定で無効なので有効にします。規定集の表は、どの章のどの商品の表かが見出しに書かれているからです。

AIに処理させる

させるのは、絞った規定の中から該当する条件を探し、規定の言葉で「規定上どうなっているか」を答えることだけです。

答えの頭には、必ず3つのどれかを付けさせます。 「規定上、引受の対象」「規定上、引受の対象外」「規定上、保険会社への相談が必要」の3つです。どれにも当てはまらないときは、答えを作らせずに照会へ回します。

指示内容を固定する

answer メソッドの promptSpec.preamble に、次の内容を入れます。

あなたは損害保険の乗合代理店で、募集人からの引受と特約の質問に答える社内の案内係です。
検索された保険会社の引受規定集・商品パンフレット・代理店向け通達だけを根拠に答えてください。

【答え方】
- 答えの1行目に、次のどれか1つを書いてください。
  「規定上、引受の対象」「規定上、引受の対象外」「規定上、保険会社への相談が必要」
  どれとも言えないときは「規定に記載がないため、管理者経由で照会します」とだけ答えてください。
- 2行目以降に、規定の条件をそのまま示し、どの章のどの表の記載かを書いてください。
- 通達と規定集の記載が両方ある場合は、通達の記載を優先し、通達の名前と適用の始期日を書いてください。
- 年式、年齢、金額、日付は、文書の表記のまま写してください。言い換えや計算をしないでください。
- 規定に「個別に相談」「保険会社に確認」などと書かれている場合は、
  「規定上、保険会社への相談が必要」としてください。

【答えないこと】
- 「引き受けます」「通ります」「大丈夫です」など、引受を確約する言い方をしないでください。
- 検索された文書に無い条件を、推し量って補わないでください。
- 検索された保険会社以外の会社の取扱いに触れないでください。
- 保険料の金額、見積の結果を答えないでください。
- 告知の内容をどう書くかについて、助言をしないでください。

「確約する言い方をしない」を書かないと、規定上の対象を「引き受けられます」と言い換えます。 規定上の対象でも、お客さまの告知の内容や過去の事故の状況で、保険会社が引受を断ることはあります。規定に合うことと、引き受けてもらえることは違うので、1行目の言い方を3つに固定します。

あわせて、answer メソッドの設定で次を有効にします。

boostSpec を使うのは、数ページの通達が数百ページの規定集に検索の当たりで負けるためです。 絞り込みで版を選び、ブーストで通達を前に出します。

出力形式を固定する

中継プログラムは、answer メソッドの応答から次の形の記録を作ります。 チャットに返すのは answer_text と citations だけです。

{
  "session_id": "",
  "insurer": "b",
  "product": "auto",
  "inception_date": "2026-11-01",
  "question_masked": "",
  "route": "answered | escalated_rule | escalated_no_answer | escalated_low_support | escalated_consult",
  "rule_status": "eligible | not_eligible | consult_required | none",
  "answer_text": "",
  "citations": [ { "doc_type": "rules", "title": "", "version": "", "section": "", "uri": "" } ],
  "support_score": 0.0,
  "inquiry_draft": null,
  "created_at": ""
}

1つ目の理由は、rule_status を答えの文から切り離して持てることです。 1行目の3つの言い方を中継プログラムが読み取り、決まった値にします。consult_required なら、答えを返したうえで照会票の下書きも作ります。 規定が相談を求めているものを、募集人の判断で止めないためです。

2つ目は、support_score で答えを止められることです。 answer メソッドは、答えがデータストアの内容にどれだけ裏付けられているかを0〜1の値で返せます。この値が自社で決めた境目を下回ったら、答えを表示せずに照会へ回します。 境目は、最初の1か月の記録を見て決めます。

3つ目は、citations の version で、どの版で答えたかが残ることです。 改定の前後で、募集人が「前と言っていることが違う」と言ってきたときに、始期日と版の組み合わせで説明できます。

照会に回したときは、inquiry_draft に次の形の照会票を入れ、管理者の受付の一覧に書き込みます。

「足りない情報」の列が、照会の往復を減らします。 保険会社がいつも聞いてくる項目のうち、会話に無いものを中継プログラムが書き出します。

システムへ連携する

保険会社への照会は、自動では送りません。 照会は保険会社が決めた経路（代理店担当者への連絡や、代理店向けシステムの照会の機能）で、管理者が行います。 中継プログラムは照会票の下書きを作るところまでです。

社内チャットのボットの作り方は、使っているチャットの製品によって変わります。 本記事では、チャットから中継プログラムのAPIを呼べることを前提にしており、この部分は利用環境に応じた個別実装が必要です。

人が確認する

AIの答えを、募集人に返す前に人が見ることはしません。 その代わり、答える範囲を規定の記載に限り、照会と記録の点検で守ります。

1. 照会の受付を毎日見る … escalated_rule と escalated_consult を先に見ます。お客さまを待たせている質問が多いためです
2. 答えた会話を週に1回抜き取る … answered から数十件を選び、出典の版と始期日が合っているか、確約する言い方が出ていないかを見ます
3. 通達を取り込んだら確かめる … 取り込みの後、改定の対象の質問を数件投げ、始期日の前後で答えが切り替わるかを見ます
4. 月に1回、照会の記録を見る … 一般の取扱いとして書き起こせるものを選び、保険会社に確かめてから社内のFAQに載せます

2番目では、取り違えの影響が大きい3社の比較を優先して見ます。

このチャットは規定を探す時間を減らすもので、引受の確認を代わりに行うものではありません。

例外に対処する

記録を残す

• 会話ごとの保険会社・商品・始期日、伏せた後の質問の文面、答え、出典の版、support_score
• 使った絞り込みの式とブーストの設定
• 照会票の内容、照会した日時、保険会社の答え、募集人へ返した日時
• 抜き取りで見つけた答えのずれと、直した内容
• 文書の取り込みの履歴（いつ、どの版を、どの適用期間で入れたか）
• 月ごとの route と rule_status の件数、照会の理由の種類

5つ目を残すのは、版の誤りを後から追うためです。 適用の始期日を間違えて入れていたと分かったとき、その期間の会話を洗い出せます。