Anthropicは2026年5月初旬、Claude Managed Agents向けに「Dreaming」「Multi-Agent Orchestration」「Outcomes」の3機能を追加した。中でも注目を集めているのがDreamingで、エージェントが蓄積したメモリを夜間バッチで再構築するという仕組みだ。Harveyの事例ではDreaming導入後にタスク達成率が約6倍に改善したと公表されている。本稿では筆者の検証環境（Managed Agents、Claude Sonnet 4.5、メモリ127件・セッション42件規模）で実機検証した結果を、効果と限界の両面から整理する。
Dreamingが解決しようとしているメモリ肥大化問題
Managed Agentsのメモリ機能は、エージェントが作業中に得た知見をmemory storeへ書き込んでいく。問題はここに矛盾した古い情報や、表現の微妙に違う重複が積み上がってくることだ。筆者の検証用エージェントを3週間と4日ほど運用したところ、127件のメモリのうち23件が「同じ意味だが微妙に表現の違う」重複だった。
重複が増えると検索精度が落ち、エージェントが古い結論に引きずられる症状が出る。Dreamingはこれをスケジュール実行で再構築する機能だ。公式ドキュメントによれば、最大100セッションまでの過去ログとmemory storeを読み、新しいmemory storeを生成する。重複は統合、矛盾は最新で上書き、横断パターンは新規エントリとして抽出される、という挙動だ。
実行時間は数分〜十数分。実際に試したところ、メモリ127件・セッション42件の規模で約7分23秒だった。Vim時代のctags再生成に近い、地味だが効くタイプの機能と表現するのが適切だろう。
API呼び出しに必要な2つのbeta header
呼び出すには2つのbeta headerが必要になる。managed-agents-2026-04-01に加え、Dreaming専用のdreaming-2026-04-21の両方を指定する必要がある。片方でも忘れると404が返ってくるため、筆者は最初の30分ほどここでハマった。beta headerの設計はもう少し検出しやすいエラーメッセージにしてほしいというのが正直な感想だ。
実装面の肝はスケジュール設定にある。手動トリガーも可能だが、本領は夜間バッチでの自動実行だ。筆者は1日1回、JST 03:30に走らせている。ピーク時間を避けつつ、朝の業務開始までに整理が終わる時間帯を選んだ形だ。dream.session_idを使えば実行中のセッションをストリーミング閲覧できるため、初期チューニング時はこれをログに流し続けると挙動が把握しやすい。
「自動更新」と「レビュー後反映」の2モード
Dreamingの結果は2つのモードで適用できる。memory storeに直接書き戻す自動モードと、差分をレビューして承認後に適用するモードだ。チーム共有のエージェントを運用しているなら、筆者は後者一択だと考えている。
理由は単純で、Dreamingが「矛盾を最新で上書き」してくる挙動のうち、約13%は「実は古い方が正しかった」ケースだった。たとえばAPIの仕様変更を一度ロールバックした履歴があると、Dreamingは新しい方を採用しがちだ。人間のレビュー工程を1段挟むだけで、この種の誤上書きはほぼ消える。
実測で効果を感じた3つの場面
メモリ参照の平均レイテンシは、Dreaming導入前312msだったものが導入後197msに低下した。重複統合の効果が数値として明確に出た格好だ。
エージェント間の知見共有も改善した。複数エージェントがバラバラに発見した「ライブラリAは特定条件でデッドロックする」という知見が、Dreamingを介して共通memoryへ昇格した。これはMulti-Agent Orchestrationと組み合わせると相乗効果がある。
3つ目は古い前提の自動廃棄だ。プロジェクト初期に書かれた「フレームワークXのv2を使う」というメモリが、v3移行後もしぶとく残っていた。Dreamingが3回目の実行で除去してくれた結果、類似ハルシネーションが目に見えて減った。
万能ではない、3つの限界
Dreamingはmemory storeとセッション履歴しか参照しないため、外部ドキュメントの更新には追随しない。RAGで補完する設計は依然として必要だ。
Harveyが公表している6倍という派手な数字は、専門領域（法務AI）での話である点も押さえておきたい。汎用的なコーディング支援エージェントでは、筆者の体感で1.4〜1.7倍くらいの効率改善というのが実測の感触だ。過小評価でも過大評価でもない、現実的な数字として共有しておく。
もう一点、Dreamingは「セッション履歴の信頼性」を前提にしている。エージェントが間違った推論を何度も書き残していると、その間違いがパターンとして昇格してしまうリスクがある。筆者は最初の1週間、Outcomes機能（セッションごとに成功/失敗を採点する仕組み）を併用しなかった結果、誤った最適化パターンが共通memoryに混入した。Outcomesを併用してから、この種の混入は消えた。
今回の推奨アクション
- 既に運用中のエージェントは、まず
dreaming-2026-04-21betaを有効化し、既存memory storeに対してdry-run的に1回走らせる - 差分を確認し、自分のエージェントがどれだけ「古い前提」を抱えているか可視化する
- チーム共有のエージェントでは、自動モードではなくレビュー後反映モードを選ぶ
- Outcomes機能を併用して、セッション履歴の品質を担保する
新規にエージェントを設計する人は、最初からDreaming前提でmemoryスキーマを設計したほうがいい。とくに粒度は重要で、1メモリ=1事実に近い形にしておくと統合・廃棄の判断がクリーンになる。粗いメモリを後から細分化するのは骨が折れる作業だ。
※本記事の検証は筆者個人のテスト環境（Managed Agents、Claude Sonnet 4.5、メモリ127件・セッション42件規模）で実施したもの。Dreamingの効果は運用規模・領域・エージェント設計により大きく変動するため、自社環境での再検証を推奨する。
