AIエージェントの長期記憶（メモリ）設計 — 永続メモリ・メモリストア・検索の実装ガイド

AIエージェントのメモリ（記憶）とは、単発の推論で完結させず、タスクやセッションをまたいで情報を保持し、のちの判断に再利用する仕組みである。チャットの会話履歴を超えて「前回ユーザーが何を依頼し、どんな制約を示したか」を覚えておくことで、エージェントは長時間タスクや反復業務を安定してこなせるようになる。

本記事は、自律的に動くAIエージェントを設計・運用するエンジニアやプロダクト担当者に向けて、永続メモリ（長期記憶）の設計手順を実装目線でまとめたものだ。メモリストアの選び方、書き込み・検索・更新のフロー、記憶の陳腐化やメモリ汚染への対策、マルチエージェントでの共有設計までを扱う。なお、1回の推論に何を詰め込むかというコンテキストエンジニアリングの設計は別記事に譲り、本記事はセッションを越えて残す「永続層」に集中する。

メモリとは「セッションをまたいで残す情報」、コンテキストとは「1回の推論にその場で渡す情報」だ。 この2つを混同すると、本来は永続化すべき情報を毎回プロンプトに詰め込んだり、逆に一時的な情報を不要に保存し続けたりする。まずは両者の境界と、メモリの基本的な3分類を整理する。

エージェントにメモリが要るのは、処理が「1回の問いと答え」で閉じないときだ。代表的なのは次の3つの場面である。

第一に、長時間タスク。調査・コード生成・複数ステップの業務処理のように、途中で得た中間結果や決定事項を後段で参照する必要がある作業では、直前までの判断を保持できないと同じ調査をやり直したり、矛盾した出力を返したりする。

第二に、マルチセッション。同じユーザーが日をまたいで何度も対話する業務アシスタントでは、「前回の依頼内容」「相手の役職や好み」「進行中の案件」を覚えていないと、毎回ゼロから説明させることになり実用に耐えない。

第三に、反復・学習。過去の失敗やユーザーからの訂正を記録し、次回以降の振る舞いに反映するケースだ。たとえば「この相手には英語ではなく日本語で返す」といった訂正を一度受けたら、それを永続化して再発を防ぐ。

逆に言えば、単発のQ&Aや一問一答のFAQボットのように状態を持ち越す必要がない用途では、無理にメモリ層を作らないほうが構成はシンプルになる。

メモリとコンテキストは、しばしば同じものとして語られるが、設計上は層が違う。コンテキストは「今回の推論でモデルに渡す入力一式」であり、プロンプト・取得した外部知識・ツール定義・直近の会話などをその場で組み立てる。一方メモリは「次回以降のために外部ストレージへ残す情報」だ。

両者の関係は、メモリが供給源、コンテキストが消費側、と捉えると整理しやすい。長期記憶に保存した情報のうち、今回の作業に関係するものだけを検索して取り出し、コンテキストに載せる。つまりメモリは「いつ・何を・どこに残すか」、コンテキストは「今・何を・どれだけ渡すか」を扱う。

本記事は前者、すなわち永続層の設計に集中する。1回の推論にどれだけ載せるか、どう圧縮・整形するかというコンテキストエンジニアリングの論点（コンテキストウィンドウの構成やコンテキスト圧縮の手法）は、そちらの記事に委ねる。役割を分けて設計すると、「保存はするが毎回は読み込まない」「読み込むが保存はしない」といった判断が明確になる。

エージェントのメモリは、保持期間と用途によって3つに分けると設計しやすい。

短期記憶（会話履歴） は、進行中のセッション内で参照する直近のやり取りだ。多くは推論ごとにコンテキストへ展開され、セッションが終われば破棄するか、要約だけを長期記憶へ昇格させる。

長期記憶（永続メモリ） は、セッションをまたいで残す情報だ。ユーザーの属性、過去の決定、繰り返し使う知識などを外部ストレージに保存し、必要なときだけ検索して取り出す。本記事の主対象はここである。

作業記憶（ワーキングメモリ） は、1つのタスクを遂行する間だけ保持するスクラッチ領域だ。計画の途中状態、ツール実行の中間結果、未確定の仮説などを置き、タスクが完了すれば破棄する。

この3層を分けないと、「一時的な中間結果を永続化してストアを汚す」「永続すべき決定を会話履歴に置いてセッション終了で失う」といった事故が起きる。まず情報ごとにどの層に属するかを決めることが、メモリ設計の出発点になる。

メモリ設計でまず決めるのは「何を残し、何を捨てるか」だ。 すべてを保存すると検索精度が落ち、コストとプライバシーのリスクが膨らむ。記憶対象の選別基準と、保持期間・個人データ保護の観点を先に固めておく。

記憶対象は「後で再利用される見込みが高く、再取得が難しい情報」に絞るのが基本だ。判断の軸は次のようになる。

• 再利用性: 同じユーザー・同じ業務で繰り返し参照されるか。一度きりの情報は残さない。
• 再取得コスト: 外部システムやデータベースから都度引き直せる情報（最新の在庫数、価格など）は、メモリに固定化せず取得元を正とする。固定化すると陳腐化する。
• 決定・訂正の記録: ユーザーの好み、確定した仕様、過去の訂正など「合意の結果」は再現が難しいので残す価値が高い。
• 要約可能性: 長い経緯は生ログのまま保存せず、要点を要約して保存するとノイズと容量を抑えられる。

避けたいのは「念のため全部保存」だ。保存量が増えるほど検索ノイズが増え、関連度の低い記憶が引き出されて出力品質を下げる。最新値が必要なデータはメモリではなくRAGやAPI取得で都度参照し、メモリには「変わりにくい事実」と「合意の結果」を置く、という棲み分けが扱いやすい。

メモリは個人データを抱え込みやすい。ユーザーの氏名・連絡先・業務上の機微情報を長期記憶に保存する場合、タイの個人データ保護法（PDPA）をはじめとする各国の規制では、利用目的の明確化・保存期間の限定・削除請求への対応が求められる。

設計上は次を組み込んでおく。

• 保持期間（TTL）: 記憶ごとに有効期限を持たせ、期限切れを自動で失効させる。無期限保存をデフォルトにしない。
• 削除の経路: 特定ユーザーの記憶を一括削除できるよう、スコープ（後述）に紐づけて保存する。削除請求に応えられない設計は規制リスクになる。
• 最小化: 目的に不要な属性は最初から保存しない。機微情報はマスキングや参照IDでの代替を検討する。

「便利だから覚えておく」と「保存してよいか」は別問題だ。とくに越境でデータを扱う構成では、保存先リージョンと移転の可否も設計段階で確認しておきたい。

永続メモリは「ストア選定 → 書き込み・検索・更新フロー → 鮮度管理」の3ステップで設計する。 どのストアに、いつ書き、どう取り出し、いつ捨てるかを順に決めていく。ここからが本記事の中心となる実装パートだ。

最初の判断は、記憶をどこに置くかだ。用途によって適したストアが異なる。

ベクトルデータベース: 「意味が近い記憶」を検索したいときに使う。記憶をエンベディング化してベクトルデータベースに格納し、問い合わせ時に類似度検索で関連記憶を引き出す。自由文の経緯やナレッジを「曖昧な手がかり」で探す用途に向く。

キーバリューストア（KVS）: 「ユーザーIDごとの設定」「案件IDごとの状態」のように、キーが確定していて完全一致で引ける情報に向く。低レイテンシで、構造が単純なメモリの保存先として扱いやすい。

リレーショナル / ドキュメントDB: 関係性や絞り込み条件が複雑な記憶（履歴の条件検索、集計）に向く。

実務では単一ストアに寄せず、組み合わせるのが現実的だ。たとえば「ユーザー属性はKVS、過去の経緯はベクトルDB」と役割分担する。検索の主目的が完全一致なのか意味的類似なのかを見極めると、過剰にベクトルDBを使ってコストと複雑さを上げる失敗を避けられる。

ストアを決めたら、ライフサイクルを定義する。

書き込み（いつ残すか）: 毎発話で保存するとノイズが増える。タスク完了時、ユーザーが訂正・確定したとき、明確なイベント（契約成立、設定変更）が起きたときなど、保存タイミングを限定する。保存時には出典（誰の発話か、どのツール出力か）と作成時刻を必ず添える。

検索（どう取り出すか）: 関連度だけで取り出すと古い記憶が混ざる。意味的な類似度に加えて、新しさ（recency）とスコープ一致（同じユーザー・案件か）で重み付けし、上位数件に絞る。取り出した記憶はそのまま信用せず、現在の文脈と矛盾しないか確認したうえでコンテキストに載せる。

更新（どう書き換えるか）: 同じ事実が更新されたら、新規追加ではなく既存記憶を上書き（upsert）し、古い値を残さない。重複記憶はマージし、矛盾する記憶は新しい方を優先するなど、競合解決のルールを決めておく。これを怠ると「古い住所と新しい住所が両方ヒットする」状態になる。

記憶は放っておくと古くなる。鮮度を保つ仕組みを最初から入れておく。

• TTLと失効: 記憶ごとに有効期限を設定し、期限切れは検索対象から外す。期限は情報の性質で変える（連絡先は長め、進行中案件の状態は短め）。
• 更新時刻での重み付け: 検索時に新しい記憶を優先し、古い記憶のスコアを減衰させる。
• 再確認のトリガー: 重要な記憶は、参照時に「この情報はまだ有効か」を現在のデータ源と突き合わせる。とくに在庫・価格・担当者のように変わりやすい値は、メモリを手がかりにしつつ最新値は取得元で確認する。
• 棚卸し: 参照されない記憶や重複を定期的に整理する。

陳腐化対策の要点は「メモリを唯一の正としない」ことだ。変わりやすい事実はメモリに固定化せず、変わりにくい事実と合意の結果だけを長く持つ。この切り分けが、古い記憶による誤った出力を防ぐ。

セッションをまたいで対話を続けるには、会話の要点を「どの層に・どの粒度で」残すかを決める必要がある。 会話要約をコンテキスト層に置くか永続層に昇格させるか、そして記憶を誰の単位で区切るかを設計する。

長い会話をそのまま全部保存すると、容量も検索ノイズも増える。実務では「セッション中の直近のやり取りは短期記憶（コンテキスト層）で扱い、セッションをまたいで残す価値がある要点だけを要約して長期記憶へ昇格させる」分担が扱いやすい。

具体的には、セッション終了時または一定の区切りで会話を要約し、「確定した依頼内容」「相手の制約や好み」「次回への申し送り」を抽出して永続メモリに保存する。生ログ全文ではなく要約を残すことで、次回セッションの冒頭で「前回の文脈」を少量のトークンで復元できる。

ここで、要約をどう作りどうコンテキストへ展開するかという整形・圧縮の手法はコンテキストエンジニアリングの領域だ。本記事の関心は「要約を永続層に残すか否か」「残すなら誰の単位で紐づけるか」という保存判断にある。両者を分けて考えると、会話履歴のふくらみを抑えつつ継続性を保てる。

記憶は必ず「誰の・どの範囲の記憶か」というスコープに紐づけて保存する。スコープを切らないと、別ユーザーの記憶が混ざる事故や、削除請求に応えられない事態を招く。

代表的なスコープは次の階層だ。

• ユーザー単位: 個人の好み・属性・過去の依頼。本人のセッションでのみ参照する。
• 組織（テナント）単位: 同じ企業・チームで共有する知識やルール。マルチテナント構成では、テナント間で記憶が漏れない分離が必須になる。
• セッション単位: そのセッション限りの作業記憶。終了時に破棄または昇格。

スコープをキーに含めて保存しておくと、検索時に「このユーザー かつ このテナント」の記憶だけを引け、削除も範囲指定で一括実行できる。とくに複数企業に同じエージェントを提供する場合、テナント分離はセキュリティの根幹であり、メモリ層でも徹底する。

メモリ運用の事故は「汚れた記憶を信じる」ことから起きる。 外部から注入された不正な記憶（メモリポイズニング）と、関連度の低い記憶のノイズ混入が二大要因だ。それぞれの兆候と対策を押さえる。

メモリポイズニングとは、悪意ある入力やツール出力を通じて、エージェントの長期記憶に誤った情報や不正な指示を書き込ませる攻撃だ。汚染された記憶は次回以降のセッションで引き出され、エージェントの判断を継続的に歪める。永続層は「一度書かれると長く効く」ため、その場限りのプロンプト注入より影響が深刻になりうる。

防御の基本は「保存する前に検証し、読み出すときに鵜呑みにしない」ことだ。

• 出典の記録（provenance）: すべての記憶に「誰の・どの経路の情報か」を付与する。ユーザー入力やツール出力をそのまま事実として保存しない。
• 書き込みの検証: 記憶として保存する内容に、指示文（「今後は必ず〜せよ」）や外部リンク・コードが紛れていないか検査し、疑わしいものは隔離する。
• 読み出し時の不信: 取り出した記憶を「ユーザーが言ったこと」として扱い、「システムの指示」として扱わない。記憶の中の命令文をそのまま実行しない。
• 権限分離: 記憶の書き込み権限を、信頼できる経路に限定する。

汚染は「いつの間にか効いている」のが怖い。保存・読み出しの両端で検証する二重化が要点になる。

汚染ほど派手ではないが、より頻繁に品質を下げるのが「無関係な記憶の混入」だ。類似度検索は、語面が似ているだけで文脈の違う記憶を引いてくることがある。たとえば別案件の決定事項が現在の案件に混ざると、もっともらしい誤りが生まれる。

対策は検索精度の設計に集約される。

• スコープで先に絞る: 意味検索の前に、ユーザー・テナント・案件で対象を限定する。
• しきい値を設ける: 類似度が一定未満の記憶は取り出さない。「ヒットしないこと」を許容する。
• 件数を絞る: 上位数件に限定し、関連度の低い記憶でコンテキストを埋めない。
• 新しさで重み付け: 古い記憶のスコアを下げ、最新の合意を優先する。

Agentic RAGのように、エージェント自身が「この記憶を使うべきか」を判断するステップを挟むと、無関係な記憶の影響をさらに抑えられる。記憶は多く引くほど良いのではなく、関連するものだけを少なく正確に引くのが要点だ。

複数のエージェントが協調する構成では、記憶を「共有するか分離するか」の線引きが設計の核になる。 共有しすぎれば干渉と漏洩、分離しすぎれば連携不足が起きる。

マルチエージェント構成では、エージェント間でどの記憶を共有し、どれを各自に閉じるかを決める。

共有メモリ: 共通の目標・確定した事実・全体の進行状況など、チーム全員が同じ前提で動くべき情報を置く。共有することで重複作業や矛盾した判断を防げる。一方で、誰でも書ける共有領域は汚染の影響範囲も広いため、書き込み権限と検証を強める必要がある。

分離メモリ: 各エージェントの作業途中の仮説やスクラッチは、本人に閉じておく。未確定の中間結果を共有すると、他のエージェントが誤った前提で動き出す。

設計の指針は「確定情報は共有、未確定情報は分離」だ。加えて、共有メモリには名前空間（namespace）を切り、どのエージェントが書いたかを記録しておくと、問題が起きたときに追跡できる。マルチテナントと同様、ここでも「誰が書き・誰が読めるか」のアクセス制御を明示することが、協調と安全性の両立につながる。

Q. メモリとRAGはどう違いますか？ RAGは外部の知識ベースから関連文書を検索してコンテキストに載せる仕組みで、主に「変わりにくい知識」を参照するために使う。メモリはエージェント自身が経験した「ユーザー固有の経緯や決定」を残す層だ。実装手段（ベクトル検索など）は重なるが、RAGは知識の参照、メモリは経験の蓄積という目的の違いがある。両者は併用するのが一般的だ。

Q. メモリは必ず実装すべきですか？ いいえ。単発のQ&Aや、状態を持ち越さない用途では、メモリ層を作らないほうが構成はシンプルで安全だ。長時間タスク・マルチセッション・反復学習のいずれかが必要になったときに導入を検討するのがよい。

Q. 会話履歴を全部保存すれば長期記憶になりますか？ ならない。生ログの全量保存は検索ノイズ・容量・プライバシーのリスクを増やす。残すべきは「合意の結果」と「変わりにくい事実」の要約であり、一時的な中間結果や都度取得できるデータは保存対象から外す。

Q. 保存した記憶が古くなったらどうしますか？ TTL（有効期限）で失効させ、検索時は新しさで重み付けする。在庫や価格のように変わりやすい値はメモリを唯一の正とせず、最新値は取得元で確認する設計にしておく。

AIエージェントのメモリ設計は、「セッションをまたいで残す永続層」を、コンテキスト設計とは別の層として扱うところから始まる。要点を振り返る。

• メモリ（残す）とコンテキスト（その場で渡す）を分け、短期・長期・作業記憶の3層で情報を仕分ける。
• 残すのは「再利用性が高く再取得が難しい情報」、すなわち合意の結果と変わりにくい事実に絞る。保持期間と個人データ保護を前提に組み込む。
• 永続メモリは、ストア選定 → 書き込み・検索・更新フロー → 鮮度管理の順で設計し、検索はスコープと新しさで絞る。
• メモリポイズニングと無関係な記憶の混入を、保存時の検証と読み出し時の不信で防ぐ。
• マルチエージェントでは「確定情報は共有、未確定情報は分離」を指針にアクセス制御を明示する。

メモリは「多く覚えるほど賢くなる」ものではなく、「必要なものを正確に残し、正確に引く」ことで初めて長時間タスクを安定させる。自律エージェントの本番運用を見据えるなら、メモリ層の設計はコンテキスト設計と並ぶ中心的な検討事項になる。