はじめに
ChatGPTのようなLLM（大規模言語モデル）を業務で使おうとすると、必ずぶつかる壁があります。
「LLMはうちの社内文書のことなんて知らない…」
これを解決する定番技術が RAG（Retrieval-Augmented Generation：検索拡張生成） です。そして最近、その進化版として Graph RAG が注目されています。
この記事では、「RAGは聞いたことあるけど、Graph RAGって何が違うの？」 という人向けに、数式なし・図解多めで両者の違いを解説します。
そもそもRAGとは？
一言でいうと
「LLMに答えさせる前に、関連する資料を検索して渡してあげる仕組み」 です。
人間に例えるとこうなります。
| 例え | |
|---|---|
| LLM単体 | 記憶だけで答える人（うろ覚え・知らないことは適当に答えがち） |
| RAG | 図書館で本を数冊持ってきてから答える人 |
RAGの仕組み
処理の流れは3ステップです。
- 事前準備：社内文書などを数百文字ごとの「チャンク（かたまり）」に分割し、ベクトル（意味を表す数値の並び）に変換してDBに保存する
- 検索：質問が来たら、質問と「意味が近い」チャンクを上位k件（例：5件）取ってくる
- 生成：質問と取ってきたチャンクをまとめてLLMに渡し、回答を作らせる
ポイントは、検索が 「質問文とチャンクの意味的な近さ」 だけで行われることです。これが後述する弱点につながります。
RAGが得意な質問
- 「有給休暇の申請方法は？」
- 「製品Xの保証期間は？」
答えが どこか1〜2箇所のチャンクに書いてある タイプの質問です。「有給休暇 申請」で検索すれば、就業規則の該当箇所がヒットしますよね。これはRAGの独壇場です。
RAGの弱点
では、こんな質問はどうでしょう？
弱点1：点と点をつなぐ質問（マルチホップ質問）
「田中さんの上司が担当しているプロジェクトの予算は？」
答えを出すには、
- 田中さんの上司は佐藤さん（人事資料に記載）
- 佐藤さんの担当はプロジェクトA（体制図に記載）
- プロジェクトAの予算は5000万円（予算資料に記載）
と 複数の文書をリレーのようにたどる 必要があります。しかし「田中さんの上司が担当しているプロジェクトの予算」という質問文とベクトルが近いチャンクを探しても、この3つの資料が都合よく全部ヒットするとは限りません。特に「プロジェクトAの予算は5000万円」というチャンクには田中さんの名前が一切登場しないため、検索に引っかからないのです。
弱点2：全体を見渡す質問
「この文書群全体の主要なテーマは何？」
RAGは「関連する数件のチャンク」しか見ません。全体を俯瞰する質問には、そもそも「これを読めば分かる」というチャンクが存在しない ので、断片的な回答しかできません。1000ページの資料から5ページだけ拾い読みして「全体の要約をして」と言われても無理がありますよね。
Graph RAGとは？
一言でいうと
「文書を細切れの山ではなく、知識のつながり（グラフ）として整理してから検索するRAG」 です。
再び人間に例えると：
| 例え | |
|---|---|
| RAG | 図書館でキーワード検索して本を持ってくる人 |
| Graph RAG | 事前に登場人物の相関図と目次・あらすじを作っておき、それをたどって答える人 |
何が変わるのか：インデックスの作り方
Graph RAG最大の特徴は 事前準備の段階 にあります。文書をチャンクに切るところまでは同じですが、そこからLLMを使って 「エンティティ（人・組織・モノ）」と「関係」を抽出 し、ナレッジグラフ を作ります。
元の文書：
田中は営業部に所属している。営業部の部長は佐藤である。佐藤はプロジェクトAの責任者を務めており、プロジェクトAの予算は5000万円だ。
これがグラフになると：
文章の中に埋もれていた「つながり」が、明示的な線 として取り出されているのが分かるでしょうか。
さらに（Microsoft版のGraphRAGでは）、グラフ上で仲良しグループ＝ コミュニティ を自動検出し、それぞれに 要約文 をLLMで作っておきます。「営業関連の話題グループ」「開発関連の話題グループ」のような、文書群全体の目次＋あらすじ集 ができるイメージです。
検索はどう変わる？
マルチホップ質問 → グラフをたどる
「田中さんの上司が担当しているプロジェクトの予算は？」なら、
田中 →（所属）→ 営業部 →（部長）→ 佐藤 →（責任者）→ プロジェクトA →（予算）→ 5000万円
と 線をたどるだけ で必要な情報が全部集まります。バラバラの文書に散らばっていた情報が、グラフ上では隣同士になっているからです。
全体俯瞰の質問 → コミュニティ要約を使う
「全体の主要テーマは？」なら、事前に作っておいた 各コミュニティの要約 をLLMに渡して統合すればOK。個別チャンクを探し回る必要がありません。
違いをまとめて比較
| 観点 | RAG | Graph RAG |
|---|---|---|
| データの持ち方 | チャンク（細切れテキスト）の山 | ナレッジグラフ＋コミュニティ要約（＋チャンク） |
| 検索方法 | 質問との意味的な近さ | グラフをたどる／要約を使う |
| 単純なQ&A | ◎ 得意 | ○（できるがオーバースペック気味） |
| マルチホップ質問 | △ 苦手 | ◎ 得意 |
| 全体俯瞰・要約 | ✕ ほぼ無理 | ◎ 得意 |
| 事前準備のコスト | 低い（埋め込み計算だけ） | 高い（LLMで全文書から抽出・要約） |
| 運用の複雑さ | シンプル | 複雑（グラフの更新・管理が必要） |
じゃあ全部Graph RAGにすればいい？
No です。ここが実務では一番大事なポイント。
Graph RAGは事前準備で 全チャンクに対してLLMを回す ため、構築コスト（お金と時間）がRAGより桁違いにかかります。文書が更新されるたびにグラフのメンテナンスも必要です。
使い分けの目安：
- 「〜の手順は？」のような一問一答が中心 → 普通のRAGで十分
- 情報が複数文書にまたがる質問や、「全体として〜」という質問が多い → Graph RAGを検討
- 実際のプロダクトでは 両方をハイブリッド で使うことも多い
まとめ
- RAG ＝ 質問に意味が近いチャンクを検索してLLMに渡す。単純なQ&Aに強いが、情報のつながりと全体像に弱い
- Graph RAG ＝ 文書からナレッジグラフを構築し、関係をたどる検索とコミュニティ要約で弱点を克服。ただし構築コストが高い
- 例えるなら、RAGは「キーワード検索で本を持ってくる人」、Graph RAGは「相関図とあらすじ集を用意している人」
- 万能薬ではないので、質問の種類でRAGと使い分けるのが実務の正解
参考
- Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks" (2020) — RAGの原典
- Edge et al., "From Local to Global: A Graph RAG Approach to Query-Focused Summarization" (2024) — Microsoft GraphRAGの論文
- microsoft/graphrag (GitHub)