Cloudflare Dynamic Workers時代のAIエージェント実行基盤設計

いま起きている変化

CloudflareのDynamic WorkersとWorkers AI関連アップデートは、AIエージェント実行基盤における前提を変えつつあります。従来の「重いコンテナを長時間立てる」方式から、「軽量アイソレートを短時間で大量に起動する」方式へのシフトです。

この変化を単純に性能改善として捉えるのは不十分です。実務では、遅延・コスト・セキュリティ境界を同時に再設計できることが本質です。

アイソレート前提で設計すると何が変わるか

起動コストが小さい環境では、分離そのものを標準動作にできます。具体的には以下です。

タスク単位で実行環境を都度生成
永続資格情報を減らし短命トークンへ寄せる
失敗時の影響範囲をタスク境界内に閉じ込める
役割別のポリシーを細かく適用

結果として、可用性だけでなく監査適合性も高めやすくなります。

推奨4プレーン構成

1. Control Plane

タスク受理
リスク階層判定
実行プロファイル配布
短命資格情報の発行

2. Execution Plane（Isolates）

タスクごとの起動
ツール呼び出し
実行制限（時間・メモリ）
中間結果の標準イベント化

3. Policy Plane

ツール許可リスト
外部送信先制御
秘密情報アクセス判定
破壊的操作前の人手承認

4. Observability Plane

レイテンシ、失敗率、再試行率
ポリシーブロック理由
トークン消費とタスク成功率
失敗再現用のリプレイ情報

この分離により、拡張速度と統制品質を同時に維持しやすくなります。

性能最適化の実践ポイント

リスク階層ごとに起動SLOを設定
長時間フローは分割可能なジョブへ再設計
データ境界近くで軽量推論・ルーティング
キュー長と同時実行上限で常時バックプレッシャー

特に4番がないと、速い基盤ほど障害の伝播も速くなります。

セキュリティ設計の要点

短命シークレット化

タスク単位で払い出し、完了後は無効化。常設キーを前提にしない。

ツール能力の明示

ツールごとに「何ができるか」を定義し、未定義操作は拒否。

意図別Egress制御

参照系APIと更新系APIを同列に扱わない。

Prompt/Tool Injection対策

外部入力とツール説明文の検査を実行前に差し込む。

高速起動の価値は、検査を省略しない設計で初めて活きます。

FinOps設計で見るべき指標

アイソレート化はアイドルコストを下げますが、再試行やバーストで費用が膨らむことがあります。以下を追跡してください。

成功タスクあたりコスト
ポリシー準拠タスクあたりコスト
再試行コスト比率
テナント別 p95 コスト

単価だけ見ると、失敗再実行が隠れて判断を誤ります。

コンテナ運用からの移行手順

Phase 1: シャドー実行

読み取り系タスクの一部をミラーし、品質差とコスト差を測定。

Phase 2: 低リスク本番移行

短時間・低リスクワークロードから実トラフィックへ。

Phase 3: 中リスク拡大

監査証跡とロールバック品質が安定したら適用範囲を拡張。

Phase 4: ハイブリッド最適化

バースト系はアイソレート、状態保持系はコンテナ、と使い分ける。

一気に全置換せず、実測で配分を決めるのが現実的です。

運用ループ

日次: エラーバジェット、ポリシーブロック急増の確認
週次: 失敗多発ツール経路とタイムアウト箇所の改善
月次: リスク分類と許可ポリシーの再評価

「速い基盤」だけでは運用は回りません。失敗の学習ループを組み込むことが、継続的な品質改善に直結します。

まとめ

Dynamic Workersのような高速アイソレート基盤は、AIエージェント運用に大きな可能性があります。ただし勝ち筋は、単純な速度競争ではありません。

タスク境界の分離、短命資格情報、明示的ポリシー、再現可能な証跡。この4点を最初から実装することで、速度と信頼の両立が可能になります。