MCPのトークン問題は深刻だ。
従来のModel Context Protocol実装は無駄な支出を招いている。AIエージェントが問題解決を始める前に、どのAPIが存在するかを説明するだけで既に5万5000トークンを消費している。Anthropicでは、一部のエンタープライズ設定では13万4000トークンもの純粋なオーバーヘッドに達している。これは効率ではない。これはリクエストごとの税金だ。
問題は馬鹿げるほど単純だ。システムがすべてのツール定義を事前にロードしており、エージェントが実際に使うかどうかは関係ない。GitHub、Slack、Sentry、Grafana、Splunkの58個すべてのツールが、巨大なJSONペイロードとしてモデルのコンテキストウィンドウにダンプされる。それらのほとんどは現在のタスクに無関係だ。何の関係もない。
“従来のMCP実装は、多くの場合、モデルコンテキストに大規模なJSONペイロードを注入し、トークン消費を増加させ、効率を低下させます。”
ここにCode Modeが登場する。そして状況は一変する。
Code Modeの実際の違いは何か？
Code Modeはツール定義を事前にロードしない。代わりに、モデルがツールを呼び出すコードをオンデマンドで生成できる。LLMは利用可能なAPIのレジストリを検索し、必要なスキーマのみを取得し、正しいエンドポイントを呼び出すPythonコードを記述し、そのコードをサンドボックス環境で実行する。結果が戻ってくる。完了だ。
効率の向上は明らかだ。コンテキストの膨張がなく、無関係なツール説明からの幻覚のリスクもなく、トークン消費は劇的に削減される。しかし、誰も話していない本当の洞察は何か？このアプローチはコンテキストウィンドウサイズを実行知能と引き換えにしている。モデルは何ができるかを説明するだけでなく、実際にそれを行う。
そしてそれにはサンドボックスが必要だ。
LLMコードを直接実行できない理由
ここが現実が厳しく突き刺さる部分だ。AIモデルに任意のPythonを生成させ、本番サーバーで実行させるのは、セキュリティ侵害への最短経路だ。ファイルアクセス。ネットワークの悪用。権限昇格。システム乗っ取り。
OpenSandbox（Alibabのオープンソースプラットフォームであり、現在CNCF Landscapeに掲載されている）は、分離実行環境を作成することでこれを解決する。生成されたPythonコードは、ファイルシステムアクセス制限、ネットワーク制御、リソース制限、プロセス分離を備えたコンテナ内で実行される。サンドボックスはモデルの意図と実際のインフラの間のお堀として機能する。
これは偏執ではない。これはアーキテクチャだ。
フローは次のようになる。スタートアップがすべての利用可能なOpenAPI仕様を検出し、レジストリに読み込む。リクエストが到着する。システムはメタデータで関連ツールを検索する。LLMはget_schema経由で選択されたツールのスキーマを検査する。モデルはエンドポイントを正しく呼び出すPythonコードを生成する。そのコードはexecute経由でサンドボックスに送信される。サンドボックスはそれを分離して実行し、実際のシステムへのHTTPリクエストを処理し、生のリスポンスを返す。LLMはそれを人間が読める形のレスポンスに変換する。
3つのコアツール（search、get_schema、execute）がそれを実現する。それだけだ。
これは実際に従来のMCPより優れているか？
はい。ただし注意点がある。
数百のAPIと膨大なツールレジストリを持つエンタープライズの場合、Code Modeはトークン税を排除する。コンテキストオーバーヘッドの90%削減は理論的ではない。それはすべてのツール定義を事前にロードするのをやめたときに起こることだ。規模が大きくなると、これは実際のコスト削減と高速化推論になる。
しかし、Anthropicのマーケティングスライドに含まれないもの：Code Modeはレイテンシを導入する。サンドボックスへの追加ラウンドトリップ、コード生成、実行、結果解析には時間がかかる。レイテンシに敏感なアプリケーションでは、従来のMCP（膨張していても）が、同じツールを繰り返し実行する場合はまだ高速かもしれない。
また、すべての環境がこのレベルの最適化を必要とするわけではない。APIの限定的なセット（例えば、合計1万5000トークン消費する5つのツール）を実行している場合、サンドボックスと動的ツール呼び出しのエンジニアリング複雑性は価値がないかもしれない。
より大きな図：コンテキスト効率を能力として
興味深いのは、これがMCP最適化だけではないということだ。これはパターンだ。モデルが大きくなり、トークンウィンドウが拡大するにつれて、すべてをコンテキストに放り込む誘惑が生じる。Anthropicは本質的に言っている。そんなことはやめろ。モデルが何を見るかについて意図的でいろ。
Code Modeがその意図性を強制する。もう100個のツール定義を遅延ロードすることはできない。発見、関連性、そしてモデルが実際に問題を解決するために必要なものについて考えなければならない。
これが重要なのは、コンテキストウィンドウサイズが虚栄のメトリクスだからだ。本当の効率はシグナル対ノイズ比についてだ。そしてCode Modeはそれを劇的に改善する。
エンタープライズ設定でこれを実装する.NETおよびC#開発者（オリジナルの著者が研究してきた）にとって、このパターンは研究する価値がある。基本原理（静的定義を注入する代わりに実行可能なコードを生成する）はAPI以上にスケールする。それはエージェントがデータベース、インフラストラクチャ、内部ツールとどのように相互作用するかを変える可能性がある。
OpenSandboxの問題
最後に1つ。OpenSandboxはほとんどの開発者にとって比較的新しい。これは堅牢だ（CNCF認可、マルチ言語SDK、Docker/Kubernetesサポート）が、採用はまだ主流ではない。本番環境でCode Modeを実装する場合、エコシステムをまだ構築している中のプラットフォームに賭けていることになる。
これは問題ではない。これは現実チェックに過ぎない。
ここでの勝利は本当だ。トークン浪費のないMCP、実際に実行可能なツール呼び出し、セキュリティと速度を犠牲にしないサンドボックスパターン。しかし実装には従来のMCPより多くのインフラが必要だ。トークンオーバーヘッド問題に自分自身が直面していない場合、それは間違った問題に対する正しいソリューションだ。
🧬 関連インサイト
- 詳細を読む： Your Access Tokens Are Probably Broken (And Nobody’s Telling You)
- 詳細を読む： Azure Kubernetes Service: Why Your Cost Optimization Strategy Is Probably Broken
よくある質問
Code ModeはすべてのAPIで動作するか？ APIがOpenAPI仕様を持ち、HTTPでアクセス可能である限り、Code Modeはそれを検出、スキーマ検査、呼び出しできる。サンドボックスは対象システムに到達するためにネットワーク出力ルールが設定されている必要があります。
Code Modeは既存のMCPセットアップを置き換えるか？ 必ずしも。ツールレジストリが小さく、トークン消費がボトルネックでない場合、Code Modeへの移行は利益なく複雑さを追加します。実際のトークンオーバーヘッドとレイテンシ要件に基づいて評価してください。
OpenSandboxは本番環境対応か？ はい。CNCF Landscapeに掲載されており、Docker/Kubernetesへのエンタープライズデプロイメントをサポートします。ただし、エコシステム成熟度とコミュニティサポートは主流ツールのレベルではありません。
