Dynamic Workers実戦導入: エージェント向けサンドボックス運用プレイブック

CloudflareのDynamic Workersは「起動が速い実行基盤」として語られがちですが、現場で本当に重要なのは速度そのものではありません。より本質的な変化は、AIエージェントが動的に生成したコードを、コンテナ中心の重い実行経路ではなく、軽量な分離実行を標準経路にできる点です。

参考: https://blog.cloudflare.com/dynamic-workers/。

なぜ今この設計が必要なのか

背景には、次の3つの圧力があります。

エージェントが扱うコードの非定型性が急増している
UX基準が「チャット並みの応答速度」へ移行している
短命タスクにコンテナ制御面を使うコストが割高になっている

つまり、従来の「とりあえずコンテナで包む」だけでは、コスト・遅延・運用複雑性の三重苦になりやすい。Dynamic Workersはこのボトルネックを崩す選択肢ですが、導入時に観測と統制を怠ると、障害が速くなるだけです。

先に脅威モデルを作る

まずは性能比較ではなく、失敗の形を定義します。

プロンプト注入により想定外の外部通信が発生する
生成コードがデータ持ち出し経路を作る
ループ暴走で実行課金が膨張する
テナント間の負荷干渉で遅延が増幅する

最低限の防御として、以下を初期実装に含めるべきです。

送信先の許可リストを実行前に強制
タスク単位のCPU・メモリ・時間上限
リクエストIDに紐づく不変監査ログ
シークレットは明示許可時のみ注入

ポイントは、各実行を「将来の監査対象」だとみなして設計することです。

実行エンベロープ設計

現場で再利用しやすい形は、4層エンベロープです。

Admission層: テナントポリシー、コード起点、タスク種別を検証
Execution層: 分離実行＋厳格クォータで処理
Observation層: レイテンシ、ネットワーク形状、ポリシー判定を記録
Result層: 出力をサニタイズし、監査メタデータ付きで返却

この構造にすると、インシデント時に「何が起きたか」だけでなく「なぜ許可されたか」まで追跡できます。

SLOは平均値ではなくテール中心

エージェント系ワークロードでは平均値最適化がほぼ意味を持ちません。ユーザー体感を壊すのはp95/p99です。

推奨SLO:

タスク種別ごとの起動p95
重要ユースケースの完了p99
認可・ポリシー判定の遅延予算
障害予算を原因カテゴリ別に可視化

対話型タスクとバッチ型タスクを同じSLOに混ぜないこと。運用の性質が違います。

FinOpsの見方を変える

分離実行は基盤コストを下げやすい一方、呼び出し回数の増加で別の課金圧力が生まれます。よって、KPIは「インスタンス稼働率」では不十分です。

見るべき指標:

成功タスクあたりコスト
ポリシー別リトライ回数
ガードレールによる中断率
定型プレアンブルのキャッシュ効率

コストの変動要因を「需要変動」か「ポリシー設計」かで説明できなければ、観測不足です。

90日導入シーケンス

1〜3週: 基線計測と最小ガードレール

既存経路の遅延・失敗・単価を計測
タスクをリスククラス分け
最小ポリシースキーマ定義

4〜7週: シャドー実行

本番トラフィックで並行検証
遅延・失敗・ポリシー判定の差分を比較
重要タスクの再現性を確認

8〜10週: 段階的切替

低リスク領域から移行
テナント別クォータ導入
SLO逸脱時の自動ロールバック設定

11〜13週: 運用定着

ランブック整備
漏えい・逸脱想定の演習
経営向けにリスク/コスト可視化

失敗しやすい導入パターン

全タスクを同時移行する
「サンドボックス化=安全完了」と誤認する
テナント分離された観測基盤なしで開始する
実行安定化前にプロンプト最適化へ走る

まとめ

Dynamic Workersの価値は速度だけではなく、実行統制の作り直しにあります。分離実行の速さに、ポリシー・監査・SLO運用を重ねて初めて、スケールできるエージェント基盤になります。