証券会社の営業員から出る商品の取扱い・勧誘のルール・手続きの質問に、社内の取扱規程と商品資料を根拠に答え、答えられないものをコンプライアンス部門に回す

処理の起点を決める

起点は、営業員が照会フォームを送信したことです。 チャットの自由な書き込みではなく、項目の決まったフォームにします。顧客の区分を選択肢にすることで、氏名や資産の額が書かれる余地をなくします。

照会の内容の欄には、入力の時点で氏名らしい語や数字の並びを検知して警告を出します。 消してから送らせます。

もう一つのトリガーは、規程の改正と商品の取扱い開始・終了です。 規程の主管部署が改正の通知を出したら、新しい版と施行日を置き、規程の表を直します。商品部が取扱い開始の通知を出したら、商品の属性に1行足します。取り込みは毎晩まとめて行い、規程の表と商品の属性は即時に直します。

入力データを集める

質を決めるのは、規程の表と商品の属性です。 この2つが値でそろっていれば、照会のうち「勧誘してよい区分か、承認が要るか」の部分は、AIの読み取りに頼らずに引けます。表の各行には根拠の条番号を書かせます。 AIの引用と突き合わせるためです。

過去の回答集には、判断した部署を必ず書きます。 窓口が規程から答えたものと、コンプライアンス部門が判断したものは、同じ回答でも重みが違います。 後者は個別の事情の上での判断なので、別の照会にそのまま当てはめられないことがあります。

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

規程・細則・商品資料・回答は、1件ごとにファイルにして Cloud Storage に置きます。公式では、メタデータは JSON Lines で、1行ごとに id、structData、content（mimeType と uri）を書きます。

{"id":"rule-solicit-2026-04","structData":{"doc_kind":"rule",
 "product_risk":["R4","R5"],"audience":"sales",
 "effective_from":"2026-04-01T00:00:00Z","effective_to":"9999-12-31T00:00:00Z",
 "article_index":["第12条","第12条の2"]},
 "content":{"mimeType":"application/pdf","uri":"gs://sales-rules/rule-solicit-2026-04.pdf"}}

照会のたびに、中継プログラムが絞り込みの条件を作ります。 公式の構文では、文字の項目は ANY() に並べた値のどれかと完全に一致するかを見られ、OR でつなげ、日時の項目は ISO 8601 の文字列と比べられます。

(product_code: ANY("F-20931") OR product_risk: ANY("R4"))
AND effective_from <= "2026-10-13T00:00:00Z" AND effective_to >= "2026-10-13T00:00:00Z"

商品のコードとリスクの区分を OR でつなぐのは、商品資料と規程の両方を引くためです。 商品資料は商品のコードで、規程はリスクの区分で絞れます。項目はスキーマで索引可能にしておかないと絞り込みに使えません。

AIへ渡す前に整形する

1. 規程に版と施行日を付ける … 改正の通知ごとに、どの条が変わったかと施行日を書きます
2. 規程の表を作る … 規程の主管部署が、リスクの区分 × 顧客の区分の扱いと根拠の条を表にします
3. 商品の属性をそろえる … 取扱い開始の通知から、リスクの区分と勧誘の対象の区分を値にします。取扱いを終えた商品には終了日を入れます
4. 回答集を整える … チャットの記録から照会と回答を拾い、根拠の条項と判断した部署を確かめて1件ずつ文書にします。顧客の情報は区分に置き換えます
5. 照会の文の個人情報を確かめる … 送信の後にも、氏名・口座番号・電話番号らしい文字列を検知し、見つかったら検索に使わず窓口へ回します

2番目の表は、規程の主管部署が責任を持ちます。 窓口やシステムの担当が規程を読んで作ると、読み方のずれが表の値として固定されます。 改正のたびに主管部署が直し、直した日を表に残します。

AIに処理させる

させるのは、規程・細則・商品資料から該当する条項と記述を探し、引用して回答案を書くことです。

3つ目を名指しで禁じるのは、営業員の照会に「この債券はおすすめか」「元本割れの可能性は低いか」が混ざるからです。 AIがそれに答えると、営業員がそのまま顧客に伝える文になります。 金融商品取引法は、不確実な事項について断定的判断を提供して勧誘する行為を禁じています。照会の回答から、その種の文が生まれないようにします。

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

指示内容を固定する

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

あなたは証券会社の営業推進部の照会窓口として、支店の営業員からの
商品の取扱い・勧誘の規程・手続きの照会に、社内の規程と商品資料を
根拠に回答案を作る立場です。読むのは支店の営業員です。

【前提】
検索の文の最初に、商品のコード、商品のリスクの区分、
顧客の年齢・投資経験・取引の目的の区分、口座の種類が並んでいます。
「規程の表の扱い」として、事前承認・確認書などの扱いが並んでいます。

【答え方】
1. 規程の表の扱いの根拠になる規程・細則の条を、名前と条番号を付けて
   本文のまま引用してください。
2. その条が求める手続き（承認、確認書、説明）を、規程の言葉で
   順に並べてください。
3. 照会に商品の仕組みやリスクの質問があれば、商品資料から引用して
   答えてください。
4. 引用した条が、規程の表の扱いと合わないと思われるときは、
   そのことを書いてください。

【厳守事項】
- この顧客に勧誘してよい、勧誘しないほうがよいと書かないでください。
- 規程の表の扱いを、別の扱いに読み替えないでください。
- 値動き、利回り、元本割れの可能性の見通しを書かないでください。
  「安全」「おすすめ」「低リスク」と書かないでください。
- 検索結果に無い規程、他社や業界一般の運用で補わないでください。
- 顧客への説明の文言を作らないでください。
- 該当する条が見つからないときは、
  「該当する規程は見つかりませんでした。コンプライアンス部門が
  確認します」とだけ書いてください。

「規程の表の扱いを読み替えない」と「合わないと思われるときは書く」を両方入れているのが要です。 前者だけだと、表が古いときにAIは古い扱いの根拠を無理に探します。後者があれば、表と規程の食い違いが照会のたびに見つかり、表の直し漏れを拾えます。

「安全」「おすすめ」を名指しで禁じるのは、商品資料にそれに近い語があるからです。 商品説明書の「相対的に価格変動が小さい」を、AIは「低リスク」と要約したがります。

出力形式を固定する

answer メソッドの返り値と規程の表の結果を、中継プログラムが次の形にまとめます。

{
  "inquiry_id": "",
  "product_code": "",
  "product_risk": "",
  "customer_class": { "age": "", "experience": "", "purpose": "", "account": "" },
  "rule_table": { "treatment": "none | pre_approval | confirmation | no_solicit",
                  "basis_article": "", "table_version": "" },
  "citations": [
    { "doc_kind": "rule | detail | notice | product | answer",
      "title": "", "article": "", "quote": "", "effective_from": "", "uri": "" }
  ],
  "procedures": [],
  "answer_text": "",
  "route": "answer | escalate",
  "escalate_reason": []
}

citations は、answer メソッドの references から取ります。公式では、citations の sources が referenceId で references を指し、references の chunkInfo に本文の断片と文書のメタデータが入ります。引用の位置（startIndex／endIndex）は UTF-8 のバイト数なので、日本語の文を文字数で切るとずれます。

route は次の規則で決めます。

どれにも当たらないものだけが answer です。 JSONにする理由は、この振り分けを規則で行うためです。特に article_mismatch は、表の条番号と引用の条番号を値で比べなければ見つけられません。

システムへ連携する

待ち行列の1行には、照会の内容、規程の表の結果、引用、escalate_reason を付けます。 担当は、探すところからではなく、判断するところから始められます。

顧客管理システムにも承認の手順にも書き込みません。 回答に「事前の承認が要る」とあれば、営業員がいつもの手順で承認を申請します。

人が確認する

人が確認するのは escalate の照会です。 answer の回答は営業員へ直接返しますが、運用を始めてから2か月は、全件を窓口の担当が見てから返します。

1. escalate_reason を見る … 表と引用の食い違いか、勧誘しない区分か、禁止の語かを確かめます
2. 規程を確かめて判断する … 食い違いなら、表と規程のどちらが正しいかを規程の主管部署に確かめます
3. 回答し、回答集に登録する … 根拠の条項と判断した部署を付けます
4. 表を直す … 表の誤りが分かったら、主管部署が直し、直した日を残します

2か月の全件確認で見るのは、answer で返したもののうち、窓口が見れば escalate にしたものが無いかです。 1割を超えるなら、answer の直接の返信を始めません。

目標は、400件をならして1件3分です。

例外に対処する

5行目の禁止の語の検知は、プロンプトとは別に、中継プログラムの文字列の照合で行います。 プロンプトで禁じても、言い換えて書くことがあります。最後の門は機械の照合に置きます。

6行目を忘れやすいので注意してください。 session を続けたまま別の商品の話を聞くと、前の商品の絞り込みと文脈で答えます。

記録を残す

• 照会の内容（6項目）、照会した営業員の所属、日時
• answer メソッドへの要求（絞り込みの条件、preamble の版）と返り値の全文
• 規程の表の結果と、そのときの表の版
• route と escalate_reason、担当の判断と根拠
• 営業員へ返した回答と、返した日時

表の版を残すのは、後のモニタリングや検査で回答の根拠を問われたときのためです。 その日の表と規程の版で答えたことを示せないと、回答の正しさを確かめられません。