Cloudflare Dynamic Workers Open Betaを実運用化する: エッジ実行の安全設計
CloudflareのDynamic Workers Open Betaは、AI時代のプラットフォームが「コード実行そのもの」を機能化し始めたことを示しています。
参考: https://www.infoq.com/news/2026/04/cloudflare-dynamic-workers-beta/
しかし本質は起動速度ではありません。信頼できないコードを繰り返し実行しても、セキュリティ負債を増やさない運用設計ができるかどうかです。
なぜ分離実行モデルが重要か
コンテナ基盤でも動的実行は可能ですが、短命ジョブが多いユースケースでは課題が出やすいです。
- 起動待ちによる遅延
- メモリ効率の悪化
- 運用オーバーヘッド増大
分離実行（isolate）を活かせば、ミリ秒起動・軽量実行・高密度処理が可能になり、エージェントのツール実行や拡張機能基盤との相性が高まります。
機能より先に脅威モデルを定義する
動的実行を外部公開する前に、最低限次の脅威を明文化してください。
- 外部送信によるデータ持ち出し
- 権限境界不備による昇格
- リソース濫用によるDoS
- テナント間汚染
脅威ごとに、既定の防御策と検知指標をセットで定義することが重要です。
Capability中心の権限制御
実装は「暗黙許可」ではなく「明示的付与」で設計します。代表例:
- ネットワーク権限（許可ドメイン/プロトコル）
- ストレージ権限（バケット/キー範囲）
- 計算リソース（CPU時間/メモリ上限）
- シークレットアクセス（テナント単位の短命発行）
要求していない権限は付与しない、を原則化します。
本番運用で外せない保護策
効果が大きい4点は次の通りです。
- 実行クラス別の確定的クォータ
- 送信先のデフォルト拒否ポリシー
- 呼び出し元と紐づく実行由来ログ
- 異常検知時の自動停止スイッチ
これらが揃って初めて、Sandboxは実態を持つ運用機能になります。
AIエージェント連携時の原則
ランタイム生成コードは既定で非信頼として扱います。推奨フロー:
- 静的な事前ポリシーチェック
- 制約付きSandbox実行
- 構造化出力の検証
- 副作用前の最終ポリシー判定
モデルの一発出力を特権操作へ直結させないことが鉄則です。
コスト/容量計画
動的実行は利便性が高い反面、クラス分離なしではコストが急増します。以下の3階層運用が実務的です。
- 低コストのバッチ変換
- 低遅延の対話処理
- 高統制の規制対応処理
各階層にSLOと予算ガードレールを別々に設定します。
段階展開の進め方
Step 1
社内ワークロードと疑似トラフィックのみで検証。
Step 2
限定テナントへ公開し、権限許可リストを厳格運用。
Step 3
監査ログの信頼性が確認できた段階で、機能カタログとセルフサービスを拡張。
まとめ
Dynamic Workersの価値は速度単体ではなく、安全に拡張可能な実行基盤を作れる点にあります。権限境界、可観測性、即時ロールバック設計を最初から組み込むことで、エッジ時代の拡張アーキテクチャを実装可能にできます。
