はじめに
AIエージェントにツールを持たせるほど、コンテキストウィンドウが圧迫される。MCP(Model Context Protocol)サーバーが提供するツール定義は1つあたり数百トークンを消費し、エンドポイントが100を超えるAPIでは定義だけで数十万トークンに達する。Cloudflare APIの場合、2,500超のエンドポイントをMCPツールとして公開すると 約117万トークン が必要になる。これはほとんどのモデルのコンテキストウィンドウを超える量である。
この問題に対してCloudflareが提案した Code Mode は、ツール定義をコード実行インターフェースに置き換えることで、同じAPI全体をわずか 約1,000トークン で扱えるようにする手法である。トークン消費量を 99.9%削減 するこのアプローチは、Anthropicのエンジニアリングチームも独立して検証し、98.7%の削減効果を確認している。
この記事では、Code Modeの仕組み・アーキテクチャ・実装方法を公式情報に基づいて解説する。
この記事で学べること
- MCPツール定義がコンテキストウィンドウを圧迫するメカニズム
- Code Modeの2ツールアーキテクチャ(
search()/execute()) - V8サンドボックスによるセキュアなコード実行の仕組み
- Cloudflare Agents SDKを使った実装パターン
- Anthropicが提唱するコード実行型MCPのベストプラクティス
対象読者
- MCPサーバーを構築・運用しているエンジニア
- AIエージェントのコスト最適化に取り組んでいる方
- Cloudflare Workers / Agents SDKに関心がある方
TL;DR
- MCPツール定義はエンドポイント数に比例してトークンを消費し、大規模APIでは100万トークン超になる
- Code Modeは
search()とexecute()の2ツールだけでAPI全体をカバーし、トークン消費を99.9%削減する - LLMはツールコール形式よりもTypeScript/JavaScriptコード生成の方が精度が高い
-
@cloudflare/codemodeパッケージのcreateCodeTool()関数で既存ツールをCode Mode対応にできる - Anthropicも同じパターンを独立検証し、98.7%のトークン削減を確認
従来のMCPツールコールが抱える3つの問題
Code Modeの設計意図を理解するために、まず従来のMCPツールコールの課題を整理する。
1. コンテキストウィンドウの浪費
MCPサーバーは接続時にツール一覧(名前・説明・パラメータスキーマ)をクライアントに送信する。エージェントはこれをすべてコンテキストウィンドウに載せる必要がある。
| API規模 | ツール数 | 推定トークン消費 |
|---|---|---|
| 小規模API | 10ツール | 約3,000トークン |
| 中規模API | 50ツール | 約15,000トークン |
| 大規模API(Cloudflare) | 2,500+ツール | 約117万トークン |
ツールが増えるほど、実際のタスクに使えるコンテキストが減少する。
2. ツールチェーンの非効率性
従来のツールコールでは、各ステップの出力がLLMのコンテキストに戻され、次のツールコールの入力として処理される。3つのAPIを連続呼び出しする場合、中間結果がすべてLLMの推論パイプラインを通過する。Cloudflareの公式ブログによると、「各ツールコールの出力がLLMのニューラルネットワークに投入され、次のコールの入力にコピーされる」という往復が発生し、時間・エネルギー・トークンを浪費する。
3. 学習データとのミスマッチ
LLMは数百万のオープンソースコードで訓練されているが、MCPツールコールのスキーマ形式はほとんど学習データに含まれていない。Cloudflareはこれを「シェイクスピアに1か月の中国語講座を受けさせてから、中国語で戯曲を書かせるようなもの」と表現している。コード生成は既存の学習データを最大限に活用できるが、ツールコール形式では能力が制限される。
Code Modeのアーキテクチャ
Code Modeの核心は、 ツール定義の配列をコード実行インターフェースに置き換える ことにある。
2ツール構成
Code Modeが提供するのは search() と execute() の2つだけである。
search() ツール: エージェントがJavaScriptを記述し、OpenAPI仕様の型付き表現に対してフィルタリングを実行する。全エンドポイントをコンテキストに載せるのではなく、必要なエンドポイントだけをオンデマンドで発見する。
// search() の実行例: WAF関連エンドポイントの発見
async () => {
const results = [];
for (const [path, methods] of Object.entries(spec.paths)) {
if (path.includes('/zones/') &&
(path.includes('firewall/waf') || path.includes('rulesets'))) {
for (const [method, op] of Object.entries(methods)) {
results.push({
method: method.toUpperCase(),
path,
summary: op.summary
});
}
}
}
return results;
};
このコードは2,500超のエンドポイントからWAF関連の操作だけを抽出する。フルスキーマをコンテキストに載せる必要がない。
execute() ツール: 発見したエンドポイントに対して、認証済みAPIリクエストを実行する。複数のAPI呼び出しをチェーンし、ページネーション処理、レスポンス検証、条件分岐を1回の実行で完結できる。
// execute() の実行例: ルールセット一覧の取得
async () => {
const response = await cloudflare.request({
method: "GET",
path: `/zones/${zoneId}/rulesets`
});
return response.result.map(rs => ({
name: rs.name,
phase: rs.phase,
kind: rs.kind
}));
};
段階的開示(Progressive Disclosure)
Code Modeのもう一つの特徴は 段階的開示 である。従来のMCPでは接続時にすべてのツール定義をロードするが、Code Modeではエージェントが必要な時に必要な情報だけを取得する。
Anthropicのエンジニアリングブログでは、これをファイルシステム型のツール発見モデルとして説明している。
servers/
├── cloudflare-api/
│ ├── zones.ts # ゾーン管理
│ ├── dns.ts # DNS操作
│ ├── waf.ts # WAF設定
│ └── index.ts # サーバー一覧
├── google-drive/
│ ├── getDocument.ts
│ └── index.ts
エージェントはディレクトリを探索するようにツールを発見し、必要なTypeScript定義だけをロードする。
V8サンドボックスによるセキュリティ
Code Modeの実行環境は、Cloudflare WorkersのDynamic Worker Loaderを利用したV8アイソレートである。
| セキュリティ制約 | 内容 |
|---|---|
| ファイルシステム | アクセス不可 |
| 環境変数 | 非公開 |
| 外部通信 |
fetch() / connect() はデフォルトでエラー |
| API認証情報 | スーパーバイザーが保持、コードからはアクセス不可 |
| 実行時間 | リソース制限あり |
V8アイソレートの起動は数ミリ秒、メモリは数MBで済むため、コードスニペットごとに新しいアイソレートを生成してもオーバーヘッドは最小限である。
認証情報はエージェントのスーパーバイザープロセスが管理し、生成されたコードからは直接アクセスできない。MCPサーバーへの呼び出しはRPCレイヤーを通じてルーティングされる。
トークン削減の定量的効果
CloudflareとAnthropicが公開しているデータを整理する。
Cloudflareの検証結果
| 方式 | トークン消費 | 削減率 |
|---|---|---|
| 従来のMCPツール定義(2,500+エンドポイント) | 約117万トークン | — |
| Code Mode(search + execute) | 約1,000トークン | 99.9% |
Anthropicの独立検証
Anthropicは自社エンジニアリングブログで、コード実行パターンを独立して検証した結果を公開している。
| シナリオ | 従来方式 | コード実行方式 | 削減率 |
|---|---|---|---|
| 大規模スプレッドシート処理 | 15万トークン | 2,000トークン | 98.7% |
Anthropicの検証では、10,000行のスプレッドシートデータをフェッチして特定条件でフィルタリングするタスクにおいて、従来のツールコールではデータ全体がLLMのコンテキストを通過するが、コード実行環境ではローカルでフィルタリングし、最終結果の5件だけをモデルに返す。
@cloudflare/codemode パッケージでの実装
Cloudflareは @cloudflare/codemode パッケージとして、Code Modeの実装を公開している。AI SDK互換のツールとして既存のワークフローに組み込める。
インストール
npm install @cloudflare/codemode ai zod
基本的な導入
import { createCodeTool } from "@cloudflare/codemode/ai";
import { DynamicWorkerExecutor } from "@cloudflare/codemode";
import { streamText } from "ai";
// V8サンドボックスの実行環境を作成
const executor = new DynamicWorkerExecutor({
loader: env.LOADER, // Worker Loaderバインディング
timeout: 30000, // 実行タイムアウト(ms)
globalOutbound: null, // 外部通信をブロック
});
// 既存のツール定義をCode Modeに変換
const codeModeTool = createCodeTool({
tools: {
listZones: { /* AI SDKのtool()定義 */ },
createDNSRecord: { /* ... */ },
updateWAFRule: { /* ... */ },
},
executor,
});
// AI SDKと組み合わせて使用
const stream = streamText({
model: openai("gpt-5"),
tools: { code: codeModeTool },
messages: userMessages,
});
createCodeTool() は内部でツール定義をTypeScript型定義に変換し、LLMがコードを記述して実行できる単一のツールに集約する。
MCPサーバーへの接続設定
Cloudflare MCPサーバーを利用する場合は、クライアント側の設定だけで導入できる。
{
"mcpServers": {
"cloudflare-api": {
"url": "https://mcp.cloudflare.com/mcp"
}
}
}
認証はOAuth 2.1準拠のフローで行われ、ユーザーが承認したスコープのみがトークンに付与される。
サーバーサイドCode Modeの特徴
Code Modeにはクライアントサイド実装とサーバーサイド実装の2パターンがある。
| 特性 | クライアントサイド | サーバーサイド |
|---|---|---|
| サンドボックス | エージェント側に必要 | サーバー側で提供 |
| トークンコスト | 固定 | 固定 |
| エージェント側の変更 | 必要 | 不要 |
| 段階的開示 | 実装依存 | 組み込み |
| セキュリティ | エージェントに依存 | V8アイソレートで担保 |
サーバーサイドCode Mode(Cloudflareの方式)は、エージェント側の変更が不要でセキュリティも担保される点が大きな利点である。
業界の動向:MCPツールコール方式への疑問
Code Modeの登場と同時期に、MCPツールコール方式への疑問を呈する動きが業界で広がっている。
Perplexityの方向転換
2026年3月11日のAsk 2026カンファレンスで、Perplexity CTOのDenis Yarats氏がMCPからの内部的な脱却を発表した。主な理由として、ツールスキーマによるコンテキストウィンドウの圧迫と、各MCPサーバーが個別に認証フローを処理する複雑さを挙げている。
Perplexityの代替策は、2026年2月に一般提供を開始した Agent API である。OpenAI互換の構文で、1つのAPIキーで複数モデル(OpenAI・Anthropic・Google・xAI・NVIDIA)にアクセスでき、Web検索などのツールもビルトインで提供する。
ただし、Perplexityの動きはMCP自体の否定ではなく、自社のユースケース(単一エージェント・既知のツールセット)に最適化した判断であり、開発者向けMCPサーバーは引き続き提供している。
Cloudflareの技術的指摘
Cloudflareはより技術的な分析を公開している。指摘された問題は以下の3点である。
- トークン浪費: ツール定義とツールコール結果がコンテキストを圧迫する
- 学習データとのミスマッチ: LLMはコード生成に最適化されているが、ツールコール形式の訓練データは少ない
- 合成の困難さ: ツールチェーンでは変数・ループ・エラーハンドリングが使えない
Code Modeはこれら3つの問題すべてに対処する設計になっている。
Code Mode導入の判断基準
Code Modeはすべてのケースで最適というわけではない。公式ドキュメントとエンジニアリングブログの情報を基に、導入判断の基準を整理する。
Code Modeが有効なケース
- ツール数が多い: 50以上のエンドポイントを持つAPI
- ツールチェーンが発生する: 複数のAPI呼び出しを連続実行するワークフロー
- データフィルタリングが必要: 大量データの取得後にローカルで絞り込むタスク
- コスト最適化が重要: トークン消費の削減が直接的なコスト削減につながる環境
従来のMCPツールコールが適しているケース
- ツール数が少ない: 10以下のシンプルなツールセット
- 単純なCRUD操作: 1回のAPI呼び出しで完結するタスク
- コード実行環境の構築が困難: サンドボックスの運用コストが見合わない場合
まとめ
Code Modeは、MCPのツール定義がコンテキストウィンドウを圧迫するという構造的な問題に対する解決策である。Cloudflareの実装では2,500超のエンドポイントを1,000トークンで扱え、Anthropicの独立検証でも98.7%のトークン削減が確認されている。
要点を整理すると以下のとおりである。
- 根本的なアプローチの転換: ツール定義の配列 → コード実行インターフェース
- LLMの強みを活用: コード生成はLLMが最も得意とするタスクの1つ
- セキュリティの担保: V8アイソレートによるサンドボックス実行
-
段階的な導入が可能: 既存のMCPサーバーに
codemode()を追加するだけで対応できる
MCPエコシステム自体は成長を続けているが、ツール数の増加に伴うコンテキスト問題は今後ますます深刻化する。Code Modeのようなコード実行パターンは、エージェント開発のスケーラビリティを確保するための重要なアプローチの1つとなる。



