この記事の途中に、以下の記事の引用を含んでいます。
Code Mode: the better way to use MCP
革命的なアプローチ？MCPとLLM連携の新常識
皆さん、AIエージェントが外部APIや各種ツールを活用する際の“標準”って何だと思いますか。
今やChatGPTをはじめとした大型言語モデル（LLM）が、さまざまな業務を自動化する時代。
それを支えるのが「Model Context Protocol（MCP）」です。
しかし、この分野のリーダーであるCloudflare（クラウドフレア）が、私たち全員が間違ったMCPの使い方をしているのではないか？と問題提起しました。
そして、より優れた「Code Mode」という新しい運用法を提案しています。
今回の記事は、技術の本道に立ち返る知見と具体的な実装モデルを示しており、AIエージェントやMCP関連に関心がある開発者はもちろん、次世代のAI活用に挑む全ての人に読んでいただきたい内容です。
「MCPをコードとして扱え」—Cloudflareの主張
Code Mode: the better way to use MCP では次のような衝撃的な指摘がなされています。
“We tried something different: Convert the MCP tools into a TypeScript API, and then ask an LLM to write code that calls that API. The results are striking:
We found agents are able to handle many more tools, and more complex tools, when those tools are presented as a TypeScript API rather than directly. Perhaps this is because LLMs have an enormous amount of real-world TypeScript in their training set, but only a small set of contrived examples of tool calls. … In short, LLMs are better at writing code to call MCP, than at calling MCP directly.”
つまり、従来のMCPのツール呼び出し（いわゆるtool_call）をLLMに直にやらせるより、ツール群をTypeScript APIとして提示し、「コード（TypeScript）を書かせて、それを実行する」ほうが、遥かにうまくいく、というのです。
真逆の発想です。
従来は、一つひとつのツール呼び出しが特殊なトークン列で行われていました。
しかしLLMは「普段見慣れない特殊なtool_call」よりも「日常的に学習してきたソースコード」のほうが圧倒的に得意だ、という指摘です。
なぜ「コードでMCP」が革命的なのか？—背景から実装例まで
従来のMCP運用とその限界
MCPとはAIエージェントと外部ツールを「機械可読なAPI仕様＋認可＋接続方式」で標準化するプロトコルです。
多くのMCPサーバーは「ツール」という概念でAPI機能をエクスポーズ（公開）します。
LLMが「<|tool_call|>…<|end_tool_call|>」のような特殊トークンでツールを呼び出し、レスポンスも専用トークンで返却される──それが今までの実装でした。
しかしこの方法、現場では実は「大変に弱い」面がありました。
特殊なトークンは実世界のコーパスには存在せず、LLMの訓練データの多くが「合成」「人工的」。
そのため、
“The special tokens used in tool calls are things LLMs have never seen in the wild. … They aren’t always that good at it. If you present an LLM with too many tools, or overly complex tools, it may struggle to choose the right one or to use it correctly.”
と述べられている通り、ツール数が増えたり複雑なパラメータが絡むと、とたんにLLMが迷走する現象が目立ちます。
新方式「Code Mode」とは？
Cloudflareはここでブレイクスルーを見出しました。
LLMは自然言語（＝特殊tool_call）ではなく、TypeScriptやPythonといった「プログラミング言語」には非常に熟達している。
ならば、AIがツール群をAPIとしてコードで呼び出せるようにし、そのコードだけを安全に実行すればよい。
これが「Code Mode」です。
具体的には、MCPサーバーのAPIスキーマ（OpenAPI等に相当する情報）から自動的にTypeScriptの型定義と関数群を生成し、
LLMはそのAPI定義を読みつつ「純粋なコード」としてツール活用タスクを実装。
このコードはCloudflare Workersの「isolate」で安全に実行され、外部ネットワークには基本的にアクセス不可能。
API呼び出しだけを“バインディング”という形で関数として公開します。
実装コード例（Pythonでいうsandbox付きscript実行のようなもの）
記事引用:
javascript
declare const codemode: {
/**
* Fetch entire documentation file from GitHub repository:
* cloudflare/agents. Useful for general questions.
*/
fetch_agents_documentation: (
input: FetchAgentsDocumentationInput
) => Promise<FetchAgentsDocumentationOutput>;
// ...他にも複数API
};
このようにAPIインターフェースが自動生成され、LLMは「通常のプログラムを書くだけ」。
仕組み的にも、サンドボックスでネットワークを遮断し、API呼び出しだけが許可されるため、
APIキー流出リスクがゼロになるなど、セキュリティ上も有利です。
開発者視点で読み解く「Code Mode」—わかりやすく解説＆独自考察
なぜ“LLMによるコード生成”がツール活用力を爆発的に伸ばすのか
現在主流のLLM（特にGPT-4/5など）は、大規模なリアルワールドのプログラム、特にTypeScript/JavaScriptやPythonを大量に事前学習しています。
つまり「TypeScriptでAPIを呼び出す」「応答データをパースして次の処理へ」というタスクは“日常茶飯事”なのです。
一方、tool_call形式はほぼベンダー独自の設計であり、
「実際の活用現場」で事例が極めて少ない。
LLM側から見ると、「普段あまり取り組まない特殊なタスク」という扱いになってしまいます。
たとえばGPT-4をAPI連携させて工数計算やデータ分析をさせたい場合も、tool_callで機能追加するより、
TypeScriptでのデータ加工やパイプライン処理を“プログラムとして”書かせたほうが、遥かに安定して上手くいく場面は想像しやすいでしょう。
この「実績に基づいた得意なやり方」をメインルートに据えるべき、という提案は説得力があります。
セキュリティ・監査体制面のブレイクスルー
code mode最大の特徴は「サンドボックス（＝isolate）」を全面的に使う点です。
従来はtool_call～API～ネットワーク～外部サーバまでパスが開いており、
“LLMが勝手に通信して怪しいAPIキーを外部に流出させる”リスクが現存していました。
しかしcode modeのバインディングでは、「許可されたAPIだけ」が「関数」としてサンドボックスに渡される。
ネットワークや環境変数からの逸脱は物理的に不可能。
しかもAPIキーもサポートプロセス側で管理され、サンドボックスには一切渡らず、LLMからは直接アクセスできません。
AIが生成したコードが“安全に監督できる”という意味で、この設計は極めて現実的かつ未来的です。
技術者観点から補足したい課題・今後の注目点
-
APIの複雑さとLLMの解釈負荷：
APIスキーマが複雑な場合、TypeScriptの型定義だけを与えるのは時に情報過多になりうる。
プロンプト設計や“必要なスキーマだけ動的に渡す”補助機能の設計が今後の焦点になるでしょう。 -
エージェントの「自律コーディング能力」依存：
LLMが自分でコード生成→動作検証→エラー修正…という「エージェントサイクル」を本当に回し続ける基礎設計が問われます。
人間のコーディングと同等のリカバリー能力、チャットインタラクション設計が一層重要になってきます。 -
サンドボックスプラットフォームとしてのWorkerエコシステム：
クラウドコンテナに比べ、isolateサンドボックスは“超高速・低コスト”ながら永続ストレージや外部リソース連携で課題も残ります。
Workers&コーディングAIエージェント固有のベストプラクティスが今後発展していくでしょう。
これからのAIエージェント設計に不可欠な「教訓」—Code Modeがもたらす示唆
本記事の最大の功績は、
AIとAPI／ツール連携の標準仕様（すなわちMCP）の“運用レベルの最適化”を示したことです。
- LLMを手工芸的なJSON tool_callプロトコルにあてはめるのではなく、
- 「LLMが最も得意な“コード生成”領域」で問題解決を自動化する
- コード実行環境は高速・セキュアなサンドボックスに限定。APIバインディングで利用範囲を厳密管理
- LLMのアウトプット（コード）＋実行→出力結果だけをLLMに戻す、という明確で監査可能なフロー
これはAI利用現場すべて、言い換えれば「AIエージェントが何を“最も得意”とするか？」を冷静に見極めて連携設計するべき、という強力なメッセージです。
実際、今後はクラウドサービスのみならず社内業務自動化やローコード開発でも、
AIに「コードを書かせて動かす」設計思想がデファクトスタンダードになっていくと考えられます。
おわりに：思考の枠を外すことから「より良い設計」は生まれる
Cloudflareの提案は、MCPの“標準的な利用法”そのものを真っ向から覆すものでした。
機械学習時代にありがちな「仕様を守ればうまくいく」という思考停止から一歩抜けて、
「LLMという“人材”の得意技を活かす運用」に目を向ける。
これこそ、コード世代のAI活用設計が今後進化するための肝になるはずです。
変化の激しい時代ですが、
API設計やAIエージェント運用に携わるすべての人にとって、
このCode Modeの発想は“保守的な正しさ”の殻を破る刺激的な挑戦に違いありません。
今後のAI自動化設計に、このアプローチを考えない手はないでしょう。
categories:[technology]
コメント