Cloudflare Agent Memory本番運用ガイド：ガバナンス・保持期間・検索設計
CloudflareのAgents Weekで示されたAgent MemoryとAI Gatewayの方向性は、エージェント開発の優先順位を大きく変えました。メモリは会話体験の付加価値ではなく、業務品質を左右する基盤機能になっています。
参照: https://blog.cloudflare.com/tag/ai/
ただし、本番運用で必要なのは「覚えること」そのものではありません。何を保存し、誰が参照でき、いつ破棄されるかを制御できることです。ここが曖昧なまま実装すると、精度より先にセキュリティ事故とコスト増が到来します。
本番メモリは“機能”ではなく“ライフサイクル”
実運用では、メモリを1つのDBに貯めるだけでは破綻します。最低でも次の流れを明示します。
- 会話やツール出力から候補を抽出
- 機密度と保存目的で分類
- ポリシーに通る情報だけ永続化
- タスクごとに必要分だけ検索
- 期限到来で要約・削除・匿名化
この流れがないと、会話ログがそのまま負債になります。
推奨構成
- Workersで書き込み前ポリシー判定
- Durable Objectsでセッション整合性管理
- KV/永続ストアでメモリオブジェクト保存
- 検索時に権限と機密度を再評価
- 監査ログで参照理由まで追跡
重要なのは、類似度検索の前にポリシー判定を置くことです。関連していても、見せてはいけない情報は返さない設計が必須です。
データモデル設計
メモリレコードには本文だけでなく、運用のためのメタデータを持たせます。
- memory_id / subject_id / workspace_id
- content_summary / source_type / embedding_ref
- sensitivity_level / consent_scope
- created_at / last_accessed_at / expires_at
- lineage（どの会話・処理で生成されたか）
lineageがないと、事故時に影響範囲を追えません。
ワークロード別の保持戦略
一律の保存期間は危険です。
- サポート支援: 数日単位で短期保持
- 開発支援: スプリント単位で保持
- 営業支援: CRMルールに合わせた保持
- 分析支援: 生データ短期、要約長期
業務ごとに「残す価値」と「残す危険」が違います。
コスト統制
永続メモリは便利ですが、検索上限を決めないと推論コストが静かに膨らみます。
- 1リクエストあたり検索件数上限
- メモリ投入トークン上限
- 新しさと確信度で優先順位づけ
- Nターンごとの要約チェックポイント
SLOとしては、検索p95遅延、再利用率、取り出したメモリの有効利用率を追うと劣化を早期検知できます。
非交渉のセキュリティ要件
- 高リスク項目の書き込み拒否
- ツール別最小権限資格情報
- 参照判断の改ざん困難な監査
- 冪等キーによる重複書き込み防止
- 緊急削除の検証可能な手順
「手動で消せる」は統制になりません。再現可能な運用手順まで含めて設計します。
30-60-90日導入
30日: 現行コンテキストの利用実態計測 60日: 書き込みポリシーと選択的検索を導入 90日: メモリ汚染・過剰参照の演習とRunbook整備
まとめ
Agent Memoryは精度向上の装置であると同時に、リスクを増幅しうる装置です。保存・検索・廃棄を政策的に管理し、予算と監査を接続できるチームが、長期的に強いエージェント基盤を作れます。
