Pi、Codemodeサンドボックスでツールを隠蔽しMCPトークンの肥大化を削減
Pi 1.0はMCPサーバーを統合しましたが、ツール定義をプロンプトから除外し、JavaScriptサンドボックスを使用して必要な時だけツールの検出と実行を行います。
英語の原文から自動翻訳されました。
Mario Zechnerが開発したコーディングエージェント「Pi」が、過去1年間の大部分において排除してきたModel Context Protocol（MCP）を、ついにコアアーキテクチャに統合しました。今年初めにEarendilによる買収を経てリリースされたPi 1.0では、標準的なMCP実装に伴う重いコンテキストコストに対処するための新しい手法が導入されています。
この統合は、すべてのサーバーツールを大規模言語モデル（LLM）に直接公開するという従来のアプローチには従いません。代わりに、Piは「Codemode」と呼ばれる内部メカニズムを用いてアクセスを仲介し、特定のタスクで明示的に必要になるまでツール定義を非表示に保ちます。
背景
昨年を通じて、Zechner氏はMCPが開発者ツール間で標準となりつつあるにもかかわらず、PiへのMCPサポート追加を拒み続けていました。彼の躊躇は具体的なパフォーマンス指標に基づいていました。人気のあるブラウザ自動化サーバーを測定した際、Chrome DevToolsをMCP経由で接続すると約18,000トークンを消費することが判明しました。これは、エージェントが有用な作業を行う前に、20万トークンのコンテキストウィンドウの約9%を占めてしまう計算です。
他のツールも同様の負担がありました。Playwright MCPは21個のツールを記述するために約13,700トークンを必要とし、同じコンテキストウィンドウの6.8%を消費していました。サーバーを追加するたびにオーバーヘッドが増え、実際のコードや推論に利用可能なスペースが減少します。Zechner氏はまた、標準的なMCPセットアップにおけるコンポーザビリティ（組み合わせ可能性）の欠如を批判し、サーバーから返される結果を永続化したり他のデータと結合したりするには、エージェントのコンテキストを経由しなければならない点を指摘しました。
この期間中、Piはブラウザ自動化のためにBashスクリプトとコマンドラインインターフェースに依存していました。これらのツールはモデルがすでに使用方法を理解していたため、わずか225トークンのREADMEで済みました。出力はパイプ処理、フィルタリング、またはディスクへの保存が可能であり、モデルのコンテキストウィンドウを詰まらせることはありませんでした。pi-mcp-adapterなどのコミュニティ拡張機能により、ユーザーはMCPをPiにブリッジできましたが、ネイティブサポートは欠如したままでした。
今年初めにPiを買収したEarendilは、MCPを見直すことを決定しました。同社は、プロトコルが成熟し、それを効果的にサポートするために必要なアーキテクチャ変更が広範に有用であると述べました。Pi 1.0は標準的な公開モデルを採用するのではなく、既存のCodemodeインフラストラクチャを通じてMCPを実装することで、Zechner氏が当初反対していたコンテキストの肥大化を回避しつつ、プロトコルをサポートしています。
仕組み
Codemodeは、言語モデルとその利用可能なツールの間に位置する中間層として機能します。QuickJSサンドボックス内で動作するため、Node API、ファイルシステムアクセス、ネットワーク接続、タイマーなしで運用されます。この隔離された環境により、スクリプトはPiのツールやモデルを呼び出し、操作を並行して実行し、メインモデルに何かを返す前に結果を処理できます。
デフォルトでは、PiはMCPサーバーのツール定義をモデルのプロンプトから除外します。システムプロンプトには、接続されている各サーバーの一行の説明のみが含まれます。エージェントがタスクを実行する必要がある場合、Codemodeを使用して適切なツールを検出し、JavaScript経由で実行し、関連する出力のみを返します。このアプローチにより、初期コンテキストは軽量に保たれ、トークン使用量は潜在的な能力ではなく、実際のアクティビティに応じてスケールすることが保証されます。
開発者はtoolExposureという設定を使用することで、この挙動をカスタマイズできます。この機能により、ツールの提示方法に対する細かな制御が可能になります。例えば、GitHub統合では、頻繁に使用するsearch_codeツールをモデルに直接公開し、オンデマンドでの検出用にget_*メソッドをCodemodeの裏側に保持し、誤ったデータ損失を防ぐためにdelete_*メソッドを完全にブロックするといったことが可能です。この柔軟性により、エンジニアは利便性と安全性・効率性のバランスを取ることができます。
主要な詳細
- Chrome DevTools MCPは以前、アクションを実行する前に約18,000トークン、つまり20万コンテキストウィンドウの9%を消費していました。
- Playwright MCPは21個のツールを記述するために約13,700トークンを必要とし、同じコンテキストウィンドウの6.8%を占めていました。
- Codemodeは、Node API、ファイルシステム、ネットワーク、タイマーアクセスなしのQuickJSサンドボックス内で実行されます。
- Pi 1.0は、GPT-5.6リクエストにおけるデフォルトのCodemodeフットプリントを、約5,300プロンプトトークンから約3,300に削減します。
- ツール宣言用にデフォルトで3,000トークンの予算が割り当てられており、超過分のツールはCodemode経由で検出可能のまま残ります。
toolExposure設定により、開発者はサーバーごとに特定のツールを公開、非表示、またはブロックできます。
重要性
AIエージェントを構築するエンジニアにとって、コンテキストウィンドウの効率は重要な制約です。ツール定義に費やされるすべてのトークンは、コード分析、推論、履歴に利用できないトークンを意味します。MCPツールをデフォルトで非表示に保つことで、Piはパフォーマンスを犠牲にすることなく豊かなエコシステムをサポートする現実的な道を示しています。この手法により、エージェントは数十のサーバーに接続しても即座にコンテキスト予算を使い果たすことなく、より複雑でマルチステップなワークフローを実現できます。
toolExposureによって提供される細かな制御は、セキュリティおよびユーザビリティに関する懸念にも対応します。すべてのツールをモデルに直接公開すると、リソースの削除や不正な変更など、意図しないアクションのリスクが高まります。重要度の低いツールや危険なツールをCodemode経由に強制することで、開発者は審査と処理の層を追加できます。このパターンは、一律の公開モデルを受け入れるのではなく、ツールアクセスをエージェントの特定のニーズに合わせて調整する、より慎重な設計を促進します。
推奨事項
- 現在のMCP統合を監査し、プロンプト内のツール定義のトークンコストを測定してください。
- Codemodeと同様の仲介層を実装し、ツール呼び出しをインターセプトして、モデルに到達する前に結果を処理してください。
- QuickJSのようなサンドボックス化された環境を使用し、完全なシステムアクセスを付与せずにツールロジックを安全に実行してください。
- ツールの細かな公開設定を構成し、あまり使用されない関数や高リスクな関数を検出メカニズムの裏に隠してください。
- ツールの説明とドキュメントを厳格なトークン予算内に収まるよう最適化し、冗長な宣言を削除してください。
- ツールを非表示にすることがエージェントのパフォーマンスに与える影響をテストし、検出遅延がユーザー体験を妨げないことを確認してください。
