なぜ最新のLLMを使っても社内Wikiの検索は「賢く」ならないのか
「GPT-4oなどの旧モデルから、推論能力が大幅に向上したGPT-5.2へ移行したのに、社内Wikiの検索精度がいまいち上がらない」
「回答の日本語は流暢だが、肝心の社内ルールを正しく引用してくれない」
OpenAIの公式情報によると、2026年2月にGPT-4o等の旧モデルが廃止され、より高度な文脈理解を持つGPT-5.2が標準となりました。これに伴い、多くの組織が最新モデルへの移行を進めています。しかし、RAG（検索拡張生成）システムを運用する現場からは、モデルを更新したにもかかわらず「精度の壁」に直面し、頭を抱えるケースが珍しくありません。
経営層からは「最新のAIに移行すれば業務効率が飛躍的に上がるはずだ」という期待を受けつつ、現場からは「求めている回答が返ってこない」と指摘される。このジレンマは、AIの進化が著しい今の技術過渡期において避けて通れない問題です。
AI導入の現場における一般的な傾向として言えるのは、RAGの精度が出ない原因の多くは、AIモデルの性能不足ではなく、参照させるデータ（社内Wiki）の「整理整頓不足」にあるということです。どれほど高度な汎用知能を持つモデルを採用しても、この根本的な課題は解決しません。顧客対応の迅速化や業務効率化を目指す上で、データ基盤の整備は不可欠です。
「魔法の杖」としてのRAGへの過度な期待と現実のギャップ
RAGは、社内データをAIに読み込ませれば、魔法のように何でも答えてくれるツールだと思われがちです。しかし、RAGの仕組みを人間の行動に例えると、「大量の資料の中から関連ページを探し出し（検索）、それを読んで要約して答える（生成）」という2段階のプロセスを行っています。
ここで重要なのは、後半の「生成（Generation）」能力を担うLLMがいかに進化しても、前半の「検索（Retrieval）」で間違った資料を拾ってきてしまえば、絶対に正しい答えは出せないということです。これはコンピュータサイエンスの世界で古くから言われる「Garbage In, Garbage Out（ゴミが入ればゴミが出る）」という原則そのものです。
最新のRAGトレンドに目を向けると、情報のつながりを知識グラフとして理解する「GraphRAG」が注目を集めています。現在では、Amazon Bedrock Knowledge Basesなどの主要プラットフォームでもGraphRAGのサポート（プレビュー段階）が開始されるなど、技術の統合が進んでいます。加えて、画像や図表も理解する「マルチモーダル対応」の技術も発展してきました。
しかし、こうした最先端のアプローチであっても、入力データの質が担保されていなければ機能しません。入力データ（検索されたドキュメント）の質が低ければ、出力結果（AIの回答）もまた、質の低いものにならざるを得ないのです。
回答精度低下の真犯人は「生成能力」ではなく「検索能力」にある
最新のLLM（大規模言語モデル）は、与えられたテキストを理解し、要約する能力においては既に人間レベルかそれ以上に達しています。特にChatGPTのような最新世代では、長い文脈の理解力や複雑な指示への追従性が飛躍的に向上しています。つまり、「見つけてきた資料を元に的確に答える」ことは非常に得意なのです。
問題は、「正しい資料を見つける」部分です。組織の社内Wikiを想像してみてください。
- 似たようなタイトルの記事が乱立している（バージョン違いの放置）
- 更新日が不明で、現在のルールかどうかわからない古いマニュアル
- 部署ごとに異なる略語（例：AS＝アフターサービス、AS＝アプリケーションサーバーなど）
人間であれば、「あ、これは総務部の古い規定だな、最新のこっちを見よう」と文脈や暗黙知で判断できます。しかし、AIにとってそれは単なる「テキストデータの塊」に過ぎません。検索フェーズで適切な情報を抽出できなければ、AIはもっともらしい嘘（ハルシネーション）をつくか、「情報が見つかりません」と答えるしかないのです。
旧モデルが廃止され、新しいモデルへの移行を迫られる場面は今後も発生するでしょう。システムの設定を変更して最新モデルに乗り換える作業自体はすぐに完了するかもしれません。しかし、モデルのパラメータ数やバージョンアップに頼る前に、まずは「AIが情報を探しやすい状態になっているか」というデータ基盤を見直す必要があります。ここを見落としたままツールを乗り換えても、根本的な精度の改善には至らず、同じ失敗を繰り返すことになるでしょう。
ベクトル検索の限界と「文脈欠損」という壁
現在、多くのRAGシステムでは「ベクトル検索」という技術が使われています。これは、言葉の意味を数値（ベクトル）に変換し、意味が近いものを探し出す画期的な技術です。しかし、万能ではありません。特に社内Wikiのような非構造化データにおいては、致命的な弱点が存在します。
キーワード検索とベクトル検索の決定的な違い
従来のキーワード検索は、「申請書」という単語が含まれているドキュメントを機械的に探します。確実性はありますが、「申込書」と書かれていればヒットしません。
一方、ベクトル検索は「申請書」と「申込書」の意味が近いことを数学的に理解してヒットさせてくれます。これだけ聞くと素晴らしい技術に思えますが、逆説的に言えば「曖昧な検索」でもあるのです。
例えば、「Aプロジェクトの予算」と「Bプロジェクトの予算」という記事があったとします。ベクトル空間上では、どちらも「プロジェクト」「予算」という概念が強いため、非常に近い位置に配置されます。AIにとって、この2つの違いを明確に区別して検索することは、人間が想像する以上に難しいのです。特に社内独自のプロジェクト名やコードネームは、一般的な学習データに含まれていないため、AIはその重要性を認識しにくい傾向があります。
社内ドキュメント特有の「暗黙知」がAIを混乱させる
さらに厄介なのが、RAGの処理プロセスで行われる「チャンク化」です。長いWiki記事をAIが処理できるように、一定の文字数（例えば500文字ごと）で機械的に分割する処理のことです。
想像してみてください。推理小説を500文字ごとに切り刻んで、バラバラに床に撒き散らしたとしましょう。その断片だけを読んで、犯人が誰か分かるでしょうか？
社内Wikiでもこれと同じことが起きています。
- 「例の件については、以下の通り対応してください」
- 「前述の手順に従って申請を行ってください」
このように、人間なら前後の文脈や「空気」で理解できる指示語や省略が、チャンク化によって分断されると、AIには全く意味不明なテキストになります。これが「文脈欠損」です。
「例の件」が何の件なのかという情報が、切り分けられた別のチャンクに含まれてしまっていれば、その断片は検索クエリ（質問）との関連性が低いと判断され、AIの目に触れることはありません。これが、RAGが「賢くない」と感じる最大の要因の一つです。
AIに「忖度」するドキュメント構造化戦略
では、どうすれば良いのでしょうか。さらに高性能なAIモデルの登場を待つ必要はありません。今すぐできる、そして最も効果的な対策は、人間側がAIに歩み寄ること。つまり、AIが理解しやすいようにドキュメントを書いてあげる「AIへの忖度（そんたく）」です。業務効率と従業員体験（社内ユーザー体験）の両立を図るためには、この視点が欠かせません。
チャンク分割の最適解は「文字数」ではなく「意味の塊」
まず、システム的なアプローチとして、機械的な文字数でのチャンク分割を見直すべきです。文章の途中でブツ切りにするのではなく、見出し（H2、H3タグ）や段落といった「意味のまとまり」ごとに分割するよう設定を変更します。
しかし、それ以上に重要なのが、元となるWiki記事の書き方です。1つの見出しの中に複数のトピックを詰め込まず、「1トピック1見出し」を徹底するだけで、検索精度は劇的に向上します。AIは「見出し」と「その内容」のセットを一つの知識として認識しやすくなるからです。
メタデータ付与による「検索の取っ掛かり」作り
AIにとって、本文だけが頼りというのは心細いものです。そこで、記事に「メタデータ」という名札を付けてあげましょう。これは図書館の本に分類ラベルを貼るようなものです。
- 対象部署: 営業部、人事部
- 適用時期: 2024年度版
- 重要度: 必須
- 関連プロジェクト: プロジェクトX
これらの情報を、Wikiのタグ機能や、あるいは本文の冒頭に明記します。そしてRAGシステム側で、このメタデータをフィルタリング条件として使えるように設定します（これをメタデータフィルタリングと呼びます）。
「営業部の旅費精算について教えて」と聞かれた時、ベクトル検索だけで全文から探すのではなく、まず「営業部」タグがついた記事に絞り込んでから検索する。これだけで、無関係な「開発部の旅費精算」記事を誤って引用するリスクを大幅に低減できます。
ハイブリッド検索（キーワード×ベクトル）の実装価値
「AIへの忖度」の極みは、検索手法のハイブリッド化です。ベクトル検索の「意味理解」と、キーワード検索の「完全一致」を組み合わせる手法です。
社内用語や型番、固有名詞（例：「K-204号議案」など）は、ベクトル検索よりもキーワード検索の方が圧倒的に強いです。ユーザーの質問から重要なキーワードを抽出し、それはキーワード検索で、抽象的な質問はベクトル検索で、というように両者のいいとこ取りをする設計（Reciprocal Rank Fusionなどが有名です）を取り入れることで、精度の安定感は段違いになります。
情シスの役割は「システム管理者」から「ナレッジ編集者」へ
ここまで技術的な話をしてきましたが、結局のところ、RAGの精度を維持し続けるためには、組織的な取り組みが不可欠です。ここで、情報システム部門の皆様に新たな役割を提案したいと思います。
Garbage In, Garbage Outの原則を再認識する
これまでの情シスの役割は、Wikiという「箱」を用意し、サーバーが落ちないように管理することでした。中身のコンテンツについては「各部署で自由にやってください」というスタンスが多かったのではないでしょうか。
しかし、RAG時代において、そのスタンスは最大のリスクになります。質の低い、構造化されていないデータが大量に投入されれば、前述の「Garbage In, Garbage Out」の通り、AIは使い物にならなくなり、結果として「導入したAIは使えない」という評価につながってしまいます。
サーバーの稼働管理と同じくらい、あるいはそれ以上に「データの品質管理」が重要なミッションとなります。
従業員に求められる「AIフレンドリー」な書き方改革
情シス担当者がすべきは、全記事をリライトすることではありません。それは物理的に不可能です。そうではなく、「AIに読ませるためのドキュメント作成ガイドライン」を策定し、社内に啓蒙することです。
- 主語を省略しない: 「提出してください」ではなく「申請者は提出してください」と書く。
- 指示語を避ける: 「前述の書類」ではなく「経費精算書」と具体名を書く。
- タイトルを具体的に: 「マニュアル」ではなく「2024年度版_経費精算システム操作マニュアル」とする。
これらは、AIのためだけでなく、新入社員や中途採用者にとっても「読みやすい」ドキュメントになります。AIに忖度することは、結果として人間にとっても優しい、質の高いナレッジベースを作ることにつながるのです。情シスは、この「ナレッジ編集者」としての旗振り役を担うべきです。
結論：RAGは「検索ツール」ではなく「組織の知を映す鏡」である
RAGの精度向上に、特効薬はありません。「このツールを入れれば明日から完璧」という話は、残念ながら幻想です。
しかし、悲観することはありません。ドキュメントの構造化、メタデータの付与、そして社員一人ひとりの書き方の改善。これら地道な「データマネジメント」こそが、AI活用の最短ルートであり、王道です。
RAGの回答精度が低いということは、裏を返せば、組織のナレッジ共有の状態が「整理されていない」という事実をAIが鏡のように映し出しているに過ぎません。この課題に向き合うことは、AI導入の成否を超えて、組織の知的生産性を根本から底上げし、従業員体験（EX）と業務効率の向上を両立させるチャンスでもあります。
「理屈はわかったけれど、実際に構造化されたデータでどれくらい精度が変わるのか」
そう思われたなら、メタデータの自動抽出や、AIが理解しやすい形式へのデータ変換をサポートする機能を持つプラットフォームの活用を検討することをおすすめします。
「AIに忖度されたデータ」が、どれほどスムーズに、そして正確に回答を導き出すのか。適切なデータ基盤を構築することで、検索精度が数十パーセント向上するケースも珍しくありません。
今の悩みが「システムの限界」ではなく、「運用の工夫」で突破できることを、確信いただけるはずです。
コメント