銀行の相続の窓口で、亡くなった方の取引の状況と相続人の申出から、必要書類と手続きの流れを相続人ごとに案内する文書の下書きを作る

処理の起点を決める

相続の受付の台帳に、店舗が相続人の一覧と申出の内容を登録したときに動かします。 店舗は死亡の連絡を受けた日に口座を止めますが、その時点では相続人の連絡先も遺言の有無も分からないことが多くあります。相続人の一覧が入った時点を起点にするのは、案内文書のあて先が決まらないと作れないからです。

申出の内容が更新されたときにも動かします。 「遺言は未確認」だった相続人から「公正証書遺言があった」と連絡があれば、店舗か担当者が台帳を更新し、案内文書を作り直します。 作り直した版は前の版と並べて担当者に見せ、どの書類が増え、どれが不要になったかを差分で示します。

1件ずつ動かし、まとめて夜間に処理することはしません。 相続人は葬儀の後の慌ただしい時期に手続きを始めることが多く、案内が1日遅れると、その分だけ書類集めの開始が遅れます。

入力データを集める

質を決めるのは、下の2つの表です。 生成AIは、規則の表に書かれた書類の名前と説明文を使って文章にします。表の説明文が分かりにくければ、案内も分かりにくくなります。 表を作るときに、書類ごとに「どこで取るか」「何通要るか」「いつまでのものか」を1行の説明として持たせます。

規則の表は、たとえば次のような行の集まりです。

行は「誰が出すか」の単位で持ちます。 同じ印鑑証明書でも、相続人全員が出すのか、受け取る方だけが出すのかは場合によって違います。役割の列があるから、相続人ごとの書き分けが規則の側で決まります。

規則の表の土台は、全国銀行協会が示す4つの場合です。 遺言書がある場合は遺言書、検認調書または検認済証明書（公正証書遺言以外の場合）、亡くなった方の戸籍謄本、預金を相続する方の印鑑証明書など。遺産分割協議書がある場合は、法定相続人全員の署名・捺印がある協議書、亡くなった方の出生から死亡までの連続した戸籍、相続人全員の戸籍と印鑑証明書。協議書が無い場合と、調停調書・審判書がある場合も、それぞれ書類が示されています。ただし同協会は、相続の方法や内容、金融機関により必要な書類が異なる場合があるとしています。 表は自行の取り決めで作り、この4つの場合は分類の枠として使います。

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

勘定系への照会は、既存の照会の仕組みを使います。 勘定系に新しい接続口を作るのは大きな工事になるため、担当者がふだん画面で見ている情報を、同じ経路で読み出す形にします。どの経路が使えるかは行内のシステムによって違い、この部分は個別の実装が必要です。

照会できないシステムがあることを前提にします。 貸金庫の台帳が紙のままなど、自動で取れない取引は「確認欄」として下書きに残し、担当者が確かめるまで案内文書を完成させません。 取れなかったものを「無い」として扱うと、第3章の（a）がそのまま起きます。

AIへ渡す前に整形する

1. 取引の種類の振り分け … 取引の一覧を、規則の表の取引の種類（普通・定期預金、口座振替、投資信託、融資、貸金庫）に振り分けます
2. 場合の判定 … 申出の内容から、4つの場合のどれかを決めます。遺言書が「未確認」なら、遺言書がある場合と無い場合の両方を候補に残します
3. 相続人の役割の付与 … 預金を受け取る予定の方、遺言執行者、それ以外の相続人、に分けます。受け取る方が決まっていなければ「未定」とします
4. 必要書類の決定 … 規則の表を引き、場合 × 取引 × 役割ごとに書類を決めます。ここで決まった書類のコードの一覧が、後の照合の正解になります
5. 符号化 … 相続人の氏名と住所を符号に置き換えます。生成AIには、続柄と役割と書類のコードだけを渡します
6. 払戻しを急ぐ事情の印 … 葬儀費用や当面の生活費のために遺産分割の前の払戻しを希望しているかを、印として渡します

6番目は、民法の規定に関わります。 民法第909条の2は、各共同相続人が、遺産に属する預貯金債権のうち相続開始の時の債権額の3分の1に、その相続人の法定相続分を乗じた額（金融機関ごとに法務省令で定める額が限度）について、単独で権利を行使できると定めています。額を計算するのは生成AIではなく、担当者です。 生成AIには、この制度があることと相談の窓口を案内させるだけにします。

AIに処理させる

させるのは、規則が決めた書類と流れを、相続人ごとの文章にすることだけです。

いちばん起きやすいのは1行目です。 生成AIは丁寧に書こうとして、「住民票もあるとお手続きがスムーズです」のような書類を足します。足された1通のために、相続人は役所にもう一度行くことになります。 書類は規則の表にあるものだけ、と指示し、照合でも確かめます。

5行目も同じです。 相続税の申告期限のような一般的な期限を書き添えると、銀行の手続きの期限であるかのように読まれます。 期限は流れの表にあるものだけにします。

指示内容を固定する

あなたは銀行の相続センターの担当者として、相続人あての案内文書の下書きを書きます。
下の「規則が決めた書類」と「手続きの流れ」だけを使ってください。

【書くこと】
1. お悔やみの言葉（1文）と、この文書で案内することの要旨（2文以内）
2. この相続人に用意していただく書類（規則が決めた書類のコードごとに、説明文に沿って）
3. この相続人にしていただく手続きの流れ（流れの表の段階のうち、この相続人の役割に関係するものだけ）
4. 場合が「未確認」のときは、確かめていただきたいことと、ある場合・無い場合で書類がどう変わるか
5. 取引ごとの補足（貸金庫、投資信託など。取引の一覧にあるものだけ）
6. 確認中の取引があれば、担当者が確認していること

【厳守事項】
- 書類は「規則が決めた書類」にあるものだけを書いてください。
  念のための書類、あると便利な書類を足さないでください。
- 書類ごとに doc_code を必ず付けてください。説明文を言い換えるのはかまいませんが、
  通数・取得先・有効期間の数字は説明文のまま書いてください。
- 場合が未確認のとき、どちらかに決めて書かないでください。
- 遺産分割前の払戻しの印があるときは、制度があることと相談窓口だけを書き、
  払い戻せる額を書かないでください。
- 期限は「手続きの流れ」に書かれたものだけを書いてください。
  相続税の申告など、ほかの手続きの期限を書かないでください。
- 遺言書や遺産分割協議書の内容を解釈しないでください。
- 符号（H01 など）は符号のまま書いてください。氏名は後で差し込みます。
- 相続人が読んで分かる言葉にしてください。「被相続人」は「お亡くなりになった方」と書いてください。

【相続人の役割】{heir_role}
【場合】{case}（will / partition_agreement / no_agreement / court_document / unconfirmed）
【取引の一覧】{accounts}
【規則が決めた書類】{required_docs}
【手続きの流れ】{flow_steps}
【確認中の取引】{pending_checks}
【払戻しを急ぐ事情の印】{early_withdrawal_flag}

「通数・取得先・有効期間の数字は説明文のまま」を明記しないと、言い換えの中で数字が動きます。 表に書いた「発行後○か月以内」が「最近のもの」になると、相続人は古い印鑑証明書を持ってきます。言い換えてよいのは文の形だけ、と区切ります。

「被相続人は、お亡くなりになった方と書く」のような言葉の指定は、相続センターで一覧にして渡します。 遺産分割協議書、検認、遺言執行者のように言い換えられない言葉は、初めて出てくるところで1文の説明を添えるように指示します。

出力形式を固定する

構造化出力で、次の形のJSONを受け取ります。

{
  "case_no": "",
  "heir_code": "",
  "heir_role": "recipient | executor | other_heir | undecided",
  "case": "will | partition_agreement | no_agreement | court_document | unconfirmed",
  "greeting": "",
  "summary": "",
  "documents": [
    { "doc_code": "", "text": "" }
  ],
  "flow": [
    { "step_code": "", "text": "" }
  ],
  "branch_note": "",
  "account_notes": [
    { "account_type": "", "text": "" }
  ],
  "pending_note": ""
}

1つ目の理由は、documents の doc_code を規則の一覧と照合できることです。 規則が決めたコードの集合と、下書きに書かれたコードの集合が一致しなければ、下書きを担当者の手元で止めます。 多すぎても少なすぎても止めます。

2つ目は、相続人ごとに同じ形で並べられることです。 相続人が3人いれば3つのJSONができ、担当者は書類の欄だけを横に並べて、全員分で漏れが無いかを確かめられます。

スキーマには制約があります。 公式のページでは、すべての項目を required に入れる必要があり、省略してよい項目は null との組み合わせの型で表すとされています。オブジェクトには additionalProperties: false を必ず付け、スキーマ全体で項目は最大100、入れ子は5段までです。minItems や maxItems などのキーワードは使えないため、書類の数の確認はスキーマではなく照合の処理で行います。 出力の項目の順はスキーマの順に従うとされているので、案内文書の段落の順に項目を並べておきます。

システムへ連携する

氏名と住所は、文書にするときに差し込みます。 生成AIには符号のまま渡し、下書きができてから、相続の受付の台帳の値で置き換えます。 実名を生成AIに渡さずに済み、差し込み先の取り違えも台帳の値で防げます。

人が確認する

案内文書は、すべて担当者と上席が確かめてから送ります。 自動で郵送する経路は作りません。

1. 照合の結果を見る … 書類のコードが一致しない下書きは、まず規則の表の側を疑います。新しい取引の種類が表に無いことが多いためです
2. 確認欄を埋める … 照会できなかった取引を担当者が確かめ、規則の表を引き直して下書きを作り直します
3. 相続人ごとの書類を横に並べる … 全員分で、印鑑証明書を出す人、署名する人が揃っているかを見ます
4. 未確認の分岐を確かめる … 分岐の書き方が相続人を迷わせないかを読みます
5. 上席の確認 … 送る前に、場合の判定と書類の一覧を確かめます

3番目が、1通で済ませていたときに起きていた漏れ（第3章の（b））を防ぐ場所です。 1人分ずつ読むと漏れに気づきません。横に並べて、役割と書類の組み合わせが表どおりかを見ます。

目標は、300件をならして1件15分です。 預金だけで相続人が1人なら数分、取引が多く未確認の項目がある相続では30分を超えます。15分を大きく超える月は、規則の表の行が足りないか、照会できない取引が増えています。 下書きを直す時間ではなく、表と照会の側を見直します。

例外に対処する

下から3行目は、規則の表では扱いきれない場面です。 未成年者の相続人には特別代理人の選任が要る場合があるなど、家庭裁判所の手続きが絡むものは、定型の案内に乗せません。 担当者が電話で事情を聞いてから案内します。

記録を残す

• 相続の受付番号、取引の一覧の写し、申出の内容
• そのときの規則の表と流れの表の版の番号
• 生成AIに渡した入力（符号化したもの）と、返ってきたJSON
• 照合の結果（一致・不一致、不一致のコード）
• 担当者が直した箇所と、上席の確認の記録
• 送った案内文書の写しと、送付日、あて先の相続人

2つ目の版の番号が最も大事です。 規則の表は、取引の種類が増えたり行内の取り決めが変わったりするたびに直します。「なぜこの書類を案内したのか」を後から問われたときに、当時の表の版が分からないと答えられません。

5つ目は、表を良くする材料になります。 担当者が毎回同じ書類を足しているなら、表に行が足りません。同じ説明文を毎回直しているなら、説明文が分かりにくいのです。