メインコンテンツまでスキップ
中級

エージェントのメモリは実際どう動くのか

チャットボットに同じ質問を2つのセッションで2回すると、どちらも初対面のように答える。それはバグではない — デフォルトの動作だ。素の言語モデルは呼び出しの間にメモリを持たない。1つの会話の中で「覚えている」ことはすべてコンテキストウィンドウの中に存在し、その会話が終われば消えてしまう。

メモリとは、それを直すために後付けする仕組みのことだ。エージェントが何を先へ持ち越すべきか、どこに保存するか、そして適切な瞬間に適切な一片をどう引き戻すかを決めるシステムである。2026年、これはサイドクエストであることをやめ、独自のベンチマーク、フレームワーク、そして本格的な研究文献を伴う、エージェント設計の第一級の要素となった。このページはその地図だ。

What you'll learn
  • コンテキストウィンドウがなぜメモリではないのか — そして境界が実際にどこにあるのかを理解する
  • エージェントが使う4種類のメモリを区別する: ワーキング、エピソード、意味、手続き
  • 4つのストレージパターンを比較する: フルコンテキスト、vector/RAG、ナレッジグラフ、コンパクション/要約
  • Claude、ChatGPT、Geminiが今日それぞれどうメモリを実装しているかを見る
  • 過剰な作り込みをせずに、自分のエージェントに合ったメモリのアプローチを選ぶ

押さえておくべき唯一の考え: コンテキスト ≠ メモリ​

最もよくある混同は、大きなコンテキストウィンドウを「メモリ」として扱うことだ。それは違う。コンテキストウィンドウは1ターン分の作業スペースであり — 呼び出しのたびにゼロから詰め直され、有限で、しかも高価だ。アテンションもその中で劣化する（Context Engineering で扱った「lost in the middle」効果）。

メモリは3つの点で異なる:

コンテキストウィンドウメモリ
寿命1リクエストセッションをまたぎ、日をまたぎ、永久に
サイズ固定のtoken上限事実上無制限（外部ストア）
コスト毎ターン支払う書き込み時に一度だけ支払う。参照は安価
アクセスすべてが常に視野に入る選択的 — 関連するものだけを取り出す

エージェントメモリの本質はまるごと、適切な情報をこの2つの間で動かすことにある。持続的な事実をウィンドウの外へ書き出して毎ターン代金を払わずに済むようにし、この特定のステップがそれを必要とするときにだけ中へ引き戻す。その流れを正しく作れば、エージェントは常に数千個の関連トークンしか保持しないコンテキストウィンドウで何週間も稼働できる。

メモリの4種類​

（大まかに）認知科学から借用して、2026年のエージェントエコシステムは4つのカテゴリーに収束した。4つすべてが必要になることはめったにない — だが名前を付けておくことで、すべてを下手にこなす一枚岩を作ってしまうのを防げる。

Guided walkthrough1 of 4
  1. 今まさにコンテキストウィンドウの中にあるもの — 現在のタスク、直近の数ターン、このステップのツール結果。設計上、揮発性である。これはスクラッチパッドであってアーカイブではない。これをうまく管理するのがコンテキストエンジニアリングであり、永続化ではない。

便利な判定法: もし*「それはいつ起きた?」と答えるならエピソード、「何が真実?」と答えるなら意味、「やり方はこう」*と答えるなら手続き、そして次の数秒間しか重要でないならワーキングメモリであり、永続化する必要はまったくない。

4つのストレージパターン​

何を覚えるかが分かったら、次にどう保存し取り出すかを選ぶ。支配的なパターンは4つあり、おおむね複雑さの順に並ぶ。実際のシステムの多くは2つか3つを組み合わせる。

1. フルコンテキスト（全部詰め込む）​

履歴全体を保持し、毎ターン再送信する。インフラ不要、完璧な想起 — token上限、コスト曲線、あるいは「lost in the middle」にぶつかるまでは。短いアシスタントには十分。だが長時間動くものには行き止まりだ。これは他のすべてのパターンが改善しようとするベースラインである。

2. Vector / RAG メモリ​

各メモリをembeddingとしてvectorデータベースに書き込む。クエリ時に現在のターンをembeddingし、最も類似した上位k件のメモリを取り出す。これは検索拡張生成を、ドキュメントではなく会話履歴に向けたものだ。安価でスケーラブルであり、事実や好みの意味的な想起のためのデフォルトとなる。

その弱点: 類似性 ≠ 関連性である、時間的またはマルチホップの質問においては。「予算が削られた後に何を決めた?」は順序の質問であり、コサイン類似度には時間の感覚も、2つの事実をつなげる感覚もない。

3. ナレッジグラフメモリ​

メモリをエンティティと関係として保存する — ノードとエッジであり、しばしばエッジにタイムスタンプが付く。質問に答えるにはvectorをファジーにマッチさせるのではなく、グラフをたどる。これがマルチホップと時間的推論を扱えるようにする（「ユーザーが苦情を言った相手のアカウントを担当していた人物を、誰が引き継いだのか?」）。Zep/Graphiti のようなフレームワークは、時間的ナレッジグラフを中心に売り込みを構築した。その代償は本物のエンジニアリングだ: 抽出、エンティティ解決、そしてグラフが腐らないよう保つこと。

4. コンパクション & 要約​

走っている履歴を定期的に蒸留した要約へ圧縮し、そこから続ける — 逐語的な想起を、より小さく安価なウィンドウと引き換えにする。これが Claude Code の /compact がやることであり、多くのチャット製品の「自動要約」がやることだ。長期メモリの最も安価な形であり、実際に最初に必要になるものであることが多い。そのリスク: 要約が、あなたが必要としていた唯一の詳細を静かに落としてしまう。数時間に及ぶ実行でこれがどう展開するかについては Long-Running Agent Harnesses を参照。

Pro tip

実際のシステムはこれらを層にする。よくある2026年のスタック: 走っている会話にはコンパクション、意味的な事実にはvector、そして時間的/マルチホップのクエリが実際にトラフィックに現れたときにだけ、その上にグラフ。グラフが解決する痛みを感じるまでは、グラフを作らないこと。

大手3社はどうやっているか​

主要なアシスタントは今やどれも何らかのメモリを搭載している。それらは同じものではなく、その違いは重要だ。

製品何を覚えるかどう動くか（大まかに）
Claude2層: あなたの好みをアプリレベルで覚えるメモリと、エージェント向けの開発者向けmemory tool。Claude app memory はチャットをまたいで事実を保存する。API の memory tool と context editing は、エージェントがクライアント側のストアにメモを書き込み、古くなったツール結果を自動でプルーニングして長時間の実行を生き延びられるようにする。
ChatGPT「保存されたメモリ」（明示的な事実）に加え、過去のチャットへの参照。ユーザーが述べた事実と自動抽出された好みの混合で、後のターンでシステムコンテキストに注入される。ユーザーが編集でき、オンオフを切り替えられる。
Geminiあなたのチャットから、そして任意で、より広い Google アカウントの領域から引き出されるパーソナルコンテキスト。以前の会話の詳細を想起し、アカウントのコンテキストを使ってパーソナライズできる。あなたのプライバシー設定に従う。

2つの学び。第一に、コンシューマー向けメモリはほとんどが意味メモリだ — 好みと事実であり、完全なエピソードの再生ではない。第二に、もしあなたがエージェントを構築しているなら、製品の組み込みメモリはあなたのメモリシステムではない。その層はあなた自身が所有し、Claude の memory tool のようなプリミティブや外部フレームワークを使う。

素のモデルをメモを取るエージェントに変える（最も安価な本物のメモリ）

You have a file called MEMORY.md that persists between our sessions.

At the END of each session, append any durable facts worth keeping:
- my stable preferences (tools, formats, style)
- decisions we made and WHY
- open threads to resume next time

At the START of each session, read MEMORY.md first and use it.
Keep it under 30 lines — when it grows past that, consolidate and
delete anything stale. Never store secrets or credentials.

その1つのパターン — 持続的なメモを外部ファイルに書き、次回それを読み戻す — こそがエージェントメモリの80/20だ。以下のフレームワークの仕組みのほとんどは、まさにこれをより自動的で、よりスケーラブルにしたバージョンにすぎない。

メモリを測る: LoCoMo ベンチマーク​

測れないものは改善できない。そしてメモリはベンチマークが登場するまで測るのが難しかった。最も引用されるのが LoCoMo（「Evaluating Very Long-Term Conversational Memory of LLM Agents」）だ: 非常に長いマルチセッションの会話 — 数十のセッションにまたがる数百のターン — に、5つの種類の質問回答ペアが付く: single-hop、multi-hop（セッションをまたぐ）、時間的推論、オープンドメイン、そして敵対的。

LoCoMo が明らかにするのは、設計の指針とすべきパターンだ: システムは single-hop の事実想起はそこそここなし、時間的とマルチホップの質問で崩壊する。その失敗モードこそが、まさにナレッジグラフメモリが存在する理由だ — それはその2つのカテゴリーを最も引き上げるパターンなのである。自分のエージェントのメモリを評価するときは、マルチホップと時間的なケースに重い比重をかけること。single-hop の想起はほとんど何でも良く見せてしまう。

過剰に作り込まずにアプローチを選ぶ​

Guided walkthrough1 of 5
  1. 何もしない。ワーキングメモリ（コンテキストウィンドウ）で十分だ。ここでメモリストアを追加するのは純粋なオーバーヘッドである。

罠はステップ5から始めることだ。グラフメモリはデモでは印象的で、本番では高価だ。はしごを登り、実際の問題を解決する最初の段で止まること。

Check yourself

0/4
  1. 大きなコンテキストウィンドウが、なぜエージェントのメモリと同じではないのか?
  2. ユーザーが尋ねる: 「予算が削られた直後に何を決めた?」どのメモリアプローチが正しく答えられる可能性が最も高いか?
  3. 「ユーザーはメートル法を好む」の分類として正しいのはどれか?
  4. 短い単一セッションのヘルパーボットを作っている。正しいメモリ設計は?
エージェントメモリの用語
Enter キーまたはスペースキーでカードを裏返します。左右の矢印キーでカードを移動できます。用語を表示しました。
1 / 8

結論​

メモリはオンにする1つの機能ではない — それはあなたが設計する流れだ: 何がウィンドウを去るか、それがどこに保存されるか、そしてどう戻ってくるか。4つのメモリ種類に名前を付けて、すべてを一枚岩で作らないようにすること。自分の問題を解決する最も安価なストレージパターンから始め、次のパターンの痛みを感じたときにだけ登ること。そして時間的とマルチホップのケースで測ること。なぜなら single-hop の想起は、あらゆるものを実際より賢く見せてしまうからだ。

メモリは Context Engineering のもう半分だ: コンテキストエンジニアリングはこのターンに何がウィンドウを満たすかを決める。メモリはターンの間に何が生き残るかを決める。この2つが合わさって、チャットボットと、あなたが長く一緒に働くほど良くなるエージェントとを分けるのだ。

情報源とさらに読む​