AIエージェントのメモリ設計｜短期記憶と長期記憶の実装パターン

AIエージェントのメモリとは｜ステートレスなLLMに記憶を持たせる仕組み

結論から言えば、APIで呼び出すLLMモデル自体は、前回のリクエスト内容を自動では保持しません。毎回独立したリクエストとして扱われるのが既定の挙動です。記憶があるように見えるアプリは、アプリ側が過去の情報を毎回詰め直しています。

なお、ChatGPTやClaudeなどのプロダクトとして提供されているメモリ機能は、サービス側がこの詰め直しを代行しているものです。自分でエージェントを実装する場合は、その層を自前で作ることになります。

つまりメモリ設計とは、「何を保存し、次のリクエストで何を読み戻すか」を決める作業です。モデルの能力ではなく、アプリケーション側のデータ設計の問題として扱うと見通しが良くなります。

短期記憶と長期記憶の違い

両者は保存先・寿命・参照範囲のすべてが違います。

混ぜると事故が起きます。会話の雑談まで長期記憶に入ると、次のセッションで無関係な前提として復活します。

長期記憶の3分類

メモリの分類はフレームワークや論文ごとに異なりますが、たとえばLangChainの公式ドキュメントでは、長期記憶を人間の記憶になぞらえて次の3つに整理しています。分類を意識すると「どのストアに入れるか」が決めやすくなります。

• 意味記憶（semantic）：事実や概念。ユーザーの所属・好み・用語定義など。パーソナライズの中心

• エピソード記憶（episodic）：過去に起きた出来事や、うまくいった対応の実例。few-shotの例として引き戻す使い方が相性が良い

• 手続き記憶（procedural）：タスクの進め方のルール。多くの実装ではシステムプロンプト側に反映する

詳細な定義はLangChain公式のMemory概説が一次情報になります。

コンテキスト設計との棲み分け

この記事が扱うのは、記憶を「どこに保存し、どう引き戻すか」です。引き戻した情報をコンテキストウィンドウの中でどう配置し、どの順で圧縮するかという組み立ての話は範囲外とし、コンテキストエンジニアリングとは｜プロンプトとの違いと実務に委ねます。

同じく、エージェントがツールを実行してよいかどうかの認可設計はAIエージェントの権限設計｜最小権限とHuman-in-the-loopの実装の担当です。記憶の読み書き自体に権限を効かせたい場合は、そちらと組み合わせてください。

エージェントの基礎概念から確認したい場合はAIエージェントとは？仕組み・種類・活用事例をわかりやすく解説が入り口になります。

ミニFAQ：RAGと長期記憶は何が違うのですか

RAGは「あらかじめ用意した文書」を検索して渡す仕組みで、情報源は基本的に不変です。長期記憶は「対話の中で生まれた情報」を書き足していく仕組みで、書き込みと無効化が必要になります。検索技術は共通でも、書き込み側の設計が別物です。

短期記憶の実装パターン4つ｜会話履歴をどう持つか

短期記憶の設計は、会話が長引いたときにコンテキストとコストをどう抑えるかという一点に集約されます。階層要約や状態マシン型など他の方式もありますが、実務でよく使う基本パターンは次の4つに整理できます。

全履歴保持

毎回すべての発言を渡す方式です。実装は最も単純で、短い問い合わせ対応なら十分に機能します。

弱点は明白で、ターン数に比例してトークンが増えます。会話が伸びるほど1リクエストあたりの入力が膨らみ、レイテンシも料金も上がる。プロトタイプ以外で採用し続けるのは難しい方式です。

直近Nターン・トークン上限でのトリミング

古い発言から順に捨て、直近だけを残します。実装が軽く、コストの上限も読みやすい。最初に選ぶ方式としては無難です。

一般的なチャット型UIの初期検証であれば、直近10〜20ターン、あるいは入力トークンの上限を決めて収まるまで削る、といった置き方から始めて、自分のログで調整するのが現実的です。この数字は検証の出発点として置きやすい範囲というだけで、普遍的な正解ではありません。1ターンあたりの発言長、ツール実行結果の量、使うモデルのコンテキスト長で適正値は大きく変わります。

注意点として、ツール実行の往復はトリミングで壊れやすい。ツール呼び出しとその結果が対で揃っていないとエラーになるモデルがあるため、対を崩さない単位で削る必要があります。

逐次要約

古い履歴を要約文に畳み、要約＋直近の発言だけを渡します。長い会話でも入力量が一定の範囲に収まるのが利点です。

要約のタイミングは、毎ターンではなく数往復ごとにまとめる方が効率が良くなります。要約自体がLLM呼び出しなので、頻度を上げるとコストが戻ってきます。

弱点は情報の欠落です。要約で落ちた細部は二度と戻りません。日付・金額・固有名詞など、後で参照される可能性が高い要素は要約プロンプト側で明示的に残すよう指示しておきます。

要約＋生ログ併用

要約をコンテキストに載せつつ、生ログは別途保存しておき、必要になったら検索して呼び戻す方式です。長期運用するエージェントの事例や各フレームワークのドキュメントで、採用例が見られる構成です。

実装コストは上がりますが、要約の欠落を検索で補えるのが強みになります。MemGPTの論文が提示したOS的な発想、つまり「主記憶に載らないものは外部に退避し、必要時に読み戻す」という考え方がこのパターンの原型にあたります。

4方式の比較

順番としては、トリミングで始めて、落ちた情報が業務上問題になった時点で要約や併用方式へ移るのが無駄が少ない進め方です。最初から併用方式を作り込むと、使われない検索基盤の保守だけが残ります。

長期記憶の実装パターン｜何を書き、いつ書き、どう引くか

長期記憶の設計は、検索側よりも書き込み側の影響が大きくなりやすい領域です。保存するレコードの質が低いと、後段の検索をどれだけ作り込んでも精度が頭打ちになります。

何を書くか｜生ログ・要約・事実抽出

生の会話をそのまま長期記憶に入れるのは避けます。ノイズが多く、同じ話題が重複し、矛盾が同居するためです。

実務では次の2つが使われます。

• 要約方式：会話の塊を短い要旨に畳んで保存する。実装が軽く、文脈は保たれるが、検索時に粒度が粗い

• 事実抽出方式：会話から再利用しやすい単位の事実を取り出し、構造化して保存する。「ユーザーの所属はA社」「連絡手段はメールを希望」のように1レコード1事実へ正規化する

パーソナライズ用途では事実抽出の方が扱いやすくなります。粒度が揃うため、重複排除と上書きが機械的にできるからです。Mem0のようなメモリ専用のレイヤーは、この事実抽出を担う位置づけで提供されています。

書き込み前に重複排除と矛盾チェックを挟むことが、長期記憶の品質をほぼ決めます。既存レコードと同じ主語の事実が来たら、追加ではなく更新として扱う設計にしておきます。

いつ書くか｜ホットパスとバックグラウンド

書き込みの実行タイミングは2通りあります。

ホットパスは、応答を返す流れの中で記憶を書く方式です。即座に反映される一方、LLM呼び出しが1回増えるぶん応答が遅くなります。チャットUIでは体感差が出やすい部分です。

バックグラウンドは、応答を返したあとに非同期で書き込む方式です。ユーザー体感を損なわずに済み、まとめて処理できるのでコスト効率も良くなります。ただし「さっき伝えたことが次のターンで反映されていない」という挙動が起きます。

判断基準はシンプルで、その記憶が直後のターンで必要かどうかです。「私の名前はAです」のような即時反映が期待される情報はホットパス、長期的な嗜好の学習はバックグラウンドに回す、という使い分けが現実的です。

どう引くか｜検索方式の選択

長期記憶の検索は、RAGの検索技術がそのまま使えます。

ベクトル検索は表現の揺れに強い一方、固有名詞や型番の完全一致に弱い傾向があります。キーワード検索と組み合わせる構成が安定しやすく、考え方はハイブリッド検索とは｜BM25とベクトル検索をRRFで統合する方法にまとめています。候補を絞ったあとの精度はリランキング（Rerank）とは｜RAGの検索精度を上げる仕組みと実装が効きます。

保存先の選定はベクトルDBの選び方｜Pinecone・Weaviate・Qdrant・pgvectorの使い分けを参照してください。ユーザーごとの事実を貯める用途では、RAGの文書コーパスに比べてレコード件数が小さく収まるケースもあり、その場合は既存のPostgreSQLにpgvectorを足す構成で足りることがあります。規模はサービスの性質で大きく変わるため、専用のベクトルDBを立てる前に件数とレイテンシ要件を見積もっておくと無駄が減ります。

事実どうしの関係を辿りたい場合は知識グラフ型という選択肢もあります。Zepが採用している時間軸つきの知識グラフは、「いつ時点で何が正しかったか」を保持できるのが特徴です。考え方はGraphRAGとは｜通常RAGとの違い・仕組み・構築案件の実務が近い領域を扱っています。

スコープと名前空間

長期記憶は誰の記憶かを必ず分離します。LangGraphのstoreは、名前空間（ユーザーIDや組織IDなどのタプル）とキーで階層的に整理する構造になっています。

設計時に決めておく軸は次の3つです。

• ユーザー単位か、組織・テナント単位か、その両方を持つか

• アプリケーションをまたいで共有するか、閉じるか

• 共有記憶に書き込める主体を誰に限るか

テナント境界を越えて記憶が参照できてしまう構成は、情報漏洩のリスクとして扱われます。マルチテナントの案件では名前空間の設計をレビュー対象に含め、求められるセキュリティ要件は契約・業界によって変わるため、要件定義の段階で発注側のセキュリティ担当と認識を合わせておくのが安全です。

ミニFAQ：長期記憶は全ターンで検索すべきですか

毎ターン検索すると、無関係な記憶が混入して回答を歪める副作用があります。ユーザー発話に固有名詞や嗜好の言及が含まれるターンだけ検索する、あるいは検索結果にスコア下限を設けて足切りする方が安定します。

記憶の更新・無効化・忘却の設計

長期記憶は、書く設計より消す設計の方が難しい。ここを省くと、運用を続けるうちに古い前提が溜まり、精度がじわじわ落ちていきます。落ち始める時期はサービスの更新頻度次第ですが、ユーザーの状況が変わりやすいサービスほど早く顕在化します。

矛盾する記憶の扱い

ユーザーの状況は変わります。「東京在住」が「大阪在住」になったとき、両方が記憶に残っていると、エージェントはどちらかをランダムに引きます。

対策は、事実に主語と属性のキーを持たせ、同じキーの新しい事実が来たら旧レコードを無効化することです。削除ではなく無効フラグと更新日時で持っておくと、誤更新時に戻せます。

更新日時を記憶レコードに必ず持たせておくと、検索結果が競合したときに新しい方を優先する単純なルールで大半を捌けます。

鮮度と有効期限

すべての記憶が永続して良いわけではありません。変化が緩やかな属性（取得済みの資格、母語）と、揮発性の高い情報（進行中の案件、今週の予定、所属先）では寿命が違います。勤務先や居住地のように「変わらなそうで変わる」属性は、恒久扱いにせず更新を前提に持たせておくと事故が減ります。

記憶の種別ごとにTTLを設定し、期限切れは検索対象から外す設計にしておきます。Anthropicのmemory toolのドキュメントでも、長期間アクセスされていないメモリファイルを定期的に削除することが運用上の注意点として挙げられています。

削除要求への対応

個人に紐づく情報を長期記憶に保存する以上、削除要求に応えられる構造が要ります。ユーザーIDで名前空間を切っておけば、該当名前空間ごと削除する操作で対応しやすくなります。

技術的に見落としやすいのは、ベクトルインデックスに埋め込みのコピーが残る構成です。元レコードを消してもインデックス側に残ることがあるため、削除フローの検証はインデックスとバックアップまで含めて行ってください。

なお、どこまでの対応が義務になるかは、扱うデータの種類と適用される法令で変わります。個人情報保護法やGDPRなどの要件が関わる場合、保存範囲・保存期間・削除手順の設計は、自己判断せず法務担当や専門家の確認を通す前提で進めてください。この記事で扱うのは、要件が決まったあとにそれを実装で満たすための構造です。

フレームワーク別の実装の入り口

主要なフレームワークは、短期記憶と長期記憶を別の仕組みとして提供しています。対応関係を押さえると移植も読み替えも早くなります。

以下は本記事の執筆時点（2026年10月）に各公式ドキュメントで確認できた内容です。この領域は更新が速く、名称や提供形態が変わることがあります。採用前に必ず公式ドキュメントの最新版を確認してください。

LangGraph

checkpointerとstoreは完全に別の仕組みです。スレッドIDで短期記憶を区切り、名前空間で長期記憶を区切る、という二重の仕切りになっています。1ターンの流れは、スレッドの状態を読み込み、そのユーザーの長期記憶を検索し、両方からプロンプトを組み立てて応答する、という形に落ち着きます。

LangGraph自体の基礎はLangGraphとは｜LangChainとの違い・エージェント構築の基本、フレームワークの選定軸はAIエージェント開発フレームワーク比較｜LangGraph・CrewAI・AutoGenにまとめています。

OpenAI Agents SDK

Sessionsを使うと、実行前に過去の履歴を自動で取得して入力の先頭に付け、実行後に新しい項目を保存します。履歴を手で詰め替えるコードが不要になるのが利点です。

バックエンドは執筆時点で複数用意されており、ローカル検証向けのSQLiteSession、本番向けのSQLAlchemySession、ワーカー間で共有するRedisSessionなどが選べます。実装名は変わる可能性があるため、最新の選択肢は公式ドキュメントで確認してください。

仕様面で取り違えやすいのは、公式ドキュメントがセッションIDは会話の識別子であって認証・認可の手段ではないと明記している点です。アクセス制御はアプリケーション層の責任になります。一次情報はOpenAI Agents SDKのSessionsドキュメントです。

Claudeのmemory tool

ここで扱うのは、Claudeのプロダクト上のメモリ機能ではなく、Anthropic APIで提供されるmemory toolです。メモリ用ディレクトリに対するファイル操作としてメモリを扱う仕組みになっています。

特徴はクライアント側で動くことです。Claudeはファイル操作を要求するだけで、実際の読み書きは自前のストレージに対して自分で実装します。保存先をデータベースにするか暗号化ファイルにするかは実装側の裁量です。

必要な情報を必要なときだけ読み戻す使い方（just-in-time）が前提になっており、長時間動くエージェントでコンテキストを膨らませないための仕組みとして位置づけられています。サーバー側で会話全体を要約する圧縮機能と組み合わせる構成も案内されています。

実装時の注意として、公式ドキュメントはメモリディレクトリの外に出るパスを必ず弾くことを要件として挙げています。パスの正規化と範囲チェックを省くと、意図しないファイルへ到達される余地が残ります。詳細はAnthropic公式のmemory toolドキュメントを確認してください。

メモリ専用基盤を使うか

専用基盤は、事実抽出・重複排除・検索といった工程を引き受けてくれます。自前で作る工数を減らせるのが利点です。ただし設計思想と担当範囲は製品ごとに異なるため、同じ「メモリ基盤」として一括りにはできません。

• Mem0：会話から事実を抽出し、プロンプト生成時に関連する記憶を返すメモリ層。パーソナライズ用途に寄せた設計

• Letta（MemGPTの後継）：エージェント自身がツール呼び出しで自分の記憶を編集するランタイム。何を覚え何を忘れるかをモデル側に委ねる

• Zep：記憶を時間軸つきの知識グラフとして保持し、「いつ時点で何が正しかったか」を追える構造

ベンダーが公表するベンチマーク比較は、自社構成が有利に出やすい性質があります。採用判断は、自分たちの実データで評価セットを作って再現してからにするのが安全です。評価の考え方はLLM評価（Evals）とは｜LLM-as-a-Judgeと品質保証の実務まで解説が参考になります。

よくある失敗と対策

生ログをそのまま長期記憶に入れる

実装初期に踏みやすい失敗です。重複と矛盾が蓄積し、検索精度が落ちていきます。要約か事実抽出を挟み、保存前に既存レコードとの突き合わせを行ってください。

古い前提が残り続ける

無効化の仕組みが無いまま運用すると、誤った前提を自信を持って答えるエージェントになります。記憶が無い状態より悪い結果になりやすい失敗です。更新日時・有効フラグ・TTLの3点を最初から持たせておきます。誤情報の抑制全般はハルシネーション対策｜LLMの誤回答を減らす実装と運用設計と併せて設計してください。

検索をベクトルだけに頼る

固有名詞・型番・社名の完全一致が必要な場面でベクトル検索だけに頼ると、取りこぼしが出ます。キーワード検索との併用を検討してください。チャンクの粒度が粗すぎる場合も精度が落ちるため、RAGのチャンク分割｜サイズ・オーバーラップの決め方と検証手順の考え方が流用できます。

評価の仕組みを作らずに本番投入する

メモリは変更の影響が見えにくい領域です。要約プロンプトを少し変えただけでも、蓄積された記憶を通じて後々の応答品質に効いてきます。変更直後のテストでは気づきにくいのが厄介な点です。記憶の書き込み・検索を含めたトレースを残すところから始めてください。計測の入り口はLangfuse・LangSmithの使い方｜LLMトレース管理と選び方にまとめています。

ツール実行の対を壊すトリミング

実装時に踏みやすい地雷です。履歴を削る処理がツール呼び出しと結果の対応を崩すと、APIエラーになります。削除の単位をターンではなく「対が揃うブロック」にしておくと回避できます。

メモリ設計チェックリスト

着手前と実装後に通すと、手戻りが減ります。

切り分け

• 短期記憶と長期記憶を別ストアに分けたか

• 長期記憶のレコードが「1事実1レコード」に正規化されているか

書き込み

• 生ログをそのまま保存していないか

• 重複排除と矛盾チェックを書き込み前に通しているか

• ホットパスとバックグラウンドの使い分けを決めたか

読み出し

• 毎ターン検索せず、必要なターンに絞る条件を決めたか

• 検索結果にスコアの足切りを設けたか

• 固有名詞の完全一致が必要な検索をベクトルだけに任せていないか

寿命

• 更新日時と有効フラグをレコードに持たせたか

• 記憶の種別ごとにTTLを決めたか

• 削除要求時に名前空間ごと消せる構造になっているか（インデックス側も含めて）

境界

• テナント・ユーザーをまたいで記憶が漏れない名前空間設計か

• 共有記憶へ書き込める主体を限定したか

運用

• 記憶の書き込みと検索がトレースに残るか

• 要約プロンプト変更時に回帰を確認する評価セットがあるか

フリーランス案件でのメモリ設計

メモリ設計は、単独の募集として立つよりエージェント開発案件の一部として現れることが多い領域です。「社内アシスタントが前回の会話を覚えていない」「会話が長くなるとAPI費用が跳ねる」といった課題から入り、結果として記憶の設計に踏み込む流れになります。

評価されやすいのは、新しいライブラリを知っていることより、コストと精度のトレードオフを自分の環境の数字で説明できることです。トリミングと要約で入力トークンがどう変わるか、書き込みをバックグラウンドに回したときに応答時間がどう動くか。変化の幅はモデル・会話の長さ・保存件数で変わるので、一般論ではなく手元のログから測った値を示せると、設計判断の相談先として扱われます。

RAG構築の経験がある人は、検索側の知識がそのまま効きます。差分は書き込みと無効化の設計なので、そこを埋めるのが最短ルートです。案件の全体像や求められるスキルはAIエージェント開発案件の単価相場｜必要スキル・獲得ルートを解説で整理しています。

自分のスキルセットでどの程度の条件を狙えるか把握したい場合は、無料のフリーランスエンジニア単価診断で市場単価の目安を確認できます。

まとめ

AIエージェントのメモリ設計は、短期記憶をスレッド単位の履歴として持ち、長期記憶を正規化した事実として別ストアに置き、無効化と有効期限をセットで作り込む——この3点に集約されます。

• 短期と長期は保存先・寿命・参照範囲が違う。混ぜない

• 短期の実装はトリミングから始め、情報欠落が問題になってから要約へ移る

• 長期記憶の品質は書き込み側で決まる。要約か事実抽出を挟み、重複と矛盾を潰してから保存する

• 更新日時・有効フラグ・TTLが無い長期記憶は、運用が進むほど精度を落とす

• フレームワークは短期と長期で担当が分かれることが多い。LangGraphのcheckpointerとstoreの関係は、その代表例として理解しやすい

• 採用判断は、ベンダーのベンチマークではなく自前の評価セットで行う

次の一歩としては、いま動いているエージェントの会話ログを10件ほど眺めて、「次のセッションに持ち越すべき事実」を手で抜き出してみてください。その抽出ルールがそのまま長期記憶の書き込み仕様になります。

参照した一次情報は次のとおりです。

• LangChain公式｜Memory overview

• LangChain公式｜Persistence（checkpointer）

• OpenAI Agents SDK｜Sessions

• Anthropic｜Memory tool

• Anthropic｜Effective context engineering for AI agents

• MemGPT: Towards LLMs as Operating Systems（arXiv）

• Mem0（GitHub）

• Letta（GitHub）

• Zep（GitHub）