AIエージェントに複数のセッションにまたがる長期タスクを任せるには、過去の作業内容をどのように記憶し、維持するかという課題がある。新たに得た知識を反映するたびにモデルをファインチューニングする方法は、計算コストが大きいうえ、既存の知識が失われる「破壊的忘却」の問題も伴う。一方、過去の会話や作業ログをそのままプロンプトに詰め込む方法にも、コンテキストウィンドウの容量や、長大な文脈から必要な情報を正確に取り出せなくなるという限界がある。
Anthropicが2026年11月6日に公開した研究報告「The components of agent memory」は、この問題に対する一つの解決策として、セッション外で推論を実行し、過去のログから記憶を整理・修正する「ドリーミング（Dreaming）」という仕組みを紹介している。人間の脳が睡眠中に経験を整理し、長期記憶として定着させる過程になぞらえた設計だが、単に会話履歴を保存する従来の方法とは何が異なるのか。また、実際の業務に導入するだけの効果はあるのだろうか。同社が公開した実験結果をもとに、AIエージェントの長期記憶を設計するうえでの重要な知見と、実用化に向けた課題を検証する。
セッション記録を整理する「オフライン推論」の仕組み
AIエージェントの記憶を考えるうえでは、まず何を「記憶」と呼ぶのかを明確にする必要がある。Anthropicはエージェント記憶を、ユーザーとの対話やタスクの実行を通じて得た知識のうち、将来のセッションでも参照できる形で保存された情報と定義している。この定義には、学習によるモデルのパラメータ更新は含まれない。また、一つの会話の中で新たな情報を理解するコンテキスト内学習や、コンテキストウィンドウの容量を確保するために過去のやり取りを要約する「コンパクション（Compaction）」とも区別される。
Anthropicが提示したアーキテクチャでは、記憶の管理を、タスクの実行中に情報を保存する「セッション中の記録」と、セッション終了後に過去の記録を整理する「ドリーミング」に分けている。前者は重要な情報をその場で残す仕組みであり、後者は複数のセッションで蓄積された情報を振り返り、将来使いやすい形に整える役割を担う。ドリーミングの主な用途は、誤ったノートの修正、Wikiなどの知識体系の構築、重要な情報の上位コンテキストへの移動、特定の目的に合わせた記憶の整理、そしてセッション間で生じた参照リンクの欠落修復という5つだ。
この設計は、人間の睡眠中に起こる記憶の整理・定着を参考にしている。ただし、Claudeが人間と同じ記憶の仕組みを獲得したという意味ではない。実際には、過去のセッションログ（トランスクリプト）を読み込み、推論モデルとファイル操作ツールを使ってMarkdown形式のノートなどを更新する処理である。重要なのは、人間の睡眠を再現することではなく、タスク実行時とは別の計算資源と時間を使って、記憶の品質を改善できる点にある。
セッション外の計算を記憶の整理に利用するという発想自体は、Anthropicが初めて提案したものではない。Lettaとカリフォルニア大学バークレー校の研究者らは、2025年4月17日に公開した論文「Sleep-time Compute: Beyond Inference Scaling at Test-time」で、次の質問が届くまでの待機時間を利用し、事前に推論を進める手法を検証している。この研究では、将来の質問をある程度予測できるほど、事前計算の効果が高くなることも確認された。Anthropicの今回の研究は、こうしたオフライン推論の考え方を、エージェントが長期間使用する記憶ファイルの管理に応用したものと位置付けられる。
メモを取りすぎるモデルと、必要な情報だけを残すモデル
タスクの実行中に何を記憶すべきか判断する能力は、モデルの世代によって大きく異なる。Anthropicは、2026年5月に公開された継続学習ベンチマーク「Continual Learning Bench（CL-Bench）1.0」のデータベース検索課題を使い、Claudeが過去の失敗から学習し、次のセッションに生かせるかを調べた。この実験では、設問ごとに新しいセッションを開始する一方、記憶ディレクトリに保存されたファイルだけは次のセッションへ引き継げるようにした。回答後には採点者から正解が提示されるため、エージェントは間違いの原因を分析し、次回に向けたメモを残すことができる。
実験では、モデルによって記憶の使い方が段階的に進化している様子が確認された。Claude Sonnet 4.6は、誤答の原因について仮説を立てることはできたものの、検証されていない推測を複数のファイルに書き残す段階にとどまった。Claude Opus 4.7になると、メモを単一の参照文書に集約し、検証済みの事実と未確認の推測を区別するようになった。Claude Sonnet 5は、採点者から正解を確認した情報を記録し、誤答した場合には修正を加えるようになった。
Claude Opus 5では、さらに一歩進んだ記憶の活用が見られた。単に正解を保存するだけでなく、そこから導いた行動規則、その規則が正しいと判断した根拠、過去に遭遇した落とし穴への警告をまとめて記録し、失敗から次の行動を改善する学習サイクルを完成させたのだ。後継のClaude Opus 5.5とClaude Sonnet 5.5も同様の学習サイクルを再現したが、記憶を利用した際の評価スコアはOpus 5とほぼ同水準だった。一方、記憶を使わない状態での基礎性能は向上しており、モデル自体の能力向上と、記憶を活用する能力の改善は必ずしも同じ速度で進むわけではないことが分かる。
より分かりやすい違いが現れたのが、ゲームボーイ用ソフト『ポケットモンスター 赤』をClaudeにプレイさせた実験だ。Anthropicは、Claude Sonnet 3.7とClaude Fable 5について、それぞれ1回のプレイが約10,000ステップに達した時点の記憶フォルダを比較した。両モデルにはゲーム中に読み書きできる記憶フォルダが与えられていたが、何を記録するかという判断は大きく異なっていた。
- 記憶ファイル総数
- 獲得バッジ数
データを表で見る
| 記憶ファイル総数 (件 / 個) | 獲得バッジ数 (件 / 個) | |
|---|---|---|
| Sonnet 3.7 | 413 | 1 |
| Fable 5 | 10 | 4 |
Claude Sonnet 3.7は、戦闘やアイテムの入手、登場人物との会話など、遭遇した出来事を細かく保存しようとした。その結果、225のフォルダに413件もの記憶ファイルを作成したものの、獲得したバッジは1個にとどまった。ゲームの進行に伴って状況が変わるため、詳細に記録した情報もすぐに古くなり、メモの管理そのものが負担になっていた。実際、約10,000ステップに達した頃には、わずか17ステップの間に6件のファイルを作成し、9件を削除したにもかかわらず、ゲーム内の操作は一度も行っていなかった。
対照的にClaude Fable 5は、2つのフォルダ内に9件のファイルを作成し、さらに全体の進捗を管理するglobal.mdを1件配置しただけで、4個のバッジを獲得した。所持金や現在位置など、ゲーム画面から確認できる情報は記録せず、自分で見つけた攻略法や行動規則を優先して保存していた。例えば、モンスターボールによる捕獲に7回連続で失敗した際には、操作のタイミングを変えることで成功した経験から、同様の失敗が3回以上続いた場合は操作間隔を変えるという規則を作成した。Anthropicによれば、Claude Opus 5.5も少数のメモを必要に応じて書き換える方法を採用し、最終的にゲームをクリアしたという。
この比較からは、記憶容量を増やすこと以上に、将来も役立つ情報を選び、不要になった情報を捨てる判断が重要になっていることが読み取れる。過去の出来事を網羅的に残すよりも、そこから得られた知見を簡潔な規則として保存する方が、長期タスクでは効率的に働く場合がある。ただし、ポケモンの実験は各モデル1回ずつの観察であり、記憶の整理方法だけが成績の差を生んだとは断定できない。ゲーム以外の業務でも同様の効果が得られるかは、別途検証する必要がある。
Anthropicの実験を踏まえると、記憶の管理方法はタスクの性質に応じて使い分けるのが合理的だ。単発の問い合わせでは既存文書を検索するだけで十分な場合が多いが、過去の経験から判断規則を学ぶ作業ではセッション中のノートが役立つ。さらに、複数の文書やセッションから知識を整理する必要がある場合には、ドリーミングを利用したWikiの構築が選択肢となる。
| アーキテクチャ | 適したワークロード | Anthropicの検証結果 | 主なコスト・リスク | 導入方法と管理上の要点 |
|---|---|---|---|---|
| トランスクリプト検索 | 単一文書の参照、定型・単発の問い合わせ | 単一文書で完結する課題ではWikiによる明確な改善が見られなかった | 検索ごとの計算コストと応答時間 | 既存のRAG基盤を活用できる |
| セッション中のノート作成 | 直近の決定事項、作業進捗、経験から得た規則の引き継ぎ | Fable 5やOpus 5では、重要な情報を選んで保存する能力が向上 | メモ作成による作業中断、過剰な記録、情報の陳腐化 | セッション間で共有する記憶ディレクトリを利用 |
| ドリーミング＋知識Wiki | 複数文書を横断する調査、計算や判断を伴う反復作業 | 複合調査課題で採点基準の達成率が検索単体の73%から87%へ向上 | オフライン推論の追加費用、誤情報の固定化、Wikiの肥大化 | Managed Agentsの研究プレビューなどを利用し、生成結果を検証して反映 |
知識Wikiは横断検索の代わりになるのか
ドリーミングの具体的な用途としてAnthropicが紹介しているのが、過去の記録をもとにした知識Wikiの自動構築と、誤った記憶の修正である。セッション中に作成されたメモは、必ずしも正しいとは限らない。エージェントが状況を誤解したまま保存した情報や、環境の変化によって古くなった情報が、その後のセッションで繰り返し参照される可能性がある。ドリーミングでは、こうした記録を元のセッションログと照合し、誤りや矛盾を見つけて修正することを目指している。
具体例として挙げられたのが、『ポケットモンスター 赤』に登場するダンジョン「おつきみやま」での失敗だ。Claudeは洞窟の入り口付近にあるポケモンセンターの位置を誤って記録し、すでに洞窟を抜けたと思い込んでいた。その結果、一方通行の段差から何度も飛び降り、以前通った道に戻されるという失敗を繰り返した。移動ツールでは段差の存在を十分に把握できなかったこともあり、誤った記憶を修正できないまま、次の町へ到達できずに終わった。
そこでAnthropicは、誤った位置情報が残る記憶フォルダに対してドリーミングを実行した。Claudeは過去のセッションログとメモを照合し、ポケモンセンターの位置に関する記述が間違っていることを発見して修正した。その後の実行では、修正された記憶を参照して洞窟へ戻り、次の町であるハナダシティまで到達できたという。ただし、これは特定の誤りを修正できた事例であり、ドリーミングによってあらゆる誤認や情報の陳腐化を検出できることが証明されたわけではない。元のログ自体に誤った解釈が含まれていれば、その情報を正しい事実として再び記憶してしまう可能性も残る。
より実務に近い検証として、Anthropicは2026年5月18日に買収を発表したStainlessの社内文書を使用した。対象は約35万件、合計約4億2,000万トークンに相当する大規模な文書群である。研究チームは、この文書群に関する25問の評価セットを作成し、Claude Opus 5のエージェントに検索ツールを与えたうえで、ドリーミングによるWikiの構築を指示した。エージェントは複数のセッションを通じて文書を調査し、関連ページの追加、重複の統合、誤った記述の修正、元資料との照合を繰り返した。
データを表で見る
| 採点基準の達成率 (%) | |
|---|---|
| 2セッション | 13 |
| 128セッション | 48 |
Wikiの構築に使うセッション数を2回から128回へ増やすと、Wikiだけを参照した場合の採点基準の達成率は13%から48%へ上昇した。さらに、検索ツールとWikiを併用した構成では、Wikiの充実に伴って達成率が54%から61%へ改善し、検索ツールだけを使用した場合の53%を上回った。この結果は、Wikiが検索を完全に置き換えるものではなく、検索と組み合わせることで効果を発揮することを示唆している。
また、Wikiと検索を併用した場合、検索単体と比べて設問あたり約20,000トークンの消費を削減できたと報告されている。ただし、この数値は質問への回答時に発生するトークン消費の比較であり、Wikiを構築するために実行した128セッション分のオフライン推論コストは含まれていない。したがって、回答時の効率が改善したとしても、システム全体の計算費用が削減できたとは限らない。長期的な費用対効果を判断するには、Wikiの構築・更新に必要なコストを含めて評価する必要がある。
Wikiの効果が特に顕著だったのは、複数の資料から情報を集め、計算や判断を加える必要がある複雑な調査課題だった。Anthropicは、企業の合併に関する文書群を使った24問の調査課題と、法務分野のベンチマーク「Harvey LAB」を用いて、Wikiの有用性を詳しく調べている。
データを表で見る
| 採点基準の達成率 (%) | |
|---|---|
| 検索ツール単体 | 73 |
| 検索＋Wiki併用 | 87 |
企業の合併に関する24問の調査課題では、採点基準の達成率が検索単体の73%から、検索とWikiを組み合わせた場合の87%へ向上した。設問の半数以上では複数の文書から情報を集める必要があり、計算や判断を伴う問題も含まれていた。一方、Harvey LABの別の課題では、必要な情報の多くが単一の文書から検索できたため、Wikiを利用しても検索単体に対する明確な改善は見られなかった。つまり、Wikiの価値は文書の量そのものよりも、情報同士の関係を整理し、複数の資料を結び付ける必要があるかどうかに左右されると考えられる。
Wikiを作れば必ず効率が上がるわけでもない。別のHarvey LABの課題では、元の文書群が合計115KBだったのに対し、Claudeが生成したWikiは68ページ、203KBに膨らみ、元資料の約1.77倍に達した。情報を整理するはずのWikiが、かえって原文より巨大になってしまったのである。Anthropicはこの状態を、アルゼンチンの作家ホルヘ・ルイス・ボルヘスの短編『学問の厳密さについて』に登場する、帝国と同じ大きさの地図になぞらえている。元の資料をほとんど圧縮できないのであれば、Wikiを作成する意義は乏しい。
複数のエージェントがWikiを共同編集する場合には、別の問題も見つかった。契約書の内容を整理する課題で、初期設定では複数のエージェントが同じ共有テーブルへ書き込んでいたため、互いの変更が上書きされ、必要な57件の事実のうち41件（72%）しか最終的な文書に反映されなかった。そこでClaudeに失敗の原因を分析させ、Wikiの構築手順を改善する試行を繰り返した結果、契約書ごとに独立したページを作成し、重要な条項を要約せず原文のまま記録する方法にたどり着いた。この変更によって、57件すべての事実を反映できるようになり、採点基準の達成率は100%に達した。
この結果は、記憶をどのように構造化し、エージェント間で編集作業を分担するかが、最終的な回答品質に直結することを示している。特に、契約条項のように原文の正確な保存が重要な情報では、安易な要約よりも、元資料への参照を維持する設計が有効だった。一方、複数文書の関係を把握する必要がある場合には、リンクで結ばれたWikiが役立つ。単一の記憶管理方法ですべての課題に対応しようとするのではなく、情報の性質に合わせて保存形式や編集方法を選ぶ必要がある。
これらの実験を総合すると、頻繁に参照する文書群を複数のセッションにわたって調査する業務では、Wikiを構築するための事前投資を回収できる可能性がある。例えば、長期間継続する法務調査や、複数の資料に分散した情報を繰り返し分析する作業などが候補となるだろう。反対に、毎回異なる資料を扱う単発の業務や、全文検索だけで回答できる問い合わせでは、ドリーミングの追加コストに見合う効果は得にくいと考えられる。
不正データと誤認が引き起こす運用上のリスク
記憶を外部ファイルとして保存し、エージェント自身に更新させる仕組みには、セキュリティと信頼性の両面で課題がある。特に注意すべきなのは、一度保存された誤った情報が後続のセッションでも参照され、正しい知識として扱われ続けることだ。例えば、エージェントが誤った操作手順を記憶し、それを次のセッションで正しい規則として利用すれば、同じ失敗を繰り返す可能性がある。ドリーミングはこうした誤りを修正する手段になる一方、誤った情報を新しいWikiへ引き継いでしまう危険もある。
記憶をいつ更新するかという問題も残る。作業中にメモを取れば、その時点で重要な情報を保存できるが、記録のために本来のタスクが中断される。一方、ドリーミングに記憶の整理を任せれば、タスク実行時の負担を減らせるものの、次のバッチ処理が完了するまで情報が更新されない。Anthropic自身も、すべての記憶を継続的に検証し直す方法は、計算コストの面から現実的ではないと認めている。そのため、頻繁に変更される情報を優先して検証したり、参照頻度に応じてドリーミングの実行間隔を調整したりする運用が必要になる。
もう一つの重要な問題が、記憶の一部をセッション開始時のコンテキストへ自動的に読み込む仕組みである。重要な情報をあらかじめ読み込んでおけば、エージェントは毎回検索することなく過去の知識を利用できる。しかし、読み込む情報が増えるほどコンテキストウィンドウを消費し、誤った記述が含まれていれば、その後の判断にも悪影響を及ぼす。さらに、Claude Codeのドキュメントでは、指示ファイルが長くなるほどモデルが指示に従う精度が低下することも指摘されている。
こうした問題への対策として、Claude Codeの自動メモリ機能では、MEMORY.mdから各セッションへ自動的に読み込む情報を、先頭200行または25KBまでに制限している。このファイルには重要事項や個別ノートへの案内を記録し、詳細な情報は必要になったときだけ読み込む階層構造を採用している。すべての知識を毎回コンテキストへ詰め込むのではなく、最初に読み込む情報を小さく保ち、必要な情報へたどり着けるようにしている点が重要だ。
セキュリティ面では、外部から持ち込まれた不正な情報が長期記憶に入り込む危険もある。エージェントが悪意あるWebサイトや第三者の提供した文書を読み込み、そこに含まれる指示を誤って自分の記憶に保存した場合、その内容が後続のセッションへ引き継がれる可能性がある。これはプロンプトインジェクションが一度のやり取りで終わらず、記憶ファイルを通じて継続的に影響を及ぼすという問題だ。特に、記憶の内容をシステムプロンプトに組み込む構成では、不正な指示がエージェントの動作を長期間にわたって誘導する恐れがある。
Anthropicの公式クックブック「Dreaming with a dynamic workflow」も、この問題について注意を促している。推奨されているのは、自分たちが管理するエージェントのログを優先的に使い、通常のタスクを実行するエージェントには記憶ストアを読み取り専用（read-only）で接続する構成だ。記憶の更新権限はドリーミングを実行するセッションに限定し、不必要なシェル操作やネットワークアクセスも与えないことで、悪意ある入力が引き起こす被害の範囲を抑える。一般のタスクを実行するエージェントと、長期記憶を編集するエージェントの権限を分離することが重要になる。
ただし、クックブックに示された夜間バッチ処理のサンプルには、生成された記憶を人間が確認せず、既存のストアへ直接反映する構成も含まれている。そのまま運用すれば、夜間に誤った情報が書き込まれ、翌朝の業務で参照される可能性がある。実運用では、更新後の記憶を検査する手順や、異常を検知した際に以前の状態へ戻せる仕組みが必要だ。
Managed Agentsのメモリ管理APIには、記憶の変更履歴を追跡するバージョン管理機能がある。変更履歴は原則30日間保持され、古いバージョンを取得して内容を書き戻すことでロールバックできる。ただし、専用の復元エンドポイントがあるわけではなく、30日を超えた履歴は削除される可能性もある。長期的な監査が必要な場合には、バージョン履歴を別途保存し、問題発生時に復旧できる体制を整えておく必要がある。
試験導入における段階的な検証手順
現時点で、AnthropicのManaged Agentsはベータ版として公開されており、ドリーミング機能を利用するDreams APIは、利用申請が必要な研究プレビュー（Research Preview）の段階にある。したがって、一般の商用環境ですぐに利用できる完成済みの機能と考えるべきではない。ただし、公式ドキュメントでは具体的なAPIの仕様や処理手順が示されており、試験導入に向けた技術的な検討は可能になっている。
Dreams APIが対応するモデルは、Claude Fable 5.1、Fable 5、Opus 5.5、Opus 5、Sonnet 5.5、Sonnet 5、Opus 4.8、Opus 4.7、Sonnet 4.6である。Dreamsのエンドポイントには専用のベータヘッダーdreaming-2026-04-21が必要で、Managed Agentsのセッション操作ではmanaged-agents-2026-04-01が使用される。ドリーミングの処理は非同期ジョブとして実行され、入力するログの量に応じて数分から数時間かかる場合がある。
重要なのは、Dreams APIが既定では入力された記憶ストアを変更せず、整理後の内容を別のストアへ出力する設計になっている点だ。なお、APIリファレンスには、output_behaviorをupdate_existingに設定して既存ストアを直接更新するオプションも記載されている。このため、記憶の更新方法は利用する設定によって異なる。
別ストアに出力する構成であれば、更新前の記憶を残したまま、ドリーミングによって生成された内容を検証できる。新しい記憶を直ちに本番環境へ反映するのではなく、管理者による確認や自動テストを実施し、問題がないことを確かめてから利用を開始する運用が可能だ。これはソフトウェア開発におけるステージング環境に近い考え方であり、記憶の誤更新が本番業務へ波及するリスクを抑えられる。
費用面では、Dreams APIの処理に選択したモデルの標準APIトークン料金が適用される。Anthropicによると、入力するセッションログの件数と長さに応じて、費用はおおむね線形に増加する。したがって、ドリーミングの実行頻度を増やせば記憶の更新遅延は短縮できる可能性があるものの、その分だけ推論コストが増える。Wikiの構築によって回答時のトークン消費が減ったとしても、オフライン推論の費用を加えた総コストで評価しなければ、実際の経済性は判断できない。
企業がエージェント記憶の導入を検討する場合、最初からドリーミングによる自動更新を採用する必要はない。まずは既存の検索基盤を用いた単純なRAG（検索拡張生成）を比較の基準とし、次にセッション中にノートを保存する構成を評価する。そのうえで、Wikiの自動構築やドリーミングによる記憶の更新を追加し、回答品質、トークン消費量、応答時間、運用負荷がどの程度変化するかを測定するのが合理的だ。
評価では、最終的な回答の正確性だけでなく、記憶の更新によって誤情報が増えていないか、必要な事実が失われていないかも確認する必要がある。特に、複数のエージェントが同じ記憶を利用する場合には、編集時の競合や情報の欠落が発生しない設計が欠かせない。また、保存された記憶が古くなった際に、元資料へ戻って確認できる仕組みや、誤った更新を取り消せる手順も重要になる。Anthropicの実験では記憶の整理による性能向上が確認された一方、こうした運用上の問題を完全に解決できたわけではない。
今回の研究が示したのは、AIエージェントの長期記憶では、保存できる情報量以上に、何を残し、どのように整理し、いつ更新するかが重要になるということだ。ドリーミングは、過去の作業から得られた知識をセッション外で整理し、次のタスクへ引き継ぐ有力な方法となり得る。ただし、その効果は作業内容によって異なり、計算コストや誤情報の継承という課題も残る。今後は、記憶を自律的に更新する能力だけでなく、生成された知識の正確性を検証し、安全に運用できる仕組みを確立できるかが、実用化の鍵となる。
