信用金庫の窓口の職員が、事務取扱要領と過去の本部への照会の記録を Vertex AI Search で検索し、手続の扱いと必要書類を、照会の回答がいまの要領の版に合うかを確かめたうえで根拠付きでそろえる

処理の起点を決める

窓口の職員が、窓口の画面で手続の種類を選び、事情を入れて送信したことを起点にします。 手続の種類は「払戻し（代理人）」「相続の届出」「成年後見の届出」「氏名・住所の変更」「口座の開設（外国籍）」のような一覧から選びます。自由に書いた文だけで検索すると、お客様の言葉に引っぱられて、別の編の条が当たるからです。

事情を足して問い直すときは、同じ会話として続けます。 公式ページでは、前の問い合わせのセッションの ID を渡すと続きとして問えるとされています。「遺言書がある」「代理人は同居の家族」と足すと、条件に合う条に絞った答えが出るようにします。

入力データを集める

質を決めるのは、照会の記録の「根拠にした条と版」と「個別の判断かどうか」の2つです。 今後の回答は、事務部が回答を登録するときに必ず入れます。8年分の過去の記録は、新しいものから順に、事務部の経験者が付け直します。 付け直していない記録は「根拠不明」として扱い、答えの根拠にも、一覧の上の方にも出しません。

照会の記録からは、お客様の名前、口座番号、店の担当者の名前を外して入れます。 検索に要るのは手続の種類と事情と回答で、どのお客様の件だったかは要りません。

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

要領は、条ごとに1つの文書に分け、メタデータに編・条・版・施行日・廃止日を持たせます。 公式ページでは、非構造のデータのメタデータは JSON Lines（NDJSON）のファイルで、各行に id、structData（または jsonData）、Cloud Storage の文書を指す content の mimeType と uri を持たせるとされています。1つの条は、たとえば次の1行にします。

{"id": "yoryo-12-034-v7",
 "structData": {"doc_kind": "rule", "procedure": "inherit",
                "volume": "12 相続", "clause": "12-34", "rule_ver": "v7",
                "effective_from": "2026-04-01", "effective_to": "9999-12-31",
                "audience": "teller"},
 "content": {"mimeType": "application/pdf", "uri": "gs://<bucket>/rule/12/12-34_v7.pdf"}}

照会の記録は doc_kind を inquiry にし、根拠の条（basis_clause）と版（basis_ver）、回答の状態（answer_state）を持たせます。 answer_state は current（根拠の条が現行のまま）、superseded（回答の後に根拠の条が改定された）、exception（個別の判断）、unknown（根拠不明）の4つです。公式ページでは、取り込めるファイルの上限は200MBで、一度に100,000ファイルまで取り込めるとされています。

要領の PDF は、データストアを作るときに文書の分割とレイアウトの解析を有効にします。 公式ページでは、レイアウトの解析は PDF の段落・表・見出しを検出するとされています。必要書類は表で書かれていることが多いので、表の説明を付ける設定も有効にします。 分割はデータストアを作ったあとに切り替えられず、見出しを各チャンクに付ける includeAncestorHeadings は既定で無効です。条の見出しが本文から離れないよう、作るときに有効にします。

AIへ渡す前に整形する

1. 数字の並びを伏せる … 事情の文から、7桁以上の数字の並び（口座番号・電話番号）を ＊ に置き換えます
2. 名前の入力を止める … 画面に「名前は入れない」と出し、敬称の付いた語があれば送信の前に職員に確かめます
3. 編の特定 … 手続の種類から、検索する編の候補を決めます（「払戻し（代理人）」なら払戻し・取引時確認・代理人の届出の編）
4. 現行の版の条件 … 今日の日付で、施行日が今日以前で廃止日が今日より後の条に絞る条件を組み立てます
5. 照会の記録の条件 … 同じ手続の種類で、answer_state が unknown 以外の記録に絞ります

4番目の廃止日は、空にせず 9999-12-31 を入れておきます。 公式ページでは、日付の項目は ISO 8601 の文字列で、<= や >= で比べられるとされています。空の項目は比べられないので、「まだ廃止されていない」を遠い日付で表します。

絞り込みの条件は、たとえば次のようになります（公式ページの書き方による）。

filter（案内する扱い）:
  doc_kind: ANY("rule")
  AND procedure: ANY("proxy_withdraw", "kyc", "proxy_notice")
  AND effective_from <= "2026-10-28" AND effective_to > "2026-10-28"
filter（過去の照会の一覧）:
  doc_kind: ANY("inquiry")
  AND procedure: ANY("proxy_withdraw")
  AND answer_state: ANY("current", "superseded", "exception")

公式ページでは、ANY は指定した値のどれかに完全に一致するときに真になり、AND・OR でつなげるとされています。絞り込みに使う項目は、スキーマの画面でインデックス可能にしておく必要があります。

一覧の側は、新しい回答を上に出します。 公式ページでは、日付の項目に FRESHNESS の型の上げ下げを掛けられ、7D や 30D のような期間の区切りで重みを変えられるとされています。回答した日（answered_at）に掛け、8年前の回答が先月の回答より上に来ないようにします。 そのうえで、中継プログラムが answer_state の順（current → exception → superseded）に並べ直します。

AIに処理させる

answer メソッドにさせるのは、現行の要領の条から、その手続の扱いと必要書類を、要領の言葉と順番のまま引用付きで短くまとめることです。 お客様の事情に当てはめた結論は出させません。

1行目がいちばん大事です。 「この場合は受け付けられますか」は、窓口でいちばん多く調べられることです。答えが「受け付けられます」と書くと、職員がそのままお客様に伝えてしまいます。 答えは要領の記載を引用するところまでにし、受け付けるかは職員と役席者が決めます。

指示内容を固定する

answer メソッドでは、回答の口調や詳しさをプロンプトの前置き（preamble）で指定できます。公式ページでは、前置きは回答の質に大きく影響しうるとされています。前置きを次のようにします。

あなたは信用金庫の営業店の窓口の職員のための、事務取扱要領の資料係です。
検索で見つかった事務取扱要領の条だけを根拠に、次の順で短く答えてください。

1. 扱い（受け付けてよい手続の範囲と、受付の順序）
2. 必要書類（書類の名前、原本か写しか、有効期限の定め）
3. 役席者の確認が要る旨の記載
4. 本部への照会を求める記載

守ること：
- 要領の言葉と順番のまま書いてください。言い換えないでください。
- お客様の事情に当てはめて、受け付けられる・受け付けられないと書かないでください。
- 要領に無い書類を足さないでください。「念のため」の書類も書かないでください。
- 書類の有効期限は、原文の書き方のまま写してください。日付を計算しないでください。
- 取引時確認が済んだかどうかは書かないでください。
- 見つからない項目は「記載なし」と書いてください。
- 条の番号と版を、各項目の末尾に括弧で書いてください。
- 検索結果に無いことを書かないでください。

「条の番号と版を末尾に書く」を入れるのは、職員が案内の前に原文を開くからです。 番号が見えれば、机の上の印刷の差し替えの漏れにも気づけます。

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

公式ページでは、支持が基準に届かない答えは返されず、理由として LOW_GROUNDED_CONTENT が返るとされています。引用の位置は UTF-8 のバイト単位なので、日本語の答えに条の番号を差し込むときは文字の位置に直します。

出力形式を固定する

中継プログラムが、2つの呼び出しの応答を次の形にそろえて窓口の画面に渡します。

{
  "lookup_id": "",
  "branch_code": "",
  "procedure": "",
  "situation_text": "",
  "answer_for_counter": "",
  "skipped_reason": "",
  "citations": [
    { "sentence": "", "doc_id": "", "clause": "", "rule_ver": "", "quote": "" }
  ],
  "needs_officer": false,
  "past_inquiries": [
    { "inquiry_id": "", "answered_at": "", "question": "", "answer": "",
      "basis_clause": "", "basis_ver": "",
      "answer_state": "current | superseded | exception" }
  ],
  "inquiry_draft": "",
  "session_id": ""
}

1つ目の理由は、answer_for_counter と past_inquiries を分けて持てることです。 お客様に案内する扱いと、過去の照会の回答が、画面の別の枠に出ます。 職員が過去の回答をいまの扱いとして読み上げる取り違えを、画面の作りで防ぎます。

2つ目は、answer_state で回答の印を出せることです。 superseded は灰色にして「回答の後に第12-34条が v6 から v7 に改定」と出し、exception は「個別の判断。前例にしない」と出します。消さずに見せるのは、本部への照会に前の回答を添えるためです。

3つ目は、needs_officer を答えと別に持てることです。 引用した条に「役席者の承認」の記載があるか、手続が相続・後見・取引時確認なら真にし、画面の上に「役席者に回す」を出します。

inquiry_draft は、答えが作られなかったときや、印の付いた回答しか無いときに埋めます。 手続の種類、事情、調べた条の番号、見つかった過去の回答の番号を並べた照会票の下書きです。事務部は、店がどこまで調べたかを読んで答えられます。

システムへ連携する

照会票は、いまどおり事務部の受付に送ります。 画面の下書きを職員が直して送る形にし、送るかどうかは職員が決めます。 事務部は回答を照会の記録に登録するときに、根拠の条と版、個別の判断かどうかを入れます。この入力が、次の店の検索の質になります。

夜間の処理は、事務連絡の改定の一覧を読み、照会の記録の basis_clause と突き合わせます。 根拠の条の現行の版が basis_ver より新しく、改定の施行日が回答した日より後なら、answer_state を superseded に書き換え、メタデータを差し替えて取り込み直します。

人が確認する

1. 条の番号と版を見る … 画面に出た条の番号と版が、手続の種類に合っているかを見ます
2. 役席者の印を見る … 印があれば、案内する前に役席者に回します
3. 引用の原文を見て案内する … 必要書類は、要領の言葉のまま案内します
4. 過去の回答の印を見る … superseded と exception の回答を、いまの扱いとして伝えません
5. 見つからなければ照会する … 下書きを直して本部に照会し、お客様に折り返しの時期を伝えます

2番目を省かないでください。 相続・後見・代理人の払戻しは、誰に払い戻すかを誤ると取り戻せない手続です。 引用が正しくても、受け付けるかは役席者が事情を聞いて決めます。

目標は、1,200件をならして1件4分です。 条の番号を見て、原文を開いて、案内のメモを作る時間です。お客様を待たせる時間が、要領を探す時間から、原文を確かめる時間に変わります。

例外に対処する

6行目は、事務連絡が施行日より前に配られるために起きます。 施行を待つ版がある条は画面に「〇月〇日から改定」と出し、来月に手続を進めるお客様に伝えるかを職員が決めます。

7行目の「画面に理由を書かない」は、窓口の画面がお客様から見えることがあるからです。 疑わしい取引の届出に関わることは、窓口の画面にも検索の記録にも書かず、いまどおり役席者に口頭で知らせる流れに任せます。

記録を残す

• 申し出（手続の種類、事情の文、店の番号、職員、日時）
• 絞り込みの条件、answer メソッドと search メソッドの応答の全文、引用した条と版
• 案内したことと、役席者に回したかどうか
• 送った照会票と、本部の回答の照会の記録の番号
• 夜間の処理で superseded に書き換えた照会の記録と、その理由になった改定

最後の行が、いまは残っていない記録です。 どの改定でどの回答が古くなったかを、事務部が追えます。