Cloudflare Workers AIとDurable Objectsで作るエージェント記憶ガバナンス（2026）

エッジでの推論実行自体は、すでに現実的な選択肢になりました。次に問題になるのは、エージェントが持つ「記憶」をどう管理するかです。Cloudflare Workers / Workers AIの進化は、計算のスケール性だけでなく、状態管理の設計力が運用品質を左右することを示しています。

ステートレスな推論は拡張しやすい一方、実用的なエージェントには文脈保持が必要です。この矛盾を解くには、記憶を単一ストアで抱え込まない設計が必要です。

記憶を目的別に分ける

まず、記憶を4クラスに分割します。

Session Memory: 会話の短期文脈
Task Memory: 複数ステップ処理のチェックポイント
Policy Memory: ルーティング規則、ガードレール、制約
Audit Memory: 監査・追跡のための不可変ログ

この分離がないと、保持期間とアクセス権限が衝突し、セキュリティと性能の両方で破綻しやすくなります。

Durable Objectsの役割を明確化する

Durable Objectsは、セッションアフィニティや逐次更新制御に非常に有効です。

テナントやユーザー単位で決定的なIDに束ねる
更新直列化で競合状態を減らす
ホットな作業状態をエッジ近傍に置く

ただし、長期保存の全責務をDurable Objectsに寄せるのは危険です。協調制御と短期状態に集中させ、長期記憶は別ストアへ退避する二層設計が安定します。

メモリライフサイクルを自動化する

実運用で効くのは次の仕組みです。

クラス別TTL
長時間セッションの要約チェックポイント
永続化前の機密フィールド秘匿化
定期圧縮と重複除去
法務要件向けのホールド例外

“後で運用で何とかする”は必ず失敗します。生成AI運用では、記憶肥大がそのまま障害と監査リスクになります。

信頼性パターン

冪等更新

ツール実行と記憶更新は、リクエストID付きで再実行可能にする。

スキーマ版管理

プロンプトやモデル更新で記憶構造は変わるため、版管理なしでは静かに破損する。

復旧経路

オブジェクト再起動やリージョン移動時は、正本ストアから上限付きリプレイで再水和する。

劣化モード

バックエンド遅延時はフル停止ではなく、最小文脈モードに自動退避する。

観測項目をSLOとして扱う

記憶書き込み遅延（p95/p99）
文脈取得ヒット率
古い文脈を参照した誤応答件数
要約品質の劣化兆候
リージョン間整合遅延

これらを内部メトリクス扱いにせず、サービス品質指標として運用することが重要です。

ガバナンス実装

テナント単位の鍵分離
記憶読み書きの監査ログ
プロンプト組み立て時のポリシーチェック
エクスポート／削除フローの明示
応答への来歴タグ付与

監査対応は“後付けの証跡探し”では間に合いません。設計段階で証跡生成を組み込む必要があります。

実装順序の推奨

記憶クラスと保持方針を定義
Durable Objectsのキー戦略と冪等更新を実装
要約・圧縮ワーカーを追加
記憶SLOダッシュボードを整備
遅延・再起動・部分障害のカオス訓練を実施

まとめ

エッジ上の状態保持エージェントは、もう実験段階ではありません。成功条件は、推論性能よりも記憶ガバナンスの完成度です。Durable Objectsを中核にしつつ、ライフサイクル制御・可観測性・統制を三位一体で設計できるチームが、2026年の運用競争を優位に進められます。