Anthropic が Claude Managed Agents に dreaming を入れてきた。

名前だけ見るとかなり大げさです。AI が夢を見る、というより、過去セッションと memory store をあとから読み直して、重複した記憶をまとめたり、古い記述を新しい内容に置き換えたり、次のタスクに効きそうなパターンを拾う仕組みです。現時点では Research Preview で、Managed Agents 向けの機能。

ただ、これは単なる「メモリ機能が少し賢くなった」話ではないと思っています。

Vibe Coding の次に来る面倒なテーマが、かなりはっきり見えたからです。これからの AI エージェント運用では、プロンプトのうまさよりも「何を覚えさせ、何を忘れさせるか」の設計が効いてくる。

いままでの Vibe Coding は、毎回ほぼ初対面だった

AI コーディングで地味にしんどいのは、同じ説明を何度もすることです。

たとえばフロントエンドのリポジトリなら、だいたいこういうローカルルールがあります。

フォームは vee-validate ではなく react-hook-form に寄せる
API 型は生成物なので直接編集しない
UI コンポーネントは features/** から shared/ui に逆流させない
Tailwind の arbitrary value は原則使わない
Storybook の story を更新しない差分はレビューで止める

人間のメンバーなら、何回かレビューを受けるうちに覚えます。

でも従来の AI エージェントは、セッションが切れるとまた新人に戻る感じがありました。もちろん project instructions や AGENTS.md、rules file でかなり改善できます。それでも、実際のレビューで出た細かい癖までは残りにくい。

結果として、毎回こんなやり取りになる。

このプロジェクトでは shared/ui の props を増やさないでください。
前回も同じ理由で戻しました。
今回は features/billing 側で adapter を作ってください。

この「前回も言った」を、エージェント側が扱える形で積み上げられるか。Dreaming の面白いところはここです。

Dreaming は「反省会」を非同期ジョブにしたもの

Claude の docs を読むと、dream は asynchronous job として動きます。

入力になるのは、既存の memory store と過去セッションの transcript。出力は、新しく整理された memory store です。元の store は直接変更されないので、必要なら人間が差分を確認してから採用できます。

ざっくり言えば、こういう処理です。

past sessions + current memory store
  -> dream job
  -> proposed memory store
  -> review or auto-apply

ここで大事なのは、モデルに「いい感じに覚えておいて」と任せるだけではないことです。

memory は放っておくと汚れます。古い仕様、重複した指示、あとから覆った判断、たまたま一回だけ通した例外。こういうものが混ざると、エージェントは賢くなるどころか、昔の間違いを自信満々に再利用します。

Dreaming はそこを掃除するための仕組みです。なので、自分なら「エージェントを育てる機能」と同時に「memory のゴミ回収機能」として見ると思います。

フロントエンド開発で効くのは、コード生成よりレビュー記憶

この機能がフロントエンドで効くとしたら、たぶん派手なコード生成ではありません。

効くのはレビューの記憶です。

たとえば、AI エージェントに何度も同じコンポーネント修正を頼む場面を考えます。

目的:
- AccountSettings の通知設定 UI を分割する

触ってよい範囲:
- src/features/account/**
- src/shared/form/**

触ってはいけない範囲:
- src/shared/ui/Button.tsx
- generated/api/**

完了条件:
- pnpm lint
- pnpm test AccountSettings
- pnpm storybook:test -- AccountSettings

このタスク自体は、いまのエージェントでもかなりこなせます。

問題はレビュー後です。

Review notes:
- shared/ui/Button に loading prop を追加しようとしたが、このプロジェクトでは feature 側でラップする
- generated/api の型を直接直そうとしたが、schema 更新が必要
- story の更新を忘れたので、UI 変更時は storybook:test を必須にする

こういうレビュー結果を次回の作業に効かせたい。

人間なら「このリポジトリでは shared/ui を触ると怒られる」と覚えます。エージェントにも同じように覚えてほしい。ただし、その記憶はノイズ込みで増えていくので、定期的に整理する必要があります。

Dreaming が実用になるなら、このレビュー記憶のメンテナンスが一番価値を持つはずです。

ただし「育てる」は放置ではない

ここを勘違いすると危ないです。

エージェントが自分で過去を振り返るなら、人間のレビューが減る、という話ではありません。むしろ逆です。レビュー対象がコードだけではなく、memory の差分にも広がる。

自分なら最低限、次の 3 つは見ると思います。

# Agent memory review checklist

1. 古い仕様が残っていないか
   - 廃止した API
   - 変更済みのディレクトリ構成
   - もう使っていないテストコマンド

2. 一回限りの例外を一般ルール化していないか
   - 緊急対応のための skip
   - 特定画面だけの暫定実装
   - レガシー移行中だけ許可した import

3. レビュー指摘が実行可能な形になっているか
   - "品質を上げる" ではなく "story を更新する"
   - "責務を守る" ではなく "shared/ui の public props を増やさない"
   - "安全にやる" ではなく "generated/api を直接編集しない"

memory は設計ドキュメントではありません。

もっと作業寄りの、エージェントが次の一手で使うための圧縮された文脈です。だから抽象的な心得を入れてもあまり効かない。効くのは、レビューで実際に止めた具体的な失敗パターンです。

`AGENTS.md` と Dreaming は役割が違う

ここも切り分けておきたいです。

AGENTS.md や repository instructions は、チームが明示的に決めたルールを書く場所です。

- パッケージマネージャは pnpm を使う
- UI は Radix + Tailwind を使う
- テストは Vitest
- API client は generated 配下を直接編集しない

一方で Dreaming で育つ memory は、運用から出てくる癖を拾う場所に近い。

- このリポジトリでは feature 側 adapter で吸収する判断が多い
- UI 差分では story 更新漏れがレビューでよく止まる
- billing 周りは optimistic update より明示的な refetch を好む

前者は憲法。後者は現場メモ。

この 2 つを混ぜるとつらいです。ルールファイルに細かいレビュー履歴を書きすぎると、人間が読めない。memory に絶対ルールを書きすぎると、いつの間にか古くなる。

Dreaming を本当に使うなら、たぶんこの分離が必要になります。

小さく始めるなら「レビュー指摘だけ」覚えさせる

自分がチームに入れるなら、いきなり全部の作業履歴を対象にはしません。

まずはレビュー指摘だけに絞ります。

# agent-review-notes.md

## 2026-05-11 AccountSettings refactor

Keep:
- feature-local adapter is preferred over changing shared/ui public props
- UI behavior changes must update the relevant story

Discard:
- temporary mock API path used during local debugging
- one-off snapshot update caused by test fixture drift

こういうメモを作業後に残し、dream の対象にする。出てきた memory 差分を人間が見る。

採用する memory は短くていいです。

When changing feature UI, update the matching Storybook story and run the focused story test.
Do not expand shared/ui public props for feature-specific loading or error states; prefer a feature-local wrapper.

これくらいの粒度なら次回の作業で効きます。逆に、長い反省文をそのまま入れてもコンテキストを食うだけです。

エージェント育成は DX というより運用設計

Dreaming という名前は正直ちょっと強すぎると思います。AI が寝ている間に賢くなる、みたいに聞こえるので。

でも、機能として見ればかなり現実的です。

AI エージェントが長い仕事をするほど、memory は汚れる。複数エージェントで作業するほど、同じプロジェクトの解釈がズレる。セッションをまたぐほど、「前回のレビューで何を学んだか」が重要になる。

つまり必要なのは、魔法の自律性ではなく、継続的な memory hygiene です。

フロントエンド開発で言えば、AI にコンポーネントを書かせること自体はもう珍しくない。差が出るのは、そのあとです。

どの失敗を記憶させるか
どの記憶を捨てるか
memory の差分を誰がレビューするか
ルールファイルと運用メモをどう分けるか

このへんを設計できるチームは、エージェントを本当に育てられると思います。

逆に、ここを放置すると「前より賢い AI」ではなく、「古い思い込みを持った AI」ができます。これはかなり嫌です。

まとめ

Anthropic の Dreaming は、AI エージェントを人間っぽくする機能というより、長期運用するための memory maintenance に近いです。

だから開発者側の仕事も変わります。

うまいプロンプトを書く。コードをレビューする。そこまでは今まで通り。これからはさらに、エージェントが何を学習したことにするのかをレビューする必要がある。

AI エージェントを「道具」として使うだけなら、毎回プロンプトを投げればいい。

でも、チームメンバーに近い形で使うなら、育成の仕組みが要ります。Dreaming はその最初のわかりやすい実装に見えます。便利そうだけど、雑に任せると普通に危ない。そこが面白い。

Source notes

Claude Blog: New in Claude Managed Agents: dreaming, outcomes, and multiagent orchestration
Claude API Docs: Dreams
Ars Technica: Anthropic's Claude Managed Agents can now "dream," sort of