Cloudflare Dynamic Workers時代のAIエージェント運用設計（2026）
CloudflareのDynamic Workers関連アップデートは、AIエージェント運用の前提を大きく変えました。ポイントは「速く実行できること」そのものではなく、自律実行を安全に制御できる実装面が整ってきたことです。今後の差は、プロンプトの巧拙よりも、実行ガードレールと障害設計の品質で決まります。
本稿では、Dynamic Workersを使ってエージェントを本番運用する際に必要な設計・運用の型を、実務観点で整理します。
なぜ“動的分離”が重要なのか
従来のAPI処理は経路が比較的固定され、失敗パターンも予測しやすい構造でした。一方でエージェントは、入力に応じてツール呼び出し順序が変化し、外部依存が増え、実行時間やコストの振れ幅も大きくなります。
Dynamic Workersの価値は、こうした不確実性を「1実行単位の隔離」で受け止められる点です。ただし、隔離だけでは不十分です。以下の3点を先に定義しないと、本番で必ず破綻します。
- 何を実行可能にするか（権限境界）
- どの状態を永続化するか（再開可能性）
- 失敗時にどう戻すか（ロールバックと代替経路）
推奨アーキテクチャ
実運用で安定しやすい構成は次の通りです。
- エッジ入口（ステートレス）: 認証、レート制御、入力検証
- セッション調停層（Durable Objects）: 実行台帳、再試行回数、進行状態
- 実行サンドボックス（Dynamic Workers）: 短命・最小権限でツール実行
- ワークフロー制御層: ステップ単位タイムアウト、補償処理、再開制御
- 監査ログ基盤: 事後検証可能な不変ログの保管
設計原則はシンプルです。計画とポリシーは永続化、実行は使い捨て。これを崩すと障害解析が一気に難しくなります。
権限モデルはdeny-by-defaultで開始する
エージェント事故の多くは「幻覚」ではなく「権限設計ミス」です。特にexecや外部HTTP呼び出しを許可する場合、IAMと同等の厳密さが必要です。
- タスク単位の短命クレデンシャル発行
- ツールごとの最小権限ロール割り当て
- 宛先ホスト・API経路の明示的allowlist化
- 書き込み操作は業務要件で個別審査
- すべてのツール呼び出しにポリシー判定IDを付与
この設計を先に固めるだけで、インシデント時の影響範囲を大幅に縮小できます。
監視指標は“成功率”の定義から作り直す
HTTP 200比率や平均応答時間だけでは、エージェント品質を測れません。以下をSLO候補として導入するのが現実的です。
- 業務タスク完了率（単なるレスポンス成功ではない）
- ポリシー拒否率（権限制御と攻撃圧の監視）
- 再試行増幅率（コスト暴走の先行指標）
- 成功タスクあたりツール呼び出し数中央値（効率性）
- 人手エスカレーション率（信頼性の実運用指標）
サービスの重要度ごとに許容値を分けることが重要です。社内自動化と対顧客ワークフローを同じ基準で運用すると、どちらも最適化できません。
失敗制御の実装ポイント
失敗時に「もう一度試す」を繰り返すだけの設計は危険です。必ず停止条件を実装します。
- 再試行回数の上限固定
- 失敗分類（ポリシー/依存先/タイムアウト/意味不一致）
- 分類ごとの代替経路（キュー退避、手動レビュー、機能縮退）
- 事後解析可能な構造化トレース保存
長い処理では中間成果物のチェックポイント化も必須です。ワーカーが入れ替わっても進捗を失わない設計が、運用コストを左右します。
導入ロードマップ（30-60-90日）
- 0-30日: ワークフロー棚卸し、権限タクソノミー策定、実行台帳導入
- 31-60日: カナリア運用、deny-by-default強制、SLOダッシュボード整備
- 61-90日: 中重要度業務へ拡張、ロールバック自動化、障害演習実施
よくある失敗は、統制前に並列実行数だけ増やすことです。スループットより先に、可観測性と責任追跡性を完成させるべきです。
まとめ
Dynamic Workersは、エージェント実行基盤として非常に強力です。ただし本当の競争力は、ランタイム性能ではなく、実行の可視化・可逆性・説明可能性をどこまで担保できるかで決まります。高速性を活かすには、まず統制を設計する。これが2026年の実務的な正解です。
