戦略コンサルティング

STP策定支援

ペルソナ / CJM /UXフロー策定支援

プライシング再設計支援

KGI / KSF / KPI / ミッションツリー策定支援

SaaSモデル / クラウド化転換支援

新規事業立ち上げ支援

ITコンサルティング

ビジネス部門支援

経営企画・事業企画チーム立ち上げ支援

カスタマーサクセスチーム立ち上げ支援

CS ヘルススコア構築支援

カスタマーサポート対応自動化支援

サービスサイト / ランディングページ構築 / リニューアル支援

オウンドメディア立ち上げ支援

プロダクト部門支援

グロースハック施策企画 / 実行支援

プロダクトロードマップ策定支援

プロダクト開発体制支援

プロダクト運用体制支援

プロダクト組織の強化 / 育成支援

開発部門支援

インフラ(クラウドサーバー)コスト削減支援

開発パートナー会社見極め・選定伴走

CTO採用支援

データ支援

データ基盤(DWH)構築支援

Tableauダッシュボード構築支援

GA4導入 / 活用支援

データ活用人材育成・トレーニング

サービス

GraphRAGとは|RAGとの違いと使い分け

2026/7/31

リンクをコピー

  • # データ基盤

  • # AI導入

  • # AI

  • # DX・AI推進担当

社内のデータをAIで扱えるようにしたい。そう考えて調べ始めると、まずRAGという言葉に行き着きます。社内文書を検索して、その結果をAIに読ませて回答させる仕組みです。
そこからもう一歩調べを進めると、今度はGraphRAG(グラフラグ)という言葉が出てきます。

ここで手が止まった方もいるのではないでしょうか。
解説を開いても「ナレッジグラフを用いてエンティティ間のリレーションを構造化し…」と書かれていて、そのナレッジグラフが何なのかが分かりません。
RAGの新しい版なのか、まったく別の技術なのかも判別できないまま、調査が止まります。

本記事では、GraphRAGの定義と仕組みを整理したうえで、従来のRAGとの違い、現時点でどれくらい実用的か、そして自社ではどちらを検討すべきかの判断軸までを示します。

GraphRAGとは、ナレッジグラフを使って社内データを検索するRAG

GraphRAG(グラフラグ)とは、社内文書からナレッジグラフを作り、そのグラフを使って検索を行うRAGの方式です。

GraphRAGを理解するには、RAGとナレッジグラフという2つの概念を理解しておく必要があります。

前提1|RAGとは、社内文書を検索してAIに読ませる仕組み

RAG(Retrieval-Augmented Generation、検索拡張生成)とは、質問に関係のありそうな社内文書を検索して取り出し、その文書をAIに読ませたうえで回答させる仕組みです。

ChatGPTのような生成AIは、自社の議事録や仕様書の中身を知りません。
そこで、質問が来るたびに社内文書から関係しそうな箇所を探し出し、「この文書を参考にして答えてください」とAIに渡します。

検索できる状態を作るために、社内文書は事前に2つの処理を受けます。

1つ目がチャンク分割(長い文書を数百文字程度の断片に切り分けること)です。
1つの文書をまるごと渡すとAIが一度に読める分量を超えるため、あらかじめ細かく切っておきます。

2つ目がエンベディング(文章を数値の並びに変換すること)です。
文章を数値にしておくと、意味が近い文章どうしは数値も近くなります。この性質を使うと、「有給休暇の日数」という質問から「年次有給休暇の付与」と書かれた断片を、言葉が完全に一致していなくても探し出せます。
この探し方をベクトル検索と呼びます。

文書を断片に切って数値に変え、質問に意味が近い断片を探す。この方式が、いま一般にRAGと呼ばれているものです。
本記事では以降、これを従来のRAGと呼びます。

前提2|ナレッジグラフとは、情報を点と線でつないだデータ

ナレッジグラフとは、人やモノや出来事を「点」、それらの関係を「線」で表したデータです。

例えば、人間関係を思い浮かべると分かりやすいかもしれません。
1人ひとりが点で、「鈴木さんは田中さんの上司である」「田中さんと佐藤さんは同僚である」というつながりが線にあたります。

社員名簿にも1人ひとりの情報は載っていますが、書かれているのは所属と役職までです。
「A社の件で相談したいが、直接の面識がない。誰を介せば話が通るか」という問いに答えるには、田中さん、鈴木さんと順につながりを辿る必要があります。
答えは、1人ひとりの情報ではなく、人と人のつながりのほうにあります。

ナレッジグラフも同じ考え方でできています。
「山田さん」「A社」「案件X」が点で、「山田さんはA社を担当している」「案件XはA社の案件である」などが線です。

このあとのGraphRAGの解説に出てくるエンティティリレーションは、この点と線の呼び名です。
エンティティが点(人・組織・製品・案件など、名前を持つ対象)、リレーションが線(対象どうしの関係)にあたります。

関連記事:ナレッジグラフとは

GraphRAGの定義

改めて、GraphRAGとは、Microsoft Researchが2024年2月にブログで公開した検索手法です。

GraphRAGは、Retrieval Augmented Generation(RAG)に対する、構造と階層を持たせたアプローチであり、プレーンテキストの断片を使った単純な意味検索のアプローチとは対照的なものである。

ここで押さえておきたいのは、GraphRAGはRAGの一種だという点です。
RAGを置き換える別の技術ではなく、RAGの中で検索の方法を変えたものにあたります。

なお、GraphRAGという言葉は、ナレッジグラフで使用されているグラフ構造(点と線の関係)を使うRAG全般を指す総称としても使われます。
本記事では、このMicrosoft Researchが公開したGraphRAGを基準に説明します。

GraphRAGの仕組み|文書からグラフを作り、質問に応じて辿る4つのステップ

GraphRAGは、質問を受ける前に社内文書からナレッジグラフを作っておき、質問が来たらそのグラフを辿って回答に必要な情報を集めます。
準備にあたる3つのステップと、質問を受けてからの1つのステップに分かれます。

ステップ1:エンティティとリレーションの抽出

最初に、社内文書からエンティティ(点)とリレーション(線)を抜き出します。

文書はまず、分析の単位に切り分けられます。
ここは従来のRAGのチャンク分割と同じ考え方です。

そのうえで、切り分けた単位ごとにLLM(大規模言語モデル。ChatGPTなどの生成AIの中核にあるもの)が本文を読み、登場する人名・組織名・製品名・案件名などのエンティティと、それらの間の関係を抜き出します。

従来のRAGが断片を数値に変えるだけなのに対して、GraphRAGはLLMに文書を読ませ、「誰が」「何と」「どう関係しているか」を明示的に取り出します。

ステップ2:ナレッジグラフの構築

抽出したエンティティとリレーションを、文書をまたいでつなぎ合わせ、1つのナレッジグラフにします。

議事録に出てきた「A社」と、契約書に出てきた「A社」と、障害報告書に出てきた「A社」は、別々の文書に散らばっていても、同じ1つの点として統合されます。

この統合によって、元の文書では離れていた情報どうしが線でつながります。
議事録に書かれた要望と、障害報告書に書かれた不具合が、A社という同じ点を経由して辿れる状態になります。

ステップ3:コミュニティ検出と要約の事前生成

出来上がったナレッジグラフの中から、密につながっている点の集まりを見つけ出します。
この集まりをコミュニティと呼び、見つける処理をコミュニティ検出と呼びます。

GraphRAGはコミュニティを階層的に整理します。
小さなまとまりが集まって中くらいのまとまりを作り、それがさらに大きなまとまりを作る、という入れ子の構造です。

そのうえで、コミュニティごとに要約を作ります。
「このまとまりは、A社との取引に関する一連のやりとりである」といった要約が、質問される前に用意されます。

Microsoft Researchは、この階層的な整理の狙いを、さまざまな抽象度の問いに答えられるようにすることだと説明しています。
細かい問いには小さなまとまりの要約が、大きな問いには大きなまとまりの要約が対応します。

ステップ4:クエリ処理

クエリ処理とは、届いた質問(クエリ)を解釈して、回答に必要な情報をグラフのどこから集めるかを決める工程です。
ステップ3までが質問を受ける前の準備で、ステップ4は質問を受けたあとの動きになります。

質問が来ると、GraphRAGは問いの性質に応じて探し方を使い分けます。
公式ドキュメントが挙げている主なものが2つあります。

1つ目が、局所検索(Local Search)です。
質問に出てくる特定の対象を起点に、ナレッジグラフの隣り合う点を辿っていき、集めた情報と元の文書の断片を組み合わせて回答を作ります。
「この案件の関係者は誰か」のように、対象が特定できる問いに向いています。

2つ目が、全体検索(Global Search)です。
ステップ3で作っておいたコミュニティ要約をすべて見渡し、それぞれから部分的な回答を作ったうえで、それらをもう一度まとめて最終的な回答にします。
「このデータ全体の主な論点は何か」のように、対象が特定できない問いに向いています。

GraphRAGと従来のRAGの違い|答えられなかった2つの問い

Microsoft Researchは、GraphRAGの公開時に、従来のRAGが苦手とする問いを2つ挙げています。この2つが、GraphRAGが作られた理由にあたります。

課題1|複数の文書にまたがる関係を辿る問いに答えられない

ばらばらの情報を共通する属性でつないで辿り、そこから新しい結論を導く必要がある問いです。
Microsoft Researchは、この形の問いに従来のRAGは苦戦すると述べています。

原因は、検索の単位にあります。
従来のRAGは文書を断片に切り、質問と意味が近い断片を上位から数件取り出します。

「A社で起きた障害は、過去3年の類似案件とどう関連するか」という問いを考えたとします。
答えを出すには、A社の障害報告書と、3年分の案件記録と、それらを結ぶ共通点を突き合わせる必要があります。
ところが検索で返ってくるのは、問いの文面に似た断片が数件だけです。
断片どうしがどうつながっているかは、どの断片にも書かれていません。

文書を断片に切った時点で、断片と断片の関係は保持されなくなります。
従来のRAGがこの形の問いに答えられないのは、精度が足りないからではなく、関係を保持する仕組みを持っていないためです。

課題2|データ全体を見渡す問いに答えられない

データ全体を通した理解が求められる問いです。
Microsoft Researchは、大量の文書、あるいは1つの長い文書を対象に、そこで語られている概念を全体としてまとめて理解することを求められると、従来のRAGは十分に機能しないと述べています。

こちらも原因は検索の単位にあります。
「このプロジェクトの論点を網羅的に整理してほしい」という問いに対して、従来のRAGは質問と意味が近い断片を数件返します。全体を見渡すことを求められているのに、返ってくるのは部分です。

しかも、どの断片が返るかは質問の文面との近さで決まるため、同じ論点を扱った断片ばかりが集まることも起こります。
返ってきた数件が全体を代表しているという保証は、ありません。

GraphRAGでどう変わったか

この2つに対して、GraphRAGは検索する対象そのものを変えました。

従来のRAG

GraphRAG

検索する対象

文書を切った断片

文書から抽出したエンティティとリレーション、およびコミュニティ要約

探し方

質問と意味が近い断片を数件取り出す

対象を起点にグラフを辿る、またはコミュニティ要約を全件見渡す

文書をまたぐ関係

断片ごとに独立しており、保持されない

同じ対象を1つの点に統合し、文書をまたいで線でつなぐ

全体像を問われたとき

質問に近い断片だけが返る

事前に作った階層的な要約から全体を組み立てる

検索の対象が、文章の断片から情報どうしのつながりに変わった、ということです。

Microsoft Researchの研究チームが公開した論文では、100万トークン規模のデータセットに対する全体を見渡す問いについて、従来のRAGと比べて回答の網羅性と多様性が向上したと報告されています。

企業がGraphRAGを取り入れるとできること

GraphRAGを入れると、社内のAIに投げられる質問の種類が、前章までの解説の通り、2つ増えます。

関係性を辿った回答が返る

【例】GraphRAGで答えられるようになる質問

  • ある部品に不具合が出た場合、影響が及ぶ製品と、その製品を納入している取引先はどこか

GraphRAGは部品名や製品名を点として文書をまたいで統合しているため、部品を起点にグラフを辿り、関連する記録を集められます。
人が「部品表で製品を調べ、その製品名で納入記録を検索し、出てきたものを1つずつ読む」という順に手を動かしていた部分が、検索の仕組み側に移ります。

データ全体を見渡した回答が返る

【例】GraphRAGで答えられるようになる質問

  • このプロジェクトに関わる社内のやりとり全体で、経営側で確認すべき重要な論点は何か

この質問に対して、GraphRAGはコミュニティ要約を全件見渡し、それぞれから部分的な回答を作ったうえで、それらをまとめて最終的な回答にします。
蓄積された記録の全体を材料にして論点を組み立てるため、質問の文面に近い記録に偏りにくくなります。

事例|LinkedInのカスタマーサポートでの導入

LinkedInのカスタマーサポート部門は、過去の問い合わせチケットをナレッジグラフにしてRAGに組み込み、問い合わせ1件あたりの解決時間の中央値を28.6%短縮しました。
研究チームが2024年に論文として公開しています。

対象になったのは、技術的な問い合わせへの対応業務です。
過去に似た問い合わせがあったかどうかを素早く正確に引き出せるかが、対応にかかる時間を左右します。

研究チームが問題として挙げたのは、従来の検索方法が過去のチケットの集まりをただの文章として扱っていた点です。
チケットの内部にある要約・詳細・再現手順・優先度といった項目どうしの関係も、チケットとチケットの関係も、断片に切った時点で失われていました。

そこで、項目・チケットどうしの2種類の関係を保ったままナレッジグラフを構築し、質問が来るとその質問を解析して関連する部分グラフを取り出し、回答を生成する方式に変えました。
冒頭の数字は、この方式に切り替えてから約6か月運用した時点での測定結果です。

GraphRAGが必要なときと、RAGで十分なとき

GraphRAGでできることが増える一方、構築コストもかかってきます。

RAGで十分なのか、GraphRAGの方が良いのか。判断の分かれ目は、自社で想定している質問が、関係性を辿る問いなのか、1対1で対応する問いなのかです。

判断軸は「関係性を辿る問いか、1対1で対応する問いか」

質問と回答が1対1で対応する問いとは、答えがどこか1か所に書かれていて、その箇所を見つければ答えが出る問いです。

関係性を辿る問いとは、答えがどこか1か所に書かれておらず、複数の箇所に散らばった情報をつないで初めて答えが形になる問いです。

RAGで十分な問い|質問と回答が1対1で対応する問い

【例】従来のRAGで答えられる質問

  • A社の担当者は誰か

  • 有給休暇は入社何か月後に何日付与されるか

どちらも、答えは顧客管理システムの1レコード、あるいは就業規則の1条文に書かれています。
必要なのは、その1か所を正確に見つけることです。
質問の文面と意味が近い断片を探す従来のRAGは、この形の問いに向いています。

社内の想定質問がこの形に寄っている場合、GraphRAGを導入しても、初期構築コストに見合う精度の向上は得られにくくなります。

GraphRAGを検討する問い|関係性を辿る問い

【例】GraphRAGを検討する対象になる質問

  • ある取引先について、営業・サポート・請求の各部門に散らばった記録を突き合わせて、いま何が起きているかを説明してほしい

  • 退職した担当者が抱えていた案件について、経緯と未解決の論点を整理してほしい

どちらも、答えが1か所に書かれていません。
複数のシステムや文書に散らばった記録を、取引先や案件という共通点でつなぎ直して初めて答えが形になります。

前者は関係を辿る問いで、後者は関係を辿ったうえで全体を要約する問いです。
GraphRAGが答えられるようになったのは、この2つの形です。

自社の想定質問リストを分類する

自社にGraphRAGが必要かどうかは、手元の想定質問を仕分けることで見当をつけれます。

  1. 社内のAIに投げたい質問を、10件ほど書き出す

  2. 重要度が高い質問にマークをする

  3. 各質問について、答えが1か所に書かれているか、複数の箇所をつないで作る必要があるかを判定する

  4. 答えが1か所に書かれている質問が全体の何割かを確認する

  5. 複数の箇所をつなぐ必要がある質問や、全体を要約する質問(論点の整理・傾向の把握)が含まれているかを確認する

答えが1か所に書かれている質問が多く、重要度が高ければ、従来のRAGで十分だという判断になります。
複数の箇所をつなぐ質問や、全体を要約する質問の方が多い・重要度が高いなら、GraphRAGを検討する対象になります。

まとめ

GraphRAGとは、社内文書からナレッジグラフを作り、そのグラフを辿って検索を行うRAGの方式です。
文書を断片に切って質問と意味が近いものを探す従来のRAGに対して、情報どうしのつながりを保ったまま検索できる点が違います。

この違いによって、複数の文書にまたがる関係を辿る問いと、データ全体を見渡して要約する問いに答えられるようになりました。
一方で、答えが1か所に書かれている問いでは、従来のRAGのほうが正確に答えます。

自社にGraphRAGが必要かどうかは、社内のAIに投げたい質問を書き出し、それが関係性を辿る問いか、1対1で対応する問いかで仕分けることで、見当をつけれます。

知見・コラム

  • コラム

考えながら動き、動きながら考える:未知を扱うプロジェクトの進め方

プロジェクトは立ち上がり、担当も決まり、メンバーはそれぞれのアクションを着実に進めている。定例会議では毎回、各担当から進捗が報告される。それなのに、プロジェクト全体として前に進んでいる感じがせず、狙っていた数値も動かない。私はデータとAIの領域で複数の会社の新規の取り組みを支援する中で、この状態を何...

2026/8/17

  • コラム

「使うたびに賢くなるAI」は、待っていても来ない

AIは使えば使うほど賢くなる、という言い方をよく見ます。私はこれを、半分だけ本当だと思っています。モデルは確かに進化します。ただ、自分の会社のやり方や、自分の文章の癖を、AIが使っているうちに勝手に覚えてくれることはありません。昨日直したことを、今日もまた直す。AIを業務で使っている方なら、覚えがあ...

2026/8/17

  • コラム

BigQueryのDWHを非構造化データへ拡張する:データレイクハウスの全体像

BigQueryでDWH(データウェアハウス)を構築すると、売上・顧客・広告といった構造化データを統合して分析できるようになります。そこに「議事録や過去の戦略資料からも示唆を出したい」という要望が来ることがあります。PDFやPowerPoint、音声はBigQueryのテーブルには入りません。本記事...

2026/8/12

記事一覧へ

arrow_forward

お役立ち資料

営業部門のAIエージェント活用ガイド|営業現場が変わる10の業務

ダウンロード

お役立ち資料一覧を見る

Contact

まずはお気軽にご相談ください