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

AIエージェントに記憶を持たせるとき、記録を保存して検索するだけで足りるのか。

Anthropic ResearchのLance Martin氏が2026年11月6日に公開した「The components of agent memory」を、人間の脳の働きになぞらえて整理しました。

記憶を「作業中に書く時点」と「作業の合間に振り返る時点（dreaming）」の二つに分け、メモ・wiki・注入コンテキスト・トランスクリプトという4つの層へ書き移す構造を、記事が示した実験結果（CL-Bench、Pokémon Red、Harvey LAB）とともに紹介しています。

振り返る時点では、記録との照合による修正、wikiと検索の併用、毎回読む層を小さく保つこと、用途に合わせた整理の基準、セッションをまたいだ抜けの補完という5つの働きを取り上げました。

書く時点の判断がモデルの進歩で上達しても、振り返る時点の仕組みは不要にならない。この示唆を、メモリ設計の判断としてまとめています。

AIエージェントの記憶設計に携わる方の参考になれば幸いです。

Transcript

1. AIエージェントメモリの 構成要素 人間の脳構造を捉えたdreaming 2026年11月 為安圭介 Lance Martin, Anthropic Research 2026年11月6日「The components of agent memory」より
2. 人生は後ろ向きにしか 理解できないが、 前向きに 生きなければならない セーレン・キェルケゴール （デンマークの哲学者、思想家） AIエージェントの記憶設計も同じ問題を抱える。 記録の価値は後から分かるが、行動は今決めなければならない。
3. サマリ 記録を残して検索するだけでは足りない理由 AIエージェントに記憶を持たせる方法として思い浮かぶのは、過去の 会話や作業の記録を保存し、必要になったときに検索する仕組みだ。 ただし、この仕組みには二つの難しさがある。何を残すかは、将来何 が必要になるかを知る前に決めるしかない。また、残したメモに誤り や古い情報が混じっても、次のセッションのエージェントはそれを信 よく知られた仕組み 記録を保存し、必要なときに検索する 難しさ1 難しさ2 残す内容を 誤ったメモや古いメモも 将来を知る前に決める 信じて使う じて使ってしう。 記事は、記憶を二つの時点に分けて扱う。作業しながら重要なことを 書き留める時点と、作業の合間に記録を振り返り、記憶を直して組み 直す時点だ。記事は後者を"dreaming"と呼ぶ。記事全体を通して示 されるのは、エージェントの記憶は、書く時点の判断と、 あとで記録を振り返って直し組み直すdreamingを組み合わせること で、正しく、必要なときに使える形に育つということ。 Anthropic Research 2026年11月6日「The components of agent memory」 書く時点 作業中に重要なことを書く 振り返る時点（dreaming） 合間に記録と照合し、直して組み 直す 記事の冒頭に引かれたキルケゴールの言葉「人生は後ろ向きにしか理解で きないが、前向きに生きなければならない」は、二つの時点の関係を表し ている。
4. 作業中に書く処理と振り返る処理 記事は、作業中に書く処理と、作業の合間に記録を振り返る処理（dreaming）を組み合わせる。 Ａ Ｉ エ ー ジ ェ ン ト の 脳 人 作業中に書く 振り返る（dreaming） 次の作業 セッションの最中 セッションの合間 次のセッション 重要だと判断したことを、 その場でメモに書く 作業の記録とメモを読み直し、 誤りを直し、整理し、 次に読むものを選ぶ 直して整理した記憶を読んで使う 難しさ1に向き合う： 何を書くかを判断する 難しさ2に向き合う： 誤りを後から直す 書く時点（海馬） 振り返る時点（新皮質） 経験の最中 睡眠中、休息中 経験をその場で素早く記録する 記録を再生し、長期の知識へまとめる 発想の元：LettaとUC Berkeleyの研究者が提案したsleep-time compute この分け方は、人の脳の働きに ならったもの。 エージェントの記憶は、 書く時点の判断と、 あとで記録を振り返って 直し組み直すdreamingを 組み合わせることで育つ。
5. 記憶の4つの層 二つの処理は、4つの層に記憶を書き移す。作業中に書くのはメモの層。 注入コンテキスト 毎回のセッション開始時に読み込む 記憶表現（wikiなど） dreamingが選んで移す メモをつなぐ地図 dreamingが作る メモ 作業中に書く dreamingが直す Claudeが書いた重要な観察 トランスクリプト 作業の記録がそのまま残る 照合の基準になる つまり、書く時点の判断はメモの層に関わり、振り返る時点の働きは、メモの修正と、その上 の層づくりに関わる。
6. 書く時点 1/4 CL-Benchの結果 どのモデルもメモで点数が上がったが、上がり幅はモデルで大きく違った。 メモを書くことは将来の予測でもある。規則を書くのは、同じパターンがまた役立つと予測すること。冒頭のデータベースのタスクで、その 上手さをモデルごとに比べた。 ▪ メモなし ▪ メモあり 右端は上がり幅 0.655 Opus 5.5 0.644 Sonnet 5.5 0.564 Opus 5 0.383 Opus 4.7 Sonnet 5 Sonnet 4.6 0.306 0.330 0.364 0.838 +0.183 0.833 +0.189 0.828 +0.264 0.700 0.610 +0.317 +0.304 +0.034 検証条件：データベースを調べて質問に順に答える。答えるたびに正解を知らされ、次の質問のためにメモを書ける。各質問は新しいセッションで始まり、持 ち越せるのはメモのフォルダだけ。評価値は平均報酬（0〜1、高いほど正しい）。
7. 書く時点 2/4 差を生んだメモの中身 上がり幅は、検証済みの規則を残せたかどうかで分かれた。 上がり幅の違いは、メモに何を残せたかで説明できた。記事はこれを学習のループとして表現。 間違えたら失敗を記録し、原因の仮説を立て、その仮説を確かめ、次に答えるための規則にする流れ。 失敗を記録する 原因の仮説を立てる ここまで到達：Sonnet 4.6 仮説を確かめる ここまで到達：Opus 4.7、Sonnet 5 規則として残す ここまで到達：Opus 5、Opus 5.5、Sonnet 5.5
8. 書く時点 3/4 書かない判断 Fable 5は画面から読める情報を書かず、自分で導いた戦略と計画だけを残した。 重要なことを書くには、重要でないことを書かない判断も要る。記事はPokémon Redのプレイで、約1万ステップ時点の2つのモデ ルのメモを比較した。Sonnet 3.7は何でも重要かもしれないと考え、戦闘や拾ったアイテム、出会った人物ごとにファイルを作った。 Sonnet 3.7が書いたもの 戦闘、アイテム、出会った人物ごとのファイル。所持金や現在地も書いた → 状態が変わるたびに記録が古くなり、整理に追われた。1万ステップ付近の 17ステップでファイルを6つ作り、9つ消し、ゲームの操作は0回 Fable 5が書いたもの Sonnet 3.7 413ファイル、225フォルダ 約98万文字 バッジ1個 Fable 5 10ファイル 約4.3万文字 バッジ4個 global.mdに現在の目標、ジム攻略の計画、メモの使い方。ルートごとの移動 計画と、学んだ戦略のフォルダ 例：コイキングの捕獲に7回続けて失敗したあと「3回以上続けて失敗したら、 タイミングを変える」と書いた
9. 書く時点 4/4 何を書くかの指示 新しいモデルには目的だけを伝える方が効き、古いモデルには詳しい指示が効いた。 古いモデル：Sonnet 4.6の点数 メモなし メモあり メモあり＋詳しい指示 「失敗だけを記録」と規則を与えたとき 0.330 メモによる上がり幅の減少 0.364 −0.234 Opus 5 0.6 41 答える前にメモを読み、仮説を確かめるよう指示すると、ほぼ倍に なった −0.150 Opus 4.7 Sonnet 4.6 −0.020 新しいモデルほど、固定した規則で効果を失った 記事の方針：メモが何のためにあるかは伝え、どう使うかは指示しない。Opus 4.7とOpus 5は、メモのフォルダがあると伝えただけで 効果的に使えた。 Sonnet 5は指示がなくても、10回中9回、答える前にメモを読んだ。Sonnet 4.6は半分未満だった。
10. 振り返る時点が必要な理由 作業中のメモには限界があり、dreamingは作業の合間に5つの働きで補う。 書く時点の判断が上達しても、メモはそのセッションで重要だと判断したことにとどまる。 作業中のメモの限界 dreamingの働き 誤ったメモや古いメモも次のセッションが信じる ① 記録と照合して直す メモは増えるほど探しにくい ② wikiのような表現を作る 毎回読み込める量には限りがある ③ 必要なものだけ上の層へ移す 何が重要かは用途で違う ④ 目的に合わせて育てる 1回のセッションは、その文脈しか見ない ⑤ セッションをまたいで抜けを埋める
11. 振り返る時点 ① 記録と照合してメモを直す 誤ったメモをトランスクリプトと照合して直すと、Claudeは先へ進めた。 西の入口 PokéCenter 一方通行の段差 落ちると元の道へ 東の出口 Cerulean Cityへ 洞窟 Mt. Moon Pokémon Redには、Mt. Moonという洞窟を抜ける場面がある。入口は西、出口は東で、入口の近くには、落ちると元の道へ戻され、登り 直せない段差。 直さないメモ メモ「PokéCenterは 東側」「Mt Moon DONE」 段差から落ち、「西 へ行き過ぎた」と結 論 3回落ち、手前の Pewter Cityへ引き返 す Cerulean Cityに着け ない dreamingで直し たメモ メモをトランスクリ プトと照合 誤りに気づき、メモ を書き直す 洞窟の入口へ戻る 3,000手中1,935手目 にCerulean City Claudeは入口近くのPokéCenterを目印にしていたので、段差から落ちるかどうかは、PokéCenterが山のどちら側にあると思ってい るかで決まった。ナビゲーションのツールは段差を表示しなかった。 メモなしの実行もCerulean Cityに着けなかった。照合して直すには、作業の記録が残っている必要がある。
12. 振り返る時点 ② wikiは検索と併用し、複数文書をつなぐ仕事に使う wikiは検索の代わりではなく、用途に応じて育てる価値が変わる。 wiki：Claudeが書いて保守する、主題ごとのページとリンク。必要な記憶を探す地図。 採点基準を満たした割合（濃い棒が128セッション後） 54%（2セッション後） wikiと検索 61% 53% 検索だけ wikiだけ 効果あり：複数文書をつなぐ問い 13%（2セッション後） 48% 合併の24問：wiki 87%／検索だけ 73%。 半分以上が10文書の複数を参照し、判断・計算も必要。 差なし：1文書で答えられる問い Harvey LAB：57採点項目の多くは、 取引概要メモ1つの検索で満たせた。 注意：wikiが原文より大きくなる場合も 別のLAB：10文書115KB → wiki 203KB（1.77倍）。 用途を見極め、育てる費用に見合うか判断する。 検証条件：Stainless社の社内文書（約35万ファイル、約4億2千万トークン）、評価25問。Opus 5が128セッションで保守。wikiは103ページ・766リンクから 222ページ・12,893リンクへ成長。検索と併用すると1問あたりのトークンも約2万減った。
13. 振り返る時点 ③ 毎回読む層を小さく保つ 毎回読み込む層は小さな索引にとどめ、詳細は下の層へ移してリンクを残す。 セッション開始時に読み込む 注入コンテキスト：何を知っていて、どこにあるかを示す索引 すべて読み込まない理由 必要なときに探して読む 読み込んだメモはトークンを消費する メモ、wiki：索引をたどって該当するページを開く 誤ったメモは、毎回のセッションに持ち込まれる 原文を確かめる トランスクリプト、元の文書 読み込んでも従うとは限らない。Claude Codeのドキュメントは、 指示ファイルが長いと遵守率が下がると警告している Claude Codeのauto memoryも同じ考え方で、MEMORY.mdの先頭200行ま たは25KBだけを読み込み、それを索引にしている。
14. 振り返る時点 ④ 用途に合わせた整理の基準 何が重要かは用途で変わるので、記憶を育てる指示も用途に合わせて変える。 最初の指示 書き換えた指示 契約Aのページ 共有の表1つ 4つのエージェントが同時に書き込み、互いの記述 を上書きした。条件の要約も粗かった 契約Bのページ Claudeが失敗を振り 返り、指示を書き換え るループ 契約条件が最も重要だ と見つけた 41/57（72%） 契約Cのページ 契約Dのページ 契約ごとに1つのエージェントが1ページを書き、 条件を原文どおり引用した 57/57（100%） Harvey LABの買収のタスク。wikiから作った概要書が契約条件を正しく書けているかを57項目で採点した。変わったのは担当の分け方、ページの単位、引用の 仕方の3点で、記事はどの変更がどれだけ効いたかを分けて示していない。支援する相手を中心に記憶を整理するClaude Duetも、用途に合わせた例。
15. 振り返る時点 ⑤ セッションをまたいだ抜けの補完 1回のセッションでは気づけない不整合を、2回目のdreamingが見つけて直した。 Claudeがメモを書くとき、見えているのはそのセッションの文脈だけ。dreamingは多くのセッションを横断して、共通のパターンや誤りを見 つけられる。 2回目のdreamingの前 38ページ、225リンク 6つのページ 2回目のdreamingの後 41ページ、278リンク 6つのページ escrow-agreement（存在しない） 9本のリンクが、存在しないページを指していた buyer-form-escrow-agreement 9本を同じ文書の既存ページへ付け替えた。 索引、指示のメール、エスカレーションの3ページも加えた Harvey LABのwikiを作る途中で、まだ作られていないページへのリンクが残った例。
16. 課題とまとめ 課題 三つの問いはいずれも、振り返りにいつ、どれだけ計算資源をかけるかの判断にかかわる。 いつ記憶を作るか どう新しく保つか 検索とどう分担するか 作業中に書けば重要な点をその場でとらえ dreamingは誤りを直せるが、計算資源を トランスクリプトの検索を記憶の土台にす る。すぐ次に使えるが、主タスクから注意 使う。すべての記憶を常に確かめるのは現 る考え方も成り立つ。wikiのような表現と がそれる。dreamingに回せば作業を妨げ 実的でないかもしれない。変わりやすい情 検索の組み合わせが効く場合もあるが、誤 ないが、出力はすぐには使えないことがあ 報に絞る方法や、アクセスの頻度で見直す りや幻覚がたまらないよう保守する計算資 る。 間隔を変える方法がある。 源がかかる。 決めること 見直す対象と頻度 決めること wikiを育てる費用に見合う用 途か 決めること 作業中に書かせるか、合間に まとめるか
17. 課題とまとめ メモリ設計への示唆 書く時点の判断はモデルに任せ、振り返る時点で照合、整理して整合を保つ。 過去の経験を、正しく、必要なときに使える記憶に変えるための分担と、その根拠。 タイミング 設計の判断 確認された条件と限界 書く時点 目的だけ伝え、何を書くかはモデルに任せる 古いモデルには詳しい指示が効いた 振り返る：直す トランスクリプトを残し、メモと照合して直す 照合には作業の記録が要る 振り返る：整理する wiki を地図にし、原文の検索と組み合わせる 複数の文書をつなぐ問いで効果。元より大きく なる例もあった 振り返る：用途に合わせる 何が重要かを用途から決め、整理の指示に入れる 3 つの変更が同時で、効果を分けた結果はない 次の作業 毎回読む層は小さな索引にし、整合はセッション をまたいで確かめる すべて読み込むと誤りも持ち込む 私が最も重要だと考えるのは、書く時点の判断がモデルの進歩で上達しても、振り返る時点の仕組みは不要になら ないこと。 記事が最後に述べるとおり、モデルは将来に起きることを本当には知りえないから。
18. ITエンジニアリングマネージャー ｜ コミュニティマネージャー ｜ 国家資格キャリアコンサルタント 技術と人をつなぐ仕事をしています S Y S T E M システムづくり ためやす けいすけ 為安 圭介 北海道・札幌 好きなもの システム構築／ITソリューション／プロジェクトマネジメント T E A M & CO M M U N I T Y チームづくり・場づくり AIコミュニティCDLE運営／ SHiFT／BUFF認定コミュニティマネージャー・メンター C A R E E R 人のキャリアに関わる 国家資格キャリアコンサルタント／キャリア支援／記事発信 note「キャリアのなやみ」 関心 人とAIのよりよい協働