Chaos and Order

💡 왼쪽 원문을 읽으면서 오른쪽에 따라 써보세요. Tab 키로 힌트를 받을 수 있습니다.

はじめに — RAGではなく、エンジンの話
リリースモデル — 毎月出て、翌月にはサポートが切れる
ストレージ — ブロックフォーマットがデフォルトになったあと、recordは静かに退場する
言語 — Cypherにバージョンが付く
GQL — 標準文書からチェンジログへ着地する方法
実行エンジン — パラレルランタイムと、デッドロックを予防するスケジューラ
水平スケーリング — Infinigraphのプロパティシャーディング、ただし別サブスクリプション
どのトラックに立つか — 判断基準
おわりに
参考資料

はじめに — RAGではなく、エンジンの話

このブログでグラフは、最近もっぱらRAGの材料として扱ってきました — Graph RAGとは何かとGraph RAGを動かす道具たちがその筋です。今日は一段下に降ります。グラフを実際に保存しクエリを実行するデータベースエンジンの層で、この1年半のあいだにかなり大きなことが静かに進んでいたからです。

舞台はほぼNeo4jです。好きか嫌いかはさておき、サーバー型プロパティグラフのデファクトであり(2026年グラフDB地形の整理を参照)、何より今このエンジンでは3つの転換が同時に進行しています。リリースモデルが変わり(カレンダーバージョニング)、ストレージのデフォルトが変わり(ブロックフォーマット)、言語がバージョンを持つようになりました(Cypher 5 vs Cypher 25 — そしてその先のISO GQL標準)。3つとも「アップグレードボタンを押せば終わり」ではなく、運用判断を要する変化です。

すべてのバージョン・日付・ポリシーはNeo4j公式のチェンジログとドキュメント、サポートポリシーページ、endoflife.dateで直接確認し、出典は本文にリンクしてあります。

リリースモデル — 毎月出て、翌月にはサポートが切れる

Neo4jは5.26を最後にセマンティックバージョニングをやめ、カレンダーバージョニングへ移行しました。endoflife.dateのNeo4j履歴によれば、最初のCalVerリリース2025.01は2025年2月初旬に出ており、以後2026.06(2026年7月8日GA)までの約17か月でフィーチャーリリースが18件積み上がっています。おおむね毎月1件です。

重要なのはスピードではなくサポートポリシーです。Neo4j公式のサポート対象バージョン文書は、各リリースのホットフィックス提供期間を「原則として次のマイナーリリースが出るまで」と明記しています。実際の表もその通りです — 2026.05のホットフィックスは2026.06が出た瞬間に終わります。つまりCalVerリリース1件の実質寿命は4〜6週間です。

トラック	バージョン	ステータス(2026-07-17時点)
LTS	4.4	2025-11-30にEOL
LTS	5.26(2024-12-06)	ホットフィックスは2028-06-06まで、最新パッチ5.26.28(2026-06-30)
CalVerトレイン	2025.01〜2026.06	最新リリースのみサポート、旧バージョンは即座にサポート終了

そして本稿執筆時点で、CalVerラインにはLTSが一つも存在しません。サポート対象バージョン文書にもendoflife.dateにも、2025.xや2026.xにLTS表記はどこにもありません。その結果、自己運用(self-managed)環境の選択肢はちょうど2つです。

5.26 LTSに留まる — 2028年6月までホットフィックスを受け取れる。代わりに、それ以降に出たすべて(Cypher 25、VECTOR型、新しいGQL構文、ABACなど)が使えない。
トレインに乗る — 新機能とバグ修正を毎月受け取れる。代わりに、毎月アップグレードしなければサポート対象外のバージョンを走らせることになる。

「年1回のメジャーアップグレード」という慣行を持つ組織にとって、第三の選択肢が存在しないことこそがこのモデルの核心であり、最も議論を呼ぶ部分です。

乗る際のコストも具体的に書いておきます。5.26 → 2025.xアップグレードガイドによれば、2025.01からJava 21が必須になり(Java 17サポート終了、Java 25は2025.10からサポート)、クラスターディスカバリーサービスv1が廃止されるためアップグレード前にv2への移行を済ませる必要があり、Kafka・Sparkコネクタと GraphQLライブラリも互換パッチバージョン以上に上げる必要があります。

ストレージ — ブロックフォーマットがデフォルトになったあと、recordは静かに退場する

CalVer移行の足元には、ストレージフォーマットの世代交代があります。公式のストアフォーマット文書によると、現状は次の通りです。

block — Enterprise Editionの推奨フォーマットであり、特に設定しなければデフォルト。プロパティをノード・リレーションシップと同じブロックにインライン保存し、ポインタ追跡を減らし、数ページでクエリを賄えるデータ局所性を設計目標としています。高密度ノードは多根世代型B+木ベースのdense storeへあふれます。
aligned — Community Editionのデフォルトフォーマット。ブロックフォーマットはCEには存在しません。
standard, high_limit — 5.23で非推奨(deprecated)化。新規データベースには使うなと明記されています。

アップグレードガイドは5.26 LTSユーザーに対し、2025.xへ上がる前にブロックフォーマットのマイグレーションを先に終えるよう強く推奨しています。マイグレーションには一つ制約があり、ブロックフォーマットのトークン名(ラベル・プロパティキー・リレーションシップタイプ)はGQL識別子の最大長である16,383文字までしか許容されません — ストレージフォーマットの仕様にISO標準の痕跡が刻まれている最初の地点です。

方向性はチェンジログの方がより鮮明です。2025.10のチェンジログはVECTORを「Cypher、ブロックストアフォーマット、v6ドライバーがサポートする新しい型」として紹介しています — 新しい型システムがブロックフォーマットを前提に育っているわけです。反対側では、レガシーなrecordフォーマットは2026年に入ると訂正項目としてしか登場しません。2026チェンジログでは、2026.04が「recordフォーマットでノードが同時にdenseへ遷移するとき、リレーションシップの走査が誤った結果を返しうるバグ」を、2026.06が「recordフォーマットで複数のリレーションシップタイプの無方向スキャンが兄弟関係を取りこぼし、出力が約50%少なく数えられるバグ」を修正しています。誤った結果を返すレベルのバグが今ごろになって見つかるということは、テストと投資の重心がどこへ移ったかを物語っています。まだrecordフォーマットの上に座っているなら、この2件はマイグレーション稟議の根拠段落になるはずです。

言語 — Cypherにバージョンが付く

2025.06(2025年7月GA)は、この時代でもっとも概念的な変化を含んでいました。クエリ言語そのものにバージョンが生まれたのです。Cypherバージョン選択の文書がルールを正確に書いています。

Cypher 5は凍結されています。 CYPHER 5で実行すると「2025.06リリース時点で存在していたCypher 5」として動作し、以後の言語変更はそのクエリに影響しません。
Cypher 25は動き続けます。 CYPHER 25で実行すると、現在動いているNeo4jバージョンのCypher 25として動作します。つまりCypher 25は毎月のリリースとともに成長する言語です。

CYPHER 25
MATCH (n:Order)-[r:SHIPPED_TO]->(:Address)
SET n = properties(r)

バージョンはクエリの接頭辞だけでなく、データベース単位のデフォルト(db.query.default_language)としても設定でき、プロシージャ・関数(APOCを含む)も言語バージョンに紐づきます — 同じAPOC配布物の中でも、Cypher 5では見えるプロシージャがCypher 25では削除されている場合があります。そして2026.02のチェンジログによれば、新規の自己運用インストールのデフォルト言語がCYPHER_25に変わりました。新規インストールでは今やCypher 25がデフォルトです。

Rustのエディションや C++の標準スイッチを知っている人には見慣れた図式でしょう。古いクエリを壊さずに言語を標準側へ押し進めるには、この仕組みが必要です。ただ、ここには非対称性が一つ隠れています — Cypher 25は2025.06以降のバージョンにしか存在しないため、5.26 LTSに留まるチームはCypher 25も、その上に乗るGQL構文も使えません。 言語の未来とサポートの安定のあいだで一つを選ばざるを得ない構造が、現在の実際の姿です。

GQL — 標準文書からチェンジログへ着地する方法

ISO/IEC 39075:2024、すなわちGQLは2024年4月に出版された610ページの国際標準です(現在のISO段階は90.92、改訂検討中)。SQL以来ISOが作った初のデータベース言語標準という象徴性は十分に消費されてきたので、ここでは実際の着地だけを見ます。標準はどのように稼働中のエンジンへ入ってくるのか。

Neo4jのやり方は「ビッグバン移行」ではなく、毎月少しずつCypher 25にGQL構文を植えていくことです。チェンジログを時系列に並べると軌跡が見えます。

2025.06 — FILTER節(中間フィルタリング)、LET節(中間変数の投影)、クエリの線形結合用NEXTキーワード、波括弧で囲んだクエリブロック。すべて「GQL conformant」と明記。Cypher Shellのデフォルトエラーフォーマットも GQLSTATUSベースのgqlに変更。
2026.02 — ceiling、local_time、zoned_datetime、collect_list、percentile_disc、stdev_popといったGQL互換の関数エイリアスを一括追加(既存実装へリダイレクトするだけで動作変化なし)。
2026.04 — UNWINDのGQL代替であるFOR .. IN節、ラベル検査述語IS LABELED。
2026.05 — GPM最短経路(ANY SHORTEST、SHORTEST kなど)にACYCLICのような明示的なパスモードのサポート。
2026.07(執筆時点で未リリース、チェンジログには掲載済み) — WITH・RETURNのGROUP BYサブ節(「Cypherを GQL標準へさらに整合させるために導入」と明記)、GQL機能GF12に相当するcardinality()関数。

これを「Neo4jはGQLをサポートしている」とまとめてしまうと誇張になります。正確な状態はNeo4j自身が文書化しています。GQL準拠付録は標準24.2節に基づく最小準拠(minimum conformance)の宣言であり、サポート項目の脇には脚注が付いています — たとえばGQLのFLOAT・INTEGERには精度の選択肢がありますが、CypherのFLOATは常に64ビットdouble、INTEGERは常に64ビットです。そして同じ付録にはまだ未サポートの必須(mandatory)機能一覧がそのまま残っています — GQLのセッション管理コマンド(SESSION SETなど)、トランザクションコマンド(START TRANSACTION、COMMIT、ROLLBACK — Neo4jではドライバーAPIがその役割を担う)、CURRENT_GRAPHのようなグラフ表現、スキーマ選択のAT節、そして予約語一覧の不一致まで。

エンジンの地形全体に広げても結論は似ています。Google Spanner Graphは自社文書の表現で「ISO GQL互換(compatible)のグラフクエリインターフェース」を提供するとし、MemgraphとFalkorDBのドキュメントは依然としてCypherを前面に出しています。まとめると — GQLは標準としては実在しますが、2026年半ば時点で「GQLで書けばどこでも動く」という移植性は存在しません。 標準の必須機能ですら代表的な実装にすべて入っているわけではなく、各ベンダーの表現(「conformant」「compatible」)は互いに異なるものを意味しています。GQLを理由にエンジンを選ぶ判断はまだ早く、今のGQLがもたらす実益は「新しく学ぶ構文が標準の方向と一致している」程度と見るのが正直なところです。

実行エンジン — パラレルランタイムと、デッドロックを予防するスケジューラ

クエリ実行の側も同じ期間ずっと動いていました。前提知識を一つ — Neo4jのパラレルランタイムはEnterprise専用で、読み取りクエリのみをサポートします。パイプラインをmorsel単位のタスクに切り分け、ワーカースレッドたちが分担する構造ですが、スケジューリングが中央キューではなくワーカーごとの分散スケジューラである点が特徴です。2026.05では、入力カーディナリティが1のとき可変長パターンをRepeat演算子で計画していたヒューリスティックがデフォルト無効化に変わりました — パラレルランタイムを使っているなら、実行計画が静かに変わっている可能性がある箇所です(クエリオプションで元に戻せます)。

書き込み側で目立つのは、2026.05〜2026.06にかけて入ったトランザクションバッチスケジューリングです。CALLサブクエリをIN CONCURRENT TRANSACTIONSで並列実行するとき(大量インポートの定番パターン)、これまではデッドロックが起きたら検知してリトライという方式でしたが、2026.06の新しいCypher 25構文DISJOINT BYはデッドロックを予防する方向でアプローチします。ロックがかかるリソースを識別する式を基準に行をバッチへ分け、リソースを共有するバッチは逐次に、共有しないバッチだけを同時に実行します。

DISJOINT BY (expr, ...)   -- ロック対象リソースを識別する式を直接宣言する
DISJOINT BY AUTO          -- サブクエリの静的解析からロック式を推論する
DISJOINT BY NONE          -- バッチスケジューリングを明示的に無効化する

チェンジログの限界の記述もそのまま移しておきます — AUTOの静的解析は、ユニーク制約とインデックスに支えられたMERGEのような一般的なパターンしかカバーせず、推論に失敗すると何の制約もなしに実行され、同じ外側クエリから生まれたバッチ間のデッドロックしか防がず、別々の同時実行クエリ間のデッドロックは防ぎません。 リレーションシップの大量作成でデッドロックのリトライループに痛い目にあったことがあるなら試す価値があり、そうでないならまだデフォルト(無効)が答えです。

トレイン上の暮らしがどんなものかを示す項目も同じチェンジログにあります。2026.02.1は「ON MATCH式がマージ中の変数に依存するときのMERGEの潜在的なデータ損失」を修正し、2026.02.3はpipelinedランタイムのEXISTSサブクエリのバグを修正しつつ「最悪の場合、誤ったデータが書き込まれた理論的リスクがあるが、実際の発生は確認されていない」と記しています。毎月のリリースは、こうした修正が早く届くことも意味しますし、修正が必要なリグレッションがそれだけ頻繁に発生することも意味します。トレインに乗るなら、パッチノートを読むことが月次の運用業務に組み込まれている必要があります。

水平スケーリング — Infinigraphのプロパティシャーディング、ただし別サブスクリプション

チェンジログのあちこちに登場する「sharded property database」は、Infinigraphという名の分散アーキテクチャです。構造が興味深く、グラフをまるごとパーティショニングするのではなく、構造とプロパティを分離します。ノード・リレーションシップの構造は単一の「グラフシャード」にそのまま置き、プロパティだけをハッシュ関数で複数の「プロパティシャード」に均等に分散します。クエリのセマンティクスとACID保証は維持されるというのが文書の主張であり、グラフの走査が構造シャード内で完結するため、分散結合地獄を避ける設計です。

裏を返せば限界も明確です — 構造自体は依然として一つのシャードに収まる必要があるため、これは「プロパティが重いグラフ」向けの拡張であって、「構造が一台のマシンを超えるグラフ」向けではありません。そして決定的に、文書に明記されている通り、標準のEnterprise Editionには含まれない別売りのInfinigraphサブスクリプション商品です(営業への問い合わせが必要)。エンジン開発自体は公開チェンジログでも継続して見られます — 2026.07のチェンジログ(未リリース)には、シャーディングされたデプロイ向けのバッチインデックスシーク演算子(RemoteNodeIndexSeek)が載っています。機能の存在と機能へのアクセスは別問題だ、というのがこの節の事実関係です。

どのトラックに立つか — 判断基準

まとめると、こう分かれます。

5.26 LTSに留まる場合

アップグレードの窓口が四半期・半期単位で決まっており、サポート契約が重要な運用環境である。2028年6月までホットフィックスが出る(5.26.28が2026年6月30日にも出ています)。
ただし、ブロックフォーマットのマイグレーションは今のうちにやっておいた方がいい — どのみち5.26のデフォルトであり、あとでCalVerへ移るときの前提条件のように推奨されている。
Cypher 25、VECTOR型、新しいGQL構文、ABACなしで暮らすことを受け入れる。

CalVerトレインに乗る場合

毎月(最低でも隔月)のアップグレードを自動化できるパイプラインと、パッチノートを読む運用習慣がある。
Cypher 25の新構文やベクター機能が実際の要件である。
サポート対象バージョンは常に「最新の一つだけ」という事実を組織が理解している。

Community Editionなら — ブロックフォーマットもパラレルランタイムも存在しない(alignedフォーマット、シングルスレッドランタイム)別の製品を使っていると考えるのが正確です。エンジン視点での今世代の改善の大半はEE側に落ちました。

GQLの移植性を狙っているなら — まだ契約ではなく方向性です。標準の必須機能の未サポート一覧が代表的な実装のドキュメントに残っているあいだは、GQLは「いつか乗り換えられるよう標準方向の構文を学んでおく」以上のことを保証しません。

組み込み型グラフエンジンを探していたなら — この地形は昨秋に大きく揺れました。組み込みの代表格だったKùzuはリポジトリが2025年10月10日付でアーカイブされ(最終リリースv0.11.3、リポジトリ)、コミュニティフォークへ引き継がれつつあります。選択肢の整理は道具編ですでに扱ったので、そちらを参照してください。

おわりに

CalVer移行後1年半のNeo4jを一文で縮めるとこうなります — エンジンはブロックフォーマットの上で毎月成長し、言語はGQLへ向けてバージョン単位で移動中であり、その速度の代償は「サポート対象バージョンは常に最新の一つだけ」という運用モデルが払っている。標準(GQL)は出版されましたが移植性はまだ来ておらず、LTSを望むチームと新機能を望むチームは、今やほぼ別のメジャーバージョンを使っているのと変わらない距離に立っています。

グラフをRAGの材料としてしか使わない立場であれば、この記事の大部分は当面無関係です — マネージドサービスや組み込みストアの裏に隠れた層だからです。しかし、グラフDBを自分で運用しているか、今まさにエンジンを選んでいるか、あるいは「GQL標準サポート」というマーケティング文言を評価しなければならない立場なら、判断材料はベンダーのスライドではなく、上にリンクしたチェンジログと準拠文書にあります。標準がエンジンへ着地する過程は華やかではありません。毎月、節を一つずつ、関数エイリアスを一束ずつ — それが実際の姿です。