MCPでコード実行する設計 — Anthropicが示す「ツール呼び出し」から「コードAPI」への移行

2025年11月4日にAnthropicのエンジニアリングブログが公開した「Code Execution with MCP: Building More Efficient Agents」は、MCP(Model Context Protocol、モデルとツールを繋ぐ標準プロトコル)をエージェントから利用する際の実装パターンを提示した記事です。著者はAdam Jones / Conor Kelly。

要点は1つで、「MCPツールをモデルに直接呼ばせるのではなく、コードとして呼び出させる形にすると、消費トークンが劇的に減る」というものです。記事内ではGoogle DriveからSalesforceへ会議メモを転記する例で、15万トークン → 2,000トークン(約98.7% 削減)という数字が示されています。

本稿では、この記事の主張をClaudeエコシステムの実装文脈で読み解きます。MCPをすでに触っているチーム向けに、どこが新しく、どこが既存のSkills / Agent SDK設計と地続きなのかを整理する立て付けです。MCPの基礎はMCP実用ガイド、エージェント実装側はAgent SDK入門を併読してください。

背景: ツール定義と中間結果がcontext windowを食い潰している

MCPがエコシステムで広がるにつれ、ひとつのエージェントに数百〜数千のMCPツールが接続される設計が現実になってきました。これはMCPの良さでもあるのですが、素朴に実装すると2つのcontext圧迫が起きます。

1つ目はツール定義の前ロードです。MCPホスト(Claude / Claude Code等)がエージェントを起動する時点で、すべての利用可能ツールのdescription / schemaをモデルに読み込ませる実装が一般的です。ツールが10個なら誤差ですが、数百を超えるとそれだけで数万トークンを占有します。

2つ目は中間結果の通り抜けです。Google Drive にある 2 時間の会議トランスクリプトを取り出して、Salesforce のレコードに要約を貼る というシンプルな処理でも、トランスクリプト全文が getDocument の戻り値としてモデルのcontextに流れ込み、続いて updateRecord の引数としてもう一度contextを通過します。同じデータが2回contextを消費し、合計で50,000トークン規模に達することは珍しくありません。

Anthropicの記事は、この2つを一度に解く設計として「ツールをコードとして呼ばせる」を提案しています。

提案: MCPツールをファイルツリーで持ち、コードからインポートさせる

記事ではTypeScriptのファイル構造を用いた具体例が示されています。

servers
├── google-drive
│   ├── getDocument.ts
│   └── index.ts
├── salesforce
│   ├── updateRecord.ts
│   └── index.ts

各MCPツールが、型付きの関数としてファイル単位で配置されます。エージェント側はモデルに「コードを書く」ように指示し、生成されたコードがサンドボックス内で実行されます。実行コードからは import { getDocument } from "./servers/google-drive" のように必要なツールだけを呼び出せます。

この構造によって何が変わるかを、記事の主張に沿って次の4点で見ていきます。

1. Progressive disclosure(必要なツールだけを後から見る)

エージェントはまずファイルツリーを走査して、関連しそうなツールの一覧と概要だけを取得します。中身の型定義や詳細なdescriptionは、実際にそのファイルを read した時にだけcontextへ入ります。記事では「search_tools 関数で関連定義をフィルタする」アイデアも併記されています。

これはClaude CodeのSkill設計とまったく同じ思想です。Claude CodeのSkillは SKILL.md のYAML frontmatterにあるdescriptionだけが起動時にロードされ、本文はエージェントが必要と判断したときに読み込みます。Anthropicがこの設計をMCPツール側にも適用しようと提案している、と読むと位置づけがクリアです。

2. Context-efficient results(中間結果をモデルに見せない)

10,000行のスプレッドシートから5行だけを抽出する、というケースを考えます。従来のMCPでは read_spreadsheet → モデル context に 10,000 行 → モデルが 5 行に絞る という流れになり、フィルタの結論を出すためだけに10,000行ぶんのトークンを消費します。

コード実行を介すると、フィルタリング自体がサンドボックス内のコード(JavaScript / Pythonの filter)で完結します。モデルに返るのは抽出された5行だけです。エージェントは「フィルタロジックを書く」役で、データ量はモデルを通らずに済みます。

3. Control flow(ループ・条件分岐・エラーハンドリングがコードで書ける)

10件のレコードに同じ処理を適用する、エラーが起きたら3回までリトライする、といった制御フローを「ツール呼び出しの連鎖」で表現すると、毎ステップでモデルが推論を回すことになります。コード実行ならば for / try-catch の素朴なコードで書けるため、モデルへの往復回数自体が減ります。

これはlatencyとcostの両方に効きます。マルチエージェントオーケストレーションで「ツール呼び出しが100回続くタスク」が増えてきている現状では、無視できない影響です。

4. プライバシー保護(モデルに見せたくないデータを通さない)

サンドボックス内の中間結果は、明示的に console.log するか return するかしない限りモデルのcontextには入りません。記事は次のように書いています。

The agent only sees what you explicitly log or return, meaning data you don't wish to share with the model can flow through your workflow without ever entering the model's context.

PII(個人を特定できる情報)のトークン化、つまりメールアドレスや電話番号を実行環境内でトークンに置換してからモデルへ渡し、別MCPツールへ渡す段階で復号する、という運用も同じ枠組みで実現できます。これは規制業界(医療・金融)でMCPを本番投入するときの大きな後押しです。

具体例: Google Drive → Salesforceの転記で98.7% 削減

記事の中心となる数値が、冒頭で紹介した150,000 → 2,000トークンです。比較を表にまとめます。

ここで強調しておきたいのは、削減幅の大きさが「2回contextを通すデータ量がどれだけ重いか」に比例して効くことです。短いテキスト1件のコピーであれば差はわずかですが、長文ドキュメント / スプレッドシート / 動画トランスクリプトのような重い中間データを扱うほど削減効果が大きくなります。

逆に言えば、現在の天気を 1 回問い合わせて返答する ような軽量タスクでは、サンドボックスの起動コストの方が上回る可能性があり、本パターンを使う旨味は薄いと言えそうです。

State persistenceとSkills(再利用可能な手順の蓄積)

記事は最後に、サンドボックス内で生成したコードを再利用可能なSkillとして保存する運用にも触れています。「Google Driveのフォルダ内全PDFをSalesforceレコードに紐付ける」のような繰り返し処理を、エージェントが書いたコードごと SKILL.md として保存しておけば、次回以降は同じ手順をモデルに再生成させずに呼び出せます。

これはClaude CodeのSkill仕組み(CLAUDE.md 10パターンで扱った設計思想)と直接接続する話で、ファイルベースのコンテキストエンジニアリングというAnthropic全体の方向性が透けて見える節です。

編集視点: Skill / MCP / Sub-agentの3つは、いずれも「モデルに直接全部を渡さず、必要なときに必要な部分だけ取り出す」という共通の発想で設計されています。Anthropicはこの3つを別々に増築してきましたが、本記事の提案はMCP側をSkill設計に寄せる動きとして読み取れます。

トレードオフ: サンドボックスの運用コスト

明るい話だけではありません。記事は次のように釘を刺しています。

Running agent-generated code requires a secure execution environment with appropriate sandboxing, resource limits, and monitoring. These infrastructure requirements add operational overhead and security considerations that direct tool calls avoid.

エージェントが生成したコードを実行するということは、prompt injection経由で危険なコードが書かれた場合に備えてサンドボックス / リソース制限 / モニタリングを用意する必要がある、ということです。MCPツールを直接呼び出す方式ではホスト側がコール可能なツールを限定すれば防御できますが、コード実行方式ではホスト側で「サンドボックス内で何が走っても安全」を担保しなければなりません。

このトレードオフはClaude Codeを社内エージェント基盤として使うチームにそのまま跳ね返ってきます。詳細はClaude Code完全ガイド2026で扱ったSandboxingの章にも繋がる話です。

Cloudflareの "Code Mode" との関係

記事の脚注に近い形で、Cloudflareが同じ着眼点を「Code Mode」として発表していたことが触れられています。Anthropic / Cloudflare双方が独立に同じ結論に到達している、という事実は、この設計が「Anthropic限定の特殊解」ではなくLLM × ツール統合の共通パターンとして成立しつつあることを示唆します。

MCPの仕様自体は通信プロトコルの定義に留まっていて、ホスト側がツールをモデルにどう提示するかは未定義です。今回の提案はMCPの上にホスト実装パターンを1つ提示したと位置づけられ、長期的にはMCP SDK側に「コード実行モード」のサポートが入る可能性も想像できます(これは推測で、現時点で公式のロードマップ言及はありません)。

「数百ツールを抱えたMCPホスト」の現実解として読み解く

最後に、この記事をClaudeエコシステム全体の流れの中に置いてみます。

2025年中盤までのMCP普及期は「とにかく接続数を増やす」「コミュニティが書いたMCPサーバーを片っ端から試す」という拡張フェーズでした。一方で、エージェント側はcontext windowを食い潰す問題に直面し始め、Skills / Sub-agents / 圧縮(compaction)機能などでcontextの節約を図ってきました。

本記事の提案は、この流れをMCP側にも持ち込む動きです。MCPツールがコードAPIとして再設計されれば、数百のツールを接続しても context は最小限 という構成が現実になります。これは個人開発者よりも、社内に数十〜数百のMCPサーバーを抱える企業利用で効いてくる話です。

実装に踏み込むまでには、以下のような検討事項が残っています。

• どのサンドボックス基盤を使うか(Deno / Bun / Pyodide / Firecrackerなど)
• 既存MCPサーバーをコードAPIとしてどう公開するか(自動生成 / 手動ラッパ)
• 監査ログの粒度をどう設計するか(コード全文vsツール呼び出しのみ)
• prompt injection経由の悪意あるコード生成への防御

Anthropicがこのうちどこまでを公式SDK / ホスト実装でカバーしてくるかは未定です。記事はあくまで設計パターンの提示にとどまっていて、汎用ライブラリの公開は予告されていません。

まとめ

• 本記事はMCPツールを「直接呼び出し」から「コードAPIとして呼ばせる」設計への移行を提案する内容
• Google Drive → Salesforceの例で150,000 → 2,000トークン(98.7% 削減)を提示
• 効果が大きいのは長文 / 大量データを扱うパイプライン。軽量呼び出しでは旨味が薄い
• 運用コストはサンドボックス基盤の構築・監査・防御に跳ね返る
• 思想としてClaude CodeのSkill / Sub-agentと地続きで、Anthropic全体のcontext engineeringの延長線上にある

MCPを業務に組み込んでいるチームにとっては、ツール定義をどう持つか 中間結果をどこで処理するか を再設計する余地があるかを点検する起点になる記事と言えそうです。具体的な実装はMCPホスト側の支援を待つ局面で、今は「コードとして呼ばせる」発想を頭に入れておくのが現実的な距離感に思えます。