Skip to content
Published on

知識グラフのツール・フレームワーク地図 — 何を、いつ選ぶか

🇰🇷KO🇺🇸EN🇯🇵JA🇨🇳ZH
Split View필사 모드
シェア
Authors

はじめに — 必要なのはピンではなく地図

知識グラフのツール地形は、この2年で爆発しました。グラフデータベースだけで6つを本気で検討でき、RDFスタックには20年の歴史があり、グラフRAGフレームワークは毎月のように新しく出ます。この種の記事のありがちな失敗は、リンクを30個並べて終わることです。リンク集はもう足りています。

だからこの記事は地図を描きます。カテゴリごとに、何のためのものか、代表ツールを2〜3個、そしていつ何を選ぶかを述べます。このシリーズの実用的な最終編です — なぜグラフRAGか、グラフをどう構築するか、ドメインをどうオントロジーとしてモデリングするかを経て、いよいよ「では何を使うのか」に答えます。

一つ正直な前提を先に。ツールは変わります。この記事を書いている間にも、有名な組み込みグラフDBが一つアーカイブされました。だからツール名よりも選ぶ基準を丁寧に書き残しました。基準のほうが長持ちするからです。

大きな分岐 — プロパティグラフ vs RDFトリプルストア

何を選ぶにせよ、最初の分岐はデータモデルです。二つの家系があります。

プロパティグラフは、ラベル付きのノードとエッジに任意のキー・バリュー属性を付けます。形式スキーマは必須ではなく、開発者フレンドリーで、Cypher(および2024年にISO標準になったGQL)、Gremlin、GSQLで問い合わせます。

// プロパティグラフ (Cypher): 実用的、スキーマは任意
CREATE (a:Person {name: 'Ada'})-[:WORKS_AT]->(c:Company {name: 'AE Ltd'})

RDFトリプルストアは(主語, 述語, 目的語)の三つ組で保存し、グローバルなIRIで実体を識別し、RDFS/OWLで形式オントロジーを定義し、論理推論を回せます。SPARQLで問い合わせ、W3C標準なので組織間の相互運用性が強みです。

# RDF (SPARQL): グローバル識別子、形式的な語彙、推論が可能
SELECT ?person WHERE { ?person a :Person ; :worksAt ?org . }

正直な基準はこうです。大半のLLM・グラフRAGアプリケーションはプロパティグラフが合います。 儀式(ceremony)が少なく、抽出したノイズ混じりのグラフを扱うのに柔軟です。RDFを持ち出すのは形式的な意味が必要なとき — 複数チーム・組織で共有する語彙、論理推論、標準・規制への準拠、データ統合です。オントロジーをどこまで形式化するかはドメインオントロジー編で別途扱いました。

なお、Amazon Neptuneは両方をサポートします(プロパティグラフはopenCypher/Gremlin、RDFはSPARQL)。「すでにAWSにいる」がそれ自体強い理由になります。

グラフデータベース — 何をどこに

6つを実用基準で分けてみます。

  • Neo4j — 事実上の標準。Cypher、最大のエコシステム、最も成熟したツール群。セルフホストまたはマネージドのAuraDB、ベクトルインデックス内蔵、そして後述の1st-party neo4j-graphrag パッケージまで。サーバー型プロパティグラフの安全なデフォルトです。
  • Memgraph — インメモリ、Cypher互換。リアルタイム・低遅延の運用ワークロードとストリーミング更新に強い。2025年のAIツールキット(SQL2Graph, Unstructured2Graph)でオンボーディングの摩擦を下げました。頻繁に変わるデータへの高速な走査が必要ならここ。
  • Kùzu — 組み込み(インプロセス)、いわば「グラフ版SQLite」。カラム型で分析志向、Cypher、ベクトル・全文検索を内蔵。ノートブック・プロトタイプ・単一ノード分析に最適です。正直な注意: Kùzu Inc.は2025年10月にAppleに買収(acqui-hire)され、GitHubリポジトリはアーカイブされました。MITライセンスなのでコミュニティフォークは続きますが、ベンダーのロードマップを前提にした長期の本番依存は慎重に。技術は優秀ですが、ガバナンスの不確実性を価格に織り込む必要があります。
  • ArangoDB — マルチモデル(グラフ + ドキュメント + キー・バリュー)。グラフとドキュメントを一つのストアに置きたいとき。
  • Amazon Neptune — AWSのマネージド。プロパティグラフとRDFの両方をサポートし、Neptune AnalyticsやBedrock Knowledge BasesのGraphRAGにつながります。AWSにいて運用負担を減らしたいならここ。
  • TigerGraph — ネイティブ並列(MPP)、GSQL。大規模グラフのディープリンク分析(不正検知、KYC/AML、レコメンド)に強い。非常に大きく、多段の走査が重い場合。

組み込み vs サーバーはこう分けます。プロトタイプ・ノートブック・単一ノードなら組み込み(Kùzu)。並行性・エコシステム・本番ならサーバー(Neo4j)。マネージドが欲しければNeptuneまたはAuraDB。

RDF・オントロジースタック — 形式的な意味が必要なとき

RDFの道に入ったなら、ツール構成はだいたいこうなります。

  • Protégé — オープンソースのOWL/RDFオントロジーエディタの標準(スタンフォード)。オントロジーを著述する場所です。
  • OWL / RDF / RDFS / SPARQL — W3C標準そのもの。RDFはデータモデル、RDFSとOWLはスキーマと論理、SPARQLは問い合わせ言語。
  • RDFLib — PythonのRDFライブラリ。スクリプティング、小さなグラフ、ETLに向きます。
  • Apache Jena — Javaフレームワーク。Fuseki(SPARQLサーバー)、TDB(トリプルストア)、推論器を含むオープンソースの働き手。
  • Ontotext GraphDB — エンタープライズRDFトリプルストア。SPARQL、RDF-star、推論、そしてベクトル類似度まで。
  • TopBraid (TopQuadrant EDG) — RDF知識グラフ上のエンタープライズデータガバナンス。EDG 8.0(2025年2月)はベクトルDBを内蔵し、実体解決やタグ付けを助けます。商用でガバナンス中心。

選ぶ基準: プロトタイプ・PythonならRDFLib。オープンソースの本番RDFアプリならJena(+Fuseki)。推論と規模が要るエンタープライズのトリプルストアならGraphDB(またはStardog)。データスチュワードシップの組織ならTopBraid EDG。オントロジーの著述はどこでもProtégé。

グラフRAGフレームワーク — 自作か、バッテリー同梱か

ここは二つの軸で分けると選びやすくなります。(1) バッテリー同梱のパイプラインか、組み立て部品か、(2) バッチのインデックスが重いか、軽いか。

  • Microsoft GraphRAG — バッテリー同梱、バッチが重い。全パイプラインを回します: LLMによる実体・関係抽出 → グラフ構築 → Leidenコミュニティ検出 → コミュニティ要約 → ローカル・グローバル検索。**「このコーパス全体の主題は何か」**のようなグローバルな問いに特に強い一方、前段のLLMインデックスコストが大きい。LazyGraphRAG(2024年末)は要約を後回しにし、インデックスコストをベクトルRAG並みまで下げつつグローバル問い合わせの品質を保ちます。コーパス全体の統合が要り、そのコストを払える(あるいはLazyで回避する)ならここ。
  • neo4j-graphrag (Python) — Neo4jの1st-party。エンドツーエンドで、KGビルダー(SimpleKGPipeline)とリトリーバ(Vector, VectorCypher, Hybrid, Text2Cypher)を提供します。Neo4jにコミットし、サポートされた経路が欲しいならここ。
  • LlamaIndex PropertyGraphIndex — フレームワークネイティブ。チャンクごとに抽出器(kg_extractors)を回して実体・関係を付け、グラフストアを差し替え、複数のリトリーバを提供します。すでにLlamaIndexの中なら。
  • LangChain LLMGraphTransformer — 組み立て部品。許可するノード・関係の型をスキーマとして渡すと、ノードと関係を抽出します。パイプラインを自分で制御したいとき。
  • Cognee — エージェントの長期記憶。ECL(Extract, Cognify, Load)パイプライン、グラフ+ベクトルのハイブリッド、複数バックエンド(Kùzu, Neo4j, NetworkX など)。文書QAではなく持続するエージェントメモリが目的なら。
  • txtai — 軽量なオールインワンの埋め込みフレームワーク。セマンティックグラフ(5.0, 2022〜)が埋め込みからエッジを自動生成し、グラフ経路の走査でRAGを行います。専用グラフDBが負担で、ローカルで軽くトピックを探索したいなら。
  • Haystack — 汎用のLLM・RAGパイプラインフレームワーク(deepset)。コンポーネントとしてグラフを組み込めますが、グラフ専用ではありません。オーケストレーション層として見て、グラフ・ファーストのツールとして期待しないこと。

自作 vs バッテリー同梱のコツ: 実体・関係を自分のグラフに入れるだけでよいなら、LangChain/LlamaIndexの抽出器や普通のLLM呼び出しで十分です。Microsoft GraphRAGは、そのコミュニティ要約・グローバル問い合わせの機構が本当に必要なときにだけ元が取れます。

ベクトル + グラフ — 埋め込みの居場所

よくある誤解は、ベクトルかグラフかを二者択一で見ることです。現代のデフォルトはハイブリッドです。

ベクトル検索は曖昧な意味的想起(「こういう文章」)を、グラフ走査は精密な多段の関係(「XとYはどうつながるか」「Zが影響するすべて」)を担います。定石はこうです — ノードやチャンクを埋め込み、ベクトル検索で入口を見つけ、そこからグラフを走査してつながった文脈を引き込む。neo4j-graphrag のVectorCypherRetrieverがまさにこの形です。

そして最近のグラフDBの多く(Neo4j, Kùzu, Memgraph, Neptune Analytics, GraphDB, TopBraid)はベクトルインデックスを内蔵します。そのため別のベクトルDBが必ずしも要りません。埋め込みはグラフを構築するのにも使われます — 似たノードをつなぐ実体解決(entity resolution)がその例で、TopBraid EDG 8.0のベクトルDBやtxtaiのセマンティックグラフがそれを行います。

グラフを使うべきでないとき

正直な反対側の錘を置きます。問いが単一ホップの類似度で解けるなら(「Xに関する文書を探す」「このポリシーを要約して」)、普通のベクトルRAGのほうが単純で、安く、速く、十分です。グラフは抽出パイプライン、ストア、スキーマ、走査ロジックを足し — そのどれもが間違え得ます。

グラフが元を取るのは、次の4つのいずれかが必要なときだけです: 多段の推論、関係を意識した検索、コーパス全体のグローバルな統合、説明可能な出所の追跡。このうちどれが要るのか名指しできないなら、たぶんベクトルRAGが答えです。検索の基礎をまず固める話はプロダクションRAGパターンにまとめました。

もう一つ — ゴミのような抽出の上に建てたグラフは、グラフが無いより悪いです。構築の品質がすべてを左右します(構築編を参照)。

決定フロー

一枚に圧縮するとこうです。

1. 問いに関係が必要か?
   (多段、「XとYはどうつながるか」、コーパス全体の主題)
   いいえ -> 普通のベクトルRAG。ここで止まる。グラフを建てるな。
   はい   -> 続ける。

2. 形式的な意味が必要か?
   (論理推論、組織間で共有する語彙、標準・規制)
   はい   -> RDFスタック: Protege(OWL)で著述、Jena/GraphDBに保存、SPARQLで問い合わせ。
   いいえ -> プロパティグラフ (下記)。

3. グラフDBを選ぶ:
   ローカル / ノートブック / 単一ノード -> Kuzu (注: 2025年にリポジトリがアーカイブ、コミュニティフォーク)
   本番サーバー、最大のエコシステム     -> Neo4j
   リアルタイム / ストリーミング更新    -> Memgraph
   AWSのマネージド                      -> Amazon Neptune
   グラフ + 文書を一つのストアに        -> ArangoDB
   超大規模の並列ディープリンク分析     -> TigerGraph

4. グラフRAG層を選ぶ:
   「コーパス全体の主題」の統合         -> Microsoft GraphRAG (コストはLazyGraphRAGで)
   Neo4jにコミット、1st-partyが欲しい   -> neo4j-graphrag
   すでにフレームワークの中             -> LlamaIndex PropertyGraphIndex / LangChain
   持続するエージェントメモリ           -> Cognee
   軽量 / ローカル / トピック探索       -> txtai セマンティックグラフ

おわりに

地図であってピンではありません。ツールは揺れます — Kùzuが今年の証拠です。揺れないのは問いです。プロパティかRDFかは流行ではなく意味論の問いであり、グラフかベクトルかはハイプではなく関係の問いです。まずその二つに答えてから、ツールを選んでください。

これでシリーズの実用的な終点に着きました。なぜグラフRAGかで理由を、構築で建て方を、ドメインオントロジーでモデリングを、そしてこの記事でツールを扱いました。グラフが過剰なときのためのプロダクションRAGパターンを傍らに置けば、地図は十分です。

最も正直な最後の一行: 最良のグラフプロジェクトはたいてい、問いに答える最小のものであり — ときにそれはグラフが一切無いことです。

参考資料

Discuss on Twitter • View on GitHub