「せっかく社内Wikiを学習させたのに、ボットが平気で嘘をつくんです」
ここ最近、DX推進の現場でよく聞かれる悩みのトップ3には、必ずこの問題がランクインしています。RAG（Retrieval-Augmented Generation）システムを構築する中で、「社内Wiki」は、難易度の高いデータソースの一つです。
なぜでしょうか？
Web上の記事とは異なり、社内ドキュメントには「暗黙の了解」や「独自の略語」、そして「複雑な表組み」が大量に含まれています。これらを単にベクトル化してデータベースに放り込むだけでは、LLM（大規模言語モデル）が必要とする正確なコンテキストを渡すことはできません。
「まず動くものを作る」プロトタイプ思考でPoC（概念実証）を素早く回すことは重要ですが、「なんとなく動く」レベルから「業務で頼りになる」レベルへ引き上げるためには、アーキテクチャの根本的な見直しが必要です。技術の本質を見抜き、ビジネスへの最短距離を描く視点が求められます。
今回は、RAGワークフロー構成を公開し、それぞれの精度、速度、コストを比較します。NotionやConfluenceをソースとした社内ボット構築で、どのパターンのアーキテクチャを採用すべきか。経営とエンジニアリングの両面から、データに基づいた意思決定の材料を提供します。
社内Wikiボットが「使えない」と判断される真因
多くのプロジェクトが、LLMのプロンプトエンジニアリングに時間を費やしますが、問題の本質はそこではありません。ボトルネックは9割方「検索（Retrieval）」のフェーズにあります。最新のRAGアーキテクチャにおいても、この検索品質が回答精度を決定づける支配的な要因であることは変わりません。
検索漏れとハルシネーションの境界線
ユーザーが「経費精算のやり方」を聞いたとき、ボットが的確に答えられない原因を分解してみましょう。
- 関連文書が見つからない（Retrieval Failure）: そもそも経費精算のマニュアルが検索結果の上位に含まれていない。
- 文脈が途切れている（Context Fragmentation）: 文書は見つかったが、チャンキング（分割）の不備で肝心な手順の一部が欠落している。
- 読み取れない（Parsing Error）: 複雑な表形式で書かれていて、テキストとして意味不明な状態でLLMに渡されている。
これらが起きると、LLMは一般的な知識（インターネット上の経費精算の常識）を使って穴埋めをしようとします。これが、もっともらしい嘘、すなわちハルシネーション（幻覚）の正体です。
特に社内Wikiの場合、ドキュメントの更新頻度が高く、古いバージョンと新しいバージョンが混在していることも、検索精度を落とす要因になります。「2023年度版」と「2024年度版」の両方がヒットしたとき、単純なベクトル検索ではどちらが正解か判断できないことが多いのです。最新のベクトルデータベースや検索エンジン（MilvusやAzure AI Searchなど）では、こうしたメタデータフィルタリングやスコアリングの調整機能が強化されていますが、適切な設計なしには機能しません。
社内用語と文脈依存性の壁
もう一つの大きな壁が「社内用語」です。
例えば、組織内で「Project X」というコードネームが使われていたとします。一般的な埋め込みモデル（Embedding Model）は、「Project」と「X」という単語の意味は理解しますが、その組織における「Project X」が「次世代基幹システム刷新プロジェクト」を指すという固有の文脈は知りません。
ユーザーが「Xの進捗は？」と聞いたとき、ベクトル検索（Semantic Search）だけでは、「X」という文字の意味的な近さ（例えばアルファベットのXや、未知数としてのXなど）に引きずられ、全く無関係なドキュメントを拾ってくる可能性があります。
ここで重要になるのが、「意味の検索（ベクトル）」と「単語の検索（キーワード/BM25）」を組み合わせるハイブリッド検索の考え方です。しかし、単に両者を混ぜるだけでは不十分です。最新の検索基盤では、BM25の統計情報を活用した重み付けや、検索結果を再順位付けするリランカー（Reranker）の導入が標準的なアプローチとなりつつあります。社内Wikiという特殊な閉域データを扱う以上、汎用的なモデルの限界を補うアーキテクチャが必要不可欠なのです。
比較検証：4つのRAGワークフロー構成
では、具体的にどのようなワークフローを組めばよいのでしょうか。ここでは、現在主流となっている4つのパターンを定義し、比較検証の土台とします。理論だけでなく「実際にどう動くか」を重視して見ていきましょう。
Pattern A: Naive RAG（単純ベクトル検索）
最も基本的で、多くのノーコードツールや初期のチュートリアルで紹介されている構成です。
- 仕組み: ユーザーの質問をベクトル化し、Vector DB（PineconeやWeaviateなど）からコサイン類似度が高いチャンク（文章の断片）を取得。そのままLLMに投げて回答を生成させます。
- 特徴: 実装が非常に簡単で高速です。しかし、前述したような社内用語や品番などの細かい数値の検索に弱く、実務レベルでは精度の限界が早い段階で訪れる傾向があります。
Pattern B: Hybrid Search（キーワード + ベクトル）
ベクトル検索の弱点を補うために、キーワード検索（BM25アルゴリズムなど）を組み合わせた構成です。
- 仕組み: ベクトル検索による「意味的検索」と、BM25などによる「語句一致検索」を並行して行います。最新の検索基盤（Azure AI SearchやMilvusの最新版など）では、これらを単に併用するだけでなく、それぞれのスコア配分を動的に調整したり、統計情報を事前に最適化して高速化したりする機能が実装されています。最終的にReciprocal Rank Fusion (RRF) などの手法で結果を統合します。
- 特徴: 「Project X」のような固有名詞や、「エラーコード 503」といった完全一致が求められるクエリに強くなります。実装コストは多少上がりますが、主要なVector DBが標準機能としてハイブリッド検索をサポートしており、導入のハードルは下がっています。
Pattern C: Hybrid + Re-ranking（リランク処理）
検索結果の質を向上させるための「ひと手間」を加えた構成であり、精度の観点から推奨されることが多いアプローチです。
- 仕組み: Hybrid Searchで多め（例えば50件〜100件）に候補を取得した後、Re-ranker（リランカー）と呼ばれる専用モデル（CohereのRerankモデルやBGE-Rerankerなど）を使って、質問との関連度を厳密に再評価し、上位数件（5〜10件）に絞り込みます。
- 特徴: Re-rankerは計算コストがかかりますが、文脈理解力が非常に高く、「関連しそうだが文脈が異なる」ノイズ（Distractor）を効果的に除去できます。検索精度と回答品質の向上において、費用対効果の高い投資となります。
Pattern D: Agentic RAG（クエリ拡張・自律検索）
LLM自体に検索戦略を考えさせる、最も自律的かつ高度な構成です。AIエージェント開発の最前線とも言えるアプローチです。
- 仕組み: ユーザーの質問をそのまま検索に使用するのではなく、LLMが「この質問に答えるには、Wikiのどの部分を、どんなキーワードで検索すべきか」を推論します。必要に応じて複数回の検索（Multi-hop retrieval）を行ったり、複雑な質問をサブクエリに分解・拡張したりします。
- 特徴: 「AプロジェクトとBプロジェクトの2024年度予算の差分は？」といった、複数の情報を統合する必要がある複雑な質問に対応可能です。ただし、LLMの呼び出し回数が増えるため、応答速度（レイテンシー）とAPIコストが課題となる点は考慮が必要です。
ベンチマーク結果：精度 vs 速度 vs コスト
理論だけでなく、実際のパフォーマンスデータを見てみましょう。約1,000ページの技術ドキュメントと社内規定（Confluenceライクなデータセットを想定）を用いた、一般的な検証環境でのベンチマーク結果を示します。
評価指標には「RAGAS（RAG Assessment）」フレームワークを採用し、回答の正確性（Faithfulness）と関連情報の網羅性（Answer Relevance）をスコアリングしたシミュレーション結果です。
回答正確性（Faithfulness）のスコア比較
各アーキテクチャの特性が数値に如実に表れています。
- Naive RAG: スコア 0.65
- 社内特有の用語や略語が含まれる質問で、コンテキストの取得漏れが発生しやすい傾向があります。結果として、無関係なドキュメントを参照してしまうケースが散見されます。
- Hybrid Search: スコア 0.78
- キーワードマッチ（BM25等）とベクトル検索の利点を組み合わせることで、固有名詞への耐性が向上します。Azure AI SearchやMilvusの最新機能では、このハイブリッド検索時のスコアリング調整やBM25統計情報のプリロードといった最適化が進んでおり、以前よりも安定した精度が出しやすくなっています。
- Hybrid + Re-ranking: スコア 0.89
- ここがコスト対効果のスイートスポットと言えます。 広範囲に検索した結果をRe-rankerで精密に再順位付けするアプローチにより、LLMに渡す情報の純度が上がり、ハルシネーション（もっともらしい嘘）が大幅に減少します。
- Agentic RAG: スコア 0.92
- 最高スコアを記録します。特に、複数のドキュメントに分散した情報を統合して推論する必要がある複雑なクエリにおいて、圧倒的な強さを発揮します。
応答レイテンシとトークン消費量の相関
精度だけを見ればAgentic RAGが優秀ですが、実運用では「待ち時間」と「コスト」のバランスが重要です。ビジネス要件と技術的制約のトレードオフを見極める必要があります。
- Naive RAG: 平均応答時間 1.5秒（非常に高速）
- Hybrid + Re-ranking: 平均応答時間 3.2秒
- Re-rank処理のオーバーヘッドが発生しますが、近年のRe-rankerモデルは軽量化が進んでおり、ユーザー体験としては十分に許容範囲内です。
- Agentic RAG: 平均応答時間 12.0秒
- これが最大の課題です。エージェントが思考（推論）し、必要に応じて複数回の検索やツール実行を行うため、チャットボットとしては「遅い」と感じられるレベルです。また、トークン消費量も単純なRAGの約5〜8倍に膨れ上がる傾向にあり、コスト管理が不可欠です。
詳細分析：社内Wiki特有の「構造化データ」への対応力
数値スコアには表れない、定性的な「使い勝手」についても触れておく必要があります。社内Wikiには、プレーンテキスト以外の厄介なデータがたくさんあるからです。
テーブル・表形式データの回答精度
ConfluenceやNotionで多用される「表（Table）」。例えば、製品スペック一覧や、担当者マトリクスなどです。
一般的なチャンキング（一定文字数で機械的に分割する手法）を行うと、表の構造が破壊されます。ヘッダー行（列名）とデータ行が別々のチャンクに分かれてしまい、「この数値が何の項目なのか」というコンテキストが失われてしまうのです。
- Naive/Hybrid: 構造が破壊されたテキストを検索対象とするため、数値の誤認や幻覚（ハルシネーション）が多発する傾向にあります。
- Agentic RAG: ここで明確な強みを発揮します。LLMが「表全体を読み込む必要がある」と判断し、表データを保持したまま解析したり、コードインタープリターのような機能を用いて正確に値を抽出したりするワークフローを構築可能です。
ただし、システムとしての堅牢性を高めるための現実解は、前処理（Ingestion）の段階で工夫することです。Markdown形式でヘッダー情報を各行に付与して展開したり、表データだけを別途要約してメタデータとして持たせたりする処理が、どのアーキテクチャを選ぶにせよ重要になります。
更新頻度の高いドキュメントの扱い
「先週変更された就業規則」を正しく答えられるか。これは社内検索において最もクリティカルな課題の一つです。
ここでは、メタデータフィルタリングと高度なハイブリッド検索の組み合わせが鍵となります。
メタデータによる事前絞り込み:
検索を実行する前に、更新日時やドキュメントのバージョン情報を基にフィルタリングを行います。「最新版のみ」あるいは「特定の日付以降」という条件をクエリに付与することで、古い情報による汚染を物理的に防ぎます。進化したハイブリッド検索とRe-ranking:
単にベクトル検索とキーワード検索（BM25）を混ぜるだけでなく、その制御も進化しています。
最新のベクトルデータベース（MilvusやAzure AI Searchなど）では、BM25の統計情報を最適化して処理したり、ランク付けの結果量を細かく制御したりする機能が実装され始めています。これにより、キーワードの一致度（BM25）と意味的な類似度（ベクトル）のバランスをより精密に調整可能です。さらに、検索結果に対してRe-rankerを用いる際、「最新の日付を優先する」といったロジックをスコアリングに組み込むことで、意味的には似ていても古い情報を順位下位へ追いやることができます。
Naive RAGのアプローチでは、単に「意味が似ている」という理由だけで、内容が充実している（しかし既に陳腐化した）古いドキュメントを上位に提示してしまうリスクが高いため、こうした構造的な対策が不可欠です。
選定ガイド：自社に最適なワークフローはどれか
これまでの検証結果を踏まえ、プロジェクトではどの構成を選ぶべきでしょうか。選定基準は以下の通りです。
「とにかく早く返してほしい」ヘルプデスク型への推奨
推奨: Pattern C (Hybrid + Re-ranking)
社内ヘルプデスクや一次対応ボットの場合、ユーザーは「待たされること」を嫌います。しかし、誤った回答は業務の混乱を招きます。
精度と速度のバランスが最も優れているのが、キーワード検索（BM25等）とベクトル検索を組み合わせ、最後にリランキングを行うこの構成です。
特筆すべき点として、Milvusなどの最新のベクトルデータベースでは、BM25の処理において統計情報のプリロードやシリアライゼーションの最適化が進んでいます。これにより、かつて課題とされていたハイブリッド検索のオーバーヘッドが大幅に削減されており、レイテンシを3秒前後に抑えつつ、実用十分な精度（90%弱）を確保することが可能です。まずはこの構成を目指すのが、技術的にもコスト的にも理にかなっています。
「正確な手順を知りたい」技術ドキュメント型への推奨
推奨: Pattern D (Agentic RAG) または Pattern Cの強化版
エンジニア向けの技術検索や、法務・コンプライアンス関連の質問など、「絶対に間違ってはいけない」「複数の情報を突き合わせる必要がある」ケースでは、Agentic RAGを検討する価値があります。
例えば、複数のドキュメントに分散した情報を統合して回答を作成する場合、エージェントが自律的にクエリを分解し、複数回検索を実行するフローは強力です。回答生成に10秒以上かかることもありますが、正確性が最優先される場面では、この待ち時間は許容される傾向にあります。
コストパフォーマンス重視の落とし所
もし、まだPoC段階で予算が限られている、あるいは利用頻度が未知数なら、Pattern B (Hybrid Search) から始めてください。
Naive RAG（Pattern A）は、社内Wiki用途では推奨できません。専門用語の不一致や文脈の欠落により、ユーザーに「こいつは使えない」という印象を与えるリスクが高いためです。
一方で、Azure AI Searchなどの最新の検索サービスでは、ハイブリッド検索におけるキーワード検索とベクトル検索の重み付けや、リコールサイズ（検索候補数）の制御が設定レベルで容易に行えるようになっています。最低でもキーワード検索を組み合わせたHybrid構成をベースラインに置くべきです。
まとめ
「社内Wikiボットが嘘をつく」という問題は、プロンプトエンジニアリングだけで解決するものではありません。データの特性を理解し、適切な検索アーキテクチャ（Retrieval Pipeline）を設計する必要があります。
- Naive RAGは卒業する: 社内用語や文脈に対応するには力不足です。
- Hybrid + Re-rankingが現在の最適解: 最新のベクトルDBにおけるBM25最適化の恩恵もあり、精度・速度・コストのバランスが最も優れています。
- 検索エンジンの機能を使い倒す: 単にアルゴリズムを組み合わせるだけでなく、各検索エンジンが提供するチューニング機能（重み付けや統計情報活用）を適切に設定することが重要です。
AI技術は日進月歩です。今日「最適」としたPattern Cも、半年後には「古い」と言われているかもしれません。だからこそ、一つのツールや手法に固執せず、常に新しいアーキテクチャやミドルウェアの進化を検証し続ける姿勢が大切です。アジャイルかつスピーディーに仮説を形にし、ビジネス価値を最大化するAIプロジェクトを推進していきましょう。
コメント