Cloudflare Dynamic Workers時代のAI実行基盤設計：エージェント生成コードを安全に回す実践プレイブック
AIエージェントが日常的にコードを生成し、実行し、再試行する時代では、「速く動く」だけの実行基盤は不十分です。CloudflareのDynamic Workersは、コンテナ前提の重い実行モデルから、軽量アイソレート前提の実行モデルへと視点を移すきっかけになります。
参考:
ただし、本当に重要なのはランタイムの速さそのものではなく、低信頼コードを安全に扱う運用証跡を持てるかです。セキュリティ審査、監査、障害対応の3つに耐える設計にしない限り、PoCが成功しても本番運用は続きません。
なぜアイソレート前提が運用設計を変えるのか
従来のコンテナ中心のサンドボックスは境界分離に優れますが、起動遅延・イメージ管理・パッチ運用の負担が常につきまといます。アイソレート型は起動コストが非常に小さく、短命ジョブを大量に回すユースケースと相性が良い一方で、「何を許可するか」を厳密に定義する設計力が問われます。
AI生成コードは本質的に高頻度・低信頼です。だからこそ、環境準備よりポリシー評価に投資するアーキテクチャへ寄せるのが合理的です。
まず作るべき3段階の信頼モデル
生成コードを最初から同じ扱いにすると事故率が上がります。最低でも次の3層に分けるべきです。
- Tier 0（未検証提案）: 合成データのみ、外部通信禁止、短時間で強制終了。
- Tier 1（検証済み自動化）: 静的解析・契約テスト・ポリシーチェック通過後、限定的な通信を許可。
- Tier 2（本番昇格済み）: 人間レビューと既存デプロイ統制を経て本番適用。
失敗パターンは、Tier 0とTier 1を曖昧にしてしまうことです。重要なのは「恒久的に信頼する」ことではなく、昇格・降格を高速に回せる運用導線です。
初期導入で外せない統制ポイント
導入初期は高度なAI判定より、基本統制の方が価値を生みます。
- 機能権限の許可リスト（ネットワーク、ファイル、秘密情報、外向きドメイン）
- 実行予算（CPU、メモリ、実行時間）
- 実行ごとの不変IDと署名可能な監査ログ
- プロンプト→生成物→実行結果の一気通貫トレース
- 異常検知時の自動隔離と再実行停止
この5点がそろっていない状態でスケールさせると、障害時に「何が起きたか」が追えなくなります。
可用性だけでなく“ポリシーSLO”を持つ
多くの組織は稼働率SLOしか持っていません。AI実行基盤では次の指標が必要です。
- ポリシー評価遅延 p95 50ms以下
- 既知悪性ケースの遮断率（回帰テスト）
- トレース欠損率 0.1%未満
- 手動介入率の月次低下
これにより、セキュリティを「頑張っている感」ではなく、改善可能な運用品質として扱えます。
ありがちな導入失敗
デモ成功直後に全社有効化してしまうケースは危険です。まずは対象を1種類に絞り、月次で安全性指標を公開し、SLO安定を確認してから展開範囲を広げるべきです。
特に有効なのは、**「重大インシデント未解消のまま展開拡大しない」**という単純なゲートです。拡大判断を感覚ではなく基準で行えます。
6週間の導入ロードマップ
1〜2週目
権限プロファイルとポリシー契約を定義し、境界違反テストを先に作る。
3〜4週目
監査イベントの共通スキーマ化。検索可能な証跡基盤を整備。
5週目
敵対的プロンプトでレッドチーム検証。封じ込めとキルスイッチの実効性を確認。
6週目
追加チームに限定展開。ロールバック条件を事前に明文化。
まとめ
Dynamic Workersは、AI生成コードの実験速度を大幅に上げられる基盤です。しかし勝敗を分けるのはランタイムではなく、信頼階層・統制・証跡を一体で運用できる設計です。ここを固めたチームほど、速度と安全性を同時に取りにいけます。
