対話データRAG構築ガイド：商談記録をAIに活用する実装手順

#対話データをAIの知識基盤に変える

企業に蓄積された商談記録や面談データは、そのままでは検索や活用が困難なフォーマットで保存されています。長時間の音声書き起こしテキストから必要な情報を見つけるには膨大な時間がかかり、多くの場合、貴重な知見が活用されないまま埋もれています。

RAG（検索拡張生成）は、この課題を解決する有力なアプローチです。商談記録をベクトルデータベースに格納し、大規模言語モデルと連携させることで、「この顧客が過去に挙げた懸念事項は何か」「競合製品との比較で最も効果的だった訴求は何か」といった問いに、自社の対話データに基づいた正確な回答を生成できるようになります。

本記事では、汎用的なRAGではなく、商談・面談の音声書き起こしデータに特化したRAG構築の実装手順を解説します。

#対話データの前処理：品質の8割はここで決まる

対話データのRAGにおいて、前処理の品質が最終的な生成精度の8割を決めるといっても過言ではありません。汎用テキストとは異なり、対話データには話者の識別、口語表現の正規化、文脈の保持といった特有の課題があります。

**話者分離（スピーカーダイアライゼーション）**は最も重要な前処理です。「誰が何を言ったか」を正確に識別できなければ、「顧客が挙げた課題は何か」「営業担当がどのように回答したか」といった検索が不可能になります。話者分離の精度は、後続のすべての処理に影響します。

タイムスタンプの付与により、発言の時間的な順序と位置を記録します。「商談の後半で顧客が述べた懸念」といった時間軸を含む検索を可能にするために必要です。

メタデータの付与として、各対話データに以下の情報を紐づけます。商談日時、顧客名・企業名、参加者、商談フェーズ（初回、提案、クロージング等）、関連する案件ID（SFA/CRMとの連携用）です。メタデータはフィルタリング検索に不可欠であり、「特定の業界の顧客との商談のみ」「クロージングフェーズの商談のみ」といった絞り込みを可能にします。

口語表現の正規化では、フィラー（えー、あのー、まあ）の除去、言い直しの整理、略語の正式名称への変換を行います。ただし、過度な正規化は発言のニュアンスを失わせるため、意味を変えない範囲に留めます。

#チャンキング戦略：発話ターン単位 vs トピック単位

チャンキングとは、長い対話データを検索に適したサイズの断片（チャンク）に分割する処理です。対話データのチャンキングには、主に2つの戦略があります。

発話ターン単位のチャンキングは、話者の発言交代（ターン）を単位としてチャンクを作成します。「顧客の質問→営業の回答」をペアにすることで、QA形式の検索に適したチャンクが生成されます。「顧客が予算について質問した場面」「競合製品との違いを説明した場面」といった検索に有効です。

トピック単位のチャンキングは、対話の話題の切り替わりを検出し、同一トピックの発言をまとめてチャンクを作成します。「予算に関する議論全体」「導入スケジュールに関する議論全体」といった、トピック全体を俯瞰する検索に有効です。要約や分析のユースケースに向いています。

実務上は、両方の戦略を併用し、ユースケースに応じて使い分けるのが最も効果的です。発話ターン単位のインデックスとトピック単位のインデックスを別々に作成し、検索クエリの性質に応じて切り替えます。

チャンクサイズの目安は、発話ターン単位で200から500トークン、トピック単位で500から1500トークンです。

#エンベディングとベクトルDB選定

チャンキングしたデータを検索可能にするために、エンベディング（ベクトル化）とベクトルデータベースの選定が必要です。

エンベディングモデルの選定では、日本語の対話データに対応したモデルを選ぶことが精度に直結します。OpenAIのtext-embedding-3-small/largeは汎用性が高く導入が容易です。多言語対応モデル（Cohere embed v3等）は日本語の口語表現にも対応しています。日本語特化モデル（例: multilingual-e5-large）は、日本語の対話データに最適化されたパフォーマンスが期待できます。

エンベディングモデルの選定は、実際のデータでベンチマークテスト（正解付きの検索クエリでの精度比較）を実施して判断することを推奨します。

ベクトルデータベースの選定は、データ規模、運用要件、コストの3軸で判断します。Pineconeはフルマネージドでスケーラビリティに優れ、運用負荷が低い選択肢です。Weaviateはハイブリッド検索（ベクトル検索＋キーワード検索）の統合が容易です。pgvector（PostgreSQL拡張）は既存のPostgreSQL環境に追加でき、導入コストを抑えられます。Azure AI Searchはエンタープライズ環境でのセキュリティ要件に対応しやすく、Microsoft製品との統合が容易です。

#検索クエリ設計：ハイブリッド検索の実践

RAGの検索精度を高めるために、セマンティック検索とキーワード検索を組み合わせたハイブリッド検索を推奨します。

セマンティック検索は、クエリの意味的な類似性に基づいてチャンクを検索します。「予算に関する懸念」というクエリに対して、「コスト面が心配」「投資対効果を示してほしい」といった、言い回しは異なるが意味的に関連するチャンクを検索できます。

キーワード検索（BM25等）は、特定のキーワードの出現に基づいてチャンクを検索します。固有名詞（企業名、製品名）や専門用語の検索に強みがあります。

ハイブリッド検索では、セマンティック検索のスコアとキーワード検索のスコアを重み付けして統合します。一般的な重み配分は、セマンティック検索70%、キーワード検索30%ですが、対話データの特性（固有名詞の多さ等）に応じて調整します。

メタデータフィルタリングも重要な検索機能です。「2025年下半期の製造業の顧客との商談」のように、メタデータで対象を絞り込んでからベクトル検索を実行することで、ノイズを大幅に削減できます。

#生成品質の評価：3つの指標

RAGシステムの品質は、「忠実性」「関連性」「網羅性」の3つの指標で評価します。

**忠実性（Faithfulness）**は、生成された回答が検索されたチャンクの内容に忠実であるかを評価します。ハルシネーション（検索結果に含まれない情報の捏造）がないかを検証する指標です。対話データのRAGでは、「顧客がそのように発言した」と生成されたが、実際には営業担当の発言だった、といった話者の取り違えも忠実性の問題です。

**関連性（Relevance）**は、検索されたチャンクとユーザーのクエリの関連度を評価します。関連性の低いチャンクがLLMに入力されると、回答の品質が低下します。

**網羅性（Coverage）**は、回答がクエリで求められた情報をどの程度網羅しているかを評価します。「この顧客のすべての懸念事項を列挙してください」というクエリに対して、一部の懸念しか含まれていない場合は網羅性が低いと判断されます。

評価は定量的な自動評価（RAGAS等のフレームワーク）と、ドメインエキスパート（営業マネージャー等）による定性的な評価を組み合わせて実施します。

#本番運用に向けたセキュリティ考慮

対話データには顧客情報や商談内容など、機密性の高い情報が含まれます。RAGシステムの本番運用にはセキュリティの考慮が不可欠です。

アクセス制御として、検索対象のデータに対する権限管理を実装します。営業担当者は自分の担当案件の商談データのみ検索可能、マネージャーはチーム全体の商談データを検索可能、といったロールベースのアクセス制御が必要です。

データの暗号化は、ベクトルデータベースに格納されるデータの暗号化（保存時・転送時）を確実に実施します。エンベディングモデルへのデータ送信時もTLS暗号化が必須です。

監査ログとして、誰がいつどのようなクエリを実行し、どのデータにアクセスしたかを記録します。

#まとめ

対話データに特化したRAGの構築は、前処理の品質、チャンキング戦略の選択、エンベディングとベクトルDBの適切な選定、ハイブリッド検索の実装、そして生成品質の継続的な評価という5つのステップで進めます。特に前処理（話者分離、メタデータ付与）の品質が最終的な生成精度に最も大きく影響します。

aileadは、対話データを構造化して蓄積する対話データAIプラットフォームです。話者分離、BANT抽出、トピック分類などの前処理済みデータを提供し、RAG構築の高品質なソースとなります。Salesforce連携（カスタムオブジェクト対応）によりCRMデータとの統合も実現。400社以上の企業が活用するaileadの詳細は、デモでご確認ください。