Skip to content
Published on

グラフDB & ナレッジグラフ 2026 完全ガイド — Neo4j 5 · ArangoDB · Memgraph · TigerGraph · Amazon Neptune · Apache AGE · Kuzu · FalkorDB · Dgraph · GraphRAG 徹底解説

Authors

"GraphRAGは、単純なベクトルRAGでは答えられない『グローバルな要約』を可能にする。100万件の文書を統合して1つの質問に答える時代が来た。" — Microsoft Research、GraphRAG論文(2024年4月)

グラフデータベースは2024年から2026年にかけて、二度目の黄金期を迎えています。一度目は2010年代後半の不正検知・推薦システム時代でしたが、二度目はLLM・GraphRAG・エージェントメモリの時代です。Microsoftが2024年4月にGraphRAGを公開し、OpenAIがメモリ機能にナレッジグラフのパターンを採用したことで、Neo4j・ArangoDB・FalkorDBといったツールのGitHubスター数が爆発的に増え、ISOは2024年4月にGQL(Graph Query Language)をSQL以来初めての新しいISOデータベースクエリ標準として採択しました。

2026年5月現在、グラフDBは**プロパティグラフ陣営(Neo4j/Memgraph/TigerGraph)、RDFトリプルストア陣営(GraphDB/Stardog/Virtuoso)、マルチモデル陣営(ArangoDB/SurrealDB)、マネージド陣営(Amazon Neptune/Cosmos DB Gremlin)、組み込み陣営(Kuzu/FalkorDB)、Postgres拡張陣営(Apache AGE)**の6つのカテゴリに分化しています。本記事では各カテゴリの代表ツール、GQL/Cypher/Gremlin/SPARQLクエリ言語、GraphRAGパターン、そして実際の導入事例まで一気にまとめます。

1. 2026年グラフDBマップ — 6陣営への分化

2026年のグラフDB生態系は、単一の勝者がいない多極体制です。

陣営代表ツール中核的特徴
プロパティグラフ(LPG)Neo4j 5、Memgraph、TigerGraphノード・関係・プロパティ、Cypher/GQL
RDFトリプルストアGraphDB、Stardog、Virtuoso、Apache Jena主語-述語-目的語、SPARQL
マルチモデルArangoDB、SurrealDB、OrientDBドキュメント + グラフ + KV
クラウドマネージドAmazon Neptune、Cosmos DB Gremlin、AuraDBマネージドSaaS
組み込みKuzu、FalkorDB、NetworkXローカル・分析ワークロード
Postgres拡張Apache AGE、pgRoutingPostgres上のグラフ

核心となる洞察は「グラフDBはもはやニッチではなく、RAG・エージェント・MDMのインフラ」という点です。2024年のMicrosoft GraphRAG論文とともに、Neo4jのLLM Knowledge Graph Builder、FalkorDBのGraphRAGパッケージが登場し、AWSはNeptune Analyticsをリリースしました。今やグラフはベクトルDBとともにRAGスタックの標準コンポーネントとなりました。

2. GraphRAGの登場 — 2024年4月の転換点

2024年4月にMicrosoft Researchが発表した「From Local to Global: A Graph RAG Approach to Query-Focused Summarization」論文は、グラフDB市場の転換点となりました。従来のベクトルRAGは「100万文書のうち最も類似する5件をLLMに渡す」モデルなのでグローバルな質問(「全体としてどんなトレンドがあるか?」)に弱かったのですが、GraphRAGはLLMでエンティティ・関係を抽出してナレッジグラフを作り、その上でcommunity detectionを実行して階層的な要約を生成します。

# Microsoft GraphRAG の基本フロー(コンセプトコード)
from graphrag.index import build_index
from graphrag.query import GlobalSearch, LocalSearch

# 1. インデックス化 — 文書をLLMで分解してエンティティ/関係を抽出
index = build_index(
    documents="./data/*.txt",
    llm_model="gpt-4o",
    embedding_model="text-embedding-3-small",
    community_levels=3,  # Leidenアルゴリズム3段階
)

# 2. グローバル検索 — コミュニティ要約ベース
global_search = GlobalSearch(index)
answer = global_search.search("このデータセットの中心的なテーマは?")

# 3. ローカル検索 — 特定エンティティ周辺の探索
local_search = LocalSearch(index)
answer = local_search.search("Sam AltmanとOpenAIボードの関係は?")

GraphRAGが意味したのは、「グラフDBはLLM時代のメモリインフラ」という再定義です。Neo4j・FalkorDB・Kuzu・Memgraphはこの流れに合わせてLLM統合ツールを素早く発表し、2025年にはLangChain・LlamaIndexの双方がProperty Graphインデックスを標準モジュールとして追加しました。

3. Neo4j 5 — 事実上の標準

Neo4j(Neo4j Inc.、2007年設立、2021年に$325M Series F調達)はグラフDBの事実上の標準です。2026年5月時点でNeo4j 5.xシリーズが安定版で、中核的な価値は次の3つです。

第一に、Cypherクエリ言語MATCH (a)-[:KNOWS]->(b) RETURN a, bのようなASCIIアートのパターンマッチングで、グラフパターンを直感的に表現できます。第二に、ACIDトランザクション — 本物のOLTPグラフとして、複数ノード・関係の更新を原子的に保証します。第三に、Graph Data Science(GDS)ライブラリ — PageRank・community detection・shortest path・node embeddingなど70以上のアルゴリズムを、GPUなしのシングルノードで実行できます。

// Neo4j 5 Cypher — 映画推薦グラフパターン
MATCH (user:User {id: $userId})-[:RATED]->(movie:Movie)<-[:RATED]-(other:User),
      (other)-[:RATED]->(rec:Movie)
WHERE NOT (user)-[:RATED]->(rec)
WITH rec, COUNT(*) AS strength
RETURN rec.title, strength
ORDER BY strength DESC
LIMIT 10

Neo4j 5の主な新機能は、Composite Database(複数のグラフを1つのクエリで結合)、Vector Index(2023年10月追加、OpenAIのEmbeddingのようなベクトルをグラフノードに保存)、Parallel Runtime(読み取りクエリの並列実行)です。ライセンスはCommunity Edition(GPLv3)、Enterprise(商用)、AuraDB(SaaS)の3つに分かれます。

4. CypherとGQL — ISO標準となったグラフクエリ

Cypherは2011年にNeo4jが作ったグラフクエリ言語で、2015年にopenCypherプロジェクトとして公開、2024年4月にISO/IEC 39075(GQL — Graph Query Language)として標準化されました。SQL(1987年)以来、ISOが採択した最初の新しいデータベースクエリ言語です。

// 1. CREATE — ノードと関係を作成
CREATE (alice:Person {name: 'Alice', age: 30})
CREATE (bob:Person {name: 'Bob', age: 28})
CREATE (alice)-[:KNOWS {since: 2018}]->(bob)

// 2. MATCH — パターンマッチング
MATCH (p:Person)-[:KNOWS*1..3]->(friend)
WHERE p.name = 'Alice'
RETURN DISTINCT friend.name

// 3. MERGE — UPSERT
MERGE (city:City {name: 'Tokyo'})
ON CREATE SET city.population = 13960000
ON MATCH SET city.last_seen = datetime()

GQLはCypherの後継で、SQLとともにISO/IEC 9075 / 39075の2トラックで管理されます。Neo4j・SAP HANA・TigerGraph・MemgraphがGQL互換作業を進めており、2026年末までにほとんどのプロパティグラフDBがGQL 1.0をサポートする予定です。

5. Memgraph — インメモリのCypher互換

Memgraph(Memgraph Inc.、2016年〜、クロアチア)はNeo4jとCypher互換のインメモリグラフDBです。中核的な差別化点は3つあります。第一に、インメモリ優先+ディスク永続化 — 全データがRAM上にあり、Neo4j比で5〜10倍速いクエリ応答を提供します。第二に、MAGEライブラリ — C++/Python/Rustで書かれたグラフアルゴリズムとLLMツール。第三に、Memgraph Lab — ビジュアルIDE。

# Memgraph Platform をDockerで起動
docker run -p 7687:7687 -p 7444:7444 -p 3000:3000 \
  --name memgraph memgraph/memgraph-platform

# Cypherシェルに接続
docker exec -it memgraph mgconsole

# インメモリのグラフアルゴリズムを呼び出す(MAGE)
CALL pagerank.get() YIELD node, rank
RETURN node.name, rank ORDER BY rank DESC LIMIT 10;

Memgraphは2024年からGraphRAG・エージェントメモリに特化した機能を追加しており、MAGEにはLLMベースのエンティティ抽出アルゴリズム、node2vectext-to-cypherのようなモジュールが含まれます。ライセンスはCommunity(BSL 1.1、一定期間後にApache 2.0)とEnterprise。

6. TigerGraph — 分散グラフ + GSQL

TigerGraph(TigerGraph Inc.、2012年〜、米国)は分散処理に特化した商用グラフDBです。中核的な差別化点はGSQL — SQLフレンドリーなグラフクエリ言語 — と、MPP(Massively Parallel Processing)アーキテクチャです。数十億ノード・数千億エッジ規模で、高速な多段ホップクエリ(>3 hops)を保証します。

-- GSQL例:友達の友達の友達(3ホップ)推薦
CREATE QUERY recommend_friends(VERTEX seed) FOR GRAPH SocialNet {
  SumAccum @score;
  Start = {seed};

  Friends = SELECT v FROM Start:s -(KNOWS:e)- :v;
  FoFs    = SELECT v FROM Friends:s -(KNOWS:e)- :v
            WHERE v != seed
            ACCUM v.@score += 1;

  PRINT FoFs[FoFs.@score] LIMIT 10;
}

TigerGraphはSKテレコム、中国人民銀行、中国工商銀行などの大型金融機関で不正検知に導入されており、2024年にはGraphRAGモジュールを発表しました。ライセンスは商用ですが、TigerGraph Cloud(SaaS)とTigerGraph DB Free Tier(1Bエッジ限定)を提供します。

7. ArangoDB — マルチモデルの代表

ArangoDB(ArangoDB Inc.、2014年〜)はドキュメント・グラフ・キーバリューの3モデルを1つのエンジンで扱うマルチモデルDBです。中核的な価値は**1つのクエリでドキュメント・グラフ・KVを一緒に扱えるAQL(ArangoDB Query Language)**です。

// AQL — グラフ + ドキュメント + フィルタを1つのクエリで
FOR user IN users
  FILTER user.country == "JP"
  FOR friend IN 2..3 OUTBOUND user knows_edges
    FILTER friend.age >= 18
    RETURN { user: user.name, friend: friend.name }

ArangoDBは2024年の4.0でGraphML統合、2025年の3.12でVector Searchを追加し、ArangoSearch(ArangoSearch + Vector)はRAGワークロードで頻繁に使われています。ライセンスはCommunity(Apache 2.0)とEnterprise。SaaSはArangoGraph(旧Oasis)として提供されます。

8. Amazon Neptune — AWSのグラフマネージド

Amazon Neptune(2018年〜、AWS)はプロパティグラフ(Gremlin・openCypher)とRDF(SPARQL)を1つのエンジンでサポートするマネージドグラフDBです。2023年にNeptune ML(GNNベース推薦)、2024年にNeptune Analytics(インメモリ分析エンジン)をリリースし、2025年にはopenCypherを一級としてサポートし始めました。

# Neptune Gremlin (Python boto3)
import boto3
from gremlin_python.driver.driver_remote_connection import DriverRemoteConnection
from gremlin_python.process.anonymous_traversal import traversal

conn = DriverRemoteConnection(
    'wss://my-cluster.cluster-xxx.us-east-1.neptune.amazonaws.com:8182/gremlin',
    'g'
)
g = traversal().withRemote(conn)

# 友達の友達推薦
result = (g.V().has('person', 'name', 'Alice')
            .out('knows').out('knows')
            .dedup()
            .limit(10)
            .values('name')
            .toList())

Neptuneの最大の魅力はAWSとの統合です。IAM・VPC・CloudWatch・SageMakerと自然に連携し、バックアップ・HA・暗号化が自動です。2025年にGAされたNeptune Analyticsは50Bエッジ規模の分析を分単位で完了できるため、GraphRAGのインデックス構築に適しています。

9. Apache AGE — Postgres上のグラフ

Apache AGE(A Graph Extension、2020年BitNine寄贈、Apache 2.0)はPostgreSQLにopenCypherを乗せる拡張です。既存のPostgresインフラをそのまま使いつつグラフクエリを追加したい場合に最も自然な選択です。

-- Apache AGE — PostgresでopenCypherを実行
CREATE EXTENSION age;
LOAD 'age';
SET search_path = ag_catalog, "$user", public;

-- グラフ作成
SELECT create_graph('social');

-- SQLの中でCypherを実行
SELECT * FROM cypher('social', $$
  CREATE (a:Person {name: 'Alice'})-[:KNOWS]->(b:Person {name: 'Bob'})
  RETURN a, b
$$) AS (a agtype, b agtype);

-- パターン検索
SELECT * FROM cypher('social', $$
  MATCH (p:Person)-[:KNOWS*1..3]->(f:Person)
  RETURN p.name, f.name
$$) AS (person_name agtype, friend_name agtype);

AGEの中核的な価値は「Postgresのトランザクション・インデックス・レプリケーション・拡張エコシステムをそのまま活用」できる点です。pgvector・PostGIS・TimescaleDBと同じDBで併用できるため、RAGスタックに自然に組み込まれます。限界は性能 — 深い多段ホップクエリでは専用グラフDB比で遅くなります。

10. Kuzu — 組み込み型の分析グラフDB

Kuzu(ウォータールー大学/Kuzu Inc.、2022年〜、MIT/Apache 2.0)はDuckDBのグラフ版を目指す組み込み型グラフDBです。単一バイナリ・Pythonホイールでインストールでき、分析ワークロード(OLAP)に最適化されています。

import kuzu
import pandas as pd

# 組み込みDB作成
db = kuzu.Database("./mydb")
conn = kuzu.Connection(db)

# スキーマ定義
conn.execute("CREATE NODE TABLE Person(id INT64, name STRING, PRIMARY KEY(id))")
conn.execute("CREATE REL TABLE Knows(FROM Person TO Person, since INT64)")

# Pandas DataFrame をロード
people_df = pd.DataFrame({"id": [1, 2, 3], "name": ["A", "B", "C"]})
conn.execute("COPY Person FROM people_df")

# Cypherクエリ
result = conn.execute("""
  MATCH (a:Person)-[:Knows*1..3]->(b:Person)
  WHERE a.name = 'A'
  RETURN DISTINCT b.name
""")
print(result.get_as_df())

Kuzuは2024年からベクトルインデックスフルテキスト検索を内蔵し始め、LlamaIndex・LangChain統合も進みました。組み込みモデルのおかげでノートPCで10億エッジのグラフ分析が可能で、GraphRAGプロトタイプで非常に人気です。

11. FalkorDB — Redisベースのスパース行列

FalkorDB(2023年、RedisGraphフォーク)はRedisモジュールとして動作するスパース行列ベースのグラフDBです。Redis Labsが2023年にRedisGraphの開発を中止した後にフォークしたプロジェクトで、中核コントリビューターが引き継いでいます。

中核技術は線形代数ベースのグラフ演算 — すべてのグラフクエリをスパース行列の乗算に変換し、GraphBLASライブラリで実行します。これにより多段ホップクエリが非常に高速です。

# FalkorDB — RedisベースのCypher
from falkordb import FalkorDB

db = FalkorDB(host='localhost', port=6379)
graph = db.select_graph('social')

# ノード/関係作成
graph.query("""
  CREATE (a:Person {name: 'Alice'})-[:KNOWS]->(b:Person {name: 'Bob'})
""")

# パターン検索
result = graph.query("""
  MATCH (p:Person)-[:KNOWS*1..3]->(f:Person)
  RETURN DISTINCT f.name
""")
for row in result.result_set:
    print(row[0])

FalkorDBの最大の差別化点はGraphRAG SDK — 文書を入力すると、LLMによるエンティティ抽出 → グラフ構築 → 自然言語クエリのCypher変換までのパイプライン全体を提供します。2025年にはLangChain・Microsoft AutoGenとの公式統合が追加されました。

12. Dgraph — 分散ネイティブGraphQL

Dgraph(Dgraph Labs → Hypermodeにリブランド、2016年〜、Apache 2.0)はネイティブGraphQLを一級クエリ言語として採用した分散グラフDBです。2024年に親会社がHypermodeへリブランドし、LLM・エージェントワークロードにより集中しています。

# Dgraph — GraphQLクエリ
query {
  queryUser(filter: {country: {eq: "JP"}}) {
    name
    friends {
      name
      age
    }
  }
}

# DQL (Dgraph Query Language)
{
  users(func: eq(country, "JP")) {
    name
    friends @filter(ge(age, 18)) {
      name
      age
    }
  }
}

DgraphはRAFT合意アルゴリズムベースの分散処理、自動シャーディング、ACIDトランザクションを提供し、数十億ノード規模でもサブ秒応答を目標とします。2026年5月現在、HypermodeはDgraphの上にエージェントメモリ・MCP統合レイヤーを乗せたSaaSをリリースしました。

13. RDF · SPARQL — セマンティックウェブの正統

プロパティグラフが「ノードとエッジにプロパティを付ける」モデルだとすれば、RDF(Resource Description Framework、W3C 1999/2014)は「主語-述語-目的語(subject-predicate-object)の3つ組」ですべての事実を表現します。W3C標準で、OWL・SHACLのようなオントロジー言語とペアになります。

# SPARQL — DBpediaから日本の総理大臣リストを取得
PREFIX dbo: <http://dbpedia.org/ontology/>
PREFIX dbr: <http://dbpedia.org/resource/>

SELECT ?pm ?name ?term WHERE {
  ?pm dbo:office dbr:Prime_Minister_of_Japan .
  ?pm rdfs:label ?name .
  ?pm dbo:termPeriod ?term .
  FILTER(LANG(?name) = "ja")
}
ORDER BY ?term

RDFは学術・政府・図書館・生命科学分野で標準です。DBpedia・Wikidata・UniProt・DrugBankのような巨大な公共ナレッジグラフはすべてRDFで公開されています。短所は学習曲線 — トリプルモデルが直感的でなく、SPARQLがSQL/Cypher比で複雑です。

14. RDFトリプルストア — GraphDB · Stardog · Virtuoso · Jena

ツール開発元ライセンス特徴
Ontotext GraphDBOntotext商用 + Free強力な推論エンジン、Linked Data
StardogStardog Union商用ナレッジグラフプラットフォーム、virtual graphs
OpenLink VirtuosoOpenLink商用 + GPLDBpedia・UniProtのバックエンド、SQL/SPARQL両対応
Apache Jena FusekiApacheApache 2.0最も人気のあるOSS Jenaサーバー
Blazegraph(legacy)GPL2Wikidataのバックエンド、開発中止
AllegroGraphFranz商用エンタープライズ、neuro-symbolic
RDF4JEclipseEDLSesameの後継、Javaライブラリ

Wikidata Query Serviceは2015年からBlazegraph上で動いてきましたが、2024年に拡張性の限界からQLever(フライブルク大学)への移行が進行中です。これはRDFトリプルストアの世代交代を象徴しています。

15. Apache TinkerPop · Gremlin — グラフのSQL化への試み

Apache TinkerPop(2009年〜)はグラフDB向けの抽象レイヤーで、Gremlinトラバーサル言語を提供します。Neo4j・Neptune・JanusGraph・Cosmos DB・OrientDBなどほとんどのプロパティグラフDBを同じコードで扱えます。

# Gremlin — TinkerPop 標準
from gremlin_python.process.anonymous_traversal import traversal
from gremlin_python.driver.driver_remote_connection import DriverRemoteConnection

g = traversal().withRemote(DriverRemoteConnection('ws://localhost:8182/gremlin', 'g'))

# 友達の友達(2-hop)推薦
result = (g.V()
           .has('person', 'name', 'Alice')
           .out('knows')
           .out('knows')
           .dedup()
           .has('age', P.gte(18))
           .limit(10)
           .values('name')
           .toList())

JanusGraph(Apache、Titanの後継)・OrientDB・Cosmos DB Gremlinはすべて、Gremlinを一級言語として採用します。短所は学習曲線 — Cypherに比べて関数型/チェーンスタイルが直感的ではありません。2024年にGQLがISOに採択されたことで、Gremlinは徐々に影響力を失いつつあります。

16. SurrealDB · OrientDB · Aerospike Graph

SurrealDB(2022年〜、Rust、BSL→Apache 2.0)はマルチモデル(ドキュメント・グラフ・KV・時系列)DBで、SQLに近いSurrealQLを使います。2025年1.0 GA以降急速に人気を集め、組み込み・サーバー・サーバーレスの3モードをサポートします。

OrientDB(2010年〜、SAPがスポンサー、Apache 2.0)は第一世代のマルチモデルグラフDBで、OrientDB-Studio・Gremlin・SQL拡張を提供します。一時はArangoDBと市場を二分していましたが、近年は成長が鈍化しています。

Aerospike Graph(2023年、AerospikeがAeroGraphを買収)はAerospikeのキーバリューエンジンの上にGremlinを乗せた形で、広告IDグラフ・リアルタイム推薦に特化しています。

-- SurrealQL — グラフトラバーサルをSQLのように
SELECT name, ->knows->person.name AS friends
FROM person
WHERE country = "JP"
LIMIT 10;

-- 多段ホップトラバーサル
SELECT ->knows->person->knows->person.name AS fofs
FROM person:alice;

SurrealDBはライブクエリ(WebSocket変更購読)、権限・認証内蔵、JS/Python/Rust SDKを備え、2026年にはSurrealKV(組み込みモード)とSurrealCloud(マネージド)をリリースしました。

17. JanusGraph · ArcadeDB — Apache陣営の分散グラフ

JanusGraph(Apache 2.0、Titanの後継、2017年〜)はApache Cassandra・HBase・BigTableの上で動作する分散グラフDBです。PayPal・Uber・IBM・NASAが採用しており、数十億エッジ規模で検証されています。

# JanusGraph + Cassandra スタック (Docker)
docker run --name janus -p 8182:8182 janusgraph/janusgraph
// JanusGraph Gremlinコンソール
graph = JanusGraphFactory.open('conf/janusgraph-cassandra.properties')
g = graph.traversal()
g.addV('person').property('name', 'Alice').next()

ArcadeDB(2021年、OrientDBの後継、Apache 2.0)はマルチモデル(グラフ・ドキュメント・KV・検索)を単一エンジンに詰め込んだ新興DBで、OrientDB互換APIとCypher・Gremlin・SQLすべてをサポートします。組み込み・サーバー・クラスターの3モードを提供します。

18. Microsoft GraphRAG · LlamaIndex · LangChain

GraphRAGツール陣営は2024年から2026年の間に爆発的に成長しました。

ツール位置づけ特徴
Microsoft GraphRAGPythonライブラリ元祖、community-based summarization
Neo4j LLM Knowledge Graph BuilderWeb UI + ライブラリPDF→グラフ自動化、Neo4jベース
LlamaIndex Property Graph IndexPythonモジュール式、どのグラフDBとも連携可
LangChain Knowledge GraphPython/JSLLMChain + Cypher変換
FalkorDB GraphRAG SDKPythonRedisベース、高速プロトタイプ
Memgraph LangChainPythonインメモリ + GraphRAG
DSPy + GraphPythonプロンプト自動最適化 + グラフ
CogneePythonLLMベースのグラフメモリ
# LlamaIndex Property Graph Index — Neo4jバックエンド
from llama_index.core import PropertyGraphIndex, SimpleDirectoryReader
from llama_index.graph_stores.neo4j import Neo4jPropertyGraphStore
from llama_index.embeddings.openai import OpenAIEmbedding
from llama_index.llms.openai import OpenAI

documents = SimpleDirectoryReader("./data").load_data()

graph_store = Neo4jPropertyGraphStore(
    username="neo4j",
    password="password",
    url="bolt://localhost:7687",
)

index = PropertyGraphIndex.from_documents(
    documents,
    property_graph_store=graph_store,
    embed_model=OpenAIEmbedding(),
    llm=OpenAI(model="gpt-4o"),
)

# 自然言語クエリ → Cypherへ自動変換 → 回答
query_engine = index.as_query_engine(include_text=True)
print(query_engine.query("主要登場人物たちの関係を要約してください"))

19. ベクトルDB vs グラフDB vs ハイブリッド

RAG時代の最も重要な設計上の問いは「ベクトルDB・グラフDB・ハイブリッドのうち何を使うか」です。

  • ベクトルDBのみ(Pinecone, Weaviate, Qdrant, pgvector):単純な意味検索・文書Q&Aに適合。グローバル質問・多段ホップ推論には弱い。
  • グラフDBのみ(Neo4j, ArangoDB):明確なエンティティ・関係構造がある場合(KG、不正検知)に強力。非構造化テキストには別途抽出ステップが必要。
  • ハイブリッド(Neo4j + ベクトルインデックス、FalkorDB + Embedding):最も一般的なGraphRAGパターン。ノードにEmbeddingを保存してベクトル検索でエントリポイントを見つけ、グラフトラバーサルで拡張。
# Neo4j 5 — ノードにベクトルインデックスを作るパターン(ハイブリッド)
# 1. ベクトルインデックス作成
CALL db.index.vector.createNodeIndex(
  'movie-embeddings', 'Movie', 'embedding', 1536, 'cosine'
)

# 2. Embedding付きの映画ノード作成
CREATE (m:Movie {title: 'Matrix', embedding: [0.123, 0.456, ...]})

# 3. ベクトル + グラフを組み合わせた検索
MATCH (m:Movie)
CALL db.index.vector.queryNodes('movie-embeddings', 10, $query_emb)
YIELD node AS similar, score
MATCH (similar)<-[:ACTED_IN]-(actor:Person)-[:ACTED_IN]->(other:Movie)
RETURN other.title, score, COUNT(actor) AS shared_actors
ORDER BY shared_actors DESC, score DESC LIMIT 10

20. 不正検知 — PayPal · 銀行 · 通信キャリア

不正検知(fraud detection)はグラフDBの最も古いキラーアプリです。PayPalは2010年代からNeo4jを導入し、クレジットカード詐欺・アカウント乗っ取り・マネーロンダリング検知に活用しています。中核となるパターンは「同じデバイス・IP・電話番号を共有するアカウントクラスター」のような多段ホップ関係探索です。

// 疑わしいアカウントクラスターの検知
MATCH (a:Account)-[:USED_DEVICE]->(d:Device)<-[:USED_DEVICE]-(b:Account)
WHERE a <> b
WITH d, COUNT(DISTINCT [a, b]) AS accounts_sharing
WHERE accounts_sharing > 5
RETURN d.id AS suspicious_device, accounts_sharing
ORDER BY accounts_sharing DESC LIMIT 20

韓国では新韓カード・KBカード・ウリィ銀行がグラフベースの異常取引検知を部分導入し、日本では三井住友銀行・楽天カードがTigerGraph・Neo4jを使っています。米国ではEquifax・Experianが信用グラフを、通信キャリアのVerizon・AT&TがSIMスワップ詐欺検知にグラフを活用しています。

21. 推薦システム — Netflix · eBay · LinkedIn

推薦システムはグラフDBの2番目のキラーアプリです。ユーザー-アイテム-属性グラフの上にGNN(Graph Neural Network)やPageRank・node embeddingを実行して推薦を生成します。

Netflixは内部で映画・シリーズ・タグ・ユーザーのグラフを運用し、一部にNeo4j・自社グラフシステムを混合で使っています。eBayは商品カタログをGraphDB(Ontotext)で運用し、多言語検索・同義語処理に活用しています。LinkedInのPeople You May Knowは自社グラフシステムLIquidが処理します。

// 映画推薦 — 同じジャンル + 同じ俳優を共有するグラフパターン
MATCH (user:User {id: $userId})-[:WATCHED]->(movie:Movie),
      (movie)-[:HAS_GENRE]->(g:Genre)<-[:HAS_GENRE]-(rec:Movie),
      (movie)<-[:ACTED_IN]-(actor:Person)-[:ACTED_IN]->(rec)
WHERE NOT (user)-[:WATCHED]->(rec)
WITH rec, COUNT(DISTINCT g) AS shared_genres,
          COUNT(DISTINCT actor) AS shared_actors
RETURN rec.title, shared_genres + shared_actors AS score
ORDER BY score DESC LIMIT 10

22. 創薬と生命科学 — Pfizer · Roche · BenevolentAI

生命科学はグラフDBの自然な領域です。タンパク質-遺伝子-疾患-薬剤の複雑な多重関係を表現するのにグラフが最適です。PfizerAstraZenecaRocheが新薬候補発見にNeo4jとRDFトリプルストア(GraphDB・Stardog)を活用しています。

BenevolentAI(英国)は自社ナレッジグラフBKG(Benevolent Knowledge Graph)に70億以上のトリプルを保持し、ALS・COVID-19の創薬研究に活用、2020年にバリシチニブをCOVID-19治療薬として再発見した事例で有名です。UniProtDrugBankChEMBLOpenTargetsのような公共ナレッジグラフがRDFで公開されています。

# OpenTargets — 疾患→ターゲット遺伝子→薬剤のトラバーサル
PREFIX otar: <http://identifiers.org/opentargets/>

SELECT ?disease ?target ?drug WHERE {
  ?disease otar:efoId "EFO_0000676" .  # Alzheimer
  ?disease otar:associatedTarget ?target .
  ?target otar:knownDrugs ?drug .
  ?drug otar:phase ?phase .
  FILTER(?phase >= 3)
}

23. ID解決 · MDM · サイバーセキュリティ

**ID解決(Identity Resolution)**は、複数のチャネル・デバイスで発見される身元情報を1人の人間に統合する作業です。マーケティングの360°顧客ビュー、KYC(顧客確認)、AML(マネロン対策)の中核インフラとしてグラフDBが標準ツールです。

MDM(Master Data Management) — Reltio・Tamr・Stibo・ProfiseeのようなMDMプラットフォームは内部でグラフDBを活用します。製品・顧客・サプライヤー間の複雑な関係を扱うにはグラフが自然です。

サイバーセキュリティでは、BloodHound(Active Directory権限グラフ)がペネトレーションテストの標準ツールで、Stellar CyberLaceworkWizがクラウド資産・脆弱性グラフを扱います。

// BloodHound — Active Directory権限の最短経路
MATCH p=shortestPath(
  (u:User {name: 'low_priv_user'})-[*1..6]->(da:Group {name: 'DOMAIN ADMINS'})
)
RETURN p

24. 公共ナレッジグラフ — DBpedia · Wikidata · YAGO · ConceptNet

ナレッジグラフ規模(2026)公開形式特徴
Wikidata1.1B+ トリプルRDF, SPARQLWikipediaの姉妹プロジェクト、最大のOSS KG
DBpedia580M+ トリプルRDF, SPARQLWikipedia infobox抽出
YAGO 4.5200M+ トリプルRDFWikidata + WordNet、ザールラント大
ConceptNet 5.734M+ トリプルJSON, REST常識推論、MIT
ImageNet KG-JSON視覚オブジェクト分類
OpenStreetMap-XML, PBF地理グラフ

Wikidata Query Serviceは2024年にBlazegraphからQLever・Wikibaseの新バックエンドへ移行中で、DBpedia LiveはWikipediaの編集をほぼリアルタイムに反映します。Microsoft Academic Graphは2021年に終了し、OpenAlex(2022年〜)とSemantic Scholarに代替されました。

25. 韓国におけるグラフ活用 — NAVER · Kakao · Samsung

NAVERは自社のナレッジグラフを検索・サービスに広く活用しています。NAVER知識百科・人物・場所のデータをグラフで統合し、検索のエンティティ回答(Knowledge Panel)の基盤として使っています。Kakao EnterpriseはKG-Cloudを通じて企業向けナレッジグラフSaaSを提供しています。Samsung ResearchはBixbyのナレッジグラフバックエンドとGalaxy AIのコンテキストメモリをグラフで構成しています。

POSTECH PRESM(Personal Relevant Search Modeling)・KAIST DKE研究室ソウル大学校 BiKE研究室が韓国語ナレッジグラフの学術研究を主導しており、NIA(韓国知能情報社会振興院)の公共ナレッジグラフ事業が政府機関への導入を牽引しています。法律事務所のYulchon・Kim & Changは法律ナレッジグラフ導入を検討中です。

26. 日本におけるグラフ活用 — PFN · NTT · Yahoo!Japan

**PFN(Preferred Networks)**はPFN Bio Knowledge Graphで新薬候補発掘の研究を進めており、化学構造・タンパク質・論文を統合しています。NTT Knowledge Computing部門は自社のグラフDBと推論エンジンを開発し、通信・ヘルスケア領域に応用しています。

Yahoo!Japan(LINE Yahoo)は自社のナレッジグラフで検索・ニュース推薦を強化し、楽天は商品カタロググラフとユーザー行動グラフを組み合わせた推薦を運用しています。サイバーエージェントDeNAメルカリは広告・ゲーム・中古取引領域でグラフベース推薦を導入しています。

学術面では、国立情報学研究所(NII)東京大学Horiラボ京都大学 Kyoto KGが日本語ナレッジグラフ研究を進めており、2024年にはJapanese Wikidata活性化プロジェクトが政府支援で開始しました。

27. 可視化ツール — Bloom · Cytoscape · Gephi · yFiles

グラフは可視化が価値の半分です。主要なツールカテゴリは以下のとおりです。

ツールライセンス特徴
Neo4j Bloom商用(Neo4jに同梱)ビジネスユーザー向け、自然言語クエリ
NeoDashApache 2.0Neo4jダッシュボード
Graphileon商用グラフアプリビルダー
Linkurious商用不正検知・インテリジェンス
yWorks yFiles商用JS/HTML/Java/.NETライブラリ
CytoscapeOSS, LGPL生命科学の標準
Cytoscape.jsMITWebグラフ可視化
GephiGPLv3学術・ソーシャルネットワーク分析
GraphvizEPL静的なダイアグラム
Sigma.jsMIT大規模なWeb可視化
Apache ECharts GraphApache 2.0一般チャート + グラフ

GraphRAG時代には可視化ツールもLLMと統合され、自然言語で「このグラフでAlice周辺の3-hopを見せて」のような指示を処理し始めました。Linkurious 2024リリースが代表例です。

28. 意思決定ツリー — どのグラフDBを選ぶか

2026年5月時点での推奨意思決定ツリーは以下のとおりです。

  • 標準・エコシステムが最優先 → Neo4j 5(最も安全なスタート)
  • AWSをすでに使っている → Amazon Neptune + Neptune Analytics
  • Postgresをすでに使っている → Apache AGE
  • インメモリの速度が必要 → MemgraphまたはFalkorDB
  • 数十億エッジの分散が必要 → TigerGraphまたはJanusGraph
  • ドキュメント・KVと併用したい → ArangoDBまたはSurrealDB
  • ローカル・ノートPCの分析 → Kuzu(DuckDBのグラフ版)
  • GraphQLが標準インターフェース → Dgraph / Hypermode
  • RDF・セマンティックウェブの標準 → GraphDBまたはStardog
  • GraphRAGのプロトタイプ → Neo4j + LlamaIndexまたはFalkorDB SDK
  • 公共データのグラフ → Wikidata + SPARQL

選択の中心には常に「クエリ言語の好み(Cypher/GQL/Gremlin/SPARQL)+ データモデル(LPG vs RDF)+ 運用形態(セルフホスト vs マネージド)」の3軸があります。

29. むすび — グラフはRAG・エージェント時代のメモリ

2024年4月のMicrosoft GraphRAG論文と2024年4月のISO GQL標準採択は偶然ではありません。LLMが「テキストの意味」を理解するようになったことで「エンティティと関係の構造」が再び重要になり、ISOはその流れに応じてSQL以来初めての新しいデータベースクエリ標準を正式化しました。

2026年のグラフDBは単なるニッチツールではなく、RAGスタックの標準コンポーネントです。新規プロジェクトであれば「Neo4j 5 + Vector Index + LlamaIndex Property Graph」が最も安全なスタートで、AWS環境ならNeptune Analytics、Postgres環境ならApache AGE + pgvectorの組み合わせが自然です。インメモリ・速度が絶対的な価値ならMemgraphまたはFalkorDB、ローカル分析はKuzuを選べばよいでしょう。

10年前のグラフDBは「関係が多い問題でたまに使うニッチ」でしたが、2026年には「RAG・エージェントメモリ・MDM・不正検知・創薬の標準インフラ」です。次の10年のデータインフラは、SQL(トランザクション)+ Vector(意味検索)+ Graph(関係推論)の3軸の組み合わせの上に構築されることになります。

参考資料