第9章 — 注意の予算管理

LLM Primer IV: MCPで設計するAI認知 のウォークスルー第9回です。100万トークンのコンテキスト・ウィンドウは「運用点」ではなく「天井値」だった、という話と、「モデルが悪くなった」と診断される事例のかなりの割合が、実は「モデルが埋もれた」だった、という話です。

なぜこの章があるのか

コンテキスト・ウィンドウは「自由なスペース」に見えます。違います。エージェントが読むトークンはどれも、レイテンシ・コスト、そして — 明らかでないがそれ以上に重要な — 品質を消費します。「100万トークンのウィンドウ=何でも収まる」という錯覚は、いまの実務で最もコストの高い読み違いのひとつで、「モデルが回帰した」と診断される本番失敗の大きな割合がここから来ます。モデルが悪くなったのではなく、埋もれたのです。この章は、コンテキストを「フリーリソース」ではなく「有限の予算」として扱う話です: 何が予算を食べるか、予算が正しい道具でないときどんな代替があるか、エージェントが必要なものだけを持って何も余分でない生産的ゾーンへ着地する方法。

9.1 コンテキスト・ロットと非線形の崖

コンテキスト長と品質の関係は線形ではありません。プロンプトを倍にしても品質は半分にはなりません — ある点を超えると、半分以上悪くなります。定着した技術名 — context rot — は俗ですが正確です。Liuらによる古典的なStanfordの研究は、関連文書がリストの中央にあるとき、端にあるときに比べてモデルの情報探索性能が劇的に落ちることを示しました。このU字カーブはモデル系列やコンテキスト長を超えて再現されています。長いプロンプトの中央は、意味のある意味で、注意の上では端よりも「安価」 — アーキテクチャは全位置を同じに扱うのに、です。

2023年から2024年に標準になった「needle in a haystack」ベンチマークは、最初はこの絵を否定するように見えました — 100K、200K、1M トークンでもほぼ完璧な取得。より丁寧な後続研究はベンチマークが甘すぎたことを示しました。均質な藁の中の目立つ針を見つけるのは、20の話題的に近い気散らしに埋もれた事実を見つけるのとは別の問題です。2025年後半に出たMCP-UniverseとBIG-Bench-Longはその敵対的構造を組み込み、数字は厳しい: 100Kトークンでフロンティアのモデルが8Kでの同じタスクと比べて10〜20点を失い、500Kでは40点に達することもあります。

MCPエージェント特有の第2の形のロットがあります。システムプロンプトにツールが積み上がるにつれて、モデルの正しいツール 選択 精度が落ちます。MCP-Universeは、5ツールで約90%だったツール選択精度が、40ツールで60%を下回ることを示しました。実務者は今これを tool-loadout rot と呼び、「機能を足したらエージェントがバカになった」の単一最大の原因です。機構は両方で同じ: 注意は有限で、プロンプトが伸びるほど各トークンの取り分は縮みます。

9.2 同じ問いへの3つの答え: MCP、RAG、ファインチューニング

モデルに必要な知識が欠けるとき、アーキテクチャ上の答えは3つあり、互いを取り違えると相当な労力が誤配分されます。MCPが合うのは知識が 運用的 なとき — 現在の在庫、今日のカレンダー、ビルドのステータス。これらは権威ある出所があり、絶えず変わるので、事前にロードしたコンテキストでは追いつけません。勝つのは新鮮さだけでなくアカウンタビリティ: モデルが「ビルドはグリーン」と言うとき、ユーザーは「何によると」と問え、答えが「このタイムスタンプでビルドサーバーに問い合わせて」と返せる。

RAGが合うのは知識が 文書的 なとき — ウィンドウには大きすぎるが検索インデックスが現実的な程度に安定なコーパス。社内ドキュメント、サポート記事、契約、大規模コードベース。第III巻はRAGの工学を扱い、依然として正典のリファレンスです。ファインチューニングが合うのは欠けているのが 振る舞い のとき — 一貫したフォーマット、特定の声、あるクラスの要求の確実な拒否。業界で繰り返される誤配分は、変わる事実知識をファインチューニングで注入することで、短く印象的なモデルを作り、その後、世界が凍結スナップショットから漂うにつれて徐々に間違いになります。

3つは排他ではありません。成熟したエージェントは普通、組み合わせます: 振る舞いはファインチューニング、文書的知識はRAG、運用的知識はMCP。役立つ枠付けは「正しい新鮮さ要件に正しい基盤を」。振る舞いはモデル世代のスケールで安定 — 重みに焼く。文書的知識は日のスケールで変わる — インデックスする。運用的知識は秒のスケールで変わる — ツール越しに取りに行く。基盤を取り違えるアーキテクチャ — 速く変わる事実に凍結された重み、生の状態に検索インデックス — は、正しさ、レイテンシ、あるいは両方でコストを払います。

9.3 ゴルディロックス・ゾーン: 足りていて、多すぎない

日常の問いは「各呼び出しでどれだけのコンテキストを渡すか」。真ん中のゾーンは、多くのチームが最初に思うより狭い。最も効くレバーはシステムプロンプトです。良いものは短く、具体的で、安定。悪いものは 防御的プロンプト — モデルが行儀悪くするたびに節が足され、ついには千語のルール集になってモデルが確実には従えなくなる。四半期ごとに「削除を目標」として監査するチームは、1年前より短く、より良い振る舞いを生むプロンプトに行き着きます。

2つ目のレバーはツール一覧です。tool-loadout rotの矯正は 段階的開示: 少数の上位ツールを登録し、ディスカバリ・ツール越しにモデルが具体へ降りていけるようにする。40の狭いツールが、内部ディスパッチを持つ4の広いツールになり、ツール選択精度は失ったものをほぼ取り戻します。3つ目のレバーは会話履歴 — ウィンドウ容量の90%ではなく、最初のターンから圧縮する。4つ目はツール結果: モデルが必要なフィールドを返し、行全体ではない。規律は 意図的な包含: どの要素についても、チームは「これがなければエージェントの挙動はどう変わるか」を答えられるべきで、答えが「変わらない」なら外す。

この章を踏まえて

この章は、単一推論呼び出しの中の有限予算としてコンテキストを枠付けしました。扱っていないのは 時間 の問いです。30秒走るエージェントは単一ウィンドウに収まる予算問題を持ちます。30分・3時間・3日走るエージェントは、現実的な大きさのウィンドウでは収まらないメモリ問題を持ちます。その規模の作業の戦略は、程度ではなく種類で違います。

次回 — 第10章: 長期タスクの記憶。 スライディング・ウィンドウとReActスクラッチパッドによる短期記憶、エピソード・ベクトルと意味ストアによる長期記憶、そして数時間・数日にわたってエージェントを生産的に保つ圧縮技術。