課題：「宝の山」がテキストのまま眠っている
金融・保険業では、顧客との面談記録が膨大に蓄積されています。
- 担当FP（ファイナンシャルプランナー）が毎日記録する顧客面談議事録（Word・紙）
- コールセンターの通話記録テキスト
- 市場分析に使うニュース記事・アナリストレポート（PDF）
これらはすべて**LV1（生データ）**です。テキストとして存在はしていますが、AIが構造的に活用できる状態ではありません。
なぜ今、AI活用が急務か
- コンプライアンス強化：金融規制（FATF・マネロン対策等）で、面談記録の構造化・追跡可能性の要件が高まっている
- 人材不足：ベテランFPのノウハウを後継者に伝えるためのナレッジ化が必要
- 顧客ニーズの変化：パーソナライズされた提案には、過去面談履歴のAI分析が不可欠
AI-Readyレベル診断
| データ種別 | 現状レベル | 問題点 | |---|---|---| | 顧客面談記録 | LV1（Word・紙） | 構造化されておらず検索・分析困難 | | 通話記録 | LV1（テキスト化はされている） | ラベルなし・構造なし | | ニュース・レポート | LV1（PDF散在） | 参照はできるがAI入力に不適 | | 用語・コンプライアンス定義 | LV0〜1 | 「要注意顧客」の定義が担当者依存 |
体制面：誰が何をするか
このケースは「コンプライアンス部門との連携」が技術実装の前提条件です。
| 役割 | 人数 | 求めるスキル | 重要度 | |---|---|---|---| | コンプライアンス担当 | 1名 | 規制要件・内部統制ルールを把握している担当者 | ★★★（必須） | | データスチュワード | 1名 | データ辞書・アノテーション定義を管理。法務と技術の橋渡し役。 | ★★★ | | ITエンジニア/データサイエンティスト | 1〜2名 | Python・LLM API呼び出しの基礎知識 | ★★ | | 現場FP（業務知識提供） | 数名 | アノテーション設計の業務要件を提供 | ★★ |
データスチュワードの役割が特に重要
「要注意ワード」「コンプライアンス上の重要事項」の定義はコンプライアンス部門が決定し、 データスチュワードがラベル定義書として文書化します。 この定義なしにLLMに学習させると、規制対応に使えない結果になります。
技術面：何のツールで・どの手順で
ステップ1：アノテーション設計（ラベル定義）（第1〜4週）
コンプライアンス担当・データスチュワード・現場FPでラベル定義書を作成します。
抽出すべき情報の例：
顧客ニーズ（退職準備・教育費・住宅購入など）リスク許容度（低・中・高）コンプライアンスアラート（投資勧誘禁止事項・マネロン疑義フラグ）提案商品（保険・投信・個別株など）
このラベル定義書が「AIへの指示書」になります。
ステップ2：LLMによる自動アノテーション（第5〜8週）
GPT-4等のLLM APIを使って、面談記録テキストから定義したラベルを自動抽出します。
# アノテーション自動化の概念コード
prompt = f"""
以下の面談記録から、指定された項目を抽出してJSON形式で返してください。
抽出項目:
- customer_need: 顧客のニーズ（退職準備/教育費/住宅購入/その他）
- risk_tolerance: リスク許容度（低/中/高）
- compliance_flag: コンプライアンス上の注意事項（なし/要確認/要報告）
面談記録:
{meeting_text}
"""
result = llm_client.complete(prompt)
重要: 自動アノテーション後は、コンプライアンス担当者がサンプルレビューを行い、精度を確認します。
ステップ3：データ辞書とDB構築（第9〜12週）
DBMLでアノテーション済みデータのスキーマを設計します。
Table customer_meetings {
meeting_id varchar [pk]
customer_id varchar [ref: > customers.id]
meeting_date date
fp_id varchar [note: "担当FP ID"]
customer_need varchar [note: "顧客ニーズ（アノテーション済）"]
risk_tolerance varchar [note: "リスク許容度（低/中/高）"]
compliance_flag varchar [note: "コンプライアンスフラグ"]
raw_text_id varchar [note: "元テキストへの参照（個人情報保護対応）"]
}
個人情報保護のため、生テキストとアノテーション済み構造データは分離して管理します。
ステップ4：検索・分析基盤とAI連携（第13〜16週）
- コンプライアンスアラートの自動検出・エスカレーションフローを構築
- FPが「この顧客に類似したニーズを持つ他の顧客はいますか？」と自然言語で検索できる機能
- 管理職向けダッシュボード：面談品質の均質化・コンプライアンス遵守率のモニタリング
効果（After）
| 指標 | Before | After | |---|---|---| | コンプライアンスチェック | 管理職が全面談記録を目視確認（膨大な工数） | AIが自動フラグ。要確認案件のみ人間がレビュー | | 顧客ニーズ分析 | 担当FPの記憶・感覚に依存 | 全面談記録からのAI分析でインサイト自動抽出 | | ベテランFPのノウハウ継承 | 退職時にノウハウが消える | 面談記録から「優良FPの対応パターン」を抽出・学習素材化 | | 規制対応レポート | 担当者が手動で集計・作成 | 構造化データから自動生成 |
よくある質問
Q：個人情報保護法・GDPR等の観点で問題はありませんか？
A：面談記録のAI処理には、利用目的の明示と適切な同意取得が前提です。アノテーション設計の段階でコンプライアンス担当と連携し、仮名化・匿名化処理の方針を組み込みます。社内LLM（オンプレミスまたはプライベートクラウド）の利用も検討に値します。
Q：AIが間違ったコンプライアンスフラグを立てた場合、どう対処しますか？
A：AI判定は「一次スクリーニング」として位置づけ、最終判断は必ず人間が行う設計を推奨します。AIが見落とした場合に備えた「フォールバックチェック」の仕組みも設計に含めます。AIの精度は継続的なフィードバックで改善されます。