損害保険会社の営業支援部が、代理店からの引受照会に、始期日に効く引受基準書と過去の回答を引いて回答の下書きを作る

処理の起点を決める

起点は、代理店システムに照会が登録されたことです。 知らせ方（通知の呼び出し、または数分おきの一覧の読み出し）はシステムの作りに合わせて選び、中継プログラムは照会の番号を受け取って中身を読み直します。

始期日の欄が空の照会は、検索しません。 「始期日をお知らせください」という下書きだけを作り、担当に渡します。

もう一つのトリガーは、基準書の改定と通達の発出です。 引受部が新しい版を置き、メタデータに版の期間を書きます。前の版は消さず、終わりの日を書いて残します。 取り込みは毎晩まとめて行います。

入力データを集める

質を決めるのは、基準書の節ごとに付ける権限の区分です。 基準書は「引受可」「条件付きで引受可」「引受部と協議」「引受不可」のような区分を業種や条件ごとに書いています。営業支援部が答えてよいのはどれかを、引受部が節ごとに決めて authority に書きます。

過去の回答には、協議して決めたものかどうかも書きます。 協議による回答はその申込の事情を見ての個別の判断なので、decision に「基準どおり」か「協議による個別の判断」かを入れます。

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

基準書は商品ごと・版ごとに章で分け、通達と過去の回答は1件ずつファイルにして Cloud Storage に置きます（公式では1ファイル200MB、一度に10万ファイルまで）。メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"fire-sme-guide-v12-ch4-sec2","structData":{"doc_kind":"guide",
 "product":["fire_sme"],"industry_code":["5610","5620"],
 "authority":"consult",
 "effective_from":"2026-04-01T00:00:00Z",
 "effective_to":"2099-12-31T23:59:59Z"},
 "content":{"mimeType":"application/pdf","uri":"gs://uw-docs/fire-sme-guide-v12-ch4-sec2.pdf"}}

authority は営業支援部で回答可（support）か引受部と協議（consult）、過去の回答には回答の日 answered_date と decision も持たせます。照会のたびに、中継プログラムが絞り込みの条件を作ります。 公式の構文では、文字の項目は ANY() に並べた値のどれかと完全に一致するかを見られ、日時の項目は ISO 8601 の文字列と比べられ、AND・OR と括弧で組み合わせられます。項目はスキーマで索引可能にしておかないと絞り込みに使えません。

product: ANY("fire_sme") AND industry_code: ANY("5610")
AND (
 (doc_kind: ANY("guide") AND effective_from <= "2027-01-01T00:00:00Z"
  AND effective_to >= "2027-01-01T00:00:00Z")
 OR
 (doc_kind: ANY("notice","past_reply") AND effective_from <= "2026-10-15T00:00:00Z"
  AND effective_to >= "2026-10-15T00:00:00Z")
)

基準書は始期日、通達と過去の回答は照会の日です。 過去の回答の effective_to には、前提にした基準書の版が終わった日を書きます。改定されると、その版を前提にした回答は検索から外れます。

並べ替えは boostSpec で行います。 公式では、conditionBoostSpecs の条件に −1〜1 の値を付けて上げ下げでき、日時の項目の経過期間で上げ下げする指定（FRESHNESS）もあり、0.1以下の小さな値から始めるよう勧めています。

"boostSpec": {"conditionBoostSpecs": [
  {"condition": "doc_kind: ANY(\"guide\")", "boost": 0.1},
  {"condition": "doc_kind: ANY(\"past_reply\")",
   "boostControlSpec": {"fieldName": "answered_date",
     "attributeType": "FRESHNESS", "interpolationType": "LINEAR",
     "controlPoints": [{"attributeValue": "30D", "boostAmount": 0.05},
                       {"attributeValue": "365D", "boostAmount": -0.05}]}}
]}

基準書を上に寄せ、過去の回答は新しいものを上に、1年を過ぎたものを下に寄せます。

AIへ渡す前に整形する

1. 基準書を節ごとに見出しを付けて分ける … 引受部の原稿からHTMLで書き出し、業種の区分表は業種コードの範囲ごとに分けます
2. 節ごとに権限の区分を付ける … 引受部が authority を書きます。「可」と「協議」が混ざる節は、分けるか consult にします
3. 版の期間を付ける … 改定の履歴から、版ごとの始まりと終わりの日を書きます
4. 過去の回答を整える … 1件ずつ文書にし、代理店名・代理店コード・顧客の名称・番地を外し、 根拠の条文、前提の版、decision を書きます
5. 照会の本文を整える … 顧客の名称や人名は検索の文から外し、記録に印を付けます

4番目で代理店と顧客を外すのは、引用の中にほかの代理店の顧客の名前が出ないようにするためです。 業種と建物の条件が残っていれば材料としては足ります。2番目で迷ったら consult に倒します。 狭めに取って失うのは、引受部の数分の時間です。

AIに処理させる

させるのは、始期日の版の基準書と、いま効いている通達・過去の回答から、照会に当たる区分と条文を探し、引用して回答の下書きを書くことです。

4つ目が、いちばん起きやすい失敗です。 協議で決まった過去の回答は、文としては基準と同じ形をしているからです。

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

filteringLevel を高くすると、根拠の弱い回答は生成されず、answerSkippedReasons に LOW_GROUNDED_CONTENT が返ります（関係の薄い内容で止まったときは NO_RELEVANT_CONTENT）。どちらでも下書きは作らず、担当が基準書を開きます。

指示内容を固定する

answer メソッドの promptSpec.preamble に、次の指示を入れます。中継プログラムは、商品、業種コード、構造、築年、保険金額、始期日、照会の日を検索の文の先頭に付けます。

あなたは損害保険会社の営業支援部の担当として、代理店からの引受の
照会に、引受基準書と通達を根拠に回答の下書きを作る立場です。
読むのは営業支援部の担当で、代理店に返す前に必ず確かめます。

【前提】
検索の文の最初に、商品、業種コード、建物の構造、築年、保険金額、
始期日、照会の日が並んでいます。基準書は始期日に効く版、
通達と過去の回答は照会の日に効くものだけが検索の対象です。

【答え方】
1. 照会に当たる区分を、基準書の名前・版・節の番号を付けて示す
2. 区分を決めている本文と、引受の条件を、本文のまま引用する
3. 業種や地域に通達があれば、通達の番号と本文を引用する
4. 区分を決めるのに足りない事実を、代理店に聞くこととして3つまで挙げる
5. 以上を、代理店の担当に向けた丁寧な文で、300字程度にまとめる

【厳守事項】
- 「お引き受けできます」「お引き受けできません」と言い切らないで
  ください。基準書の区分を、区分の名前のまま書いてください。
- 保険料、割増、割引の額や率を書かないでください。計算もしないでください。
- 検索結果に無い基準、別の版の基準書で答えないでください。
- 一般的な保険の引受の考え方で補わないでください。
- 過去の回答だけが根拠のときは、「過去の回答による」と書き、
  回答の日を書いてください。協議による個別の判断の回答は、
  「過去に協議で個別に判断した例」と書き、基準として書かないでください。
- 代理店名、顧客の名称、人の名前を書かないでください。
- 当たる区分が見つからないときは、
  「基準書で該当する区分を確認できませんでした」とだけ書いてください。

「区分の名前のまま書く」を明記しないと、AIは区分を言い換えます。 「条件付きで引受可」を「お引き受けできる見込みです」と書き、代理店はそれを顧客に「引き受けてもらえます」と伝えます。 条件の落ちた回答は、申込の段階で覆ります。

出力形式を固定する

answer メソッドの返り値と照会の項目を、中継プログラムが次の形にまとめます。

{
  "inquiry_id": "",
  "product": "fire_sme | liability | work_injury",
  "industry_code": "",
  "inception_date": "",
  "guide_version": "",
  "draft_reply": "",
  "citations": [ { "doc_kind": "guide | notice | past_reply", "title": "",
                   "section": "", "authority": "support | consult",
                   "decision": "", "quote": "", "uri": "" } ],
  "missing_facts": [],
  "grounding_score": 0,
  "route": "reply | consult",
  "route_reasons": []
}

引用は references から取ります。各要素にはチャンクの本文と文書の structData が付くので、authority と decision はそこから中継プログラムが写し、AIの文からは読み取りません。 引用の位置（startIndex／endIndex）は UTF-8 のバイト数なので、日本語の文を文字数で切るとずれます。

route は次の規則で決めます。

どれにも当たらないものだけが reply です。 引受部へ回るのは consult_section・individual_only・notice_present・amount_over で、past_reply_only と skipped は担当が基準書を開いて答え、decisive_words は語を消して担当に戻します。

システムへ連携する

協議の1行には、照会の6項目、引用、route_reasons、下書きを付けます。 引受部は引用を読んで判断するところから始められ、結果は decision を「協議による個別の判断」として過去の回答に入ります。

人が確認する

代理店に答えるのはいつも営業支援部の担当で、協議の区分を判断するのはいつも引受部です。

1. 版を確かめる … guide_version が始期日に効く版かを見ます
2. 引用を読む … 区分を決めている本文が照会の業種と条件に当たっているかを読み、境目の業種は別表で確かめます
3. 足りない事実を聞く … missing_facts を代理店に聞きます
4. consult は引受部へ回す … 代理店には「引受部で確認しています」と返します

2番目を省かないでください。 区分表は似た名前の業種が隣り合い、検索が隣の行を引くことがあります。引受部は毎週、consult の一覧と reply の抜き取りを読み、 同じ協議が続く業種を基準書の改定の候補にします。

例外に対処する

4行目は、工場と倉庫をまとめる照会で起きます。 まとめて引くと、片方の基準が漏れます。

記録を残す

• 照会の6項目（顧客の名称と人名は外したもの）、代理店コード、照会の日、担当
• 選ばれた基準書の版と、絞り込みの条件、boostSpec と preamble の版
• answer メソッドの返り値の全文（answerText、citations、references、根拠のスコア、answerSkippedReasons）
• route と route_reasons、担当が直した後の回答の全文、引受部の協議の結果
• 担当が直す前と後の差分

選ばれた版を残すのは、後から誤りを問われたときに、担当の読み違いか版の登録の誤りかを切り分けるためです。