損害保険の代理店で事故の連絡を受けたときに、過去の事故対応の記録から似た事故の経過・必要書類・お客さまへの説明を探して担当者に返す

処理の起点を決める

検索は、受付メモが保存されたときに動かします。 事務担当が事故の聞き取りを終えて受付メモを保存し、保険会社への報告を済ませるころには、画面の横に似た事故のまとめが出ている、という流れです。担当者が「検索する」と思い立つ前に出ていることが大事で、検索の画面を別に開かせると、忙しい時間ほど使われません。

保存のたびに動かすと、書きかけで保存したメモでも検索が走ります。そこで、保険会社と保険の種類と事故の型の3つが入っていないメモでは検索しません。 3つがそろった時点で初めて動きます。後から受付メモを書き足したときは、事故の型が変わったときだけ検索し直します。

取り込みは、事故対応が「完了」になった記録を夜間にまとめて行います。 対応中の記録は経過が途中で、必要だった書類もそろっていません。途中の記録を混ぜると、「このあと何が起きるか」の見通しが短く出ます。

入力データを集める

質を決めるのは、下の2つです。 事故の型の一覧が無いと、検索を保険会社と保険の種類でしか絞れず、自動車保険の中で物損と人身が混ざって出てきます。 手引の改訂日が無いと、改訂前の事故の記録を、いまの書類の根拠のように読んでしまいます。

お客さまの不安は、受付メモに1行で書いてもらいます。 「修理の間の代車が要るか」「相手の連絡先が分からない」「下の階に謝りに行くべきか」。似た事故の記録の中で、同じ不安にどう答えたかを探すための手がかりになります。

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

顧客管理システムから、完了日・保険会社・保険の種類・事故の型・対応メモの全文を書き出します。API があればそれを使い、無ければ夜間のCSVの書き出しを Lambda が読みます。取り込みの単位は1件の事故です。

索引には、伏せたあとの文章だけを入れます。 氏名、電話番号、住所の番地、証券番号、車両の登録番号、相手方の名前は、取り込みの前に伏せます。探したいのは事故の中身で、誰の事故かではありません。 元の記録は顧客管理システムにあり、記録の番号から人がたどれれば足ります。

AIへ渡す前に整形する

1. 伏せ字 … 氏名、電話番号、メールアドレス、住所の番地、証券番号、車両の登録番号、相手方の名前を、規則（正規表現と顧客マスタの照合）で ［氏名］ のような記号に置き換えます
2. 記録の整理 … Claude に対応メモを読ませ、「経過」「必要だった書類」「お客さまへの説明」「お客さまの不安と答え」の4つに分けさせます
3. 人による確認 … 整理した内容を、記録を閉じた担当者が確かめます。確定するまで索引には入れません
4. 埋め込みの作成 … 取り込みのパイプラインで、「事故の状況」と「経過」の文から埋め込みを作ります
5. 項目の付与 … 保険会社・保険の種類・事故の型・完了日・支店を項目として入れます
6. 手引の改訂日との比較 … 完了日がその保険会社の手引の最終改訂日より前なら before_revision: true を付けます

2番目と3番目を分けているのは、整理の誤りが検索の質にそのまま出るからです。 例えば「代車の手配をした」を「必要だった書類」の欄に入れてしまうと、書類を探す人に代車の話が出ます。記録を閉じた担当者が、そのときの経過を一番よく覚えています。 確認は1件1分程度で、完了の処理の一部にします。

1番目は規則でやり、AIに任せません。 伏せ漏れはそのまま索引に残り、他の支店の担当者にも見えます。漏れても気づける仕組みとして、伏せたあとの文に電話番号や証券番号の形が残っていないかを、もう一度規則で確かめます。

AIに処理させる

AIにさせることは2つの場面に分かれます。 取り込みのときの記録の整理と、検索のときのまとめです。

検索のときのまとめは、次の4つです。

• 経過の流れ … 似た事故で、報告のあと何がどの順に起きたか（修理工場の見積、保険会社の担当の決定、相手方との連絡、書類の回収、完了まで）
• 必要だった書類 … 似た事故で実際に回収した書類。「手引で確認すること」を必ず添える
• お客さまへの説明の要点 … 似た事故で、担当者が最初に何を伝え、どこで質問が出たか
• 違いの指摘 … 上位の記録どうしで経過が分かれている箇所と、その分かれ目になった事情

4つ目がいちばん役に立つことが多い項目です。 似た事故でも、相手がいたかどうか、けががあったか、修理か買い替えかで経過が分かれます。「この事故はどちらに当たりそうか」を担当者が考える材料になります。

させないことの中で、いちばん起きやすいのは支払の見込みです。 過去の記録には「全額支払われた」「一部のみ」と書かれていることがあり、まとめに写すと、担当者がそのままお客さまに伝えかねません。支払の結果はまとめに出さず、経過の一部として「保険会社の判断が出た」とだけ書かせます。

指示内容を固定する

あなたは損害保険の代理店で、事故の連絡を受けた事務担当を手伝う立場です。
下の「似た過去の事故対応の記録」だけを根拠に、今回の事故の参考になる点を
まとめてください。記録に書かれていないことは書かないでください。

【今回の事故】
保険会社：{insurer}　保険の種類：{line}　事故の型：{accident_type}
受付メモ（伏せ字済み）：{intake_memo}
お客さまの不安：{customer_concern}

【まとめる項目】
1. 経過の流れ：似た事故で、報告のあと何がどの順に起きたか
2. 必要だった書類：似た事故で実際に回収した書類。
   各書類の後ろに必ず「（保険会社の現在の手引で確認）」と付ける
3. お客さまへの説明の要点：最初に何を伝えたか、どこで質問が出たか、
   お客さまの不安にどう答えたか
4. 違いの指摘：記録どうしで経過が分かれている箇所と、その事情

【厳守事項】
- 保険金が支払われるか、いくら支払われるかの見込みを書かないでください。
  記録に支払の結果が書かれていても、まとめには写さないでください。
- 記録に無い書類を、一般的に必要そうだという理由で足さないでください。
- 保険会社の手引の内容を、あなたの知識から書かないでください。
- 過失の割合や責任の有無について書かないでください。
- 記録が1件しか当たらない項目は、「1件のみ」と明記してください。
- 記録のどれにも書かれていない項目は「該当する記録なし」と書いてください。
- 今回の事故と記録の事故で、相手の有無・けがの有無が違う場合は、
  その違いを先頭に書いてください。

検索で当たった記録は、検索結果のブロック（type: "search_result"、source に記録の番号、title に事故の型と完了月、content に4つの欄）として渡します。

「記録に無い書類を足さない」を明記しないと、一般的な書類を補ってきます。 自動車の物損なら「修理見積書、事故証明書、写真」と、それらしく並べます。どれも正しそうに見えるのが問題です。 保険会社によって、また事故の型によって要らないものがあり、要らない書類を頼まれたお客さまは手間をかけたうえに代理店への信頼を下げます。

「支払の結果を写さない」は、厳守事項の1行目に置きます。 担当者が読む画面にある以上、いつかお客さまへの説明に混ざります。代理店は支払を約束する立場にありません。

出力形式を固定する

引用付きの文章で受け取り、プログラムで4つの欄に振り分けて画面に出します。

Claude の検索結果のブロックを使うと、回答の文に、どの検索結果のどのブロックから取ったかの引用が付きます。 引用は search_result_location という形で返り、source・title・cited_text（引用したブロックの文）・start_block_index と end_block_index（content の中の位置）を持ちます。記録の4つの欄をそれぞれ別のブロックにして渡せば、「経過」から取ったのか「必要だった書類」から取ったのかまで分かります。

画面に出す形は次のとおりです。

{
  "query_id": "Q-2026-10-0412",
  "filters": { "insurer": "A社", "line": "自動車", "accident_type": "車両の物損・相手あり" },
  "hits": [
    { "record_id": "J-2025-0731", "closed": "2025-09", "score": 0.82,
      "before_revision": false }
  ],
  "summary": {
    "timeline":    [ { "text": "", "cites": ["J-2025-0731#0"] } ],
    "documents":   [ { "text": "", "cites": ["J-2025-0731#1"], "note": "保険会社の現在の手引で確認" } ],
    "explanation": [ { "text": "", "cites": ["J-2024-1102#2"] } ],
    "differences": [ { "text": "", "cites": ["J-2025-0731#0", "J-2024-1102#0"] } ]
  },
  "flags": ["single_record_only", "before_revision"]
}

1つ目の理由は、引用の無い文を画面で見分けられることです。 まとめの文に引用が付いていなければ、記録から取っていない文です。cites が空の文は灰色で出し、説明に使わない運用にします。

2つ目は、before_revision を書類の欄に結び付けられることです。 引用元の記録が手引の改訂より前なら、その書類の行に印を出します。担当者が手引を開く理由が、画面の上で見えます。

なお、Claude API では引用（Citations）と構造化出力は一緒に使えません。 そのため、JSON の形はプログラムの側で組み立てます。引用の有効・無効は、1回の依頼の中のすべての検索結果でそろえる必要があることにも注意します。

システムへ連携する

検索パイプラインは次のように作ります。重みは言葉の句0.4、意味の句0.6から始め、第14章の試しで直します。

PUT /_search/pipeline/accident-hybrid
{
  "phase_results_processors": [
    { "normalization-processor": {
        "normalization": { "technique": "min_max" },
        "combination": { "technique": "arithmetic_mean",
                         "parameters": { "weights": [0.4, 0.6] } } } }
  ]
}

検索は、filter に保険会社・保険の種類・事故の型・完了日の範囲を bool でまとめ、queries に match（受付メモの文）と neural（同じ文から作る埋め込み）を並べます。hybrid クエリは問い合わせの一番外側に置く必要があり、function_score などの中には入れられません。新しい記録を少し上げたいときも、点数の関数ではなく完了日の範囲の絞り込みで扱います。

人が確認する

人が確認するのは、取り込みの整理と、検索のまとめの2か所です。

1. 取り込み … 記録を閉じた担当者が、4つの欄の振り分けを確かめます。確定するまで索引に入れません
2. 検索のまとめ … 担当者が、まとめと引用元の記録を読みます。引用の無い文は使いません
3. 必要書類 … 保険会社の現在の手引で確かめます。before_revision の印があるものは必ず
4. お客さまへの説明 … まとめをそのまま読み上げず、今回の事故との違い（相手の有無、けがの有無）を考えて話します
5. 参考にした記録の番号を残す … 対応メモに記録の番号を書きます

3番目を省かないでください。 過去の記録の書類は、その時点の手引に基づいています。改訂のあとに同じ書類を頼むと、要らない書類を集めさせるか、足りない書類で手続きが止まります。 どちらもお客さまの手間になります。

目標は、1件の調べものを8分にすることです。 内訳は、まとめと引用元を読むのに4分、手引で書類を確かめるのに2分、説明の組み立てに2分です。8分を超える事故が続くなら、事故の型の一覧が粗いか、記録の整理が足りません。

例外に対処する

上から3行目までが、運用を始めた直後に多い例外です。 記録の取り込みが進むまでは、珍しい事故の型では当たりが少なく出ます。そこで AI に一般論で埋めさせないことが、この構成の要です。

6行目の人身事故は、検索を止めはしませんが説明の要点を出しません。 けがをされたお客さまへの説明は、過去の言い回しを借りるべき場面ではないからです。

記録を残す

• 検索ごとの記録：検索の番号、日時、担当者、絞り込みの条件、伏せ字済みの検索文
• 当たった記録の番号と点数、before_revision の有無
• Claude に渡した検索結果のブロックと、返ってきた文と引用
• 担当者が「使った」「使わなかった」を付けた結果と、使わなかった理由（任意）
• 取り込みの記録：整理の前後の文と、確認した担当者
• 伏せ字の規則にかかった件数と、規則の版

4つ目が、重みの調整と事故の型の一覧の見直しの材料になります。 「使わなかった」が多い事故の型は、言葉の句と意味の句の重みが合っていないか、型の分け方が粗いかのどちらかです。

検索ログには、伏せたあとの文だけを残します。 受付メモの元の文は顧客管理システムにあります。検索の仕組みの側に、もう1か所お客さまの情報が溜まる場所を作らないためです。