ベクトルデータベースは「この文書に意味が近いものはどれか」に、グラフデータベースは「この口座とつながっている口座はどれか」に答えるためのデータベースです。どちらもリレーショナルデータベース（RDB）の置き換えではなく、RDBが苦手な問いを引き受けます。
この記事では、比較表で違いを押さえたうえで、ナレッジグラフとベクトルデータベースの関係を整理します。続いて、同じ送金データを再帰SQL（PostgreSQL 18）・Neo4j 2026.09・Apache AGEの3つで辿った実測結果を示し、製品の選び分けとGraphRAGで併用するときの判断までを扱います。
まとめ：似たものを探すならベクトル、つながりを辿るならグラフ
扱う問いが「これに似たものは何か」ならベクトルデータベース、「これとつながっているものは何か」ならグラフデータベースを選びます。迷ったときは、答えが「近い順の上位数件」で足りるのか、「条件を満たす全件」が必要なのかで切り分けます。
- ベクトルデータベースは、データを埋め込みベクトルとして持ち、距離の近さで検索します。RAGの検索基盤や類似画像検索が代表用途です。類似検索で返るのは近い順の上位k件なので、「該当を全部」という問いには向きません
- グラフデータベースは、データをノードとエッジで持ち、関係を辿って検索します。不正検知や部品構成、ナレッジグラフが代表用途です
- ナレッジグラフは「知識をエンティティと関係で表す」データの表し方で、グラフデータベースはその置き場所の1つです。RDF形式ならSPARQL、プロパティグラフならCypherで問い合わせます
- 5,000口座・15,000送金の実測では、8段先まで辿っても再帰SQLが約50ミリ秒で答え、グラフ専用DBの速さは出ませんでした。差が出たのは書きやすさと「経路」の数え方です
- RAGで関係を辿る質問や全体を俯瞰する質問が多いなら、ベクトル検索とナレッジグラフを組み合わせるGraphRAGが候補です。全質問をGraphRAGに回す必要はありません
ベクトルデータベースとグラフデータベースの違いを7観点で比べた一覧表
データの持ち方・得意な検索・検索手段・返る結果の性質・代表製品・典型用途・苦手な処理の7軸で並べると、両者は競合ではなく役割分担の関係にあるとわかります。
| 観点 | ベクトルデータベース | グラフデータベース |
|---|---|---|
| データの持ち方 | 高次元ベクトル（埋め込み） | ノード（実体）とエッジ（関係） |
| 得意な検索 | 類似性検索（近似最近傍） | 関係の探索・経路探索 |
| 主な検索手段 | 距離計算＋ANNインデックス | Cypher・Gremlin・GQL・SPARQL |
| 類似検索で返るもの | 距離の近い順の上位k件 | パターンに合う全件 |
| 代表製品 | Pinecone・Milvus・Qdrant・pgvector | Neo4j・Amazon Neptune・ArangoDB |
| 典型用途 | RAG・画像検索・レコメンド | 不正検知・部品構成・知識グラフ |
| 苦手な処理 | 全件列挙・関係の多段探索 | 意味の近さによる曖昧検索 |
ベクトルデータベースは「データ単体の特徴の近さ」、グラフデータベースは「データ間のつながり」を一次的な検索対象にします。苦手な処理の行が互いの得意分野になっているため、類似検索と関係探索の両方が要るなら併用を検討します。ベクトルデータベース単体の仕組みと製品比較はベクトルDBとは？仕組み・インデックス構造・製品比較とpgvectorで動かす手順で扱っています。
仕組みの違い：埋め込みと近似最近傍検索、ノード・エッジとクエリ言語
ベクトルデータベースの仕組み：埋め込み・距離関数・HNSW
ベクトルデータベースは、テキストや画像を機械学習モデルで数百〜数千次元の数値ベクトル（埋め込み）に変換し、座標が近いものを「似ている」とみなします。近さの尺度はコサイン類似度やユークリッド距離です。全件と総当たりで比べると遅いため、HNSWやIVFといった近似最近傍検索（ANN）のインデックスで候補を絞ります。
代表的なHNSWは、Malkov氏とYashunin氏の論文（arXiv:1603.09320）で提案された階層グラフ型のインデックスです。内部で近傍のグラフを辿るため「ベクトルDBの中にもグラフはある」と言えますが、それは検索を速くするための索引で、業務上の関係を表すグラフDBのエッジとは別物です。方式の比較は近似最近傍探索とは？HNSW・IVF・PQの選び分け、パラメータはHNSWとは？階層グラフの仕組みとM・ef_constructionの決め方で整理しています。検索精度は埋め込みモデルの質に加え、文書の分割方法やANNの探索設定にも左右されます。日本語文書なら、まず日本語の埋め込みモデルの選び方から始めます。
グラフデータベースの仕組み：ノード・エッジとCypher・Gremlin・GQL
グラフデータベースは、実体をノード、関係をエッジとして保存します。考え方の数学的な基礎はグラフ理論とはで解説しています。「AさんがBさんをフォローしている」「この部品がこの製品に使われている」といった関係をそのままデータ構造として持つため、多段の関係を問う検索を短く書けます。
問い合わせには専用のクエリ言語を使います。Neo4jはCypher、Amazon NeptuneはGremlin・openCypher・SPARQLの3つに対応します（Neptuneユーザーガイド）。2024年4月12日には、プロパティグラフ向けの国際標準クエリ言語GQLがISO/IEC 39075:2024として発行されました。SQLに対応する位置づけで、構文はCypherに近いものです。弱点は設計の手間で、どの実体をノードにし、どの関係をエッジにするかのモデリングにSQLに慣れたチームでも時間がかかります。
RDBとの位置づけとPostgreSQLで両方を扱う折衷案
RDBは行と列の構造化データと厳密なトランザクションに強く、在庫や会計の管理では今も第一選択です。苦手なのは非構造データの意味検索と、深さの決まらない関係の探索で、そこをベクトルとグラフが補います。
PostgreSQLには、ベクトル型を足すpgvector（2026年10月時点の最新タグはv0.8.7、PostgreSQL 13以上）と、Cypherを足すApache AGE（同PostgreSQL 18向けの最新は1.8.0）があり、1つのDBで両方を試せます。pgvectorの導入はpgvectorとは？インストール手順と使い方、データベース全体の種類はデータベースとは？種類・DBMS・RDBとNoSQLの選び方で整理しています。
ナレッジグラフとベクトルデータベースの違い：表し方と置き場所
「ナレッジグラフ vs ベクトルデータベース」は、厳密には同じ階層の比較ではありません。ナレッジグラフは知識の表し方、ベクトルデータベースは検索の仕組みを持った置き場所です。
ナレッジグラフのデータモデルと格納先としてのグラフDB
ナレッジグラフは「取引先A —担当— 山田」「案件X —顧客— 取引先A」のように、エンティティと関係で知識を表したものです。表し方は2系統あり、主語・述語・目的語の3つ組で書くRDF形式はSPARQLで、ノードとエッジに属性を持たせるプロパティグラフ形式はCypherやGQLで問い合わせます。RDFの語彙設計はオントロジーとは？RDF・RDFS・OWLの違い、問い合わせはSPARQLとは？RDFを検索するクエリ言語の書き方で解説しています。検索エンジンが持つ「Googleナレッジグラフ」は同じ考え方の大規模な実例です（Googleナレッジグラフとは）。
格納先はグラフデータベースが一般的ですが、RDBの表やファイルに置くこともできます。逆にベクトルデータベースは、ナレッジグラフの各ノードや文書の断片を埋め込みにして「意味で引く入口」として併用されます。選ぶ対象は二者択一ではなく、知識を関係として持つか、文章の断片として持つかです。
「全部挙げて」に弱いベクトル検索：LIMIT 100で40件の実測
ナレッジグラフがベクトル検索より強いのは、「取引先Aに関係する案件をすべて」のように全件を求める質問です。ベクトル検索は近い順に上位を返す仕組みなので、該当が何件あるかを知りません。
これは件数の指定にも表れます。pgvector 0.8.7のREADMEは、HNSWの結果は探索候補リストの大きさ（hnsw.ef_search、既定40）で頭打ちになると書いています。20,000件・64次元の表にコサイン距離用のHNSWインデックスを作り、反復スキャンは既定の無効のまま確かめた結果が次のとおりです（実行計画はHNSWのIndex Scan）。
SHOW hnsw.ef_search; -- 40
SELECT count(*) FROM (
SELECT id FROM documents
ORDER BY embedding <=> (SELECT embedding FROM documents WHERE id = 1)
LIMIT 100
) s; -- 40 行しか返らない
SET hnsw.ef_search = 200; -- 同じ問い合わせで 100 行エラーも警告も出ずに、100件のつもりが40件で終わります。RAGで「一覧を出して」という質問を受けるなら、ベクトル検索の件数設定を見直すだけでなく、関係として持っているデータ（RDBの表やナレッジグラフ）から引く経路を用意します。WHERE句で絞るとさらに減る点と、0.8.0から入った反復スキャン（hnsw.iterative_scan）での対処はpgvectorのREADMEに記載があります。
同じ送金データを再帰SQL・Neo4j・Apache AGEで辿った実測
「グラフDBは多段の関係探索が速い」はよく見る説明です。そこで、5,000口座（20件に1件を不正フラグ付き）と15,000件の乱数の送金を、PostgreSQL 18.6の表、Neo4j 2026.09.0 Community、PostgreSQL上のApache AGE 1.7.0の3つに同じ内容で入れ、口座1から1〜N回の送金で届く不正フラグ口座を数えました。PostgreSQLとAGEはIntel Mac上、Neo4jはDocker（Linux VM）上で動かし、時間は2回目以降の値です。実行環境と計時方法（psqlの\timingとcypher-shellの表示）が違うため、数値は同じ桁かどうかの目安として読んでください。
SQLの再帰CTEとCypherの可変長パスの書き方の差
SQLでは、送金表を自分自身と結合し続ける再帰CTEになります。
WITH RECURSIVE path(dst, hops) AS (
SELECT dst, 1 FROM transfers WHERE src = 1
UNION ALL
SELECT t.dst, p.hops + 1
FROM path p JOIN transfers t ON t.src = p.dst
WHERE p.hops < 3
)
SELECT count(DISTINCT a.id) AS flagged_reachable, count(*) AS path_rows
FROM path p JOIN accounts a ON a.id = p.dst
WHERE a.flagged;Cypherでは、段数を*1..3で指定するだけです。同じ文はNeo4jでもAGE（cypher()関数の中）でも動きます。
MATCH (a:Account {id: 1})-[:TRANSFER*1..3]->(b:Account)
WHERE b.flagged = true
RETURN count(DISTINCT b) AS flagged_reachable, count(*) AS path_rows;不正フラグ口座までの経路そのものも、MATCH p = ...で受けて[n IN nodes(p) | n.id]と書けば「1→4988→1200」のように返ります。SQLで経路を返すには、再帰のたびに配列へ口座IDを積む列を自分で足す必要があります。
3段・6段・8段の到達件数と応答時間
| 段数 | 届いた不正口座 | 経路の数 | 再帰CTE | Neo4j | Apache AGE |
|---|---|---|---|---|---|
| 1〜3 | 6 | 6 | 約1ms | 3〜9ms | 6.4ms |
| 1〜6 | 83 | 111 | 5.4ms | 16〜23ms | 139.7ms |
| 1〜8 | 215 | CTE 1,073／Cypher 1,070 | 49〜54ms | 57ms | 1,258〜1,349ms |
届いた口座の数は3つとも一致しました。この規模では再帰CTEが最も速く、Neo4jは同じ桁、AGEは8段で1秒を超えました。AGEはPostgreSQLの表の上でCypherを解釈する拡張で、今回の条件（AGE 1.7.0・既定のインデックス）では段数が増えるほど時間が伸びました。最新の1.8.0や別のデータ分布では結果が変わりうるため、Cypherが書けることと探索が速いことは分けて評価します。グラフDBの速さを理由に導入するなら、自社のデータ量と段数で同じ比較をしてから決めます。比べるのは、関係の数・段数・1ノードあたりの分岐数・経路を返すかどうかを自社の問い合わせに合わせたときの応答時間です。
経路の数が1,073と1,070に分かれた理由
8段では、届いた口座は同じ215件なのに、経路の数がCTEで1,073、Cypherで1,070と食い違いました。原因は「同じ送金を1つの経路で2回通るか」です。Cypher Manualは、既定では同じパターンの中で関係を再び辿らないとしており、送金が輪になっている箇所でCTEだけが同じ送金を往復した経路を数えます。Neo4jでMATCH REPEATABLE ELEMENTSを付けて再実行すると、1,073件になりCTEと一致しました。
不正検知で「資金の経路を何本見つけたか」を指標にするなら、この差は件数の違いとして報告に出ます。SQLで書くときは経路の配列に通った送金IDを持たせて再訪を除く条件を足し、Cypherで輪を含めたいときはREPEATABLE ELEMENTSを明示します。
Neo4jのベクトルインデックスとSEARCH句による1つのDBでの併用
グラフDB側もベクトル検索を取り込んでいます。Neo4jのCypher Manualによると、ベクトルインデックスは5.13で一般提供になり、2026.01でCypherの中にベクトル検索を書けるSEARCH句が入りました。従来のdb.index.vector.queryNodesは2026.04で非推奨です。
CREATE VECTOR INDEX chunkEmbedding IF NOT EXISTS
FOR (c:Chunk) ON c.embedding
OPTIONS { indexConfig: {
`vector.dimensions`: 1536,
`vector.similarity_function`: 'cosine'
}};
MATCH (q:Chunk {id: 'query-001'})
MATCH (c:Chunk)
SEARCH c IN (
VECTOR INDEX chunkEmbedding
FOR q.embedding
LIMIT 6
) SCORE AS score
WITH q, c, score WHERE c <> q
MATCH (c)-[:MENTIONS]->(e:Entity)
RETURN c.id, score, collect(e.name) AS entities;Chunkノードに1,536次元の埋め込みとMENTIONS関係が入り、インデックスがONLINEになっている前提で、意味が近いチャンクからそのチャンクが言及するエンティティまでを1回で辿る問い合わせです。2026.09.0で動かすと、注意点が3つありました。
SEARCH句はCypher 25専用です。先頭にCYPHER 5を付けると42I67（CYPHER 25でなら解釈できる）のエラーで止まります。既存DBの既定言語はSHOW DATABASES YIELD name, defaultLanguageで確かめます- 問い合わせ元のチャンク自身がスコア1.0で1位に入ります。上の例の
WHERE c <> qを書かないと、上位の1枠を自分で使います - 次元数は1〜4,096、類似度関数は
cosineとeuclideanだけです。4,097次元やdotを指定するとインデックス作成時にエラーになります
関係を辿る問いが主役なら、DBを2つ持たずにこの構成で始められます。ベクトル検索の件数と負荷が主役なら、専用のベクトルデータベースへ分けた構成と、応答時間・メモリ・費用を並べて比べてから決めます。Neo4j単体の構造とエディションはNeo4jとは？グラフデータベースの構造とCypher・エディション選定で整理しています。
代表的なベクトルデータベースとグラフデータベースの製品と2026年10月時点の版
版番号は変わりやすいため、採用前に各公式ページで仕様と料金を確認してください。
ベクトルDBの製品：Pinecone・Weaviate・Milvus・Qdrant・pgvector
運用をベンダーに任せたいならフルマネージドのPineconeが手堅く、費用は保存量と読み書きの使用量で決まり、専用の読み取りノード（Dedicated Read Nodes）を使う構成では時間課金も加わります（料金ページ）。キーワード検索とベクトル検索を組み合わせるなら、ハイブリッド検索を標準で持つWeaviateが扱いやすい設計です。十億ベクトル超の規模ならMilvus（最新はv3.0.3）とマネージドのZilliz Cloud、Rust製でメタデータの絞り込みに強いのがQdrant（同v1.19.2）です。ローカル開発にはChroma（ChromaDB）が軽量です。
既存のPostgreSQLを活かすならpgvectorでDBを増やさずに始められます。クラウドのマネージド構成ならAzure Cosmos DB for NoSQLのベクトル検索やAmazon S3 Vectorsも候補です。料金体系の違いはベクトルデータベースの価格とおすすめで比べています。
グラフDBの製品：Neo4j・Amazon Neptune・ArangoDB・Apache AGE
グラフDBの代表格はNeo4jで、Cypherの情報量とコミュニティの厚さが導入のしやすさにつながります。版番号は年と月に基づくカレンダー形式で、2026年10月時点の最新は2026.09系です。AWSでマネージド運用するならAmazon Neptuneで、分析向けのNeptune Analyticsとの違いはAmazon Neptuneとは｜3つのクエリ言語・Analyticsとの違いで解説しています。
ドキュメント・グラフ・キー値を1つで扱いたいならArangoDBのマルチモデル構成、PostgreSQLの運用に乗せたいならApache AGEです。前章の実測（1.7.0）では深い探索ほど時間が伸びたため、AGEを選ぶなら、実際のデータと段数で応答時間を測ってから決めます。Azureでの選択肢はAzureのグラフDBはどれを使う？で整理しています。RDF形式の知識グラフをSPARQLで問い合わせるなら、NeptuneのほかApache Jena Fusekiとは？Jena 6の変更点とインストール・Docker運用で扱うようなRDFストアが候補になります。
用途別の使い分けとベクトルもグラフも見送る場面
不正検知・レコメンド・社内文書検索での選び分け
不正検知では、取引パターンの異常を「似た不正プロファイルとの近さ」で捉えるならベクトル、「同一人物が複数口座を操る関係」を暴くならグラフが有効です。レコメンドでは、商品そのものの特徴で似た品を出すならベクトル、購買履歴のつながりから「この商品を買った人が次に買う品」を出すならグラフが向きます。社内文書の検索ならまずベクトル検索で足り、型番や固有名詞の完全一致も拾いたいときはBM25と組み合わせるハイブリッド検索へ進みます。
決め手は、ユーザーが投げる問いの主語が「内容」か「関係」かです。内容ならベクトル、関係ならグラフ、全件を返す必要がある質問が混じるなら関係として持つ側を必ず用意します。
専用DBを採用しない方がよいデータ規模と業務の条件
データが数千件で関係も浅いなら、ベクトルもグラフも過剰です。数万件程度のベクトル検索なら、まずpgvectorでインデックスを張らない厳密検索の応答時間を測り、要件を満たすなら専用DBは足しません。関係の探索も、前章の実測規模（数千ノード・数万エッジ）なら再帰CTEで十分速く、グラフDBを足す理由は速さではなく書きやすさになります。
会計や在庫のように表形式の集計が中心で、関係を辿る問いがない業務は、グラフDBへ移さずRDBに留めます。Neo4jにもcountやsumなどの集計関数とACIDトランザクションはありますが（Operations Manual）、移す利点がなければデータモデルの作り直しと運用基盤の追加が負担として残るだけです。
GraphRAGでベクトル検索とナレッジグラフを併用する構成と導入手順
ベクトルRAGが苦手な質問とGraphRAGのインデックス処理
ベクトルRAGは意味の近い断片を返すのは得意ですが、複数文書をまたいで関係を辿る質問や「この資料群の主要なテーマは何か」のような俯瞰する質問は構造的に苦手です。近い断片を数件拾うだけでは全体像が手に入らないためです。
GraphRAGは、文書からエンティティと関係を抽出してナレッジグラフを作り、グラフとベクトル検索を組み合わせてこの弱点を補います。Microsoft GraphRAGの公式ドキュメントでは、分割したテキストからエンティティ・関係・主張を抽出し、Leiden法で階層的なコミュニティにまとめ、コミュニティごとの要約を生成する流れが示されています。元の論文（arXiv:2404.16130、最新は2025年2月19日の第2版）は、100万トークン規模のデータで、全体把握が要る質問に対し回答の網羅性と多様性が従来型RAGを上回ったと報告しています。勝率は評価方法とデータに依存するため、自社データで同じ質問セットを比べてから判断します。
Microsoft GraphRAG 3.3をCLIで動かす最小手順
2026年10月8日にPyPIへ出たv3.3.0は、Python 3.11以上3.14未満が要件です。3.2系以前の手順にあったPython 3.10は外れています。
python3.12 -m venv .venv
source .venv/bin/activate # Windows は .venv\Scripts\activate
python -m pip install graphrag==3.3.0
graphrag init --model gpt-4.1 --embedding text-embedding-3-large
# .env の GRAPHRAG_API_KEY にAPIキーを設定し、input フォルダへテキストを置く
graphrag index
graphrag query "この資料群で繰り返し出てくる主要なテーマは何か"
graphrag query "取引先Aと関係する案件と担当者は誰か" --method local3.3.0のgraphrag initは、オプションを付けないと既定のチャットモデル（gpt-4.1）と埋め込みモデル（text-embedding-3-large）を対話で尋ねます。自動化するときは上のように--modelと--embeddingで渡します。生成されるのはsettings.yaml・.env・input・promptsで、ベクトルストアの既定はLanceDBでした。Intel Mac（x86_64）のPython 3.12では依存するlancedb 0.38系の配布物が見つからずインストールが止まり、Linuxコンテナ（python:3.12-slim）では入りました。
検索方式は--methodで選び、全体を俯瞰するglobal（既定）、特定エンティティ周辺を調べるlocal、ローカル検索にコミュニティ情報を加えるdrift、通常のベクトルRAGにあたるbasicの4つです（CLIリファレンス）。インデックス作成では文書全体に対してLLMを呼ぶため、費用は埋め込み生成だけのベクトルRAGより大幅に増えます。小さな文書群で費用を測ってから対象を広げてください。Azure上での構成はGraphRAGをAzureで動かす方法で手順を示しています。
全量GraphRAGにせず質問の種類で振り分ける判断
多くの質問は通常のベクトルRAGで足り、関係を辿る質問や俯瞰質問だけをグラフに振り分ける構成が現実的です。質問の意図でDB・ベクトル検索・ナレッジグラフを使い分ける設計はOmniRAGとは？意図に応じてDB・ベクトル検索・ナレッジグラフを使い分けるRAG設計パターンで整理しています。
GraphRAGを採用するのは、人・組織・案件など固有のエンティティが多く、その関係を問う質問が利用ログの一定割合を占める場合です。FAQやマニュアル検索のように答えが1つの文書に収まる質問が大半なら、GraphRAGは見送ります。通常のRAGで評価し、追加のインデックス費用に見合う改善が確かめられたときだけ広げます。ベクトルRAGに留め、リランクやハイブリッド検索で精度を上げる方が先です。RAGの組み立てはLangChainでRAGを構築する手順で確認できます。自社データでベクトルDBとナレッジグラフをどの範囲で使うかの設計から相談したい場合は、一創のRAG構築支援で検索基盤の選定から実装まで対応しています。
ベクトルデータベースとグラフデータベースの違いに関するよくある質問
グラフDBとベクトルDBの違いを一言で言うと？
ベクトルDBは「意味が近いもの」を類似度の順に探し、グラフDBは「関係でつながっているもの」をパターンの条件で探します。前者はRAGや類似画像検索、後者は不正検知や部品構成に向きます。両方が必要なら、Neo4jのようにベクトルインデックスを持つグラフDBか、pgvectorとApache AGEを入れたPostgreSQLで1つのDBに載せる構成も取れます。
グラフデータベースとは何ですか？
実体をノード、関係をエッジとして保存し、つながりを辿る検索に特化したデータベースです。Neo4jのCypher、Amazon NeptuneのGremlin・openCypher・SPARQLなど専用のクエリ言語で問い合わせます。2024年には標準クエリ言語GQLがISO/IEC 39075として発行されました。
ベクトルデータベースとは何ですか？
データを高次元の数値ベクトル（埋め込み）として保存し、距離の近さで似たデータを検索するデータベースです。HNSWなどの近似最近傍検索インデックスで、全件比較をせずに上位候補を返します。pgvectorではHNSWインデックスを使う検索の件数が既定の探索候補数（40）で頭打ちになるため、件数が要る用途では設定の確認が欠かせません。
グラフデータベースとリレーショナルデータベースの違いは？
RDBは表と結合で関係を表し、グラフDBは関係そのものをエッジとして持ちます。多段の探索はグラフDBの方が短く書けますが、5,000口座・15,000送金・8段の実測ではPostgreSQLの再帰SQLの方が速く答えました。厳密な集計やトランザクションが要る業務はRDB、深さの決まらない関係を頻繁に辿る業務はグラフDBが向きます。
ナレッジグラフとベクトルデータベースはどちらを選ぶべきですか？
意味の近い情報を引きたいならベクトル、エンティティ間の関係を辿りたい・該当を全件挙げたいならナレッジグラフです。ナレッジグラフは知識の表し方で、ベクトルDBは検索の仕組みなので、RAGでは両方を組み合わせるGraphRAGが有力な選択肢になります。二者択一にこだわる必要はありません。
