Pi.dev MCP統合とCodemodeの導入

Pi.devは、モデルコンテキストプロトコル(MCP)をそのコア機能に正式に統合しました。これは、以前のMCPに対する否定的な立場を逆転したものであり、MCPの進化と、ツール呼び出しをより強固にオーケストレーションする仕組みの必要性に応じたものです。Pi.devは、ツールの調整を可能にするJavaScriptベースのサンドボックス「Codemode」を導入することで、この課題に対処しています。

MCPをコアに統合する

Pi.devは、MCPをオプション拡張からコア機能に移行しました。これは、MCPをサポートするために必要なアーキテクチャ変更が、システム全体にとって一般的に有用であることが判明したためです。特に、この統合により、Pi内でJevの利用が容易になり、MCPとPiの両方にとって必要なインタプリタサンドボックスが提供されるようになります。

Pi.devは、MCPがまだ課題を抱えていること(特にコンポジションに関する問題)を認めつつも、現在のプロトコルの状態が初期バージョンよりも大幅に改善されていると見ています。Pi.devのMCPに対するアプローチは、OpenAPIと同様に、ツールが構造化されたデータを返し、ドキュメントや説明から検出可能な「知的なツール発見」を重視しています。

Codemode:新たなオーケストレーション層

Codemodeは、ハーネス側(エージェントループが存在する場所)で実行されるJavaScriptサンドボックスであり、ツール側(bashやその他の外部プロセスが実行される場所)ではなく、その役割を果たします。これは、エージェントがJavaScriptを使って複数のツールをより柔軟に順序立てて実行できるようにするための仕組みです。

Codemodeの主な技術的特徴

  • 実行環境:ハーネスが実行される場所で動作するため、セッショントランスクリプトの一部として状態が維持される一方、ローカルファイルシステム上には保存されません。
  • 実装:WASMバイナリとして配布される小さなJavaScriptバージョンを使用し、保護とパフォーマンスのバランスを実現しています。
  • 自動読み込み:MCPが設定されるとCodemodeは自動的に読み込まれますが、Piの設定でデフォルトツールとして有効化することも可能です。
  • 目的:直接のJSON/XMLツール呼び出し(安全だが制限がある)とBash実行(強力だが内在的なセキュリティや型チェックが欠如)の間の妥協点として機能します。

コンポジション問題の解決

MCPとともにCodemodeを導入した主な理由の一つは、MCPに伴う従来のコンポジション問題を解決することです。JavaScriptサンドボックスを使用することで、モデルがツールをより効果的に連鎖させられるようになります。たとえば、ユーザーは「Codemode経由でtypesafe/jevを使って、私たちのイシュートラッカーで最も不満を感じている20人のコメント投稿者を特定して」と要求でき、システムはLinear MCPとJevを組み合わせて分析を実行し、コンテキストを無駄にすることなく処理できます。

コミュニティの見解と技術的議論

この発表は、開発者コミュニティ内でMCPと従来のCLIベースのツール使用の利点についての技術的議論を引き起こしました。

MCPとCodemodeの利点に関する主張

  • 相互運用性:一部の開発者は、MCPがUSB-Cのように広く互換性のあるエコシステムを提供すると主張しており、少数の「最適」だが断片化された独自ソリューションよりも、広範な採用が価値があると述べています。
  • イテレーティブ開発:MCPは、エージェントが通常、ハードコードされたスクリプトよりもインターフェースの変更に耐性があるため、ツールインターフェースの改善をより迅速に行えるとされています。
  • MCPを構成ツールとして利用:ユーザーは、自然言語で複雑なmacOSアプリケーションをMCPを使って構成し、既存のアプリロジックを活用することで、モデルが複雑なコードをゼロから書く必要がないと報告しています。

反対意見と代替案

  • Codemodeの不要性:一部の批判者は、LLMがすでにBashやPythonスクリプトを使ってツールを効果的に連鎖させられるため、Codemodeは不要だと主張しています。
  • プロトコルに対する批判:一部のユーザーは、MCPがREST APIやOpenAPIの代替であるとし、なぜ標準HTTPプロトコルとして始まらなかったのか疑問を呈しています。
  • 複雑性の懸念:コア統合への移行が、以前は軽量で拡張性の高いハーネスに「肥大化」をもたらすと懸念する声もあります。

"人々が犯した主な誤りは、自分のワークフローとローカルスタックのことを考えすぎ、チーム全体のワークフローと運用スタックのことを考えなかったことだ。" — @CharlieDigital

Sources

関連