AIエージェントが「コードを書いて実行する」という形でタスクをこなす時代が、現実のものになりつつあります。
Cloudflareは2026年3月、AIが生成したコードを安全かつ高速に実行するための軽量サンドボックス機能「Dynamic Worker Loader」の詳細を公開しました。コンテナベースの従来手法と比較して起動速度が100倍速く、メモリ消費も大幅に抑えられると説明されており、コンシューマースケールでのAIエージェント展開を現実的な選択肢に引き上げる可能性があります。
この発表の背景にあるのは、同社が昨年9月に提唱した「Code Mode」というコンセプトです。AIエージェントがAPIをツールとして呼び出すのではなく、コードを書いてAPIを呼び出すという設計思想であり、トークン使用量を最大81%削減できることが示されています。しかし、AIが生成したコードをそのまま実行すれば、悪意あるプロンプト注入によって深刻な脆弱性が生じる恐れがあります。コード実行のための「隔離された場所」、すなわちサンドボックスの確保が不可欠なのです。
セキュリティと速度の両立という、AI基盤の設計において避けて通れないこの課題に、Cloudflareがどう向き合ったかが、今回の発表の核心といえます。
AIエージェントとコード実行——なぜ「今」サンドボックスが問題になるのか
AIエージェントの能力が向上するにつれ、その動作モデルも変化しています。初期のチャットAIは主にテキストを生成するだけでしたが、近年では「エージェント」として複数のツールを呼び出し、外部サービスと連携しながら自律的にタスクを遂行するケースが増えています。
こうした流れの中で、Cloudflareが昨年9月に提唱したのが「Code Mode」というアーキテクチャです。従来のエージェントがMCPサーバーなどを通じてAPIをツールとして呼び出す方式に対し、Code Modeではエージェント自身がTypeScriptなどのコードを生成し、そのコードがAPIを直接呼び出します。この方式により、AIが毎回ツール定義を読み込む必要がなくなり、トークン消費量が81%削減できたとCloudflareは報告しています。
さらに同社は、MCPサーバーの背後にCode Modeを配置する構成も実証しており、Cloudflare APIの全機能をわずか2つのツールと1,000トークン以下で呼び出せるMCPサーバーを実現したとされています。
この設計が普及すると、必然的に「AIが生成したコードをどこで実行するか」という問題が浮上します。アプリケーション内部で直接eval()を呼ぶことは論外で、悪意あるユーザーがプロンプトを工夫するだけで、任意のコードをアプリ内に潜り込ませることができます。実行環境はアプリケーション本体と、そして外部のシステムから明確に隔離される必要があります。
AIサンドボックスはすでに業界全体の課題として認識されており、多くの企業がLinuxベースのコンテナ技術で対応を試みています。Cloudflare自身もコンテナランタイムとSandbox SDKを提供していますが、今回の発表はそれとは別の、より軽量なアプローチを打ち出したものといえます。コンシューマースケール——つまり、エンドユーザー一人ひとりがエージェントを持ち、そのエージェントがコードを書くような世界——ではコンテナの重さが致命的なボトルネックになりうる、という問題意識が根底にあるようです。
コンテナとの比較で見えてくる、Dynamic Worker Loaderの設計思想
AIエージェントのコード実行環境として、現在最も広く使われているのはコンテナ（Dockerなど）ベースのサンドボックスです。Dynamic Worker Loaderが目指す位置づけを理解するには、まずこのコンテナ方式と何が異なるのかを整理しておく必要があります。
コンテナ方式の特徴と課題
- 起動時間： Linuxベースのコンテナは一般に数百ミリ秒の起動時間を要します。リクエストのたびに新規コンテナを立ち上げていては、レイテンシが許容範囲を超えます
- メモリ消費： 一つのコンテナを維持するだけで数百MBのメモリが必要です。ユーザー数が増えれば、インフラコストは急速に膨らみます
- ウォームアップの必要性： 起動遅延を避けるために「ウォームコンテナ」を常時待機させる運用が一般的ですが、これはコストとセキュリティのトレードオフを生みます
- コンテナ使い回しのリスク： コストを抑えるために複数のタスク間でコンテナを共用すると、タスク間の隔離が損なわれ、セキュリティリスクが高まります
Dynamic Worker Loaderのアプローチ
Cloudflareが提示するDynamic Worker Loaderは、同社のサーバーレス実行基盤「Cloudflare Workers」の仕組みを活用した、より軽量な隔離環境です。Cloudflare Workersは、V8エンジンの「アイソレート（Isolate）」と呼ばれる技術を用いており、JavaScriptランタイムレベルで各実行コンテキストを分離します。
この仕組みにより、以下のような特性が生まれます。
- 起動速度： コンテナの起動に数百ミリ秒かかるのに対し、WorkerのIsolateは数ミリ秒以内に起動できるとされており、「100倍速い」というCloudflareの主張もこの差を指しています
- メモリ効率： OSレベルの仮想化を伴うコンテナと異なり、V8アイソレートはJavaScriptのランタイムレベルで分離を実現するため、メモリフットプリントが大幅に小さくなります
- セキュリティの設計： 各Worker実行は独立したアイソレートとして動作するため、タスクをまたいだ状態の漏えいや、他の実行コンテキストへのアクセスが構造的に防がれます
- 対応言語： Workersが主に対象とするのはJavaScript／TypeScriptですが、WebAssemblyを経由することで他言語への対応も技術的には可能です
既存のサンドボックスSDKとの関係
Cloudflareはすでに「Sandbox SDK」をリリースしており、こちらはコンテナベースの実行環境を対象とした製品です。Dynamic Worker Loaderはそれを置き換えるものではなく、「より軽量で高速な代替ルート」として共存するポジショニングと考えられます。重い処理やOSレベルの操作が必要なケースにはコンテナが引き続き有効で、軽量なコード実行や大量の並行処理が必要なシーンにはDynamic Worker Loaderが向くという棲み分けが想定されているようです。
また、Code ModeはMCPサーバーと組み合わせることが可能で、AIエージェントがMCPを経由してDynamic Worker Loaderを呼び出すというアーキテクチャも技術的には成立します。既存のMCPインテグレーションを活かしながら、コード実行部分だけを切り出して安全に処理する構成として、エンタープライズ用途での採用が検討されうる形といえます。
IT担当者・導入検討者が確認しておきたい点
Dynamic Worker Loaderは技術的に興味深い発表ですが、実務での活用を検討するにあたってはいくつかの観点を整理しておく必要があります。
言語・ランタイムの制約
Cloudflare WorkersはV8アイソレートをベースとしており、主な実行対象はJavaScript／TypeScriptです。Pythonや他の言語でAIエージェントのロジックを構築している場合は、Dynamic Worker Loaderをそのまま適用できるケースは限られる可能性があります。WebAssemblyへのコンパイルが可能かどうかも、技術選定時に確認が必要な点です。
セキュリティモデルの理解
「アイソレートによる隔離」と「OSレベルの仮想化コンテナによる隔離」は、セキュリティの設計モデルが異なります。V8アイソレートはJavaScriptエンジン内での分離であり、ブラウザセキュリティモデルの延長線上にあります。コンテナはLinuxのカーネル機能（namespaceやcgroups）による分離です。組織のセキュリティポリシーや監査要件によっては、どちらのモデルが適合するかを精査する必要があります。
CloudflareエコシステムへのロックインとAPIアクセス制御
Dynamic Worker Loaderを活用するには、Cloudflare Workersの実行基盤に乗ることが前提となります。既存のシステムがAWSやGCPなど他クラウドに依存している場合、インテグレーションの工数や設計上の制約を事前に確認しておくことが重要です。また、サンドボックス内のコードが外部サービスや社内システムに対してどのようなアクセス権を持つかの制御設計も、初期から詰めておくべき点です。
コスト構造と実際のスケール感
「コンテナより軽い」という表現は正しいとしても、大量のAIエージェントが同時稼働する場合のコスト試算は別途必要です。Cloudflare Workersの料金は実行回数・CPU時間ベースであり、エージェントの利用パターンによっては予想外のコストが発生する可能性もあります。現時点でDynamic Worker Loaderがどのティアの料金プランに含まれるか、あるいは追加費用が発生するかどうかも、正式リリース後に確認すべきポイントです。
現時点での成熟度
Cloudflareは当初この機能を「実験的」として公開しており、本番環境での大規模採用を前提とするには、仕様の安定性やドキュメントの充実度、サポート体制を確認してから判断することが望ましいと考えられます。
「コードを書くAI」が当たり前になる世界へ
今回のDynamic Worker Loaderの発表は、単なるインフラの速度改善にとどまらない意味を持ちます。AIエージェントがコードを書いて実行するという「Code Mode」のコンセプトを、現実のサービスとして成立させるための基盤整備である、と捉えることができます。
AIがコードを生成する場面はすでにGitHub CopilotやCursorなどのツールで日常化していますが、「生成したコードをリアルタイムに実行してタスクを完結させる」という段階は、セキュリティと性能の両立という高い壁がありました。コンテナの起動遅延が数百ミリ秒ある環境では、ユーザーが対話するたびにその待機が発生し、体験として成立しにくい面があります。動的なコード実行の遅延をミリ秒単位に抑えることで、エージェントとの対話がはじめて「自然な速さ」で機能するといえます。
メモリ効率の改善は、スケールの問題でもあります。一人のユーザーが一つのエージェントを持つのではなく、多数のサブエージェントが並行して動くアーキテクチャが今後一般化していくとすれば、実行環境の軽量化は単なる性能指標ではなく、ビジネスモデルの実現可能性に直結する要素になるかもしれません。
Cloudflareがインフラ企業としてAIエコシステムの中で独自のポジションを確立しようとしている姿勢は、このDynamic Worker Loaderにも色濃く表れています。エッジコンピューティングのネットワークを活かした低レイテンシの実行環境と、Workersの軽量アイソレーション技術の組み合わせは、他のクラウドプロバイダーが短期間で模倣しにくい差別化要因になりうると見る向きもあります。
AIエージェントが「考えてコードを書いて動かす」という一連のサイクルが、ユーザーの手元でどれだけシームレスに実現されるか——Dynamic Worker Loaderはその問いに対する一つの実践的な回答として、今後の業界での受け入れられ方が注目されます。
