損害保険会社の査定担当が、火災保険の風災・水災の事故で、査定マニュアルと本社の照会回答を引き、支払の判断の根拠を探す

処理の起点を決める

起点は、査定担当が事案の画面から疑問を入れたことです。 検索の欄は事案の画面に置き、事案の番号を持ったまま中継プログラムを呼びます。 担当者が日付や商品を打ち込む欄は作りません。

事故日が空、または事故の種類が「調査中」の事案では、約款とマニュアルだけを検索し、災害ごとの取扱いは引きません。 画面に「事故日が確定していないため、災害ごとの取扱いは確かめていません」と出します。

もう一つのトリガーは、文書の更新です。 約款の改定、マニュアルの改訂、照会回答の追加や取り消し、災害ごとの取扱いの発出のたびに、本社がメタデータを書きます。前の版は消さず、終わりの日か status を書いて残します。 取り込みは毎晩です。

入力データを集める

質を決めるのは、照会回答の status です。 照会回答は、本社がマニュアルに取り込んだ後もそのまま残り、取り消したものも消されていないことが多いはずです。「有効」（active）、「マニュアルに反映済み」（merged）、「取り消し」（withdrawn）を1件ずつ付けます。 取り消したものは検索の対象から外し、反映済みのものはマニュアルより下に置きます。

もう一つは、文書ごとの review（本社の審査が要るか）です。 マニュアルの節のうち、支払わない場合の当てはめ、経年劣化や欠陥との見分け、故意や不正の疑いの扱いなどは、拠点だけで決めず本社の審査に回すと社内で決めておき、その節に review: true を付けます。

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

約款は商品ごと・版ごとに章で分け、マニュアルは節ごと、照会回答と通達は1件ずつファイルにして Cloud Storage に置きます。メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"qa-2025-0412","structData":{"doc_kind":"hq_reply",
 "product":["home_fire"],"peril":["wind"],"status":"active",
 "review":true,"answered_date":"2025-09-03T00:00:00Z",
 "effective_from":"2025-09-03T00:00:00Z",
 "effective_to":"2099-12-31T23:59:59Z"},
 "content":{"mimeType":"application/pdf","uri":"gs://claims-docs/qa-2025-0412.pdf"}}

災害ごとの取扱いには disaster_id、対象の都道府県の prefecture、事故日の期間を書きます。事案のたびに、中継プログラムが絞り込みの条件を作ります。 公式の構文では、文字の項目は ANY() で列挙した値との完全一致を見られ、NOT を前に付けて否定でき、日時の項目は ISO 8601 の文字列と比べられます。項目は索引可能にしておく必要があります。

product: ANY("home_fire") AND NOT status: ANY("withdrawn")
AND (
 (doc_kind: ANY("policy") AND effective_from <= "2024-06-01T00:00:00Z"
  AND effective_to >= "2024-06-01T00:00:00Z")
 OR
 (doc_kind: ANY("manual","hq_reply") AND effective_from <= "2026-10-15T00:00:00Z"
  AND effective_to >= "2026-10-15T00:00:00Z")
 OR
 (doc_kind: ANY("disaster_rule") AND disaster_id: ANY("T2609")
  AND prefecture: ANY("kochi")
  AND effective_from <= "2026-09-21T00:00:00Z"
  AND effective_to >= "2026-09-21T00:00:00Z")
)

約款は保険始期、マニュアルと照会回答は照会した日、災害ごとの取扱いは事故日です。 災害の識別子が付いていない事案では、3つ目の括弧を外します。

並べ替えは boostSpec で行います。 公式では、conditionBoostSpecs の条件に −1〜1 の値を付けて上げ下げでき、日時の項目の経過で上げ下げする指定（FRESHNESS）もあります。

"boostSpec": {"conditionBoostSpecs": [
  {"condition": "doc_kind: ANY(\"policy\",\"manual\")", "boost": 0.1},
  {"condition": "status: ANY(\"merged\")", "boost": -0.1}
]}

約款とマニュアルを上に、マニュアルに反映済みの照会回答を下に寄せます。 同じ内容がマニュアルにあるなら、根拠はマニュアルの節にしたいからです。

AIへ渡す前に整形する

1. 約款とマニュアルを章と節で分ける … 節の番号と見出しを本文に残し、支払事由・支払わない場合・損害の額の決め方を別のファイルにします
2. 照会回答を1件ずつ文書にする … 照会した拠点・担当者・契約者の名前・住所を外し、照会の要旨、回答、根拠の条文、回答の日、status、review を書きます
3. 災害ごとの取扱いに期間と地域を付ける … 通達の本文から、災害の識別子、都道府県、事故日の始まりと終わりを書きます。市区町村で区切る取扱いは、市区町村の一覧も本文に残します
4. 疑問の文を整える … 担当者の文から、契約者の名前、番地、電話番号の形の文字を見つけたら外し、記録に印を付けます
5. 事案の項目を検索の文に付ける … 事故の種類と商品を、疑問の文の先頭に付けます

2番目で拠点と担当者まで外すのは、照会回答が「どの拠点がこの判断をしたか」として読まれないようにするためです。 根拠として要るのは、回答の中身と条文だけです。

3番目で市区町村の一覧を本文に残すのは、都道府県の絞り込みだけでは足りない取扱いがあるからです。 都道府県で絞って引いた後、担当者が本文の一覧で事案の所在を確かめます。

AIに処理させる

させるのは、絞り込まれた約款・マニュアル・照会回答・災害ごとの取扱いの中から、疑問に関わる条文と手順を探し、本文のまま引用して並べることです。

3つ目がいちばん起きやすい失敗です。 マニュアルの見分けの観点（さびの有無、割れ口の色など）を引用した後、AIは疑問の文に書かれた様子から「経年劣化と考えられます」と書き足したがります。 その一文は、写真を見ていない者の結論です。

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

公式では、userPseudoId は128文字までの仮名の識別子で、個人を特定できる情報を入れてはならないとされています。担当者の社員番号から作った別の値を使います。

指示内容を固定する

answer メソッドの promptSpec.preamble に、次の指示を入れます。中継プログラムは、商品、事故の種類、保険始期、事故日、災害の名前を疑問の文の先頭に付けます。

あなたは損害保険会社の査定担当の調べものを手伝う立場です。
読むのは火災保険の自然災害の事故を査定している担当者で、
答えを査定メモに写す前に、必ず原文を開いて確かめます。

【前提】
検索の対象は、保険始期に効く版の約款、いま効いている査定
マニュアルと本社の照会回答、事故日と地域に当たる災害ごとの
取扱いだけです。取り消された照会回答は含まれていません。

【答え方】
1. 疑問に関わる約款の条文を、約款の版と条の番号を付けて引用する
2. 損害の確かめ方を、査定マニュアルの節の番号を付けて引用する
3. 同じ論点の本社の照会回答があれば、回答の日を付けて引用する
4. 災害ごとの取扱いが当たれば、災害の名前・期間・地域を書く
5. 根拠に当てはめるために、担当者が確かめる事実を3つまで挙げる

【厳守事項】
- 「お支払いの対象です」「お支払いできません」「免責です」
  と結論を書かないでください。
- 経年劣化か、災害による損害かを判断しないでください。
  見分けの観点を引用するところまでにしてください。
- 損害の額、保険金の額、免責の金額を計算しないでください。
- 検索結果に無い条文、別の版の約款で答えないでください。
- 一般的な保険の考え方で補わないでください。
- 照会回答だけが根拠のときは、「照会回答による」と書き、
  マニュアルの節が見つからなかったことを書いてください。
- 契約者や関係者の名前を書かないでください。
- 根拠が見つからないときは、
  「該当する条文と手順を確認できませんでした」とだけ書いてください。

「照会回答だけが根拠のとき」を分けて書かせるのは、照会回答がその事案の事情を見た個別の回答だからです。 マニュアルに無い論点で照会回答だけが根拠なら、今回の事案に同じように当てはまるかを、担当者が本社に確かめる必要があります。

出力形式を固定する

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

{
  "claim_id": "",
  "session": "",
  "question": "",
  "policy_version": "",
  "disaster_id": "",
  "answer_text": "",
  "citations": [ { "doc_kind": "policy | manual | hq_reply | disaster_rule",
                   "title": "", "section": "", "status": "active | merged",
                   "review": false, "quote": "", "uri": "" } ],
  "facts_to_check": [],
  "route": "self | review",
  "route_reasons": [],
  "skipped": ""
}

引用は references から取ります。review と status は文書の structData から中継プログラムが写し、AIの文からは読み取りません。 引用の位置（startIndex／endIndex）は UTF-8 のバイト数なので、日本語の文を文字数で切るとずれます。

review_section と reply_only は本社の審査へ回ります。 conclusion_words は語を消して担当者に戻し、no_disaster_rule は地域と期間の登録を本社に確かめ、skipped は担当者が文書を開きます。

システムへ連携する

本社への照会の下書きには、引用と route_reasons を付けます。 本社の担当者は、拠点がどの条文を見て迷ったかから読み始められます。

人が確認する

根拠を当てはめて判断するのはいつも査定担当で、支払と不払いを決めるのは決裁権限を持つ職員です。

1. 版を確かめる … policy_version が保険始期に効く版かを見ます
2. 原文を開く … 引用の前後の文を読み、条文の但し書きや例外を確かめます
3. 事実を確かめる … facts_to_check を、写真・見積り・契約者への聞き取りで確かめます
4. review は本社へ回す … 契約者には「本社で確認しています」と伝えます

2番目を省かないでください。 約款の支払わない場合の条文には但し書きが付くことが多く、引用が但し書きの手前で切れていると、反対の意味に読めます。

例外に対処する

記録を残す

• 事案の番号、疑問の文（外した語の印を含む）、担当者の仮の識別子、会話の識別子
• 選ばれた約款の版、絞り込みの条件、boostSpec と preamble の版
• answer メソッドの返り値の全文（answerText、citations、references、answerSkippedReasons）
• route と route_reasons、本社への照会と回答

会話は既定で60日より古いものが自動的に削除されるので、査定の根拠として残すものは自社の保管先に写します。 苦情や訴訟は事故から長く経ってから来ることがあるためです。