GraphRAGを実際に構築して分かった「使うほど賢くなるAI」の仕組み
はじめに ─ 「AIに文書を読ませる」だけでは足りなかった
最近、「社内の文書をAIに読ませて質問に答えさせる」という仕組みを耳にする機会が増えました。いわゆる RAG（Retrieval Augmented Generation） です。
これ、確かに便利なんです。マニュアルや規則集をAIに渡しておけば、「この手続きどうやるの？」と聞くだけで答えが返ってくる。
でも、実際に数千件のドキュメントを扱うシステムを作ってみて気づいたことがあります。
「文書を読ませる」だけでは、AIは賢くならない。
人間が知識を使うとき、「AならばB、BならばC」と 知識のつながり を辿って考えますよね。でも従来のRAGは、関連しそうな文書の断片を探してくるだけ。点 は見つけられても、点と点のつながり は見えていません。
この記事では、「AIに本を渡す」のではなく 「AIに知識の地図を渡す」 仕組み ── GraphRAG について、実際に構築・運用して分かったことをまとめます。
そもそもRAGとは？何ができるのか
まずはRAGの仕組みをおさらいしましょう。
- ドキュメントを小さな断片（チャンク）に分割して、ベクトルDBに格納
- ユーザーの質問を同じくベクトル化して、似ている断片を検索
- 見つかった断片をLLMに渡して回答を生成
RAGが得意なこと：
- 「在宅勤務の申請方法は？」→ 該当するマニュアルを見つけてピンポイント回答
- 「経費精算の上限額は？」→ 規程から正確な数字を引用
シンプルで強力。多くのユースケースでこれで十分です。
でも、こんな質問には答えられない
| 質問の種類 | 具体例 | RAGの限界 |
|---|---|---|
| バージョン追跡 | 「旅費規程が改正されたけど、出張精算のやり方は変わった？」 | 最新版は見つかるが、何が変わって何に影響するかは追えない |
| 多段推論 | 「この通知の根拠法令が最近改正されたか確認して」 | 通知→根拠法令→改正履歴の3段階を辿れない |
| 全体俯瞰 | 「今年の規則変更を全体的にまとめて」 | top-kチャンクのつぎはぎで、網羅性がない |
ドキュメントが数百件ならまだ何とかなります。でも 数千件規模 になると、似たような断片が大量にヒットして、本当に必要な情報が埋もれる ── いわゆる ノイズ問題 が顕在化します。
GraphRAGとは何か
GraphRAGは、RAGの仕組みに ナレッジグラフ（知識グラフ） を組み合わせたアーキテクチャです。
ナレッジグラフって？
ナレッジグラフとは、知識を ノード（点） と エッジ（線） で表現したものです。
[旅費規程] ──改正──→ [旅費規程 v2]
│ │
│ 根拠 │ 根拠
↓ ↓
[出張精算マニュアル] [出張精算マニュアル v2]
│
│ 参照
↓
[経費精算システム操作手順]
人間が「この規程が変わったから、あのマニュアルも確認しなきゃ」と考えるのと同じ構造を、データとして持ちます。
GraphRAGの4層構造
| 層 | 役割 | 従来RAGとの違い |
|---|---|---|
| Document | 元ファイルのメタデータ | RAGと同じ |
| Chunk | テキスト断片 + ベクトル | RAGと同じ |
| Entity | 文書から抽出された「知識」 | GraphRAG独自 |
| Community | 知識の自動グルーピング | GraphRAG独自 |
従来RAGは上の2層だけ。GraphRAGは Entity層 と Community層 が加わることで、「知識と知識のつながり」を表現できるようになります。
従来RAG vs GraphRAG 比較
| 項目 | 従来RAG | GraphRAG |
|---|---|---|
| 検索方式 | ベクトル類似度（top-k） | グラフ走査 + ベクトル |
| 検索単位 | チャンク（テキスト断片） | エンティティ + チャンク |
| 関係性の理解 | なし | あり（エッジで表現） |
| 全体俯瞰 | 苦手（断片の寄せ集め） | 得意（コミュニティサマリー） |
| ノイズ耐性 | 文書増加で劣化 | グラフ構造で絞り込み |
| 初期構築コスト | 低い | 高い（グラフ構築が必要） |
| 得意な質問 | 事実確認 | 関係性・全体像・推論 |
プロンプトで体感する「RAGの限界」と「GraphRAGの強さ」
同じ質問をRAGとGraphRAGに投げたとき、回答がどう変わるか見てみましょう。
例1：単純な質問 ── 両方とも回答可能
プロンプト： 「在宅勤務の申請方法を教えてください」
RAGの回答：
在宅勤務を希望する場合は、所属長の承認を得た上で、
勤怠管理システムから「在宅勤務申請」を提出してください。
申請は勤務日の前日17時までに行う必要があります。
（参照: 在宅勤務規程 第5条）
GraphRAGの回答：
在宅勤務を希望する場合は、所属長の承認を得た上で、
勤怠管理システムから「在宅勤務申請」を提出してください。
申請は勤務日の前日17時までに行う必要があります。
（参照: 在宅勤務規程 第5条）
こういうピンポイントの質問では、違いはほぼありません。RAGで十分です。
例2：関係性が必要な質問 ── RAGの限界が見える
プロンプト： 「旅費規程が4月に改正されたけど、出張精算のやり方は変わった？」
RAGの回答：
旅費規程（2026年4月改正版）では、日当の上限額が以下の通り
変更されました。
- 国内出張：8,000円 → 10,000円
- 海外出張：12,000円 → 15,000円
（参照: 旅費規程 第12条）
→ 旅費規程の最新版は見つかりますが、出張精算マニュアルへの影響 には触れていません。
GraphRAGの回答：
旅費規程の4月改正に伴い、以下の影響があります。
■ 旅費規程の変更点
- 日当上限額の引き上げ（国内8,000→10,000円、海外12,000→15,000円）
■ 出張精算マニュアルへの影響
- 精算フォームの「日当欄」上限値が変更されています
- 4月以前に申請済みの出張は旧規程が適用されます
■ 経費精算システムの対応状況
- システム側の上限設定は4/15に更新予定（情報システム課通知 No.2026-031）
⚠ 4/1〜4/14の期間は手動で上限額を確認してください。
（参照: 旅費規程 第12条, 出張精算マニュアル 3.2節,
情報システム課通知 No.2026-031）
→ 旅費規程 → 出張精算マニュアル → システム操作手順 のグラフ関係を辿って、影響範囲を横断的に回答 しています。
例3：全体俯瞰の質問 ── RAGでは不可能
プロンプト： 「今年のコンプライアンス関連の規則変更を全体的にまとめてください」
RAGの回答：
コンプライアンスに関連する記述が見つかりました。
- 情報セキュリティポリシーにおいて、外部メディアの持ち込みが禁止されました
- ハラスメント防止規程が改定され...
（以下、関連度が高い順にチャンクを並べただけ）
→ top-kで拾ったチャンクの寄せ集め。抜け漏れがあるかも分からない。
GraphRAGの回答：
2026年度のコンプライアンス関連の規則変更を、分野別に整理します。
【1. 情報セキュリティ】（3件の変更）
- 外部メディア持ち込み禁止（4月〜）
- クラウドサービス利用基準の改定（5月〜）
- ログ保存期間の延長: 1年→3年（6月〜）
【2. ハラスメント防止】（2件の変更）
- SOGIハラスメントの定義追加（4月〜）
- 相談窓口の外部委託化（7月〜）
【3. 内部統制】（1件の変更）
- 決裁権限の見直し（100万円→50万円に引き下げ）
計6件の変更があり、特に情報セキュリティ分野の変更が集中しています。
→ Community層のサマリー を使って体系的に整理。これがGraphRAGの真骨頂です。
なぜ「使うほど賢くなる」のか
GraphRAGの最大の特徴は、ドキュメントが追加されるたびにグラフが成長し、回答の質が上がっていく ことです。
知識の自動循環ループ
ポイントは MENTIONS自動リンク です。新しいドキュメントを追加すると、テキスト中に既存のエンティティ名が含まれているかを自動でチェックし、関係を張ります。
つまり、ファイルを置くだけで、既存の知識と自動的につながる。
同じ質問を3回聞いたら、回答はこう変わる
具体例で見てみましょう。社内の「出張精算」について質問します。
プロンプト（毎回同じ）： 「出張精算の手続きを教えて」
1回目：社内規則集だけが登録されている状態
出張精算は以下の手順で行います。
1. 出張報告書を作成
2. 領収書を添付
3. 所属長の承認を取得
4. 経費精算システムで申請
（参照: 出張精算マニュアル 第3章）
→ 基本的な手順だけ。マニュアル通りの回答です。
2回目：1ヶ月後、旅費規程の改正通知が追加された
出張精算は以下の手順で行います。
1. 出張報告書を作成
2. 領収書を添付
3. 所属長の承認を取得
4. 経費精算システムで申請
⚠ 重要：2026年4月の旅費規程改正により、以下が変更されています。
- 日当上限額が引き上げ（国内8,000→10,000円）
- 4月以前申請分は旧規程が適用
改正前後で精算額が異なる場合がありますのでご注意ください。
（参照: 出張精算マニュアル 第3章, 旅費規程改正通知 2026-04）
→ 改正通知がグラフに追加されたことで、旅費規程改正 → 出張精算マニュアル の関係が生まれ、改正の影響を含む回答に進化 しました。
3回目：さらに1ヶ月後、社内QA集が追加された
出張精算は以下の手順で行います。
1. 出張報告書を作成
2. 領収書を添付
3. 所属長の承認を取得
4. 経費精算システムで申請
⚠ 2026年4月の旅費規程改正により日当上限額が変更されています。
💡 よくある質問（社内QAより）：
- Q: 4月をまたぐ出張の場合、日当はどちらの規程？
A: 出張開始日の規程が適用されます
- Q: 海外出張の為替レートはいつ時点？
A: 帰国日の社内レート（毎月初更新）を使用
- Q: タクシー利用はどこまで認められる？
A: 終電後または荷物20kg超の場合。事前承認が必要。
（参照: 出張精算マニュアル, 旅費規程改正通知, 社内QA集 #精算）
→ QA集の追加により、実務レベルのアドバイスまで回答 できるようになりました。
誰も回答テンプレートを更新していません。 ドキュメントを追加しただけで、グラフ構造が成長し、AIが自動的に関連知識を結びつけた結果です。
コミュニティ検出 ─ AIが知識を自動で整理する
GraphRAGのもう一つの重要な機能が コミュニティ検出 です。
「似た知識」が自動でグループ化される
エンティティ間の関係性を分析し、密に関連するもの同士を自動でグルーピングします。使われるのは Leidenアルゴリズム という手法です。
直感的に言うと：
SNSの友人関係から「このグループは同じ部活の仲間っぽいな」と自動で見抜くようなもの。知識同士の関係の濃さから、テーマの近いもの同士がまとまります。
3階層のコミュニティ
| レベル | 粒度 | Leidenのgamma | 用途 |
|---|---|---|---|
| Level 0 | 細かい（個別トピック） | 1.5 | 具体的な質問への回答 |
| Level 1 | 中程度（テーマ群） | 0.7 | テーマ横断の質問 |
| Level 2 | 粗い（大分類） | 0.3 | 全体俯瞰の質問 |
Local Search と Global Search
この階層構造により、GraphRAGは2種類の検索モードを使い分けます。
Local Search（具体的な質問向け）
- エンティティのベクトル検索 → 1-hop近傍のグラフ走査 → 関連チャンク取得
- 「出張精算の手続きは？」のようなピンポイント質問に最適
Global Search（全体俯瞰の質問向け）
- Community層のサマリーを検索 → Level1-2のコミュニティを収集 → map-reduceで統合回答
- 「今年の変更をまとめて」のような俯瞰的な質問に対応
先ほどの「コンプライアンス関連の変更をまとめて」という質問に答えられたのは、この Global Search + Community層 のおかげです。
どんなケースで使うべきか
「じゃあ全部GraphRAGにすればいいの？」と思うかもしれませんが、そうではありません。
こんなときはRAG
| ユースケース | 例 | RAGで十分な理由 |
|---|---|---|
| 社内FAQ | 「有給の申請方法は？」「Wi-Fiのパスワードは？」 | 1つの文書内で回答が完結する |
| 製品マニュアル検索 | 「エラーコードE-301の対処法は？」 | 独立したFAQ・トラブルシューティング |
| 契約書の条項確認 | 「解約の通知期限は何日前？」 | 特定の文書から事実を抽出するだけ |
| 議事録の検索 | 「先月の会議で決まった納期は？」 | 日付と内容でピンポイント検索 |
| カスタマーサポート | 「返品の手順を教えて」 | 手順書から該当箇所を返すだけ |
共通点： 質問と回答が1対1で対応しており、文書間の関係性を辿る必要がない。
こんなときはGraphRAG
| ユースケース | 例 | GraphRAGが必要な理由 |
|---|---|---|
| 法令・規則の体系管理 | 「この通知の根拠法令は改正されてる？」 | 法律→政令→通知→マニュアルの階層を辿る必要がある |
| 改正の影響分析 | 「旅費規程の改正で、他に影響を受ける手続きは？」 | 規程→関連マニュアル→システム手順の連鎖を追跡 |
| 組織横断のナレッジ | 「この案件に関連する過去の対応事例を全部出して」 | 複数部署・複数年度の文書を関係性で結びつける |
| バージョン追跡 | 「このマニュアルは最新版？前回から何が変わった？」 | 文書の改廃関係（旧版→新版→廃止）を管理 |
| 全体俯瞰レポート | 「今年度のセキュリティ関連の変更を一覧にして」 | コミュニティサマリーで体系的に網羅 |
| 投資分析の知識蓄積 | 「以前この銘柄を分析したとき、どんな懸念があった？」 | 分析履歴→銘柄→業界→マクロ環境の関係を辿る |
共通点： 「AとBの関係は？」「全体的にどうなってる？」のように、複数文書を横断した推論が求められる。
判断フローチャート
GraphRAGのデメリット
GraphRAGは万能ではありません。導入前に知っておくべきコストがあります。
| デメリット | 詳細 |
|---|---|
| 初期構築コストが高い | エンティティの定義、関係性の設計、抽出パイプラインの構築が必要。RAGなら「チャンク分割してベクトルDBに入れる」だけで動くが、GraphRAGはグラフスキーマの設計から始まる |
| 関係性の維持に仕組みが必要 | ドキュメントが追加・更新されるたびに、エンティティ抽出→関係性構築→コミュニティ再検出のパイプラインを回す必要がある。自動化しないと運用が破綻する |
| グラフの品質がそのまま回答品質 | エンティティの抽出精度が低い、関係性の定義が雑だと、RAGより回答品質が悪くなることもある。「ゴミを入れればゴミが出る」はグラフでも同じ |
| インフラが増える | ベクトルDBに加えてグラフDB（Neo4j等）が必要。運用・監視の対象が増える |
| LLMコスト（構築時） | Microsoft GraphRAG等ではエンティティ抽出にLLMを使うため、グラフ構築時にトークンコストが発生する（クエリ時は逆に節約できる） |
一言でまとめると、「関係性を維持するための仕組みを構築する分、RAGよりも構築コストがかかる」 ── これがGraphRAG最大のデメリットです。
逆に言えば、この構築コストを払う価値があるかどうかが、RAG / GraphRAGの選定基準になります。
段階的アプローチのすすめ
だからこそ、いきなりGraphRAGを構築する必要はありません。
- Phase1（最初の数ヶ月）： RAGで運用開始。メタデータ（カテゴリ、バージョン、有効日）は豊富に付けておく
- Phase2（運用データが溜まってから）： RAGで答えられなかった質問を分析し、GraphRAG層を追加
RAGからGraphRAGへの移行は 追加型 です。既存のベクトルDBはそのまま使えます。Phase1でメタデータを豊富に付けておけば、Phase2でのグラフ構築がスムーズになります。
使えるライブラリ・サービスまとめ
GraphRAGを実装する選択肢は急速に増えています。
OSSライブラリ
| 名前 | 提供元 | 特徴 | おすすめ用途 |
|---|---|---|---|
| Microsoft GraphRAG | Microsoft Research | 自動KG生成、Leiden検出、Local/Global Search | フルスペックで試したい |
| LightRAG | 香港大学 | GraphRAGの1/6000トークン消費、インクリメンタル更新 | コスト重視・高速 |
| nano-graphrag | OSS | Microsoft GraphRAGの軽量版、コードがシンプル | 学習・プロトタイプ |
| Neo4j + LangChain | Neo4j / LangChain | Cypher自動生成、グラフDB本格運用 | 本格プロダクション |
| FalkorDB + LangGraph | FalkorDB | インメモリグラフDB、超高速クエリ | リアルタイム処理 |
| LlamaIndex PropertyGraph | LlamaIndex | PropertyGraphIndex、複数DB対応 | LlamaIndexユーザー |
マネージドサービス
| サービス | 提供元 | 特徴 |
|---|---|---|
| Amazon Bedrock + Neptune | AWS | フルマネージドGraphRAG（2025年3月GA） |
| Azure Cosmos DB AI Graph | Microsoft | CosmosDB上でグラフ+ベクトル統合 |
| LazyGraphRAG | Microsoft Research | GraphRAGの0.1%コスト（科学研究向け） |
| Neo4j AuraDB + GenAI | Neo4j | マネージドNeo4j + GraphRAGテンプレート |
筆者は Neo4j + 自前パイプライン で構築しました。最も自由度が高いですが、その分エンティティ抽出や関係定義は自前で設計する必要があります。「まず試してみたい」なら Microsoft GraphRAG か LightRAG から始めるのがおすすめです。
実装アーキテクチャ（エンジニア向け）
ここからは技術的な詳細です。
全体構成
グラフスキーマ
ノード:
Document { id, title, source_path, category, embedding[768] }
Chunk { id, text, chunk_index, token_estimate, embedding[768] }
Entity { id, name, type, description, embedding[768] }
Community { id, level, title, summary, rank, embedding[768] }
リレーション:
Document -[:HAS_CHUNK]-> Chunk
Chunk -[:NEXT_CHUNK]-> Chunk # 順序保持
Chunk -[:MENTIONS]-> Entity # テキスト中に出現
Entity -[:RELATES_TO {type}]-> Entity # 意味的関係
Entity -[:BELONGS_TO {level}]-> Community
Community -[:CHILD_OF]-> Community # 階層構造
チャンク分割パラメータ
CHUNK_SIZE = 512 # トークン目安
CHUNK_OVERLAP = 50 # オーバーラップ
CHAR_PER_TOKEN = 1.5 # 日本語の場合
境界は文末（。、\n\n、\n）で区切り、文の途中で切れないよう配慮します。
ベクトルインデックス設定（Neo4j Cypher）
-- ベクトル検索（768次元, cosine類似度）
CREATE VECTOR INDEX entity_embeddings
FOR (e:Entity) ON (e.embedding)
OPTIONS {indexConfig: {
`vector.dimensions`: 768,
`vector.similarity_function`: 'cosine'
}}
-- 全文検索
CREATE FULLTEXT INDEX entity_fulltext
FOR (e:Entity) ON EACH [e.name, e.description]
Local SearchのCypher例
-- 1. クエリベクトルで類似エンティティを検索
CALL db.index.vector.queryNodes('entity_embeddings', 10, $query_embedding)
YIELD node AS entity, score
-- 2. 1-hop近傍を走査
MATCH (entity)-[r:RELATES_TO]-(neighbor:Entity)
-- 3. 関連チャンクを取得
MATCH (chunk:Chunk)-[:MENTIONS]->(entity)
-- 4. コミュニティ情報を付加
MATCH (entity)-[:BELONGS_TO]->(comm:Community)
WHERE comm.level <= 1
RETURN entity, collect(DISTINCT neighbor) AS neighbors,
collect(DISTINCT chunk)[..3] AS topChunks,
collect(DISTINCT comm) AS communities
ORDER BY score DESC LIMIT 5
トークン効率 ─ 精度とコストの両立
GraphRAGの見落とされがちなメリットが トークン効率 です。
| 指標 | 従来RAG | GraphRAG |
|---|---|---|
| 1クエリあたりのコンテキスト | 2,500〜5,000トークン | 500〜2,000トークン |
| 精度を上げる方法 | top-kのkを増やす（コスト増） | グラフ走査の深さ調整（コスト微増） |
| 精度とコストの関係 | 比例（精度↑ = コスト↑） | 非線形（精度↑ ≠ コスト↑） |
なぜ少ないトークンで高精度？
従来RAGは「関連しそうなチャンクをたくさん渡して、LLMに判断させる」アプローチ。渡すチャンクが増えるほどトークンが増えます。
GraphRAGは「グラフを辿って、本当に必要なチャンクだけをピンポイントで取得する」アプローチ。ノイズとなるチャンクがそもそも含まれない ため、少ないトークンで高精度を実現できます。
これは特に APIの従量課金 が発生する本番環境で効いてきます。
まとめ
GraphRAGを実際に構築してみて、最も実感したのは以下の3点です。
1. GraphRAGは「知識に構造を与える」技術
ドキュメントをテキストの断片としてではなく、知識のネットワーク として扱う。それだけで、AIの回答品質は劇的に変わります。
2. 使うほど賢くなるのは「嘘」じゃない
ドキュメントを追加するたびにグラフが成長し、既存の知識と自動的につながる。同じ質問でも、背景知識が増えれば回答の深さが変わる。複利で知識が効く世界 です。
3. まずはRAGから、限界を感じたらGraphRAGへ
いきなりGraphRAGを構築する必要はありません。RAGで運用を始め、「文書間の関係性が追えない」「全体像を聞く質問に答えられない」と感じたタイミングで、GraphRAG層を追加する 段階的アプローチ が現実的です。
Discussion