Dynamic Workers × Durable Objectsで作る, 本番で壊れない状態管理付きエージェント基盤

Dynamic WorkersとDurable Objectsの組み合わせは、エージェント基盤の難所である「柔軟性」と「一貫性」の両立に効きます。生成コードを高速に回しつつ、状態と副作用を制御できるからです。

参照:

先に結論, 実行と状態を分離する

本番運用で安定する構成は次の分離です。

Dynamic Worker: 生成ロジックやテナント固有処理を実行
Durable Object: セッション状態、順序制御、ロックを保持

Dynamic Workerは交換可能な計算資源、Durable Objectは整合性境界という役割に切り分けます。

この分離をしない場合、状態をプロンプトや一時キャッシュに寄せてしまい、障害時に再現不能になります。

よくある失敗をどう防ぐか

重複副作用

リトライ競合で次が起きます。

チケット二重発行
二重課金
競合するインフラ変更

Durable Objectでidempotency keyを検証し、順序を固定すれば大半を防げます。

セッション間リーク

共有ヘルパーを介して別セッション情報が混ざる事故は、生成コード運用で起こりがちです。

Durable Objectキーをセッション単位/テナント単位で明示し、分離境界をハード化します。

ポリシーの時間差崩壊

判定時と実行時で前提がズレると、許可したはずの操作が危険化します。

判定ハッシュを状態側に保存して再評価可能にすると、後追い検証が現実的になります。

実装ライフサイクル

1. Admission

セッションIDとリスク区分を発行
対応するDurable Objectへルーティング
利用可能ツールと予算を登録

2. Dispatch

Dynamic Workerへ不変実行エンベロープを渡す
エンベロープにポリシーハッシュ、ACL、期限を含める

3. Tool mediation

ツール呼び出しは必ず状態オーナーを経由
予算、順序、権限を都度検証
不許可時は構造化エラーで返す

4. Checkpoint

N操作ごとに要約と差分を保存
リプレイ範囲を小さく保ち復旧時間を短縮

5. Termination

最終状態ダイジェストを出力
一時資格情報を失効
判定/実行トレイルを保管

性能最適化のポイント

ワークロード形状でキュー分離

短時間同期処理
長時間マルチツール処理
承認必須の高リスク処理

を同一キューで混ぜないことが重要です。

ホットパーティション回避

多数セッションを同一Durable Objectキーに寄せるとロック競合で遅延が悪化します。キー設計を粒度細かく見直します。

状態サイズの上限管理

巨大可変オブジェクトは競合と再計算コストを増やします。イベント追記＋定期コンパクションが安定です。

セキュリティで抜けやすい項目

生成コードパッケージ署名検証
外向き通信先Allowlist
CPU/実行時間上限
ツール引数の選択的マスキング
prompt injection回帰テストの定期実行

高速化だけ先行すると、障害の伝播速度も上がります。

見るべきSLO

単純なp95遅延だけでは不足です。

admissionから初回応答までの遅延
ツール承認判定遅延
ロック競合率
重複副作用の防止率
ポリシー拒否比率

自律処理の品質は、このような運用品質指標で初めて可視化できます。

8週間導入プラン

1-2週

副作用を持つ処理の棚卸し
idempotency keyの共通設計
状態オーナー境界の定義

3-4週

重要ツール3系統を状態仲介に移行
構造化エラー仕様を統一
競合メトリクス計測開始

5-6週

生成実行をDynamic Workersへ移行
ランタイムガードレール適用
リトライ競合カオステスト

7-8週

パーティション/キュー調整
Runbook整備
監査向け証跡エクスポートを自動化

まとめ

Dynamic Workersは強力ですが、状態管理を曖昧にしたまま導入すると不安定化します。柔軟な実行面と、厳密な状態面を分離することが、本番品質のエージェント運用を作る最短ルートです。