この記事で分かること

  • ウェルスマネジメントの提案プロセス7工程を「AI可(一般化した情報のみ)/AI補助+人が確定/人のみ」で仕分ける判定表と、その判定理由
  • 顧客の氏名・口座番号・保有明細・家族構成・健康状態・年収といった情報をAIに入力しない前提で、一般化した条件から提案書の叩き台を作る具体的な手順とプロンプト
  • AIが書きがちな提案書の4つの問題(断定的な将来リターン/リスクの過小記載/横並びの定型文/目的とつながらない配分)と、人が必ず直す確認項目
  • 「どの前提で、どのデータで、誰が判断したか」を後から再現できるようにする記録様式と、提案書ドラフトに固有の検証手順

はじめにお断りします。本記事は教育目的の一般的な解説であり、投資助言ではありません。特定の商品・配分・運用方針を推奨するものではなく、記事中に登場する条件や数値はすべて理解のための仮設例です。また、法令の適用可否についての判断も行いません。実務への適用にあたっては、所属先の法務・コンプライアンス部門および専門家にご確認ください。

結論:AIには「顧客のいない提案書」しか作らせない

ウェルスマネジメントの現場で生成AIを使いたい、という相談で最初に出てくるのが「顧客の資産状況を貼り付けて、最適な提案書を作らせたい」という発想です。この使い方は、実務上おすすめできません。理由は2つあります。

第一に、顧客の個人情報・資産情報をAIサービスに入力すること自体が、そもそも慎重な検討を要する行為だからです。個人情報保護委員会は2023年6月2日付の「生成AIサービスの利用に関する注意喚起等について」で、個人情報取扱事業者が生成AIサービスにプロンプトとして個人情報を含む内容を入力する場合には、特定した利用目的の達成に必要な範囲内であることを十分に確認する必要があると注意喚起しています。この注意喚起は具体的な入力可否を一律に判定するものではありませんが、少なくとも「業務で使うのだから当然入れてよい」という前提が成り立たないことは明らかです。具体的な適用は、所属先の法務・コンプライアンス部門にご確認ください。

第二に、提案の中身を決める工程こそ、AIが最も不得手な領域だからです。顧客がなぜその資金を持っているのか、何を不安に思っているのか、家族と何を話したのか——提案の妥当性を左右するのはこうした個別事情ですが、これはAIに渡すべきでない情報であると同時に、渡したところでAIには重み付けができない情報でもあります。

そこで本記事が勧める運用は単純です。①一般化した条件だけを与えてAIに叩き台を作らせる → ②人が個別事情を当てはめて書き換える → ③人が最終確認する。AIが触れるのは①だけで、②と③には一切関与させません。この線を引いておくと、「どこまでAIを使ったか」を説明する必要が生じたときにも答えが明確になります。金融商品取引法には顧客の知識・経験・財産の状況や契約の目的に照らして不適当な勧誘を行ってはならないという適合性の原則が、また金融サービスの提供に関する法制には重要事項の説明に関する規律が置かれています。いずれも「誰が判断し、誰が説明したのか」が特定できることを前提とした制度であり、AIの介在がその特定を曖昧にしてはいけません。制度の詳細な解釈や個別事案への当てはめは本記事の範囲外です。

全体像:一般化 → 個別化 → 最終確認の3層

提案書ができるまでの流れを、AIの関与という軸で描き直すと次のようになります。工程の呼び方は会社によって異なりますが、①顧客ニーズのヒアリング、②リスク許容度の把握、③資産配分案の作成、④商品選定、⑤提案書の作成、⑥説明、⑦アフターフォローという7つに整理すると、AIの適用可否を議論しやすくなります。

提案プロセス7工程×AIの適用区分 AI可(一般化情報のみ) AI補助+人が確定 人のみ 工程 区分 判定の理由 ① 顧客ニーズのヒアリング 人のみ 発言内容そのものが個人情報 ② リスク許容度の把握 人のみ 適合性の確認は対話が前提 ③ 資産配分案の作成 AI補助+人が確定 一般化した条件で複数案を出す ④ 商品選定 人のみ 取扱商品・手数料は社内情報 ⑤ 提案書の作成 AI可(一般化情報のみ) 構成と一般的な説明文のみ ⑥ 説明 人のみ 説明の履行は担当者本人の行為 ⑦ アフターフォロー AI補助+人が確定 定型の市況コメント案まで ※本図は一般的な整理です。所属先の社内規程が優先します。
図1:提案プロセス7工程とAIの適用区分。7工程のうち4工程は「人のみ」で、AIが単独で担える工程は⑤の下書きに限られます。

この図から読み取ってほしいのは、AIが単独で担える工程は7つのうち1つしかないという事実です。世の中には「AIが提案書を自動生成する」という表現がありますが、実際に自動化できるのは「顧客が特定されていない状態での文章の骨格」までです。骨格に中身を入れる作業は、依然として人の手に残ります。この構造は、業界全体の役割分担を理解しておくと納得しやすくなります。運用会社・販売会社・アドバイザーの機能の違いについてはアセットマネジメント業界の全体像を参照してください。

工程ごとの判定:何をAIに任せ、何を人が確定するか

図1の判定を、実務で使える粒度まで開いたものが次の表です。「AIに任せる範囲」を狭く具体的に書いておくことが重要で、範囲が曖昧なまま運用すると、担当者ごとに使い方がばらついて説明が難しくなります。

工程区分AIに任せてよい範囲人が必ず行うことその判定にした理由
① 顧客ニーズのヒアリング人のみなし(面談前の一般的な質問項目リストの作成のみ可)面談・記録・意図の確認顧客の発言は個人情報そのもの。要約のためにAIへ渡すと入力範囲が一気に広がる
② リスク許容度の把握人のみなし(社内の確認項目を一般論として説明させるのみ可)確認表の実施・本人の理解確認適合性の確認は本人との対話を前提とする制度趣旨。回答の解釈をAIに委ねられない
③ 資産配分案の作成AI補助+人が確定一般化した条件(年代帯・期間区分・目的の類型)に対する考え方の複数案と、各案の長所短所の整理個別事情を踏まえた採否の決定、比率の確定論点の網羅には使えるが、採否は顧客の個別事情に依存し、AIはその情報を持たない
④ 商品選定人のみなし取扱商品一覧との照合・費用の確認・社内規程の適用取扱商品・手数料体系・販売可否は社内情報であり、AIは最新の正しい情報を持たない
⑤ 提案書の作成AI可(一般化情報のみ)章立て・見出し・一般的な用語説明・リスク説明の定型部分の下書き個別部分の記入、断定表現の修正、最終稿の確定顧客が特定されない文章の骨格づくりであれば、入力情報を一般論に限定できる
⑥ 説明人のみなし(想定問答の一般的な類型化のみ可)対面・非対面での説明、理解の確認、記録説明を履行する主体は担当者本人。AIが介在すると誰が説明したかが曖昧になる
⑦ アフターフォローAI補助+人が確定一般顧客向けの市況コメントの下書き、よくある質問の整理個別の残高・損益に触れる部分の記載、送付先の決定、最終確認一般論の文章は再利用が効く一方、個別の運用状況に踏み込むと個人情報の領域に入る

③の「考え方の複数案」という書き方に注意してください。ここでAIに求めるのは、たとえば「取り崩し期に入る資金の性質を踏まえると、流動性の確保をどう設計するかについてどんな考え方があるか」といった論点の洗い出しであって、比率の指示ではありません。分散の理論的な背景は現代ポートフォリオ理論とアセットアロケーションで、資産クラスごとの性質はオルタナティブ投資の分類で扱っています。リスクとリターンを同じ土俵で比べる指標についてはリスク調整後リターンの指標が参考になります。AIに理論の説明をさせると、もっともらしいが出典のない記述が混じるため、理論的な裏付けは一次資料か社内の教材で確認するのが確実です。

何をAIに入れないか:入力可否の判断

ここが本記事の中心です。顧客に紐づく情報は、原則としてどれも入力しない——この一線を最初に引いてしまうのが、結局いちばん運用しやすくなります。「この程度なら大丈夫か」を毎回考えると、判断が担当者ごとにぶれ、後から検証もできません。

入力可否の判断フロー AIに入力したい情報 特定の個人を識別できる情報か 氏名・口座番号・保有明細・家族構成・健康状態・年収の実額 はい 入力しない いいえ 一般化した属性に置き換えられるか 年代帯・リスク許容度の区分・資金の目的の類型 いいえ 入力しない はい 利用している環境はどちらか 一般向けサービス 入力しない(社内規程を確認) 法人契約の管理環境 社内規程の範囲で可
図2:入力可否の判断フロー。同じ情報でも、一般向けサービスか法人契約の管理環境かで扱いが変わります。

図2で最後に環境の分岐が来ることに注目してください。同じ「一般化した属性」であっても、どの環境で使うかによって扱いが変わります。一般に公開されている無料・個人向けのサービスと、勤務先が法人契約を結び、入力データの取り扱い範囲やログの保存条件が契約と社内規程で定められた管理環境とでは、前提が異なります。前者では一般化した属性であっても入力を控え、後者では社内規程の範囲内で扱う、という整理が現実的です。ただし本記事は特定のサービスの契約内容を判定するものではありません。どの環境が「管理環境」に当たるかは、必ず所属先の規程と契約書で確認してください。情報区分の作り方と社内ルールの整備手順そのものは本記事の範囲外です(「機密情報・個人情報の注意」に関連記事を挙げています)。本記事では顧客情報という文脈に絞ります。

情報の種類具体例一般向けサービス法人契約の管理環境代わりに書く一般化表現
顧客氏名山田太郎様入力しない入力しない記載しない(提案書上は空欄のまま人が記入)
口座番号・顧客番号口座番号、社内顧客ID入力しない入力しない記載しない
保有明細保有商品名と評価額の一覧入力しない入力しない「複数の投資信託を保有」等、商品分類のみを人が記述
家族構成配偶者・子の人数・年齢入力しない入力しない「扶養が必要な家族の有無」という区分のみを人が判断材料にする
健康状態既往歴、要介護度入力しない入力しない記載しない(要配慮個人情報に当たり得るため特に慎重に扱う)
年収・資産の実額年収◯◯万円、金融資産◯◯万円入力しない入力しない実額を書かず「運用に回せる資金の性質」だけを類型で示す
年代帯60代前半控える社内規程の範囲で可10年刻み以上の粗い区分にする
リスク許容度の区分元本毀損の許容度は小さい控える社内規程の範囲で可社内の確認表の区分名だけを使う
資金の目的の類型取り崩しながら生活費を補う控える社内規程の範囲で可目的の類型名のみ(背景事情は書かない)
運用可能期間の区分10年程度控える社内規程の範囲で可「5年未満/5〜10年/10年以上」等の区分

表の下半分(薄い青の行)が、いわゆる「一般化した条件」です。これらを組み合わせても、その組み合わせが特定の個人と結びつきうる場合には慎重な判断が必要になります。たとえば地方の小規模な支店で、特定の職業・年代・目的が重なると、事実上個人が特定できてしまうことがあります。属性を一般化しても、組み合わせの珍しさが残っていないかを最後に確認する——これが実務上の落とし穴です。

作業手順:一般化した条件で叩き台を作る

ここからは実際の手順です。所要時間の目安は、慣れれば1件あたり30〜40分程度です(後掲の設例参照)。

  1. 面談記録を人が読み、社内の確認表に沿って区分を確定する。この時点ではAIを使いません。区分とは、年代帯・運用可能期間・リスク許容度・資金の目的の類型といった、社内で定義済みのカテゴリのことです。
  2. 区分だけを並べた「一般化した条件文」を人が書く。10行以内の箇条書きにします。ここに固有名詞・実額・具体的なエピソードが1つでも混じっていないかを、書いた本人が読み返します。
  3. 条件文をAIに渡し、提案書の構成案と一般的な説明文の下書きを作らせる。プロンプトは後掲のものを使います。出力には必ず「[要個別確認:〇〇]」のプレースホルダを入れさせます。
  4. 出力から、そのまま使える部分と使えない部分を人が仕分ける。一般的な用語説明とリスク説明の定型部分は再利用でき、目的・配分・商品に関する部分は原則として書き直しになります。
  5. 個別事情を人が当てはめる。面談記録を見ながらプレースホルダを埋め、AIの言い回しを自分の言葉に置き換えます。ここでAIに戻さないことが重要です。
  6. 断定表現とリスク記載を人が点検する。後掲のチェックリストを使います。必要なら、顧客情報を削除・置換したドラフトを点検用プロンプトにかけて機械的な見落としを拾います。
  7. 記録を残して確定する。使った条件文の全文、AI出力の版、人が変更した箇所と理由を保存します(後掲の記録様式)。

プロンプト例1:一般化した条件から構成案と下書きを作る

特定のAI製品に依存しない汎用の書き方です。そのままコピーして、条件文の部分だけを差し替えて使えます。

【役割】あなたは、日本の金融機関で個人向け資産運用の提案書を作成する担当者を補助するアシスタントです。特定の顧客は想定されていません。以下の一般化した条件だけを前提に作業してください。

【目的】提案書の「章立て(構成案)」と「一般的な説明文の下書き」を作る。具体的な商品・配分・運用方針の推奨は行わない。

【入力資料】以下の一般化した条件のみ。これ以外の情報は与えられていません。
- 年代帯:60代前半
- 資金の性質:退職金の一部
- 運用可能期間の区分:10年程度
- リスク許容度の区分:元本毀損の許容度は小さい(社内確認表の区分名)
- 目的の類型:取り崩しながら生活費を補う
- 制約:一定額の流動性を確保したい

【対象期間】期間の単位は「年」で統一する。
【単位】比率は%、金額は百万円で表記する。ただし金額の実額は記載しない。

【出力形式】
1. 提案書の見出し構成(章立てと、各章の目的を1行で)
2. 各章に入れるべき記載項目の箇条書き
3. 「リスクの説明」章の一般的な説明文の下書き(400字以内)
4. 担当者が個別に埋める必要がある箇所の一覧(本文中に [要個別確認:〇〇] の形で埋め込み、末尾に一覧化する)

【計算方法】数値計算は行わない。試算が必要な箇所は [要試算] とだけ記載する。

【禁止事項】
- 具体的な商品名・ファンド名・銘柄名を書かない
- 「〜すべきです」「〜が最適です」といった推奨表現を使わない
- 将来のリターン・利回りを断定的に書かない(「年率〇%が見込めます」等)
- 顧客の個人情報を尋ねない。情報が不足する場合は質問せず [要個別確認:〇〇] と書く
- 法令・規制の適用可否を判断しない。制度に触れる場合は「制度の趣旨」までに留める

【不明情報の処理】前提が不足している箇所は推測せず「不明」と書き、何が不足しているかを併記する。

【出典の表示】制度・統計に言及する場合は、出典が特定できるものだけを書く。特定できない場合は「出典未確認」と明記する。

【検算】数値を含む記述を出した場合は、根拠となる計算式を必ず併記する。

【レビュー項目】最後に、担当者が確認すべき点を次の4観点でリスト化する。
(1)断定表現の有無 (2)リスク記載の分量 (3)目的と記載内容の対応 (4)個別化が必要な箇所の抜け

プロンプトの一般的な組み立て方(役割・文脈・形式・検証の4点セット)は金融実務のためのプロンプトエンジニアリングで解説しているため、ここでは提案書作成に固有の要素だけを補足します。ポイントは「禁止事項」に推奨表現と断定的な将来予測を明示的に書くことと、不足情報を質問させずにプレースホルダにさせることです。質問を許すと、担当者がつい顧客情報を答えてしまう経路ができてしまいます。

出力例と、人が書き換えた箇所

上のプロンプトを実行すると、おおむね次のような構成案が返ってきます(要約して掲載しています)。なお以下の条件・記述は仮設のモデルケースであり、特定の商品・配分・運用方針を推奨するものではありません。

1. 見出し構成
  第1章 ご相談の背景と目的の確認  /目的:面談で伺った内容の再確認
  第2章 前提条件の整理            /目的:期間・制約・確認済み区分の明示
  第3章 考え方の選択肢            /目的:取りうる方針の比較
  第4章 想定されるリスク          /目的:損失の可能性と種類の説明
  第5章 費用                      /目的:継続的に発生する費用の明示
  第6章 今後の見直しの進め方      /目的:見直しの時期と条件

2. 各章の記載項目(抜粋)
  第2章:運用可能期間の区分/確保したい流動性の考え方 [要個別確認:確保額]
  第3章:各選択肢の長所と短所/[要試算]
  第4章:価格変動/為替/金利/流動性/信用の各リスクの一般的な説明

3. 「リスクの説明」章の下書き(抜粋)
  「投資には元本を割り込む可能性があります。価格変動リスクのほか、
   外貨建ての資産では為替変動リスクが生じます。……」

4. 個別に埋める箇所
  [要個別確認:確保額] [要個別確認:見直しの頻度] [要試算:費用の年間概算]

構成の骨格としては使えます。しかし、そのまま提案書にはなりません。この出力に対して人が行った修正は次の4点でした。

  1. 第1章の「目的」を書き直した。AIが書いた「安定的な資産形成を目指します」は、面談で顧客が実際に口にした言葉と違いました。面談記録にあった表現に置き換えています。目的の記述が定型文のままだと、後で「なぜこの提案なのか」を説明できません。
  2. 第4章のリスク説明を増やした。AIの下書きは価格変動・為替の2つで終わっていました。流動性リスクと、取り崩し期に価格が下落した場合の影響(同じ金額を取り崩すために売却口数が増える点)を人が加筆しています。
  3. 第3章から「一般的には〜が選好されます」という記述を削除した。出典がなく、かつ実質的に推奨表現になっていたためです。
  4. 第5章の費用を、社内の商品一覧から人が転記した。AIには費用の数値を書かせていません(プロンプトで[要試算]にさせています)。

この4点は毎回ほぼ同じ場所で発生します。つまりAIの弱点は再現性が高く、チェックリスト化できるということです。次章でその形にします。

AIが作りがちな提案書の4つの問題と、人が必ず直す項目

AIの叩き台に出やすい問題と、人が直す対応 AIの叩き台に出やすい問題 人が必ず直す ① 断定的な将来リターン 「年率◯%が見込めます」と書いてしまう 前提と幅を併記し断定を外す 数値を残すなら出典・前提・不確実性を明記 ② リスクの過小記載 利点は詳しく、損失の説明は数行で終わる 損失の説明を同じ強さで書く リスク章の分量と具体性を利点章と揃える ③ 横並びの定型文 誰に出しても同じ文章になっている 面談記録の言葉で書き直す 目的欄は顧客が実際に述べた表現を使う ④ 目的と配分がつながらない なぜこの構成なのかが読み取れない 各要素の役割を目的に紐づける 「この部分は何のためにあるか」を1文で書く ※4項目はいずれも人が修正する前提の指摘であり、AIに再修正させても検証は必要です。
図3:AIの叩き台に繰り返し現れる4つの問題と、人が必ず行う修正の対応関係。
問題見つけ方(症状)人が行う修正確認の基準
① 断定的な将来リターン「見込めます」「期待できます」「安定的に」を全文検索して1件でもヒットする数値を削除するか、前提・出典・不確実性を併記して断定を外す将来の数値が残る場合は、必ず出典と前提が併記されていること
② リスクの過小記載リスク章の文字数が、方針・利点を書いた章の半分未満損失の可能性・想定される最大の影響・損失が出た場合の対応を加筆リスク章の文字数が利点側の章と同等以上
③ 横並びの定型文直近3件の提案書と並べて、目的欄の文言がほぼ同じ面談記録に出てくる顧客自身の言葉で目的を書き直す目的欄に、面談記録から引用できる語句が2つ以上含まれる
④ 目的と配分がつながらない「なぜこの構成か」を1文で説明できない箇所がある各要素について「何のためにあるか」を目的に紐づけて1文で記述提案書上の全要素に、目的への紐づけが1文ずつある

プロンプト例2:ドラフトの記載上の問題を機械的に洗い出す

チェックリストによる目視の後で、見落としを拾うために使います。渡すのは顧客を識別できる情報をすべて削除・置換したドラフトだけです。置換作業は人が行い、置換漏れがないことを確認してから実行します。

【役割】あなたは、金融機関の提案書の記載を点検するレビュー担当の補助役です。

【目的】以下の提案書ドラフトについて、記載上の問題点のみを指摘する。投資判断の妥当性・内容の良し悪しは評価しない。

【入力資料】提案書ドラフトの本文。顧客を識別できる情報はすべて削除・置換済みで、氏名は[顧客]、金額は[金額]、商品名は[商品]に置換してあります。置換された箇所の中身を推測しないこと。

【対象期間】ドラフトに記載された期間表記をそのまま用いる。
【単位】ドラフトの単位表記をそのまま用い、単位が混在している箇所は指摘対象とする。

【出力形式】表形式で1行1指摘。列は次の4つ。
「該当箇所(原文を20字以内で引用)」「区分」「なぜ問題か」「修正の方向性」
区分は次の6つから必ず1つ選ぶ。
 (1)断定的な将来予測 (2)リスク記載の不足 (3)目的と記載内容の不一致
 (4)定型文で個別性がない (5)単位・数値の不整合 (6)出典が示されていない

【計算方法】ドラフト内に計算結果がある場合は、記載された前提から再計算し、一致しなければ(5)として指摘する。再計算の式を必ず示す。

【禁止事項】
- ドラフトにない情報を補わない
- 商品・配分・運用方針の推奨を書かない
- 「全体として問題ありません」といった総括をしない
- 置換済みの箇所([顧客][金額][商品])の内容を推測しない

【不明情報の処理】判断に必要な前提がドラフトから読み取れない場合は「判断不能:不足している前提は〇〇」と書く。推測しない。

【検算】数値に関する指摘には、再計算の式と結果を必ず添える。

【レビュー項目】最後に、指摘件数を区分別に集計した表を出す。指摘が0件の区分も0と明記する。

説明責任:根拠を後から再現できる状態にする

AIを使ったかどうかにかかわらず、提案の根拠は後から再現できる必要があります。AIを使うと、この再現性が壊れやすくなります。同じプロンプトでも出力が毎回同じとは限らず、記録がなければ「どの版の文章を顧客に渡したのか」が追えなくなるからです。

実務上の対処は単純で、AI出力を成果物としてではなく「入力の一つ」として記録することです。次の8項目を提案書1件ごとに残します。既存の営業記録システムに項目を足せる場合はそこに、難しい場合は案件フォルダにテキストファイルを1つ置くだけでも機能します。

記録項目何を書くか記入例(仮設)
1. 作成日・作成者日付と担当者名2026-08-03/営業第2部 担当者B
2. 使用した環境どの環境で使ったか(社内で定義した環境名)法人契約の管理環境(社内規程 第◯条の対象)
3. 入力した条件文AIに渡した一般化した条件文の全文(箇条書き6行をそのまま貼り付け)
4. AI出力の保存出力の全文と取得日時draft_ai_20260803_1420.txt
5. 人が変更した箇所と理由章ごとに、変更内容と根拠第1章:目的を面談記録の表現に差し替え/第4章:流動性リスクを加筆
6. 参照した一次資料費用・商品情報の出所社内商品一覧(2026-08-01版)、目論見書
7. 最終確認者と確認日誰が最終稿を確認したか課長C/2026-08-03
8. 交付版の特定顧客に渡した版のファイル名と版数proposal_v3_final.pdf(v3)

この記録の目的は、あとから「どの前提で、どのデータで、誰が判断したか」を第三者が辿れるようにすることです。項目3(入力した条件文の全文)を残すことには、副次的な効果もあります。入力ログを定期的に読み返せば、顧客情報が混入していないかを事後に点検できます。混入が見つかった場合は、その時点で社内規程に従った報告が必要になります。組織としての運用ルールづくりはポートフォリオ・ガバナンス投資制限といった既存の枠組みと接続させると、新しい仕組みを一から作らずに済みます。

数値例:提案書1件あたりの工数はどう変わるか(仮設)

「AIで提案書作成が劇的に速くなる」という言説の実態を、仮設の数字で確認します。みなと総合ウェルスパートナーズ(架空のIFA法人)で、提案書1件あたりの工程別所要時間を測定したという設定です。単位はで統一しています。

工程従来(分)AI併用(分)差(分)
① ヒアリング内容の整理40400
② リスク許容度の確認30300
③ 配分案の検討6045−15
④ 商品選定50500
⑤ 提案書のドラフト作成9035−55
⑥ 説明準備(想定問答)4525−20
⑦ 記録・保存2520−5
(追加)AI出力の検証・修正030+30
合計340275−65

検算します。従来の合計は 40+30+60+50+90+45+25 = 340分。AI併用の合計は 40+30+45+50+35+25+20+30 = 275分。差は 340 − 275 = 65分で、削減率は 65 ÷ 340 = 0.191…、すなわち約19%です。月20件を作成する場合、65分 × 20件 = 1,300分となり、60で割ると 1,300 ÷ 60 = 21.67、約21時間40分の削減になります。

この設例が示しているのは3点です。第一に、削減が起きるのは⑤の下書きに集中していること(−55分は削減総額65分の85%に相当します。55 ÷ 65 = 0.846)。第二に、検証工程が新たに30分増えること。AIは「書く時間」を減らしますが「確かめる時間」を増やします。第三に、全体では2割程度の削減に留まること。人が担う工程が多い業務では、これが現実的な水準です。もし「7割削減できる」という試算が出てきたら、検証工程を数えていないか、人が判断すべき工程をAIに任せている可能性を疑ってください。

提案書ドラフトの検証方法

生成AI出力の一般的な検証手順(出典の実在確認→数値の転記確認→計算の再現→論理の整合)については生成AI出力の検証手順で扱っています。ここでは提案書という成果物に固有の検証項目だけを挙げます。上から順に実施すると、手戻りが少なくなります。

  1. 断定表現の全文検索。「見込めます」「期待できます」「安定的」「確実」「必ず」「安心」を検索し、ヒットした箇所をすべて見直します。検索語のリストは社内で共有して固定します。
  2. プレースホルダの残存確認。「[要個別確認」「[要試算」が本文に残っていないかを検索します。1件でも残っていれば未完成です。
  3. リスク章と利点章の分量比。文字数を数え、リスク章が利点側の章より短くないことを確認します。数え方は文字カウント機能で構いません。
  4. 数値の再計算。提案書に残っている数値を、記載された前提から手計算で再現します。再現できない数値は削除するか、出所を明記します。
  5. 面談記録との突合。提案書の「目的」欄と面談記録を並べ、顧客の言葉が反映されているかを確認します。ここが定型文のままだと、③の問題が残っています。
  6. 固有名詞の実在確認。商品名・制度名・数値の出所を、社内の商品一覧や目論見書と1件ずつ照合します。AIが実在しない商品名やファンド名を生成する場合があるため、この照合は省略できません。
  7. 入力ログの事後確認。実際にAIへ入力した内容を読み返し、一般化した条件文から逸脱した情報が含まれていないかを確認します。
  8. 交付版の特定。顧客に渡したファイルと、保存した最終稿が同一であることを版数とファイル名で確認します。

これらは1件あたり合計で20〜30分程度の作業です。前掲の設例で「AI出力の検証・修正」に30分を計上しているのは、この工程を想定しています。

機密情報・個人情報の注意

本記事の運用は「顧客に紐づく情報をAIに入力しない」ことを前提に組み立てています。個人情報保護委員会は、個人情報取扱事業者が生成AIサービスにプロンプトとして個人情報を含む内容を入力する場合、特定した利用目的の達成に必要な範囲内であることを十分に確認するよう注意喚起しています。入力してよいかどうかの判断は法令解釈を伴うため、本記事では行いません。所属先の法務・コンプライアンス部門の判断に従ってください。情報区分の設計と社内規程の作り方については生成AIに入れてよい情報・いけない情報を参照し、本記事では顧客情報という文脈に限定した運用だけを扱っています。

よくある失敗

  1. 「匿名化したから大丈夫」と考えて、保有明細をそのまま貼り付ける。氏名を消しても、保有商品の組み合わせ・購入時期・金額の並びは特定につながる情報を含みます。属性を粗くしても、組み合わせの珍しさは残ります。実額と明細は入力しない、という線を動かさないのが安全です。
  2. AIに「最適な配分を教えて」と聞いてしまう。返ってくるのはもっともらしい比率ですが、根拠は学習データ上の一般論であり、その顧客のための根拠ではありません。しかも出力に出典がないため、後から説明できません。AIには論点を出させ、比率は人が決めます。
  3. AIの文章をそのまま提案書に貼り、断定表現を見落とす。「安定的な収益が期待できます」といった表現は、AIの下書きに高い頻度で現れます。検索語リストを固定して機械的に潰す運用にしないと、必ず漏れます。
  4. 検証時間を工数に数えず、削減効果を過大に報告する。導入効果の報告で「作成時間が6割減」と出したものの、検証工程が計上されていなかった、というのは典型的なパターンです。前掲の設例のように、増える工程も同じ表に載せてください。
  5. 記録を残さないまま運用を始める。後から「この提案書のどこまでAIが書いたのか」を問われたときに答えられません。記録様式は運用初日から使い始めます。

実務チェックリスト

  • 提案7工程それぞれについて、AIの適用区分(AI可/AI補助+人が確定/人のみ)を社内で決めて文書化した
  • AIに入力してよい情報の一覧と、入力してはいけない情報の一覧を、具体例つきで作成した
  • 利用してよいAIの環境(一般向けサービスか、法人契約の管理環境か)を社内規程で特定した
  • AIに渡す「一般化した条件文」の書式を定め、固有名詞・実額を書かない旨を明記した
  • 条件文を書いた後、固有名詞・実額・エピソードが混入していないかを本人が読み返す手順を入れた
  • 提案書の下書き用プロンプトに、推奨表現と断定的な将来予測の禁止を明記した
  • 不足情報をAIに質問させず、プレースホルダで返させる設計にした
  • 断定表現の検索語リスト(「見込めます」「期待できます」等)を社内で共有・固定した
  • リスク章と利点章の分量比を確認する手順を検証工程に入れた
  • 提案書に残る数値をすべて手計算で再現できることを確認した
  • 商品名・費用は社内の商品一覧から人が転記し、AI出力を使っていないことを確認した
  • 提案書の「目的」欄が面談記録の言葉で書かれていることを確認した
  • 記録様式8項目(作成者・環境・条件文全文・出力・変更箇所と理由・参照資料・最終確認者・交付版)を保存した
  • 入力ログを定期的に読み返し、顧客情報の混入がないかを点検する担当と頻度を決めた
  • AI活用の範囲と限界を、顧客から質問された場合にどう説明するかを社内で決めた

日本のウェルスマネジメント実務での留意点

海外の資産運用向けAI活用の記事を読むときは、制度の前提が異なることに注意してください。米国では投資顧問業者(RIA)に信認義務(fiduciary duty)が課され、証券会社の勧誘行為には別途 Regulation Best Interest という枠組みが適用されるとされています。日本の適合性の原則や説明に関する規律とは、義務の性質も適用範囲も異なります。米国向けの「AIでアドバイザー業務をどこまで自動化できるか」という議論の結論を、そのまま日本の実務に持ち込むことはできません。本記事は米国制度の解説を目的としておらず、その詳細は範囲外です。

日本国内の動向としては、金融庁が2026年3月3日に「AIディスカッションペーパー(第1.1版)」を公表しています。これは2025年3月公表の第1.0版の更新版で、2025年を「AIエージェント元年」と位置づけ、AIエージェントに関する章が新設されています。金融機関等へのアンケート・ヒアリングを踏まえた初期的な論点整理という位置づけであり、規制そのものではありませんが、当局がどの論点を重視しているかを知るうえで有用です。あわせて、総務省・経済産業省の「AI事業者ガイドライン(第1.2版)」(2026年3月31日)が、AI開発者・提供者・利用者それぞれの取り組み事項を示しています。日本銀行も「金融システムレポート別冊」として金融機関における生成AIの利用状況とリスク管理を扱ったレポートを公表しています。

国内の金融機関が実際にどのような領域で生成AIを導入しているかについては、公表事例をまとめた日本の金融機関の生成AI導入事例を参照してください。本記事では事例の再掲は行いません。なお、モデルを使った配分の自動生成やスコアリングに踏み込む場合は、モデルの検証・承認・継続モニタリングといった論点が別に発生します。AIを用いたモデリングを業務に組み込む際は、社内のモデル管理の枠組みに乗せられるかを先に確認してください。

よくある質問(FAQ)

Q. 顧客情報を入力しないなら、AIを使う意味はあるのでしょうか。
A. 提案書の骨格づくりと定型部分の下書きに限れば、実測ベースで工数は減ります(前掲の仮設例では1件あたり65分、約19%)。ただし「AIが提案を考えてくれる」ことは期待できません。AIが減らすのは書く時間であって、考える時間ではない、と割り切ると使いどころが定まります。

Q. 社内で法人契約している管理環境なら、顧客の保有明細を入れてもよいのでしょうか。
A. 本記事では判断できません。契約条件・社内規程・利用目的の特定状況によって扱いが変わるため、所属先の法務・コンプライアンス部門にご確認ください。個人情報保護委員会は、生成AIサービスへ個人情報を含む内容を入力する場合には特定した利用目的の達成に必要な範囲内であることを十分に確認するよう注意喚起しています。少なくとも「管理環境だから自動的に問題ない」とは言えません。

Q. AIが作った提案書だと顧客に伝える必要はありますか。
A. 一律の答えはなく、社内規程と各社の方針によります。本記事が勧めているのは、伝える・伝えないの判断以前に、聞かれたときに事実として説明できる状態を作っておくことです。記録様式8項目を残していれば、「構成の下書きにAIを使い、目的・配分・商品・費用の記載は担当者が作成し、上長が確認した」と具体的に説明できます。

まとめ

ウェルスマネジメントで生成AIを使う場合、判断の分かれ目は「性能」ではなく「どこで線を引くか」です。提案プロセス7工程のうち、AIが単独で担えるのは提案書の骨格づくりだけで、残る6工程は人が確定するか、人だけで行う領域です。顧客の氏名・口座番号・保有明細・家族構成・健康状態・年収の実額は入力せず、一般化した条件で叩き台を作り、人が個別事情を当てはめ、人が最終確認する——この3層を守れば、AIの利用範囲を明確に説明できます。

そして、AIを使う以上は記録が要ります。どの前提で、どのデータで、誰が判断したか。この3つが後から辿れるようにしておくことが、提案業務における説明責任の実務的な形です。工数削減は結果としてついてくるもので、前掲の設例が示すように2割程度が現実的な水準です。誇張された削減率を目標に置くと、削られるのはたいてい検証工程になります。

再度お断りします。本記事は教育目的の一般的な解説であり、投資助言ではありません。記事中の条件・数値はすべて架空のモデルケースであり、特定の商品・配分・運用方針を推奨するものではありません。法令の適用可否についても判断を行っていません。実務への適用は、所属先の法務・コンプライアンス部門および専門家にご確認ください。

出典・参考(2026-08-03確認)

※本記事は教育目的の一般的な解説であり、法務・税務・会計・投資に関する助言ではありません。実際の判断は専門家にご確認ください。設例は理解のための仮設例です。AI製品の仕様・料金は変更されることがあるため、利用前に各社の公式情報をご確認ください。