10月23日、n8n blogが「AI Agent Memory: How LLM Agents Manage State in Production」と題した記事を公開した。本記事はCogneeのメンバーによるn8n blogへの寄稿であり、LLMエージェントが本番環境でどのように状態（ステート）を管理するか、短期・長期メモリのアーキテクチャ設計と実装パターンについて詳しく紹介されている。
LLMはそもそも何も覚えていない
まずこの前提から入る。LLM自体にはメモリがない。各リクエストは独立しており、モデルはプロンプトを読んでレスポンスを返したら何も保持しない。次のリクエストが来た時点で、前のやり取りはモデルにとって存在しないも同然だ。
一問一答ならそれで問題ない。しかしフォローアップを処理するサポートエージェント、更新商談に備えるセールスアシスタント、1時間おきに実行されて前回の結果を把握すべきワークフローなど、継続性が必要なシステムには「状態」が必須であり、モデルはそれを保持できない。
結論としてはシンプルだ。エージェントのメモリはモデルの外側に置く。エージェントは学んだことを外部に保存し、各LLM呼び出しの前に関連部分を取得してプロンプトに注入する。この外部レイヤーが「AIエージェントメモリ」であり、その設計が「エージェントが正しいことを記憶できるか、無関係な情報に埋もれるか」を決める。
短期メモリと長期メモリ：2つの時間軸
エージェントのメモリは通常、2つの時間軸で機能する。
短期メモリは「今起きていること」を追跡する。直近のメッセージ、中間推論、ツール出力、タスクの現在状態などだ。コンテキストウィンドウが埋まると、履歴をサマリーに圧縮して差し戻す手法がよく使われる。ただし要約は詳細を失い、中間ドラフトや高コストな計算結果は圧縮してはいけないケースもある。
長期メモリはセッションをまたいで生き続ける。ユーザーの好み、過去タスクの結果、うまくいった手法の知見、そしてドキュメント・チケット・CRMレコードといった外部ナレッジが対象だ。どのデータを保持し、どう構造化し、各リクエストで何を返すかを決める専用レイヤーが必要になる。
どちらの場合も、モデルへの届け方は変わらない。モデルが受け取るのは1つのプロンプトだけ。メモリはそのプロンプトの組み立て方を変えるだけだ。
RAG・コンテキストエンジニアリングとの違い
よく混同される4つの概念を整理する。
| アプローチ | 知識の場所 | 更新者 | 向いている用途 |
|---|---|---|---|
| LLMメモリ（モデルの重み） | モデル内部 | 訓練・ファインチューニング | 一般知識・スキル |
| コンテキストエンジニアリング | 現在のプロンプト | アプリケーションコード | このリクエストに必要なデータの注入 |
| RAG | 主に静的な外部コーパス | ドキュメントを書く人・システム | 既存知識でアンサーをグラウンディング |
| エージェントメモリ | 進化し続ける外部メモリ層 | 人、データパイプライン、エージェント自身 | タスク・セッション・ソースをまたいだ継続性 |
RAGとエージェントメモリの最大の違いは書き戻しがあるかどうかだ。RAGは読み取るだけで書き戻さない。「先週ユーザーが何を聞いたか」「どの修正が既に失敗したか」はRAGでは記憶できない。エージェントメモリはエージェントが新しい事実・好み・結果をその都度書き込み、後で取得する。
メモリのアーキテクチャ：4つのパターン
どのストアを選ぶかが、書き込みロジックと検索能力を大きく左右する。
- ベクターデータベース: セマンティック類似度で検索。セットアップが簡単だが、「Q3売上」と「Q4売上」はベクター空間で近接するため区別が難しく、時系列の概念もない。
- ファイル（MEMORY.mdなど）: コーディングエージェントで普及したパターン。透明性があり、バージョン管理できる。ただしスケールしないし、複数エージェントで共有するとすぐ破綻する。
- ナレッジグラフ: 事実をエンティティとリレーションシップで表現。「売上レポートはEU案件を対象とし、EU案件はユーロ建てで、数値は請求エクスポートから来ている」という関係をエッジでたどれる。論理的に関連する事実を取得できるが、インジェスト時のコストが高い。
- ハイブリッド: 実際の本番システムはこれ一択に近い。完全一致のIDはインデックス、関係性はグラフ、曖昧検索はベクター、時系列クエリはタイムスタンプ付きストアと、複数を組み合わせてロジックで統合する。
「溜め込むだけ」は機能しない：メモリ管理の3要素
メモリレイヤーは増え続けるだけでは劣化する。古い事実が正しい事実と競合し始めるからだ。記事では管理すべき3つのプロセスが挙げられている。
- 集約（Consolidation）: 生エントリを定期的に要約・高レベルなレコードに変換し、元データへのトレイルを残す。
- 更新（Updating）: 事実が変わった時、盲目的に上書きすると履歴が消える。タイムスタンプを保持し「今の事実」と「3月時点での認識」を両方答えられる状態を維持する。
- 忘却（Forgetting）: 古いデータセット、修正済みの誤情報、削除リクエストに対して明示的な削除操作が必要。使用頻度による自然な重み減衰とは別の操作として扱う。
使用から学習する仕組みも重要だ。回答が確認されればその根拠となったメモリの重みが上がり、修正されれば下がる。週単位で検索精度が上がっていくのが理想とされている。
ベンチマーク：BEAMでの数字
記事では公開ベンチマークにも触れている。代表的な3つはLoCoMo（約26Kトークン）、LongMemEval（約115K）、そして最も厳しいBEAM（最大10Mトークン、10種のメモリ能力を評価）だ。
BEAMでの現時点のState of the Artは**100Kトークンで79%、10Mトークンで67%**とされている。前の最高スコアはそれぞれ73.4%・64.1%だった。なお本記事はn8n blogへのCognee寄稿であり、このスコアはCognee自身が記録したものとして紹介されている点には留意されたい。ベンチマーク提供者と記録保持者が同一であるため、数値の客観的な検証には第三者評価を参照することを勧める。
記事自体も「ベンチマークは最終回答をチェックするだけで、何週間もの更新後の状態や複数エージェントで共有した時の挙動は見ない」と正直に指摘している。最終的に重要なのは、自分のワークフローでメモリありとなしを比較した実測だとしている。
n8nでの実装：2つのパターン
記事の後半はn8nとCogneeを組み合わせた実装例に当てられている。大きく2つのパターンだ。
1. 全ワークフロー共有の「会社ブレイン」
Slackスレッド、チケット、ドキュメント、CRMノート、通話トランスクリプトなどをn8nのトリガーで収集し、メモリレイヤーに構造化して蓄積する。各ワークフローはアクション実行前にそのメモリに自然言語でクエリできる（「Acmeの現在のステータスは？約束したことは？」）。単純な類似検索では得られない、エンティティ間の関係を含んだ回答が返ってくる。
2. 単一のAIエージェントワークフロー内メモリ
n8nのAI AgentノードのMemoryポートを使う短期メモリと、Cogneeのようなツールで実装する長期メモリを組み合わせるパターン。前者はデフォルトの「Simple Memory」で会話履歴を保持し、後者はセッションをまたいで学んだことを蓄積する。
詳細はAI Agent Memory: How LLM Agents Manage State in Productionを参照していただきたい。
