# 第 2 章：RAG、ロングコンテキスト、ナレッジグラフ

> **一文で：** AI に知識へのアクセスを与える主要な方法は 3 つある：データベースを検索する（RAG）、長文書を与える、事実をグラフで繋ぐ。
>
> **なぜ重要か：** 自分のデータに関わる用途で AI を使うなら、本章はあなたの状況にどのアプローチが最適かを説明する。

**ナレッジ検索層 ——何が機能し、何が機能せず、なぜ答えはほぼ常に「ハイブリッド」なのか。**

---

## RAG は死んでいない

半年に一度、誰かが「RAG は死んだ、ロングコンテキストだけで十分だ」と公言する。半年に一度、エンタープライズが彼らの誤りを証明する。

**Gartner の 2025 Q4 エンタープライズ調査** によれば、RAG パイプラインを純粋な context-stuffing（巨大な context window に文書コーパス全体を流し込む方式）で置き換えようとした組織の 71% が、12 か月以内に RAG を再導入した。理由は一貫していた：コスト、レイテンシ、スケール時の精度劣化、動的または頻繁に更新されるナレッジベースを扱えないこと。

RAG は死んでいない。進化している。問いは決して「RAG か非 RAG か」ではなかった ——「どんな種類の RAG を、何と組み合わせるか」だった。

---

## コストの現実

RAG の経済的論拠は依然として圧倒的である。

典型的な RAG パイプラインは関連チャンクを 5–20 個（およそ 2,000–8,000 トークン）取得してモデル呼び出しに渡す。同じクエリに対する context-stuffing アプローチは、500K–1M トークンの原文書をロードする必要があるかもしれない。

**クエリあたりコスト比較（概算、2026 年中盤価格）：**

| 方式 | 入力トークン | 概算コスト | 相対コスト |
|----------|-------------|-----------------|---------------|
| RAG（ターゲット検索） | ~5,000 | ~$0.00008 | 1x |
| Context-stuffing（コーパス全体） | ~500,000 | ~$0.10 | 1,250x |

これは丸め誤差ではない。エンタープライズスケール ——月数百万クエリ —— では、月あたり推論コストが $80 か $100,000 かは、プロジェクトが予算審査を生き残れるかどうかを決める。

モデル価格が下がるにつれてコスト差は縮まるが、検索は常に、ナレッジベース全体を毎回呼び出しに力ずくで投入するより安い。情報理論の法則がこれを保証する：関連情報を選ぶ方が、すべての情報を処理するより安い。

---

## ロングコンテキスト：機能するとき、機能しないとき

ロングコンテキスト window（128K、200K、1M+ トークン）は、特定のユースケースには真に変革的である：

**ロングコンテキストが優れる場面：**
- **静的、有界の文書分析**：単一の契約書、コードベースファイル、研究論文を分析する場合で、関連コーパス全体が window に収まるとき
- **クロスリファレンスタスク**：一度ロードした固定文書群にまたがる繋がりを見つける
- **要約**：大きいが有限の入力を構造化された出力へと凝縮する

**ロングコンテキストが破綻する場面：**

**「Lost in the middle」劣化。** [Liu 他 (2023)](https://arxiv.org/abs/2307.03172) のリサーチが示したところでは、LLM は長コンテキストの中央に置かれた情報に対し、先頭や末尾の情報と比べて著しく劣った性能を示す。その後のモデル改善はこの効果を減らしたが消し去ってはいない。2026 年初頭時点で、関連情報が 500K+ トークンの context に埋もれているとき、モデルは依然として測定可能な精度劣化を示す。

**動的なナレッジベース。** ナレッジベースが時間単位で更新される（製品在庫、サポートチケット、ニュースフィード）なら、context window 全体を毎回再埋め込みすることはできない。RAG の検索ステップは更新を自然に扱う ——新しい文書がインデックスされ、prompt 構造を変えずに即座に検索可能になる。

**マルチテナント分離。** ロングコンテキストアプローチはアクセス制御に苦労する。複数のユーザーや権限レベルの文書が同じコーパスに存在するとき、RAG パイプラインは検索時フィルタリングを強制できる。Context-stuffing は注意深い（そしてエラーの起きやすい）文書分離を要求する。

**スケール時のレイテンシ。** 100 万トークンの処理は 5K トークンの処理より明らかに長くかかる、最適化された推論であっても。応答時間が秒以下である必要があるユーザー向けアプリケーションでは、ターゲット検索が勝つ。

### 2026 年アップデート：Titans + MIRAS がロングコンテキストのトレードオフを再フレーミングする

上記すべての制約は Transformer 風 context window を前提とする：注意で読まれるトークンの平坦なスパン、位置によらず同じトークンあたりコスト、同じ「lost in the middle」失敗モード。**Titans + MIRAS**、Google Research による 2026 年 4 月のアーキテクチャ族は、その前提を破る。Titans では、記憶は注意 window ではなく ——推論中に勾配降下で自身の重みを更新する**訓練可能ニューラルモジュール**である。モデルは長い履歴をトークンとして繰り越すのではなく、文字通り重み更新へと圧縮する。MIRAS はこの「推論しながら学習する」プロセスを安定に保つ訓練レシピを提供する。同程度のパラメータ数で、Google は Titans が Mamba-2、Gated DeltaNet、Transformer++ をロングレンジ想起と多段推論で上回ると報告している。これは元のロングコンテキスト制約を否定するものではない ——GPT-4 Turbo、Gemini 1.5、Claude が引き続き使う注意 window パラダイムには依然として当てはまる —— だが、**「注意バジェットは希少」というフレーミングが、いまや一つのアーキテクチャ族の性質であって、普遍的制約ではない**ことを確立する。実践者にとって、これはロングコンテキストのトレードオフがもはや単一曲線ではないことを意味する。少なくとも 2 つある：注意 window 曲線（lost-in-the-middle とトークンあたりコストが支配的）と訓練可能記憶曲線（コストが推論時の重み更新へとシフトし、失敗モードが安定性と忘却へとシフトする）。RAG はどちらにとっても強いデフォルトだが、RAG が勝つ*理由*は両レジームで異なる。

---

## GraphRAG：フラット検索では足りないとき

標準 RAG は文書を独立したチャンクとして扱う。これは事実検索（「返品ポリシーは何？」）には機能するが、*関係推論* を要する質問（「我々の遅延出荷と品質クレームの両方に繋がるサプライヤーはどこ？」）には失敗する。

[Microsoft の GraphRAG](https://github.com/microsoft/graphrag)（2024–2025）はハイブリッドアプローチを導入した：原文書からナレッジグラフを構築し、グラフ走査をベクトル検索と並行して使ってクエリに答える。

### GraphRAG の仕組み

1. **インデックス段階**：文書からエンティティ（人、組織、概念）とそれらの間の関係を抽出するために処理される。これらが従来のベクトル埋め込みと並んでグラフ構造を形成する。
2. **コミュニティ検出**：グラフは密に接続されたエンティティのコミュニティに分割される。各コミュニティに要約説明が付く。
3. **クエリ段階**：与えられたクエリに対し、ベクトル類似度*と*グラフ走査の両方が関連 context を取得するために用いられる。エンティティ関係が、フラット検索が見逃す多段推論パスを提供する。

### GraphRAG が重要なとき

- **多段クエリ**：「2025 年に上場した企業と買収された企業の共通投資家は誰？」 ——関係連鎖の走査が必要
- **エンティティ中心の推論**：特定のエンティティとその他のエンティティとの繋がりに関する質問
- **グローバル要約**：「我々の顧客フィードバック全体の主要テーマは？」 ——コミュニティ要約がすべての文書を処理せずにこれを提供する

### GraphRAG が過剰なとき

- 単純な事実検索（標準 RAG で十分扱える）
- ロングコンテキストですべて保持できる小規模コーパス
- エンティティ抽出の質が低いユースケース（ゴミを入れればゴミが出る）

GraphRAG のインデックスコストは標準 RAG より著しく高い。グラフは関係推論が中核要件であるときだけ構築すべきで、デフォルトとしてではない。

### 2026 年の進化：ロングコンテキストの意味的バックボーンとしての KG

2024 年から 2025 年の大半を通して、GraphRAG は **RAG への代替** ——限られた context window を持つモデル向けにチャンクを取得する別の方法 —— として枠付けられた。2026 年までにそのフレーミングはシフトした。フロンティアモデルが context window を数百万トークン規模へと押し広げるにつれて（Gemini 1.5 が 100 万、Kimi が 200 万中国語文字超、さらなる拡大が進行中）、問いはもはや「どうやって少数の関連チャンクを検索するか」ではなく「我々が必要とするものの大半を既に保持できるほど大きい context をどうやって航行するか」である。

その世界で、ナレッジグラフは**検索の代替物**であることをやめ、**ロングコンテキストのための構造化インデックス層**となる。グラフはどのチャンクをロードするかを決めるためにあるのではない ——チャンクは既に window 内にある。グラフは、何が window 内にあるかの意味地図をモデルに与えるためにある：どのエンティティが存在するか、どう関連するか、どのセクションがどのトピックに対応するか、どこに矛盾が住むか、どの多段パスが質問を関連証拠に繋ぐか。GraphRAG は、それが生まれた 8K トークン window への回避策としてではなく、エージェントが 100 万トークン window を効率的に歩くことを可能にする**意味的バックボーン**として再登場する。2026 年 4 月の訓練可能記憶モジュール（Titans + MIRAS）の到来はこの役割を置き換えはしない ——初期の証拠はナレッジグラフと訓練可能記憶が本番スタックで**共存し合成される可能性が高い**ことを示し、グラフは訓練可能モジュールが既に重みへ圧縮したものの上に型付けされたクエリ可能な構造を提供する。

---

## 2025–2026 の RAG 技法ランドスケープ

RAG 自体が複数の専門化されたアプローチへと枝分かれした。鍵となる派生：

### Self-RAG（Asai 他, 2023）

[Self-RAG](https://arxiv.org/abs/2310.11511) は、検索が*いつ*必要か、*何を*取得するか、取得したコンテンツが実際に関連するかを決めるようにモデルを訓練する。常に検索する代わりに、モデルは検索プロセスをゲートする特別な「reflection token」を生成する。

**鍵となる利点**：不要な検索呼び出しを減らし、関連しない取得コンテンツを除外、効率と精度の両方を改善する。

### Corrective RAG (CRAG)

[Corrective RAG](https://arxiv.org/abs/2401.15884)（Yan 他, 2024）は検索後に検証ステップを加える。軽量な evaluator が取得文書がクエリに関連するかを評価する。確信度が低ければ、システムは web 検索や代替検索戦略をフォールバックとしてトリガーする。

**鍵となる利点**：主要ナレッジベースが答えを含まないときの優雅な劣化。

### Adaptive RAG

[Adaptive RAG](https://arxiv.org/abs/2403.14403)（Jeong 他, 2024）は、複雑度に応じてクエリを異なる検索戦略にルーティングする分類器を使う。単純なクエリは直接検索を得る。複雑なクエリは chain-of-thought 推論付きの多段検索を得る。曖昧なクエリは結果融合付きの複数検索パスを得る。

**鍵となる利点**：one-size-fits-all パイプラインを使う代わりに、検索コストをクエリ複雑度に合わせる。

### Golden-Retriever RAG

Golden-Retriever RAG は、LLM 自身を使って検索前にクエリを書き換えることで検索品質に焦点を当てる。モデルは「理想的な文書」記述を生成し、これが生のユーザー入力の代わりに検索クエリとして使われる。

**鍵となる利点**：ユーザーが質問する仕方と文書が書かれる仕方の語彙ギャップを埋める。

---

## 「Context Engine」としての RAG

[RAGFlow](https://github.com/infiniflow/ragflow)、オープンソースの RAG エンジンは、2025 年末のレビューで「Retrieval-Augmented Generation」という用語がもはや現代の RAG システムが行うことを捉えていないと論じた。彼らの提案するリフレーム：RAG は検索技法から **Context Engine** ——異種ソースから関連情報をモデルの context window へと組み立てる汎用システム —— へと進化した。

このリフレームは [第 1 章](01-evolution.md) で記述した context engineering の進化と整合する。RAG は単なる「検索して詰める」ではない。現代の RAG システムは：

- クエリの意図と複雑度を分類する
- 適切な検索戦略にルーティングする（ベクトル、キーワード、グラフ、ハイブリッド）
- 結果を再ランクしフィルタする
- 取得コンテンツをトークン予算に合わせて圧縮する
- 適切な構造とメタデータで結果をフォーマットする
- 引用と検証のための来歴を追跡する

これは検索ステップではなく、context 組み立てパイプラインである。RAG システムが context engine *である*。

---

## ハイブリッドアーキテクチャ：収束

2025–2026 年の証拠は明確にハイブリッドアプローチを指している。すべての次元で勝つ単一技法はない：

| 次元 | RAG | Long Context | Knowledge Graph |
|-----------|-----|-------------|----------------|
| クエリあたりコスト | 低 | 高 | 中 |
| 動的更新 | 強 | 弱 | 中 |
| 関係推論 | 弱 | 弱 | 強 |
| セットアップ複雑度 | 中 | 低 | 高 |
| 精度（ターゲット） | 高 | 中 | 高 |
| 精度（グローバル） | 中 | 高 | 高 |

**本番で勝つパターン：**

1. **ナレッジグラフ** ：エンティティ関係とグローバル理解のため
2. **RAG** ：特定クエリに対する動的なターゲット検索のため
3. **ロングコンテキスト** ：完全文書が重要な有界分析タスクのため
4. **Query router** ：クエリごとに適切な戦略を選ぶ

これは机上のものではない。スケールでの本番システム（エンタープライズ検索、コーディングアシスタント、カスタマーサポートエージェント）は 3 つすべてを組み合わせて使う。エンジニアリング課題は一つを選ぶことではない ——各クエリに適切なツールを選ぶ router を構築することである。

---

## 鍵となるプロジェクトとリソース

| プロジェクト | 説明 | リンク |
|---------|-------------|------|
| Microsoft GraphRAG | ナレッジグラフ + RAG ハイブリッド | [github.com/microsoft/graphrag](https://github.com/microsoft/graphrag) |
| RAGFlow | 深い文書理解を伴うオープンソース RAG エンジン | [github.com/infiniflow/ragflow](https://github.com/infiniflow/ragflow) |
| NirDiamant/RAG_Techniques | RAG 実装の包括的コレクション | [github.com/NirDiamant/RAG_Techniques](https://github.com/NirDiamant/RAG_Techniques) |
| LangChain | 充実した RAG ツールを持つフレームワーク | [github.com/langchain-ai/langchain](https://github.com/langchain-ai/langchain) |
| LlamaIndex | LLM アプリケーションのためのデータフレームワーク | [github.com/run-llama/llama_index](https://github.com/run-llama/llama_index) |
| Chroma | オープンソースの埋め込み DB | [github.com/chroma-core/chroma](https://github.com/chroma-core/chroma) |

---

## Sources

- Gartner. "Enterprise RAG Adoption" survey commentary, Q4 2025 — 本章冒頭で引用される 71% リバート数値は複数の業界分析にまたがって流通する。一次アクセスには Gartner サブスクリプションが必要なため、自由に到達可能な一次 URL からではなく、広く引用される業界統計としてここに記載する。
- Liu, N. F. et al. (2023). "Lost in the Middle: How Language Models Use Long Contexts." [arXiv:2307.03172](https://arxiv.org/abs/2307.03172)
- Microsoft. (2024). "GraphRAG: Unlocking LLM discovery on narrative private datasets." [microsoft.com/research](https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-datasets/)
- Asai, A. et al. (2023). "Self-RAG: Learning to Retrieve, Generate, and Critique through Self-Reflection." [arXiv:2310.11511](https://arxiv.org/abs/2310.11511)
- Yan, S. et al. (2024). "Corrective Retrieval Augmented Generation." [arXiv:2401.15884](https://arxiv.org/abs/2401.15884)
- Jeong, S. et al. (2024). "Adaptive-RAG: Learning to Adapt Retrieval-Augmented Large Language Models through Question Complexity." [arXiv:2403.14403](https://arxiv.org/abs/2403.14403)
- RAGFlow. (2025). "Year-End Review: From RAG to Context Engine." [github.com/infiniflow/ragflow](https://github.com/infiniflow/ragflow)
- NirDiamant. (2025). "RAG Techniques." [github.com/NirDiamant/RAG_Techniques](https://github.com/NirDiamant/RAG_Techniques)
- Google Research. (April 2026). "Titans + MIRAS: Helping AI Have Long-Term Memory." [research.google/blog/titans-miras-helping-ai-have-long-term-memory/](https://research.google/blog/titans-miras-helping-ai-have-long-term-memory/) — 同程度サイズで Mamba-2 / Gated DeltaNet / Transformer++ を上回る訓練可能記憶モジュール。

---

*前の章: [第 1 章 — 3 つの世代](01-evolution.md)*

*次の章: 第 3 章 — Context Engineering Deep Dive (近日)*
