プロンプト詰め込みから、エージェントのためのクエリ可能な知識へ

はじめに

エージェントがメモリをどう使うべきかへの関心が高まっています。モデル重みに置くべき知識は何か、コンテキストウィンドウに載せるべきものは何か、そして外部システムに置いて必要なときだけ問い合わせるべきものは何か、という論点です。これは能力の話であると同時に、効率の話でもあります。トークンは高価で、コンテキストは有限で、検索品質は重要です。実務的な設計として有力なのは、生のソースをプロンプトの外に置き、その上に構造化知識レイヤーを築き、必要なときにだけエージェントがそれを問い合わせる形です。

RAG システム、エージェントメモリ、MCP サーバーを作っている人にとって、問いはほぼ同じになってきています。どうすればノイズを最小限に抑えつつ、正しい根拠を取り出せるのか、という問いです。

重要なのはコンテキストウィンドウを避けることではありません。重要なのは、その場で本当に価値の高い材料、つまり具体的な証拠と制約条件のためにコンテキストを使うことです。

この考え方自体は新しくありません。RAG、ツール利用、外部メモリ、長文コンテキスト評価はいずれも、以前からおおむね同じ方向を向いていました。今は周辺ツールが整ってきたことで、この設計をきれいに実装しやすくなっている点が違います。

私たちはこの方向性がもっとも筋が良いと考えています。

なぜ重要か

エージェント実務でよく起きる圧力は、コーパスが大きくなるほど、プロンプトが一度に多すぎる仕事を背負い始めることです。指示、検索結果、メタデータ、中間要約、推論対象の証拠がすべて同じ場所に押し込まれます。これで十分に機能することもありますが、うまくいかないこともあり、うまくいっている場合でも無駄が多いことがあります。

その無駄はコストだけではありません。注意資源の無駄でもあります。

コンテキスト内の余分な段落はすべて、モデルの注意を奪い合います。ノイズの多い検索結果が一つ増えるごとに、本当に重要な数点が見えにくくなります。毎回同じ事実を生文書から再発見させる設計は、本来もっと上流で済ませておくべき仕事を後ろ倒しにしているだけかもしれません。

だからこそ、メモリ設計とコンテキスト設計が重要なテーマになっています。制約は単に「どれだけ入るか」ではなく、「そもそも何をモデルの前に置く価値があるのか」です。

重み、コンテキスト、外部知識

この問題を考えるうえでは、知識が存在しうる場所を三つに分けると整理しやすくなります。

一つ目はモデル重みです。ここには学習済みの広範な知識があり、強力で驚くほど有能なこともあります。ただし拡散していて、特定コーパスの正確な記録としては扱いにくく、狙った更新も簡単ではありません。

二つ目はコンテキストウィンドウです。ここでは証拠が鋭くなります。Jeff Dean は Dwarkesh Patel と Noam Shazeer との対話で、モデル入力に直接置かれた情報は、学習を通じて間接的に吸収された知識よりもはるかに明瞭だと指摘しました。モデルが今まさに処理しているテキストへ直接注意を向けられるからです。この違いは実務上とても重要です。コンテキストが証拠を明瞭にする場所なら、そこには最良の証拠を置くべきであって、広くて粗い検索結果を詰め込む場所ではありません。

三つ目は外部知識です。モデル重みだけでは足りないほど正確で、最新で、構造化され、追跡可能な情報が必要なときに、モデルが問い合わせる外部システムのことです。

面白い設計上の論点は、この第三の層にあります。

長いコンテキストは助けになるが、検索そのものは解決しない

長いコンテキストウィンドウが魅力的に見える理由はわかりやすいものです。厳しい上限を緩め、より多くのソースを持ち込み、大きな入力を途中で切らずに処理できるようにします。

しかし、長いコンテキストを持てることと、その中から関連情報へ安定して到達できることは同じではありません。

ここで参考になるのが Lost in the Middle（TACL 2024）です。この研究は、長い入力のどこに関連情報が置かれるかによってモデル性能が落ちうることを示しました。特に長いコンテキストの中央にある重要情報は、先頭や末尾にある場合よりもうまく使えないことがあります。要点は単純で、情報が入ることと、モデルがそれを堅牢に使えることは別だということです。

これは長文コンテキストの価値を否定する話ではありません。ただ、それ自体は検索戦略にはならないという意味です。

なぜ検索と外部メモリが繰り返し重要になるのか

明示的な外部メモリの必要性は以前から指摘されてきました。NeurIPS 2020 の元祖 RAG 論文は、その議論をわかりやすく示しています。言語モデルは多くの知識をパラメータに保持しますが、知識集約的なタスクでは明示的な非パラメトリックメモリへのアクセスが有効です。検索は factuality、specificity、provenance を改善します。

モデルがよりエージェント的になるにつれて、この考え方の重要性はさらに増しています。実在の文書群に基づいて質問に答えることが求められるなら、アーキテクチャが問われます。重要な情報はすべて重みの中にあるはずだと仮定したり、より大きなテキストの山をプロンプトに貼ればよいと考えたりするだけでは足りません。必要なのは、正確な情報を必要なときに引き出す方法です。

ツール利用の流れも同じ方向を向いています。Toolformer（NeurIPS 2023）が重要なのは、すべてを解決するからではありません。モデルが内部知識だけに頼るのではなく、外部システムを呼び出せるときにより良く機能する、という同じ発想を反映しているからです。

「とにかくもっと検索する」ことの問題

検索を組み込んだあとにも、もう一つの問いが残ります。何を、どんな形で検索するのかという問いです。

ここで生の検索の限界が見えてきます。エージェントにとって有用な質問の多くは、実は単純なキーワード検索の問題ではありません。構造に依存しています。

• ある概念に言及した特定日以降の statement をすべて出す
• 一人の発言者が speeches と press conferences でどう論点を変えたか比較する
• ある entity に紐づく文書を列挙し、そこから source と subtype で絞る
• ある文書を前の版と diff する

こうした問いは単なる「何かテキストを見つけてくる」問題ではありません。構造化検索の問題です。答えはメタデータ、正規化、関係性、精密なフィルタリングに依存します。

このため、知識グラフ、メモリシステム、保守された中間レイヤーへの関心は続いています。Andrej Karpathy の最近の LLM Wiki gist も、この圧力を実務家の言葉で表現した良い例です。彼が言いたいのは、生文書検索が無価値だということではありません。多くのシステムが、毎回ゼロから知識を再発見させており、生ソースとクエリ時推論のあいだに維持された知識レイヤーを育てていない、という指摘です。

この見方はかなり正しい方向を向いていると思いますし、壮大な理論としてではなく、実務のワークフローとして素直に書いている点も有益です。

なぜ構造が重要なのか

コーパスが、ばらばらの文書の山ではなく構造化知識として表現されると、いくつかのことが一気にやりやすくなります。

• 第一に精度です。entity、日付範囲、ソース種別、文書 subtype、比較対象など、必要な切り口だけを正確に問い合わせられます。
• 第二に効率です。無関係なトークンをコンテキストへ持ち込む量を減らせます。
• 第三に合成可能性です。同じ知識レイヤーを、質問応答、ページ生成、版比較、要約、エージェント作業支援など複数用途で再利用できます。
• 第四に追跡可能性です。何がどこから来て、なぜ選ばれたのかを説明しやすくなります。

最近の研究も、コンテキスト品質の重要性を繰り返し示しています。Influence Guided Context Selection for Effective Retrieval-Augmented Generation（NeurIPS 2025 poster）は、ノイズの多い検索コンテキストが RAG を大きく損ないうること、そしてより良い選択が重要であることを論じています。これは多くの実務家がすでに感じている直感と一致します。検索量が多いことは、そのまま良い検索を意味しません。

したがって目標は、単に検索することではありません。モデルに渡る前の段階で、構造ができるだけ絞り込みを済ませるようにしながら、狭く正確に検索することです。

なぜ MCP がこの設計に合うのか

ここで MCP が役に立ちます。

MCP が価値を持つのは、モデルを魔法のように賢くするからではありません。外部システムへきれいにアクセスする経路を与えるからです。その外部システムが構造化知識コーパスであるとき、このアクセスパターンは特に強力になります。

エージェントワークフローで MCP を検討しているチームにとって、実務上の転換点はここにあります。広い検索とプロンプト詰め込みから、構造化知識コーパスへの正確なツール経由アクセスへ移ることです。

大きな検索ダンプ全体をモデルに読ませる代わりに、モデルはもっと精密なクエリを発行できます。

• このコーパスを検索する
• この日付範囲で一致する item を列挙する
• この文書を取得する
• この文書を前の版と比較する
• canonical entity を見つけて関連資料を列挙する

そうすると、仕事の多くがプロンプトから検索レイヤーへ移ります。通常、そのほうが自然です。

コンテキストウィンドウは依然として重要です。ただし役割はより狭く、より価値の高いものになります。コーパス全体を広く探索する場所ではなく、選ばれた証拠の上で推論する場所になります。

効率が仕事の質を変える理由

ここには、もう少し実務的な論点もあります。より良い検索アーキテクチャは、単にトークンを節約するだけではありません。どのようなワークフローが現実的になるかを変えます。

エージェントが事実の再発見に予算を使いすぎれば、比較、評価、統合、判断に回せる予算は減ります。検索が鋭く安価になれば、人が本当に欲しい部分へより多くの計算資源を回せます。

xRAG のような論文が興味深いのもそのためです。ここで重要なのは個別手法そのものより、効率的な grounding が実装上の細部ではなく第一級の関心事になってきている、というシグナルです。

近年のエージェントメモリ研究にも同じ傾向があります。A-Mem のような論文は、メモリ構成そのものを後付けではなく、エージェント設計の中核問題として扱い始めていることを示しています。

この流れは妥当です。エージェントワークフローが本格化するほど、メモリは便利機能ではなくインフラになります。

なぜ私たちはこの作り方を選ぶのか

私たちにとって面白いのは、新しいパラダイムを名乗ることではありません。この設計方向を現実のドメインで真面目にやり切ることです。

コーパスが豊富で、問いが精密で、ユーザーが追跡可能な答えを求めるなら、重みだけに頼るのでは足りません。同時に、より大きなテキストをコンテキストへ詰め込むことも、たいてい最もきれいな答えではありません。より有用なのは、生ソースをプロンプトの外に置き、その上に構造化知識レイヤーを維持し、エージェントが直接使えるクエリ面として露出することです。

だからこそ、MCP を通じて公開された構造化コーパスには意味があります。

コンテキストウィンドウが重要ではないからではありません。構造で上流に押し戻せる仕事に使うには、コンテキストウィンドウがあまりにも貴重だからです。