Cloudflare Dynamic Workers実践設計: AI生成アプリを安全に動かすサンドボックス運用
CloudflareのDynamic Workers関連発表は、単なる新機能追加ではなく「AI生成アプリをどう安全に量産運用するか」という設計課題への回答になっています。モデルを呼ぶだけの時代から、生成された小さなアプリ群を統制して動かす時代に移った、というのが本質です。
参考文脈: https://blog.cloudflare.com/dynamic-workers/ / https://blog.cloudflare.com/durable-object-facets-dynamic-workers/。
いま何がボトルネックか
多くの企業で、生成AIを使って作られる内部ツールや業務補助アプリの数は急増しています。一方で、プラットフォームチームのレビュー能力は線形にしか増えません。結果として、次の3つが詰まります。
- どのアプリがどの権限で動くのか不明瞭
- 状態分離が甘く、テナント境界が崩れやすい
- 問題発生時に責任者・停止手順が曖昧
つまり課題は「生成品質」より「実行統制」です。
推奨する設計原則
まず制御面と実行面を分離します。
- 制御面: ポリシー判定、配布許可、クォータ付与、監査記録
- 実行面: 推論実行、ツール呼び出し、データアクセス、レスポンス返却
各生成アプリには、所有組織・リスク区分・許可コネクタ・保存期間を含むメタデータ封筒を必須化します。これを実行時に強制できる構造が重要です。
サンドボックスを三層で作る
- ランタイム境界: 外向き通信はデフォルト拒否、許可リストのみ通す
- 状態境界: Durable Objectsをアプリ単位で分割し、テナントキーを固定
- 認証境界: 実行ステップごとに短命・最小権限トークンを発行
この三層で、1つの漏えいが全体事故に拡大する経路を断てます。
信頼性運用の具体策
生成アプリは人手実装よりも「仕様の揺れ」に弱いため、通常の監視だけでは不十分です。以下を標準化します。
- 実行前のツール契約検証
- 書き込み処理のidempotency key
- ワークロード別のタイムアウト予算
- アプリ単位のサーキットブレーカー
- ポリシー違反の自動停止
失敗をゼロにするのではなく、失敗を局所化して復旧を定型化するのが実務的です。
コスト管理は再試行を可視化する
エージェント運用では「黙って増える再試行」がコスト悪化の主因になります。管理指標として、
- ユーザー操作1回あたりの最大ツール呼び出し数
- アプリ階層別のトークン上限
- 部門別の月次予算枠
- キャッシュ再利用率
を設定します。上限超過時はハードエラーではなく、決定論的な代替フローへ降格させる設計が効果的です。
90日導入ロードマップ
- 1〜30日: 既存生成アプリの棚卸しとリスク分類
- 31〜60日: 実行境界・状態境界を強制し、アプリ別可観測性を整備
- 61〜90日: 公開ゲート、SLO、停止基準を運用ルール化
まとめ
Dynamic Workersの価値は、速さそのものではなく、生成アプリを「制御可能な単位」で増やせることにあります。サンドボックス、最小権限、監査可能性を同時に組み込めば、AI活用の拡大とガバナンスを両立できます。
