投資信託の月次レポートを、顧客ごとの保有銘柄に合わせた分かりやすい説明文の下書きにし、営業担当のフォローの連絡に使う
運用会社が毎月出す投資信託の月次レポートから銘柄ごとの要点を作り、顧客が持っている銘柄の組み合わせに合わせて、分かりやすい説明の連絡文を下書きします。営業担当は確かめて直し、フォローの連絡に使います。
- 生成AI
- Azure OpenAI Service/Claude/Gemini
- 連携・自動化
- n8n/Power Automate
- 対象業界
- 金融
- 対象部門
- 営業
- 対象業務
- 書類作成/要約
- 主な課題
- 営業フォローが追いつかない/属人化している/書類作成に時間がかかる
- AIで行う処理
- 生成
- 主な効果
- 品質標準化/工数削減/機会損失防止
- 導入難易度
- ★★★☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 営業推進部が、今月のフォローの対象の顧客と銘柄の一覧を各店に流す
- 営業担当が、顧客の保有銘柄を投信の勘定の仕組みで確かめる
- 保有銘柄ごとに運用会社の月次レポートを開き、騰落率、分配金、運用の状況を読む
- 顧客の保有の組み合わせに合わせて、連絡文を書く
- 数値をレポートと照らし、表示が要る注意の文を付ける
- 上席が確かめ、電子メールか手紙で送るか、面談の手元資料にする
- 連絡したことを顧客の管理の仕組みに記録する
- 自動月次レポートが出そろったら、中継プログラムが保有の多い銘柄のレポートから文字と表を取り出す
- 自動Azure OpenAI で銘柄ごとの要点を作る(数値は記号で書き、根拠の文を写す)
- 自動中継プログラムが、要点の記号にレポートの表の数値を差し込み、根拠の文がレポートにあるかを確かめる
- 人コンプライアンスの担当が、銘柄ごとの要点を審査して承認する
- 自動営業推進部の対象の一覧の顧客ごとに、保有銘柄と審査済みの要点を材料に、連絡文の下書きを作る
- 自動中継プログラムが、顧客の保有の数値を差し込み、禁止の言い回しを点検し、表示の要る事項を定型の文で付ける
- 人営業担当が下書きを確かめ、顧客に合わせて直して送る
- 【人/自動】 連絡したことを顧客の管理の仕組みに記録する
各工程の詳しい説明を読む
- 営業推進部が、今月のフォローの対象の顧客と銘柄の一覧を各店に流す
- 営業担当が、顧客の保有銘柄を投信の勘定の仕組みで確かめる
- 保有銘柄ごとに運用会社の月次レポートを開き、騰落率、分配金、運用の状況を読む
- 顧客の保有の組み合わせに合わせて、連絡文を書く
- 数値をレポートと照らし、表示が要る注意の文を付ける
- 上席が確かめ、電子メールか手紙で送るか、面談の手元資料にする
- 連絡したことを顧客の管理の仕組みに記録する
(a)レポートを読むのに時間がかかる。 3番目で、同じ銘柄のレポートを支店の40名がそれぞれ読んでいます。同じ要点を40回読み取っているのと同じです。
(b)値下がりの月ほど遅れる。 値上がりの月の連絡文はすぐ書けますが、値下がりの月は言葉を選ぶのに時間がかかり、後回しになります。 顧客から「下がっているが大丈夫か」と電話が来てから説明することになり、本来いちばん連絡すべき月に連絡が遅れます。
(c)運用会社の見通しを自分の見立てのように書く。 「運用会社は〜と見ています」と書くべきところを、「今後は回復が見込まれます」と書いてしまう。誰の見方かが消えると、断定的な判断を伝えたように読めます。
(d)数値の書き写しを誤る。 騰落率の期間(1か月と1年)を取り違える、分配金を税引前と税引後で混ぜる。目で照らしても、忙しい月には漏れます。
- 【自動】 月次レポートが出そろったら、中継プログラムが保有の多い銘柄のレポートから文字と表を取り出す
- 【自動】 Azure OpenAI で銘柄ごとの要点を作る(数値は記号で書き、根拠の文を写す)
- 【自動】 中継プログラムが、要点の記号にレポートの表の数値を差し込み、根拠の文がレポートにあるかを確かめる
- 【人】 コンプライアンスの担当が、銘柄ごとの要点を審査して承認する
- 【自動】 営業推進部の対象の一覧の顧客ごとに、保有銘柄と審査済みの要点を材料に、連絡文の下書きを作る
- 【自動】 中継プログラムが、顧客の保有の数値を差し込み、禁止の言い回しを点検し、表示の要る事項を定型の文で付ける
- 【人】 営業担当が下書きを確かめ、顧客に合わせて直して送る
- 【人/自動】 連絡したことを顧客の管理の仕組みに記録する
4番目が、この設計の分かれ目です。 審査するのは、600通の連絡文ではなく、30本ほどの銘柄の要点です。 連絡文は審査済みの要点からしか作らないので、要点を通った言葉だけが顧客に届きます。
7番目で、営業担当が必ず確かめてから送ります。 顧客の事情(最近の相談の内容、家族の状況、前回の連絡への反応)は、営業担当にしか分かりません。 下書きは出発点で、送る文の責任は営業担当にあります。
02今回想定するシステム構成
運用会社の月次レポート(PDF)── 毎月上旬に出そろう ▼【トリガー】対象の銘柄のレポートがそろった 中継プログラム(Azure Functions)── 文字と表の取り出し ▼ Azure OpenAI(Microsoft Foundry)── 1段目:銘柄ごとの要点(構造化出力) ▼ 中継プログラム ── 数値の差し込み、根拠の文の照合 ▼ 【人】コンプライアンスの担当が要点を審査・承認 ▼ 投信の勘定の仕組み(顧客ごとの保有)+ 営業推進部の対象の一覧 ▼ Azure OpenAI ── 2段目:顧客ごとの連絡文の下書き(数値は記号) ▼ 中継プログラム ── 保有の数値の差し込み、禁止の言い回しの点検、表示の要る事項の付加 ▼ 営業担当の下書きの一覧 → 確かめて直して送る → 顧客の管理の仕組みに記録
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 生成AI | Azure OpenAI(Microsoft Foundry)の Standard デプロイ | Claude、Gemini |
| 連携 | Azure Functions(レポートの取り出し、数値の差し込み、点検、下書きの一覧への書き込み) | Power Automate、n8n |
| 保管 | Azure Blob Storage(レポート、要点、審査の記録、下書きと送った文) | 文書管理の仕組み |
| 定型文 | 表示の要る事項と注意の文(コンプライアンスの担当が管理) | ― |
投信の勘定の仕組みと顧客の管理の仕組みは、新しく足すものではありません。 投信の勘定からは対象の顧客の保有の明細を読むだけで、書き込みは連絡の記録だけです。 記録も、営業担当が送ったことを確かめた後に行います。
生成には、Azure OpenAI の構造化出力を使います。 渡した JSON Schema にモデルの出力を従わせる機能で、以前の JSON モードは正しい JSON を保証しても、スキーマへの厳密な準拠は保証しなかったとされています。要点を決まった項目で受け取り、数値の記号と根拠の文を項目として持たせるために使います。
データの扱いは、Standard デプロイを選ぶことで決めます。 プロンプトと応答は他の顧客に提供されず、基盤モデルの学習に使われず、モデルはステートレスで、プロンプトも応答もモデルに保存されないとされています。Global や DataZone の種類でなければ、指定した地域(geography)の中で処理されるとされているので、日本の地域のリソースに Standard デプロイを置きます。
03どうやって実装するのか
処理の起点を決める
1段目の起点は、対象の銘柄の月次レポートが出そろったことです。 運用会社のレポートの掲載日は銘柄ごとに違うので、営業推進部が対象にした銘柄のレポートがすべて保管の場所に入った時点で動かします。 毎営業日の朝に保管の場所を見て、そろったかを確かめます。
2段目の起点は、コンプライアンスの担当が要点を承認したことです。 承認された銘柄から順に、その銘柄を持つ対象の顧客の下書きを作ります。複数の銘柄を持つ顧客は、持っている銘柄の要点がすべて承認されてから作ります。 1銘柄だけ先に書いた下書きを送ると、残りの銘柄の説明が抜けた連絡になります。
月の途中で分配金の額の変更や繰上償還の告知が出たときは、別の起点として臨時の要点を作ります。 臨時の要点も同じ審査を通します。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 月次レポート | 基準価額、騰落率(期間別)、分配金の実績、資産の構成、組入れの上位、運用の状況と今後の運用方針の文 | 運用会社のPDF |
| 銘柄の基本情報 | 銘柄名、運用会社、分類、決算の頻度 | 自社の銘柄の台帳 |
| 対象の一覧 | 今月のフォローの対象の顧客と、対象にした理由(基準価額の変動、分配金の変更) | 営業推進部 |
| 顧客の保有 | 保有銘柄、口数、評価額、取得からの損益、分配金の受取り方 | 投信の勘定の仕組み |
| 連絡の希望 | 連絡の方法(電子メール・手紙・面談)、前回の連絡の日 | 顧客の管理の仕組み |
| 定型文 | 表示の要る事項、元本の保証が無い旨などの注意の文 | コンプライアンスの担当 |
質を決めるのは、月次レポートの表を正しく取り出すことです。 騰落率の表は「1か月・3か月・6か月・1年・設定来」のように期間が列に並び、列を1つずらして読むと、1か月の騰落率として1年の値を伝えることになります。 表は列の見出しと値の組で取り出し、見出しの無い値は使いません。
顧客の名前は、生成AIに渡しません。 2段目で渡すのは、保有銘柄の組み合わせと、評価額の増減の向き(増えた・減った)と、分配金の受取り方の区分だけです。名前と数値は、下書きができた後に中継プログラムが差し込みます。
データの取得方法を決める
| 取るもの | どこから | 何に使うか |
|---|---|---|
| レポートの文 | PDFの文字の層 | 運用の状況と見通しの要点 |
| レポートの表 | PDFの表(見出しと値の組) | 騰落率・分配金・基準価額の差し込み |
| 顧客の保有の明細 | 投信の勘定の仕組みの書き出し | 保有の数値の差し込み |
| 対象の顧客 | 営業推進部の一覧 | 下書きを作る顧客の決定 |
運用会社のレポートはレイアウトが会社ごとに違います。 主な運用会社ごとに、表の位置と見出しの読み方を設定にしておき、設定の無い会社のレポートは表の取り出しを人が確かめます。 PDFの文字の層が無いレポートは、取り出しに失敗した旨を出して対象から外します。
記号の対応表は、銘柄ごとに例えば次のような形で作ります。
{
"fund_code": "F0123",
"report_month": "2026-09",
"values": [
{ "symbol": "{nav}", "label": "基準価額", "value": "12,345円", "as_of": "2026-09-30" },
{ "symbol": "{ret_1m}", "label": "騰落率(1か月)", "value": "-3.2%", "as_of": "2026-09-30" },
{ "symbol": "{dist_last}", "label": "分配金(1万口あたり・税引前)", "value": "50円", "as_of": "2026-09-15" }
]
}
label に期間と税引前・税引後の区別を必ず入れます。 差し込む先の文にも同じ label を添えて表示するので、「1か月の騰落率」なのか「1年の騰落率」なのかが、顧客の読む文の上でも分かります。 値の書式(円・%・カンマ)は対応表の側で決め、生成AIには触らせません。
顧客の保有の明細は、営業推進部が対象を決めた日の終わりの時点のものを使います。 評価額は日々変わるので、連絡文に書く評価額には「何月何日時点」を必ず付けます。 日付は中継プログラムが差し込みます。
AIへ渡す前に整形する
- 表を見出しと値の組にする … 騰落率の期間、分配金の決算日、基準価額の日付を見出しと組にします
- 文を節に分ける … 「運用の状況」「今後の運用方針」などの見出しで分け、節の名前を付けます
- 数値に記号を割り当てる … 表の値ごとに
{ret_1m}{dist_last}のような記号を割り当て、記号と値の対応表を作ります - 顧客の保有をまとめる … 顧客ごとに、保有銘柄の組み合わせと、評価額の増減の向き、分配金の受取り方の区分を作ります
- 顧客を型に束ねる … 保有銘柄の組み合わせと区分が同じ顧客を1つの型にまとめ、型ごとに1回だけ下書きを作ります
- 名前と口座の情報を外す … 2段目に渡す材料から、顧客の名前・口座番号・住所を外します
5番目で、生成の回数を減らします。 600件の対象の顧客でも、保有銘柄の組み合わせと区分の型は数十から百程度に収まります。型ごとに下書きを作れば、同じ型の顧客には同じ材料から同じ下書きが出ます。 顧客ごとの違いは、差し込む数値と、営業担当の直しで付けます。
2番目の節の名前は、誰の見方かを守るために使います。 「今後の運用方針」の節から取った文は、連絡文では必ず「運用会社は〜としています」と主語を付けて書かせます。
AIに処理させる
1段目でさせるのは、月次レポートの文から、顧客に伝える要点を短い文で書き、数値を記号で示し、根拠の文をそのまま写すことです。
| 要点の項目 | 中身 | 書き方 |
|---|---|---|
| 今月の動き | 基準価額の動きと、その主な理由 | 理由は「運用の状況」の節の言葉に沿う |
| 分配金 | 直近の分配金の額と、前回からの変化 | 額は記号、変化の有無だけを文で |
| 運用の状況 | 資産の構成や組入れの変化 | レポートに書かれた範囲だけ |
| 運用会社の見通し | 今後の運用方針 | 必ず「運用会社は」を主語にする |
2段目でさせるのは、顧客の保有の型ごとに、審査済みの要点をつないで、平易な言葉の連絡文を書くことです。 複数の銘柄を持つ型では、銘柄ごとの段落を作り、最初の段落で全体の動きをまとめます。数値は1段目と同じ記号で書かせます。
| させないこと | 理由 |
|---|---|
| 将来の値動きの予想 | 不確実なことの断定的判断の提供に当たりうる |
| 買い増し・売却・乗り換えを勧めること | この連絡は勧誘のためのものではない |
| 運用会社の見通しを自社や担当者の見立てとして書くこと | 誰の見方かが消える |
| 数値を本文に書くこと | 差し込みで書く。書き写しの誤りを防ぐ |
| 顧客の損益を計算すること | 投信の勘定の数値を使う |
| 審査済みの要点に無いことを足すこと | 審査を通らない言葉が顧客に届く |
1行目と3行目が最も起きやすい失敗です。 値下がりの月に顧客を安心させる文を書かせると、モデルは「長期的には回復が期待されます」と書きます。レポートに運用会社の見通しとして書かれていても、主語を外せば自社の見立てになります。
1段目の要点は、例えば次のような文になります。
| 項目 | 要点の文 |
|---|---|
| 今月の動き | 基準価額は {ret_1m} の動きでした。運用会社は、組み入れている海外株式の下落を主な理由に挙げています |
| 分配金 | 直近の分配金は {dist_last} で、前回と同じ額でした |
| 運用会社の見通し | 運用会社は、今後も業績の安定した企業への分散投資を続ける方針としています |
どの文も、理由と見通しに「運用会社は」が付いています。 値下がりの理由を自社の言葉で説明し直すと、レポートに無い分析が入ります。理由はレポートに書かれたものだけを、運用会社の説明として伝えます。
指示内容を固定する
2段目の指示の例です。1段目も同じ禁止事項を持ちます。
あなたは銀行の資産運用の相談の担当として、投資信託をお持ちのお客さまに、
今月の運用の状況をお伝えする連絡文の下書きを作ります。
読むのは60代以上のお客さまで、専門用語に慣れていない方を想定してください。
【材料】
- お客さまの保有の型:{holding_pattern}
- 銘柄ごとの審査済みの要点:{approved_points}
【書き方】
1. 最初の段落で、お持ちの銘柄の今月の動きを2〜3文でまとめてください。
2. 銘柄ごとに段落を分け、要点の順に書いてください。
3. 数値は本文に書かず、要点にある記号(例:{ret_1m})をそのまま書いてください。
4. 専門用語は、言い換えるか短い説明を添えてください(例:基準価額=投資信託の値段)。
5. 全体で400〜600字にしてください。
【厳守事項】
- 審査済みの要点に無いことを書かないでください。
- 今後の値動きを予想しないでください。「回復が見込まれます」
「今後も上昇が期待できます」のような文を書かないでください。
- 運用会社の見通しを書くときは、必ず「運用会社は〜としています」と書いてください。
- 買い増し、売却、乗り換えを勧める文を書かないでください。
- お客さまの損益を計算しないでください。
- 注意の文や、表示が必要な事項は書かないでください(後で定型の文を付けます)。
「注意の文を書かない」は、定型の文と食い違わせないためです。 生成させると、元本の保証が無い旨の言い回しが毎回少しずつ変わり、審査済みの定型の文と違う表現が顧客に届きます。 表示の要る事項は、コンプライアンスの担当が管理する定型の文を中継プログラムが付けます。
「記号をそのまま書く」は、記号の対応表で差し込むためです。 本文に残った記号が対応表に無ければ、下書きを営業担当に出さずに止めます。
出力形式を固定する
1段目は、構造化出力で次の形の JSON を受け取ります。
{
"fund_code": "",
"report_month": "",
"points": [
{ "item": "monthly_move | distribution | portfolio | manager_outlook",
"text": "", "placeholders": [""], "source_section": "", "evidence": "" }
]
}
スキーマはすべての項目を必須にし、オブジェクトごとに additionalProperties: false を付けます。 構造化出力はJSON Schemaの一部の機能だけに対応し、すべての項目を必須にすること、additionalProperties: false を付けることが求められ、出力の項目の順はスキーマの順に従うとされています。item は列挙(enum)で4つの値に限ります。
1つ目の理由は、evidence で要点の根拠をレポートの文と照らせることです。 中継プログラムが evidence の文字列がレポートの文に含まれるかを確かめ、含まれない要点は審査の画面で赤く示します。
2つ目は、source_section で誰の見方かを機械的に確かめられることです。
| 条件 | 扱い |
|---|---|
item が manager_outlook で、text に「運用会社は」が無い | 審査に出さず作り直す |
source_section が「今後の運用方針」なのに item が別 | 審査の画面で印を付ける |
placeholders の記号が対応表に無い | 審査に出さず作り直す |
evidence がレポートの文に無い | 審査の画面で赤く示す |
2段目の出力は、連絡文の本文と使った記号の一覧です。 中継プログラムが記号に数値を差し込み、禁止の言い回しの一覧(「必ず」「確実」「見込まれます」「買い時」など)に当たる語が無いかを点検し、当たれば下書きに印を付けます。
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| レポートの保管の場所 | 読み取り | 月次レポートのPDFを取る |
| Azure OpenAI | API呼び出し(構造化出力) | 1段目の要点、2段目の下書き |
| 審査の画面 | 書き込みと承認の読み取り | 要点の審査と承認 |
| 投信の勘定の仕組み | 書き出しの読み取り | 顧客ごとの保有の明細 |
| 営業担当の下書きの一覧 | 書き込み | 下書きと、点検の結果 |
| 顧客の管理の仕組み | 書き込み(送った後) | 連絡の記録 |
下書きを顧客へ自動で送ることはしません。 電子メールの送信も手紙の印刷も、営業担当が下書きを確かめた後に行います。送信の機能は、この構成に持たせません。
人が確認する
人の確認は2か所に置きます。
- コンプライアンスの担当が要点を審査する … 銘柄ごとの要点を、レポートと照らして承認します。運用会社の見通しの主語、禁止の言い回し、根拠の文を見ます
- 営業担当が下書きを確かめる … 差し込まれた数値がその顧客の保有のものか、顧客の事情に合っているかを見て直します
- 直した下書きを点検に通し直す … 営業担当が直した文も、禁止の言い回しの点検に通してから送ります
- 上席が抜き取りで見る … 営業担当が大きく直したものを中心に見ます
審査の画面には、要点の文とレポートの該当箇所を左右に並べます。 evidence の文はレポートの側で色を付け、差し込まれた数値には対応表の label と日付を添えます。 30本の要点を1本数分で見られる形にしておかないと、審査が毎月の流れの詰まりになります。
3番目を省かないでください。 審査は要点に対して行っているので、営業担当が直した言葉は審査を通っていません。 直した文に「今が買い時」と足されれば、要点の審査の意味がなくなります。
同じ要点から作る連絡文は、広告等の規制の対象になりうるものとして扱います。 金融商品取引業等に関する内閣府令は、電子メールや郵便などで多数の者に対して同様の内容で行う情報の提供を、広告に類似する行為としています。どこまでが個別の連絡で、どこからが広告等に当たるかは、コンプライアンスの担当と決めておき、要点と定型の文の審査をその手続きに乗せます。
例外に対処する
| 起きること | 対応 |
|---|---|
| 対象の銘柄のレポートが届かない | その銘柄を持つ顧客の下書きを作らない。営業推進部に知らせる |
| 表の取り出しに失敗した | その銘柄の要点を作らない。設定を直すか、人が表を読む |
| 要点の根拠の文がレポートに無い | 審査の画面で赤く示す。コンプライアンスの担当が作り直しを指示する |
| 本文に対応表に無い記号が残った | 下書きを出さずに作り直す |
| 禁止の言い回しが含まれる | 下書きに印を付け、営業担当が直す。直した後も点検に通す |
| 繰上償還や分配金の変更の告知が月の途中で出た | 臨時の要点を作り、審査を通してから下書きを作り直す |
| 顧客の保有がレポートの月の途中で変わった | 対象を決めた日の時点の保有で作り、日付を明記する |
| 顧客が連絡を望まない旨を伝えている | 顧客の管理の仕組みの連絡の希望で対象から外し、下書きを作らない |
| 顧客の保有の型が1人だけの組み合わせ | 型にまとめても名前を渡さないことは同じ。下書きは作るが、営業担当の直しを前提にする |
| 生成の呼び出しが失敗する | 営業担当が従来どおり書く |
6行目は、値動きの連絡より急ぐものです。 繰上償還の告知を受けた顧客は、次の手続きを考える時間が要ります。 月次の流れとは別に、承認されたらすぐ下書きを出します。
記録を残す
- 月次レポートの原本と、取り出した文・表・記号の対応表
- 1段目の要点の JSON と、コンプライアンスの担当の承認の記録(承認した人・日時・直した点)
- 2段目の下書きと、差し込んだ数値と、点検の結果
- 営業担当が直した後の送った文と、直す前の下書きとの差分
- 連絡の方法と送った日、顧客の管理の仕組みへの記録
2つ目と4つ目は、顧客から「こう説明された」と申し出があったときの記録です。 どの要点を材料に、誰が承認し、営業担当がどう直して送ったかが残っていれば、説明の経緯を後からたどれます。 直しの差分は、営業担当がどこで下書きを信用していないかも示します。
04実装レベルの3段階
半自動化で、1件15分が10分程度になります。 レポートを読む時間は審査済みの要点で縮みますが、顧客の保有の組み合わせに合わせて書くのは営業担当のままです。本格構成で5分になり、この段階が本記事の想定です。 差が大きいのは、組み合わせに合わせた文と数値の差し込みが、型ごとに機械で行われるからです。 段階を飛ばさないでください。 半自動化の間に、コンプライアンスの担当と要点の審査の基準を固めます。基準が揺れたまま顧客ごとの下書きを出すと、営業担当の直しが増え、点検の意味が薄れます。
05工数削減シミュレーション
導入後 600件 × 5分 ÷ 60 = 50 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 投資信託を販売する銀行・信用金庫・証券会社で、販売した顧客へのアフターフォローとして、基準価額の動きや分配金の変更を毎月伝える運用をしている場合。取り扱う投資信託が数十本から百本を超え、営業担当が運用会社の月次レポートを読んで顧客ごとに連絡文を書いている場合。値下がりした月ほど連絡が後回しになり、顧客から問い合わせを受けてから説明している場合。広告等の審査の手続きがあり、コンプライアンスの担当が連絡文のひな形を審査できる場合。
- 投資信託の顧客が少なく、営業担当が1人ずつ電話で話して足りる場合。運用会社の月次レポートを顧客にそのまま送るだけで、説明を足す運用をしていない場合。連絡文で次に買う銘柄や乗り換えを勧めたい場合(この構成はレポートに書かれた事実を顧客の保有銘柄に合わせて伝えるだけで、勧誘の文は作りません)。顧客の名前や保有の明細をクラウドの生成AIに渡すことが、社内の規程で認められていない場合。
07最小構成で試す方法
- 先月の対象の顧客から20件を選ぶ(値下がりした銘柄を持つ顧客と、3銘柄以上を持つ顧客を数件入れる)
- その20件について、営業担当が実際に送った連絡文を拾う
- 関係する銘柄の月次レポートを手元のAIサービスに読み込ませ、銘柄ごとの要点を作らせる
- 要点と保有の組み合わせを貼り、「この要点だけを使って、お客さまへの連絡文を書いてください。数値は書かず記号のままにしてください。今後の値動きを予想しないでください。運用会社の見通しは運用会社を主語にしてください」と指示する
- 下書きを、実際に送った連絡文と、コンプライアンスの担当の目で比べる
| 出てきた内容 | 判断 |
|---|---|
| 実際の連絡文より平易で、要点が漏れていない | 2段の構成と審査の手続きの構築に進む |
| 見通しの主語が外れた | 指示の書き方と点検で直る。構成は有効 |
| 実際に送った連絡文にも禁止の言い回しがあった | 定型の文と審査の基準をそろえるのが先。 AIの問題ではない |
3行目が出ることは珍しくありません。 失敗ではなく、これまでの連絡文の書き方そのものに、直すべき点があったと分かったということです。 その場合は、コンプライアンスの担当と、要点の審査の基準を先に決めてください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 今後の値動きを予想する文を書く | 指示で禁じ、禁止の言い回しの点検で止める |
| 運用会社の見通しの主語が外れる | 節の名前で見通しの要点を見分け、主語が無ければ作り直す |
| 騰落率の期間を取り違える | 表を見出しと値の組で取り出し、数値は記号で差し込む |
| 注意の文の言い回しが毎回変わる | 生成させず、定型の文を付ける |
| 顧客の名前を生成AIに渡してしまう | 保有の型にまとめ、名前は下書きの後に差し込む |
| 1銘柄だけ先に下書きを送る | 保有銘柄の要点がすべて承認されてから作る |
| 営業担当の直しで禁止の言い回しが入る | 直した文も点検に通してから送る |
| 繰上償還の告知が月次の流れに埋もれる | 臨時の要点として別の起点で動かす |
| レポートの表の取り出しが会社ごとに崩れる | 主な運用会社ごとに読み方を設定し、設定の無いものは人が確かめる |
| どこからが広告等に当たるかが曖昧 | コンプライアンスの担当と決め、要点と定型の文を審査の手続きに乗せる |
上の3行が、この構成の失敗のほとんどです。 どれも、顧客を安心させたい文が事実の伝達を越えることか、数値を写し間違えることから来ます。見通しの主語と数値の差し込みを機械で守っているかどうかで、営業担当が下書きを信用できるかが決まります。
最後の行は、始める前に決めておくものです。 運用を始めてから広告等に当たると判断が変わると、それまでに送った連絡文の表示を見直すことになります。 審査の手続きに乗せる範囲は、広めに取って始め、記録を見ながら狭めるほうが安全です。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 顧客の保有銘柄、口数、評価額、取得からの損益、連絡の方法です。顧客の資産の状況は、銀行が扱う情報の中でも特に慎重に扱うべきものです。
- 顧客の名前と口座の情報を生成AIに渡さない … 保有の型にまとめて渡し、名前と数値は下書きの後に差し込みます
- 処理する地域を決める … Standard デプロイを日本の地域のリソースに置き、Global や DataZone の種類を使いません
- 断定的な判断や勧誘の文を作らせない … 金融商品取引法は、不確実な事項について断定的判断を提供して勧誘することを禁じています。指示で禁じ、点検で止め、人が確かめます
- 広告等の表示の規制を確かめる … 多数の者に同様の内容で行う情報の提供は、広告に類似する行為とされます。表示の要る事項は定型の文で付け、要点と定型の文を審査の手続きに乗せます
- 顧客へ自動で送らない … 送るのは営業担当で、送った文の記録を残します
- 記録の閲覧を限る … 下書きと送った文には顧客の資産の状況が入るので、営業担当とその上席、コンプライアンスの担当に限ります
誤りが起きた場合のリスクは、誤った数値や断定的な見通しを顧客に伝えることと、顧客の資産の情報が不要に広がることの2つです。 前者は数値の差し込みと見通しの主語の点検で、後者は保有の型にまとめて名前を渡さないことで防ぎます。
10まず何から始めるか
1週目:対象の銘柄と定型の文を決める
顧客の保有の多い30本を選び、表示の要る事項と注意の文をコンプライアンスの担当と定型の文にします。禁止の言い回しの一覧もここで作ります。
2週目:20件で試す
先月の対象から20件を選び、手元のAIサービスで要点と連絡文を作らせます。見通しの主語が外れていないか、値動きを予想していないかを最優先で見ます。
3週目:審査の基準を決める
要点の何を見て承認するか、どこからが広告等に当たるかを、コンプライアンスの担当と営業推進部で決めます。 あわせて、運用会社ごとのレポートの表の読み方を設定します。
4週目:要点を自動で作る
Azure OpenAI の Standard デプロイを日本の地域に置き、構造化出力で要点を作り、数値の差し込みと根拠の照合をして審査に回すところまで作ります。この時点では、承認された要点を営業推進部が各店に配ります。
2か月目: 投信の勘定の書き出しから保有の型を作り、顧客ごとの下書きと禁止の言い回しの点検を足します。3か月目以降: 全店で使い、1件15分が何分になったかを実測します。値下がりの月にも対象の顧客への連絡が月の前半に終わり、コンプライアンスの抜き取りで見つかる不適切な表現が3か月続けて無かった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 金融商品取引法第37条:広告その他これに類似するものとして内閣府令で定める行為をするときの表示の義務と、利益の見込み等について著しく事実に相違する表示・著しく人を誤認させるような表示の禁止。第38条第2号:顧客に対し、不確実な事項について断定的判断を提供し、又は確実であると誤解させるおそれのあることを告げて勧誘をする行為の禁止 | e-Gov 法令API: 金融商品取引法 | 2026-10-07 |
| 金融商品取引業等に関する内閣府令第72条:郵便、ファクシミリ、電子メール、ビラ又はパンフレットの配布その他の方法により多数の者に対して同様の内容で行う情報の提供を、広告類似行為とすること。第73条:広告等をするときの表示の方法 | e-Gov 法令API: 金融商品取引業等に関する内閣府令 | 2026-10-07 |
構造化出力が渡した JSON Schema にモデルを従わせること。JSON モードはスキーマへの厳密な準拠を保証しなかったこと。すべての項目を必須にし、additionalProperties: false を付けること。出力の項目の順がスキーマの順に従うこと。対応する型に Enum が含まれること | Microsoft Learn: How to use structured outputs with Azure OpenAI in Microsoft Foundry Models | 2026-10-07 |
| プロンプトと応答が他の顧客に提供されず、基盤モデルの学習に使われないこと。モデルがステートレスであること。Global・DataZone の種類でなければ指定した地域の中で処理されること | Microsoft Learn: Data, privacy, and security for Foundry Models sold by Azure | 2026-10-07 |
連絡文が広告等に当たるか、どの表示が要るかは、各社のコンプライアンスの担当が法令と業界の規則に照らして判断してください。 本記事は e-Gov 法令API と Microsoft Learn で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-0861)についてのご相談はこちらから。
