従来型のRAGシステムを構築したことがあれば、その長所はご存じでしょう。関連するチャンクを検索し、LLMが根拠に基づく回答を生成します。性能は妥当で、コストも予測可能です。ほとんどのナレッジベース検索には、これで十分です。
しかし、一部のクエリは従来型RAGでは扱えません。マルチホップの質問（「機能Xを使っていて、過去6か月以内に解約した顧客はどこですか？」）、関係性の多い質問（「競合A、B、Cと比べて、当社の価格設定はどうですか？」）、統合を要する質問（「この顧客のカスタマージャーニーについて分かっていることをすべて要約してください」）などです。従来のチャンクベース検索はチャンクをうまく組み合わせられず、LLMは多くの場所に分散したコンテキストを取りこぼします。
「チャンクを超える」アプローチであるグラフRAG、エージェント型RAG、ロングコンテキストRAGは、それぞれ異なる方法でこうした限界に取り組みます。本記事では、それぞれが何であるか、どのような場合に適しているか、本番環境で実際にどう動作するか、そして重要なトレードオフを解説します。
チャンクベースRAGの限界
何を修正しようとしているのかを理解するために、限界を見てみましょう。
限界1：関係構造がない。 チャンクは独立した単位です。チャンクAが顧客Xのアカウントについて、チャンクBが顧客Xからの苦情について書かれていても、その関係は失われます。ベクトル空間内の2つのチャンクにすぎず、独立して検索されるか、検索されないかが決まります。
限界2：マルチホップがない。 「機能Xを使い、Yについて苦情を申し立てた顧客」という問いには、2つの異なるソースの情報を集合論理で組み合わせる必要があります。チャンクベース検索では実現できません。
限界3：統合能力が限られる。 「このアカウントとの関係を時系列で要約してください」という問いでは、多数のチャンクを集めて、一貫した物語にまとめる必要があります。チャンクは断片として提示されるため、LLMは毎回ゼロから統合しなければなりません。
限界4：固定パイプラインの硬直性。 従来型RAGは常に、クエリの埋め込み → K件の検索 → 生成、という流れです。反復的な検索や複数ステップの推論が必要な複雑なクエリは、このパイプラインに適合しません。
限界5：コンテキストの希薄化。 上位5件のチャンクに、クエリには一致していてもトピックから外れたものが含まれる場合があります。LLMはそれらをかき分ける必要があり、品質が低下します。
ここから説明する各バリエーションは、それぞれこうした限界の一部に対処します。
グラフRAG
考え方は、データをナレッジグラフとして表現することです。エンティティー（人、製品、ドキュメント、イベント）をノード、関係をエッジにします。クエリでは、ベクトル検索の代わりに、またはベクトル検索に加えて、グラフをたどります。
グラフRAGが役立つ場合
関係性の多いドメイン。 顧客、アカウント、商談、やり取りの構造。組織階層。製品分類。引用ネットワーク。エンティティーそのものと同じくらい、エンティティー間のつながりが重要なものです。
マルチホップ推論。 「第3四半期に製品Xを購入したチームのマネージャーは誰ですか？」という問いには、製品 → 商談 → チーム → マネージャーとたどる必要があります。グラフRAGなら自然に処理できます。
集計。 「セグメントYの顧客のうち、システムZと連携している顧客は何社ですか？」という問いには、エンティティーをまたぐ集合演算が必要です。ナレッジグラフに対するSQLの方が、テキスト検索より優れています。
引用と説明。 グラフの関係は明示的で、監査可能です。LLMは「コンテキストから判断すると、ジョンがチームAcmeを管理していると思います」ではなく、「ジョンはチームAcmeのマネージャーです［エッジ：manages］」と引用できます。
グラフRAGの実際の仕組み
一般的なパイプラインは次のとおりです。
1. 抽出。 データからグラフを構築します。一般的なアプローチは2つあります。
- 構造化ソース（データベース、構造化API）: 直接インポートします。顧客、製品、取引はすでに表形式になっています。
- 非構造化ソース（ドキュメント、文字起こし、メール）: LLMを使ってエンティティーと関係を抽出します。「この文字起こしから、人、組織、それらの関係を抽出してください。」
出力は、ノード（型とプロパティーを持つ）とエッジ（型とプロパティーを持つ）です。
2. 保存。 Neo4j、Memgraph、エッジテーブルを備えた独自のPostgresなど、グラフデータベースを使います。選択肢はクエリパターンと規模によって異なります。
3. 埋め込みによる拡張。 各ノードにもテキスト表現と埋め込みを付与します。これにより、グラフをたどりながらセマンティック検索も行うハイブリッド処理が可能になります。
4. 検索時のクエリ。 一般的なパターンは3つあります。
- グラフのみのクエリ。 LLM（またはルーティングロジック）がグラフクエリ（Cypher、SQL）を生成します。実行し、結果をLLMに返します。
- 埋め込みを先に行い、グラフを展開。 埋め込みで関連エンティティーを見つけ、その近傍と関連エンティティーに展開します。
- ハイブリッド。 1つのパイプラインでベクトル検索とグラフ探索を組み合わせます。
5. LLM向けに整形。 グラフの結果を、LLMが使える構造化テキストに整形します。エンティティーとそのプロパティーを示し、関係を明示します。
具体例
顧客データを持つSaaS企業を考えます。エンティティーは、顧客、契約、製品、サポートチケット、やり取り、従業員です。
従来型RAGのアプローチは、顧客ドキュメントをチャンクに分割して埋め込み、検索します。関係構造は失われます。
グラフRAGのアプローチ：
- ノード：顧客、契約、製品、チケット、やり取り、従業員。
- エッジ：顧客→has→契約、顧客→subscribed_to→製品、顧客→submitted→チケット、チケット→assigned_to→従業員、契約→sold_by→従業員。
クエリ：「SaaSティアの顧客のうち、第1四半期に3件を超えるサポートチケットがあり、第2四半期に契約更新を迎える顧客はどこですか？」
これは自然にグラフクエリとして表現できます。
MATCH (c:Customer)-[:HAS]->(contract:Contract)
WHERE contract.tier = "SaaS"
AND contract.renewal_date BETWEEN "2026-04-01" AND "2026-06-30"
MATCH (c)-[:SUBMITTED]->(t:Ticket)
WHERE t.created BETWEEN "2026-01-01" AND "2026-03-31"
WITH c, count(t) as ticket_count
WHERE ticket_count > 3
RETURN c, ticket_count
LLMがこのクエリを生成します（またはテンプレート化されたクエリから選択します）。実行し、結果を整形して、応答を生成します。
従来型RAGでは簡単に答えられませんが、グラフRAGなら明快に処理できます。
トレードオフ
長所：
- 関係性を問うクエリを自然に処理できます。
- 構造が明示的で、監査可能です。
- 埋め込みと組み合わせられます。
短所：
- グラフの構築には本格的なエンジニアリング作業が必要です。特に非構造化ソースでは、抽出が完全ではありません。
- スキーマ設計が重要です。不適切なスキーマは制約になります。
- 保守が必要です。データの変化に伴って、グラフも変化します。
- ベクトル検索ほどツールが成熟していません。
選ぶべき場合：
ドメイン内で関係性が第一級の要素である場合に、グラフRAGを選びます。高度に聞こえるという理由だけで選ばないでください。ドキュメント中心の多くのドメインでは、従来型RAGの方がシンプルで、同等に優れています。
MicrosoftのGraph RAGと関連研究
MicrosoftのオープンソースGraphRAGプロジェクト（2024年）は、次の具体的なアプローチを広めました。
- ドキュメントからエンティティーと関係を抽出する（LLMベース）。
- エンティティーをコミュニティーにクラスタリングする。
- 複数の階層レベルでコミュニティーごとの要約を生成する。
- クエリ時に、関連するコミュニティーの要約を検索し、コンテキストとして使う。
これは、具体的な情報検索よりも、コーパス全体にまたがる「大局的な」質問（例：「この顧客の苦情履歴における主なテーマは何ですか？」）に適しています。
LightRAG、Graphitiなどの派生手法があり、それぞれ固有のアーキテクチャ上の選択があります。
エージェント型RAG
考え方は、固定された「検索してから生成する」パイプラインではなく、何を、いつ、どのように検索して絞り込むかを決めるLLMエージェントを使うことです。エージェントは追加の検索クエリを実行し、結果を見て不十分だと判断すれば、別の角度から試せます。
エージェント型RAGが役立つ場合
反復が必要な複雑なクエリ。 「第1四半期に解約が増えた理由を理解したい」という問いでは、多くの角度（どのセグメント、どの期間、どの機能、どの競合）から調べる必要があります。エージェントなら反復的に探索できます。
1回の検索では不十分なクエリ。 複数の異なる検索結果を組み合わせなければ答えられない場合、エージェントなら自然に処理できます。
条件分岐のあるクエリ。 「検索1の結果からXが真ならYを調べ、そうでなければZを調べる。」エージェントは分岐を処理できますが、固定パイプラインにはできません。
曖昧なクエリ。 エージェントはユーザー（またはデータ）に確認できます。
エージェント型RAGの仕組み
パイプラインは次のとおりです。
ユーザーのクエリ
↓
エージェントが必要な情報を推論
↓
エージェントが検索ツールを呼び出す（1回または複数回）
↓
エージェントが結果を読む
↓
エージェントが判断: 情報は十分か、それとも追加検索が必要か
↓
完了するまでループ
↓
最終回答を生成
実装には次の要素が含まれます。
ツールとしての検索。 検索関数をエージェントに公開します。search_documents(query)、lookup_by_id(id)、aggregate(field, filter)などです。エージェントが必要に応じて呼び出します。
メモリー。 エージェントは、複数の呼び出しをまたいで検索済みの内容を記憶します。同じコンテンツの再取得を避けます。
意思決定。 エージェントは、十分な情報があるかを明示的に推論します。「ユーザーの質問への答えは分かっているか。分からない場合、ほかに何を検索する必要があるか。」
終了条件。 エージェントは停止すべき時点を判断する必要があります。最大ステップ数、信頼度のしきい値、「回答済み」という条件などです。
具体例
クエリ：「第1四半期における顧客の懸念事項の上位3つを、例とともに教えてください。」
従来型RAGのアプローチは、顧客フィードバックのチャンクをいくつか検索し、トピックが網羅されていることを期待します。
エージェント型RAGのアプローチ：
エージェント: 第1四半期の顧客の懸念事項を見つける必要があります。まず、その期間の顧客からの苦情を検索します。
> ツール: search_documents(query="2026年第1四半期 顧客からの苦情", filter={date_range: "Q1 2026"})
エージェント: 25件の結果が得られました。どのようなトピックが含まれるか確認します。
> ［結果を読む］
エージェント: 価格、サポートの遅さ、連携機能の不足という3つの主要テーマが見つかりました。それぞれについて具体例を取得します。
> ツール: search_documents(query="価格に関する顧客の苦情", filter={...})
> ツール: search_documents(query="サポート速度に関する顧客の苦情", filter={...})
> ツール: search_documents(query="連携機能の不足に関する顧客の苦情", filter={...})
エージェント: 各テーマについて3～5件の具体例がそろいました。回答にまとめます。
検索を複数回行い、反復的に絞り込みます。エージェントは見つけた内容に基づいて構成を決めます。
トレードオフ
長所：
- 複雑な複数ステップのクエリを処理できます。
- クエリの複雑さに適応します（単純なクエリでは長いエージェント実行を開始しません）。
- 質問によって曖昧さを解消できます。
短所：
- レイテンシーが高くなります（複数回の検索）。
- コストが高くなります（複数回のLLM呼び出し）。
- エージェントの信頼性が重要です。不適切なエージェントはループしたり、諦めたりします。
- 評価が難しくなります（実行経路のばらつきが増えます）。
- 制御が難しくなります（エージェントが予期しないことをする可能性があります）。
選ぶべき場合：
クエリの複雑さが大きく異なる場合に、エージェント型RAGを選びます。単純なクエリは高速な経路を使い、複雑なクエリだけをエージェント型で処理できます。クエリが一様に単純なら、オーバーヘッドに見合いません。
エージェント型RAGのパターン
一般的なパターンをいくつか挙げます。
パターン1：ReAct（Reason＋Act）。 エージェントが明示的に推論し、行動（検索）し、観察して、再び推論します。完了するまで繰り返します。
パターン2：計画と実行。 エージェントが最初に複数ステップの計画（何をどの順序で検索するか）を作成し、その計画を実行します。必要に応じて調整します。
パターン3：自己批評。 検索後、エージェントが取得した情報で十分かを評価します。不十分ならクエリを改善して再度検索します。
パターン4：ツールが豊富なエージェント。 エージェントは多数の検索ツール（全文検索、SQLクエリ、グラフクエリ、API呼び出し）を持ち、その中から選択します。
ユースケースに応じて適したパターンは異なります。ツールが豊富なエージェントは異種データソースに、ReActは探索的なクエリに、計画と実行は複雑なクエリの構造を事前に計画できる場合に適しています。
ロングコンテキストRAG
考え方は、100万トークン以上のコンテキストウィンドウ（Gemini、GPT-5）があるなら、そもそもなぜチャンクを検索するのか、というものです。コーパス全体をコンテキストに入れます。
ロングコンテキストRAGが役立つ場合
小規模なコーパス。 100Kトークンのコーパスなら、100万トークンのウィンドウに容易に収まります。検索インフラは不要です。
ドキュメント全体の理解。 「この500ページのドキュメント全体を要約してください。」ロングコンテキストモデルなら直接処理できます。
少数のドキュメントをまたぐクエリ。 「この10件の契約を比較してください。」慎重に検索するより、すべてをコンテキストに入れる方が簡単です。
プロトタイピング。 ロングコンテキストは、動作するシステムを作る最も簡単な道です。ロングコンテキストでプロトタイプを構築し、必要に応じて後から検索で最適化します。
ロングコンテキストRAGの仕組み
パイプラインは非常に単純です。
[コーパス（100K～1Mトークンの場合もある）]
↓
+ [ユーザーのクエリ]
↓
LLM呼び出し
↓
[回答]
ベクトルストアも、チャンク分割も、再ランキングもありません。
実際には、コーパスをコンテキストに収めるために軽い検索を行う場合があります（たとえば、5Mトークンのコーパスから500Kトークンの部分集合を検索）。ただし、検索は粗い粒度で行い、細かく「関連箇所を見つける」作業はLLMが担います。
「コンテキスト劣化」の問題
2025～2026年の現実として、ロングコンテキストモデルは実際には長いコンテキストをうまく利用できません。
実証的には次のことが分かっています。
- 品質が最も高いのは、おおむね5～50Kトークンのコンテキストです（その背景にある位置的注意のパターンは、Liuらの「Lost in the Middle」と、その後のロングコンテキスト評価で報告されています）。
- 100Kトークンを超えると、品質は明らかに低下します。
- 500Kトークンを超えると、重要な情報が見落とされたり、誤って適用されたりすることがよくあります。
モデルは技術的には長いコンテキストを処理できますが、「干し草の山から針を探す」ベンチマークは性能を実態以上に見せています。現実のロングコンテキスト利用では問題が生じます。
つまり、ロングコンテキストRAGが安定して機能するコーパスは最大約50Kトークンです。それを超えると、優れた検索と比べて品質が低下します。
トレードオフ
長所：
- 可能な限りシンプルなアーキテクチャです。
- 保守すべき検索パイプラインがありません。
- コーパス全体の理解が必要なタスクに最適です。
短所：
- コンテキストサイズが大きいと品質が低下します。
- クエリ当たりのコストが高くなります（毎回、コンテキスト全体に対して料金が発生します）。
- レイテンシーが高くなります（大きなコンテキストほど応答が遅くなります）。
- 安定して収まるコーパスを超えて拡張できません。
選ぶべき場合：
小規模なコーパス（50Kトークン未満）、一度限りの分析、プロトタイプに適しています。大規模なナレッジベースを対象とする汎用検索には適していません。
ハイブリッド：検索＋ロングコンテキスト
一般的なパターンは、従来型RAGより大きく、コーパス全体より小さいコンテキスト（関連コンテンツ50～200Kトークン）を検索することです。コンテキスト劣化を起こさず、クエリを適切に処理するのに十分なコンテキストをLLMに渡せます。
実装では、上位5件ではなく上位50件のチャンクを検索し、すべてを含めてLLMに精査させます。
次の場合にうまく機能します。
- クエリに広いコンテキストが必要。
- モデルが中規模のコンテキスト（50～200K）を適切に処理できる。
- コストを許容できる。
2026年時点の最適な選択肢の1つは、積極的に検索し（50～100チャンク）、すべてを含めて、関連箇所をLLMに使わせる方法です。コストと引き換えに、単純さと品質を得られます。
適切なバリエーションの選択
判断フレームワークを示します。
従来のチャンクベースRAGを使う場合：
- ドキュメントが主要なデータである。
- クエリの大半が情報検索型である。
- 処理量とコストが重要である（クエリ当たりのコストが最も安い）。
- 予測可能なレイテンシーが必要である。
グラフRAGを使う場合：
- データに豊かなエンティティー間の関係構造がある。
- クエリにマルチホップ推論、集合演算、集計が含まれる。
- グラフの構築と保守に投資できる。
エージェント型RAGを使う場合：
- クエリの複雑さが大きく異なる。
- 一部のクエリには反復的な探索が必要である。
- 難しいクエリのために、より高いレイテンシーとコストを許容できる。
- エージェントの実行をデバッグするための可観測性がある。
ロングコンテキストRAGを使う場合：
- コーパスが小さい（50Kトークン未満）。
- 最もシンプルなアーキテクチャを求める。
- 一度限りの分析またはプロトタイプである。
組み合わせる場合：
- 実際のシステムの大半が組み合わせています。
- 関係性を問うクエリには従来型＋グラフ。
- 複雑なクエリには従来型＋エージェント型。
- 境界にあるケースには、検索範囲を広げた従来型（中規模コンテキスト）。
2026年時点の成熟した答えは、「クエリごとに適用する、上記すべて」です。ルーターがクエリの特性に基づき、どのバリエーションを使うかを決めます。
本番環境の現実
実際の導入から得られた所見をいくつか挙げます。
複雑さは複利的に増える。 各バリエーションを追加するたびに複雑さが増します。4種類すべてを使うシステムは、かなり大規模なエンジニアリング作業になります。従来型から始め、明確な限界に達した場合にだけバリエーションを追加してください。
評価が難しくなる。 複数の検索経路がある場合、すべてを評価する必要があります。テストセットには、各経路を通るクエリを含めます。
コストは大きく異なる。 グラフRAGは安価な場合があります（データベースクエリ1回）。ロングコンテキストRAGは高価です。エージェント型RAGは状況により異なります（単純なら安く、複雑なら高い）。クエリごとのコストを追跡してください。
レイテンシーも同様に異なる。 エージェント型RAGが30秒で応答しても問題ないユースケースもあれば、そうでないものもあります。UXの状況に応じてバリエーションを選びます。
保守負担。 グラフのスキーマはドリフトし、エージェントのプロンプトには調整が必要で、埋め込みモデルは更新されます。各バリエーションに固有の保守コストがあります。それを踏まえて計画してください。
80対20。 従来型RAGは、クエリの80%を十分に処理できます。チャンクを超えるバリエーションは、従来型が苦手とする難しい20%を処理します。置き換えるのではなく、拡張してください。
複合アーキテクチャ
複数のバリエーションを使う実用的なアーキテクチャは次のとおりです。
クエリ
↓
ルーター（クエリを分類）
├→ 「情報検索」→ 従来型RAG（安価、高速）
├→ 「関係性」→ グラフRAG
├→ 「複雑／自由回答」→ エージェント型RAG
└→ 「コーパス全体／小規模コーパス」→ ロングコンテキスト
各バリエーションが回答を生成します。
可観測性によって使用された経路を追跡します。
評価スイートですべての経路を網羅します。
単一のバリエーションより複雑ですが、幅広いクエリを適切に処理できます。多様なクエリを扱う成熟したシステムでは、最終的にこのアーキテクチャへ到達します。
実用的な構築手順
稼働中の従来型RAGを拡張する場合は、次のように進めます。
最初にロングコンテキストを追加する。 エンジニアリングコストが最も低く、特定の種類のクエリに役立ちます。すぐに成果が出ることもよくあります。
複雑なクエリにエージェント型を追加する。 従来型RAGが苦手とするクエリを特定します。それを処理するエージェントを構築し、条件に応じてルーティングします。
最後にグラフRAGを追加する。 エンジニアリングコストが最も高くなります。明確な関係性クエリのパターンがある場合に限り、投資に見合います。
通常、この順序がROIに合います。ロングコンテキストは低コストで実際の価値があります。エージェント型は中程度のコストで、実際の不足を補います。グラフは高コストで、特定のユースケースに適します。
置き換えず、拡張する
従来のチャンクベースRAGは主力ですが、限界があります。「チャンクを超える」バリエーションであるグラフRAG、エージェント型RAG、ロングコンテキストRAGは、それぞれ異なる能力を引き出します。
進むべき道は、従来型RAGを置き換えることではなく、拡張することです。成熟したシステムでは複数のバリエーションを使い、それぞれが得意なクエリを処理するよう適切にルーティングします。
必要な投資は小さくありません。各バリエーションには、本格的なエンジニアリング作業が必要です。しかし、従来型RAGの品質が頭打ちになったシステムでは、能力の向上を実感できます。「情報検索」クエリだけを適切に処理するシステムより、関係性を問うクエリ、複雑なクエリ、コーパス全体を対象とするクエリも処理できるシステムの方が、はるかに有用です。
クエリを整理してください。従来型RAGがうまく処理できないものを特定します。適したバリエーションを選び、拡張機能を構築し、反復します。
これが、RAGシステムを「一部のクエリには役立つ」状態から、現実にある多様な質問へ真に対応できる状態へ成長させる方法です。
