GraphRAGはRDFかプロパティグラフか3問

同じ題材を Neo4j のプロパティグラフで組んだ場合と、RDF/SPARQL で組んだ場合を並べると、得意な問いの種類が割れます。どちらが優れているかではなく、答えやすい問いの形が違います。

「先にどっちが偉いか」を議論する前に、3つの質問で決めるほうが早く終わります。書いてしまえば紙1枚です。Neo4j 5系のCypher 25とISO GQLが動き始めた2026年版で。

GraphRAG で RDF かプロパティグラフかを先に決める理由

GraphRAG界隈にいる方ならご存知の通り、Microsoftが2024年にGraphRAGを公開してから、知識グラフをLLMの検索層に置く構成は珍しくなくなりました。MicrosoftのGraphRAGは生成した三項組をプロパティグラフ形式に変換します (GraphProducer解説)。Microsoft Fabric Graphに至っては「ラベル付きプロパティグラフ(LPG)のみサポート、RDFはサポートしない」と明言しています (Microsoft Fabric Graph docs)。

つまり大手の最新サービスを使うだけならプロパティグラフ一択に見えます。それでもなぜRDFが残っているのか。理由は単純で、問いの種類が違うから です。「製薬会社の治験データを既存のオントロジーに重ねて推論したい」と「自社CRMの顧客行動をたどってレコメンドしたい」は別の問題です。前者はRDF/SPARQLが30年積み上げてきた推論器とオントロジー資産が効きます。後者はプロパティグラフの素直な可視化とCypherの学習コストの低さが効きます。

判定は5分でいいと書きましたが、判定をしないで進めると、3か月後に「Neo4jで全部組み終わってからオントロジー統合の要件が降ってきて全書き直し」みたいな話になります。逆も起きます。どちらの向きでも起こります。

質問1: 既存オントロジーに乗りたいか

最初の質問はこれだけです。

自分の領域に、既に世界で標準化されつつあるオントロジーがあって、それに乗りたいか?

具体例で言うと、金融ならFIBO、医療ならSNOMED CT やRxNorm、Webコンテンツ全般ならSchema.org。これらが既に「概念とその関係」をRDF/OWL形式で定義していて、業界全体でURIが共有されています。

ここに乗りたい場合は、ほぼ自動的にRDFです。プロパティグラフでも同じ意味の構造は組めますが、外部とのデータ交換のたびにRDFへのマッピングを書くことになります。Neo4jのn10s (neosemantics) プラグインでRDFのインポート/エクスポートはできますが、それは「2つの世界の間にブリッジを毎回引いている」状態で、量が増えると保守コストになります。

逆に、自分のドメインにそんな共通語彙が存在しない、あるいは存在しても採用する気がない場合は、この質問でRDFを選ぶ理由はほぼなくなります。社内CRM、SaaSの行動ログ、リポジトリ内のコード関係 — どれも標準オントロジーがあって嬉しい類のドメインではありません。

質問1がYesならRDF寄り、Noなら次の質問へ。

質問2: データの主な聞き手は組織内か、組織横断か

二つ目の質問です。

このグラフから情報を取り出す「主な聞き手」は、自社のアプリケーション一つか、それとも他組織と共有しながら使うか?

RDFのいちばんの強みは、私の感覚では「組織を超えて意味が壊れない」点です。W3Cの仕様としてのURI、SPARQLの連合クエリ (federated query)、OWLによる推論。これは複数の組織が自分のグラフを持ち寄って統合する場面でほとんど無敵です。Linked Open Dataが20年以上続いている理由でもあります。

一方、プロパティグラフは「単一の組織が自分のドメインを表現する」ときに気持ちよく刺さります。Neo4jのCypherは学習コストが低く、MATCH (a:Customer)-[:BOUGHT]->(p:Product) のような表現が直接書けます。エッジに属性 (購入日、金額、チャネル) を直接ぶら下げられるので、業務ロジックがそのままモデルになります。

判断軸として書き下ろすと、

• 同一企業内のサービス用 = プロパティグラフ
• 複数組織でのデータ統合 / 公的データセットとの相互運用 = RDF
• 学術や標準化を視野に入れる = RDF
• 「うちのCRMで使うだけ」 = プロパティグラフ

質問2が「組織横断」ならRDFを残す理由が増えます。「単一組織」ならプロパティグラフ寄りに針が振れます。

質問3: 関係そのものに属性を頻繁にぶら下げたいか

三つ目です。

グラフのエッジ (関係) に、属性をたくさん、頻繁に乗せたいか?

具体的に言うと、「AさんがBさんに送金した」というエッジに、金額、日時、チャネル、手数料率、不正検知スコアを直接乗せたい、というケース。あるいは「コードAがコードBを呼ぶ」というエッジに、呼び出し回数、最終呼び出し時刻、呼び出し元ファイル、を直接乗せたい、というケース。

プロパティグラフはこの設計が母国語です。エッジ自体がオブジェクトで、ノードと同じように属性を持てます。

CREATE (a:Account {id: "A001"})-[:TRANSFER {
  amount: 100000,
  currency: "JPY",
  timestamp: datetime(),
  channel: "mobile_app",
  fraud_score: 0.02
}]->(b:Account {id: "B042"})

これが書けるかどうかが、業務ロジックがそのままモデルになるか、「もう一段マッピングが要る」かの分岐点です。

RDFでも同じことはできますが、三項組 (主語・述語・目的語) の世界観なので、エッジに属性を載せるには reification という回避テクニックを使います。「この三項組という事実、それ自体について語る」というメタな構造です。RDF 1.2ではRDF-star というショートカット記法が標準入りしましたが、それでも素のプロパティグラフほど自然にはなりません。

質問3が「エッジ属性を頻繁に乗せたい」ならプロパティグラフ。「ほぼノード中心の関係しか張らない」ならRDFも普通に戦えます。

3つの質問の結合

整理するとこうなります。

合計点でだいたい決まります。3つ全部Noだとプロパティグラフ +3点、3つ全部Yesでも軸が割れます (RDF +4点、プロパティグラフ +2点)。迷うケースの多くは質問2か3で針が大きく振れるので、判定そのものは短時間で終わります。

ただしGraphRAG文脈で一つ補足が要ります。LLMからのアクセシビリティ という観点では、2026年6月時点でCypherの方が一歩リードしています。LLMにクエリを書かせる場合、Cypherの方が学習データに大量に乗っており、ZeroShotの正確度が高いという報告が複数あります。GraphRAGをLLMで触らせる前提なら、迷ったときの判断材料として「Cypher側」に薄く重みを足してください。

選んだあとに効いてくる3軸

判定そのものは3問で終わりますが、選んだ側とはこの先ずっと付き合うことになります。効いてくるのは次の3軸です。

「表現力の広さ」と「運用の軽さ」はほぼ反比例します。 3問でどちらかに寄ったら、次はこの表で「その代償を払えるか」を確かめる順番になります。

業界の動き — Cypher 25とGQLが追いついた

2026年に念のため知っておくべき変化は、Cypher側が ISO GQL という標準仕様にほぼ揃ってきたことです。GQLはISO/IEC 39075:2024 として2024年4月に発行され、グラフデータベースの初の国際標準クエリ言語になりました。

Neo4j側の動きは具体的です。Neo4j 5系では Cypher 5 と並んで Cypher 25 が選べるようになっており、Cypher 25 はGQL準拠の関数エイリアス (ceiling, local_time, path_length ほか) や IS LABELED 述語など、GQLの機能を取り込み続けています (Cypher Manual)。Neo4j 2026.02 以降の標準設定では、新しいデータベースは Cypher 25 がデフォルトになりました。

「Cypherはベンダーロックインだ」というRDF派の長年のツッコミに、Cypher側がGQLの旗で答えた、というのが2026年の構図です。プロパティグラフを選ぶ心理的ハードルが、一段下がっています。

一方のRDF側は、Stardog、GraphDB、Virtuoso といった既存のトリプルストアが安定運用フェーズに入り、Apache JenaやOxigraphの軽量実装も健在です。W3CではRDF 1.2 / SPARQL 1.2 のWD (Working Draft) が進行中で、特にRDF 1.2のRDF-star導入はエッジ属性の弱点を埋める方向に効きます。RDFが消える兆候はありません。「乗りたい標準が違うだけ」というのが正しい捉え方です。

実装の道具立ても2025年後半から動きました。エンベデッドで始めるつもりなら、まずどのリポジトリを指しているかを確かめてください。

• Kuzu (エンベデッドのプロパティグラフDB) の本家 kuzudb/kuzu は 2025-10-10 のプッシュを最後にアーカイブされています。現在は Vela Partners の Vela-Engineering/kuzu がフォークを維持していて、こちらには 2026-07 にもコミットが入っています (2026-09-04 に GitHub API で確認)
• Microsoft の GraphRAG 手法を Neo4j 向けに実装した neo4j-contrib/ms-graphrag-neo4j が参考実装として使えます
• Neo4j 公式の Python クライアントは PyPI 上では neo4j-graphrag という名前です (リポジトリ名は neo4j-graphrag-python)

RDF 側の実装は Oxigraph (Rust、軽量) と Apache Jena (枯れている) が実務の選択肢ですが、GraphRAG の参考実装はほぼプロパティグラフ前提です。 「RDF でも組める」と「RDF で組んだ前例がある」は別なので、ここは判定の重みになります。

得意な問いが割れる例

質問1と質問2の差は、具体的な問いに落とすとはっきり出ます。同じ題材を両方式で持ったとして、次の2つを聞くと手触りが逆になります。

• 「最近6か月で頻繁に使っているユーザーが、購入したことのない商品カテゴリは?」
  • プロパティグラフなら数行のCypherで書けます。SPARQL 側はユーザーの活動を時系列で扱うために中間ノードを挟むので、クエリが長くなります。
• 「ある規制Aと、それを参照している規制Bがあって、Bが廃止された場合にAに影響が出るか?」
  • RDF/OWL 側は参照関係をオントロジーで形式化してあれば、推論器が「Aの一部要件はBの廃止で再評価が必要」と導けます。プロパティグラフ側はクエリを手で書くことになり、しかも「廃止の影響範囲」というドメイン知識がクエリの中に埋まります。

前者は社内のデータだけで完結する問いで、後者は標準オントロジー (FIBO 的な世界観) に乗る問いです。質問1と質問2の答えが先に分かっていれば、この差は事前に予測できます。 逆に言うと、両方の問いが同じくらい大事な組織では、3問では決まりません。

決めたあとに落ちる3つの穴

形式を決めても、GraphRAG 側の穴は別に空いています。3つとも、判定を間違えたせいではなく判定のあとで踏むものです。

1. エンティティ正規化を後回しにする。 抽出の直後に正規化を入れないと、同じものを指すノードが増え続けます。PoC の後半でノード数が想定の2倍3倍になるのは、たいていこれです
2. (a)-[*]-(b) を深さ制限なしで書く。 大きなグラフでは秒で返らなくなります。*..6 のように必ず上限を書きます
3. LLM が生成した Cypher をそのまま実行する。 SQL インジェクションと同じ構図です。生成されたクエリは実行の前にチェック層を通します。RAG 側が信頼できても、Graph 側に穴があると全体が落ちます

まとめ — 紙1枚の判定フロー

5分で決まるように、もう一度書きます。

1. 既存オントロジーに乗りたいか? → Yes なら RDF寄り
2. 組織横断で使うか? → 横断ならRDF、単一組織ならプロパティグラフ
3. エッジに属性を頻繁に乗せるか? → 頻繁ならプロパティグラフ

迷ったら プロパティグラフから始めて、必要になったらn10sでRDFブリッジを引く。これはMicrosoft Fabricが現にやっている戦略で、初手のリスクを下げます。逆に最初から既存オントロジーに乗ると分かっているなら、最初からRDFで組んだ方が後悔が少ない。

GraphRAG の実装そのものには別の難所がありますが、土台のグラフモデル選択は、この3つの質問で足ります。3か月後に書き直さない選択を、今5分で。

---

GraphRAGとプロパティグラフ実装の詳細は、私のKindle本にまとまっています。

ChatGPTの嘘を見抜く!Knowledge Graph実践ガイド — RDF vs Property Graphの選定からGraphRAG実装まで、判定基準と実装パターンを一通り。