← ブログに戻る

GraphRAGを7ステップで構築: RDF/PG決定表(2026年版)

/ 7分で読めます / graphrag · knowledge-graph · rdf · property-graph · neo4j

GraphRAGを本番で回そうとして最初に詰まるのは、モデル選びの1つ手前です。「RDFとProperty Graph、どっちで始めるか」。私も最初のPoCで、ここで週末を2回溶かしました。この記事は、その選択を3軸(コスト・クエリ表現力・運用工数)で数値化した決定表と、Property Graphを軸にしたときの構築7ステップを、2026年8月時点の実測感覚でまとめたものです。なお、同じ「ナレッジグラフ」でも「コード変更の影響範囲を可視化する」タイプのgit履歴 × tree-sitter系の実装記事とは切り口が違います。あちらは既に決めたグラフに何を載せるかの話。この記事は、そもそもどのグラフで始めるかの決定木です。

RDF vs Property Graph 決定表(3軸)

軸RDF(Oxigraph / Apache Jena / GraphDB)Property Graph(Neo4j / Kuzu-Vela)
コスト(初期学習+運用)URI・名前空間・SPARQL・OWLの学習コスト。運用は自前中心Cypher学習は数日。Aura DB等マネージド前提で運用工数低
クエリ表現力OWL推論とSPARQL Federationが強い。標準規格の恩恵大エッジに直接プロパティ。ホワイトボード図がそのままCypherになる
運用工数Apache Jena / GraphDBは自前運用中心。Oxigraphは軽量だが本番実績は薄めNeo4j AuraDB、Kuzu embedded、両方で運用工数最小化しやすい

「表現力の広さ」と「運用の軽さ」はほぼ反比例します。

GraphRAGを最初に導入するチームで、社外組織との標準連携が要件に入らないなら、Property Graphに寄せた方が最初の90日で回収しやすいです。

RDF vs Property Graph 3軸決定表

Property Graphを選んだあとの7ステップ

Neo4j公式の構築フレームワークを、GraphRAG前提で圧縮しました。

順に説明します。

Step 1. ユースケースを1クエリに絞る

「社内データを全部グラフにしたい」はほぼ確実に失敗します。

私も一度やって、3ヶ月使われずに終わりました。良い例はこれくらい具体的です。「新人エンジニアが、あるAPIエンドポイントを変更したときに影響するサービスを、30秒以内で把握できるようにする」。1クエリに絞ると、必要なノードとエッジが自動的に決まります。

Step 2. データソースを分類する

構造化(DB, CSV)、半構造化(JSON, YAML)、非構造化(PDF, テキスト)の3種で分類します。GraphRAGの旨味は、LLMで非構造化データからエンティティと関係を自動抽出できる部分に集約されています。非構造化データが8割を超えるなら、抽出プロンプトとレビュープロセスの設計をStep 3より先に固めた方が結局早い。というのが私が3回やり直して学んだ順序です。

Step 3. オントロジーをユースケースから逆算

Step 1のクエリを起点に、必要最小限のノードラベルとエッジタイプだけ設計します。

// ノードラベル
(:Service {name, version, team})
(:API {path, method, status})
(:Developer {name, team})

// エッジタイプ
(:Service)-[:EXPOSES]->(:API)
(:API)-[:CALLS]->(:API)
(:Developer)-[:MAINTAINS]->(:Service)

「あとで使うかもしれない」ラベルは書かないでください。追加は後からできます。

削除は誰も踏み切れません。

Step 4. データモデリングとインデックス

Neo4jに落とすときは、最初にインデックスを張るところまでやります。

CREATE INDEX FOR (s:Service) ON (s.name);
CREATE INDEX FOR (a:API) ON (a.path);

インデックス無しでLLMからのCypher生成を回すと、100ノード程度でも体感1秒以上かかる場面が出ます。GraphRAGは応答時間の要件が厳しいので、Step 4で必ずインデックスを張ってください。

Step 5. LLMで非構造化データを取り込む

非構造化データの取り込みは、LLMに直接プロンプトで抽出させる形が2026年ではデファクトです。

# 概念コード
prompt = """
以下の議事録から、エンティティ(人、組織、技術)と
それらの関係をJSONで抽出してください。
形式: {"nodes": [...], "edges": [...]}
テキスト: {document}
"""

抽出結果をそのまま入れずに、必ず「同一エンティティの正規化」(例: “Neo4j 5.x” と “Neo4j” を1ノードに束ねる)を挟みます。ここを怠るとノード数が数千規模で発散します。

Step 6. Cypherでビジネスロジックを表現し、APIとして出す

GraphRAGの「Graph」部分の実体は、このStep 6のCypherクエリ集です。

// 影響範囲分析: APIを変更したとき、影響を受けるサービスは?
MATCH (target:API {path: "/api/users"})
      <-[:CALLS]-(caller:API)
      <-[:EXPOSES]-(s:Service)
RETURN s.name, caller.path;

// 最短接続パス: 2つのサービス間の依存パスは?
MATCH path = shortestPath(
  (a:Service {name: "UserAPI"})-[*..6]-(b:Service {name: "PaymentService"})
)
RETURN path;

Neo4j 2026.02系以降はCypher 25のSEARCH句(ベクトルインデックス向け)がGA。ベクトル検索とグラフ探索を1つのCypherクエリで書けます。

GraphRAGを「ベクトルとグラフのハイブリッド検索」として実装するなら、Cypher 25対応かどうかが最初の判断基準になります。

Step 7. 運用: 鮮度・品質・監視

作って終わりではないのはRDBと同じです。ナレッジグラフは「孤立ノードが増える」「同一エンティティが分裂する」の2つで劣化するのが特徴です。

  • 鮮度: データソースとの同期パイプラインを日次で回す
  • 品質: 孤立ノードと重複エンティティの監視を週次で
  • スキーマ進化: 新ユースケース追加時にラベル追加のみ許可、ラベル削除は3ヶ月凍結

2026年時点で押さえておく道具

Property Graph側の状況は2025年後半に大きく動きました。

  • Neo4j: Cypher 25は2025.06でGA、2026.02系でCYPHER_25がデフォルト言語になり SEARCH句(ベクトルインデックス向け)もGA。ベクトル検索とグラフ探索を1つのCypherクエリに組み合わせて書けます。Microsoft GraphRAG手法のNeo4j向け実装として、Neo4jコミュニティ(neo4j-contrib)主導のms-graphrag-neo4jパッケージが実装リファレンスとして使えます
  • Kuzu: 2025年10月のApple買収(公表は2026年2月)でGitHubリポジトリはarchive。Vela PartnersがVela-Engineering/kuzuとしてforkを維持しており、multi-writer対応とn-hop path クエリでNeo4j比の高速化を公表しています(倍率はワークロード次第なので自分のデータで測るのが正解)
  • Neo4j公式GraphRAG Python: PyPI上はneo4j-graphrag(リポジトリ名はneo4j-graphrag-python)として長期サポート下で提供

RDF側はOxigraph(軽量・Rust実装)とApache Jena(枯れた実装)が実務では選択肢。ただし本番運用実績はProperty Graph側と比べて薄いままで、GraphRAGの参考実装もほぼProperty Graph前提です。

GraphRAG導入で最初に落ちる3つの罠

Property Graphを選んだあとでも、GraphRAG固有の落とし穴が3つあります。

  1. エンティティ正規化を後回しにする: 抽出直後に正規化を入れないと、ノード数がPoC後半で2倍3倍に発散します
  2. (a)-[*]-(b)の無制限パスクエリ: 深さ制限を書かないと大規模グラフでは秒単位で返らなくなります。*..6のように必ず上限を書きます
  3. LLMのCypher生成をそのまま実行: SQL injectionと同じで、生成されたCypherは事前チェック層を通してから実行してください。GraphRAGのRAG部分が信頼できても、Graph部分に穴があると全体の信頼性が落ちます

まとめ

  • 迷ったらProperty Graph。特にGraphRAGを最初の90日で回収したいならNeo4j / Kuzu-Velaが第一選択
  • RDFはSPARQL/OWL推論と組織横断連携が明確に要件のときだけ
  • Property Graphで始めても、neosemantics(n10s)でRDFに橋を架けられる。あとから方向転換できる
  • Neo4j 2026.02系のCypher 25 SEARCH句で、ベクトル検索とグラフ探索を1つのクエリに組み合わせて書けるようになった

決定表を眺めて「うちは要件的にRDFかも」と一瞬でも思ったら、実は要件の書き方がまだ抽象度高すぎるサインです。3ヶ月後の自分に読ませて意味が通る粒度まで落とすと、選択肢はだいたい片方に寄ります。ナレッジグラフ全体の構造と設計論は『ナレッジグラフ実践ガイド』にまとめました。この記事はその第3章(RDF vs PG)と第4章(構築7ステップ)を、GraphRAG導入の視点で1本に圧縮したものです。書籍側では第5章以降でGraphRAGとエンタープライズ導入の話を段階的に展開しています。

ナレッジグラフ活用大全 関連書籍 ナレッジグラフ活用大全 ナレッジグラフ 活用大全 | GraphRAG・Neo4j・RDF・Property Graph・Emotion AI の実践書 書籍ページを見る →

関連する記事

記事一覧を見る →