銀行・信用金庫の営業店から届く事務手続きの照会に、事務規程・事務手引と本部の通達を根拠にチャットで答え、規程に無い事案は事務指導の担当へ回す

処理の起点を決める

起点は、営業店の行員がチャットで照会を送ったことです。 チャットは行内ポータルに置き、行内の ID でログインした行員だけが使えるようにします。ログインした行員の所属と役職が、閲覧の権限の判定にそのまま使われます。

1つの照会は、1つのセッションで最後まで続けます。 確認項目を聞き返すやり取りと、答えたあとの「では代理人が来た場合は」のような続けての質問を、同じセッションでつなぎます。別の手続きの照会は、新しいセッションで始めてもらいます。 同じセッションで手続きを変えると、前の手続きの条件が言い換えに混ざります。

処理は照会のたびに1件ずつ行います。 窓口で顧客が待っている照会なので、まとめて処理する理由がありません。

入力データを集める

質を決めるのは、確認項目の表と、通達の「変更した手引の章」です。 確認項目の表が無いと、聞き返しをAIの判断に任せることになります。通達がどの章を変えたかが分からないと、手引の古い記載と通達の新しい記載が、同じ重みで回答に並びます。

確認項目の表は、手引の分岐をそのまま表にしたものです。 相続の払戻しなら「遺言書の有無（公正証書／自筆／無し）」「遺産分割協議書の有無」「払戻しを受ける人（相続人全員／代表者／遺言執行者）」「口座の種類（普通／定期／融資の返済口座）」のように、手引で取り扱いが分かれる条件だけを並べます。

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

規程・手引・通達は、Cloud Storage に置いてデータストアに取り込みます。 文書ごとのメタデータは JSONL の各行に id、structData、content.mimeType、content.uri を書き、そこに acl_info を足します。

絞り込みの式は、日付の比較を使って書きます。 項目を索引可能にしておけば、procedure: ANY("inheritance") AND effective_from <= "2026-10-06" AND status: ANY("current") のように書けます。日付はISO 8601の形式で、施行前の通達を検索の時点で除きます。 廃止の通達は status を retired にして除きます。

取り込みは、通達を発出した日に1回ずつ行います。 Cloud Storage からの定期的な取り込み（1日、3日、5日ごと）もありますが、定期的な取り込みではデータソースのアクセス制御が使えないとされています。役席者だけの通達を扱う以上、定期の同期は使わず、発出のたびに取り込みを実行します。

AIへ渡す前に整形する

1. 通達に施行日と廃止日を付ける … 管理表から転記し、施行日の無い通達は発出日を施行日とします
2. 通達に変更した手引の章を付ける … 本文の「第○章○節を次のとおり改める」から、事務指導グループが章の番号を書きます
3. 手引を手続きの単位で分ける … 1つのPDFに複数の手続きが入っているものは、手続きごとに分けます
4. 閲覧の範囲を付ける … 役席者だけの通達には、役席者のグループの group_id を acl_info に書きます
5. 顧客の情報を除く … 通達に添付された事例に顧客の氏名や口座番号があれば伏せます
6. 確認項目の表を作る … 照会の多い上位20の手続きから、手引の分岐を表にします
7. 文書の分割を設定する … データストアを作るときに分割を有効にし、見出しを各断片に含めます

4番目は、データストアを作る前に決めます。 アクセス制御はデータストアの作成時にしか有効にできません。後から「この通達は役席者だけ」と言い出しても、作り直しになります。 最初の取り込みの前に、通達の管理表に閲覧の範囲の列を足してください。

2番目を省かないでください。 章の番号が付いていれば、中継プログラムは「手引の第5章の回答には、第5章を変えた現行の通達を必ず先に示す」という規則を持てます。検索の順位に任せると、手引の記載のほうが長く詳しいため、先に出てきます。

AIに処理させる

させるのは、聞き取った条件に当たる手引と通達の記載を見つけ、取り扱い・必要書類・承認の要否を、出典を付けて短く返すことです。 何を聞き返すかは、確認項目の表で中継プログラムが決めます。

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

閲覧の権限は、ログインした行員の ID で検索が行われることで効きます。 中継プログラムは、行員の代わりに広い権限で検索してはいけません。広い権限のサービスアカウントで検索すると、役席者だけの通達が全行員への回答に入ります。

3行目が最も起きやすい失敗です。 回答を作るモデルは、一般的な相続の手続きを知っています。それで補うと、自行の手引に無い「この書類はあの書類で代えられる」が、自行の取り扱いのように届きます。 どの書類を受け付けるかは、自行の手引にしか書いてありません。

指示内容を固定する

answer メソッドの preamble に、次の指示を入れます。

あなたは信用金庫の本部で、営業店の行員からの事務手続きの照会に答える担当です。
読むのは窓口で顧客を待たせている行員で、あなたの回答を見て手引と通達を開きます。

【前提】
検索の文の最初に、行員から聞き取った条件が並んでいます。
その条件に当たる記載だけを使って答えてください。

【答え方】
1. 最初に、根拠にした事務手引の章と節、通達があれば通達の番号と施行日を書いてください。
2. 手引の記載を変える通達があるときは、通達の記載を先に書き、
   「手引の第○章は通達第○号で変わっています」と明記してください。
3. 取り扱いの流れを、手引の順序のまま3〜6行で書いてください。
4. 必要書類を箇条書きで書いてください。手引の書類の名前をそのまま使ってください。
5. 役席者の検印や本部への事前の協議が要るときは、最後に必ず書いてください。

【厳守事項】
- 検索結果の文書に書かれていることだけで答えてください。
  一般的な銀行実務の知識で、取り扱いや必要書類を補わないでください。
- 聞き取った条件と違う条件の取り扱いを書かないでください。
- 必要書類を省略してよいとは書かないでください。
- 顧客に伝える文面を作らないでください。
- 取引の制限の理由を顧客にどう伝えるかを聞かれたときは、
  「この照会は事務指導の担当へ回します」とだけ書いてください。
- 該当する記載が見つからないときは、
  「事務手引と現行の通達に該当する記載が見つかりません。事務指導の担当へ回します」
  とだけ書いてください。
- 顧客の氏名、口座番号を書かないでください。

「聞き取った条件と違う条件の取り扱いを書かない」が、この指示の要です。 手引の相続の章には、遺言書がある場合と無い場合が並んで書かれています。何も言わなければ、両方を丁寧に並べ、行員はその中から自分の事案を探すことになります。 条件を聞き取った意味が無くなります。

検索の文は、中継プログラムが確認項目の値から組み立てます。 例えば「手続き：相続の払戻し、遺言書：公正証書、遺産分割協議書：無し、払戻しを受ける人：遺言執行者、口座：普通預金。取り扱いと必要書類を教えてください」のように、確認項目を表の順に並べ、行員の質問の文を最後に足します。

出力形式を固定する

answer メソッドの応答を、中継プログラムが次の形に整えて、チャットと記録に渡します。

{
  "inquiry_id": "",
  "session_id": "",
  "branch": "",
  "role": "staff | officer",
  "procedure": "inheritance | name_change | restriction | other",
  "conditions": { "will": "", "partition_agreement": "", "payee": "", "account_type": "" },
  "status": "answered | escalated | skipped",
  "escalate_reason": "not_in_rules | skipped | restriction_disclosure | user_request | none",
  "answer_text": "",
  "manual_refs": [ { "chapter": "", "section": "", "uri": "" } ],
  "circular_refs": [ { "no": "", "effective_from": "", "changes_chapter": "", "uri": "" } ],
  "approval_required": "",
  "feedback": "resolved | escalated_after | wrong | none"
}

1つ目の理由は、conditions を回答と一緒に残せることです。 事務指導の担当へ回すとき、聞き取り済みの条件がそのまま渡るので、担当は条件を聞き直さずに答えられます。 誤った回答が出たときも、どの条件で検索したかが分かります。

2つ目は、circular_refs の changes_chapter で検査ができることです。 中継プログラムは、manual_refs の章を変える現行の通達がデータストアにあるのに circular_refs に入っていない回答を見つけたら、回答を出さずに事務指導の担当へ回します。 手引の古い記載だけで答えた回答を、営業店に届けないためです。

3つ目は、feedback で回答の質を測れることです。 行員がチャットの最後に「解決した／担当へ回した／誤り」を選び、誤りの多い手続きから確認項目の表と通達の章の付け方を直します。

システムへ連携する

勘定系のシステムには、つなぎません。 口座の状態や顧客の情報をこの構成で引くと、照会の文と顧客の情報が同じ記録に残ります。 事案の事実は行員が端末で確かめ、条件として選択肢で入れます。

人が確認する

行員は、回答を読んだあと必ず出典の手引と通達を開いてから、顧客に案内します。 回答は「どの章と通達を見ればよいか」を示すもので、書類の書式や記入の例は原文にしかありません。

1. 通達の番号と施行日を確かめる … 施行日が今日以前か、手引を変える通達が先に示されているかを見ます
2. 条件が事案と合っているかを確かめる … 聞き返しで選んだ値が、顧客の事案と違っていないかを見ます
3. 承認の要否を確かめる … 検印や事前の協議が要るなら、役席者に回します
4. 評価を付ける … 解決した／担当へ回した／誤りを選びます

2番目を軽く見ないでください。 窓口で急いでいる行員は、選択肢を読み違えて「自筆」と「公正証書」を取り違えることがあります。条件を1つ違えた回答は、出典まで含めて正しく見えるので、回答の側からは誤りに気付けません。 回答の上に、選んだ条件を必ず並べて表示します。

事務指導の担当は、回ってきた照会だけを見ます。 規程に無い事案は、これまでどおり法務やコンプライアンスの担当と相談します。答えたら、その取り扱いを手引か通達に足すかを月次で見直します。

目標は、900件をならして1件4分です。 回答で解決した照会の記録の確認と、回ってきた照会を担当が答える時間の平均です。

例外に対処する

5行目は、運用の約束として営業店に伝えておきます。 権限の無い行員の検索には役席者だけの通達が出ないため、「規程に無い」と回されたものの中に、役席者なら答えが見える照会が混ざります。 担当は回ってきた照会を見て、役席者に相談するよう案内します。

記録を残す

• 照会の文、選んだ確認項目の値、日時、所属の店と役職
• 中継プログラムが組み立てた検索の文と、使った絞り込みの式
• answer メソッドの応答の全文（回答、出典、回答しなかった理由）
• 回す・回さないの判定と、その理由
• 行員の評価と、事務指導の担当が最終的に答えた内容
• そのとき現行だった通達の番号と施行日の一覧

最後の行は、後から照会の回答を確かめるときに効きます。 通達が改廃されたあとで「なぜその回答だったか」を確かめるには、当時どの通達が現行だったかが要ります。 手引の改訂のたびに、この一覧を残します。