契約者からの「この場合は支払われるか」の問い合わせに、加入した時期の版の約款・特約・ご契約のしおりから該当条項を根拠付きで示す
契約者から「この手術は対象か」「この入院は支払われるか」と聞かれたとき、その契約が加入した時期の版の約款・特約・ご契約のしおりから、該当する条項を引用付きで示します。オペレーターは条項を読んで回答し、判断の要るものは査定の部門へ回します。
- 生成AI
- Gemini
- AIサービス
- Azure AI/Google Vertex AI/OpenSearch
- 対象業界
- 保険/金融
- 対象部門
- カスタマーサポート
- 対象業務
- 問い合わせ対応/情報検索
- 主な課題
- 問い合わせが多い/情報が見つからない/確認ミスが多い
- AIで行う処理
- 検索(RAG)
- 主な効果
- 品質標準化/対応スピード向上/検索時間短縮
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- RAG・個別開発(大)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 契約者から電話を受け、本人確認をして証券番号を聞く
- 契約管理システムの照会画面で、主契約と特約の商品名、契約日、特約の付加日を見る
- 社内ポータルで商品のフォルダを開き、ファイル名の年月から版の見当をつける
- 版が分からないときは、スーパーバイザーに対応表を確かめてもらう
- 約款のPDFを開き、目次と語の検索で「手術」「入院」などの条項を探す
- 特約が関係しそうなら、特約のPDFも開いて同じように探す
- 条項の要件を読み、契約者に説明する。判断がつかないものはスーパーバイザーに相談する
- 応対記録に、問い合わせの内容と案内した内容を書く
- 人契約者から電話を受け、本人確認をして証券番号を照会画面に入れる
- 自動中継プログラムが契約管理システムから、主契約・特約の商品コード、契約日、特約の付加日を引く
- 自動商品コードと日付から、その契約に適用される版の一覧を作る
- 人オペレーターが問い合わせの要点を検索欄に入れる(氏名・病院名は入れない)
- 自動版の一覧で絞り込んだうえで、約款・特約・しおりから該当する箇所を探し、引用付きの回答を作る
- 自動引用がすべて版の一覧の中の文書かを確かめ、外れていれば回答を出さない
- 自動支払の可否の判断を求める問い合わせかを見て、案内の定型文と査定部門への経路を添える
- 人オペレーターが引用された条項の原文を開き、要件を確かめてから契約者に説明する
- 人答えの出なかったもの、条項の読み方が分からないものをスーパーバイザーに回す
- 【自動/人】 案内した条項と版が応対記録に入り、オペレーターが案内の内容を書き足す
各工程の詳しい説明を読む
- 契約者から電話を受け、本人確認をして証券番号を聞く
- 契約管理システムの照会画面で、主契約と特約の商品名、契約日、特約の付加日を見る
- 社内ポータルで商品のフォルダを開き、ファイル名の年月から版の見当をつける
- 版が分からないときは、スーパーバイザーに対応表を確かめてもらう
- 約款のPDFを開き、目次と語の検索で「手術」「入院」などの条項を探す
- 特約が関係しそうなら、特約のPDFも開いて同じように探す
- 条項の要件を読み、契約者に説明する。判断がつかないものはスーパーバイザーに相談する
- 応対記録に、問い合わせの内容と案内した内容を書く
(a)版を探すところで時間が消える。 3番と4番は、問い合わせの中身と関係のない作業です。ファイル名の年月は販売開始の時期で、契約日ではありません。 改定版の切り替わりの前後に加入した契約では、どちらの版か分からず、スーパーバイザーの手元の表に頼ることになります。
(b)新しい版の条項で答えてしまう。 急いでいると、フォルダの一番上にある最新の版を開きます。手術の対象の範囲や入院の日数の数え方は、版によって違います。 後で査定の結果が案内と違うと分かったとき、苦情の原因は電話の案内になります。
(c)約款の言葉で探しても見つからない。 契約者は「日帰り入院」「カテーテルの手術」と言いますが、約款には「入院日と退院日が同一の日である場合」「手術の定義」として書かれています。語の検索では、契約者の言葉から条項にたどり着けません。
(d)確認がスーパーバイザーに集中する。 版の確認と条項の読み方の相談が1日に何十件も届き、オペレーターは保留のまま待ちます。 配属されて間もない人ほど相談が増えます。
- 【人】 契約者から電話を受け、本人確認をして証券番号を照会画面に入れる
- 【自動】 中継プログラムが契約管理システムから、主契約・特約の商品コード、契約日、特約の付加日を引く
- 【自動】 商品コードと日付から、その契約に適用される版の一覧を作る
- 【人】 オペレーターが問い合わせの要点を検索欄に入れる(氏名・病院名は入れない)
- 【自動】 版の一覧で絞り込んだうえで、約款・特約・しおりから該当する箇所を探し、引用付きの回答を作る
- 【自動】 引用がすべて版の一覧の中の文書かを確かめ、外れていれば回答を出さない
- 【自動】 支払の可否の判断を求める問い合わせかを見て、案内の定型文と査定部門への経路を添える
- 【人】 オペレーターが引用された条項の原文を開き、要件を確かめてから契約者に説明する
- 【人】 答えの出なかったもの、条項の読み方が分からないものをスーパーバイザーに回す
- 【自動/人】 案内した条項と版が応対記録に入り、オペレーターが案内の内容を書き足す
3番が、この設計の分かれ目です。 検索より先に、どの版を探してよいかを契約管理システムのデータで決めます。 生成AIに版を選ばせると、似た条項を持つ別の版を引くことがあります。
8番を省かないでください。 回答の文は条項を見つけるための案内で、契約者に説明するのは条項の原文です。
02今回想定するシステム構成
【取り込み】約款・特約・しおりのPDF(版ごと)+版の台帳 ▼【トリガー】約款の改定の登録 中継プログラム ── 版のメタデータ(商品コード・適用期間)をJSONLにする ▼ Vertex AI Search(Agent Search)── レイアウトパーサーで解析し、見出し付きで分割 ▼ 非構造化データのデータストア(版ごとの文書) 【問い合わせ】オペレーターの照会画面(証券番号+問い合わせの要点) ▼ 中継プログラム ── 契約管理システムから商品コード・契約日・特約の付加日を引く │ 適用される版の一覧を作り、絞り込みの式にする ▼ Vertex AI Search(Agent Search)の answer メソッド │ filter で版を絞り、引用付きの回答と支持スコアを返す ▼ 中継プログラム ── 引用が版の一覧の中か、支払の可否を求める問い合わせかを確かめる ▼ 【人】オペレーターが条項の原文を確かめて説明 → 応対記録へ └──▶ 判断の要るものはスーパーバイザー/支払査定の部門へ
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 検索基盤 | Vertex AI Search(Agent Search。answer メソッドとメタデータの絞り込み) | Azure AI Search、Amazon OpenSearch Service |
| 生成AI | Gemini(answer メソッドの回答の生成に使うモデル) | ─ |
| 連携 | 中継プログラム(Cloud Run 上で動かす。契約の照会、版の決定、引用の検査) | Cloud Functions |
| 保管 | Cloud Storage(約款・特約・しおりの原本と、版のメタデータ) | ─ |
| 基幹 | 既存の契約管理システム(読み取りのみ) | ─ |
契約管理システムと応対記録のシステムは、置き換えません。 最初の準備作業は、版の台帳を作ることです。 スーパーバイザーの手元の対応表を、商品コード・版・適用期間の一覧に直します。
土台になるのは、Vertex AI Search です。 Google Cloud のドキュメントでは、Agent Search へ名称が変わりつつあると注記されています。使うのは、Cloud Storage に置いた文書から作る非構造化データのデータストアで、文書ごとにメタデータを付けて取り込めます。
版の絞り込みは、メタデータのフィルタで行います。 日付の項目は ISO 8601 の形式で >= や < で比べられ、文字の項目は ANY() で一致を見て、AND/OR/NOT で組み合わせられます。絞り込みに使う項目は、スキーマで索引可能(Indexable)にしておく必要があります。
回答の生成は、answer メソッドで行います。 根拠を付ける設定(includeCitations)、関連性の低い内容しかないときに代わりの応答を返す設定(ignoreLowRelevantContent)、回答を求めていない入力を扱わない設定(ignoreNonAnswerSeekingQuery)があり、回答しなかった理由は answerSkippedReasons に入ります。 回答の文がデータにどれだけ支えられているかを示す支持スコア(0〜1)も返せます。
03どうやって実装するのか
処理の起点を決める
トリガーは2つあります。 取り込みの側は約款の改定の登録、問い合わせの側はオペレーターが照会画面で検索を押したことです。
取り込みは、商品部門が新しい版を登録したときに動かします。 約款の改定は年に数回で、日を決めて定期で回すほどの頻度はありません。Vertex AI Search には1日・3日・5日ごとに自動で取り込む定期の取り込みもありますが、ドキュメントでは定期の取り込みは元のデータの権限の制御に対応せず、手動で更新もできないとされています。この構成では、1回ごとの取り込みを、版の登録のたびに中継プログラムから起こします。
古い版は消しません。 販売を終えた商品でも、保有契約がある限り問い合わせが来ます。入れるのは「保有契約のある全部の版」です。
問い合わせの側は、証券番号が照会画面に入っていることを条件にします。 証券番号なしで検索させると、版を絞り込めず全部の版から引くことになり、この構成がいちばん防ぎたい取り違えが、そのまま起きます。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 約款・特約のPDF | 普通保険約款と特約条項。版ごとに1ファイル | 商品部門の原本(Cloud Storage へ複製) |
| ご契約のしおり | 約款を説明した冊子。版ごとに1ファイル | 同上 |
| 版の台帳 | 商品コード、文書の種類、版の番号、適用開始日、適用終了日、ファイルの場所 | スーパーバイザーの対応表を作り直したもの |
| 契約の情報 | 主契約と特約の商品コード、契約日、特約の付加日、特約の解約日 | 契約管理システム(読み取り) |
| 問い合わせの要点 | オペレーターが入れる1〜2文(「日帰り入院の扱い」など) | 照会画面 |
質を決めるのは、版の台帳です。 適用期間が1日でもずれていると、切り替わりの前後に加入した契約で、隣の版を引きます。
特約の付加日を必ず持たせます。 主契約を10年前に結び、3年前に先進医療の特約を付けた契約では、主契約は10年前の版、特約は3年前の版です。契約日だけで絞ると、特約を古い版で引いてしまいます。
問い合わせの要点には、氏名・病院名・証券番号を入れさせません。 検索に要るのは「何についての問い合わせか」だけです。
データの取得方法を決める
取り込みでは、版の台帳から JSONL を作ります。 1文書につき1行で、content.uri に Cloud Storage の場所、structData に版のメタデータを入れます。
{"id": "MED2016-yakkan-v3",
"structData": {"product_code": "MED2016", "doc_type": "yakkan",
"version": "v3", "effective_from": "2018-04-02", "effective_to": "2021-10-01",
"title": "医療保険(2016)普通保険約款 第3版"},
"content": {"mimeType": "application/pdf",
"uri": "gs://policy-wording/MED2016/yakkan_v3.pdf"}}
doc_type は yakkan(普通保険約款)/rider(特約条項)/shiori(ご契約のしおり)の3つです。product_code・doc_type・effective_from・effective_to は、スキーマで索引可能にします。 現在も有効な版の effective_to には、遠い将来の日付(9999-12-31)を入れておき、比較の式を1通りにします。
問い合わせでは、契約管理システムの照会のAPIから契約の情報を引きます。 契約管理システムの側に照会の口があるかは、自社のシステム部門に確かめてください。無い場合は、照会画面の表示内容を中継プログラムへ渡す形にします。
引いた情報から、絞り込みの式を作ります。 主契約と特約ごとの条件を OR でつなぎます。
(product_code: ANY("MED2016") AND effective_from <= "2019-06-01"
AND effective_to > "2019-06-01")
OR (product_code: ANY("RIDER-ADV") AND effective_from <= "2023-02-15"
AND effective_to > "2023-02-15")
主契約の基準日は契約日、特約の基準日は付加日です。基準日を誰が見ても同じに決められる規則として、中継プログラムに書きます。 復活や転換があった契約の基準日は商品ごとに扱いが違うため、最初は自動で決めず、スーパーバイザーへ回す例外にします。
AIへ渡す前に整形する
- 原本の確認 … 商品部門の原本と同じファイルかを、ファイルのハッシュ値で確かめてから複製します
- 版の台帳との突き合わせ … 台帳に無いファイル、ファイルの無い台帳の行を一覧にし、取り込みを止めます
- 適用期間の重なりの検査 … 同じ商品コード・同じ文書の種類で、適用期間が重なる版や、すき間のある版が無いかを見ます
- 解析の設定 … レイアウトパーサーを使い、段落、表、リスト、見出しを検出させます
- 分割の設定 … 分割の大きさは100〜500トークンで指定でき、既定は500です。見出しを分割した各部分に付ける設定(
includeAncestorHeadings)を有効にします - スキャンしかない古い版の扱い … 電子の原本が無い古い版はOCRのパーサーで読みます。PDFの最初の500ページまでしか読まれないため、超えるものは分けます
- 別表の確認 … 手術の種類と給付倍率の別表が表として取れているかを、版ごとに数か所開いて確かめます
5番目は、データストアを作る前に決めます。 ドキュメントでは、文書の分割はデータストアを作った後で有効にも無効にもできないとされています。後から変えたくなれば、データストアを作り直して全部の版を入れ直すことになります。
includeAncestorHeadings が効くのは、約款が条番号で書かれているからです。 「第18条 手術給付金の支払」の途中で切れた断片は、見出しが無いとどの給付金の、どの要件の話かが分かりません。既定は無効なので、明示して有効にします。
3番目の検査を省かないでください。 適用期間の重なりがあると、1つの契約に2つの版が当たり、どちらの版の条項が出るかは検索の順位で決まってしまいます。
AIに処理させる
させるのは、絞り込まれた版の文書から問い合わせに関係する条項を探し、要件を条文のとおりに並べて、引用を付けることだけです。
| させること | 中身 |
|---|---|
| 該当条項の特定 | 問い合わせに関係する約款・特約の条と項、別表の番号 |
| 要件の列挙 | 支払の要件、支払われない場合(免責事由)、定義の条項を、条文の言葉で並べる |
| しおりの説明の併記 | 同じ内容をしおりがどう説明しているか。根拠ではなく説明の言葉として |
| 確認の要る点の指摘 | 要件のうち、診断書や医療機関の情報が無いと決まらない点 |
3行目を「根拠ではなく」と分けているのは、しおりが要約だからです。 しおりは読みやすさのために細部を省くことがあり、しおりの記載だけで答えると、約款の但し書きが抜けた案内になります。 約款の引用が1つも無い回答は、中継プログラムが出さないようにします。
| させないこと | 理由 |
|---|---|
| 支払われる・支払われないの結論 | 個別の請求の判断は、診断書を見る支払査定の部門が行う |
| 版の選択 | 契約管理システムのデータから規則で決める。生成AIの判断に任せない |
| 他の版の条項による補い | 絞り込まれた版に無いことは「記載なし」とする |
| 手術名と約款の定義の当てはめ | 医学的な判断を含む。当てはまるかは査定が決める |
| 給付金の額の計算 | 入院日額や倍率の掛け算はしない。別表の位置を示すだけ |
4行目が、いちばん起きやすい失敗です。 「カテーテルの手術は対象か」と聞かれると、別表に近い名前の項目を見つけて「対象です」と書きます。近い名前があることと、その手術が当たることは別の話です。
指示内容を固定する
answer メソッドの promptSpec.preamble に、次の指示を入れます。
あなたは生命保険会社のコールセンターで、オペレーターを手伝います。
回答を読むのはオペレーターで、引用された条項の原文を開いて確かめてから
契約者に説明します。検索結果は、この契約に適用される版の文書だけです。
【答え方】
1. 最初に、問い合わせに関係する条項の名前と番号を1〜2文で書いてください。
2. 次に、その条項に書かれている支払の要件を、条文の言葉のまま並べてください。
3. 支払われない場合(免責)や、定義の条項が関係すれば、それも書いてください。
4. ご契約のしおりに同じ内容の説明があれば、「しおりの説明」として分けて書いてください。
5. 要件のうち、診断書や医療機関の情報が無いと決まらない点を最後に書いてください。
【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
保険の一般的な知識や、他の商品の約款の内容で補わないでください。
- 「支払われます」「支払われません」「対象です」「対象外です」と書かないでください。
「支払の可否は、ご請求後に査定で判断されます」と書いてください。
- 手術名や病名が、約款の別表のどの項目に当たるかを決めないでください。
関係しそうな別表の番号と、その項目の文言を示すだけにしてください。
- 金額、日数、回数、倍率は、条文や別表に書かれているとおりに書いてください。
計算や言い換えをしないでください。
- 約款の条項が見つからないときは、しおりの説明だけで答えを作らないでください。
- 根拠になる条項が見つからないときは、答えを作らないでください。
- 契約者の氏名、証券番号、医療機関の名前を答えに書かないでください。
「支払われます」と書かないことを、定型の文まで指定しています。 禁じるだけだと「対象となる可能性が高いです」と言い換えて書きます。オペレーターがその文を読み上げれば、契約者には「支払われる」と聞こえます。 書く文を決めておくほうが確実です。
「計算や言い換えをしない」は、別表と日数のためです。 手術の給付倍率や入院の日数の上限は、版によって数字が違います。生成された文が別の行の倍率を書いたり、「60日」を「2か月」と言い換えたりすると、版を正しく絞った意味がなくなります。
出力形式を固定する
answer メソッドの応答を、中継プログラムが次の形に整えて画面と応対記録に渡します。
{
"inquiry_id": "",
"contract_ref": "(証券番号は記録側でのみ保持)",
"versions": [
{ "product_code": "MED2016", "doc_type": "yakkan", "version": "v3", "base_date": "2019-06-01" }
],
"status": "answered | skipped | escalated",
"skipped_reasons": [],
"answer_text": "",
"citations": [
{ "doc_id": "", "doc_type": "yakkan | rider | shiori", "version": "",
"article": "", "snippet": "", "uri": "" }
],
"support_score": 0,
"payment_decision_requested": false,
"route_to": "none | supervisor | claims"
}
1つ目の理由は、versions で「どの版で答えたか」を残せることです。 後で査定の結果と案内が食い違ったとき、版の取り違えだったのか、条項の読み違いだったのかを、この欄で切り分けられます。
2つ目は、citations で中継プログラムが検査できることです。 引用の doc_id が versions の版の一覧に1つでも無ければ、回答を出さずに escalated にします。引用の doc_type に yakkan も rider も無く、shiori だけのときも同じ扱いです。
3つ目は、support_score で根拠の弱い回答を見分けられることです。 境の値は、最初の1か月の記録を見てスーパーバイザーが決めます。
4つ目は、payment_decision_requested で案内の型を変えられることです。 問い合わせが「支払われるか」を聞いていると判定されたものには、査定の流れと請求の書類の案内を定型で添えます。 判定は、問い合わせの要点に「支払われ」「対象になるか」などの語があるかで中継プログラムが行い、生成AIには任せません。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 契約管理システム | 照会のAPI(読み取り) | 商品コード、契約日、特約の付加日を引く |
| Cloud Storage | ファイルの配置と JSONL | 約款・特約・しおりの原本と版のメタデータ |
| Vertex AI Search | データストアの取り込み | 版の登録のたびに1回ごとの取り込み |
| Vertex AI Search | answer メソッド | filter で版を絞り、引用付きの回答を返す |
| 照会画面 | 中継プログラムの画面 | 回答、引用、版、原文へのリンクを表示 |
| 応対記録のシステム | 既存の記録の項目 | 案内した版と条項を書き込む |
応対記録への書き込みは、オペレーターが「この内容で記録」を押したときだけにします。 自動で書き込むと、確かめた案内とそうでない案内の区別がつきません。
検索の結果の件数は、既定の10件のままで始めます。 answer メソッドの検索の段階で返す件数は既定が10、上限が25です。主契約・特約・しおりの3種類から引くので、少なすぎると特約の条項が漏れます。件数を増やすより先に、版の絞り込みが効いているかを確かめます。 検索結果を文書の単位で返すか、分割した部分の単位で返すか(searchResultMode)は、分割した部分の単位にします。条項の単位で引用させるためです。
人が確認する
オペレーターが、引用された条項の原文を開いてから説明します。 画面の回答の文をそのまま読み上げないことを、研修の最初に決めます。
- 版を確かめる … 画面の上に出る「この契約の版」が、照会画面の契約日・特約の付加日と合っているかを見ます
- 条項の原文を開く … 引用のリンクから約款の該当箇所を開き、前後の条文と、定義の条項を読みます
- 査定の判断が要るかを決める … 個別の手術・入院が当たるかを聞かれていれば、定型の案内と請求の書類の説明に切り替えます
- 答えが出なかったものを回す …
skippedとescalatedは、問い合わせの要点ごとスーパーバイザーへ回します - 案内の内容を記録する … 案内した条項と、契約者に伝えた言葉を応対記録に書き足します
スーパーバイザーは、週に一度の抜き取りで、版と条項が正しかったか、支払の可否を言い切っていないかを録音と照らします。
目標は、1,500件をならして1件4分です。 条項の確認に3分、記録に1分を見ています。4分を大きく超える月は、escalated が増えているか、版の台帳の日付に誤りがあります。
例外に対処する
| 起きること | 対応 |
|---|---|
| 証券番号が入っていない | 検索させない。版を絞れない検索は行わない |
| 契約に当たる版が台帳に無い | escalated。台帳の不足として商品部門へ知らせる |
| 1つの契約に2つの版が当たる | 適用期間の重なり。回答を出さず、台帳を直すまでスーパーバイザーが対応 |
| 復活・転換・特約の中途付加の扱いが不明 | 基準日を自動で決めず、スーパーバイザーへ回す |
| 引用が版の一覧の外の文書 | 回答を出さずに escalated |
| 引用がしおりだけ | 約款の条項を確かめるよう表示し、escalated |
| 回答がスキップされた | answerSkippedReasons の内容に応じて「関係する条項が見つかりません」などの文を出す |
| 支持スコアが低い | スーパーバイザーへ回すボタンを目立たせる |
| 問い合わせの要点に氏名や病院名が入った | 送る前に検出して止め、入れ直してもらう |
| Vertex AI Search が応答しない | 照会画面に「通常の手順で確認してください」と出し、社内ポータルの約款へのリンクを示す |
上から4行目までは、AIではなく版の台帳と契約の情報の問題です。 最初の数か月は件数を毎週数えます。
記録を残す
- 問い合わせの要点、問い合わせの日時、受けたオペレーター
- そのときの版の一覧(商品コード、版、基準日)と、作った絞り込みの式
- answer メソッドの応答の全文(回答の文、引用、支持スコア、スキップの理由)
- 中継プログラムの検査の結果(版の外の引用、しおりだけの引用、支払の可否を求める問い合わせかの判定)
- オペレーターが記録した案内の内容と、回答から変えた点
- スーパーバイザーへ回したものと、その結論
- 版の台帳の変更の履歴(誰が、いつ、どの日付を直したか)
2つ目で絞り込みの式まで残すのは、台帳が後から直るためです。 式があれば、台帳の誤りで影響を受けた案内を洗い出せます。
5つ目は、査定の結果と突き合わせるために使います。 案内した条項と査定で使われた条項が違っていた問い合わせを月に一度拾い、版の取り違えか、条項の読み違えかを分けて、台帳と研修に返します。
04実装レベルの3段階
最小構成は、版を正しく絞れば条項が引けるのかを確かめるための段階です。 半自動化で、1件10分が6分程度になります。 版を選ぶのはまだオペレーターです。本格構成で4分になり、この段階が本記事の想定です。 第4章の①の版の特定が、ここで初めて無くなります。 段階を飛ばさないでください。 半自動化で1か月使うと、オペレーターが選んだ版と台帳の版が食い違う契約が見つかります。自動に任せる前に直しておくべきものです。
05工数削減シミュレーション
導入後 1,500件 × 4分 ÷ 60 = 100 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 医療保険・がん保険・傷害保険など、約款と特約の改定を何度も重ね、販売時期の違う版の契約を多数保有している生命保険会社・損害保険会社・共済のコールセンター。契約者から「この手術は対象か」「この入院は支払われるか」の問い合わせが毎月数百件以上あり、オペレーターが約款のPDFを開いて条項を探すのに時間がかかっている場合。約款・特約・しおりの電子データに、商品コードと適用開始日を付けて管理できる場合。
- 販売している商品が少なく、約款の版が1〜2つしかない場合。約款の版と契約をひも付ける情報(商品コード・契約日・特約の付加日)が契約管理システムから取り出せない場合。問い合わせの大半が住所変更や払込方法の変更など手続きの案内で、約款の条項を引く必要がない場合。なお、個別の請求が支払の対象になるかの判断は支払査定の部門が行うもので、この構成では代替できません。
07最小構成で試す方法
- 問い合わせの多い医療保険の商品を1つ選び、保有契約のある版の約款・特約・しおりを全部集める
- 先月の応対記録から、その商品の支払対象の問い合わせを30件選ぶ(うち数件は、版の違いで答えが変わるものを入れる)
- 30件それぞれについて、契約日と特約の付加日から、当時スーパーバイザーが確かめた版を書き出す
- 手元のAIサービスに、その版のPDFだけを渡し、「この約款から、問い合わせに関係する条項と要件を、条番号付きで条文の言葉のまま並べてください。支払われるかどうかは書かないでください」と指示する
- 出てきた条項を、当時オペレーターが案内した条項と突き合わせる
4番目で「その版のPDFだけを渡す」のが大事です。 全部の版を渡して選ばせると、規則に任せる部分をAIにさせることになります。
| 出てきた内容 | 判断 |
|---|---|
| 当時案内した条項と同じものが、条番号付きで出た | データストアと版の絞り込みの構築に進む |
| 条項は合っているが「対象です」と書いた | 指示の書き方で直る。構成は有効 |
| 別表の表が崩れて条項を読み違えた | 解析の設定と原本の形式が先。 電子の原本があるかを確かめる |
3行目の結果は、古い版がスキャンしたPDFしか残っていないときに出ます。 商品部門に電子の原本が無いかを先に確かめてください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 新しい版の条項で答える | 版の絞り込みを検索の外で、規則で決める。 証券番号なしでは検索させない |
| 特約が主契約の版で引かれる | 特約ごとに付加日を基準日にし、主契約と別に絞り込む |
| 絞り込みが効かない | 絞り込みに使う項目をスキーマで索引可能にする。取り込みの前に設定する |
| 適用期間が重なる版がある | 取り込みの前に重なりとすき間を検査し、止める |
| 条項の断片が何の話か分からない | includeAncestorHeadings を有効にする。 分割はデータストアの作成後に変えられない |
| 古い版の別表が崩れる | 電子の原本を探す。無ければOCRのパーサーで読み、表を数か所目で確かめる |
| 「対象です」と書いてしまう | 書く文を定型で指定する。禁じるだけでは言い換える |
| しおりだけを根拠にする | 約款・特約の引用が無い回答を中継プログラムが止める |
| 回答の文を読み上げる | 条項の原文を開くことを研修で決め、抜き取りで確かめる |
| 定期の取り込みに切り替える | 権限の制御に対応せず、手動で更新もできない。 版の登録のたびに取り込む |
上の2行が、この構成の失敗のほとんどです。 どちらも、検索の質ではなく、何を検索の対象にするかの問題です。
「回答の文を読み上げる」は、運用を始めて数か月たってから起きます。 抜き取りの確認を続けてください。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 約款・特約・しおり(公開されている文書)、契約の商品コードと日付、そして問い合わせの要点に含まれる手術名・病名・症状です。病歴は要配慮個人情報に当たる情報で、取り扱いには特に注意が要ります。
- 検索に送るのは、問い合わせの要点と版の絞り込みだけにする … 証券番号、氏名、生年月日は中継プログラムの中で止め、Vertex AI Search へは送りません。 版を決めるのに要るのは商品コードと日付だけです
- 問い合わせの要点から個人を特定する情報を外す … 病院名や医師の名前、日付と組み合わせた具体的な経過は入れさせません。入力欄の注意と、送る前の検出の両方で止めます
- 支払の可否を案内しない … 回答は条項の案内までです。電話口で可否を言い切ると、査定の結果と食い違ったときに契約者の不利益と苦情になります
- 応対記録への書き込みは、オペレーターの確認の後にする … 回答が出た時点で書き込むと、確かめていない案内が記録に残ります
- ログの保存期間と閲覧の範囲を決める … 問い合わせの要点には病名が残ります。応対記録と同じ規程で決めます
- 約款の原本を正とする … データストアの文書は写しです。改定のたびに原本と照らします
誤りが起きた場合のリスクは、違う版の条項で案内することと、支払の可否を言い切ることの2つです。 前者は版の台帳と絞り込みの規則で、後者は指示の定型の文と研修で防ぎます。
10まず何から始めるか
1週目:版の台帳を1商品分つくる
問い合わせのいちばん多い医療保険の商品について、保有契約のある版を全部洗い出し、商品コード・版・適用期間の台帳にします。特約も別の行にします。
2週目:30件で試す
先月の応対記録から、その商品の問い合わせを30件選び、当時の版のPDFだけを手元のAIサービスに渡して条項を探させます。当時の案内と条項が合っているか、「対象です」と書いていないかを最優先で見ます。
3週目:案内の線を決める
どこまでを電話で案内し、どこからを査定の判断として請求の手続きに回すかを、支払査定の部門と決めます。 あわせて、payment_decision_requested のときに添える定型の文を決めます。
4週目:データストアを作る
1商品分の版を Vertex AI Search に取り込みます。分割の設定と includeAncestorHeadings、索引可能にする項目を、作る前に決めます。 オペレーターが版を選んで検索する半自動化の形で、スーパーバイザー数名に使ってもらいます。
2か月目: 契約管理システムの照会とつなぎ、版を自動で決める本格構成にして、給付金窓口の一部のオペレーターで使います。escalated と版の台帳の不足を毎週数えます。3か月目以降: 商品を広げ、1件10分が何分になったかを実測します。査定の結果と案内した条項の食い違いを月に一度拾い、版の台帳と研修に返す流れが回った時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
Vertex AI Search が Agent Search へ改称中であること。answer メソッドの includeCitations、ignoreLowRelevantContent、ignoreNonAnswerSeekingQuery、answerSkippedReasons、promptSpec.preamble、filter、支持スコア(0〜1)。検索の段階で返す件数が既定10・上限25であること。searchResultMode で文書と分割した部分を選べること | Google Cloud: Get answers and follow-ups(answer method) | 2026-10-06 |
絞り込みの ANY()、数値と日付の比較の演算子、日付を ISO 8601 の形式で比べられること、AND/OR/NOT で組み合わせられること。絞り込みに使う項目を索引可能にする必要があること | Google Cloud: Filter search by metadata | 2026-10-06 |
レイアウトパーサーが段落・表・リスト・見出しを検出すること。分割の大きさが100〜500トークン(既定500)、includeAncestorHeadings の既定が無効であること。分割がデータストアの作成後に切り替えられないこと。OCRのパーサーがPDFの最初の500ページまでを読むこと。レイアウトとOCRのパーサーに Document AI の機能の料金がかかり、デジタルのパーサーが無料であること | Google Cloud: Parse and chunk documents | 2026-10-06 |
Cloud Storage から取り込むときのメタデータの JSONL(id、structData/jsonData、content.mimeType、content.uri)。1回ごとの取り込みが手動の更新を要すること。定期の取り込みが1日・3日・5日ごとで、権限の制御に対応せず、手動で更新できないこと | Google Cloud: Create a search data store | 2026-10-06 |
個別の請求が支払の対象になるかは、支払査定の部門が診断書などをもとに判断してください。 本記事は Google Cloud の公開ドキュメントで確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0606)についてのご相談はこちらから。
