「RAGはもう不要だ」という声が、また聞こえてきました。
数か月おきに繰り返されるこの議論。
今回の火種は、Anthropic社のClaude Coworkです。
セッションをまたいで情報を「記憶」できるエージェント機能が話題を呼びました。
そして、Redditの r/Rag コミュニティでも議論が盛り上がっています。
本記事では、このRedditでの議論を参考に、RAGとエージェントメモリの違いについて整理してみます。
「RAGは死んだ」論の背景
Claude Coworkのようなエージェントは、タスクの進行状況や過去のやり取りをセッション間で保持できます。
従来のLLMでは、コンテキストウィンドウの制約が常に付きまとっていました。
「さっき言いましたよね？」と聞いても、実際には何も覚えていない。
そんな経験をした人は多いでしょう。
この制約から解放されたことで、「もうRAGは要らないのでは？」という疑問が生まれたわけです。
しかし、Reddit上の議論を追ってみると、答えはかなり明確でした。
エージェントメモリとRAGは別物である
議論の中で繰り返し指摘されていたのが、「メモリ」と「検索」の根本的な違いです。
エージェントメモリは、エージェント自身が何をしていたかを記録する仕組みです。
タスクの状態、過去の会話の流れ、ユーザーとのやり取りの文脈。
これらを保持することで、長期にわたるタスク遂行が可能になります。
一方でRAGは、外部の知識を取得してプロンプトに注入する仕組みです。
対象となるのは、社内ドキュメントやデータベース、専門領域の文献など。
つまり、モデルが本来持っていない情報を補完する役割を担っています。
あるユーザーの表現が分かりやすかったので、少し意訳して紹介します。
完璧な記憶を持つけどドキュメントを読まない同僚と、何でも読むけど5分前の会話を忘れる同僚。 どちらも困りますよね。
この比喩は、両者の関係をうまく表現しています。
メモリとRAGは競合するものではありません。
補完し合うものです。
RAGの定義を正しく理解する
議論の中で特に印象的だったのが、「RAGの定義そのものが誤解されている」という指摘でした。
RAGは、ベクトル検索やセマンティック検索の同義語ではありません。
情報を自動的に取得し、それをプロンプトに注入して推論を行う。
このシステム全般を指す広い概念です。
したがって、キーワード検索の結果をLLMに渡すのもRAGです。
グラフデータベースから知識を取得するのも、RAGの一形態と言えます。
埋め込みベクトルを使った類似度検索は、RAGを実現する手法の一つに過ぎません。
この区別を理解していないと、どうなるか。
「Claude Coworkがあるからセマンティック検索は不要だ」という議論が、いつの間にか「RAGは死んだ」にすり替わってしまいます。
オンプレミス環境でのRAGの価値
Reddit上では、セキュリティの観点からRAGの重要性を強調する声も目立ちました。
医療、法律、金融といった業界では、データをクラウドに送ること自体が許されないケースがあります。
特にEU圏では、データ保護規制の影響が大きいです。
エアギャップ環境（外部ネットワークから隔離された環境）での運用を求められる場面も珍しくありません。
こうした状況では、クラウドベースのエージェントメモリは選択肢に入りません。
オンプレミスでRAGシステムを構築し、機密データに対してローカルで検索・推論を行う仕組みが不可欠です。
セキュリティ要件を考慮すると、RAGは単なる技術的な選択肢ではありません。
コンプライアンスの要請に応える手段でもあるのです。
エージェント検索との共存
興味深い指摘もありました。
Anthropic自身が、コーディングエージェントの内部でRAGからエージェンティック検索へ移行したという情報です。
ここで注目すべきは、以下の3つの技術がそれぞれ異なる役割を果たしている点でしょう。
コンテキストウィンドウの拡大は、一度に処理できる情報量を増やします。
RAGは、外部知識をプロンプトに注入します。
そして、エージェンティック検索は、エージェント自身が能動的に情報を探索します。
これらは排他的な関係ではありません。
状況に応じて組み合わせるべき技術です。
どれか一つが他を置き換えるという単純な構図にはなっていません。
GraphRAGという選択肢
Neo4jを使ったGraphRAGを実際に構築しているという開発者のコメントもありました。
知識ベースとメモリサービスの両方を統合しているそうです。
そして、複数のドメインにまたがる書籍やドキュメント、ユーザーのメモを横断的に扱っているとのこと。
RAGは単一の技術ではありません。
ベクトルDB、グラフDB、SQLを組み合わせた多層的なアプローチも有効です。
こうした柔軟な設計こそ、RAGの強みと言えるでしょう。
本質は「コンテキストの取得」
結局のところ、ラベルの問題に囚われすぎる必要はありません。
エージェントメモリもRAGも、LLMに適切なコンテキストを渡すための手段です。
LLMは世界の知識を圧縮して保持しています。
しかし、特定の企業の社内ドキュメントや、最新のデータベースの中身までは知りません。
その溝を埋めるのがRAGの役割です。
そして、タスクの継続性を保つのがメモリの役割です。
まとめ
Claude Coworkの登場は、エージェント技術の進化を示すものです。
しかし、RAGの終焉を意味するものではありません。
エージェントメモリはタスク状態の管理に優れています。
RAGは外部知識の取得に特化しています。
両者は補完関係にあり、本番環境では組み合わせて使うのが現実的な選択となるでしょう。
「RAGは死んだ」という主張が出るたびに思うことがあります。
技術の本質を理解せずに表面的な機能だけを比較しても、正しい結論には辿り着けないということです。
新しいツールが登場したとき、既存の技術を否定するのではなく、どう組み合わせるかを考える。
その姿勢が、より良いシステム設計への近道ではないでしょうか。
