Cloudflare Code Modeの「トークン99.9%削減」は本当か？

なぜ今、この検証が必要なのか

2026年3月、Cloudflareが「Code Mode」というMCPサーバーの新設計を発表した。そのマーケティングコピーは鮮烈だった——「2,500以上のAPIエンドポイントを1,000トークンで提供」。同社の公式ブログには「従来方式の117万トークンから99.9%削減」という数字が踊った。

ところが同月、WorkOSが独立した実証テストを公開した。そこには「Code ModeによるトークンコストはXX%カット」として81%という数字が記されていた。

99.9%と81%——同じ技術なのになぜこれほど異なるのか？ SNSでは「どちらが本当か」という議論が起きた。いずれかが誇大広告なのか、それともどちらも正しいのか。KanseiLinkは両社の一次ソースを精査し、この謎を解明する。

Cloudflare Code Modeとは何か

従来のMCPサーバーは、接続時にすべてのToolの定義（名前・説明・パラメータスキーマ）をLLMのコンテキストウィンドウに読み込む。APIエンドポイントが多いサービスほど、この「セットアップコスト」は爆発的に増大する。

Cloudflareが提案したCode Modeは根本的に異なるアプローチだ。すべてのツール定義を展開する代わりに、たった2つのツールだけをエクスポートする：

• search(query): OpenAPI仕様をベクター検索し、関連エンドポイントを特定する
• execute(code): LLMが生成したJavaScriptをCloudflare Dynamic Worker内の隔離サンドボックスで実行する

LLMは「ツールを呼び出す」のではなく「TypedクライアントとOpenAPI型定義に対してコードを書く」という形で動作する。Cloudflare APIクライアントの型情報は事前にコンパクトな表現に変換されており、全エンドポイントへのアクセスを維持しつつコンテキスト消費を極小化する。

Claim 1: 「99.9%削減」— Cloudflare公式ブログ ⚠️ 条件付き真

しかし「条件付き真」としたのはなぜか？ この数字には2つの重大な前提がある。

第一に、比較対象が「Cloudflare APIの全エンドポイントをすべてMCPツールとして定義した場合」という、実際にはほぼ誰も採用しない極端なシナリオだ。通常の実装では必要な一部エンドポイントだけをツール化するため、従来方式でも117万トークンにはならない。

第二に、117万トークンという数字は「最先端の基盤モデルのコンテキストウィンドウを超える」とCloudflare自身が認めている数字だ。つまり従来方式ではそもそも動作すら不可能なシナリオとの比較であり、実用上の比較ベースラインとしては適切とは言えない。

99.9%という数字は技術的な証明としては正確だが、「一般的なMCPサーバー実装でCode Modeを使えば99.9%安くなる」と解釈するのは誤りだ。

Claim 2: 「81%削減」— WorkOSテスト ✅ 検証済み

WorkOSの81%は「APIスキーマの初期ロードコスト」ではなく、「エージェントが実際に31件のイベントを作成する作業全体を通じて消費したトークンの合計」の削減率だ。これはプロダクション環境での実コストに直結する数字であり、エンジニアリングの意思決定に際してより参考にすべき指標と言える。

なぜ同じ技術で異なる数字が出るのか

結論から言えば、両方の数字は正確だが、測定している対象が根本的に異なる。

• 99.9%（Cloudflare）: 「APIスキーマをコンテキストにロードするコスト」——すなわち会話開始時の固定オーバーヘッドの削減率。Cloudflare APIという極端に大規模なAPIとの比較で意味を持つ。
• 81%（WorkOS）: 「実タスクを実行する際のランタイムコスト」——すなわちエージェントが実際に動いている間の消費の削減率。実業務シナリオでの実測値として信頼性が高い。

イメージとしては、99.9%は「レストランのメニューを読む時間が99.9%短縮された」という主張であり、81%は「食事全体の所要時間が81%短縮された」という主張だ。どちらも真実だが、あなたが気にすべきは「食事時間」の方だろう。

なぜこの混乱が生まれるのか

MCPのトークンコスト議論には根本的な複雑さがある。トークン消費は大きく分けて3つの場面で発生する：

1. 初期化コスト（Tool定義ロード）: 会話開始時にすべてのTool定義をコンテキストに展開するコスト。サーバーのエンドポイント数に比例。
2. ターン内コスト（Tool呼び出し）: 各ツール呼び出しの引数と結果のコスト。タスクの複雑さと呼び出し回数に依存。
3. 履歴蓄積コスト（会話継続）: 会話履歴がコンテキストに蓄積されていくコスト。会話の長さに比例。

Cloudflareの99.9%は主に①を、WorkOSの81%は①②③を含む合計コストの削減率を示している。「どのフレームで語っているか」を確認せずに数字だけを比較すると混乱する。

日本SaaS開発者への実際の影響

Cloudflare Code Modeが革新的なのは否定しないが、日本SaaS開発者にとっての現実的な適用範囲を整理しておく必要がある。

Code Modeが劇的効果を発揮する条件：

• エンドポイント数が100以上ある大規模APIを持つSaaS
• OpenAPI仕様（Swagger）が整備されている
• Cloudflare Workers上にMCPゲートウェイを構築できる
• エージェントが多種多様なエンドポイントを横断的に使うユースケース

KanseiLinkが評価する日本主要SaaSのエンドポイント規模から考えると、freee・マネーフォワード・kintoneといった大規模SaaSではCode Mode型設計が有効だ。一方、エンドポイントが数十程度の専門特化SaaSでは、従来のMCPサーバーとの差は限定的になる可能性が高い。

より現実的な目標は「スマートなツール定義の絞り込み」だ。全エンドポイントをMCPツールとして公開せず、エージェントが実際に使う頻度の高い20〜30エンドポイントに絞ることで、Code Modeに頼らずとも70〜80%の効率化は実現できる。

まとめ：どの数字を使うべきか

99.9%と81%——どちらも正確な数字だが、使うべき場面が異なる。

社内稟議や投資判断の根拠として使うなら81%（ランタイム削減）に近い実測値の方が保守的で誠実だ。技術的な可能性として、「超大規模APIではセットアップコスト上の理論的最大値は99.9%に達する」という事実は正確だが、それは多くの日本SaaSの現実ではない。

MCPコスト最適化の議論が成熟するにつれ、「何%削減できるか」よりも「どのエンドポイントセットで、どのタスクパターンに最適化するか」という問いの方が本質的になっていく。Cloudflare Code Modeはその方向への重要な一歩だが、銀の弾丸ではない。