メモリとRAGの違い

メモリとRAGは、どちらも「必要な情報を後から取り出してコンテキストへ渡す」仕組みのため混同されがちです。しかし、情報を書き込む主体が根本的に異なります。

何が違うのか

横にスクロールできます→

観点	メモリ	RAG
情報の出どころ	AIとのやり取りの中で生まれた情報	外部で管理されている文書・データ
書き込む主体	エージェント自身、またはユーザー	文書の作成者・管理者
更新のきっかけ	会話や作業の進行	元文書の改訂
典型的な中身	好み、取り決め、過去のタスク結果	マニュアル、規程、仕様書、FAQ
対象の広がり	そのユーザー・そのプロジェクト固有	組織全体で共有される知識

この表は横方向にスクロールできます。キーボードでは、表にフォーカスして左右の矢印キーを使用してください。

一言でいうと、RAGは「みんなの資料を引く」仕組み、メモリは「この相手との経緯を覚える」仕組みです。

判断の流れ

graph TD
    Q["この情報はどこで生まれたか"] --> A["やり取りの中で判明した"]
    Q --> B["外部の文書に書かれている"]
    A --> M["メモリに保存する"]
    B --> R["RAGで検索して引く"]
    M --> C["コンテキストへ渡す"]
    R --> C

判断に迷ったら「この情報は、元になる文書がどこかに存在するか」を考えます。存在するならRAG、存在せずやり取りの中でだけ生まれたものならメモリです。

実装が似ていても役割は分ける

長期メモリの実装にベクトル検索を使う場合、技術的にはRAGとほぼ同じ構成になります。それでも、保存先と運用は分けたほうが安全です。

• 混ぜると、古くなった会話メモが公式文書と同列に検索される
• 誤りが見つかったとき、どちらを直せばよいか分からなくなる
• 権限管理の単位が異なる（メモリは個人単位、文書は組織単位のことが多い）

併用が基本

実務では、どちらか一方ではなく併用が基本形です。

• RAG — 社内規程や製品仕様など、正解が外部文書にある質問に答える
• メモリ — 相手の状況・好み・過去の経緯を踏まえて回答を調整する

たとえば問い合わせ対応では、規程はRAGで引き、その顧客との過去のやり取りはメモリから補う、という役割分担になります。

まとめ

• メモリはやり取りの中で生まれた情報、RAGは外部で管理された文書を扱う
• 判断基準は「元になる文書が外部に存在するか」
• 実装が似ていても、保存先と運用は分けたほうが管理しやすい
• 実務では併用が基本で、RAGが知識、メモリが相手固有の前提を担う

関連リンク

• メモリとは
• RAGとは
• 長期メモリの保存方式