Neo4jとは？グラフデータベースの構造とCypher・エディション選定を実装視点で解説【2026年版】

Neo4jは、データを「もの」と「つながり」の形のまま保存するグラフデータベースです。人・注文・商品といった実体をノードとして置き、その間の関係をリレーションシップという第一級のデータとして持たせます。関係を後から結合して求めるのではなく、最初から線として保存しておく点が、リレーショナルデータベースとの分かれ目になります。

この記事では、Neo4jが内部でどうデータを辿っているのか、Cypherでどこまで書けるのか、Community・Enterprise・AuraDBのどれを選ぶのか、そしてどの案件で採用し、どの案件で見送るのかを、実装者が判断できる粒度で整理します。版番号とサポート期限は参照時点（2026年7月）の公式情報に基づく実測値です。

まとめ：Neo4jの要点と採用判断の軸

• 正体はプロパティグラフDB：ノードとリレーションシップの双方にラベルとプロパティを持たせ、関係そのものを検索対象にできる。
• 速さの源は隣接参照：あるノードから隣を辿る費用がデータ総量に依存しにくく、深いホップ探索でJOINの積み重ねと差が開く。
• 問い合わせ言語はCypher：グラフの形をそのまま書くパターン記述で、ISO標準のGQLに沿った系譜にある。
• 提供形態は3つ：GPLv3のCommunity、商用サブスクリプションのEnterprise、マネージドのAuraDB。クラスタと権限制御はEnterprise以上。
• 版はカレンダー方式：2025年1月からYYYY.MM形式へ移行し、参照時点の最新は2026.06系。長期運用向けは5.26 LTS。
• AI基盤ではベクトル索引と併用：埋め込みの近傍検索とグラフ探索を組み合わせるGraphRAGの土台になる。
• 採用が向く条件：関係の深さが可変で、経路そのものが答えになる案件。集計とレポートが主目的ならRDBのままで足りる。

Neo4jとは何か：プロパティグラフモデルで表すデータ構造の基本

Neo4jはスウェーデン発のグラフデータベースで、商用のグラフDBとしては最も広く使われている部類に入ります。扱うデータモデルはプロパティグラフと呼ばれ、ノードとリレーションシップの両方に任意のキー・バリューを持たせられる点が特徴です。

グラフという用語そのものの定義や、経路探索アルゴリズムの理論的な背景はグラフ理論とは？頂点と辺の基礎から最短経路・グラフDB・GNNの実装応用までで整理しています。ここではデータベース製品としての実装に絞って見ていきます。

ノード・リレーションシップ・プロパティが担うそれぞれの役割分担

Neo4jのデータは4つの構成要素で表現される仕組みです。ノードは実体そのもので、Personのようなラベルで種類を区別します。リレーションシップはノード間の有向の線で、WROTEやPURCHASEDといった型を1本につき1つ持つ設計です。プロパティはノードとリレーションシップの両方に付けられる属性で、購入日や金額のように「関係が持つ情報」も自然に保存できます。ラベルはノードの分類であり、インデックスや制約を張る単位にもなります。

この構造の利点は、テーブル設計で中間テーブルに追い出していた情報を、線そのものに載せられる点です。たとえば「誰がいつ何を買ったか」は、購入テーブルを作らずともPURCHASEDリレーションシップのプロパティとして表せます。関係の種類が増えても、新しい型の線を足すだけでスキーマ変更が済むため、後から関係が生えてくる領域と相性が良い設計になります。

隣接参照によるホップ探索がJOINの積み重ねと違ってくる理由

リレーショナルデータベースで友人の友人を求めるには、結合テーブルを2回JOINします。3ホップなら3回、5ホップなら5回です。各JOINはインデックス探索を伴い、対象行が増えるほど中間結果が膨らみます。深さが可変なら、そもそもSQLで素直に書くこと自体が難しくなります。

Neo4jは、ノードのレコードから隣接するリレーションシップのレコードへ物理的な参照を保持しています。あるノードの隣を辿るときにグローバルな索引を引き直さないため、1ホップの費用がデータベース全体の規模にあまり左右されません。この性質があるので、深さが読めない探索や、経路の形そのものを条件にする問い合わせで差が出ます。

逆に、全件を舐めて合計や平均を出す処理は、列指向のDWHやRDBの方が速い場面が大半です。グラフDBは万能の置き換えではなく、探索という一点に強い専用機だと捉えるのが実態に合っています。カテゴリとしての位置づけと他方式との比較はベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】にまとめました。

Cypherの基本文法：MATCHとMERGEで関係をたどる問い合わせ

Neo4jの問い合わせ言語はCypherです。丸括弧でノード、角括弧と矢印でリレーションシップを表し、グラフの形をそのまま文字で描く構文になっています。グラフ問い合わせ言語のISO標準であるGQLはCypherを源流のひとつとしており、記法の考え方は共通しています。

パターンマッチでノードと関係を同時に指定するクエリの組み立て

もっとも基本的な読み取りはMATCH句です。SQLのSELECTに相当し、探したいグラフの形をパターンとして書きます。次の例は、ある人物が書いた記事のうち、特定のタグが付いたものを取り出す問い合わせです。

MATCH (p:Person {name: '佐藤'})-[:WROTE]->(a:Article)-[:TAGGED]->(t:Tag {name: 'graph'})
RETURN a.title, a.publishedAt
ORDER BY a.publishedAt DESC
LIMIT 20

可変長のホップは矢印の中に範囲を書く方式です。-[:KNOWS*1..3]- と書けば1〜3ホップの知人関係を辿る意味になり、深さの上限だけを決めて探索できます。SQLの再帰CTEで同じことを書くのに比べると、意図が読み取りやすい記述です。最短経路を求める関数も用意されており、経路そのものを値として返せる点がグラフDBらしい部分です。

MERGEと制約とインデックスで書き込み時の重複を抑える設計

書き込みではCREATEとMERGEの使い分けが必要です。CREATEは無条件に作るため、同じ人物のノードが何度でも増える原因になります。MERGEは「あれば取得、なければ作成」の動きをするので、外部システムから繰り返し取り込むデータには基本的にMERGEを使います。

MERGE (p:Person {employeeId: 'E1024'})
  ON CREATE SET p.createdAt = datetime()
  ON MATCH SET p.updatedAt = datetime()
MERGE (d:Department {code: 'DEV'})
MERGE (p)-[:BELONGS_TO]->(d)

ここで見落とされやすいのが索引と制約です。MERGEはパターンに一致するノードを探す動作を含むため、キーとなるプロパティに一意性制約を張っていないと全走査になり、取り込み件数が増えた途端に遅くなります。ラベルとプロパティの組に一意性制約を作れば、内部で索引も作られ、重複ノードの発生も同時に防げます。取り込み処理を書く前に、どのプロパティを業務上のキーとするかを決めておく作業が先に済ませる工程です。

大量投入では、1件ずつのトランザクションを避け、数千件単位でまとめてコミットする実装が基本です。CSVからの一括取り込み構文や、行の集合を分割しながら処理する仕組みが用意されているので、初期ロードはそちらへ寄せます。1件ずつのMERGEをアプリ側のループで回す実装は、件数が桁違いになった時点で破綻します。

エディションと版数：Community・Enterprise・AuraDBの選び分け

Neo4jの提供形態は3つです。どれを選ぶかで、使える機能と運用の担当範囲が変わる仕組みです。ここを取り違えると、検証は通ったのに本番の可用性要件を満たせないという事故を招きます。

ライセンスと機能境界で分かれる3つの提供形態の実務的な差と判断基準

Community Editionは無償で全機能というわけではありません。単一インスタンス構成が前提で、クラスタによる冗長化、ロールベースの権限制御、複数データベースの同居、細かな監査といった運用機能はEnterprise Edition以上に置かれています。加えてGPLv3である点は、自社製品に組み込んで配布する形態では法務確認が必要になります。社内システムのサーバとして立てて使う分には問題になりにくい一方、SaaSに同梱して配布する構想があるなら、早い段階で確認しておくべき箇所です。

AuraDBはNeo4j社が運用するマネージド提供で、無償枠のほかに従量課金の有償枠が並びます。課金はインスタンスサイズと稼働時間で決まる構成のため、常時稼働の本番用途では月額が読みやすい反面、検証環境を立てっぱなしにすると費用が積み上がります。金額体系は改定されるので、見積時点で公式の料金表を必ず引き直してください。AWS上で同種の要件を満たすなら、マネージドのグラフDBであるAmazon Neptuneとは何か：グラフデータベースの基本的な説明と利点も比較対象に入ります。

カレンダーバージョニングへの移行と5.26 LTSを跨ぐ制約

版番号の体系は2025年1月に変わりました。それ以前は5.26のようなセマンティックバージョニングでしたが、以降はYYYY.MM.Patch というカレンダー方式になり、月次で新しい系列が出ます。参照時点（2026年7月）で最新の系列は2026.06系で、2026.06.0が2026年7月2日付、その前の2026.05.0が2026年5月26日付です。

長期運用向けには5.26 LTSが用意されており、サポート終了は2028年6月6日です。パッチ提供が続くため、頻繁な追随が難しい基幹用途ではこちらが現実的な選択になります。旧LTSの4.4系は2025年11月30日でサポートが終了しているので、まだ4.4で動いている環境があるなら移行計画が要ります。

移行で注意すべき制約が2点あります。ひとつは経由点で、5.x以前から新しいカレンダー系列へ上げる場合、5.26 LTSを一度経由する必要があり、飛び越えられません。もうひとつが実行環境で、2025.01.0以降はJava 21が前提です。5.26 LTSはJava 17と21の双方で動くため、先にJavaを21へ揃えてからデータベースを上げる順序にすると、切り分けが楽になります。

言語側にも版があります。Cypher 5とCypher 25が併存しており、参照時点の既定はCypher 5です。クエリ単位あるいはデータベース単位で言語版を指定できる仕組みが用意されているため、段階的に移せます。Cypher 5は当面維持され、廃止予定の機能には事前告知が置かれる方針が示されているので、移行を急ぐ必要はありません。ただし新しい構文はCypher 25側にのみ入るため、新規構築なら最初から新しい言語版で書き始める判断もあり得ます。

ベクトル索引とGraphRAG：AI基盤でNeo4jが担う役割

生成AIの文脈でNeo4jの名前が出るのは、ベクトル索引を内蔵したことと、グラフ構造が検索の根拠づけに効くことの2点が理由です。文章の埋め込みベクトルをノードのプロパティとして持たせ、近似最近傍の索引を張れるため、意味的な類似検索とグラフ探索を1つのデータベースの中で完結できます。

埋め込みの近傍検索とグラフ探索を組み合わせる検索設計の考え方

純粋なベクトル検索は、質問に似た断片を集める働きしかしません。断片同士の関係、たとえば「この規程は別の規程を参照している」「この障害はこの部品に起因する」といったつながりは、類似度だけでは復元できません。グラフを併用する設計では、まず近傍検索で入口となるノードを数件見つけ、そこからリレーションシップを辿って周辺の文脈を集め、まとめてLLMへ渡します。

この組み合わせがGraphRAGと呼ばれる手法群です。手法の全体像と適用範囲はGraphRAGの概要とその応用範囲についての詳細解説で解説しています。問い合わせの意図によってグラフ探索と通常のベクトル検索を切り替える設計パターンはOmniRAGとは？意図に応じてDB・ベクトル検索・ナレッジグラフを使い分けるRAG設計パターンで整理しました。

ナレッジグラフ構築で先に見積もっておくべき作業と運用負荷の具体像

実装で費用が膨らむのは、データベースの構築そのものではなく、ナレッジグラフを作る工程です。文書からエンティティと関係を抽出し、表記ゆれを名寄せし、誤って抽出された関係を落とす作業が発生します。LLMに抽出させる方式が一般的になりましたが、抽出結果の品質は対象文書の書式に強く依存するため、実データでの試行が避けられません。

運用面では、元文書が更新されたときにグラフをどう追随させるかという設計が必要です。全再構築は簡単ですが費用がかかり、差分更新は削除された関係の扱いが難所になります。文書IDを持つノードを起点に、その文書から生成した関係だけを消して作り直す形なら、差分更新の実装が現実的な範囲に収まります。

導入判断：Neo4jの採用条件と見送るべき場面をどう線引きするか

ここからは判断の話です。グラフDBは扱う対象を選ぶ道具なので、要件から逆算して線を引きます。以下は受託開発の現場で実際に効いてくる基準です。

採用が妥当になる3つの条件と、その条件を満たさない場合の代替

第一の条件は、探索の深さが可変であることです。組織の指揮系統、部品表の展開、権限の継承のように、何段辿るかが実行時まで決まらない要件では、Cypherの可変長パターンが素直に効きます。深さが常に1〜2段で固定なら、RDBのJOINで十分です。

第二の条件は、関係そのものが答えになることです。不正検知で「同じ端末と口座を共有する申込者の連なり」を出す、レコメンドで「購入者が他に何を買ったか」を辿るといった要件は、経路が結果そのものになります。逆に、集計値や順位表が成果物なら、グラフにする必要はありません。

第三の条件は、関係の種類が増え続けることです。新しいつながりが業務側から次々に出てくる領域では、線の型を足すだけで済む構造が効きます。関係の定義が固定で今後も変わらないなら、テーブル設計の方が運用は素直です。

RDBのままで足りる場面と、移行費用を見誤らないための確認事項

見送るべき場面もはっきりしています。まず、明細を大量に書き込み、月次で集計するだけの業務系です。この形はRDBとDWHの組み合わせが強く、グラフDBに移す動機がありません。次に、全件走査の集計が主役の分析用途です。グラフDBの索引構造は探索向けで、列方向の集計には向きません。もうひとつ、書き込みスループットが極端に高い時系列データの受け皿としても不適です。

既存システムからの移行を検討するときは、費用の見積もりを3つに分けてください。ひとつめはデータモデリングで、テーブルをそのままノードに写すと関係が貧弱なグラフになるため、業務側と組み直す工程が要ります。ふたつめは取り込み実装で、初期ロードと日次同期の両方が必要です。みっつめは運用体制で、Cypherを読み書きできる人員をチーム内に確保できるかという問題です。3つめを見落として導入し、書ける人が1人しかいない状態で運用が止まる例が実際にあります。

判断を早める現実的な進め方は、いま最も重いSQLを1本選び、同じ結果をCypherで書いて実データで比較することです。机上の比較では決着しないので、本番相当のデータ量で応答時間と実装の読みやすさを測る期間を、工程へあらかじめ入れておくのが安全です。

グラフを含むデータ基盤の構成選定、ナレッジグラフの設計、RAG基盤との接続まで、Neo4jを軸にした実装はデータ分析基盤構築・MLOps構築支援で相談を承っています。モデリングから運用引き渡しまで一貫して対応します。

運用と移行：既存のRDBからNeo4jへ段階的に移すための設計手順

全面移行から入る判断は、ほとんどの案件で費用対効果が合いません。現実的なのは、RDBを正とし、探索が必要な部分集合だけをNeo4jへ同期する併存構成です。

正となるデータベースを決めて同期の向きを片方向に固定する運用設計

併存で失敗する原因のほとんどは、双方向同期に手を出すことです。どちらが正なのかが曖昧になり、不整合の調査に時間を取られる結果を招きます。RDBを正とし、Neo4jは探索専用の読み取り側に置く片方向の構成なら、同期が壊れても再構築での復旧が可能です。同期はCDCで差分を流す方式と、日次で全再構築する方式のどちらかを、鮮度要件で選びます。

監視では、ノード数とリレーションシップ数の推移、ヒープとページキャッシュの使用量、遅いクエリのログを見ます。グラフDBはメモリにグラフの作業領域が乗るかどうかで性能が大きく変わるため、データ量の増加に対してメモリ設定を見直す運用が要ります。バックアップはEnterpriseとAuraDBで手段が異なり、Communityでは停止を伴う取得が基本になる点も、構成選定の材料に入れておいてください。

よくある質問

Q1. Neo4jとAmazon Neptuneはどちらを選ぶべきでしょうか

運用体制と既存環境で分かれます。AWS上に基盤が揃っていて運用を任せたいならNeptune、Cypherの表現力とエコシステムを重視するならNeo4jが第一候補です。NeptuneはGremlinやSPARQLも扱える一方、Cypher資産の移植性ではNeo4jに分があります。AuraDBを選べばNeo4jでも運用委託は可能なので、まず運用範囲を決め、その次に問い合わせ言語で絞る順序が判断しやすいでしょう。

Q2. Community Editionを本番で使っても問題ないですか

単一インスタンスで足りる規模なら使えます。ただしクラスタによる冗長化とロールベースの権限制御が使えないため、可用性の要件や利用者ごとの権限分離が必要な案件では要件を満たせません。加えてGPLv3であるため、自社製品へ組み込んで配布する形態では法務確認が必要です。社内向けの参照系として立てる用途が現実的な範囲になります。

Q3. 5.26 LTSと2026年のカレンダー版はどちらで構築すべきですか

更新の追随体制で決めます。月次の新系列に追随できる体制があり、新機能を早く取り込みたいならカレンダー版、変更を抑えて長く動かしたいなら5.26 LTSです。LTSのサポート終了は2028年6月6日なので、それまでに次の移行計画を立てる前提になります。なお5.x以前から新系列へ上げる際は5.26 LTSの経由が必要で、Java 21への切り替えも同時に発生します。

Q4. データ量が数億ノード規模でも安定運用に耐えられますか

規模そのものより、探索の局所性とメモリ配分が判断軸です。全体が数億ノードでも、1回の問い合わせが触る範囲が数千ノードに収まるなら応答は保てます。逆に全体を舐める処理が主役なら、規模が小さくても遅くなる性質です。設計段階で「1クエリが触るノード数」を見積もり、その作業領域がメモリに乗る構成にできるかを確認してください。

Q5. ベクトル検索だけが目的でもNeo4jを選ぶ意味はありますか

類似検索だけが要件なら、専用のベクトルデータベースやRDBの拡張を選ぶ方が構成は軽くなります。Neo4jを選ぶ意味が出るのは、検索した断片の間にある関係を辿って文脈を足したい場合です。将来的にナレッジグラフへ広げる構想があるなら最初からNeo4jに寄せる判断もありますが、当面が類似検索だけなら過剰投資になりやすい部分です。

関連記事

• ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】
• Amazon Neptuneとは何か：グラフデータベースの基本的な説明と利点
• グラフ理論とは？頂点と辺の基礎から最短経路・グラフDB・GNNの実装応用まで
• GraphRAGの概要とその応用範囲についての詳細解説
• OmniRAGとは？意図に応じてDB・ベクトル検索・ナレッジグラフを使い分けるRAG設計パターン