🧠 AI プロダクト動向

MCPサーバーへの接続数が増えるほど、エージェントは実際のリクエストを読む前に大量のツール定義を処理することになる。Anthropicの公式エンジニアリングブログは、数千のツールに接続したエージェントは「リクエストを読む前に数十万トークンを処理する必要がある」と説明し、さらにツール呼び出しの結果（例えば2時間の会議の文字起こし）がモデルのコンテキストを2回通過することで5万トークン以上が追加消費される例を挙げている。

この無駄を解消する方法としてAnthropicが示したのが、MCPツールを直接呼び出すのではなく./servers/google-drive/getDocument.tsのようなコードAPIとしてファイルシステム上に提示し、エージェントにコードを書かせて操作させる方式だ。モデルはファイルシステムの探索が得意なため、必要なツール定義だけをオンデマンドで読み込め、結果もコード内でフィルタしてから返せる。中間状態や再利用可能な処理は「スキル」としてファイルに永続化できる。

Cloudflareは公式ブログで、AnthropicのCode Executionと同じアーキテクチャに独立に到達したと明かしている。根拠は「LLMは現実のコードを大量に学習しているが、ツール呼び出しの例は限られた作り物にすぎず、コードを書かせる方が得意」という洞察で、MCPツールをTypeScript APIへ変換しLLMにコードを書かせ、サンドボックス化された隔離環境でミリ秒単位の起動時間で実行する。異なる2社が独立に同じ結論に達したことは、この設計が特定ベンダーの都合ではなく構造的な必然であることを示している。

一方Anthropicはコード実行とは別に、既存のtool-calling形式を変えずに済む代替案として「Tool Search Tool」も公式に提供している。BM25または正規表現でツール定義そのものを検索し、一致したツールだけをdefer_loading: true指定で遅延ロードする仕組みで、コード実行基盤を持たないクライアントでも導入できる。両者は排他的な選択肢ではなく、任意のコードを書かせられるかどうかで使い分けるものだ。

Klavisは公式ブログで、数千のツールを一つのMCPサーバー（Strata）の裏に集約し、エージェントの問い合わせを「意図の表明 → カテゴリ選択 → アクション名の一覧 → スキーマ取得」という4段階に強制する設計を公開した。各段階で得られる情報は最小限に絞られ、エージェントが実際に実行するアクションを確定させるまで完全な入力スキーマは渡されない。

この段階分けは、AnthropicやCloudflareが示したコード実行・検索遅延ロードと発想は同じだが、クライアント側の実装を変えずにMCPサーバーを差し替えるだけで導入できる点が異なる。Klavisはこの構成で60〜80%のコンテキスト削減と13〜15%の精度向上を報告しており、既製品としての「遅延ロードゲートウェイ」という選択肢が実用段階にあることを示している。