RAGの検索精度、GraphDBを足したら変わるかもしれない

RAGの検索精度、GraphDBを足したら変わるかもしれない

こんにちは、サーバーワークスで生成AIの活用推進を担当している針生です。

社内RAGに「今期のAプロジェクトの関連資料と担当者を見せて」と聞いたのに、返ってきたのは的外れな結果だった。そんな経験、ありませんか？

RAGにベクトル検索を組み合わせるアーキテクチャは、もはや珍しいものではありません。社内ドキュメントをチャンク分割し、ベクトル表現に変換してベクトルDBに格納。ユーザーの質問もベクトル表現に変換し、意味的に近い文書を検索してLLMに渡す。この仕組みは「何について書かれた文書か」を探すのに適しています。

しかし、組織のナレッジにはもう一つの軸があります。「この文書は誰が書いたのか」「どのプロジェクトに紐づくのか」「このプロジェクトにはどの部署が関わっているのか」。文書の中身だけではなく、文書と人、文書とプロジェクト、人と部署といった「つながり」の方にこそ、組織固有の価値が眠っています。

この記事では、ベクトル検索だけでは捉えきれない「関係性」を、GraphDB（グラフデータベース）で補完するハイブリッドなRAGアーキテクチャ GraphRAG について解説します。

なぜベクトル検索だけでは不十分なのか

ベクトル検索の限界を、2つの具体的なシーンで見てみましょう。

「Aプロジェクトの関連ドキュメントと担当者を教えて」

社内RAGに「Aプロジェクトの関連ドキュメントと担当者を教えて」と質問したとします。ベクトル検索は、「Aプロジェクト」「ドキュメント」「担当者」といったキーワードと意味的に近い文書を返してくれます。Aプロジェクトについて言及している議事録や、設計書の一部が候補に上がるかもしれません。

しかし、返ってきた文書の中に「担当者は田中さん」と明示的に書かれていなければ、担当者の情報は得られません。Aプロジェクトの担当者が田中さんであるという事実は、人事システムやプロジェクト管理ツールの中にあり、文書ベクトルには含まれていないからです。ベクトル検索は「文書の中身」を探しているのであって、「文書の外側にある関係性」は検索対象に入っていません。

「今期の○○について」

もう一つ、より厄介な例があります。「今期の売上に関するドキュメントを見せて」と聞いたとき、RAGは「今期」「売上」という意味に近い文書を探します。しかし、ここに落とし穴があります。

たとえば、私が所属する株式会社サーバーワークスは2月決算です。「今期」は3月から翌年2月を指しますが、3月決算の一般的な企業とは期間がずれています。ベクトル検索にとって「今期」はあくまでテキストの意味的な表現にすぎず、「サーバーワークスの今期は2026年3月〜2027年2月である」という組織固有のルールは、ベクトルのどこにも含まれていません。

プロンプトで毎回期間を指定しないと誤った結果が返ってくることになります。

ベクトル検索の限界

これらの例から見えてくるのは、ベクトル検索の本質的な限界です。

• 意味的類似性 ≠ 構造的関係性：文書が似ていることと、文書がプロジェクトや人に紐づいていることは別の話です
• 組織の暗黙知を扱えない：会計期間の定義、部署構造、プロジェクトの担当関係など、組織固有のルールやコンテキストはベクトルには含まれません

では、この「つながり」をどう表現し、検索に組み込めばよいのでしょうか。ここで登場するのがグラフデータベースです。

GraphDBとは何か

グラフデータベース（GraphDB）は、データを「ノード」と「エッジ」で表現するデータベースです。ノードがエンティティ（人、部署、プロジェクト、ドキュメントなど）を、エッジがエンティティ間の関係を表します。各ノードとエッジにはプロパティ（属性情報）を持たせることができます。

RDB（リレーショナルデータベース）でも外部キーとJOINで関係性を表現できますが、「田中さんが所属する部署が関わっているプロジェクトに紐づくドキュメント」のような多段階のつながりをたどるクエリは、JOINが深くネストし、パフォーマンスも可読性も落ちます。GraphDBはこうした「関係性をたどる」操作に特化して設計されており、何段階の関係をたどっても一定のパフォーマンスで結果を返せます。

組織ナレッジとの相性

組織のナレッジは、本質的にグラフ構造をしています。

組織ナレッジのグラフ構造イメージ

人は部署に所属し、プロジェクトを担当し、プロジェクトにはドキュメントが紐づく。会社には固有の会計期間がある。これらの関係は、テーブルの行や列よりも、ノードとエッジで表現する方が直感的です。

そして、この構造がそのまま「検索の経路」になります。「Aプロジェクトの担当者は？」という問いに、グラフをたどるだけで答えられます。ベクトル検索のように文書の中身を探す必要はありません。

GraphRAGという考え方

ベクトル検索の限界が見えてきたところで、「ならばGraphDBだけで検索すればいいのでは？」と思うかもしれません。しかし、GraphDBだけでも不十分です。グラフは構造化された関係性をたどるのは得意ですが、「この文書の内容はあのトピックと意味的に近い」といった非構造的な類似性の発見は苦手です。

つまり、ベクトル検索とGraphDBにはそれぞれ得意領域があります。

	得意なこと	苦手なこと
ベクトル検索	意味的に似た文書を探す	エンティティ間の関係性をたどる
GraphDB	構造化された関係性をたどる	非構造的な類似性を発見する

この2つを組み合わせるのがGraphRAGの基本的な考え方です。

先行事例が示す効果

GraphRAGというアプローチは、すでに複数のリサーチや実装で有効性が確認されています。

Microsoftは2024年にGraphRAGをOSSとして公開しました。LLMを使ってテキストからエンティティと関係を自動抽出し、ナレッジグラフを構築する仕組みです。ベースラインのRAGと比較して、回答の包括性（Comprehensiveness）の評価で大幅な改善が報告されています。

他にも、ベクトル検索とグラフ検索の相互補完で事実の正確性が改善されたという報告（Basu et al., 2024）や、知識グラフがベクトル検索にはない「明示的な推論パス」と「監査可能な推論プロセス」を提供できるという主張（Belova et al., 2026）など、GraphRAGの有効性を裏付ける研究が蓄積されつつあります。

ハイブリッドRAGの処理フロー

では、具体的にどのような処理フローになるのでしょうか。以下の図に全体像を示します。

ハイブリッドRAGの処理フロー

まず、データの準備段階では2つの処理を並行して行います。

1. ドキュメントをチャンク分割し、ベクトル表現に変換してベクトルDBに格納する（従来のRAGと同じ）
2. ドキュメントからエンティティ（人、プロジェクト、部署など）と関係性を抽出し、グラフDBに格納する

次に、クエリの処理段階です。

1. ユーザーの質問を受け取る
2. ベクトル検索で意味的に関連する文書チャンクを取得する
3. 取得したチャンクに含まれるエンティティを起点に、グラフDBで関連するエンティティや関係性を探索する（たとえば、2ホップ以内の関連情報を収集）
4. ベクトル検索の結果とグラフ探索の結果を合わせて、コンテキストとしてLLMに渡す
5. LLMが両方の情報を統合して回答を生成する

このフローによって、「意味的に近い文書」と「構造的につながっている情報」の両方を活用した回答が可能になります。

組織固有のコンテキストをグラフで表現する

ここからは、冒頭のシーンに立ち返って、GraphDBがどのように組織固有の課題を解決するのかを具体的に見ていきます。

「今期」問題の解決

「今期」問題の解決フロー

サーバーワークスのような2月決算の会社で「今期のドキュメントを見せて」と聞かれたとき、ベクトル検索だけでは期間を正しく解釈できません。しかし、グラフに会社の会計期間を定義しておけば、この問題は解決できます。

グラフ上に「サーバーワークス」というノードがあり、「会計期間」というエッジで「第N期: 2026-03-01〜2027-02-28」というノードにつながっている状態を考えます。ユーザーが「今期」と言ったとき、まずグラフを参照して「今期 = 2026年3月〜2027年2月」を解決し、その期間をベクトル検索のメタデータフィルタとして適用します。こうすることで、ベクトル検索が返す文書は正しい期間に絞り込まれます。

グラフが「辞書」として機能し、組織固有の語彙を検索可能な条件に変換するわけです。

プロジェクト横断検索の解決

プロジェクト横断検索 ― グラフ探索 × ベクトル検索

もう一つの課題だった「Aプロジェクトの関連ドキュメントと担当者」についても見てみましょう。

openCypherというグラフクエリ言語を使うと、以下のように記述できます。

MATCH (pj:Project {name: 'Aプロジェクト'})<-[:ASSIGNED_TO]-(p:Person),
      (pj)-[:HAS_DOCUMENT]->(doc:Document)
RETURN p.name AS 担当者, p.role AS 役割, doc.title AS ドキュメント

このクエリは、Aプロジェクトを起点に「担当者」と「関連ドキュメント」を一度に取得します。SQLのJOINとは異なり、関係をたどる方向が直感的に読み取れます。

さらに広げて、「開発部が関わっている全プロジェクトとその関連ドキュメント」を取得することもできます。

MATCH (d:Department {name: '開発部'})<-[:BELONGS_TO]-(p:Person)-[:ASSIGNED_TO]->(pj:Project)
OPTIONAL MATCH (pj)-[:HAS_DOCUMENT]->(doc:Document)
RETURN d.name AS 部署, p.name AS 担当者, pj.name AS プロジェクト, doc.title AS ドキュメント

部署→人→プロジェクト→ドキュメントという3段階の関係を、1つのクエリで自然にたどれます。このグラフ探索の結果を、ベクトル検索で取得した関連文書のコンテキストと合わせてLLMに渡すことで、「Aプロジェクトについて、担当の田中さんが書いた設計書v2によると...」といった、関係性を踏まえた回答が生成できるようになります。

組織の暗黙知をグラフに落とし込む

ここまでの例で見えてくるのは、グラフのスキーマ設計そのものが「組織の知識構造の設計」であるということです。普段は人の頭の中や散在するシステムの中にある暗黙知を、ノードとエッジとして明示化し、検索可能にする。これがGraphRAGの本質的な価値です。ただし、どこまでモデル化するかのさじ加減は重要で、これについては後述します。

AWSでの実現手段

概念としてのGraphRAGを理解したところで、実際にどう構築するかに目を向けてみましょう。AWSでは、このアプローチを実現するためのマネージドサービスがすでに提供されています。

Bedrock Knowledge Basesによるベクトル検索RAG

Amazon Bedrock Knowledge Basesは、ここまで説明してきたベクトル検索RAGのパイプラインをマネージドに提供するサービスです。

検索時にはメタデータフィルタリングが利用でき、ドキュメントに付与したメタデータ（日付、カテゴリなど）で検索結果を絞り込めます。さらに、Implicit Filterという機能では、ユーザーの自然言語クエリからメタデータフィルタをLLMが自動生成します。「今期の」と言われたときに日付フィルタを自動で適用するような動きが、ある程度は可能です。

しかし、Implicit Filterだけでは先述の「今期 = 3月〜翌2月」のような会社固有の定義までは解決できません。ここでGraphDBの出番になります。

GraphRAG機能（Neptune Analytics連携）

Bedrock Knowledge BasesにはGraphRAG機能が提供されています。Amazon Neptune Analyticsとの連携により、以下のことが実現できます。

• ドキュメントからエンティティと関係性をLLMで自動抽出
• Neptune Analytics上にナレッジグラフを自動構築
• ベクトル検索とグラフ探索を組み合わせたマルチホップ推論

注目すべきは、グラフモデリングの専門知識がなくても始められる点です。コンソールから数クリックで有効化でき、ドキュメント間の関係性の抽出はLLMが自動で行います。

また、Neptune向けのオープンソースGraphRAGツールキットも公開されており、より細かいカスタマイズが必要な場合の選択肢もあります。

マネージドGraphRAGと独自構築の使い分け

Bedrock Knowledge BasesのGraphRAG機能は、ドキュメントからの関係性自動抽出を強みとしています。「まずGraphRAGを試してみたい」という段階では、この方法が最も手軽です。

一方、組織固有のスキーマ（会計期間の定義、部署階層、プロジェクトの分類体系など）を精密にモデル化したい場合は、独自にグラフを設計・構築する方が適しています。人事システムやプロジェクト管理ツールから関係性データを取り込み、組織の構造に合ったスキーマでNeptuneにグラフを構築する方法です。

現実的には、まずマネージドのGraphRAGで効果を確認し、組織固有のコンテキストが必要になった段階で独自グラフを追加していく、という段階的なアプローチが取りやすいでしょう。

導入にあたっての課題

GraphRAGには明確なメリットがありますが、導入にあたっては考慮すべき課題もあります。

グラフデータの構築と維持

最大の課題は、グラフデータをどう構築し、どう鮮度を保つかです。

Bedrock Knowledge BasesのGraphRAG機能を使えば、ドキュメントからの関係性抽出は自動化できます。しかし、人と部署の所属関係、プロジェクトの担当者、会計期間の定義といった組織構造の情報は、人事システムやプロジェクト管理ツールなど既存のシステムから取り込む仕組みを別途構築する必要があります。

関係性データは変化します。人が異動し、プロジェクトが終了し、新しいプロジェクトが始まる。グラフの鮮度が落ちれば、検索結果の正確性も落ちます。既存システムとの同期パイプラインの設計は、技術的にも運用的にも検討が必要です。

スキーマ設計のさじ加減

グラフのスキーマ設計では「どこまでモデル化するか」の判断が求められます。

組織のあらゆる関係性をグラフに落とし込もうとすると、スキーマが複雑になりすぎて維持が困難になります。逆に、シンプルすぎると必要な関係性が表現できません。まずは「ベクトル検索だけでは答えられなかった質問」を起点に、最小限のスキーマから始めるのが現実的です。「プロジェクトと担当者の関係」「部署の階層構造」「会計期間の定義」など、効果が見えやすいものから段階的に広げていくのがよいでしょう。

コストの考慮

Neptune Analyticsは、グラフのサイズとコンピューティングユニットに応じた課金体系です。小規模なグラフから始める場合は比較的低コストで試せますが、組織全体のナレッジグラフに拡大する場合はコスト見積もりが重要になります。Bedrock Knowledge Basesの利用料と合わせて、全体のランニングコストを事前に試算しておくことをお勧めします。

まとめ

ベクトル検索で取得した文書に、グラフから得た関係性のコンテキストを添えることで、RAGの回答品質は大きく変わります。AWSではマネージドな環境で手軽に始められる手段も揃っています。

組織固有のスキーマが必要になったら、独自のグラフ構築と組み合わせることも可能です。

RAGの次の一手として、GraphRAGを検討してみてはいかがでしょうか。

参考文献

• Microsoft. "GraphRAG: Unlocking LLM discovery on narrative private data". https://microsoft.github.io/graphrag/
• Basu et al. (2024). "HybridRAG: Integrating Knowledge Graphs and Vector Retrieval Augmented Generation for Efficient Information Extraction". https://arxiv.org/abs/2408.04948
• Belova et al. (2026). "An Alternative Trajectory for Generative AI". https://arxiv.org/abs/2603.14147

針生 泰有(執筆記事の一覧)

サーバーワークスで生成AIの活用推進を担当