ステートレスなRAGの落とし穴：クエリ時のAIアーキテクチャが不十分な理由

By Mirko Peters · 2026-08-13

ブログへようこそ。エンタープライズAIについてのポッドキャストの議論をフォローしてくださっている方なら、現代の生産性ツールが持つ当初の誇大な期待の向こう側を見ることに、私たちが多くの時間を費やしていることをご存じでしょう。

Automatically translated with AI from the original post. Read the English original

ブログへようこそ。エンタープライズAIについてのポッドキャストの議論をフォローしてくださっている方なら、現代の生産性ツールが持つ当初の誇大な期待の向こう側を見ることに、私たちが多くの時間を費やしていることをご存じでしょう。標準的なデモでは、Microsoft Copilotのようなツールは驚くほど賢く見えます。プロジェクトのドキュメントを見つけ、ポリシーを要約し、SharePointから情報を抽出し、企業コンテンツの断片をつなぎ合わせて説得力のある回答を作ることができます。しかし、その印象的なユーザー体験の裏には、根本的なアーキテクチャ上の制約が隠れています。それは、検索は記憶ではないということです。Copilotは組織内を検索できますが、それは組織について持続的な理解を構築しているという意味ではありません。 この投稿では、Retrieval-Augmented Generation（RAG）の仕組みを掘り下げ、チャンク分割とステートレスなクエリのループによって、AIが企業内のやり取りを通じて蓄積されたコンテキストを保持できなくなる理由を解説します。これらの概念についてより詳しく音声で解説している関連ポッドキャストエピソード、Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes Itもぜひご覧ください。

Copilotは記憶しない。検索しているのです

Copilotを使う体験は、重要な錯覚を生み出します。Microsoft 365から情報をうまく結び付けられると、システムが組織について何かを学習したように見えます。しかし、後日似た質問をすると、システムは以前に構築した理解を単に呼び出すのではなく、再び検索を実行するため、異なる結果を返すことがあります。組織が基本的な要約を超えて、実際の意思決定をAIに支えてほしいと期待し始めたとき、この違いは決定的に重要になります。

実質的に同じ質問でも、どの情報が検索されたかによって回答が一貫しないなら、ユーザーはビジネス上重要な作業にAIを頼ることに急速に消極的になります。その結果、技術的な問題にとどまらず、導入の問題になりかねません。ユーザーは予測可能性を求めています。まったく同じプロンプトに対して、月曜日には一つの回答を、木曜日には矛盾する回答を返すアシスタントであれば、信頼はすみやかに損なわれていきます。

Retrieval-Augmented Generationが実際に行うこと

RAGとは、Retrieval-Augmented Generationの略です。簡単に言えば、企業のドキュメントはチャンクに分割され、それぞれのチャンクはエンベディングによって表現されます。ユーザーの質問も同様に比較可能な表現に変換され、システムは意味的に関連するチャンクを検索します。最も上位にランク付けされた情報が、回答を生成するためのコンテキストとして大規模言語モデルに渡されます。

このアーキテクチャは非常に有用です。大規模言語モデルが、元の学習データに含まれていなかった情報を使って質問に答えられるようにし、企業コンテンツに基づいてAIの回答を裏付ける実用的な方法を提供します。しかし同時に、重要なアーキテクチャ上の制約も生まれます。モデルが受け取るのは、現在のクエリのために選ばれた断片であり、組織の知識について完全で持続的な表現を保持しているわけではないのです。

チャンク分割の問題

企業の知識が、独立した段落として存在することはめったにありません。プロジェクト計画には、何十ページにもわたって分散した依存関係が含まれることがあります。あるポリシーが別のポリシーを参照していることもあります。技術アーキテクチャは、数か月前に会議メモ、Teamsの会話、SharePointのページ、設計ドキュメントに記録された決定に依存している場合があります。

従来のRAGは、これらのソースをより小さな単位に分割し、現在の質問に関連すると思われる断片を判定します。そのため、モデルは完全なドキュメントやそのすべての関係性を必ずしも理解するのではなく、選ばれた断片を見ることになります。単純な情報検索であれば、非常にうまく機能することがあります。しかし、関係性、履歴的な文脈、依存関係、積み重ねられた決定、あるいは多数のソースをまたいだ推論を必要とする質問では、その限界がはるかに顕著になります。

ステートレスRAGの落とし穴

従来の検索拡張型ワークフローには、「すでに答えが分かっている」という概念そのものがありません。質問を受け取り、情報を検索し、回答を生成すると、次の検索処理では処理がほぼ最初からやり直しになります。RAG のステートレス性が大きな障壁になるのは、まさにこの点です。

ある対話で得られた知見が、今後のすべての対話で利用できる組織の永続的な知識になるわけではありません。エンタープライズ AI にとって、この違いは非常に大きな意味を持ちます。組織に必要なのは、単により良い検索機能ではありません。プロジェクト、プロセス、ポリシー、テクノロジー、人、意思決定、依存関係、そしてそれらを結ぶ関係性について、構造化された理解を維持できるシステムが、今後ますます求められるようになります。

知識の検索と知識のコンパイル

本シリーズの最新オーディオ版で取り上げる中心的なアーキテクチャの考え方もここにつながります。組織の知識をクエリのたびに再構築するのではなく、事前に AI がその知識をコンパイルしておいたらどうか、という発想です。LLM Wiki は、この考え方の転換を表すものです。

エンタープライズ文書をバラバラな断片の集まりとして扱い、検索されるのを待つのではなく、AI が情報を統合し、組織が現時点で理解していることを表す構造化された知識アーティファクトにまとめられます。重要なのは、単に新しい UI を用意することではありません。クエリ時の再構築から、永続的な知識の統合へと知性の置き場所を移すことです。

LLM Wiki がモデルを変える理由

同じ製品、顧客、プロジェクト、ポリシー、アーキテクチャについて書かれた数千の文書を想像してください。従来の RAG は、質問が来てから、それに答えられそうな断片を探し出そうとします。一方、LLM Wiki のアプローチでは、そうした断片化されたソースを、一貫性のある知識ページへと継続的に変換しようとします。

関係性、意思決定、定義、依存関係、履歴的な背景、そして裏付けとなるソースは、管理された知識表現の一部になり得ます。その後、Copilot やほかの AI エージェントは、生の文書から毎回理解を再構築するのではなく、統合された組織の理解を含むレイヤーから情報を取得できます。

ドキュメントリポジトリから知識レイヤーへ

この変化は、SharePoint のようなシステムの役割にも影響します。SharePoint は、文書、ページ、ポリシー、プレゼンテーション、会議の成果物、コラボレーションコンテンツの正式なリポジトリとして、引き続き機能できます。ただし、生のエンタープライズコンテンツが自動的に利用可能な組織の知識になるわけではありません。

AI が生成する知識レイヤーは、こうした元のシステムの上に配置し、散在する情報を組織の地図に近いものへ変換できます。プロジェクトと意思決定の結びつき、ポリシーとプロセスの結びつき、システムとオーナーの結びつき、概念とその裏付けとなる根拠の結びつきを可視化するイメージです。目的は元の文書を排除することではありません。文書の中に埋もれている関係性を明示化することです。

プロンプトの改善ではアーキテクチャの問題は解決しない

プロンプトエンジニアリングによって、LLM が取得されたコンテキストをどう解釈するかは改善できます。しかし、そもそも正しいコンテキストが取得されたことは保証できません。検索レイヤーが不完全な断片を返したり、重要な依存関係を見落としたり、古い文書を提示したりすれば、どれほど優れたモデルでも不完全な情報をもとに推論することになります。

そのため、モデルの改善だけでは、エンタープライズ AI のすべての問題は解決できません。モデルに与える知識の品質と構造が、依然として基本となります。一時的な検索結果に頼り、構造化された永続的なメモリを持たないアーキテクチャは、どれほど巧みなプロンプトを用いても修正できません。

ガバナンスの課題はさらに大きくなる

このアーキテクチャには、重要な注意点も伴います。組織の SharePoint 環境に、古いポリシー、重複したドキュメント、放棄されたプロセス、矛盾する指示、明確なオーナーのない文書が含まれている場合、LLM Wiki は良い情報を統合するのと同じくらい効率的に、誤った情報も統合してしまいます。

危険なのは、統合された知識が、元のコンテンツが持つ実態よりもはるかにきれいで権威あるものに見えてしまうことです。そのため AI は、従来の情報ガバナンスを軽視するどころか、むしろ重要性を高めます。コンテンツのオーナーシップ、ライフサイクル管理、バージョン管理、保持、アーカイブのプロセス、正式なソース、メタデータ、明確に定義された正式なシステムのリファレンスは、AI アーキテクチャの基盤となる要素です。

AI の準備はコンテンツの品質から始まる

多くの組織では、Copilot への準備をライセンス、セキュリティ、展開、トレーニングのプロジェクトとして捉えがちです。これらも重要ですが、その土台となるナレッジ環境も同じくらい重要です。どの文書が現在のプロセスを表しているのかを誰も把握していなければ、AI が組織内の曖昧さを魔法のように解消することはできません。

3 つの部門がポリシーについて互いに矛盾するバージョンを管理していれば、AI は 3 つの「真実」を引き継ぐことになります。古いドキュメントが無期限に検索可能なままであれば、それは依然として回答の根拠になりうる素材です。エンタープライズ AI は、これまで組織が無視できていたナレッジ管理の負債を表面化させるのです。

Copilot の採用を左右する信頼

技術的な影響は、すぐにビジネス上の影響となります。メールの下書きや会議の要約に AI を使うなら、ユーザーは時折の不整合を許容するかもしれません。しかし、AI にポリシーの説明、顧客の判断の支援、プロジェクト状況の解釈、コンプライアンス情報の提供、業務プロセスのガイドなどが期待されると、許容度は大きく下がります。

重要な質問に対する回答が一貫しないことをユーザーが一度経験すると、信頼できる人間の専門家や従来の手作業のプロセスに戻ってしまうことがよくあります。一見うまく展開されたように見えても Copilot の採用が頭打ちになる大きな理由がここにあります。したがって、信頼は単なる採用指標ではなく、アーキテクチャ上の要件なのです。

まとめ

要するに、検索拡張生成（RAG）は外部文書に接続する強力な手段をエンタープライズ AI にもたらしましたが、その場限りのクエリのループとチャンク分割の制約があるため、真の組織的な記憶とはいえないことがよくあります。永続的な知識の集約がなければ、Copilot のようなシステムは、一貫性、深い文脈上の関連性、そしてエンタープライズとしての信頼性に引き続き苦労するでしょう。生の文書リポジトリから、構造化されてコンパイルされたナレッジレイヤーへ移行すること（新たに登場した LLM Wiki のアプローチなど）が、派手なデモと信頼できるビジネスツールとの間の溝を埋める鍵です。このテーマをさらに掘り下げ、エンタープライズ AI のメモリをどう改善するかについての詳しい分析を聞きたい方は、ぜひ完全版のエピソードをお聴きください: Your Copilot Has No Memory — Why RAG Fails and LLM Wiki Fixes It。