9月30日、earendil.comが「"You Said No MCP!"」と題した記事を公開した。AIエージェントハーネス（エージェントの実行・制御を担う基盤フレームワーク）「Pi」の開発チームが、かつて公式に否定していたMCP（Model Context Protocol）をコアアーキテクチャに組み込む決断をした経緯と、その技術的背景を詳述した内容だ。
「手のひら返し」ではなく「内部から形成に加わる」という判断——その言葉の裏には、MCP単体では解決できない課題を独自の仕組みで補完するという、シビアな技術的計算があった。
MCPを「不要」と言っていたチームが翻意した理由
MCPはAnthropicが主導するオープンプロトコルで、LLMに外部ツール（ファイルシステム、API、データベースなど）を接続するための標準仕様だ。2025年以降AIエージェントの文脈で急速に普及し、主要なLLMプロバイダーやツールベンダーが対応を進めている。
Earendilが開発するPiは、AIエージェントを制御・実行するためのハーネスだ。チームは以前、Marioによるブログ記事やポッドキャストを通じて「MCPは不要」という立場を明確に打ち出していた。それが今回、MCPをコアに組み込む方針へと転換した。
翻意のきっかけは、MCP対応に必要な内部変更が、Pi自体の別機能——特に後述する「Codemode」——の改善とまったく同じ方向を向いていると気づいたことだ。つまり、MCP対応と汎用的な内部アーキテクチャ改善が一致していた。
チームはMCPへの批判を撤回したわけではない。記事中で明確に認めているのは、ツールの合成（compose）が難しいという本質的な課題だ。複数のツール呼び出しを柔軟に組み合わせるには依然として大きな工夫が必要で、MCP単体では解決しない。また多くのMCPサーバーはトークン効率を優先してテキストを返す設計になっており、構造化データを扱うOpenAPI的なアプローチとは相容れない設計哲学もある。
それでも転換した理由を、記事はこう表現している。
"We believe the best way to positively influence something is to embrace it."
傍観者として批判するより、内部から議論を形成する方が影響力を持てる——という現実路線だ。
核心：JavaScriptでツール呼び出しを制御する「Codemode」
記事の最も重要な技術的提案がCodemodeだ。一言で言えば、「エージェントがツール呼び出しをJavaScriptコードで記述・制御できる仕組み」である。
通常のエージェントループでは、どのツールをどの順序で呼ぶかはハーネス側のロジックに依存する。LLMはツール名と引数を指定するだけで、実行の流れを細かく制御することはできない。Codemodeでは、LLMがJavaScriptを生成し、そのコードがハーネス側のサンドボックス上で実行される。実行の流れは「LLMがJSコードを生成 → サンドボックスで実行 → 結果をセッショントランスクリプトに格納 → 次のステップへ」という形になっており、ツール呼び出しの順序・並列化・データの受け渡しをコードレベルで明示的に制御できる。
JavaScriptを選んだ理由として記事が挙げるのは、WASM（WebAssembly）バイナリとして小さく配布でき、合理的なサンドボックス保護を確保しやすい点だ。WASMはブラウザやサーバーサイドを問わず安全に実行できるバイナリ形式で、任意コード実行のリスクを抑えやすい。セッション状態はファイルシステムではなくセッショントランスクリプト内に保持される設計になっている。
記事にはCodemodeの実例が掲載されている。Linearのイシュートラッカーから167件のオープンイシューを取得し、「Jev」（Earendilが開発した軽量テキスト分類モデル。感情やカテゴリを少ないトークンで高速に判定することを目的としている）を使って各スレッドのユーザー感情をフラストレーション度合い別に分類するタスクだ。
const { issues } = await tools.mcp__linear__list_issues({
team: "Pi", state: "open", limit: 250,
});
const jev = await models.getModelOfType(
"classifier", "cloudflare-workers-ai", "typesafe/jev",
);
// 4並列でイシューごとにコメントを取得し分類
await Promise.all([worker(), worker(), worker(), worker()]);
CodemodeがMCPツール（Linear）とJevモデルを橋渡しし、4並列で処理する——この構造が重要なのは、大量のコンテキストを消費せずに実行できる点だ。通常のエージェントループで同じ処理をしようとすると、途中経過がすべてコンテキストに積み重なっていく。JavaScriptの制御フローに乗せることで、その問題が回避される。
結果は167件中156件がニュートラル、11件がmild（軽度の不満）、0件がhighだった。「READMEにインストールセクションがない」「Escキー押下後にPiが固まる」といった具体的なフィードバックが上位に挙がっている。
なぜ今この設計が必要になったか
最近のLLMは「遅延ツール読み込み（deferred tool loading）」「会話途中のシステムメッセージ更新」「推論レベルの動的変更」といった高度な機能を持ち始めている。こうした新しいモデル能力に対応するには、ツールのメタデータをより細かく制御できる仕組みが必要になる。
CodemodeなしでMCP拡張を外部実装しようとすると、Piのツール定義から十分なメタデータが取得できず、体験が劣化する。この技術的な要請が、MCPをコアに組み込む直接の動機だ。MCP対応が「外付けの妥協」ではなく「アーキテクチャの一部」として統合された背景には、こうした必然性がある。
Piチームが主張しているのは「MCPがすべての問題を解決した」ではない。「Codemodeがツール合成という本質的な課題を緩和する」「批判するより内部から形成に加わる方がいい」という、課題を認めたうえでの現実的な判断だ。MCPの普及とともにエコシステムが広がる中で、どう関与するかを選んだ結果である。
詳細は"You Said No MCP!"を参照していただきたい。
