エージェントメモリとは？短期記憶と長期記憶の設計・実装判断を実装者向けに解説【2026年版】

エージェントメモリは、AIエージェントがセッションをまたいで会話・決定・作業状態を保持し、次の実行で読み戻す仕組みです。短期記憶（スレッド内の会話履歴）と長期記憶（ユーザーの事実・過去の行動・手順）を分けて設計し、書き込みと削除の規則まで決めないと、記憶は増えるほど検索ノイズになります。この記事では、記憶の分類とRAGとの境界、LangGraph・OpenAI Agents SDK・Claude APIのメモリツール・Mem0/Zep/Lettaが実装している機構の差、保存先の選び方、そして採用を見送るべき条件までを実装の判断材料として整理します。数値と版番号はいずれも2026年8月2日時点の一次情報です。

まとめ：エージェントメモリの採用条件と見送る場面の結論

結論から示します。エージェントメモリを入れる価値があるのは、同じ利用者・同じ案件と何度も対話し、前回の決定や嗜好や進捗を読み戻すことで入力の手戻りが減る場合だけです。逆に、1回の問い合わせで完結するFAQ応答や、社内文書を引くだけの検索アシスタントに長期記憶を足しても、精度は上がらず保守対象だけが増えます。

設計の骨格は3つです。短期記憶はスレッド単位の履歴として永続化し、長期記憶は名前空間を分けた別ストアに置く。書き込みは生ログのまま溜めず、抽出・要約・重複排除を通した「1事実1レコード」に正規化する。無効化と有効期限を最初から設計に入れる。古い事実が消えない記憶は、時間が経つほど誤った前提を注入します。記憶を読み戻す先である窓の上限と計上範囲は、コンテキストウィンドウの定義と有効長の考え方で扱っています。

実装の第一手は、使っているエージェント基盤の内蔵機能（LangGraphのStore、OpenAI Agents SDKのSessions、Claude APIのメモリツール）で足りるかの検証です。抽出・矛盾解決・時系列管理まで要るときにMem0やZepのような専用基盤を足す順序が費用対効果に見合います。

エージェントメモリの定義とコンテキスト管理・RAGとの役割分担

用語の範囲を先に固定します。エージェントメモリは「実行時に書き込まれ、後の実行で読み戻される情報の集合と、その読み書きの規則」を指します。プロンプトに毎回同じ文言を入れる行為は記憶ではありません。書き込む主体がエージェント自身である点が、静的な設定ファイルとの分かれ目です。

短期記憶・長期記憶・エピソード記憶の3分類と保持期間の設計境界

分類の軸はLangGraph公式ドキュメントの区分が実装に直結する形です。短期記憶は単一スレッド内の状態で、会話履歴やツール実行結果が入ります。長期記憶はスレッドをまたぐもので、セマンティック記憶（利用者や案件についての事実）、エピソード記憶（過去のやり取りを少数事例として再利用するもの）、手続き記憶（エージェント自身の指示文を反省にもとづき更新するもの）に分かれます。

保持期間の境界はこう引きます。短期記憶はスレッド終了かトークン上限で要約に畳む。セマンティック記憶は削除要求か無効化まで残す。エピソード記憶は件数上限を決めて古いものから捨てる。手続き記憶は版管理し、前の指示文へ戻せるようにします。全部を同じテーブルに入れると、削除要求への対応が破綻します。

RAGとの違いは検索対象が外部知識か対話履歴かで分かれる境界

RAGとエージェントメモリは、検索技術としてはほぼ同じ道具（埋め込みとベクトル検索）を使います。分かれるのは書き込みの主体と対象です。RAGは事前に用意した外部文書をインデックスし、実行時は読み取り専用。メモリは実行時に生成された情報を書き込み、後から引く方式です。メモリ側にだけ「誰がいつ何を書いたか」「その事実がいつ無効になったか」の管理が要ります。

両者を1つの検索経路にまとめると、社内規程のような不変の知識と利用者の直近の発言が同じスコアで競合します。検索器を分け、プロンプト上でも別ブロックに置いてください。RAG側の設計はエージェンティックRAGの仕組みを整理した解説で扱っています。

メモリとRAM・KVキャッシュを取り違えたときの設計ミスの実例

「メモリ」という語は3つの層で使われ、要件定義の段階で混線します。1つ目はサーバーのRAM。2つ目はLLM推論のKVキャッシュで、1リクエスト内で再計算を省く仕組みであり、セッションをまたいで内容を覚えるものではありません。3つ目が本記事のエージェントメモリです。

取り違えの典型は「メモリを増やせば長い文脈を覚えられる」という要求です。実際に効くのはコンテキスト窓の使い方であって、記憶ストアの容量ではありません。推論側の仕組みはKVキャッシュがLLM推論を高速化する仕組みの解説、コンテキスト窓そのものの圧縮設計はコンテキストの構成要素と圧縮の実装で分けて確認してください。

主要フレームワークが実装するメモリ機構の比較と選定時の判断観点

2026年8月2日時点で、主要な実装は「フレームワーク内蔵」と「専用基盤」に分かれます。内蔵は永続化とスコープ分離までを担い、何を覚えるかの判断はアプリ側に残る構成です。専用基盤は抽出・統合・無効化まで引き受けます。どちらを選ぶかは、記憶の質をアプリ側で作り込む余力があるかで決まります。

LangGraphのcheckpointerとStoreで分ける短期と長期の境界

LangGraph（PyPI上の最新は1.2系、2026年8月2日時点で1.2.10）は、短期記憶をcheckpointerによるスレッド永続化として扱い、thread_id単位で状態を復元します。長期記憶は別APIのStoreで、store.put・store.get・store.searchの3操作と名前空間で構成される仕組みです。名前空間にテナントIDと利用者IDを含める設計にしておくと、削除要求のときに範囲を特定できます。

何を覚えるかの判断ロジックはアプリ側の実装であり、フレームワークは保存と検索の器を提供する立場に留まります。

OpenAI Agents SDKのSessionsが担う会話履歴の永続化の範囲

OpenAI Agents SDKのSessionsは、実行前に履歴を取得して入力に前置し、実行後に生成された項目を保存する仕組みです。バックエンドはSQLiteSession（ファイルまたはインメモリ）、OpenAI側で保持するOpenAIConversationsSession、拡張としてRedisSession・SQLAlchemySession・MongoDBSession、暗号化を被せるEncryptedSessionなどが用意されています。

ここで担保されるのは短期記憶の永続化です。取得件数はSessionSettingsのlimitで直近N件に絞れますが、会話から事実を抜き出して利用者プロファイルへ昇格させる処理は含まれません。長期記憶が要るなら、抽出層を自前で置くか専用基盤を接続します。

Claude APIのメモリツールがファイル操作でメモリを扱う仕組み

Claude APIのメモリツールは、記憶をファイルとして読み書きさせる方式です。ツール定義はmemory_20250818で、Messages APIでは一般提供されておりベータヘッダーは不要、Claude 4以降のモデルで使えます。コマンドはview・create・str_replace・insert・delete・renameの6種類です。

特徴はクライアントサイドで動く点です。モデルは操作を要求するだけで、実行するのは自社のハンドラーになります。保存先を自社インフラに置けるため、個人情報を含む記憶を外部に預けたくない要件と噛み合います。実装時はパストラバーサル対策が必須です。公式ドキュメントも、メモリ用ディレクトリの外を指すパスは拒否するよう明記しています。サーバー側の会話圧縮（コンパクション）と併用し、要約後も残すべき事実だけをメモリに書く分担が推奨されています。

Mem0・Zep・Lettaの専用基盤が引き受ける抽出と更新の処理

専用基盤は「何を覚えるか」の判断まで担います。Mem0（PyPI上の最新は2.0系、2026年8月2日時点で2.0.15）は会話・セッション・利用者・組織の階層で記憶を持ち、addで会話から事実を抽出しsearchで層をまたいで検索する構成です。公式サイトはLoCoMoベンチマークで92.5、検索1回あたり平均6,956トークン（全文投入型は25,000超）と公表しています。いずれもベンダー公表値であり、自社データでの再測を前提にしてください。

Zepは時間軸付きのナレッジグラフ（Graphiti）で、エンティティをノード、事実をエッジとして持ちます。新しい情報が既存の事実を無効化した時刻をエッジに記録するため、「いつまで有効だった事実か」を区別できます。Lettaは0.16系（同時点で0.16.8）で、humanやpersonaといったラベル付きのメモリブロックと、そこから溢れた情報を格納するアーカイバルメモリを分ける構成です。

選定の観点は単純です。記憶の中身を自社ロジックで制御したいならLangGraphやClaude APIのメモリツール、会話から自動で嗜好を拾わせたいならMem0、事実が時間とともに変わる業務ならZepの時系列モデルが噛み合います。

メモリに書く判断と捨てる判断を分けるライフサイクル設計の基準

記憶の品質は、書き込みの門番をどこに置くかで決まります。全発話を保存する実装は初期は動きますが、数百ターンを超えたあたりから検索結果に無関係な断片が混ざり、応答が不安定になります。

hot pathで書くかバックグラウンドで書くかの遅延の分岐

LangGraph公式は書き込み戦略をhot pathとbackgroundに分けています。hot pathは応答中にツールとして記憶を書く方式で、直後の応答から参照できる代わりに応答レイテンシが伸びます。backgroundは応答後や定期実行で書く方式で、レイテンシへの影響は小さい一方、書き込み前の再質問には間に合いません。

判断はこう切ります。「以後は敬語をやめてほしい」のような、その場で行動を変える指示はhot path。会話全体の要約や利用者プロファイルの更新はbackground。両方をhot pathに寄せると1ターンあたり数百ミリ秒から数秒の追加待ちが発生し、対話型UIでは体感品質を落とします。

抽出・要約・重複排除で肥大化を抑える更新パイプラインの設計手順

書き込み前に3段の処理を通します。抽出は永続化に値する事実だけを取り出す工程で、判定基準（利用者の属性・確定した決定・繰り返し現れる嗜好）をプロンプトに明示します。要約は複数ターンにまたがる経緯を1レコードに畳む工程。重複排除は既存記憶と意味が重なるレコードを検索し、追加ではなく更新に倒す工程です。

1. 会話ログから候補となる事実を抽出する
2. 既存記憶を検索し、重複または矛盾の有無を判定する
3. 新規なら追加、重複なら更新、矛盾なら旧レコードを無効化する
4. 書き込み結果を監査ログに残し、後から復元できるようにする

この4手順を欠く実装では、同じ事実の言い換えが何十件も並んで検索上位を埋めます。1事実1レコードが後段の精度を決めます。

矛盾する記憶の無効化と有効期限による鮮度担保の運用ルール設計

記憶の誤りは「間違った情報が入る」より「正しかった情報が古くなる」形で入ります。担当者の交代、料金プランの変更、方針の転換。どれも過去のある時点までは正しい事実でした。Zepが採用する、事実が無効になった時刻をエッジに保存する設計はこの問題への直接的な回答です。自前実装でも、レコードにvalid_atとinvalid_atの2列を持たせ、検索時に有効な事実だけを返せば同等の管理ができます。

有効期限の設定も併用してください。Claude APIのメモリツールの公式ドキュメントも、長期間アクセスされていないメモリファイルを定期的に削除する運用を挙げています。参照されない記憶を残す利益はほぼなく、削除要求への対応コストと情報漏えい時の被害だけが増えます。

メモリ保存先の選択肢とスキーマ設計で決まる検索精度と運用コスト

保存先は検索クエリの形から逆算します。「この利用者の言語設定」のようにキーで一意に引ける情報と、「以前この人が困っていた話題」のように曖昧な想起が要る情報では、適した保存先が違います。

ベクトル検索とキーバリューとグラフの使い分けと適合する条件の整理

キーバリューやRDBは、利用者IDと属性名で引ける情報に向きます。検索コストはほぼゼロで、値の更新も単純です。ベクトル検索は語彙が一致しない想起に向きますが、類似度上位を返す性質上、無関係な記憶も一定確率で混ざるため、しきい値と件数上限を設けてください。グラフは、エンティティ間の関係と事実の有効期間を扱う場合に効きます。

実務では3つを併用する構成が多くなります。分担はプロファイルがRDB、会話由来の事実がベクトル、案件の関係がグラフです。1つの保存先で全部を賄おうとすると、どこかで検索精度か更新コストが破綻します。

名前空間とメタデータのスキーマで担保するテナント分離と監査の設計

スキーマの最小構成は、名前空間（テナントID・利用者ID・エージェント種別）と、レコードのメタデータ（出所、生成時刻、有効期間、確度、参照元の会話ID）です。マルチテナントでは、検索時のフィルタではなく名前空間そのものでテナントを分離してください。フィルタ漏れは他社データの露出に直結します。

出所と会話IDを残しておくと、誤った記憶が見つかったときに、どの発話から生成されたかを追跡できます。監査要件のある案件では、この追跡可能性が導入可否を分ける条件になります。

検索呼び出し回数と埋め込み費用から見た運用コストの見積もり手順

コストは「毎ターンの検索回数×検索1回のトークン量」と「書き込み時の抽出処理の推論コスト」で決まります。Mem0が公表する検索1回あたり平均6,956トークンと全文投入型の25,000超という対比は、記憶を取り出す設計が入力トークンの削減につながることを示しています。ただし書き込み側では抽出のためのLLM呼び出しが増えるため、総額は「読み出しの削減分から書き込みの追加分を引いた値」で評価してください。

記憶検索を全ターンで走らせる必要はありません。指示語や過去参照を含むターンだけに絞る設計なら、検索回数を半分以下に抑えられます。

エージェントメモリを採用しない条件と実装で踏む失敗パターンの実例

ここは判断を言い切ります。長期記憶は、入れれば賢くなる機能ではありません。以下の条件では採用しない方が、精度も保守性も上がります。

単発完結タスクに長期記憶を足して精度が落ちる典型パターンと兆候

1回の質問で完結する社内FAQ、規程検索、コード生成の単発依頼。これらに長期記憶を足すと、前回の別案件の文脈が回答に混ざります。実際に起きるのは「前は別の書き方を提案していたので、それに寄せる」という不要な引きずりです。1セッションで完結する要件なら短期記憶だけで十分で、長期記憶は見送ってください。

役割ごとに記憶を共有すべきか分離すべきかは、シングルエージェントとマルチエージェントの使い分けの判断基準と合わせて決めると整理しやすくなります。

長期記憶への汚染注入と権限分離を怠ったときの被害範囲と対策の型

長期記憶は、攻撃者から見れば「一度書き込めば以後ずっと参照される領域」です。外部から取り込んだ文書や利用者入力をそのまま記憶へ書く実装は、埋め込まれた指示で以後の判断を歪められます。攻撃の型と防御はメモリポイズニングの脅威と防御策の解説で扱っています。

実装側の対策は3点です。書き込み経路に検証を挟み、外部由来のテキストを事実として昇格させない。読み取り権限を利用者・テナント単位で分離する。監査ログを残し、異常なレコードを遡って削除できるようにする。この3点が揃わない状態での本番投入は避けてください。

個人情報を含む記憶の保存先の選択と削除要求への対応の設計条件

記憶には利用者の属性や業務上の機微情報が入ります。保存先をベンダー側に置くか自社に置くかは、契約と規程で先に確定させてください。Claude APIのメモリツールがクライアントサイドで動作する設計なら、保存も削除も自社の管理下で完結します。

削除要求への対応は、名前空間の設計と直結します。利用者IDで名前空間を切っていれば、その配下を削除するだけで完了します。全レコードにフィルタをかけて探す構成では、埋め込みベクトルの残存や要約への混入まで追い切れません。要約に個人情報が溶け込むと、元レコードを消しても情報が残るため、要約対象から個人情報を除外する処理をパイプライン側に置いてください。

内製と外部基盤の判断基準と受託開発で切り分ける実装範囲の線引き

内製が向くのは、記憶の判定基準が業務固有で、外部の汎用抽出では拾えない場合です。「見積条件の変更履歴だけを記憶する」といった要件は、自前のスキーマとルールで書いた方が短く済みます。外部基盤が向くのは、対話から嗜好や属性を継続的に拾う汎用的な用途です。

判断が割れるのは、記憶の設計と業務要件の翻訳が要る局面です。当社では業務要件からメモリのスキーマと保持ルールを設計し、既存システムと接続するところまでをAIエージェント開発として請けています。エージェント自体の位置づけから整理したい場合は、AIエージェントの仕組みと業務への組み込み判断を先に確認してください。

エージェントメモリの段階導入の進め方と効果測定で置く指標の設計

いきなり長期記憶を全面導入せず、短期記憶の永続化から始めて効果を測る順序が安全です。指標を決めずに入れると、記憶が効いているのか判別できません。

短期記憶の永続化から長期記憶へ段階的に広げる4段階の導入手順

1. セッション内履歴の永続化だけを入れ、再開時の文脈復元を確認する
2. 要約による履歴圧縮を足し、長い対話でのトークン量を測る
3. 利用者プロファイル（セマンティック記憶）を追加し、抽出の精度を人手で検証する
4. エピソード記憶と手続き記憶を足し、無効化と有効期限の運用を回す

各段階で止まれる構成にしておけば、費用対効果が合わない時点で打ち切れます。指標は3つに絞ります。再質問率（同じ情報を再入力した割合）、1対話あたりの入力トークン量、誤った記憶の混入率です。3つ目を月次50件程度のサンプル検査で見ない運用は、古い事実を自信を持って語る状態に気づけません。

よくある質問

エージェントメモリの実装で問い合わせの多い論点をまとめました。

エージェントメモリとRAGはどちらを先に実装すべきですか？

社内文書や商品情報など、既に存在する知識を引かせたいならRAGが先です。エージェントメモリは対話や作業の中で新しく生まれた情報を残す仕組みなので、何を残す価値があるかを運用しながら見極める必要があります。RAGで基礎的な回答品質を確保し、そのうえで利用者ごとの文脈を足す順序が、手戻りの少ない進め方です。

短期記憶だけで運用する場合、どこまでの体験を実現できますか？

同一セッション内での文脈保持と、中断した会話の再開までは実現できます。OpenAI Agents SDKのSessionsのように履歴をSQLiteやRedisへ永続化すれば、翌日に同じ会話の続きから再開させることも可能です。実現できないのは、別のスレッドで前回の嗜好を引き継ぐ体験で、これには長期記憶の抽出処理が要ります。

記憶が増えすぎて検索が当たらなくなる問題はどう防ぎますか？

書き込み前の重複排除と、検索時のしきい値・件数上限の2段構えで防ぎます。書き込み時は既存記憶を検索して意味が重なるレコードを更新に倒し、同じ事実の言い換えを増やさないこと。検索時は類似度のしきい値を設け、返す件数を5件程度に制限します。参照されない記憶に有効期限を設けて定期削除すれば、長期運用でも検索品質を保てます。

Mem0やZepのベンチマーク数値はそのまま信用してよいですか？

ベンダーが公表する数値は、自社の評価条件で測られたものです。Mem0のLoCoMo 92.5や検索1回あたり平均6,956トークンという値も、その条件下での結果として読むべきです。判断に使うなら、自社の会話データから50件から100件の評価セットを作り、記憶ありとなしで再質問率と誤り率を比較してください。データの性質が違えば順位は入れ替わります。

個人情報を含む記憶はどこに保存するのが安全ですか？

削除要求と監査に自社で応えられる場所、つまり自社が管理するデータベースやストレージに置く構成が安全です。Claude APIのメモリツールはクライアントサイドで動作し、ファイルの実体を自社インフラに置けます。利用者IDで名前空間を分離し、要約処理の対象から個人情報を除外しておけば、削除要求のときに残存を追い切れます。

関連記事

• コンテキストの構成要素と圧縮の実装：コンテキスト窓そのものを縮める手法
• エージェンティックRAGとは何か：外部知識の検索側の設計
• メモリポイズニングとは：長期記憶を狙う攻撃と書き込み経路の防御
• KVキャッシュとは：推論側のメモリ削減という別の層の話
• シングルエージェントとマルチエージェントの違い：記憶を共有するか分離するかの判断材料