証券会社の営業員が書く勧誘の記録を、適合性の原則と社内規程に照らして点検し、記載の抜けと確認が要る勧誘を管理部門に回す

処理の起点を決める

毎朝の定時に、前日の面談記録をまとめて処理します。 内部管理責任者は朝に前日の記録を読んでいるので、その時刻までに点検の一覧が出ていれば足ります。 記録は営業員が夕方から夜に書くことが多いので、翌朝の処理なら前日分がほぼそろっています。

前日の夜より後に書き足された記録は、翌日の処理で拾います。 書き足しの日時を見て、一度点検した記録が書き足されたら、もう一度点検の対象に入れます。 内部管理責任者の指示で書き足された記録が、指示どおりに直ったかを確かめるためです。

入力データを集める

質を決めるのは、記載事項の一覧の例です。 「顧客の反応」を「検討する」の一言で記載ありとするか、何を検討するのかまで要るかを、例で決めておきます。 例の無い一覧では、AIも内部管理責任者と同じだけ迷います。

取引の集計は、プログラムで作って渡します。 監督指針は、合理的な理由を欠く高頻度の売買かの判断にあたって、顧客の年間の平均投資残高に対する支払手数料の累計額の割合や、顧客の過去の取引頻度などに留意するとしています。この割合は取引のデータから計算するもので、AIに計算させるものではありません。 AIには、計算した値と社内の目安を超えたかの印だけを渡します。

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

顧客管理システムからの書き出しの方式は、製品によって違います。 この部分は、利用しているシステムに応じた個別の実装になります。 承認の記録が別のシステムにある場合は、顧客の番号でひも付けられるかを最初に確かめます。

承認の記録は「その日に有効なもの」を引きます。 承認に有効期間を設けている社内規程なら、勧誘の日が有効期間の中にあるかを見ます。勧誘の日より後の承認は、事前承認になりません。

AIへ渡す前に整形する

1. 個人情報の置き換え … 顧客の氏名、住所、電話番号、口座番号を記録の本文から外し、顧客の番号に置き換えます。本文中の家族の名前や勤務先も、顧客カードの登録値で探して置き換えます
2. 区分への変換 … 生年月日は年齢の区分に、金融資産の額は資産の区分に変換し、値そのものは渡しません
3. 承認の記録の付加 … その日に有効な承認があれば、対象の商品と承認した役席者の役職を付けます
4. 取引の集計の付加 … 直近の取引の回数、同じ日の売却と購入の有無、手数料の割合と社内の目安を超えたかの印を付けます
5. 短すぎる記録の扱い … 本文が数文字の記録（「不在」「留守電」など）は、勧誘が無かったものとして記載事項だけを見ます
6. 版の記録 … 使った記載事項の一覧と商品の区分の一覧の版を、記録ごとに残します

2番目を省かないでください。 年齢と資産の額をそのまま渡すと、AIはそれを使って「この年齢でこの商品は不適当」と書きます。適合性の判断はこの構成の外に置くので、判断の材料になる値を必要以上に渡しません。 承認の要否は、区分を使って規則が決めます。

AIに処理させる

させるのは、記載事項ごとの有無の判定、記録から案内した商品を読み取ること、確認が要る型に当たる記述を引用することです。

3行目と4行目の右端が、この構成でいちばん大事な区別です。 監督指針が不適当な勧誘の例に挙げるのは、適合しない商品を勧誘するために、顧客に投資目的の変更を求める行為です。顧客が自分から見直したいと言った場合とは、意味が違います。記録に「誰が言い出したか」が書かれていないなら、それ自体が書き足しを求める理由になります。

最後の行は、顧客カードの更新につながります。 監督指針は、顧客の申出等で資産・収入の状況や投資目的が変化したことを把握した場合に、顧客カード等の登録内容の変更を行うか否かを顧客に確認した上で変更を行うことを着眼点にしています。記録にそうした申出が出てきたら、顧客カードが直されたかを内部管理責任者が確かめる材料にします。

4行目がいちばん起きやすい失敗です。 記録に「見直しのご相談」とだけあると、AIは文脈から「顧客の希望による」と補います。補った瞬間に、書き足しを求めるべき記録が「問題なし」に変わります。

指示内容を固定する

あなたは証券会社の営業管理の担当として、営業員の面談記録を点検します。
渡された記録と一覧だけを見て判定してください。推測で補わないでください。

【記載事項ごとの status】
- written .. 一覧の例の「記載あり」に当たる記述がある
- vague .... 記述はあるが、例の「記載なし」に当たるほど中身が無い
- missing .. 記述が無い
迷ったときに written を選ばないでください。

【確認が要る型】
- switching: 保有する商品の売却と別の商品の購入を勧める記述
- objective_change: 投資目的やリスクの許容度を変える話が出た記述
- customer_report: 資産・収入の状況や投資目的が変わったという顧客の発言
各型について、initiator を sales（営業員が持ちかけた）/ customer（顧客から）/ unclear で示す。

【厳守事項】
- quote には、根拠にした記録の文を、記録のとおりに一字一句写してください。
- 記録に誰が持ちかけたか書かれていなければ、initiator は unclear にしてください。
  文脈から推測して customer にしないでください。
- 案内した商品は、記録に出てくる名前を products_mentioned に写し、
  商品の区分の一覧で対応する名前があれば product_code に入れてください。無ければ unknown_product。
- 承認が要るか、承認があったかを判断しないでください。承認の記録は別に照合します。
- 勧誘が適合性の原則に反するか、不適当かを書かないでください。
- 年齢、資産の額について書かないでください。営業員を評価しないでください。

【記載事項の一覧（版：{rule_version}）】{required_items}
【商品の区分の一覧】{product_list}
【この記録の付加情報（顧客の区分・取引の集計の印）】{context}
【面談記録】{record}

「誰が持ちかけたか書かれていなければ unclear」を独立した1項目にしているのは、ここが点検の要だからです。 一般的な「推測しない」だけでは、AIは文脈から読み取れることは推測ではないと考えます。この項目だけは、明示されていなければ unclear と決めます。

「承認が要るか判断しない」を入れているのは、渡した顧客の区分から、AIが承認の要否まで言い出すからです。 AIの判断と規則の判断が食い違ったとき、どちらが正しいかの議論になるのを避けます。

出力形式を固定する

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

{
  "record_id": "",
  "rule_version": "",
  "required_items": [
    { "item_no": "", "status": "written | vague | missing", "quote": "" }
  ],
  "products_mentioned": [ { "name_in_record": "", "product_code": "" } ],
  "patterns": [
    { "type": "switching | objective_change | customer_report",
      "initiator": "sales | customer | unclear", "quote": "" }
  ]
}

公式の説明では、構造化出力ではすべてのフィールドを必須にし、オブジェクトには additionalProperties: false を設定する必要があり、最大100個のオブジェクトのプロパティと最大5段の入れ子が持てるとされています。

1つ目の理由は、引用をプログラムで照合できることです。 Azure Functions が quote を記録の本文と突き合わせ、一致しないものは unverified として扱い、その指摘を採用しません。

2つ目は、AIの読み取りと規則の判断を別の層に置けることです。 AIは products_mentioned で商品を読み取り、承認が要るかは、顧客の年齢の区分と product_code の区分の組み合わせで規則が決めます。 承認が要るのにその日に有効な承認が無ければ、approval_missing とします。

乗換えの記述が拾われた記録では、patterns にたとえば次の要素が返ります。

{ "type": "switching", "initiator": "unclear",
  "quote": "保有中のAファンドの一部を売却し、新しい外債ファンドへの切替えをご案内。前向きにご検討とのこと。" }

「ご案内」とあっても、切替えの話をどちらが先に出したかは書かれていないので unclear です。 内部管理責任者は、営業員にどちらから出た話かを確かめ、記録に書き足させます。

3つ目は、取引の集計と突き合わせられることです。 switching が拾われた記録で、取引のデータに同じ日の売却と購入があれば、記録の文章と実際の取引がそろって乗換えを示していることになります。

システムへ連携する

どのシステムにも書き込みません。 点検の結果を顧客管理システムに戻すと、確かめる前の判定が顧客の記録に残ります。 書き足しの指示は、内部管理責任者がいまの方法で行います。

人が確認する

1. escalate を最初に見る … 承認の記録が本当に無いか、承認のシステムへの登録が遅れただけかを確かめます。無ければ営業員に事情を聞き、本社に報告します
2. review を読む … 引用と記録の前後を読み、乗換えや投資目的の変更を誰が持ちかけたかを営業員に確かめます。customer_report は顧客カードが直されたかを見ます
3. insufficient を営業員に戻す … 抜けている記載事項を示して書き足させます
4. clear は一覧で流し見る … 営業員ごとの件数と、引用の無い記録だけを見ます
5. 判定を直したら記録する … どの記録の、どの判定を、何に変えたかを残します

1番目で「登録の遅れ」を必ず確かめてください。 承認は口頭で得て、システムへの登録が翌日になることがあります。登録の遅れを承認の無い勧誘として扱うと、営業員は点検そのものを信じなくなります。 登録の遅れが多いなら、それは承認の運用の問題として本社に上げます。

目標は、4,500件をならして1件1分です。 clear は流し見で数秒、review と escalate は記録の前後を読み、営業員に確かめるので数分かかります。

例外に対処する

上の2行は、AIの問題ではなく台帳の問題です。 商品の区分の一覧と顧客カードが整っていないと、規則が承認の要否を決められず、review が増えます。 一覧の整備が、点検の精度を上げるいちばんの近道です。

記録を残す

• 面談記録の版（書き足しの前後）と、点検した日時
• 付加した顧客の区分、承認の記録、取引の集計の印
• 使った記載事項の一覧と商品の区分の一覧の版
• Azure OpenAI に渡した入力と、返ってきたJSONの全文
• 引用の照合の結果と、規則で決めた点検の結果
• 内部管理責任者が判定を直した記録と、営業員への指示・聴取の記録

最後の行は、監督指針が内部管理部門に求める検証の材料にもなります。 監督指針は、内部管理部門が勧誘の実態の把握の方法を定め、その状況を把握・検証して見直すことを着眼点にしています。どの型の指摘がどれだけ出て、どう処理されたかが残っていれば、点検の方法そのものを見直せます。