AI Memoryとは？ 「AIが覚えている」の中身を分解する

会話AIが「前に話したことを覚えている」ように見えるとき、その仕組みをまとめてAI Memoryと呼ぶことがあります。ただし、この言葉は人間の記憶をそのままAIへ移した概念ではありません。多くのシステムでは、過去の会話や重要な事実を外部のstoreへ保存し、必要になったときに検索して現在のpromptへ戻すことで「覚えている」ような連続性を作っています。^[1][3]

そのためAI Memoryを理解するときは、「モデルが頭の中に記憶した」と考えるより、何を保存し、どこに置き、いつ取り出し、どのcontextへ戻すかを管理する仕組みと見る方が正確です。

context windowとmemoryは違う

現在の会話履歴がcontext windowに残っているだけでも、AIは数ターン前の情報を参照できます。しかしcontext windowには上限があり、会話が長くなると古い情報は入りきらなくなります。またsessionを終了すれば、そのthreadのstateを次のsessionへ自動的に持ち越せない設計もあります。

Memory機構は、この制約を補うために使われます。例えば「ユーザーが以前選んだ設定」「前回のtaskで得た教訓」「何度も使うproject情報」を別storeへ保存し、次回必要になったときにretrieveしてモデルへ渡します。

Short-termとLong-term

AI agentの実装では、memoryをshort-termとlong-termに分けることがあります。Short-term memoryは、いま進行しているthreadやworkflowのstateです。会話履歴、現在のTODO、途中計算、toolの結果などが含まれます。

Long-term memoryは、sessionやthreadをまたいで残る情報です。ユーザー固有の好み、過去に成功した手順、繰り返し参照する事実などを保存し、後のconversationでも利用します。

この区分は絶対ではありません。製品ごとに「memory」という語のscopeは異なるため、名称よりも保存期間と参照範囲を確認する必要があります。

何を記憶するか

AI Memoryは、保存内容の性質でも分けられます。事実や属性を保存するsemantic memory、過去の出来事や行動例を保存するepisodic memory、手順やルールを保持するprocedural memory、といった整理があります。

例えば「ユーザーは日本語で回答を希望する」はsemanticな事実として保存できます。「前回このデータ変換でエラーになり、この手順で修正した」はepisodicな経験です。「必ず監査後に公開する」といったsystem ruleはproceduralな情報として扱えます。

ただし、この分類は人間の認知モデルとの類推です。AIに人間と同じ記憶機構が実装されていることを意味しません。

「保存」より難しいのは「思い出す」こと

大量のmemoryを保存しても、必要なときに正しいmemoryをretrieveできなければ役に立ちません。そこでembeddingによるsemantic search、keyword search、hybrid search、re-ranking、knowledge graphなどが使われます。

また、何でも保存するとmemoryが肥大化し、古い情報や矛盾する情報が混ざります。そのためmemory systemには「何を記録するか」「既存memoryを更新するか」「期限切れを削除するか」「矛盾をどう解決するか」というwrite policyも必要です。

MemGPTのような研究は、有限のcontext windowと外部memoryの間で情報を出し入れし、長期的な会話や大規模文書処理を続ける設計を示しました。これはAI Memoryが単なるdatabase名ではなく、contextへ情報を出し入れする制御問題でもあることを示しています。^[2]

model trainingとは違う

ここは特に誤解しやすい点です。AI Memoryへ情報を追加したからといって、通常はmodel weightsが更新されるわけではありません。つまり「AIがこの会話から学習して賢くなった」とは限りません。

外部memoryに保存された情報は、後から検索され、入力contextとしてモデルへ与えられます。これはfine-tuningや継続学習とは別の仕組みです。もちろん、保存したinteractionを将来のtraining dataへ使うシステムはあり得ますが、それはmemory機構とは別の工程として確認する必要があります。

誤記憶とmemory pollution

AI Memoryには便利さと同時にリスクがあります。モデルが会話から誤った事実を抽出して保存すると、その誤りが次回以降も繰り返し使われる可能性があります。古い住所や変更済みのproject方針が残れば、stale memoryになります。また、攻撃者が悪意ある指示をmemoryへ書き込ませ、将来のsessionへ影響させるmemory poisoningのような問題も考えられます。

そのため重要なmemoryでは、provenance、作成時刻、更新履歴、所有者、信頼度、削除手段、access controlを持たせる設計が重要です。

privacyとユーザー制御

「覚えてくれる」機能は、裏返すと「情報を保存する」機能です。製品を使うときは、何が保存対象か、どのscopeで共有されるか、ユーザーが確認・修正・削除できるか、保存期間はどうなっているかを確認する必要があります。

AI Memoryの便利さは、保存量の多さだけでは決まりません。不要な情報を保存しないこと、正しい情報を必要なときに出すこと、誤りを訂正できることの方が重要です。

元の説明へ戻ったときの読み方

「このAIにはmemoryがあります」と書かれていたら、まずmemoryのscopeを確認してください。同じthreadだけか、sessionをまたぐか、ユーザー単位か、agent単位か。次に、保存方式とretrieval方式、更新・削除、privacy controlを確認します。

そして「memoryがある」ことから、modelが継続学習している、すべてを正確に覚えている、必要な情報を必ず思い出せる、と推論してはいけません。AI Memoryは、保存と検索と更新を組み合わせて継続性を作るシステム機能です。

実用チェックリスト

• scopeはthread/user/agent/orgのどれか
• 何を誰がwriteするか
• retrieval方式は何か
• 訂正・削除・期限設定が可能か
• model trainingと混同していないか
• privacy/access control/provenanceがあるか

関連するAI用語

• G174：Long-Term Memory
• G175：Knowledge Base
• G172：Context Compaction
• G164：ベクトルデータベース

注・出典

1. LangChain Docs — Memory overview — short-term/thread-scopedとlong-term/cross-sessionを区別し、semantic/episodic/procedural memoryを説明。 ↩
2. MemGPT: Towards LLMs as Operating Systems — 有限contextを補うため、階層的memory管理で長期会話・大文書を扱う設計例。 ↩
3. LangChain Docs — Memory — AI applicationのmemoryをstate/storeとして実装する具体例。 ↩

AI協働制作について

本記事は、著者が独自に設計した指示、参照資料、出典確認規則、著作権確認および監査工程を組み込んだChatGPT等の生成AIを、情報収集の補助、資料整理、構成検討、草稿作成、文章校正および監査補助に使用して制作しました。記事の対象範囲、情報源の採否、構成、解釈および最終表現は著者が判断し、最終稿を承認しています。著者は、本記事の正確性、独自性、引用、著作権処理および公開内容について責任を負います。制作工程の詳細は「AI協働制作方針」をご覧ください。