Cloudflare Dynamic Workersで作るAgent Sandbox運用: 2026実践ガイド

2026年のCloudflare周辺トレンドを見ると、エージェント処理をエッジに寄せたい要求は明確です。ただし同時に、無制限な実行環境を持ち込むとコストと事故率が急増します。そこで有効なのが、動的Workerサンドボックスを中核にした運用モデルです。

本稿では、実運用で耐えるための設計・制御・監視を、プラットフォーム運用視点でまとめます。

なぜ「動的サンドボックス」が必要か

従来の常駐型Agentランナーは、過剰プロビジョニングと権限肥大が起きがちです。Worker実行モデルには次の強みがあります。

リクエスト単位で分離しやすい
実行寿命が短く、残留リスクが小さい
観測点が境界に集まり、監査しやすい

重要なのは、起動の速さではなく運用ルールの明文化です。

制御プレーンと実行プレーンを分離する

制御プレーン

サンドボックスリース発行（短TTL）
ワークロード別ポリシーバンドル付与
テナントごとの予算/クォータ管理
監査向け署名付き実行レシート記録

実行プレーン

制約付きWorkerでタスク実行
承認済み先のみ外向き通信を許可
構造化ログを即時送信
タイムアウト/違反で強制終了

「実行側に判断させすぎない」ことが安定化の鍵です。

権限はプロンプトではなく能力プロファイルで管理

GitHub changelogで増えている細粒度権限管理と同様に、Agentにも能力プロファイルを適用します。

タスク意図を分類
対応する能力プロファイルを選択
プロファイル拘束付きトークンを発行
境界外アクションをゲートウェイで拒否

モデル再判定に依存する権限判断ループは、レイテンシと不確実性の温床です。

外向き通信ガバナンス（Egress）

コスト漏れと事故の多くはEgressから発生します。必須制御は以下です。

既定はdeny
プロファイル単位の宛先ホスト許可
宛先別のレート/バイト上限
応答サイズ制限
プライベートIPとメタデータ系への遮断

「とりあえず*で許可」は短期開発には楽でも、後で必ず負債化します。

状態管理は3層に分ける

Qiita/Zennの運用知見でも共通するのは、ホット状態を最小化する設計です。

実行中の一時状態: リクエストスコープ
短期セッション状態: 低遅延ストア
監査/再現の正本: 永続バックエンド

サンドボックス内部に長期状態を抱え込まないことが再現性を守ります。

監視は「文章ログ」より「イベント契約」

最低でも次のイベントを構造化で収集します。

sandbox_issued
tool_call_attempted
tool_call_blocked
execution_completed
execution_terminated

API境界から下流ツールまで相関IDを通すだけで、障害調査と監査工数は大幅に減ります。

スパイク耐性: キューを分離する

HNでもよく話題になりますが、Agentトラフィックは偏りが激しいです。対策は単純で強力です。

対話系の低遅延キュー
バッチ系の高スループットキュー

それぞれに別の同時実行枠と再試行予算を設定し、相互干渉を止めます。

FinOpsを最初から組み込む

テナント単位の日次予算枠
バイト/ツール/API呼び出しの計測
70%警告、100%ハードキャップ
自己確認できる利用ダッシュボード

コストを可視化すると、最適化の議論が感覚論から設計論へ変わります。

インシデント運用ランブック

問題能力プロファイルを停止
影響テナントのリースを失効
疑わしい宛先を全体遮断
レシート再生で影響範囲を特定
ポリシーパッチ後にカナリア復旧

担当とSLAを事前に決めることで、初動遅延を防げます。

90日導入計画

0-30日

既存ツールと宛先依存を棚卸し
初期能力プロファイルを定義
観測イベント契約を整備

31-60日

主要対話ワークロードを移行
クォータ強制を有効化
deny/timeout前提の障害訓練

61-90日

チャージバック可視化を全展開
ポリシー昇格パイプライン自動化
四半期レポート運用開始

まとめ

Dynamic Workersは高速実行の話だけではなく、Agent実行を統制可能にする運用モデルです。制御プレーン分離、明示権限、Egress計測を徹底すれば、速度と安全性を両立できます。

Cloudflareの公開情報や各種開発コミュニティの実践知を参照しつつ、自社の境界条件に合わせてプロファイルを育てるのが成功ルートです。