従来のRAGはもう古い？graphRAGが変える社内検索の常識
こんにちは、株式会社TIMEWELLの濱本です。今日は、私たちがZEROCKのコア技術として採用している「graphRAG」についてお話しします。
「社内の情報をAIに学習させたい」 「ChatGPTを使っているけど、社内の情報には答えられない」 「RAGを導入したけど、思ったほど精度が出ない」
こうした声を、私たちは日常的にお聞きしています。実は、これらの課題の多くは、従来のRAG技術の構造的な限界に起因しています。そして、その限界を突破するために生まれたのがgraphRAGなのです。
本記事では、RAGの基礎から始めて、なぜ従来のRAGでは不十分なのか、そしてgraphRAGがいかにしてその課題を解決するのかを、5000文字を超えるボリュームで徹底的に解説していきます。技術的な内容も含まれますが、エンジニアでない方にもわかりやすいよう心がけていますので、ぜひ最後までお読みください。
第1章：そもそもRAGとは何か—LLMの「記憶」を拡張する技術
まず、RAG（Retrieval-Augmented Generation、検索拡張生成）の基本を押さえておきましょう。
ChatGPTやClaudeといった大規模言語モデル（LLM）は、インターネット上の膨大なテキストを学習しており、一般的な知識については驚くほど詳しく回答できます。しかし、「自社の製品仕様」「社内の業務プロセス」「過去の顧客対応履歴」といった社内固有の情報については、当然ながら知りません。
RAGは、この問題を解決するための技術です。ユーザーからの質問を受けると、まず社内のドキュメントから関連する情報を検索し、その検索結果をLLMに渡して回答を生成させます。いわば、LLMに「カンニングペーパー」を渡すようなものです。
RAGの基本的な流れ
| ステップ | 処理内容 |
|---|---|
| 1. 質問受付 | ユーザーが質問を入力 |
| 2. 検索 | 社内ドキュメントから関連情報を検索 |
| 3. 情報付与 | 検索結果をLLMに渡す |
| 4. 回答生成 | LLMが検索結果を参照して回答を生成 |
表1：RAGの基本フロー
たとえば、「製品Aの保証期間は何年ですか？」という質問が来たとします。RAGシステムは、まず社内の製品仕様書から製品Aに関する情報を検索します。「製品Aの保証期間は2年間です」という記述を見つけたら、この情報をLLMに渡し、正確な回答を生成させます。
この仕組みにより、LLMは学習していない社内固有の情報についても、正確に回答できるようになります。
第2章：従来のRAGが抱える3つの限界
RAGは素晴らしい技術ですが、従来の実装方式（以下、ベクトルRAGと呼びます）には、いくつかの構造的な限界があります。
限界1：「類似」と「関連」は違う
ベクトルRAGは、テキストデータを「ベクトル」と呼ばれる数値の列に変換し、質問と意味的に類似したテキストを検索する仕組みです。しかし、「意味的な類似性」は必ずしも「関連性」と一致しません。
具体例で考えてみましょう。「A社の担当者は誰？」という質問に対して、ベクトル検索では「A社との取引履歴」というドキュメントがヒットするかもしれません。しかし、そのドキュメントに担当者の名前が明記されていなければ、回答できません。
実際に必要なのは、「A社」→「担当者：田中太郎」という関係性の情報です。これは、単純な類似検索では見つけにくいのです。
限界2：チャンク分割で失われる文脈
ベクトルRAGでは、長いドキュメントを一定の長さ（たとえば500文字）ごとに分割（チャンク化）し、それぞれをベクトル化します。しかし、この分割によって文脈が失われることがあります。
製品マニュアルを例に考えてみましょう。「第3章 トラブルシューティング」の内容を検索したい場合、チャンク分割によって「第3章」というヘッダーと本文が別々のチャンクになってしまうと、検索精度が下がります。
さらに深刻なのは、「詳細は第5章を参照」といった相互参照がチャンク間で断絶されてしまうことです。ドキュメント全体の構造を理解していれば当然たどり着ける情報に、ベクトル検索ではたどり着けないのです。
限界3：多段階推論ができない
最も深刻な限界は、複数ステップの推論ができないことです。
「A社の担当者が以前在籍していた部署はどこ？」という質問を考えてみましょう。この質問に答えるには、以下のステップが必要です。
- まず「A社の担当者」を特定する（→田中太郎）
- 次に「田中太郎の以前の在籍部署」を探す（→営業第一課）
ベクトルRAGでは、質問全体との類似度で検索するため、「A社」「担当者」「在籍部署」といった要素が一つのドキュメントに含まれていなければ、適切な情報を取得できません。情報が複数のドキュメントに分散している場合、お手上げなのです。
第3章：graphRAGの革新的アプローチ
これらの限界を克服するために生まれたのが、graphRAGです。
ナレッジグラフという発想
graphRAGの「graph」は、ナレッジグラフ（知識グラフ）を指しています。ナレッジグラフとは、情報を「エンティティ（実体）」と「リレーション（関係）」で構造化したデータモデルです。
たとえば、以下のような関係を表現できます。
- 「田中太郎」—（担当する）→「A社」
- 「田中太郎」—（以前在籍）→「営業第一課」
- 「営業第一課」—（所属）→「東日本事業部」
このようにして構築されたグラフは、情報の「つながり」を明示的に保持します。「A社の担当者は誰？」という質問に対して、グラフを辿れば「田中太郎」という回答に到達できます。
graphRAGの動作原理
graphRAGは、以下のようなプロセスで動作します。
1. エンティティとリレーションの抽出 社内ドキュメントやメール、チャットログなどのテキストデータから、エンティティとリレーションを抽出します。「契約書に田中が署名した」という文からは、「契約書」「田中」というエンティティと、「署名する」というリレーションを抽出します。
2. ナレッジグラフの構築 抽出したエンティティとリレーションを使ってナレッジグラフを構築します。このグラフは、組織の知識を構造化した「知識の地図」のようなものです。
3. グラフ探索による情報収集 質問が入力されると、まず質問から関連するエンティティを特定し、グラフを辿って関連情報を収集します。
4. 回答生成 収集した情報をLLMに渡し、回答を生成させます。
従来RAGとの決定的な違い
| 観点 | ベクトルRAG | graphRAG |
|---|---|---|
| 検索方式 | 意味的類似度 | グラフ探索 |
| 情報の捉え方 | 個別のテキスト断片 | エンティティ間の関係 |
| 多段階推論 | 困難 | 可能 |
| 文脈の保持 | チャンク単位で分断 | グラフ構造で保持 |
| 情報の更新 | 再インデックスが必要 | ノード・エッジの追加で対応 |
表2：ベクトルRAGとgraphRAGの比較
先ほどの「A社の担当者が以前在籍していた部署はどこ？」という質問を、graphRAGで処理してみましょう。
- 質問から「A社」「担当者」「在籍部署」というキーワードを抽出
- グラフ上で「A社」ノードを特定
- 「A社」から「担当する」リレーションを辿り、「田中太郎」に到達
- 「田中太郎」から「以前在籍」リレーションを辿り、「営業第一課」に到達
- 「営業第一課」という回答を生成
このように、graphRAGではグラフ構造を辿ることで段階的に情報を収集し、複雑な質問にも対応できるのです。
第4章：企業でgraphRAGを活用するポイント
graphRAGは強力な技術ですが、その威力を最大限に発揮するためには、いくつかのポイントを押さえる必要があります。
ポイント1：データの質がすべてを決める
graphRAGの精度は、元となるデータの質に大きく依存します。ゴミを入れればゴミが出てくる（Garbage In, Garbage Out）という原則は、ここでも当てはまります。
私たちがZEROCKを導入支援する際にもっとも重視するのが、データクレンジングの工程です。具体的には以下の作業が必要になります。
- 重複ドキュメントの削除
- 古い情報の整理・アーカイブ
- 不正確な情報の修正
- 業界特有の用語・社内用語の辞書登録
ある製薬会社での導入事例では、薬剤名や化合物名の辞書を事前に整備したことで、エンティティ抽出の精度が30%以上向上しました。
ポイント2：継続的な更新の仕組み化
graphRAGは、構築して終わりではありません。組織の知識は日々更新されるため、ナレッジグラフも継続的にメンテナンスする必要があります。
ZEROCKの「AIナレッジ」機能では、この課題に対応しています。チャットの結果やリサーチ結果をワンクリックで保存すると、自動的にナレッジグラフに反映されます。ユーザーの日常業務の中で自然とナレッジが蓄積されていくため、更新作業の負担を最小限に抑えることができます。
ポイント3：ユースケースの見極め
graphRAGは万能ではありません。すべての検索課題がgraphRAGで解決できるわけではなく、適切なユースケースを見極めることが成功の鍵です。
graphRAGが特に威力を発揮するケース：
- 複数の情報源を横断する必要がある質問
- 因果関係や時系列を追う必要がある質問
- 人物・組織・プロジェクトの関係を把握する必要がある質問
従来のベクトルRAGで十分なケース：
- 単純なキーワード検索
- 特定ドキュメントの内容確認
- FAQ形式の定型的な質問
ZEROCKでは、両者をハイブリッドで使用することで、最適な検索体験を提供しています。
第5章：ZEROCKのgraphRAG実装
私たちTIMEWELLは、graphRAG技術をZEROCKに実装し、多くの企業の課題解決を支援してきました。
導入の簡素化
一般的にgraphRAGの構築は複雑で、専門的な知識が必要です。しかしZEROCKでは、ドキュメントをアップロードするだけで、自動的にエンティティ抽出、グラフ構築、インデックス作成が行われます。技術的な知識がなくても、graphRAGを活用した社内情報検索を実現できます。
検索精度の向上
従来のベクトル検索と比較して、ZEROCKのgraphRAG実装では、複雑な質問への回答精度が平均40%向上しています（当社調べ）。特に、「〇〇の担当者は誰？」「このプロジェクトに関わった人は？」といった、関係性を問う質問で顕著な効果が見られます。
セキュリティへの配慮
エンタープライズでの利用を前提としているため、IPアドレス制限やシングルサインオン（SSO）といった高度なセキュリティ機能も完備。機密性の高い社内情報を扱う場合でも、安心してご利用いただけます。
結論：構造化された知識が組織を強くする
graphRAGは、単なる技術的な進化ではありません。それは、組織の知識を「構造化する」という哲学の具現化です。
バラバラに散在していた情報を、意味のあるつながりで結びつけることで、初めて「使える知識」になります。そして、その知識は、検索時間の短縮だけでなく、新しい洞察の発見や組織学習の加速といった、より高次の価値を生み出します。
従来のRAGでは「検索して見つける」ことしかできませんでしたが、graphRAGでは「つながりを辿って理解する」ことができるのです。
あなたの組織の社内検索を、次のステージへ。ZEROCKにご興味をお持ちいただけましたら、ぜひお気軽にお問い合わせください。14日間の無料トライアルで、graphRAGの威力を実感していただけます。
参考文献 [1] Microsoft Research, "From Local to Global: A Graph RAG Approach to Query-Focused Summarization", 2024 [2] Lewis et al., "Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks", NeurIPS 2020