「またCopilotが『わかりません』と答えたんですが、本当にドキュメントは登録されているんですか？」
社内の利用促進チャットに投稿されたこの一言は、従業員の体験を著しく損ね、業務効率化の妨げとなります。PoC（概念実証）段階ではスムーズに回答していたはずのAIが、本格導入後に特定の社内用語や複雑な規定について尋ねられると、途端に沈黙したり、あるいは全く関係のない文書を参照して平然と嘘をついたりする――。いわゆる「ハルシネーション（幻覚）」や「参照放棄」の問題です。
現場では、この問題に対して「プロンプトを工夫しましょう」や「システムプロンプトで役割を与えましょう」といった対症療法が取られがちです。しかし、「参照元が見つかりません」というエラーの本質は、プロンプトエンジニアリングで解決できるほど浅いものではないと考えられます。 これはRAG（検索拡張生成）アーキテクチャにおけるデータパイプラインと検索ロジックの構造的欠陥が原因である可能性があります。
一般的な傾向として、顧客体験（CX）や従業員体験を損なう最大の要因は「期待値とのギャップ」です。「社内のことは何でも知っているAI」という触れ込みで導入されたCopilotが、基礎的な就業規則すら答えられないとき、ユーザーの信頼は地に落ち、利用率は急降下します。
本記事では、表面的な設定変更ではなく、RAGシステムの心臓部である「検索精度」を根本から立て直すための技術的な方法を提示します。データの切り方（チャンキング）から、キーワードと意味を併用するハイブリッド検索、そしてAIによる再順位付け（リランク）まで、顧客ジャーニー全体を俯瞰し、最適なAI活用ポイントを特定するためのアーキテクチャ再構築手法を解説します。社内ステークホルダーに対して「なぜ改修が必要なのか」を説明するための論理武装としても、ぜひお役立てください。
なぜCopilotは「参照元なし」と答えるのか：エラーの解剖学
まず、システム内部の挙動を正確に把握することから始めましょう。「情報の参照元が見つかりません」というメッセージが表示されるとき、RAGのプロセスを分解すると、エラーが発生するポイントは大きく2つに分類されます。特に、GitHub Copilotの最新アップデートにより、OpenAI（ChatGPT）、Anthropic（Claude）、Google（Gemini） の各最新モデルを選択可能になった現在、この問題の切り分けはより重要性を増しています。
「検索ヒットなし」と「コンテキスト不適合」の違い
Copilotが回答を生成できない背景には、以下の2つの異なる事象が混在しています。
- Retrieval Error（検索失敗）: ユーザーの質問に対して、検索エンジンが関連するドキュメントチャンク（文章の断片）を見つけられなかったケースです。これは純粋に検索精度の問題ですが、Copilotにおいてはコンテキスト指定の不足も大きな要因です。例えば、
@workspaceコマンドを使用してリポジトリ全体を検索対象にしていない場合、開いているファイル以外は「存在しない」ものとして扱われます。 - Generation Refusal（生成拒否）: 検索エンジンはいくつかのチャンクを拾ってきましたが、LLM（大規模言語モデル）がそれらを読み込んだ結果、「この情報だけではユーザーの質問に回答するには不十分である」あるいは「不確実性が高い」と判断したケースです。これは「コンテキストの質」の問題です。
GitHub Copilotでは、選択するモデルによって、この「生成拒否」の基準が異なります。あるモデルでは「情報不足」と判断されても、別のモデルでは推論能力やコンテキストウィンドウの違いによって回答が導き出されるケースがあるのです。したがって、エラーの原因が「検索範囲」にあるのか「モデルの判断」にあるのかを見極めることが、データドリブンなトラブルシューティングの第一歩となります。
ベクトル検索の落とし穴：意味的類似性とキーワードの一致
現在のRAGシステムの多くは、文章を数値の羅列（ベクトル）に変換して類似度を測る「ベクトル検索」を主軸にしています。これは「意味」を捉えるのに優れていますが、万能ではありません。
例えば、社内固有の製品型番「XJ-9000」について検索する場合を考えてみましょう。ベクトル検索は「XJ-9000」という記号的な文字列よりも、「高性能なサーバー」といった意味的な文脈を優先して拾ってしまうことがあります。その結果、型番そのものが記載された仕様書よりも、概念的に似ているマーケティング資料を上位に表示してしまい、LLMが「仕様が見つかりません」と答える事態を招きます。
トークン制限と最新機能の死角
また、LLMに渡せる情報量（コンテキストウィンドウ）と、利用する機能の特性も重要な要素です。
GitHub Copilotの最新版では、Agent Modeのような自律的なコード修正機能や、Copilot Editsによる複数ファイル編集、さらにはMCP（Model Context Protocol） による外部ツール連携が可能になり、以前よりも広範な情報を処理できるようになりました。しかし、以下の点に注意が必要です。
- コンテキストの「迷子」: Agent Modeは自律的に関連ファイルを探索しますが、探索範囲が広すぎるとノイズ情報が増え、肝心の情報が埋もれる（Lost in the Middle現象）リスクがあります。
- モデルの特性変化: AIモデルの進化に伴い、利用可能なモデルは頻繁に更新されます。例えば、新しいモデルへ切り替えた際、以前のモデルで機能していたプロンプトやコンテキスト構成が、新しいモデルの安全性基準や推論ロジックと合致せず、「回答不能」となる場合があります。
- 外部コンテキストの接続: MCPなどで外部データソースと連携している場合、その接続設定や権限の問題でデータ取得に失敗していても、表面上は単なる「参照元なし」として処理されることがあります。
つまり、どれだけ高性能な最新モデルや機能を選んだとしても、検索範囲の指定とコンテキストの質が適切でなければ、「ゴミを入れてゴミが出てくる（Garbage In, Garbage Out）」か、あるいは「参照元なし」というエラーに行き着くのです。
参考リンク
診断フェーズ：現在のRAGアーキテクチャの弱点を特定する
再構築に着手する前に、現在のシステム構成のどこにボトルネックがあるかを診断する必要があります。以下のチェックリストを用いて、自社のRAGシステムの健康状態を確認してください。
チャンクサイズの適切性チェック：文脈が分断されていないか
最も一般的な失敗例は、ドキュメントを「単純に500文字ごと」などの固定長で機械的に分割しているケースです。
例えば、「有給休暇の申請ルール」という見出しがあり、その下に具体的なルールが箇条書きされているとします。もし固定長分割によって、見出しとルールが別のチャンクに分かれてしまったらどうなるでしょうか？
- チャンクA: 「...に関する規定。第5条 有給休暇の申請ルール」
- チャンクB: 「1. 原則として3日前までに申請すること。2. 緊急時は...」
チャンクBだけが検索でヒットしても、LLMはそれが「何のルールなのか」を判断できません（主語の欠落）。結果、「文脈不明」として回答に使用されず捨てられます。これが「データはあるのに答えない」主原因の一つです。
メタデータの活用状況：ファイル形式や更新日のフィルタリング
インデックス作成時に、ファイル名、作成者、更新日、カテゴリなどのメタデータを付与していますか？ また、検索時にそれらを活用していますか？
「最新の就業規則を教えて」と聞かれた際、メタデータによる「更新日」のフィルタリングやソートが行われていないと、2年前の古い規定がヒットしてしまう可能性があります。古い情報を参照して回答すればハルシネーションですし、矛盾を検知して回答を拒否すればエラーとなります。
検索クエリの変換ロジック：ユーザー質問をそのまま投げていないか
ユーザーの入力（プロンプト）を、そのまま検索エンジンに投げていませんか？
ユーザーは「経費精算のアレ、どうやるんだっけ？」といった曖昧な話し言葉で質問します。これをそのまま検索クエリにすると、ノイズが多く精度が落ちます。LLMを使って「経費精算 システム 操作手順 申請方法」といった検索用キーワードや、整ったクエリに変換する前処理（Query Rewriting）が実装されているかを確認してください。
処方箋1：データ前処理とチャンキング戦略の再設計
診断でデータパイプラインに問題があることがわかった場合、まずはETL（Extract, Transform, Load）プロセスの見直しから始めます。ここでの修正は、後段の検索ロジック改善よりもコスト対効果が高く、業務効率の向上に直結するケースが多いです。
意味の塊を維持する「セマンティックチャンキング」の実装
固定長分割からの脱却を目指しましょう。現在は、LangChainやLlamaIndexなどの最新フレームワークを活用して、段落や見出し単位、あるいは意味の変化点を検知して分割する「セマンティックチャンキング」が実装可能です。
特にカスタマーサービス領域で扱う顧客データや社内規定集は機密性が高いため、実装時にはフレームワークの選定と運用に注意が必要です。
- セキュリティと最新APIへの対応: LangChainなどの主要ライブラリでは、データの読み込み処理に関する重要なセキュリティ強化が行われています。脆弱性対策が含まれる最新のパッチ適用版を使用することは、企業のガバナンスとして必須です。また、APIの仕様も変化しており、古い実装例をそのまま流用すると動作しない可能性があるため、公式ドキュメントでの確認が欠かせません。
- 分割手法の最適化: 具体的には、Recursive Character Text Splitter（再帰的文字分割） のような手法を用い、まずは大きな区切り（段落など）で分割を試み、指定サイズを超える場合のみ、より小さな区切り（文など）で分割するというアプローチが有効です。
これにより、「見出し」と「内容」が泣き別れになるリスクを最小限に抑えつつ、安全でメンテナンス性の高いパイプラインを構築できます。
Parent-Child Indexing（親文書・子チャンク方式）
さらに精度を高める手法として、「Parent-Child Indexing（Small-to-Big Retrieval）」を推奨します。
- 検索用データ（Child）: 細かく分割したチャンク（例：200文字）。具体的なキーワードや文脈をピンポイントで捉えるために使用します。
- 生成用データ（Parent）: 検索でヒットした子チャンクが属する、より大きな親チャンク（例：1000文字やドキュメント全体）。LLMに渡すのはこちらです。
これにより、「検索は鋭く（細かい粒度でヒットさせる）」、「回答は豊かに（前後の文脈を含めてLLMに読ませる）」という理想的な状態を作れます。文脈の欠落による回答不能エラーを劇的に減らすことができるテクニックです。
「ゴミデータ」を排除するインジェスチョンパイプラインの浄化
RAGにおいても「Garbage In, Garbage Out（ゴミを入れればゴミが出る）」は真理です。社内ドキュメントには、ヘッダー、フッター、目次、広告的な定型文など、検索ノイズとなる情報が大量に含まれています。
PDF解析ツールを活用し、本文以外のレイアウト要素を除去する処理をパイプラインに組み込みましょう。特に、全ページに共通して書かれている「社外秘」などの文言は、すべてのドキュメントの類似度を不当に高めてしまうため、必ず除外処理（ストップワード設定や正規表現による削除）を行う必要があります。
処方箋2：検索精度の壁を突破するハイブリッド検索とリランク
データが綺麗になっても、それを見つけ出す「目」が悪ければ意味がありません。ここでは、検索ロジックのアップデートについて解説します。
キーワード検索とベクトル検索の「いいとこ取り」：ハイブリッド検索の設定
前述の通り、ベクトル検索は「型番」や「固有名詞」に弱い傾向があります。一方で、従来のキーワード検索（BM25など）は、単語が完全に一致しないとヒットしません。
この両者の弱点を補うのが「ハイブリッド検索」です。Azure AI Searchなどの最新の検索サービスでは、標準機能として提供されています。
ハイブリッド検索では、ベクトル検索のスコアとキーワード検索のスコアを融合（RRF: Reciprocal Rank Fusionなどを用いて統合）して順位を決定します。これにより、「概念的な質問」にも「具体的な型番の検索」にも対応できる堅牢な検索システムが実現します。まだベクトル検索単体で運用している場合は、ハイブリッド構成への移行を検討すべきです。
検索結果をLLMの視点で並べ替える「セマンティックリランカー」の導入
ハイブリッド検索で候補を絞り込んだ後、さらに精度を高める「切り札」となるのが「リランク（Re-ranking）」です。
検索エンジンが返した上位候補（例えば50件）に対して、より高度な言語モデル（リランカー）を用いて、「ユーザーの質問に対して本当に回答能力があるか」という視点で再評価し、並べ替えを行います。
Azure AI Searchの「セマンティックリランカー」機能などがこれに該当します。リランカーは計算コストがかかるため全ドキュメントに対しては使えませんが、検索上位の数十件に対して適用することで、精度向上をもたらします。リランクを導入するだけで、検索精度が20〜30%向上し、「参照元なし」のエラーが大幅に減少するケースも確認されています。
回答生成に最適なコンテキストウィンドウの調整
リランクによって真に関連性の高い情報が上位に来たら、LLMに渡すチャンク数（Top-K）を調整します。多すぎればノイズになり、少なすぎれば情報不足になります。
一般的には、リランク後の上位3〜5件程度が最適解とされていますが、ドキュメントの性質によります。ここで重要なのは、トークン数を意識した動的な制御です。「上位5件」と固定するのではなく、「累積トークン数が2000に達するまで上位から採用する」といったロジックを組むことで、回答精度を安定させることができます。
持続的な品質保証：エラー再発を防ぐ評価システムの構築
システムを改修して終わりではありません。社内ドキュメントは日々増え続け、ユーザーの質問トレンドも変化します。一度きりの修正で終わらせず、継続的に信頼性を担保する「Assurance（保証）」の仕組みが必要です。
Ragasを用いた回答精度（Faithfulness/Answer Relevance）の自動評価
「精度が上がった気がする」という主観的な評価は危険です。Ragas (Retrieval Augmented Generation Assessment) などの評価フレームワークを導入し、数値を追跡しましょう。
特に注目すべき指標は以下の2つです。
- Faithfulness（忠実性）: 生成された回答が、参照したコンテキスト（ドキュメント）に基づいているか。これが低いとハルシネーションの疑いがあります。
- Answer Relevance（回答関連性）: 生成された回答が、ユーザーの質問に対して適切か。
これらの指標をCI/CDパイプラインに組み込み、システム改修のたびに自動テストを走らせることで、デグレード（改悪）を防ぐことができます。
ユーザーフィードバックループの組み込みと継続的改善（CI/CD for RAG）
CopilotのUIには必ず「Good/Bad」ボタン、あるいは「回答が役に立ちましたか？」というフィードバック機能を実装してください。そして、ここで集まった「Bad」データを宝の山として扱います。
「Bad」が押された質問と回答のペアを分析し、なぜ間違えたのか（検索失敗か、生成失敗か）を分類します。これを正解データ（Golden Dataset）として蓄積し、次回の評価テストに追加していくのです。このデータドリブンな改善ループこそが、AIの回答精度を継続的に高め、ユーザー体験を向上させる確実なアプローチです。
「使えない」と言わせないための社内SLA設定
最後に、社内ユーザーとの合意形成についてです。「100%完璧なAI」は存在しません。しかし、「90%の確率で正解し、わからない場合は正直に『関連資料が見当たりません』と答える」ことは設計可能です。
「どのような質問に対しては回答を保証し、どのような質問（例えば個人的な相談や、データがない領域）はスコープ外とするか」というSLA（サービスレベルアグリーメント）を明確にし、社内に周知することも、信頼回復の重要なステップです。
Copilotの「参照元なし」エラーは、システムの限界ではなく、設計の未熟さが招く現象です。今回ご紹介したチャンキング戦略、ハイブリッド検索、リランク技術を組み合わせることで、社内ナレッジを正確に引き出し、ユーザーの業務を強力に支援する「頼れる相棒」へと進化させることができます。
しかし、これらのアーキテクチャ再構築は、既存のシステム環境やデータの特性によって最適なパラメータが異なります。「自社のデータの場合、どのチャンキング手法がベストなのか？」「Azure AI Searchの設定はどうチューニングすべきか？」といった具体的な実装レベルでの疑問が生じた際は、段階的なAI導入と継続的な改善を視野に入れたアプローチを検討することをおすすめします。
コメント