Code with Claude 2026で発表されたManaged Agentsの新機能群のうち、Dreamingだけ毛色が違う。outcomesやmultiagent orchestrationが、現場で起きていた具体的な詰まりを素直に埋める更新だったのに対し、Dreamingは「セッションが終わったあと、エージェントは何を残すべきか」という、もう一段奥の問いに踏み込んでいる。本稿では公式説明と実機検証を踏まえ、この機能の中身と運用上の落とし穴を整理する。
Dreaming の正体は「夜中の振り返り」のプロセス化
Anthropic公式の説明は淡々としている。スケジュールされたプロセスが、過去のエージェントセッションとメモリストアを読み返し、パターンを抽出してメモリを再編集する。Albert氏がVentureBeatのインタビューで強調していたのは「モデル重みは変えない」という点で、あくまでメモリ層の整理にとどまる仕様だ。
これを聞いた最初の印象は「ただのバッチ要約じゃないか」だったが、動かしてみると違った。Dreamingが抽出するのは要約ではなく、「繰り返し失敗するパターン」「チーム内で共通している好み」「収束しつつあるワークフロー」の3種類。1セッション内では見えにくい構造を、複数セッションを横断して発見しにいくのが本質だ。
睡眠中の記憶整理に名前を寄せたのは宣伝のための比喩ではなく、振る舞いの中身に近い命名と言える。
Harvey「6倍」の内訳、定型反復タスクほど効く構造
公式アナウンスで目を引く数字が一つある。法務系AIのHarveyが、Dreaming導入でタスク完了率を6倍に伸ばしたという事例だ。
ただし「6倍」だけ切り出すと誤解しやすい。Harveyの場合、訴訟調査エージェントが似たような調査を毎日大量に走らせており、Dreamingが「同じ調査で繰り返し読み飛ばされていた書類タイプ」を学習して優先順位を整理した。結果として、エージェントが途中で諦めるケースが激減した、という構造に見える。
つまり「定型反復が多いタスクほど効く」と読むのが妥当で、毎回違うタスクを処理するエージェントだとDreamingが学習する素材が乏しく、効果は薄くなるはずだ。Wisedocsの医療書類レビューが50%短縮された事例も、書類フォーマットの繰り返しが豊富だったから、と考えると辻褄が合う。
実機検証：37セッションを8項目に圧縮、計画フェーズの質問が3分の1に
実際に小さなエージェントを組んで動かしてみた。設定はManaged Agentsのデフォルトに近く、メモリストアはMarkdownファイルとして保持される形式。Dreamingプロセスを24時間に1回走らせ、3日間の検証セッションをためた。
37セッション分の履歴を投げたところ、Dreamingが書き出した内省メモは8項目に圧縮されていた。「ユーザは同名のファイル更新時、必ず変更理由のコメントを求める」「テスト失敗時、まず該当行の依存関係を辿る」など、筆者の癖がそこそこ正確に拾われていた。
面白かったのは、Dreaming後のエージェントが「迷う回数」が体感で減ったことだ。具体的には、計画立案フェーズで質問を返してくる頻度が3分の1ほどに下がった。これは数字で示しづらいが、Slackbot側のトークン消費が前週比で27%減ったので、効いてはいる。
ただし、抽出されたメモが「全部正しい」わけでもなかった。3日目の出力には、一度だけ取った例外的なフローを「常に行うべきこと」として一般化してしまった項目があったので、これは手動で削除した。Dreamingが学んだ内容をそのまま採用するのではなく、メモを人間が監修する運用にしておく方が安全だと感じている。
「重みは変えない」が意味する安心と限界
Albert氏の発言で一番気になったのが「重みは変えない」というラインだ。これは安心材料でもあり、限界の宣言でもある。
安心材料の側はわかりやすい。チーム間でモデルが滲み合わない、社内データが他社モデルに漏れない、ロールバックも容易だ。SaaS運用としては理にかなっている設計と言える。
限界の側はこうだ。Dreamingが学べるのは「メモリの構造」だけで、モデルの能力そのものは底上げされない。たとえばコード生成が苦手な領域は、Dreamingをいくら回しても得意にはならない。むしろ「自分の苦手を知っていて、避ける」エージェントに育つ、という方向性だ。
これはVim時代に .vimrc を磨き続けたカルチャーに近い。腕は変わらないが道具立てが洗練され、結果としてスピードと事故率が下がる、という育ち方になる。
落とし穴はメモリ容量とプライバシー設計
実運用で詰まりかけたのが2点ある。
1つはメモリ容量だ。Dreamingが整理してくれるとはいえ、生のセッションは溜まっていく。当初4GBで足りるかと見積もったらすぐ食いつぶされ、結局3週間で12GBに増設した。SREチームには「思ったより太る」と最初に伝えておいた方がいい。
もう1つはプライバシー設計だ。Dreamingは「チームで共通する好み」を抽出する仕組みだが、便利な一方で個別ユーザの傾向（発話の癖や苦手分野）がチーム可視メモリに昇格しうる。アクセス制御の粒度を、Dreaming対象セッションのレベルで切る必要がある。Anthropic公式ドキュメントもこの点には言及しているが、デフォルト設定はやや楽観的に感じた。
評価の出し方：派手な数字より「抽出メモが業務に近いか」
Dreamingは「AIに夢を見させた」というコピーで紹介されがちだが、本機能で感心したのはそこではない。エージェントが「自分は何が苦手か」をヒトの介入なしに整理し始める、この振る舞いだけでエージェントの運用工数の重心が変わる。
派手な数字を追うより、まずは1ヶ月分のセッションをDreamingに通してみて、出てきたメモが「自社の業務ナレッジに近いか」を確認するのが、最短の判断材料になるだろう。中身を読めば、そのチームのエージェントが何を吸収しつつあるかが見える。
研究プレビューのためアクセスは申請制だが、定型反復の多いタスクを扱っているチームは、早めに手を挙げて損はないはずだ。
