社内文書をベクトル検索で引いてAIに答えさせる仕組みは、もう珍しくない。ただし運用してみると、どうしても答えられない問いの型があることに気づく。
「この顧客の契約条件と、過去のインシデントと、現在の請求状況をまとめて」。この問いに必要な情報は3つの別々の文書に散っている。ベクトル検索は問いに似た断片を上位から拾うため、3つのうち2つしか拾えないことがあり、しかも足りていないことを教えてくれない。
ナレッジグラフは、この問題に「関係」で答えるアプローチである。ただし構築と運用の負荷は決して軽くない。本記事は、効果と負荷の両方を扱う。
この記事の対象読者
- 社内文書のRAGを運用していて、答えられない問いの型に気づいている開発者
- ナレッジグラフやGraphRAGの導入を検討していて、投資判断の材料が欲しい方
- 社内知識基盤の設計を任されているデータ基盤チーム
- 「ナレッジグラフを入れれば精度が上がる」という提案を受けて判断が必要な意思決定者
ナレッジグラフとは
ナレッジグラフは、モノ（エンティティ）とその関係を、点と線として保持するデータ構造である。
「山田商事」という顧客ノード、「契約A」という契約ノード、その間を結ぶ「契約している」という関係。文書の中に埋もれていた関係を、辿れる形にしたものだと考えればよい。
設計の型にあたるものはオントロジーと呼ばれ、ナレッジグラフはその型に実データを流し込んだ実体である。型そのものの設計についてはオントロジーとは？AI時代のデータ活用を変える意味の地図で扱っている。本記事は実体をどう作り、どう運用し、AIにどう使わせるかに絞る。
ベクトル検索が落ちる3つの問いの型
ベクトル検索は「問いに意味が近い断片」を返す仕組みである。だから次の3つが苦手になる。
1. 複数文書をまたぐ関係の問い。 顧客の契約・インシデント・請求のように、答えが複数の文書に分散している場合。ベクトル検索は上位N件を返すため、N件に全部が入らないと不完全な答えになる。
2. 集約と網羅性を要する問い。 「この製品に関するクレームは全部で何件あり、傾向はどうか」。上位N件では全体像が出ない。「全部」を要求する問いに、類似度上位の抽出は原理的に答えられない。
3. 多段の参照。 「この部品の供給元の、そのまた供給元で問題が起きていないか」。1回の検索で辿れない連鎖は、関係を持たない構造では追えない。
逆に言えば、これら以外の問いはベクトル検索で足りる。 「就業規則の休暇の規定は」「この製品の仕様は」といった単一文書に閉じた問いに、ナレッジグラフは要らない。
効果は実測されている
ナレッジグラフの効果には、公開された実測がある。data.worldのJuan Sequedaらが保険業のデータセットで行った検証では、SQLデータベースへ直接問い合わせた場合の正答率が16.7%だったのに対し、同じデータをナレッジグラフ表現にすると54.2%と約3倍になった。
さらにAllemangとSequedaの論文では、オントロジーによるクエリ検査（OBQC）とLLMによる修復を加えることで、正答率72%に到達している（論文アブストラクトの値。詳細値は72.55%）。
ここで注目すべきは内訳である。この論文は72%の正答に加えて、「わからない」と返したものが8%、誤答が20%と報告している。つまり意味の層を通すと、答えられないときに答えられないと言えるようになる。
これは実務では正答率の数字以上に重要である。もっともらしい間違った答えが業務に流れるより、「情報が足りない」と止まるほうが被害が小さい。同じ論点はセマンティックレイヤーとは？指標定義を1つにする層でも扱っている。
ただしこの実測は保険業の特定データセットに対するものである。 自社データで同じ差が出る保証はなく、後述するとおり構築の質に大きく依存する。
作り方
1. エンティティと関係を決める
すべてを拾おうとしない。 業務上で実際に辿りたい関係だけを定義する。顧客・契約・製品・インシデントといった主要なエンティティを10〜20個、その間の関係を定義するところから始める。
ここは自動化できない。どのエンティティが業務にとって意味があるかは、業務を知っている人しか決められない。
2. 既存データから抽出する
- 構造化データ（基幹システム、DB） からの抽出は機械的にできる。テーブルとリレーションが既にグラフに近い形をしている
- 非構造化データ（文書、メール、議事録） からの抽出はLLMを使う。文章からエンティティと関係を取り出す処理になる
構造化データから先に着手する。 精度が高く、コストも低い。非構造化データの抽出は、構造化側の骨格ができてから足すほうが失敗しにくい。
3. 名寄せをする
ここが実務で最も時間を食う。「株式会社山田商事」「山田商事（株）」「ヤマダ商事」を同一エンティティとして扱えないと、グラフは繋がらない。
名寄せの精度がグラフの価値を決める。 繋がっていないグラフは、ただの高価な文書置き場である。
4. 検証する
構築後、実際の業務の問いをいくつか投げて辿れるかを確認する。この検証を飛ばすと、繋がっていないことに数ヶ月後の本番で気づく。
AIに使わせる — GraphRAG
構築したグラフをLLMに使わせる手法がGraphRAGである。MicrosoftがGraphRAGという名称で実装を公開しており、代表的な参照実装として扱われている。
大まかな流れは、文書からエンティティと関係を抽出してグラフを構築し、グラフ上のまとまり（コミュニティ）ごとに要約を作り、問いに応じてグラフを辿りながら文脈を組み立てる、というものである。コミュニティ要約を持つことで、「全体としてどうか」という網羅性の要る問いに答えられるようになるのが、素のベクトル検索との差である。
コストと運用の現実
ここが本記事で最も伝えたい部分である。
構築コストは軽くない
非構造化データからのグラフ構築は、文書をLLMに通してエンティティと関係を抽出する処理であり、対象文書の量に比例してトークン費用がかかる。Microsoftのリポジトリ自身が「GraphRAGのインデックス作成は高コストな処理になりうる。ドキュメントを全部読んでプロセスとコストを理解し、小さく始めること」と警告している（2026年8月26日確認）。
「とりあえず全社の文書を入れてみる」は最も高くつく始め方である。
更新が重い
グラフの本質的な難しさはここにある。文書が1つ増えたとき、その文書に含まれるエンティティが既存のどのノードと繋がるかを判定し直す必要がある。更新頻度が高いデータほど、グラフの維持コストは跳ね上がる。
日次で文書が追加される社内Wikiと、年次で改訂される規程集では、まったく難易度が違う。着手前に対象データの更新頻度を確認する。
スキーマが育たないまま腐る
初期に定義したエンティティと関係は、業務の変化に合わせて手入れが要る。手入れする担当が決まっていないグラフは、1年後には現実と乖離した状態で残る。 これは技術の問題ではなく体制の問題である。
参照実装の位置づけも確認する
Microsoftのリポジトリは、本プロジェクトが現在おおむねメンテナンスモードであり、バグ修正と依存関係の更新は受け付けるが新機能は追加しない旨を明記している（2026年8月26日確認）。参照実装としての価値は高いが、そのまま本番の製品基盤として採用するかは別の判断になる。
判断 — そもそも必要か
正直に書くと、多くの現場ではベクトルRAGで足りるか、部分的な併用で十分である。
| 選択肢 | 向く状況 | 負荷 |
|---|---|---|
| ベクトルRAGのみ | 問いが単一文書に閉じている。まずここから | 低 |
| チャンク設計とリランキングの改善 | 情報は拾えているが順位が悪い | 低 |
| 部分的なグラフ併用 | 特定の関係（顧客と契約など）だけ辿れればよい | 中 |
| フルのグラフ構築 | 網羅性と多段参照が業務の中核 | 高 |
判断の起点は「ベクトル検索で答えられない問いが実際に来ているか」である。 来ていないなら要らない。来ているなら、それが本当に関係を辿る必要のある問いなのか、単にチャンク設計が悪いだけなのかを切り分ける。
「精度が上がりそうだから」でグラフ構築に着手すると、構築費用と維持体制の両方を抱えて成果が出ない。動かない提案を勧めないのが実装パートナーの仕事である。
失敗パターン
全社文書を一括で投入する。 構築コストが跳ね、しかも使われない領域が大半を占める。業務の問いから逆算して範囲を絞る。
名寄せを後回しにする。 繋がらないグラフは価値を生まない。名寄せは付随作業ではなく本体である。
更新頻度を確認せずに着手する。 高頻度更新のデータでフル構築すると、維持だけで人が張り付く。
保守担当を決めない。 スキーマは腐る。定期的に手入れする体制とセットで始める。
ベクトルRAGの改善余地を試さずにグラフへ行く。 チャンク設計とリランキングで解決する問題が、実際には多い。
FAQ
Q1. ナレッジグラフとオントロジーはどう違うのか？
オントロジーが「型」、ナレッジグラフがその型に実データを流し込んだ「実体」にあたる。「顧客は1つ以上の注文を持つ」という定義がオントロジー、「山田商事は注文A・B・Cを持つ」という実体がナレッジグラフである。詳細はオントロジーとは？AI時代のデータ活用を変える意味の地図を参照してほしい。
Q2. ベクトルRAGを捨ててグラフに置き換えるのか？
置き換えではなく併用が普通である。単一文書に閉じた問いはベクトル検索のほうが速くて安い。 関係を辿る問いだけをグラフ側に回す構成が実務的である。
Q3. どのくらいのデータ量から効果が出るか？
量ではなく問いの型で決まる。文書が10万件あっても単一文書に閉じた問いしか来ないならグラフは不要で、1,000件でも関係を辿る問いが業務の中核ならグラフが効く。判断は業務側から行う。
Q4. 構築にどれくらいかかるか？
範囲による。構造化データから主要エンティティ10〜20個に絞った初期構築であれば数週間規模だが、名寄せの難易度で大きく振れる。表記ゆれが多い、マスタが整備されていない、重複顧客が放置されている、といった状態であればそちらの整備が先になる。
Q5. Microsoftのgraphragをそのまま本番で使ってよいか？
参照実装として仕組みを理解するには適している。 ただし公式リポジトリ自身が現在おおむねメンテナンスモードである旨を明記しているため（2026年8月26日確認）、本番の製品基盤として採用する場合は、保守方針とサポート体制を自社で引き受けられるかを判断する必要がある。
Q6. グラフを作れば正答率は72%になるのか？
ならない。 引用した数値は保険業の特定データセットにおける実測であり、しかもオントロジーによるクエリ検査とLLM修復を組み合わせた条件での結果である。自社データで同じ数字が出る前提で投資判断をしてはいけない。自社の業務の問いで評価セットを作り、実測する。
Q7. 更新が頻繁なデータでは使えないのか？
使えないわけではないが、維持コストが上がる。範囲を限定して部分導入するのが現実的である。更新頻度の低いマスタ系（顧客、製品、組織）をグラフにし、更新頻度の高い文書はベクトル検索側に置く、といった役割分担で負荷を抑えられる。
次に読むべき記事
- オントロジーとは？AI時代のデータ活用を変える意味の地図 — 型としての意味の設計
- セマンティックレイヤーとは？指標定義を1つにする層 — 指標定義の統一と失敗の質
- Company Brain（カンパニーブレイン）とは？企業のAI知識基盤 — 社内知識基盤の全体像
- LangGraph実装入門｜エンタープライズのAIエージェント構築フレームワーク — 検索結果を使う側の実装
まとめ
- ナレッジグラフは、モノとその関係を点と線で保持するデータ構造である。オントロジーが型、ナレッジグラフが実体にあたる
- ベクトル検索が落ちるのは「複数文書をまたぐ関係」「集約と網羅性」「多段の参照」の3つ。それ以外の問いにはグラフは要らない
- 効果は実測されている。SQL直接16.7%、ナレッジグラフ表現54.2%、オントロジー検査とLLM修復を加えて72%。内訳では「わからない」が8%あり、答えられないと言えるようになる点が実務的には大きい
- 構築で最も時間を食うのは名寄せである。繋がらないグラフは高価な文書置き場にしかならない
- 更新頻度の高いデータほど維持コストが跳ねる。 着手前に必ず確認する
- Microsoftのgraphragは参照実装として価値が高いが、公式リポジトリに現在おおむねメンテナンスモードと明記されている（2026年8月26日確認）。本番採用は別途判断する
- 多くの現場ではベクトルRAGで足りるか、部分併用で十分である。 判断の起点は「答えられない問いが実際に来ているか」
FDXのナレッジ基盤支援
FDXはAX（AI Transformation）の実装パートナーとして、社内知識をAIが使える形にする設計から、構築・運用移管までを対応領域とする。
ナレッジグラフは強力だが万能ではなく、投資に見合わない現場も多い。必要かどうかの判断から一緒に行うのがFDXの立ち位置である。 業務の問いを分解して適用範囲を見極めるところから始めたい場合はAX診断を、実装体制の相談はお問い合わせからどうぞ。
出典・参考文献
- Juan Sequeda, Dean Allemang, Bryon Jacob「A Benchmark to Understand the Role of Knowledge Graphs on Large Language Model's Accuracy for Question Answering on Enterprise SQL Databases」（保険業データセットでSQL直接16.7%、ナレッジグラフ表現54.2%）
- Dean Allemang, Juan Sequeda「Increasing the LLM Accuracy for Question Answering: Ontologies to the Rescue!」（OBQCとLLM Repairの併用で正答72%、「わからない」8%、誤答20%）
- Microsoft「GraphRAG リポジトリ」（インデックス作成が高コストになりうる旨の警告、現在おおむねメンテナンスモードである旨の記載。いずれも2026年8月26日確認）