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流にまとめた機能です。