ClaudeのDreamsがエージェントのメモリ・ストアを再構築、オリジナルには一切手を加えない（2026年）

2つの入力、1つの新しい出力

Dreamとは、正確に2種類の入力を受け取る「非同期ジョブ」です。その入力とは、「既存のメモリ・ストア（Claudeが検証、重複排除、再構成を行うストア）」と、「1〜100件のセッション（Claudeがパターンやインサイトを抽出して出力に組み込むための、過去の対話履歴）」です。

生成されるものは、同様に極めて正確に説明されています。「新しく再構成されたメモリ・ストア：重複がマージされ、古いエントリや矛盾するエントリが最新の値に置き換えられ、新しいインサイトが浮き彫りにされたもの」です。

3番目の項目に注目してください。重複のマージや古いエントリの置換は「クリーンアップ」です。一方、対話履歴から新しいインサイトを浮き彫りにすることは、それとは異なります。ストアがこれまでキャプチャしていなかったセッションを読み込み、そこから示唆される内容を書き留めるのです。対話履歴はあるがストアがまだない場合、ドキュメントには回避策が示されています。「最初に空のメモリ・ストアを作成し、それを memory_store 入力として渡します。」

入力は決して変更されない

これこそが、この機能を安心して使えるようにしている設計上の選択です。

「入力ストアが変更されることは決してないため、出力を確認し、結果が気に入らなければ破棄することができます。」

後に、さらに強い表現で再確認されています。「Dream自体がその入力を削除または変更することはありません。」そして、これは失敗時にも適用されます。failed（失敗）または canceled（キャンセル）となったDreamにおいて、「出力メモリ・ストアは、失敗前に書き込まれた内容のまま残されます。」また、「出力ストアは部分的なコンテンツを保持したまま存続するため、停止前に何が生成されたかを検査できます。」

つまり、不適切なDreamによる失敗モードは「ストアを削除する」ことであり、「ストアを再構築しなければならない」ことではありません。

方向付けはするが、エディタではない

最大4,096文字に制限されたオプションの instructions フィールドは、「Dreamingパイプラインが何を合成するかを方向付けます。これはパイプライン全体に適用され、何を注意深く読み取るか、何をマージまたはドロップするか、そして出力ストアをどのように構造化するかを決定します。」Anthropic自身の例としては、以下のようなフォーカス表明があります。「コーディングスタイルの好みに焦点を当て、単発のデバッグノートは無視してください。」

そして、無駄な実行を防ぐための警告が続きます。

「このパイプラインは入力に対する合成パスであり、ストアのテキストに適用されるエディタではありません。そのため、特定の行をターゲットにした命令的な指示（「文XをYに変更する」、「セクションZのカウントを修正する」など）は、通常、変更を生み出しません。」

ピンポイントな変更については、ドキュメントは別の方法を案内しています。「出力ストアに対して直接 Memory Stores API を使用してください。」Dreamsはストアの全体像を整えるためのものであり、行単位の編集のためのものではありません。

時間はかかるが、監視は可能

「Dreamsは非同期で実行され、入力される対話履歴の数に応じて、通常は数分から数時間かかります。」ライフサイクルは、pending（保留中）、running（実行中）、そして completed（完了）、failed（失敗）、canceled（キャンセル）のいずれかになります。

知っておく価値のある、運用上の小さな詳細があります。「出力ストアのIDは、ワークフローが入力ストアを複製した後、Dreamが running になってから間もなく、Dreamの outputs[] に表示されます。実行中のDreamは、一時的に空の outputs[] を報告することがあります。」初期段階での空の配列はエラーではありません。

そして、その作業を観察することができます。実行中のDreamの session_id は「パイプラインを実行している基礎となるセッションを指して」おり、そのイベントをストリーミングして「Dreamがリアルタイムで何を読み書きしているかを観察する」ことができます。そのセッションは「Dreamが終端状態に達したときにアーカイブ（削除ではない）されるため、その後も対話履歴を利用できます。」

完了後の2つの道

Dreamが完了すると、その出力は「ワークスペース内の通常のメモリ・ストア」になります。そこから、ドキュメント化された2つのパスがあります。活用する：「入力メモリ・ストアの代わりに（または並行して）、将来のセッションに memory_store リソースとしてアタッチする。」破棄する：ストアを削除またはアーカイブする。

この一文において、「並行して（alongside）」は静かながら重要な選択肢です。整理されたストアとオリジナルのストアの二者択一を迫られるわけではありません。

現実の構造的な問題に対処しています。 インクリメンタルな書き込みは矛盾を蓄積させます。これはAnthropicの実装のバグではなく、追記型のストアであれば必然的に起こることです。レビューゲートを設けた定期的な合成パスは合理的な解決策であり、それが動作するストアの仕組みについては Claude's agent memory stores で解説しています。

自動では実行されません。 スケジュール実行やバックグラウンドでのトリガーはありません。Dreamを作成し、モデルを選択し、ステータスをポーリングし、出力を確認し、アタッチするか破棄するかを決定します。これらはすべて明示的な呼び出しです。

2重のゲートがあり、そのゲートは具体的です。 「Dreamingはリサーチプレビュー機能」であり、申請によるアクセス制限があります。また、ヘッダーが重要になります。「Dreamのエンドポイントは dreaming-2026-04-21 ベータヘッダーによって制限されています。managed-agents-2026-04-01 ヘッダー単体ではDreamsへのアクセスは許可されません。」セッションやメモリ・ストアの呼び出しには、後者のみが必要です。

トークン費用が比例して発生します。 「Dreamsは、選択したモデルの標準的なAPIトークンレートで課金されます。」また、「コストは入力セッションの数と長さにほぼ比例してスケールします。」Anthropic自身の推奨は、小さく始めることです。「まずは少数のセッションから始め、キュレーションの品質に満足したらスケールアップしてください。」

実行中に入力を削除することからは保護してくれません。 ドキュメントには次のような警告があります。「実行中に入力メモリ・ストアをアーカイブまたは削除する（あるいは入力セッションを削除する）と、Dreamは input_memory_store_unavailable または input_session_unavailable で失敗します。」入力はDreamに対して読み取り専用ですが、ユーザーによる操作からロックされているわけではありません。

到達する可能性のあるサイズ制限があります。 エラーリストには、input_memory_store_too_large、組織のストア上限に達したときの memory_store_org_limit_exceeded、そして「パイプラインが実行時間予算を超過した」ときの timeout が含まれています。

「Claudeが自動的に自身のメモリを維持するようになった」 Managed Agentsにおいてはそうかもしれませんが、Dreamsを通じてではありません。これは、明示的な入力、モデルの選択、そして最終的な決定を伴って、あなたが呼び出すジョブです。

「間違ったメモリを修正してくれる」 入力が裏付ける内容に基づいて、「古いエントリや矛盾するエントリ」を最新の値に置き換えます。特定の文を変更したい場合は、出力ストアに対する Memory Stores API を使用します。ドキュメントにある通り、行レベルの命令的な指示は「通常、変更を生み出しません」。

「レビューはオプションである」 レビューこそがこの機能の本質です。レビューを行わずにDreamを本番セッションに直接アタッチすることは、この設計を安全にしている唯一の特性、そして入力を保存している最大の理由を捨てることになります。

「セッション数は多ければ多いほど良い」 セッションが増えればコストも時間もかかります。ガイダンスでは、品質に納得した後にスケールアップするよう求めています。コストと実行時間はどちらも対話履歴の量に依存します。

「ChatGPTが行っていることと同じである」 レイヤーもエルゴノミクスも異なります。OpenAIのDreamingは、バックグラウンドでコンシューマー向けのメモリを整理します。AnthropicのDreamsは、開発者がトリガーする合成ジョブであり、レビュー可能なアーティファクトを出力し、ソースを変更することはありません。

「キャンセルすれば元に戻る」 キャンセルは実行を停止するだけで、クリーンアップは行いません。キャンセルされたDreamは、部分的な出力ストアをそのまま残すため、検査または削除する必要があります。Dreamをアーカイブしても「その出力メモリ・ストアには手を加えない」ため、Dream自体に「アーカイブ解除（unarchive）」はありません。

ステップ 1：キュレーションを行う前に、ストアにとって何が「古い」かを定義する

合成パスの質は、与える判断基準の質に左右されます。実行する前に、ストア内のどのカテゴリのエントリの変更を許可し、どれを保持すべきかを書き留めておきます。

instructions フィールドは、その判断を記述する場所であり、高レベルのガイダンスとして最も効果的に機能します。Anthropicの表現を借りれば、「フォーカス領域... 変更せずに保持するコンテンツ、またはストア全体に適用したい出力規則」です。「コーディングの好みについては、最も新しい記述を優先する」というのは適切な粒度です。「セクション3の数値を修正する」は適切ではありません。

ステップ 2：実際に実行するレビュー手順を構築する

入力ストアが保存されるのは、レビューを可能にするためです。事前に「何を比較（diff）するか」と「どのような場合に破棄するか」の2つを決めておくことで、レビューを形骸化させずに実行できるようにします。

有効なデフォルト設定は、出力を既存のストアと置き換えるのではなく、ドキュメントで明示的に許可されているように、一定期間「並行して（alongside）」アタッチし、エージェントの動作が改善されるかを観察することです。記憶されたエントリ間の競合に注意を払う必要があり、この一般的な習慣については detecting conflicts in AI memory で解説しています。

Dreamの実行中にそのセッションのイベントをストリーミングすると、何を読み書きしているかがわかります。どの対話履歴が重視されているかを確認することは、セッションの選択が正しかったかを学ぶ最も早い方法であるため、少なくとも一度は実行する価値があります。

ステップ 3：キュレーションするストアを特定のベンダーのパイプラインから独立させる

ここに構造的なポイントがあります。これはDreamsに対する批判ではありません。仕組みは堅牢であり、レビューゲートは正しい設計です。しかし、それは特定のプラットフォーム上の、リサーチプレビューフラグの背後にある、特定の方法で構築されたエージェントのメモリ・ストアに限定されています。

一方で、最も早く劣化するメモリは、あなたが使用するすべてのツールに分散しているものです。チャットで伝えた好み、コーディングエージェントに与えた修正、別の場所のセッション履歴に記録された決定事項などです。重複や矛盾は、単一のストア内よりも、ツール間でさらに急速に蓄積されますが、単一ベンダーのキュレーションパスではそれらを検知できません。

自身が所有するメモリレイヤーこそが、その統合されたストアが存在すべき場所であり、そこでも同じ習慣が適用されます。読み込み、修正し、剪定し、バージョン履歴を保持するのです。MemoryLake は3つのステップでセットアップできます。

ステップ 1：APIキーを作成する

サインインし、ダッシュボードからAPIキーを生成します。自分自身のストアであれば直接開いて検査できるため、上記のレビュー習慣を理想論ではなく実践的なものにできます。Anthropicのメモリ・ストアはそのままの場所に残り、Anthropic独自のAPIを通じて管理されます。

ステップ 2：最初のメモリをアップロードする

永続的な事実を入力します。決定事項とその理由、ドメイン用語、永続的な好み、複数回行った修正などです。Dreamが合成するであろうものと同じ素材を、使用するすべてのツールからアクセスできる場所に保持します。

ステップ 3：AIとエージェントを接続する

エージェントをストアに向けます。これにより、キュレーションはベンダーのメモリシステムごとではなく、知識そのものに対して一度だけ行うものになります。この利点については syncing AI memory across your tools で詳しく説明しています。

第一の変化は、「エージェントのメモリが時間の経過とともに悪化した」という現象が、漠然とした不満ではなく、診断可能な状態になることです。Anthropicはこれに名前とメカニズムを与えました。すなわち、インクリメンタルな書き込み、重複、矛盾、そして古いエントリです。

第二に、レビューがあらゆるキュレーション機能のデフォルトの期待値になることです。Dreamsは入力を決して変更しないことで、優れた先例を作りました。これは、採用するすべてのメモリ・システムに求めるべき合理的な仕様です。

第三に、スコープ（範囲）に関する問いがより鮮明になることです。プラットフォームごとのキュレーションパスは、そのパスが見える範囲のストアしか助けられません。見えないのは、同じユーザーが他の4つのツールに伝えたすべての内容です。これこそが、auditing what your AI remembers を個別の作業としてではなく、一元的に監査すべき理由です。

• 少数のセッションから始める。 コストと実行時間はどちらも対話履歴の量に比例します。Anthropicは、品質に納得した後にのみスケールアップすることを推奨しています。
• 適切な粒度で instructions を記述する。 フォーカス領域や出力規則は効果的ですが、行レベルの指示は通常、変更を生み出しません。
• 置き換える前に並行してアタッチする。 出力は、入力ストアと置き換えるのではなく、その隣に並行して配置することができます。
• 実行中に入力に手を加えない。 実行中に入力ストアやセッションをアーカイブまたは削除すると、Dreamは即座に失敗します。
• 一時的に outputs[] が空になることを想定する。 入力が複製された後、Dreamの実行開始直後に出力ストアIDが表示されます。
• 正確な編集には Memory Stores API を使用する。 Dreamsは再構成を行い、APIは編集を行います。
• キャンセル後にクリーンアップを行う。 キャンセルまたは失敗したDreamは、意図的に部分的な出力ストアをその場に残します。
• プレビュー期間終了時に再確認する。 Dreamingは独自のベータヘッダーを持つリサーチプレビュー機能であり、プレビューの挙動は変更される可能性があります。

ここで模倣すべき仕組みは、合成そのものではありません。それをめぐる保証です。すなわち、ストアを読み込み、対話履歴を読み込み、新しいストアを書き出し、人間が拒否できるようにオリジナルには一切手を加えないという保証です。

これは、メモリを「間違える可能性のあるもの」として真剣に捉えた設計です。Dreamsへのアクセス権の有無にかかわらず、この習慣は一般化できます。意図的にキュレーションを行い、採用前にレビューし、重要な知識は自分で読み取れる場所に保管することです。