AIエージェントは、推論より先に実行基盤でつまずきます。ツール呼び出しを増やすほど遅くなり、コンテナを立てるほど重くなり、外部APIを触らせるほど安全設計が難しくなります。CloudflareのDynamic Workersは、この3つをまとめて整理するための仕組みです。
https://blog.cloudflare.com/dynamic-workers/
この記事では、Dynamic Workersが何を解決するのか、通常のコンテナ実行と何が違うのか、AIエージェントにどう効くのかを整理します。
- なぜAIエージェントの実行に専用のサンドボックスが要るのか
- Dynamic Workersが軽い理由
- TypeScript APIとHTTP APIの使い分け
- 料金と導入時の注意点
実行基盤がボトルネックになる
CloudflareがDynamic Workersを出した背景は明快です。AIが生成したコードを、そのままアプリ内で実行するのは危険です。ユーザー入力次第で、不要な権限を持つコードを走らせる余地があるからです。そこで必要になるのが、アプリ本体から切り離されたサンドボックスです。
従来の選択肢はコンテナです。ただし、コンテナは起動が重く、メモリ消費も大きいです。エージェントごと、リクエストごとに毎回立てるには向きません。特に、エンドユーザーごとに個別のAIワークフローを動かす設計では、速度とコストが先に限界を迎えます。
Dynamic Workersは、Cloudflare Workersの実行モデルをそのまま使い、コードを実行時に読み込んで別Workerとして起動します。起動の単位が軽いので、エージェントが短い処理を何度も回す構成と相性が良いです。
何が軽いのか
Cloudflareの説明で重要なのは、Dynamic Workersの土台がisolatesだという点です。isolatesはV8の分離実行環境で、コンテナよりずっと小さく、立ち上がりも速いです。記事では、数ミリ秒で起動し、数メガバイトのメモリで動くと説明されています。
この性質が効くのは、AIエージェントの典型的な処理が「長時間の常駐」ではなく「短い実行の連続」だからです。例えば、次のような処理です。
- 受け取った指示をコードにして実行する
- APIを数回たたいて結果だけ返す
- 一時的なファイル操作や変換を行う
- 必要なときだけ外部通信を許可する
こうした用途では、常に温かいコンテナを保持するより、必要なときだけ新しい実行環境を起こすほうが合理的です。
TypeScriptでAPIを見せる発想
Dynamic Workersのもう1つのポイントは、エージェントに何をどう見せるかです。Cloudflareは、MCPのようなフラットなツール定義より、TypeScriptの型付きAPIを推しています。
理由は単純です。エージェントは、短い型定義なら理解しやすく、実行時の呼び出しもコードとして組み立てやすいからです。OpenAPIは表現力がありますが、定義が長くなりやすく、エージェントに読ませるトークンも増えます。
TypeScriptのインターフェースなら、たとえばチャットルームの履歴取得、投稿、購読のような操作を、そのまま型として渡せます。これなら、エージェント側は「何ができるか」を短い情報量で把握できます。
この設計は、単に見通しがよいだけではありません。安全性にも効きます。公開したい機能だけを薄いラッパーに切り出せるので、余計な権限をエージェントに渡しにくくなります。
HTTP連携は補助に回す
もちろん、すべてをTypeScript RPCに寄せる必要はありません。Dynamic WorkersはHTTPの外部APIも扱えます。その場合は globalOutbound で送信前のリクエストを検査し、認証情報の注入、許可先の制限、拒否、書き換えを行えます。
ここで重要なのは、秘密情報をサンドボックスに見せない設計です。エージェント本体は認証鍵を保持せず、外向き通信の段階でだけ必要なヘッダーを付与します。これなら、モデルが秘密を出力してしまう事故を減らせます。
ただし、Cloudflare自身もTypeScript RPCのほうが少ないトークンで済み、権限の境界も明確だと説明しています。既存のREST資産を活かす場面だけHTTPを使い、そうでなければRPCに寄せるのが現実的です。
料金は使い方次第で十分軽い
Dynamic Workersの料金は、少なくとも発表時点では1日あたりのユニークWorker作成、リクエスト、CPU時間の3軸で考えます。ドキュメントでは、作成単価は1 Workerあたり0.002ドルという案内がありますが、ベータ期間中はこの課金が無効化されていると書かれています。
ここで見るべきなのは、単価そのものより、AIエージェントの実行単位に合っているかです。大きな常駐インスタンスを抱えるのではなく、短命な実行を大量に回す前提なら、価格設計も理解しやすくなります。少なくとも、コンテナを都度起動するより、使い方によってはかなり扱いやすいです。
どんな場面で効くか
Dynamic Workersが刺さるのは、AIが「判断」だけでなく「実行」も担当する場面です。
- ユーザーごとに異なる自動化を走らせたい
- APIをまたいだ処理をエージェントにまとめて任せたい
- 実行コードを一時的に生成し、その場で安全に動かしたい
- 低遅延で、ワークロードを地域分散したい
逆に、常駐プロセスが前提のシステムや、複雑なOSレベルの依存関係を強く使うワークロードには向きません。ここはコンテナのほうが自然です。Dynamic Workersはコンテナ置き換えの万能薬ではなく、AIエージェント向けに軽量化した実行レイヤーです。
まとめ
Cloudflare Dynamic Workersは、AIエージェントのための「軽い実行環境」を作る発想です。コンテナより速く、Workerとして分離でき、TypeScriptで権限を絞れる点が強みです。
エージェントにコードを書かせる構成は増えています。そこで最後に残る課題は、どう安全に、どう軽く、どう短い待ち時間で実行するかです。Dynamic Workersは、その答えをCloudflare流にまとめた機能です。