エージェントメモリの構成要素

エージェントメモリの構成要素

セーレン・キェルケゴールは、「人生は後ろ向きにしか理解できないが、前向きに生きなければならない」と書きました。AIエージェントのメモリ設計において、私たちは同様のジレンマに直面しています。

人間は、日常生活を送る中で常に記憶をエンコードしています。海馬はこれにおいて中心的な役割を果たし、その瞬間の経験を捉えることで、記憶が迅速に形成され、即座に利用可能になります。しかし、一部の経験だけが長期的な知識へと統合されます。

その統合の多くは、脳がオフラインの時に起こるようです。睡眠中や、静かな休息中に、海馬は最近の経験を再生します。これは、それらの経験を徐々に蒸留し、知識として最もよく考える部分である新皮質に統合すると考えられています。

エージェントメモリも同様の分業を利用できます。エージェントは、その作業の多くをログやトランスクリプトに記録します。LettaとUC Berkeleyの研究者は、モデルが対話の合間のアイドル時間を利用して既存のコンテキストを再編成する方法として、スリープタイムコンピューティングを提案しました。この考え方は、エージェントがログをレビューして間違いを修正したり、新しいノートや表現を生成したりすることで、メモリを整理するのに役立ちます。このプロセスはしばしばドリーミング（図1）と呼ばれます。

私たちは、ドリーミングがClaudeに効果的なメモリを与えるのに役立つツールであることがわかりました。この記事では、エージェントメモリについてどのように考えているかを共有し、ドリーミングの使用を含む、メモリの整理に各構成要素がどのように貢献しているかを探るために使用したいくつかの評価を walkthrough します。

メモリノート

「エージェントメモリ」とは、Claudeがユーザーとの対話や割り当てられたタスクを含む経験から得て、セッション間で保持し、後で読み取れるコンテキストとして保存される知識を指します。これには、モデルが学習したりコンテキストを管理したりする他の方法（重みの変更（トレーニング中に設定される内部パラメータ）、インコンテキスト学習（単一の会話内で得られる知識）、およびコンパクション（Claudeが古いターンを置き換えるために書く要約で、新しいコンテキストウィンドウで作業を続けられるようにするもの）など）は含まれません。

人間の脳では、経験の前、最中、または後に放出される化学信号が、記憶を重要であるとマークすることがあります。マークされた記憶は、オフライン期間中にマークされていない記憶よりも頻繁に再生される傾向があります。このプロセスはリプレイと呼ばれ、長期記憶の安定化と統合を助けます。

同様に、Claudeはセッションログ中の顕著なイベントを発生時にタグ付けして、後で見つけやすくしたり、メモリストア（図2のメモリノートのフォルダなど）に書き込むことができます。しかし、Claudeは何が顕著かを、次に何が来るかを知る前に、どのように判断できるのでしょうか？

メモリは未来が必要とするものについての予測になりうる

メモリは、時として予測です。ルールを書き出すことで、エージェントはその記述しているパターンが再び関連性を持つと予測します。例えば、検証済みの事実を書き出すことは、将来のセッションのエージェントがその事実を再確認せずに頼りたいという予測です。時間をかけて、Claudeはこれらの種類の予測を行うのがはるかに上手になりました。

エージェントのメモリ使用能力を測定するベンチマークであるContinual Learning Bench (CL-Bench) 1.0のタスクを考えてみましょう。特定のタスクでは、Claudeはデータベースを参照して一連の質問に答える必要があります。Claudeが回答した後、正しい解決策が与えられ、将来の質問に答えるのに役立つメモリを書き込むことができます。

メモリはここで学習ループをサポートできます。Claudeが質問を間違えた場合、その失敗を記録し、何が間違っていたかについての仮説を立て、それらの仮説をテストし、将来どのように答えるかについてのルールに変えることができます。

私たちはClaude Managed Agentsを使用してCL-Bench 1.0タスクを実行しました。Claudeは各質問を新しいセッションで開始しましたが、1つの例外がありました。それは、セッション間で永続するメモリディレクトリからファイルを検索できることでした。

異なるモデルが独自の学習ループを作成する上で、さまざまなレベルの成功を達成しました。Claude Sonnet 4.6は、回答が間違っていた理由についての仮説を生成するまで進みました。そのメモリディレクトリには、それぞれいくつかのテストされていない推測をリストしたファイルが散在していました。

Claude Opus 4.7は、ノートを単一の参照ドキュメントに統合し、どの事実をチェックしたか、どれが未確認のままかをマークし始めました。Claude Sonnet 5は、採点者がチェックした後、各回答を確定済みとマークし、間違った回答をした場合に修正を書き込みました。

Claude Opus 5は、これらのモデルの中で最初にループを閉じました。そのエントリのほとんどは、ルール（およびそのルールが真実であるとどのように知ったか）、以前の質問への回答、および途中で発見したトラップに関する明確な警告（図3）を含んでいました。

Opus 5と同様に、Claude Opus 5.5とClaude Sonnet 5.5は両方ともループを閉じ、メモリを使用して将来の質問に最もよく答える方法に関する検証済みのルールをキャプチャしました。メモリを使用した場合、両モデルはOpus 5と同程度のスコアでしたが、メモリなしのベースラインパフォーマンスはわずかに高かっただけです。

Claudeは顕著さを判断することを学んだ

私たちはまた、ClaudeがPokémon Redをプレイする能力を評価しました。このゲームは、Claudeが複雑な長期間タスクをナビゲートすることを要求し、Claudeが何をメモリに保存するかについての判断力をテストします。各実行の開始時に、各モデルに、プレイ中に読み書きできるメモリファイルのフォルダを与えました（図4）。

Claude Sonnet 3.7とClaude Fable 5のそれぞれ約10,000ステップ時点でのメモリフォルダを比較しました。私たちが気づいた主な違いは、各モデルが何を覚えておくべきだと考えたかでした。Sonnet 3.7は、すべてが重要かもしれないと想定し、無差別にメモリに書き込みました。そのメモリフォルダには、遭遇したもののアーカイブが含まれており、しばしば戦った各バトル、見つけた各アイテム、出会った各NPCごとに個別のファイルがありました。最終的に、Sonnet 3.7は225フォルダに413個のメモリファイルを書き込み、1つのバッジを獲得しました（バッジはゲームの進行状況を示します）。

対照的に、Fable 5は2つのフォルダに9つのファイルと、global.mdという単一のトップレベルファイルを作成し、4つのバッジを獲得しました。

Sonnet 3.7のアプローチは、主にゲームの状態が常に変化するため問題でした。Sonnet 3.7の詳細な記録は継続的に時代遅れになっていました。その結果、Claudeが進むにつれて、ゲームをプレイするのではなく、メモリを検索するためにより多くの時間とリソースを費やす必要がありました。例えば、ステップ10,000頃、Sonnet 3.7は「マスター」メモリファイルの4番目のフォルダを開始しました。次の17ステップで、6つのファイルを作成し、9つを削除し、ゲーム自体では何もアクションを起こしませんでした。

Fable 5のアプローチは、ゲームが明示的に伝えない情報にメモリを使用しました。Sonnet 3.7がメモリに書き込んだ情報の種類（プレイヤーの所持金やマップ上のプレイヤーの位置など）は、毎ターン画面から読み取れるため、保存するのは冗長です。対照的に、戦略、計画、テスト済みのルールに関するメモリファイルは、Claudeがそれらを考案した場合にのみ存在し、Claudeが書き留めない限り消滅します。

Fable 5はそのメモリをそれに応じて整理しました。そのglobal.mdファイルはダッシュボードとして機能し、現在の目標、ジム（バッジを獲得するチャレンジ）を攻略するための事前作成された計画、およびモデル自身のメモリ使用ルールを保持していました。locationsフォルダには特定のルートをナビゲートするための計画が、gameplayフォルダにはゲームの仕組みについて学んだことに基づいた戦略が含まれていました。例えば、7回連続でモンスターボールがコイキング（最も捕まえやすいポケモンの一つ）を捕獲できなかった後、Claudeは「3+個のボールが連続で失敗した場合、タイミングを変える（メニュー操作の間に余分な「待機」プレスを挿入する） - この操作の直後に捕獲が成功した」と書きました。

はるかに小さなメモリフォルダで、Fable 5はSonnet 3.7よりもゲームをはるかに進めました。Opus 5.5も同様のアプローチを取りました。現在の目標と次のステップを追跡するメモリノートの小さなフォルダを保持し、プレイ中にそれらを書き直し、ゲームをクリアしました。

Claudeにメモリを書かせるための誘導

Claudeにメモリの目的を伝えることは役立ちますが、どのように使用するかを指示しないことが重要だとわかりました。CL-Benchでは、単にメモリフォルダが利用可能であることをClaudeに伝えました。その一般的なガイダンスは、Opus 4.7とOpus 5がメモリを効果的に使用するのに十分であり、両方のパフォーマンスに顕著な向上をもたらしました（図3）。

また、モデルにメモリに書き込むべき内容に関する特定のルールを与えてテストしました。各テストには1つのルールがありました。各ルールでメモリから得られたパフォーマンスの向上度を、メモリなしで得られたパフォーマンスと比較しました。「失敗のみを記録する」というルールを設定した場合、Opus 5とOpus 4.7の両方で、メモリがもたらしたパフォーマンスの向上は大幅に失われました（図5、右）。より強力なモデルでは、顕著さを判断する自由を与える方が、事前に固定されたルールを設定するよりも効果的であり、それらのルールはパフォーマンスを低下させる可能性がありました。

また、誘導が古いモデルに最も役立ったことも気づきました。例えば、Sonnet 4.6はメモリディレクトリからファイルを読み込まず、回答が間違っていた理由についての仮説をテストすることに失敗することがよくありました。

この場合、Claudeに回答前にメモリファイルを読み込むように促し、その後仮説を明示的にテストするように指示したところ、ベンチマークスコアがほぼ倍増しました（図5、左）。Sonnet 5はこれを自分で行います。促されることなく、10回中9回回答前にメモリを読みました。対照的に、Sonnet 4.6は半分の時間しか行いませんでした。

最先端のClaudeモデルでは、通常、人が要求した場合や、明らかに記憶する価値のあるものがある場合にメモリノートを作成するように簡単なガイダンスを与え、その判断はClaudeに任せています。

ドリーミングはメモリを修正できる

Claudeはセッション中に顕著だと判断したことに基づいてメモリに書き込むため、最初から間違っているノートや、環境の変化とともにずれていくノートは、後続のセッションでClaudeに読み取られ、信頼される可能性があります。

ドリーミングは、Claudeがノートをセッショントランスクリプトと照合してテストする方法を提供します（図6）。これは、ClaudeがManaged Agentsを使用してメモリディレクトリをマウントしてPokémonをプレイしていた際に、肯定的な例として見られました。

ゲームのある部分では、プレイヤーはマップの西側にエントランスがあり、東側にエグジットがある洞窟システムである「月の山」を通過する必要があります。エントランスの近くにはトラップがあります。それは、プレイヤーを元のルートに落とす一方通行の崖で、登る方法がありません。Claudeは山の入り口にある建物である「ポケモンセンター」をランドマークとして使用していたため、ポケモンセンターが山のどちら側にあると考えているかによって、崖から降りるかどうかが決まります。

ある時点で、Claudeは（誤って）ポケモンセンターが東側にあると書き込みました。ポケモンセンターから出ると、「月の山は後ろにある」と宣言し、ノートを更新しました。「月の山完了」。しかし、月の山は後ろにはありませんでした。数アクション後、Claudeは崖を越えて、来たルートに戻ってしまいました（図7）。ナビゲーションツールには落下が表示されなかったため、Claudeは「遠く西にやりすぎた」と結論付け、自分がずっと正しい側にいたと考えました。それは違いました。

次に、ドリーミングがClaudeがこのトラップを回避するのに役立つかどうかをテストしました。ポケモンセンターの場所が間違っていたメモリフォルダに対してドリーミングを実行しました。Claudeはノートをセッショントランスクリプトと照合し、エラーを検出し、それを書き直しました。トランスクリプトは、Claudeにメモリを検証するためのグラウンドトゥルースを提供しました。修正されたメモリノートにより、Claudeは直接月の山に入り、最終的にハナダシティに到達しました。

修正されていないノートの実行では、Claudeは3回その前のルートに落下しました。3回目の失敗の後、Claudeは「ループし続けるよりもやめよう」と書いて、諦めたようでした。私たちのセットアップの自動応答は、続行するように指示しました。そのため、Claudeは山の前の町であるトキワシティまで戻り、そこで回復と補充を望んでいました。Claudeがハナダシティに到達することなく実行は終了しました。

ドリーミングは新しいメモリ表現を構築できる

ドリーミングにより、Claudeはメモリをナビゲートするための表現を構築できます（図9）。使用されるメモリ表現の一種はwikiと呼ばれ、Claudeが書いたページと維持するページのコレクションで、Claudeが一つの主題について知っていることを集め、他のノートとリンクします。これらのリンクは、Claudeにメモリをふるい分け、必要に応じてメモリを効率的に見つけるためのマップを提供します。

wikiのような表現は、Claudeが成長し続ける知識ベースを横断するのに役立ちます。私たちは、Stainlessという、5月に買収したソフトウェア会社の内部ドキュメント（約35万ファイル、約4億2000万トークン）のコーパスを使用して、メモリ表現としてのwikiの利点を調査しました。このコーパスに関する25の質問の評価セットを作成し、Claudeにそれを探索するための検索ツールを与えました。また、ドリーミングを使用してこれらのファイルに基づいてwikiを構築するようにClaudeに指示しました。128セッションにわたって、Opus 5エージェントにファイルを探索し、リンクされたwikiページを作成または修正し、重複をマージし、ソースと主張を照合するように促しました。

各セッションは、エージェントが以前のセッションで行った進捗の上に構築され、共有ログを使用して作業を調整しました。ドリーミングを2セッションから128セッションにスケールアップするにつれて、25の質問に対するパフォーマンスは、評価基準の13%から48%に向上しました（図10）。

Claudeはwikiを段階的に構築します。初期wikiを作成した後、後続のドリーミングラウンドを使用してそれを追加、編集、または削除します。初期のドリーミングラウンドでは、Claudeの知識は新入社員の知識に似ており、wikiのみに基づいて質問に答える能力は限られています。ドリーミングを繰り返すほど、知識マップはベテラン社員のように豊かになります。私たちのテストでは、検索ツールへのアクセスも与えられた場合、wikiはClaudeに最も役立つことがわかりました。検索とwikiの両方を使用したとき、Claudeの累積スコアは、検索ツールのみにアクセスした場合の53%と比較して、wikiが成長するにつれて54%から61%に上昇しました。Claudeの最高のスコアは、質問に答えるためにwikiのみを使用した場合は48%でした。検索とwikiの使用は、質問あたり約20,000トークンを節約しました。

Claudeがwikiを持つことでどのような種類のタスクが利益を得るかをテストしたかったのです。これを行うために、Harvey LABベンチマークと、合併に関する文書のコレクションを使用しました。ベンチマークはClaudeに文書セットを与え、その内容に基づいて法的弁論を作成するように要求します。その後、ベンチマークは基準リストに対して弁論を採点します。ポケモン実行ほど魅力的ではないかもしれませんが、これらの評価は、wikiを構築するための多様な文書コレクションを提供してくれます。

Claudeに文書からwikiを構築するように指示しました。その後、Claudeに（合併に関する）質問に答えたり、法的弁論を作成したりするように依頼しました。これはwikiから、または直接ファイル検索から行いました。あるテストでは、合併に関する24の質問（図11、左）があり、その半数以上でClaudeは複数の文書から情報を検索する必要があり、多くの場合、判断や計算も必要でした。これらの項目（赤とオレンジの線）では、Claudeは検索のみを使用した場合は73%だったのに対し、wikiを参照した場合は87%のスコアでした。

他のケースでは、wikiはそれほど有用ではありませんでした。あるLABタスク（図11、右）では、弁論の基準は単一のドキュメントからのテキスト検索で取得できることが多く、wikiは検索と比較してパフォーマンスに明確な向上を示しませんでした。別のLABタスクでは、wikiは文書自体よりも大きくなりました（図12）。ボルヘスの1段落の短編小説「科学における正確さについて」の地図製作者のように、帝国と同じ大きさの地図を作成したClaudeは、何も抽象化しない非常に詳細なwikiを作成しました。

ドリーミングはメモリ階層の上位にノートを昇格できる

ドリーミングは、ノートをメモリ階層の最上位に浮上させることもでき、エージェントハーネスはそれらを各セッションの開始時にClaudeのコンテキストに先取りしてロードできます（図13）。これは、Claudeがそれらを検索する必要がないこと、あるいは検索すべきものがあることを知る必要さえもないことを意味します。

新しいセッションにメモリを昇格させること（コンテキスト注入の一形態）は慎重に行う必要があります。注入されたメモリは貴重なトークンを消費し、間違ったノートはすべてのセッションに引き継がれる可能性があります。ノートをロードしても、Claudeがそれに基づいて行動することを保証するわけではありません。Claude Codeのドキュメントでは、長いインストラクションファイルは遵守率を低下させると警告しています。したがって、メモリ階層の最上位は比較的小さく保つ必要があり、ドリーミングの作業の多くは、一部の詳細を下位階層に移動し、リンクを残すことによってそれを維持することです。

Claude Codeの自動メモリは、同じ方法で注入レイヤーを小さく保ち、Claudeはセッション中にそれを維持します。Claudeはすべての自動メモリを各セッションのコンテキストウィンドウにロードするわけではありません。MEMORY.mdの最初の200行または25KBのみをロードします。このヘッダーはインデックスとして機能し、Claudeに何を知っていてどこで見つけられるかを示します。

ドリーミングはメモリを特定の目標に集中させることができる

ドリーミングは、メモリの成長方法を形成することもできます。例えば、Claude Duetのようなアシスタントは、支援している人に焦点を当てたメモリを持つことで恩恵を受けることが多く、ドリーミングは特定の目標のためにメモリを構築するように調整できます。

メモリの成長を指示する指示はタスクによって異なり、Claudeにどの情報が実際に重要かを伝えます。例えば、LABベンチマークのタスクの1つは、企業の買収をシミュレートし、契約セットを提供します。弁論は、契約条件を正しく記述しているかどうかに基づいて採点されます。

wikiを生成するための基本的な指示から始めましたが、Claudeにwikiをどのように使用するかは伝えませんでした。このタスクは契約条件に大きく依存していました。wikiが構築されている間、複数のエージェントが同時に共有契約条件テーブルに書き込んでいました（図14、左）。

結果として、重要な事実が欠落したwikiが作成されました。wikiから生成された弁論を採点したところ、Claudeは57の事実のうち41（72%）しか含んでいませんでした。何がうまくいかなかったのかを調べたところ、共有テーブルは契約条件を不十分に要約しており、エージェントがお互いの作業を上書きしたため、一部の条件が完全に欠落していました。

契約条件はwikiの最も重要な部分でしたが、指示にはそのことが記載されていませんでした。より良い指示を見つけるために、Claudeが失敗を振り返り、指示の変更を提案し、wikiを再構築するループを実行しました。このループにより、Claudeは契約条件に従うことの重要性を発見し、それに応じてwikiを構築するための指示を書き直しました。

各契約はwikiで独自のページになり、単一のエージェントによって書かれ、共有テーブルに要約するのではなく、条件をそのまま引用しました。この改善されたwikiから生成された弁論を採点したところ、基準の100%が満たされ、以前の72%から向上しました。

ドリーミングはセッションが残したギャップを埋めることができる

Claudeがメモリノートを書くとき、それはその特定のセッションのコンテキストしか見ません。ドリーミングは、多くのセッションを横断して共通のパターンを見つけたり、一般的な間違いを修正したりできます。

LABベンチマークのwikiを構築する際（例として図14を参照）、Claudeはまだ作成されていないページにリンクすることがありました。2回目のドリーミングパスで、これらのギャップの多くが閉じられました。あるタスク（図15）では、ドリーミングはwikiの欠落ページへの9つのリンクを見つけ、それらを同じドキュメントの既存のページに再ポインティングしました。また、wikiを改善するために、インデックスを含む3つの新しいページを追加しました。

後ろ向きに考え、前向きに見る

エージェントのメモリシステムを設計する方法については、多くの未解決の質問があります。1つは、Claudeがいつメモリを作成すべきかということです。Claudeがタスクに取り組むとき、メモリストア（例：フォルダ、ファイル、データベース）に書き込み、顕著さをソースでキャプチャし、将来のターンやセッションで重要な詳細を即座に利用可能にすることができます。しかし、その場でノートをログに記録することは、必然的にClaudeの注意をメインタスクからそらします。対照的に、ドリーミングはメモリ作成をバックグラウンドに押し出すことができますが、ドリーミングからの出力はClaudeが即座にアクセスできない可能性があります。

もう1つの質問は、メモリを確実に最新の状態に保つ方法です。Claudeは誤った予測をしたり、最初から間違っているルールをメモリに書き込んだりすることがあります。環境が変化すると、メモリがずれて無関係になることもあります。ドリーミングはこれらの間違いを修正する1つの方法ですが（図8）、計算が必要です。Claudeにすべてのメモリを継続的にチェックするように指示することは実用的ではないかもしれません。代わりに、変更されそうな情報にドリーミングを集中させるか、ドリーミングの頻度を慎重に調整することが重要かもしれません（例：メモリへのアクセス頻度に基づく）。

Claudeのトランスクリプト検索をメモリの基盤と考えることも合理的です。表現（例：wiki）と検索（図10）を組み合わせることが効果的な場合があります。しかし、Claudeはメモリ表現を維持し、それらがエラーや幻覚を蓄積しないようにするために計算を使用する必要があります。

Claudeの顕著さに関する判断は改善されましたが、将来のターンに何が起こるかを真に知ることができるモデルはありません。ドリーミングは、Claudeに後ろ向きに見て、計算を使用してメモリを整理し、間違いを修正し、将来のセッションがメモリに容易にアクセスできるようにする表現を維持する機会を与えます。Claudeがより有能になるにつれて、メモリシステムは進化し、Claudeのメモリシステムを設計することについては、まだ学ぶべきことがたくさんあります。

ドリーミングの開始方法と知識wikiのクックブックをご覧ください。