Cloudflare Agent MemoryとAI Searchを実運用する, 状態を持つエージェント基盤の設計

CloudflareのAgents Weekで示されたAgent MemoryとAI Searchは、実務の本質的課題に直結しています。エージェントは記憶がないと役に立たず、記憶を持たせすぎるとコストとリスクが跳ね上がります。重要なのは「記憶する」ことではなく、何をどの期間どう管理するかです。

3層メモリで考える

実装しやすい構成は次の3層です。

• 短期キャッシュ（直近ターンの連続性）
• セッション記憶（作業中タスクの文脈）
• 永続サマリ（長期的な嗜好・確定知識）

この分離がないと、不要データが永続層へ流れ込み、検索ノイズと保管コストを同時に増やします。

AI Searchの品質を決めるのは前処理

検索品質はベクトルDB選定だけで決まりません。むしろ効くのは以下です。

• チャンク分割方針（意味単位）
• メタデータ設計（更新日時、信頼度、機密区分）
• 更新/失効ポリシー
• クエリ時のフィルタ条件

「とりあえず全文投入」は、後で高確率で失敗します。

ガバナンス必須項目

• データ区分別TTL
• インデックス前の機密マスキング
• エージェント単位の書き込み上限
• 取得信頼度しきい値
• 明示的な忘却フロー

特に忘却フローが無い設計は、法務・監査の観点で詰みやすいです。

コスト運用

推論トークンだけでなく、メモリ書込・検索呼び出しにも予算を設定します。ワークフロー単位で予算を切り、逸脱をアラート化すると、月末に突然コストが膨らむ事故を防げます。

まとめ

Agent Memoryは便利機能ではなく、データライフサイクル設計そのものです。AI Searchは検索APIではなく、運用品質の鏡です。初期段階でルールを明文化し、観測可能にしておくことが、状態を持つエージェントを安定運用する最短ルートです。