第1章 — AI統合の危機と、エージェント型アーキテクチャの台頭

LLM Primer IV: MCPで設計するAI認知 を章ごとに紹介していくウォークスルー、第1回です。2024年に支配的だったパターン — 長いシステムプロンプト、一握りのツール、一つのコンテキストウィンドウにすべてを担わせる — がはっきりした順番で壊れていき、その失敗が指し示すのは、業界が静かに作りつつあったプロトコル層だった、という話からはじまります。

なぜこの章があるのか

2年ほどの間、LLMアプリケーションの標準レシピはこうでした。長いシステムプロンプトを書き、ツールをいくつか付け、それを「エージェント」と呼ぶ。デモは動きました。そして予想どおり、表面積が広がるにつれて壊れていきました。プロンプトは6000トークンを超え、ツールの数は40を超える。チームはパッチを当て、監査し、回帰テストを回し、ある時点で気づきます — 機能を増やすコストが、以前の指数関数倍に膨らんでいる。原因は怠惰でも下手な設計でもありません。すべての関心事を「モデルのコンテキスト」という共有リソース1つに通すアーキテクチャと、その下に隠れていた、もっと深い組み合わせ爆発の問題でした。

この章では、チームが実際に出会う順番で失敗モードを並べ、それぞれに名前を付け、アーキテクチャ的な逃げ道を提示します。逃げ道は2つあります。モデルとツールが事前合意なしに見つけ合うためのプロトコル層、そしてモデルの視界を「自由記述のテキスト欄」ではなく「予算」として扱うコンテキスト工学の規律。両方が本書の残りの土台になります。

1.1 モノリシック・エージェントと、システムプロンプトが最終的に折れる理由

第1世代の本番LLMアプリケーションは、形としては単純でした。数千トークンのシステムプロンプトに、役割、ツール、制約、トーン、例外を書き込む。狭い面では動きました。チームが段落単位で機能を追加していくうちに、プロンプトはコードベースの中で最も長い単一の成果物になり、編集はほぼ「追加」だけ — 何かを消すのが怖いから — になります。

このプロンプトが内部で何をしていたかは、注意(attention)で考えると見えてきます。トランスフォーマーはコンテキスト内のすべてのトークン — システムプロンプトの全トークンを含む — に対して注意の重みを計算します。6000トークンのプロンプトは流し読みされません、平均されます。プロンプトが長いほど、注意の質量は、今のステップに無関係な指示にも広がります。現象には名前があります — コンテキストの希薄化、指示の衝突、能力のドリフト。チームは回帰を観測しますが、原因を局所化できません。なぜなら原因は、2スプリント前に足された一節と新しい3つのルールとの相互作用だからです。

関連する失敗がツール層でも起きます。10個のツールならモデルは正しく選ぶ。40個になると選択精度が落ちる、ときに急激に。チームは曖昧さを解く言葉を足してパッチを当てますが、プロンプトは伸び、注意はさらに希薄化する。システムは自分自身とのフィードバックループに入っています。

1.2 専門化と、間違った向きに曲がるメンテナンスカーブ

プロンプトの問題の下には、もう一段深い問題があります。フロンティアの汎用モデルは強いジェネラリストですが、ジェネラリストの性能は広い表面の平均で、平均は崖を覆い隠します。法務契約レビュー、構造化された医療コーディング、財務照合 — それぞれ内部の語彙、内部のルール、汎用学習が最適化していない誤差許容を持ちます。直感は「プロンプトで専門化させる」ですが、コストは「より多くの注意予算を使って、より少ない見返り」。本物の専門化は、自前の集中したコンテキストを持つ自前のコンポーネントを求めますが、モノリシック・エージェントにはそれを置く場所がありません。

メンテナンスも同じ向きにスケールしません。50個のツールを4ドメインに持つモノリシック・エージェントは、5ツール1ドメインのものの10倍のメンテナンス負担にはとどまりません — それ以上です。すべての機能が、共有プロンプトを通じてすべての機能と相互作用するからです。チームの速度は「既存面を一貫させ続けるコスト」で決まり、「新機能を作るコスト」では決まりません。推論コストはコンテキスト長に比例するので、プロンプトを縮めたい経済圧力と伸ばしたい工学圧力は反対方向に引き合います。

1.3 N×Mの統合問題

分解の必要性を認めるとします。今あなたは、N個のモデルを持つコンポーネントと、M個のツール統合を抱えています。共有プロトコルがなければ、統合コストは N×M — どのモデルもどのツールに対してカスタムアダプタコードを必要とし、モデルの癖×ツールの癖がデカルト積で増えます。新しいモデルが出れば全ツールを再テスト。新しいツールが入れば N 個のアダプタを書く。

計算機の歴史にはこの形に名前があり、解にも名前があります。LSP(2016年)以前、すべてのエディタはすべての言語との統合を必要としました — エディタ×言語。LSPがプロトコルを導入し、行列は加法的コストへ畳まれました。USB以前、周辺機器のカテゴリごとに独自のポートがあり、OSは独自のドライバを抱えていました。USB以降、ホスト1つ、デバイス1つ、その間に共有プロトコル1つ。Model Context Protocolはモデルとツールへ同じ手を当てます。アダプタを消すのではなく、標準化する。最初の統合は遅い、100個目はずっと速い、1000個目はツーリングの蓄積でほぼ無償。勝負は累積カーブの中にあります。

ディスカバリ付きのプロトコルは、もう一つの静かな行列 — 「説明の行列」 — も畳みます。モデルはもう、起動時にすべてのツールをシステムプロンプトに列挙してもらう必要がありません。プロトコルに「今使えるものは何か」と問い、権威ある出所 — サーバー自身 — から構造化されたカタログを受け取ります。

1.4 プロンプト工学からコンテキスト工学へ

アーキテクチャの転換に語彙の転換が追従します。2022〜2023年の規律はプロンプト工学 — モデルを望ましい振る舞いへ寄せる言い回しを探す技術でした。2025年にはプロンプトは多くの入力のうちの一つになりました。モデルは、取得された文書、ツールの説明、過去のターン、ツールの結果、スクラッチパッドのメモ、メモリの断片も見ます。各ステップでコンテキストに何があるべきかは、もはや言い回しでは答えられません。アーキテクチャが、ターンごとにモデルが何を見るべきかを決めます。

定着した呼び名はコンテキスト工学です。コンテキストウィンドウを「管理される予算」として扱います。最新の長文コンテキスト・モデルは100万トークンのウィンドウをうたいますが、コンテキストが埋まるにつれ性能は非線形に劣化します — ときどき context rot と呼ばれる現象です。100万トークンの中に答えを埋めて渡されたモデルは、丁寧に選ばれた1万トークンを渡された同じモデルより、しばしば悪い答えを返します。重要なのはウィンドウサイズではなく、実際にモデルの前にあるものの中の有用な信号の密度です。

MCPは、コンテキスト工学を実用にするためのインフラの一部です。プロトコルがホストに、どのツールとどのデータソースが使えるかを問い、関連するものをその瞬間に取り、モデルが呼び出せる能力を交渉する仕組みを与えます。ホストは現在のタスクが本当に必要としているものをもとに、ターンごとにコンテキストを組み立てます。

この章を踏まえて

診断は3つに分かれます。モノリシック・エージェントは長いプロンプトが注意を希薄化するから壊れる。専門化された能力は共有プロンプトの中に住めない。両者の下にはN×Mの統合問題が居る。3つの失敗モードはどれも同じ方向 — モデルとツールが見つけ合い、説明し合い、できることを交渉する「下の層」 — を指します。第2章はその層を紹介します — MCPが定義する3つの役割、概念的なプリミティブの小さな集合、明示的な能力交渉から始まるセッション・ライフサイクル。

次回 — 第2章: Model Context Protocol の正体。 MCPとは何か、「AI のUSB-C」という言い回しが実際に何を意味するのか、Host・Client・Serverの三役割、動的ディスカバリと双方向メッセージがRESTと違って効いてくる場面。