Managed Agentsのメモリストアを使い始めて数ヶ月——同じ設定が何度も書き込まれ、半年前の指示と先月の指示が矛盾し、エージェントがどちらに従えばいいか分からなくなった経験はないでしょうか。IT担当者を専任で置けない中小企業ほど、メモリの手動整理に時間を割けず、この問題を放置しがちです。Anthropicが研究プレビューとして公開した「Dreams」は、この整理作業そのものをエージェントに任せる仕組みです。
メモリストアはなぜ放置すると使い物にならなくなるのか
メモリストアは最大1万件が上限で、重複や矛盾が蓄積すると新規書き込みに失敗する。
各セッションがメモリストアに書き込む内容はローカルかつ増分的です。ユーザーの好み、プロジェクトの慣習、過去の失敗といった情報がセッションを重ねるごとに追記されますが、誰も整理しなければ重複エントリ・矛盾した指示・陳腐化した情報がそのまま積み上がります。ストアが1万件の上限に達すると、新規メモリの直接作成だけでなく、エージェントが未マップのパスにファイルを書き込む操作も失敗するようになり、気づいたときには本番のエージェント挙動に影響が出ています。
Dreamsとは何をする仕組みか
Dreamsは既存ストアと過去セッションを読み、整理済みの新しい出力ストアを生成する。
Dreamsは、既存のメモリストア1つと過去のセッション記録1〜100件を入力として受け取り、重複を統合し、矛盾する記述を最新の内容で置き換え、新たな気づきを抽出した別の出力ストアを生成します。重要なのは、入力側のメモリストアは一切変更されない点です。結果が気に入らなければ出力ストアを破棄するだけでよく、本番運用中のストアを壊すリスクなしに試せます。instructionsパラメータ（最大4,096字）で「コーディング規約に関する記述を優先し、一回限りのデバッグメモは無視する」といった焦点を指定でき、Claude Opus 5やClaude Sonnet 5を含む複数モデルから処理に使うモデルを選べます。
Dreamsはどう運用フローに組み込むのか
Dreamsは非同期ジョブで、完了までステータスをポーリングして確認する設計になる。
ジョブを作成するとpending状態で返り、処理が進むとrunningに移行します。完了（completed）すると出力ストアのIDがoutputsに現れるので、内容をレビューしたうえで今後のセッションをその出力ストアに切り替えるか、不要であれば削除・アーカイブします。公式ドキュメントが推奨する使い方は、ストアが1万件の上限に近づく前にDreamsで整理し、整理後のストアにセッションを切り替えて元のストアをアーカイブする運用です。課金は選択したモデルの標準トークン料金で、入力セッションの数と長さにほぼ比例して増えるため、最初は少数セッションで試し、整理品質に納得してから対象を広げるのが安全です。
中小企業はDreamsの導入をどう判断すべきか
Dreamsは研究プレビューのため、まず小規模な試行から段階的に評価するのが現実的だ。
専任のプラットフォームチームを持たない中小企業にとって、メモリの手動棚卸しは後回しにされがちな作業です。Dreamsはこの作業を定期ジョブとして自動化できますが、2026年10月時点では研究プレビューのためアクセス申請が必要で、本番の全ストアにいきなり適用するものではありません。まずは最も肥大化しているストア1つと直近の少数セッションで試し、出力ストアの品質とコストを確認してから、定期実行に組み込むかどうかを判断する進め方が現実的です。Managed Agentsの導入設計やメモリ運用の整備についてはKuuの AI Opsでも支援しています。
参考
まとめ
Managed Agentsのメモリストアは便利な反面、放置すれば重複と矛盾で機能しなくなります。Dreamsは過去セッションから非破壊的に整理済みストアを生成する仕組みで、上限に達する前の定期整理に組み込むことで、専任の運用担当者がいなくてもメモリ品質を保てます。導入可否の判断やManaged Agentsの運用設計に迷う場合は、Kuuの AI Opsにご相談ください。