RAGの今後

RAGはなくなるのではなく、形が変わります。単純な「ベクトル検索してLLMに渡す」構成は縮小し、長文コンテキスト、エージェント、権限管理、コード実行、評価、知識グラフと組み合わさった「情報アクセス基盤」へ進化していきます。

「RAGは不要になる」の誤解

長いコンテキストを扱えるLLMが増えると、「全部入れればRAGはいらないのでは」と考えたくなります。

しかし、RAGの役割は単にコンテキスト長を節約することではありません。

RAGには次の役割があります。

• 必要な情報を大量文書から選ぶ
• 権限に応じて見せる情報を制御する
• 文書の鮮度や版を管理する
• 根拠を引用できるようにする
• 不要な機密情報をLLMに渡さない
• 検索・生成の品質を評価する
• ツールやデータソースをまたいで調査する

長文コンテキストは「たくさん読める」能力です。RAGは「何を読むべきかを選び、根拠として管理する」能力です。両者は競合ではなく補完関係です。

今後の方向性

RAGは、次の6つの方向へ広がっています。

方向	何が変わるか
Long-context RAG	検索で候補を絞り、選んだ文書を長く読む
Agentic RAG	エージェントが検索計画、再検索、検証を行う
Graph RAG	文書群をエンティティ・関係・要約として構造化する
Multimodal RAG	PDF、表、画像、音声、動画を扱う
Code RAG	リポジトリ、テスト、実行ログ、履歴を扱う
Secure RAG	権限、監査、データ最小化を中核に置く

1. Long-context RAG

今後のRAGは、短いチャンクを数個渡すだけではなく、検索で候補を絞ったうえで、必要な文書を長く読む構成になります。

graph LR
    Q["質問"] --> R["候補検索"]
    R --> S["文書選択"]
    S --> LC["長文コンテキストで精読"]
    LC --> A["回答"]

この構成では、RAGの役割は「コンテキストを短くすること」ではなく、「読むべき資料を選ぶこと」になります。

向いている用途は次の通りです。

• 契約書の特定条項を周辺文脈ごと読む
• 論文を複数本比較する
• 長い設計書から関連セクションを読む
• リポジトリ内の関連ファイルをまとめて読む

2. Agentic RAG

複雑な質問では、検索を1回で終えるのではなく、調査として進める必要があります。

Agentic RAGでは、エージェントが次のように行動します。

1. 質問を分解する
2. 必要な情報源を選ぶ
3. 検索する
4. 結果を読む
5. 足りなければ検索を変える
6. 矛盾を確認する
7. 根拠付きで回答する

2025年のAgentic RAGサーベイや、2026年のA-RAGのような研究は、RAGが固定パイプラインから、LLMの推論能力とツール利用能力を活かす方向へ進んでいることを示しています。[1][2]

3. Graph RAG

大量文書に対して「全体として何が起きているか」を聞く場合、チャンク検索だけでは不十分です。

Graph RAGは、文書からエンティティ、関係、コミュニティ、要約を作り、文書群全体を構造として扱います。[3]

今後は、次のような用途で重要になります。

• 顧客問い合わせ全体のテーマ分析
• 組織内の知識ネットワーク可視化
• 研究論文群の関係整理
• 法務・規制文書の関連条項整理
• 障害報告とシステム構成の関係分析

ただし、Graph RAGは構築コストが高いため、すべてのRAGに必要なわけではありません。全体質問や関係性の質問が多い領域で効果を発揮します。

4. Multimodal RAG

業務文書はテキストだけではありません。

PDF、表、図、スクリーンショット、音声、動画には、テキスト抽出だけでは失われる情報があります。

データ	失いやすい情報
PDF	ページ構造、脚注、表、段組み
表	行列関係、単位、計算式
画像	図の意味、配置、注釈
音声	話者、間、強調
動画	時刻、画面操作、場面転換

今後のRAGは、単にOCRしたテキストを検索するだけでなく、元の構造と対応づけて根拠を示す必要があります。Multimodal Agentic RAG のサーベイも、テキスト以外の入力を扱う検索・生成パイプラインを整理しています。[4]

5. Code RAG

コーディングエージェントの台頭により、RAGはソフトウェア開発の中核にもなります。リポジトリレベルのコーディングエージェント評価を扱う SWE-PolyBench のようなベンチマークも登場しています。[5]

コードRAGでは、次の情報を検索・読解します。

• ソースコード
• 型定義
• テスト
• 設定
• 実行ログ
• Issue
• PR
• コミット履歴
• エージェント向け指示ファイル

コードRAGの今後は、単なるコード検索ではなく「変更して検証するRAG」です。

graph TD
    Search["関連コード検索"] --> Edit["編集"]
    Edit --> Test["テスト実行"]
    Test --> Log["ログ読解"]
    Log --> Search

実行結果が次の文脈になり、エージェントが検索と修正を繰り返します。

6. Secure RAG

企業でRAGを使うほど、技術的な検索精度よりも権限と監査が重要になります。

今後のRAGでは、次の設計が標準になります。

設計	内容
権限継承	元システムのアクセス権を検索時に強制する
データ最小化	必要な根拠だけLLMに渡す
引用監査	回答と根拠の対応を保存する
インデックス鮮度	更新・削除・失効を反映する
プロンプトインジェクション対策	検索文書を命令として扱わない
ログ制御	機密情報を過剰に保存しない

「ベクトルDBに全部入れる」設計は、権限と更新の扱いを誤ると危険です。今後は、元データソースの権限を保ったまま、必要時に問い合わせる構成も増えます。

RAGはエージェントの記憶になる

エージェントにとって、RAGは外部記憶です。

ただし、これは単なる長期メモリではありません。

• 公式文書を参照する記憶
• 過去の作業履歴を参照する記憶
• ユーザー権限で制御される記憶
• 検証可能な引用を持つ記憶
• 更新・削除できる記憶

人間が仕事をするとき、すべてを暗記するのではなく、必要な資料を探し、読み、メモし、根拠を示します。RAGは、エージェントにこの作業能力を与える基盤になります。

今後も残る課題

RAGが進化しても、課題は残ります。

課題	なぜ難しいか
検索失敗	必要な根拠が見つからなければ正しく答えられない
根拠の矛盾	複数資料が異なる内容を持つことがある
評価の難しさ	実務質問は正解が1つとは限らない
コスト	検索、リランク、長文読解、検証で費用が増える
遅延	エージェント化すると複数ステップになりやすい
権限	ユーザーごとに見える情報が異なる
鮮度	インデックスが古いと誤答につながる

特に、評価は今後も重要です。RAGの改善は、体感ではなく、検索再現率、根拠忠実性、引用正確性、業務成功率で測る必要があります。

実務での結論

これからRAGを設計するなら、次の考え方が現実的です。

1. 単純なFAQならAdvanced RAGで十分
2. 長い文書を読むならLong-context RAGを組み合わせる
3. 全体傾向を聞くならGraph RAGを検討する
4. 複雑な調査ならAgentic RAGを使う
5. ソフトウェア開発ならCode RAGとして設計する
6. 企業利用では、最初から権限・監査・評価を入れる

まとめ

• RAGは消えるのではなく、情報アクセス、権限管理、検証、エージェント行動の基盤へ変わる
• 長文コンテキストはRAGの代替ではなく、RAGで選んだ資料を深く読むための補完になる
• Agentic RAGとCode RAGにより、RAGは「回答生成」から「作業遂行」の文脈へ広がる
• 今後のRAGで重要なのは、検索精度だけでなく、根拠、権限、鮮度、評価、監査である

参考文献

1. Agentic Retrieval-Augmented Generation: A Survey on Agentic RAG
2. A-RAG: Scaling Agentic Retrieval-Augmented Generation via Hierarchical Retrieval Interfaces
3. From Local to Global: A Graph RAG Approach to Query-Focused Summarization
4. MMA-RAG: A Survey on Multimodal Agentic Retrieval-Augmented Generation
5. SWE-PolyBench: A multi-language benchmark for repository level evaluation of coding agents