投資信託を販売したときの提案記録を、顧客カードの属性・投資経験・意向と照らして点検し、記録の不足と確認漏れを営業店へ戻す

処理の起点を決める

毎朝6時に、前営業日に約定した分をまとめて取り出します。 記録の入力は約定の当日か翌日に終わる運用が多いので、約定の翌営業日の朝に点検すれば、営業店の担当者が面談を覚えているうちに照会できます。月に一度まとめて点検すると、照会が届くころには担当者が面談の中身を思い出せません。

記録が未入力のものは、その日の点検から外し、翌日に持ち越します。 3営業日たっても入力されないものは、記録が無いこと自体を escalate として一覧に出します。 入力を待ち続ける設計にすると、記録の無い販売がいつまでも点検されません。

販売の取消しや約定の訂正があった場合も、翌朝の取り出しで拾い直します。同じ約定を二度点検しないよう、約定番号で既処理を管理します。

入力データを集める

質を決めるのは、いちばん下の一覧です。 「リスクを説明した」という記載を、記載ありとするのか、何のリスクをどう説明したかまで要るのかが決まっていなければ、AIは書いた人の数だけ違う判定を返します。 一覧の例は、過去の照会で営業店とやり取りした記録から作るのが早く、照会して追記された実例が、そのまま「記載あり」の例になります。

顧客カードの最終更新日を必ず入れます。 第3章の（d）を拾うには、記録に書かれた資産や収入の変化と、顧客カードがいつ更新されたかを並べる必要があります。

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

営業店システムから、毎朝のバッチで3つのデータを取り出します。つなぎ方は、約定番号から顧客番号、顧客番号から顧客カードの順です。

顧客カードは、約定日時点の内容を取ります。 点検する日までに顧客カードが更新されていると、最新の内容では食い違いが消えて見えます。履歴を持っていない場合は、取り出した時点の内容を点検結果と一緒に保存します。

記録が約定番号でひも付かない運用もあります。その場合は顧客番号と、約定日の前14日以内の面談日で引き、複数見つかれば全部を渡します。提案から約定まで数回の面談を重ねることがあるからです。

AIへ渡す前に整形する

1. ひも付けの確認 … 約定に対応する記録が見つからないものは、AIに渡さず escalate の候補にします
2. 規則の照合 … 年齢が社内規則の基準に当たるか、当たる場合に承認の記録があるか、承認の日時が約定より前かを照らします
3. リスク区分の照合 … 商品のリスク区分と顧客のリスク許容の区分を、本部が決めた対応表で照らし、範囲外なら out_of_range を付けます
4. 顧客カードの鮮度 … 最終更新日からの経過を計算し、本部が決めた期間を超えていれば印を付けます
5. 個人を特定する項目を外す … 氏名、住所、電話番号、口座番号は記録の本文から置き換え、顧客番号は仮の番号に置き換えます
6. 値を文章に直す … 顧客カードの選択式の値を、「投資目的：元本の安全性を重視」のような項目名付きの文にします

2番から4番を、AIより先に済ませるのが大事です。 これらは答えがデータから決まり、AIに読ませると読み落としたり、それらしい解釈を足したりする余地が生まれます。 結果はAIに「すでに分かっている事実」として渡し、文章の読み取りにだけ集中させます。

5番目で氏名を外しても、点検はできます。 判定に要るのは年齢の区分や投資目的であり、名前ではありません。家族の名前や勤務先が記録の本文に書かれていることもあるため、置き換えの規則は辞書と正規表現の両方で作ります。

AIに処理させる

させるのは、記録の文章について3つのことを判定し、根拠にした文を原文のまま書き出すことだけです。

右端の列が、この構成でいちばん大事な区別です。 missing は記録に何も書かれていないこと、vague は書かれているが一覧の基準に届かないことで、営業店への照会の書き方が変わります。 前者は「記載がありません」、後者は「何をどう説明したかを追記してください」です。混ぜると、営業店は何を書き足せばよいか分かりません。

食い違いと理由を別の欄にするのは、第1章のとおりです。 食い違いがあっても、「お客様から、分配金を生活費に充てたいとのご意向。元本が減る可能性を、基準価額の推移の例で説明し、ご理解いただいた」と書かれていれば、理由は written です。照会するかどうかは、その組み合わせで規則が決めます。

4行目がいちばん起きやすい失敗です。 「目論見書を交付」とだけある記録を読ませると、目論見書にリスクが書いてあるのだから説明したのだろうと考えて written にしがちです。交付したことと説明したことは別の事項として一覧に並べ、指示でも分けます。

指示内容を固定する

あなたは銀行の本部で、投資信託などの販売記録を点検する立場です。
営業店が残した提案・面談の記録を読み、記録として残っているかどうかだけを判定してください。
販売が顧客に適合していたかどうかの結論は書かないでください。

【必ず書く事項】{required_items}
（番号、事項、記載ありとする例、記載なしとする例が並んでいます）

【status の選び方（必ず書く事項）】
- written ... 一覧の「記載ありとする例」と同じ程度に具体的に書かれている
- vague ..... 触れているが、例の程度に届かない（例：「リスクを説明」とだけある）
- missing ... 記録のどこにも書かれていない
迷ったときに written を選ばないでください。

【食い違いの書き出し方】
- 顧客カードの値と、記録に書かれた意向・資金の性格・投資経験が合わない箇所を、
  記録の原文をそのまま引用して書き出してください。
- 食い違いごとに、その理由や意向が変わった経過が記録に書かれているかを
  written ／ partial ／ missing で答えてください。
- 記録に書かれていないことを補って理由を作らないでください。

【厳守事項】
- 書面を交付したことと、その内容を説明したことは別の事項です。
  「目論見書を交付」だけを根拠に、リスクや手数料の説明を written にしないでください。
- 「通常は説明している」「おそらく理解している」といった推測で埋めないでください。
- evidence には、判定の根拠にした記録の文を一字も変えずに写してください。
  根拠が無い場合は空にしてください。
- 年齢の基準、承認の有無、リスク区分の照合結果は【確認済みの事実】として渡します。
  これを読み直したり、別の結論を書いたりしないでください。
- 顧客の人柄、判断能力、理解力について、記録に無い評価を書かないでください。
- 記録に資産・収入・投資目的の変化が書かれていれば、card_update_hint に原文を写してください。

【確認済みの事実】{rule_results}
【顧客カード（約定日時点）】{customer_card}
【商品の属性】{product}
【提案・面談の記録】{records}

「交付と説明は別」を明記しないと written が増えます。 記録には「重要事項説明書、目論見書を交付し説明」のように、交付と説明が一文に並んで書かれることが多く、何も言わなければその一文を根拠に、リスク・手数料・元本割れの可能性のすべてを written にします。一覧の側でも、交付と説明を別の番号にしておきます。

「確認済みの事実を読み直さない」と書くのは、AIが規則の結果を上書きしようとするためです。 承認の記録が無いと渡すと、本文の「課長同席」という記載を見つけて承認ありと書き直すことがあります。同席と承認は別のものとして、規則の側で扱います。

出力形式を固定する

次の形のJSONで受け取ります。

{
  "trade_id": "",
  "required_items": [
    { "item_no": "R03", "status": "written | vague | missing", "evidence": "" }
  ],
  "conflicts": [
    {
      "field": "investment_purpose | fund_character | experience | risk_tolerance",
      "card_value": "",
      "record_quote": "",
      "reason_status": "written | partial | missing",
      "reason_quote": ""
    }
  ],
  "card_update_hint": "",
  "unclear_points": [""],
  "inquiry_draft": ""
}

required_items には一覧の事項を全部並べます。判定を省いた事項があると、後段で missing と区別がつかないためです。 structured outputs は項目をすべて required にするので、省くこと自体ができません。

1つ目の理由は、AIの判定と照会の決定を別の層に置けることです。 required_items と conflicts はAIが埋め、照会するかどうかは Python が規則で決めます。

2つ目は、照会の基準が変わっても直すのは規則だけで済むことです。 監査の指摘で「手数料の説明が vague なら照会」を「missing のときだけ照会」に変える、といった変更が、プロンプトを触らずにできます。

3つ目は、evidence と record_quote で確認が速くなることです。 担当者は記録の全文を開く前に、AIが何を根拠にしたかを一覧で読めます。evidence が記録の中に一字一句そのまま存在するかは、Python で文字列として照合します。 存在しなければ、その判定は unclear に落とします。

システムへ連携する

営業店システムへは書き込みません。 記録の追記と顧客カードの変更は、顧客に確かめたうえで営業店の担当者が行うものだからです。監督指針も、顧客カードの登録内容の変更は顧客に確認したうえで行うことを求めています。この構成が出すのは、「変更の要否を確かめてください」という照会までです。

照会の送信も人が行います。下書きは照会の仕組みの入力欄に貼れる形で作り、送るかどうか、文面をどう直すかは担当者が決めます。

人が確認する

人が読むのは ask_branch と escalate のものだけです。 clear のものは、店ごと・担当者ごとの件数を一覧で流し見ます。

1. escalate を先に読む … 承認の記録が無い、記録そのものが無いなど、照会では済まないものが入っています。 コンプライアンス統括部へ回すかを決めます
2. ask_branch の根拠を確かめる … evidence と record_quote を読み、必要なら記録の全文を開きます。missing の事項が本当に書かれていないかを、全文で確かめます
3. 照会文を直して送る … 営業店が何を追記すればよいかが分かる書き方になっているかを見ます
4. 判定を覆したら記録する … どの事項を、どちらに変えたかと理由を残します

2番目を省かないでください。 記録が複数の面談に分かれていて、AIに渡した範囲に説明の記載が無かっただけ、ということがあります。照会の空振りは、営業店の点検への信頼を下げます。

clear の抜き取りも続けます。 毎月、clear から数十件を選んで人が全文を読み、AIが written にした事項が本当に書かれていたかを確かめます。 照会の一覧だけを見ていると、見逃しの側の誤りに気づけません。

例外に対処する

4行目を「AIが読めなかった」と扱わないでください。 記録が短いことは、それ自体が点検で拾いたい事実です。短い記録を人の点検へ回すと、照会の件数がAIの導入前と変わらなくなります。

最後の行は、監査のときに効いてきます。 どの時点の基準で点検したかが残っていないと、過去の判定が正しかったかを説明できません。

記録を残す

• 点検の対象にした約定番号と、取り出した日時
• AIに渡した記録・顧客カード・商品の属性・確認済みの事実（個人を特定する項目を置き換えた後のもの）
• AIが返したJSONの全文と、使ったモデルのデプロイ名と、必ず書く事項の一覧の版
• 規則で決めた判定（clear ／ ask_branch ／ escalate）と、その根拠になった条件
• 人が判定を覆した記録 … どの事項を、どちらに変えたか、理由
• 照会を送った日時、営業店の回答、追記の有無、照会を閉じた日時
• 店ごと・担当者ごとの vague と missing の発生率

3つ目で一覧の版を残すのは、基準が後から変わるためです。 「記載あり」の例を書き換えると、過去の判定の意味が変わります。当時の基準が残っていないと、監査で問われたときに説明できません。

最後の行は、営業店の研修の材料になります。 特定の店や担当者に同じ事項の vague が続くなら、記録の書き方を教えるほうが、照会を繰り返すより早く直ります。