MCPのCode Executionで本当にトークンは減る?直接呼び出しとの損益分岐を試算【2026年版】
MCPのCode Execution(コードモード)でトークンが減る処理・増える処理を、Claude 5.5の料金で試算。一括照会・大きな結果・逐次呼び出しの比較、損益分岐の計算式、4つの実装方法、Programmatic Tool Callingの制約、効果の測り方まで解説します。
最終更新:2026年10月14日 / 対象:Anthropic APIのProgrammatic Tool Calling(
code_execution_20260120/code_execution_20260521)、Claude 5.5の料金、MCPのコード実行パターン
MCPのCode Execution(コード実行、「コードモード」とも呼ばれます)は、複数のMCPツール呼び出しをモデルが書いた1本のスクリプトにまとめ、途中の結果をコンテキストに載せずに処理する方法です。MCPのトークン消費を大きく減らせる一方、どんな処理でも得をするわけではありません。この記事では、どんなときにトークンが減り、どんなときに逆に増えるのかを、計算例を使って具体的に確かめます。
結論(30秒で読める要約)
- Code Executionでトークンが減るのは、ツールの結果が大きいとき、または呼び出し回数が多いときです。Anthropicのドキュメントでは、75ツールのエージェントのベンチマークで課金対象の入力トークンが約38%減った一方、1ターンに1〜2回の逐次呼び出しをするτ²-benchではコストが約8%増えています。
- 仕組みとしては、モデルが書くスクリプト(出力トークン)とコンテナの実行時間という小さな固定費を払い、その代わりに生のツール結果をコンテキストから外します。
- 筆者の試算では、Claude 5.5の料金と後述の前提で、生の結果がスクリプトの返す量より約2,500トークン多ければ、並列の直接呼び出しよりCode Executionのほうが安くなります。
- Sonnet 5.5での3つの試算では、20件の一括照会で69%安く、4万トークンの結果1件の絞り込みで57%安く、依存関係のある小さな呼び出し2回では約4.5%高くなりました。
- 判断はエージェント単位ではなくツール単位で行います。一覧取得・検索・エクスポートのようにデータ量の多いツールはコード経由にし、途中でモデルの判断やユーザーの確認が必要なツールは直接呼び出しのまま残します。
目次
- MCPのCode Executionとは
- なぜMCPのトークン消費が変わるのか
- Code Executionと直接呼び出しのトークン比較(計算例)
- 損益分岐の計算式
- 向いている処理・向いていない処理
- MCPでCode Executionを実装する4つの方法
- 実装例(Anthropic API)
- 自分の環境で効果を測る方法
- よくあるハマりどころ
- NodeFlareならこう解決できる
- よくある質問
1. MCPのCode Executionとは
MCPのCode Executionとは、モデルがツール呼び出しを1ターンに1回ずつ出すのではなく、サンドボックス内で動くコードからMCPツールを呼び出すやり方です。Anthropicが2025年11月に「エージェントはツールを直接呼ぶより、ツールを呼ぶコードを書いたほうがスケールする」という趣旨で紹介し、Cloudflareも同じ結論に達して「Code Mode」と名付けています。
AnthropicのAPIでは、これが Programmatic Tool Calling として提供されています。allowed_callers: ["code_execution_20260120"] を付けたツールは、コード実行コンテナの中でPythonの非同期関数として呼べるようになります。ドキュメントには「プログラムから呼び出したツールの結果は入出力トークンの使用量に数えない。数えるのはコード実行の最終結果とClaudeの応答だけ」と書かれています。
ここでいう「トークン」はLLMのトークン(コンテキストと課金の単位)のことです。MCPのトークン消費の全体像と7つの削減方法は、MCPのトークン消費の解説記事にまとめています。
2. なぜMCPのトークン消費が変わるのか
ツールを直接呼ぶと、呼び出すたびに増えるコストが2つあります。Code Executionは、そのうち2つ目をなくし、1つ目を小さくします。
| コスト | 直接呼び出し | Code Execution |
|---|---|---|
| モデルのターン数 | 逐次処理の1ステップごとに1ターン | 通常はスクリプトを書く1ターンと回答の1ターン |
| 生のツール結果 | すべての結果が載り、以降のターンで毎回読み直される | スクリプトが出力・返却したものだけ |
| ツール呼び出しの引数 | モデルが毎回書く(出力トークン) | スクリプトの中で1回書くだけ |
| 固定費 | ツール定義以外にはない | スクリプト(出力トークン)とコンテナの実行時間 |
効いてくるのは「読み直し」です。直接呼び出しのループでは、結果が会話履歴に追加され、その後のターンでは履歴全体が毎回入力として送られます。3,000トークンの結果を10件、10ターンかけて扱うと、合計は3万トークンでは収まりません。Anthropicのドキュメントにも「10個のツールを直接呼ぶと、プログラムから呼んで要約だけ返す場合の約10倍のトークンを使う」とあります。
3. Code Executionと直接呼び出しのトークン比較(計算例)
よくある3つの処理をモデル化して試算しました。Anthropicの計測値ではなく筆者の計算です。自分の数字で計算し直せるよう、計算方法も表の下に書いています。
前提(全シナリオ共通):システムプロンプトとユーザーの指示で2,000トークン、ツール定義で10,000トークン、Anthropicが公表しているClaude 5.5のツール利用時のシステムプロンプト286トークン、直接呼び出し1回の引数は出力60トークン、最終回答は300トークン、プロンプトキャッシュは使わない、とします。料金はClaude Sonnet 5.5の入力100万トークンあたり2ドル、出力100万トークンあたり10ドル(2026年10月時点のAnthropic料金ページ)です。コード実行ツール自体の定義のトークンは含めていないため、実際の環境では別途測ってください。
| シナリオ | 方式 | 入力トークン | 出力トークン | 費用(Sonnet 5.5) |
|---|---|---|---|---|
| A. 20件を照会(1件3,000トークン) | 直接・逐次(21ターン) | 900,606 | 1,500 | $1.8162 |
| 直接・並列(2ターン) | 85,772 | 1,500 | $0.1865 | |
| Code Execution(スクリプト400、返却500トークン) | 25,472 | 700 | $0.0579 | |
| B. 4万トークンの結果1件から要約だけ残す | 直接(2ターン) | 64,632 | 360 | $0.1329 |
| Code Execution(スクリプト300、返却500トークン) | 25,372 | 600 | $0.0567 | |
| C. 依存関係のある呼び出し2回(各300トークン) | 直接・逐次(3ターン) | 37,938 | 420 | $0.0801 |
| Code Execution(2回実行、スクリプト各200トークン) | 38,358 | 700 | $0.0837 |
計算方法:各ターンの入力は「システムとユーザーの指示(2,000)+ツール定義(10,000)+286+それまでの会話履歴」です。直接呼び出しでは、呼び出しごとに引数と結果が履歴に加わります。Code Executionでは、1ターン目でスクリプトを書き(出力)、2ターン目ではスクリプトとその返り値だけを読みます。プログラムから呼んだツールの結果は課金されないためです。費用は「入力÷100万×2ドル+出力÷100万×10ドル」で求めました。たとえばシナリオAのCode Executionは、25,472×2÷100万+700×10÷100万=0.0509+0.0070=0.0579ドルです。
表から分かること:
- シナリオA:Code Executionは並列の直接呼び出しより69%安くなります(0.0579ドル対0.1865ドル)。最も高いのは逐次の直接呼び出しで1.82ドルです。結果を最大20回読み直すためです。
- シナリオB:大きな結果をサンドボックス内で絞り込むと57%安くなります(0.0567ドル対0.1329ドル)。Anthropicの記事にある「1万行のスプレッドシートのうち5行だけをモデルに見せる」例と同じ構図です。
- シナリオC:Code Executionのほうが約4.5%高くなります(0.0837ドル対0.0801ドル)。1回目の結果を見てから2回目の呼び出しを決める必要があるため往復が減らず、スクリプトの出力トークンだけが増えます。τ²-benchで約8%高くなったというAnthropicの結果と同じ傾向です。
コンテナの実行時間:リクエストにWeb検索やWebフェッチを含めない場合、Anthropicはコード実行を時間で課金します。1回あたり最低5分、組織ごとに毎月1,550時間までは無料、それを超えると1コンテナ1時間あたり0.05ドルです。筆者の計算では、無料枠を超えた5分の実行は5÷60×0.05≒0.0042ドルで、Sonnet 5.5の入力トークン約2,100個分に当たります。無料枠は1,550÷(5÷60)=18,600回分の5分実行に相当します。なお web_search_20260209 か web_fetch_20260209(またはそれ以降)を含めたリクエストでは、コード実行は無料です。
4. 損益分岐の計算式
並列の直接呼び出し1ターンと比べたとき、Code Executionが得になるのは「コンテキストから外せる入力トークン」が「余分に書く出力トークン」を上回るときです。
節約量(入力トークン換算)=
[ N × (a + r) − S − R ] # 2ターン目から外せる入力
− k × [ S − N × a ] # 増える出力トークン(価格で重み付け)
N:ツール呼び出し回数、r:結果1件の平均サイズ、a:直接呼び出し1回あたりの引数のトークンS:スクリプトの長さ、R:スクリプトが返す量k:出力単価÷入力単価。Claude Opus 5.5(4ドル/20ドル)、Sonnet 5.5(2ドル/10ドル)、Haiku 5.5の10万トークン以下のプロンプト(0.10ドル/0.50ドル)はいずれもk = 5です。
節約量を0とおくと N × r = 6S + R − 6N × a になります。呼び出し1回、スクリプト400トークン、返却500トークン、引数60トークンなら、6×400+500−360=2,540トークンです。この前提では、生の結果が返却量より約2,500トークン多くなるとCode Executionが得になります。無料枠を超えている場合はコンテナの費用を、さらにコード実行ツール自体の定義のトークンも加えて考えてください。
逐次の直接呼び出しと比べる場合は、減らせる1ターンごとに会話履歴全体の読み直しも減るため、損益分岐はずっと低くなります。
5. 向いている処理・向いていない処理
Anthropicのドキュメントは、向いている処理と向いていない処理を挙げています。下の表では、それぞれがMCPのトークン消費にどう効くかを補っています。
| 処理 | 向き不向き | 理由 |
|---|---|---|
| 多数の対象への一括処理(50個のエンドポイント確認、20件の照会など) | 向いている | 多くの結果がサンドボックス内にとどまり、N回の往復が1回になる |
| 絞り込みや集計ができる大きな結果(ログ、エクスポート、表計算) | 向いている | 絞り込んだ行だけがコンテキストに届く |
| エージェントによる検索・情報収集 | 向いている | 繰り返しの検索と絞り込みをコードで行える。AnthropicはBrowseCompとDeepSearchQAで入力トークンが24%減ったと報告 |
| ポーリングや待機(デプロイ完了を待つなど) | 向いている | ループと待機をモデルのターンではなくコードで回せる |
| 毎回前の結果を見て判断する必要がある逐次処理 | 向いていない | スクリプトではモデルとの往復を省けない |
| 小さな結果の呼び出しが数回だけ(特に会話の最初のターン) | 向いていない | スクリプトとコンテナの固定費が節約分を上回りうる |
| 呼び出しのたびにユーザーの確認が必要なツール(支払い、削除など) | 向いていない | どのみち人が各ステップを確認する |
実際の利用での目安として、Anthropicの本番トラフィックでは、ツール定義が10〜49個のリクエストでProgrammatic Tool Callingを有効にすると、20〜40%程度トークンが減るのが一般的だとされています。
6. MCPでCode Executionを実装する4つの方法
サンドボックスを置く場所は4通りあります。誰が運用するか、手持ちのMCPツールをそのまま使えるかが違います。
| 方法 | コードが動く場所 | 既存のMCPサーバーで使えるか | 主なトレードオフ |
|---|---|---|---|
| AnthropicのProgrammatic Tool Calling | Anthropicのコード実行コンテナ(Python) | クライアント側でMCPツールをカスタムツールとして渡せば使える。AnthropicのMCPコネクタ経由のツールはプログラムから呼べない | 一時停止したツール呼び出しをすべてクライアントで処理する。ZDRの対象外 |
| クライアント側でのコード実行(Anthropicのファイルツリー方式) | エージェントの横に自前で用意したサンドボックス | 使える。ツールを ./servers/google-drive/getDocument.ts のようなファイルとして見せ、必要なものだけ読ませる |
サンドボックスを自分で作り、安全に運用する必要がある |
| サーバー側のCode Mode(Cloudflareの設計) | MCPサーバー自体(V8 isolate) | そのサーバーのAPIに限られる | 1サーバー1API。Cloudflareは2,500超のエンドポイントで117万トークンが約1,000トークンになったと報告 |
| プロキシ側のコードモード | MCPサーバーの前に置くゲートウェイ | サーバーを変えずに使える | ゲートウェイのサンドボックスと権限の仕組みに依存する |
Anthropicは「コード実行はそれ自体の複雑さを持ち込む」と書いており、エージェントが書いたコードにはサンドボックス、リソース制限、監視が必要です。Cloudflareのサンドボックスはファイルシステムも環境変数もなく、外部への通信も既定で無効です。どの方法でも、ツールの出力は「コードに渡る信頼できない入力」として扱ってください。脅威モデル全体はMCPセキュリティのチェックリストで解説しています。
7. 実装例(Anthropic API)
MCPツールをコードから呼べるようにするには、MCPクライアントでツール一覧を取得し、Messages APIにカスタムツールとして渡して allowed_callers を付けます。途中で判断が必要なツールは直接呼び出しのままにします。
{
"model": "claude-sonnet-5-5",
"max_tokens": 4096,
"tools": [
{ "type": "code_execution_20260120", "name": "code_execution" },
{
"name": "crm_get_account",
"description": "Get one CRM account by ID. Returns JSON: {id, name, owner, arr, status}.",
"input_schema": {
"type": "object",
"properties": { "id": { "type": "string" } },
"required": ["id"]
},
"allowed_callers": ["code_execution_20260120"]
},
{
"name": "crm_close_account",
"description": "Close an account. Requires user confirmation.",
"input_schema": {
"type": "object",
"properties": { "id": { "type": "string" } },
"required": ["id"]
},
"allowed_callers": ["direct"]
}
],
"messages": [
{ "role": "user", "content": "この20社のうち支払い期限を過ぎているのはどこ? ..." }
]
}
エージェントのループは次のように動きます。
- レスポンスが
stop_reason: "tool_use"で止まり、containerのIDと、caller.typeがcode_execution_20260120のtool_useブロックが返ります。 - 各呼び出しをMCPクライアントで実行し、
tool_resultブロックだけを含むユーザーメッセージを、同じcontainerのIDを付けて返します。テキストを混ぜてはいけません。 - コードが終わるまで繰り返します。Claudeのコンテキストに入るのは、スクリプトの最終出力だけです。
トークンを減らすうえで大事な点が2つあります。1つは、スクリプトが結果を解析できるよう、出力形式(JSONのフィールドと型)をツールの説明文に書くことです。もう1つは、構造化された簡潔なデータを返すことです。どちらもAnthropicのドキュメントでベストプラクティスとして挙げられています。
8. 自分の環境で効果を測る方法
ベンチマークの数字だけを根拠に、すべてのツールでCode Executionを有効にするのは避けましょう。Anthropicも、実際のトラフィックの代表的なサンプルで allowed_callers の有無による課金対象の入力トークンを比べるよう勧めています。
- 実際のタスクを20〜50個選び、
allowed_callersありとなしで1回ずつ実行します。 - 各タスクのループ内の全リクエストについて、
usage.input_tokensとusage.output_tokensを合計します。最初のリクエストだけで比べないでください。 usage.server_tool_use.code_execution_requestsを記録し、コンテナの実行時間を見積もります。- タスクあたりの費用と成功率を比べ、費用が下がり成功率が落ちないツール群だけで有効にします。
- サーバー側ではツールごとのレスポンスサイズを記録します。レスポンスが大きいツールほど、Code Executionの効果が出やすい候補です。
9. よくあるハマりどころ
| 症状 | 原因 | 対処 |
|---|---|---|
| 有効にしたら費用が上がった | 結果の小さい逐次呼び出しが中心の処理だった | 該当ツールを ["direct"] に戻し、一括処理や大きな結果のツールだけコード経由にする |
tool_choice で400 invalid_request_error |
allowed_callers に "direct" がないツールを tool_choice で指定している |
"direct" を加えるか、tool_choice から外す |
Circular $ref detected で400 |
input_schema に再帰的な $ref がある |
そのツールは直接呼び出しにするか、再帰を展開する |
| MCPコネクタのツールがコードから動かない | AnthropicのMCPコネクタ経由のツールはプログラムから呼べない | 自前のMCPクライアントからカスタムツールとして渡すか、サーバー側・プロキシ側のコードモードを使う |
スクリプト内で TimeoutError |
ツールの結果を返すのに約4分以上かかった | ツールを速くし、expires_at より十分前に返す(アイドル状態のコンテナは約5分で回収される) |
| スクリプトが結果を解析できない | ツールが文章や形式不明のデータを返している | JSONを返し、フィールドを説明文に書く |
strict: true のツールが拒否される |
Structured OutputsはProgrammatic Tool Callingに対応していない | そのツールは strict を外すか、直接呼び出しにする |
| 「コード専用」のツールをモデルが直接呼んだ | allowed_callers はモデルへの案内であり、セキュリティ境界ではない |
権限はクライアントかサーバーで強制する |
10. NodeFlareならこう解決できる
NodeFlareはMCPサーバーをホスティングし、プロキシ側でサーバーごとのトークン関連の設定を提供しています。どれもサーバーのコードを変える必要はありません。この記事で挙げた課題ごとに、対応する設定を紹介します。
課題:一括処理や大きな結果でコンテキストがあふれる(2〜3章)。でもサンドボックスを自分で運用したくない(6章)。
→ Code Execution(tool_code_mode)を有効にします。サーバーは個々のツールの代わりに run_code と search_tools を公開します。モデルが tools.* を呼ぶJavaScriptを書き、NodeFlareがそれを実行し、返り値だけがモデルに戻ります。複数のツール呼び出しが1回の実行にまとまります。サンドボックスはプロキシとは別のDenoのサブプロセスで、ファイルシステム・環境変数・子プロセスは使えず、通信先はプロキシのツール呼び出し用エンドポイントだけです。既定値はタイムアウト600秒(変更可)、1回の実行あたりのツール呼び出し上限50回、V8のヒープ上限128MBです。run_code 自体がMCPツールなのでサーバー側で完結し、クライアント側のコード実行機能に頼りません。AnthropicのMCPコネクタ経由のツールがプログラムから呼べない、という制約も回避できます。
課題:サーバーによってはCode Executionが向いていない(3章のシナリオC、5章)。
→ 設定はサーバーごとです。CRM、ログ、分析など扱うデータが多いサーバーでは tool_code_mode を有効にし、短い逐次処理や1ステップずつ確認する作業に使うサーバーは直接呼び出しのままにできます。どのサーバーが大きなレスポンスを返しているかは、リクエストログの res_bytes(呼び出しごとのレスポンスサイズ)で分かります。NodeFlareのドキュメントでも、res_bytes が大きいほど呼び出し側のコンテキスト消費が直接増えると説明されています。
課題:直接呼び出しのサーバーでは、ツール一覧がトークンを消費し続ける。
→ tool_search_mode を有効にします。tools/list が search_tools(query) と call_tool(name, args) の2つのメタツールに置き換わり、ツールが増えても初期のトークン消費はほぼ一定です。GEMINI_API_KEY を設定すると意味検索になり、失敗時はキーワード検索に戻ります。
課題:エージェントが書いたコードが、呼ぶべきでないツールを呼ぶおそれがある(6章)。
→ tool_list_filter_by_scope を有効にすると、呼び出し元の認証情報で使えるツールだけが一覧に出ます。APIキーには tools:call:get_weather のような狭いスコープを付けて発行できます。コードモードでは、スクリプトからのツール呼び出しもサーバー側で転送前にスコープを再確認し、実行ごとに短命のトークン(有効期間は実行タイムアウト+10秒)が使われます。
課題:残ったツール定義の説明文が長い。
→ tool_schema_slim を有効にすると、500文字を超えるツール説明を(UTF-8を壊さずに)切り詰めます。ツール名と入力スキーマはそのまま残ります。スクリプトが頼りにする出力形式の説明は、最初の500文字以内に書いておきましょう。
NodeFlareは決まった削減率を公表していません。自分の処理での効果は、8章の測り方か4章の計算式で確かめてください。
最小の始め方:
- nodeflare.tech にサインインし、MCPサーバーのGitHub URLを入力します。ランタイム、トランスポート、起動コマンドは自動で検出されます。
- デプロイしたら、サーバー設定で
tool_code_modeを有効にします(複数のエージェントで共有するならtool_list_filter_by_scopeも)。 - 表示されたサーバーのURLとAPIキーをMCPクライアントに追加します。
1サーバーまで無料で試せます(Freeプラン:1サーバー、月30 GB時間のコンピュート)。→ nodeflare.techで始める
11. よくある質問
MCPのCode Executionを使えば必ずトークンは減りますか?
いいえ。Anthropicの報告では、75ツールのベンチマークで課金対象の入力トークンが約38%減った一方、1ターンに1〜2回の逐次呼び出しをするτ²-benchではコストが約8%増えました。ツールの結果が大きいときや、モデルの判断を挟まずに多くの呼び出しをまとめられるときに効果が出ます。
Code ModeとProgrammatic Tool Callingの違いは?
考え方は同じで、呼び名が違います。Code ModeはCloudflareの呼び方で、Programmatic Tool CallingはAnthropicのコード実行コンテナでコードを動かすAPIの機能です。どちらもコードからツールを呼び、途中の結果をコンテキストに載せません。
プログラムから呼んだツールの結果は入力トークンとして課金されますか?
されません。Anthropicのドキュメントでは、プログラムから呼んだツールの結果は入出力トークンの使用量に数えず、数えるのはコード実行の最終結果とClaudeの応答だけとされています。ただしコンテナの実行時間は別に課金されることがあります。
Claude APIのコード実行の料金はいくらですか?
Web検索かWebフェッチ(2026-02-09版以降)をリクエストに含めていれば無料です。それ以外は時間課金で、1回あたり最低5分、組織ごとに毎月1,550時間まで無料、それを超えると1コンテナ1時間あたり0.05ドルです。
AnthropicのMCPコネクタとProgrammatic Tool Callingは併用できますか?
できません。MCPコネクタ経由のツールはプログラムから呼べません。自前のMCPクライアントでツール一覧を取得して allowed_callers 付きのカスタムツールとして渡すか、サーバー側・プロキシ側のコードモードを使います。
ツールが何個以上あればCode Executionを使う価値がありますか?
ツールの数より、結果の大きさとタスクあたりの呼び出し回数のほうが効きます。Anthropicの本番データでは、ツール定義が10〜49個のリクエストで20〜40%程度の削減が一般的です。小さな呼び出しが1〜2回だけのタスクでは、逆に高くつくことがあります。
ツール検索とCode Executionは併用すべきですか?
はい。減らすコストが違います。ツール検索は最初に読み込むツール定義のトークンを、Code Executionはツール結果のトークンとモデルとの往復を減らします。Anthropicのファイルツリー方式もCloudflareの search() も、この2つを組み合わせています。
直接呼び出しのまま残すべきツールは?
ユーザーの確認が必要なツール、結果を見てモデルが次の手を判断する必要があるツール、再帰的なスキーマや strict: true を使うツールです。Anthropicは、ツールごとに ["direct"] かコード実行のどちらか一方を選ぶよう勧めています。
MCPのCode Executionは安全ですか?
安全性はサンドボックス次第です。エージェントが書いたコードには隔離、リソース制限、監視が必要で、ツールの出力は信頼できない入力として扱います。allowed_callers はセキュリティ境界ではないので、権限はサーバーかゲートウェイで強制してください。
ここでいう「MCPトークン」はAPIトークンのことですか?
いいえ。この記事は、MCPツールが消費するLLMのトークンについての記事です。APIキーやOAuthのアクセストークンはセキュリティの記事で扱っています。
まとめ
MCPのCode Executionは、生のツール結果をサンドボックスに閉じ込め、複数のモデルのターンを1本のスクリプトにまとめることでトークン消費を減らします。一括処理や絞り込める大きな結果では効果がはっきり出て、筆者の試算ではSonnet 5.5で57〜69%安くなりました。一方、短く依存関係のある呼び出しでは少し高くなります。損益分岐の計算式で見当をつけ、実際のトラフィックで課金対象のトークンを測り、どのツールをコード経由にするかをツールごとに決めましょう。
