# Neo4jの機能と実践的な使い方 🚪 データ投入の方法選びを最初に間違えると、後工程がすべて遅くなります。Neo4jの「インポート方法 選択ガイド」は、規模と頻度から最適な入口を決めるためのハブページです。 🏷️ タイトル: インポート方法の選択ガイド 🔗 URL: 📘 概要 Neo4jへのデータ投入には複数の手段があり、それぞれ得意な規模・実行モード（オンライン/オフライン）・権限要件が異なります。このページは個別の手順書ではなく、「どの方法を選ぶべきか」を最初に判断するための入口にあたります。 ⚙️ 機能の説明 主な選択肢は次のとおりです。 ・Data Importer: ブラウザGUIでCSVをドラッグ＆ドロップし、ノード/リレーションシップに視覚的にマッピング。Cypher不要で、検証・プロトタイピング向き。 ・`LOAD CSV`: Cypherで書く汎用的な取り込み。オンライン（DB稼働中）で動き、非管理者でも実行可能。数十万〜数百万行クラスまで。 ・`neo4j-admin database import`: オフラインのバルクローダ。空のDBに対し、ストアファイルへ直接書き込むため最速。数十億規模の初期構築向け。 ・コネクタ/APOC: Apache Spark / Kafka / CDC による継続的同期や、JSON/XML/XLSなど多様な形式の取り込み。 🛠️ 実践的な使い方 規模と頻度で入口を決めるのが実践の第一歩です。 ・数千件のマスタを手早く → Data Importer（GUI） ・数百万件の定期ロード/差分ロード → `LOAD CSV`（`MERGE`で冪等化） ・数十億件のワンショット初期構築 → `neo4j-admin database import`（オフライン） ・常時の継続同期 → Kafka / CDC / Spark コネクタ いずれの経路でも、取り込み前にキー列へ一意制約を張るのが共通の定石です。 ```cypher CREATE CONSTRAINT person_id IF NOT EXISTS FOR (p:Person) REQUIRE IS UNIQUE; ``` 💡 ユースケース プロジェクト初期に、PoCはData Importer、本番初期構築は`neo4j-admin import`、日次差分は`LOAD CSV`、というように経路を分けて設計します。これにより「検証は軽く速く、本番投入は最速」を両立できます。 ⚠️ 注意点 ・`neo4j-admin import`は空のDB専用かつオフラインのため、稼働中DBには使えません。 ・`LOAD CSV`は行数が数十万〜数百万に近づくとメモリ問題が出やすく、`CALL { } IN TRANSACTIONS`での分割が必要です。 ・継続同期（Kafka/CDC）は初期ロードとは別物として、組み合わせて設計します。 ・このページは入口です。各方式の細部は必ずリンク先の個別ドキュメントで確認してください。 #Neo4j# #DataImport#

# Neo4jの機能と実践的な使い方 🔒 インポート前に一意制約を1本張る——たったそれだけで、MERGEの重複防止と高速ルックアップを同時に手に入れられます。公式もインポートの前提手順として明記しています。 🏷️ タイトル: Uniqueness / Property existence / Node key constraints 🔗 URL: 📘 概要 制約は、ノードやリレーションシップが満たすべきルールをDBレイヤで強制する仕組みです。キーの一意性や必須プロパティを保証し、複数パイプラインからの書き込みでもエンティティの整合性を守ります。一意制約は裏で range インデックスを生成し、ルックアップも速くします。 ⚙️ 機能の説明 ・プロパティ一意制約: ラベル/型ごとにプロパティ値(または組み合わせ)の一意を保証します。Community Editionでも利用可能で、裏側の range インデックスがMERGEやインポートを最適化します。 ・プロパティ存在制約: 指定プロパティが必ず存在することを保証します(Enterprise限定)。 ・プロパティ型制約: プロパティが指定の型であることを保証し、スキーマのドリフトを防ぎます(Enterprise限定)。 ・キー制約(Node key / Relationship key): 一意性と存在を兼ね備え、複合主キーに相当します(Enterprise限定)。 🛠️ 実践的な使い方 インポート前に必ず作成する一意制約です。 ```cypher CREATE CONSTRAINT person_id IF NOT EXISTS FOR (p:Person) REQUIRE IS UNIQUE; ``` ノードキー(複合キー)と存在制約の例です。 ```cypher CREATE CONSTRAINT order_key IF NOT EXISTS FOR (o:Order) REQUIRE (o.tenantId, o.orderId) IS NODE KEY; CREATE CONSTRAINT user_email_exists IF NOT EXISTS FOR (u:User) REQUIRE IS NOT NULL; ``` 確認・削除は次の通りです。 ```cypher SHOW CONSTRAINTS; DROP CONSTRAINT person_id IF EXISTS; ``` 💡 ユースケース ・大量インポート前に一意制約を張り、MERGEの重複防止と高速化を同時に得る。 ・マスタ系ノードのキー整合性をDBで強制し、複数パイプライン書き込みでも二重化を防ぐ。 ⚠️ 注意点 ・一意制約以外(存在・型・キー)はEnterprise Edition限定です。Communityでは一意制約のみ使えます。 ・既にデータに違反がある状態で制約を作成すると失敗します。先にデータをクレンジングします。 ・バルクインポートは有効な制約に対して検証され、違反があると失敗し得ます。 ・より高度な制約や一元管理が必要なら、graph type によるスキーマ定義が推奨されています。 #Neo4j# #Cypher#

# Neo4jの機能と実践的な使い方 ⚡ 「グラフDBでもインデックス設計が性能の8割」。MATCHの起点となるプロパティに正しい索引を張るだけで、検索が O(n) から O(log n) に変わります。 🏷️ タイトル: Range / Text / Point / Composite index 🔗 URL: 📘 概要 インデックスはノード・リレーションシップ・プロパティの複製で、主データへの高速なアクセス経路を提供します。作成後はDBMSが自動でメンテナンスします。MATCHのアンカー(起点)探索を高速化し、クエリプランナが述語に応じて自動選択します。 ⚙️ 機能の説明 ・Range(既定): 等価・範囲比較・`IN`・`STARTS WITH` など最も多くの述語を解決します。まず張るべき索引です。 ・Text: `STRING` 専用で、`CONTAINS` と `ENDS WITH` を最適化します。部分一致の画面検索向きです。 ・Point: 空間 `POINT` 値専用で、距離検索やバウンディングボックス内検索を最適化します。 ・Composite: 複数プロパティをまとめて索引化し、複数条件の絞り込みを一度に解決します。 ・Token lookup: ラベル/リレーションシップ型の探索を高速化する基盤索引です。 ・このほか全文検索インデックスとベクトルインデックス(類似検索/GenAI向け)があります。 🛠️ 実践的な使い方 起点プロパティへの range / composite / text / point インデックスの作成例です。 ```cypher CREATE INDEX user_email IF NOT EXISTS FOR (u:User) ON ( CREATE INDEX order_composite IF NOT EXISTS FOR (o:Order) ON (o.customerId, o.status); CREATE TEXT INDEX product_name_text IF NOT EXISTS FOR (p:Product) ON ( CREATE POINT INDEX store_loc IF NOT EXISTS FOR (s:Store) ON (s.location); ``` 確認・削除は次の通りです。 ```cypher SHOW INDEXES; DROP INDEX user_email IF EXISTS; ``` 💡 ユースケース ・` を MATCH の起点にするアプリで、ルックアップを O(log n) 化。 ・`STARTS WITH` は range、`CONTAINS`/`ENDS WITH` は text、地理検索は point を選ぶ画面検索。 ⚠️ 注意点 ・どの索引が効くかは述語次第です。`CONTAINS` は range では効かず text が必要、という対応関係を意識します。 ・索引は書き込みコストとストレージを増やします。実際に使われるか `PROFILE` で確認してから運用に乗せます。 ・複合インデックスは先頭プロパティから順に効くため、列の順序が性能を左右します。 #Neo4j# #Cypher#

# Neo4jの機能と実践的な使い方 ♻️ 「なければ作る、あれば更新する」——イベントストリームを何度流しても重複ノードを生まない冪等な書き込みは、`MERGE` 一文で実現できます。 🏷️ タイトル: CREATE / MERGE / SET / DELETE 🔗 URL: 📘 概要 `MERGE` は、パターンが存在すればマッチして束縛し、なければ作成して束縛する upsert クラウズです。`MATCH` と `CREATE` を一体化し、過去にデータが在ったかどうかで条件分岐できます。日次バッチやストリーム取り込みの冪等化に不可欠です。 ⚙️ 機能の説明 ・全体一致か全体作成か: `MERGE` はパターン全体に対して「すべてマッチ」か「すべて作成」のどちらかで、既存パターンを部分的に再利用しません。部分的に扱いたい場合は `MERGE` を複数に分解します。 ・`ON CREATE SET` / `ON MATCH SET`: 作成時だけ・マッチ時だけ実行されるプロパティ設定です。作成時刻の刻印やアクセス回数のインクリメントに使えます。両方を同時に書けます。 ・リレーションシップの `MERGE`: 少なくとも片方のノードが束縛済みである必要があります。無向 `-[r:KNOWS]-` は双方向で探してから左→右で作成します。 ・制約との連動: 一意制約があると `MERGE` は競合検知を行い、重複生成を防ぎます。性能上もラベル/プロパティへのインデックス作成が強く推奨されます(無いと毎回フルスキャン)。 🛠️ 実践的な使い方 イベントストリームの冪等な upsert 例です。 ```cypher MERGE (u:User {id: row.userId}) MERGE (p:Page {url: row.url}) MERGE (u)-[v:VIEWED]->(p) ON CREATE SET v.count = 1 ON MATCH SET v.count = v.count + 1 ``` 派生ノードを重複なく作る定番パターンです。 ```cypher MATCH (person:Person) MERGE (loc:Location {name: person.bornIn}) MERGE (person)-[r:BORN_IN]->(loc) ON CREATE SET r.createdAt = timestamp() ``` 💡 ユースケース ・クリックストリーム/IoTイベントの取り込みで、同一ユーザー・ページを一意化しながらカウントを積み上げる。 ・複数パイプラインからマスタを書き込んでもエンティティが二重化しない取り込み基盤。 ⚠️ 注意点 ・`MERGE` のキーには一意制約を併用するのが鉄則です。制約が無いと並行実行で一瞬の重複が生じ得ます(制約は最終的整合のみ保証)。 ・`MERGE` のプロパティに `null` は使えません。条件付き設定は後段の `SET` で行います。 ・同一 `MERGE` 内で作成中ノードの値を相互参照できません。先に `MATCH` するか `SET` に分けます。 ・`DELETE` はリレーションシップ付きノードに失敗します。`DETACH DELETE` を使います。 #Neo4j# #Cypher#

# Neo4jの機能と実践的な使い方 🕸️ 「このサーバーが落ちたら、何が連鎖して止まるのか?」——その答えは、関係を何ホップでも辿れるCypherの可変長パターンが教えてくれます。 🏷️ タイトル: 可変長パターン(`*1..5`)/ SHORTEST / Quantified Path Patterns 🔗 URL: 📘 概要 可変長パターンは、ホップ数が固定でない経路をひとつのパターンで表現するCypherの機能です。「最大5段まで遡る」「最短経路を1本だけ取る」といった、グラフならではの問いをそのまま宣言的に書けます。最短経路探索やQuantified Path Patterns(QPP)もこの仲間です。 ⚙️ 機能の説明 ・量化リレーションシップ(従来構文): `[:REL*1..5]` は1〜5回の繰り返しを表します。`*2` はちょうど2回、`*3..` は3回以上、`*..10` は10回以下、`+` は1回以上、`*` は0回以上を意味します。 ・Quantified Path Patterns(QPP): `((a)-[r:NEXT]->(b)){1,3}` のようにパターン全体を括弧で囲んで繰り返します。GQL準拠で、内部にWHEREのインライン述語を書けるのが強みです。 ・グループ変数: QPP内で宣言した変数は、外側から参照するとマッチした要素のリストになります(例: `r` がリレーションシップの配列)。`reduce()` などと組み合わせて経路上の合計距離を計算できます。 ・最短経路: `SHORTEST k` で最短をk本、`ALL SHORTEST` で同率最短をすべて、`ANY` で任意の1本を取得します。旧来の `shortestPath()` / `allShortestPaths()` 関数も使えますが、キーワード構文の方が高速です。 🛠️ 実践的な使い方 サプライチェーンで供給元を最大5段まで遡る例です。 ```cypher MATCH (p:Part {sku: $sku})-[:SUPPLIED_BY*1..5]->(supplier:Company) RETURN DISTINCT ``` 2人を最短で繋ぐ紹介経路(最短1本)です。 ```cypher MATCH path = SHORTEST 1 (a:Person {id:$a})-[:KNOWS]-+(b:Person {id:$b}) RETURN [n IN nodes(path) | AS intro_chain ``` 💡 ユースケース ・障害影響分析:あるサーバー障害が何ホップ先まで波及するか。 ・マネーロンダリング検知:口座間の資金移動経路の追跡。 ・組織図・SNS:上司の上司、友達の友達の最短到達経路。 ⚠️ 注意点 ・上限のない `*` や `[:REL*]` はパス爆発を招き、数百万件のマッチで実行が止まりかねません。必ず上界(`*1..5` など)を付けます。 ・ラベル・リレーションシップ型・インライン述語で探索範囲を早期に枝刈りすると劇的に速くなります。QPPはこの枝刈りに向いています。 ・Cypherは既定で同一リレーションシップの再走査を許しません。必要に応じて挙動が変わる点に注意してください。 #Neo4j# #Cypher#

# Neo4jの機能と実践的な使い方 🕸️ 「上司の上司」も「友達の友達でまだ友達でない人」も、MATCHのパターン1つで言い表せます。 🏷️ タイトル: MATCH / OPTIONAL MATCH / WHERE 🔗 URL: 📘 概要 MATCHはCypherの中核で、グラフ内から特定のパターンを検索する句です。ノード・リレーションシップ・プロパティのパターンを宣言し、WHEREで絞り込み、OPTIONAL MATCHでLEFT JOIN相当の「あれば取得」を表現します。グラフ検索の大半はこの3つの組み合わせで成立します。 ⚙️ 機能の説明 ・ノードマッチ: `MATCH (m:Movie) RETURN m.title`。ラベルなし`(n)`は全ノード ・ラベル式: OR は `(n:Movie|Person)`、否定は `(n:!Movie)` ・リレーションシップ: 方向は`-->`/`<--`、無向は`--`で両方向にマッチ ・型式: `-[:ACTED_IN|DIRECTED]-` で複数型をOR(1本に複数型は付かないので`:A&B`は決して一致しない) ・可変長: `-[:REPORTS_TO*2]->` のように複数ホップをたどる ・WHERE: パターン後の絞り込み。`NOT EXISTS { ... }` でパターンの否定も可能 ・OPTIONAL MATCH: 一致がなければ変数をnullにして続行(LEFT JOIN相当) 複数のMATCHは順次評価されます。変数で結合されないと意図しない直積(Cartesian product)になるため、`WITH`で変数の受け渡しを制御します。 🛠️ 実践的な使い方 組織図で「上司の上司」を可変長でたどります。 ```cypher MATCH (e:Employee {name: $n})-[:REPORTS_TO*2]->(boss) RETURN ``` SNSで「友達の友達でまだ友達でない人」を否定パターンで表します。 ```cypher MATCH (me:Person {id: $id})-[:FRIEND]-(f)-[:FRIEND]-(fof) WHERE me <> fof AND NOT (me)-[:FRIEND]-(fof) RETURN DISTINCT ``` プロフィール画面で「注文があれば注文も返す」。 ```cypher MATCH (u:User {id: $id}) OPTIONAL MATCH (u)-[:ORDERED]->(o:Order) RETURN collect( AS orders ``` 💡 ユースケース 組織階層のたどり、SNSの友達推薦(FoF)、プロフィールAPIでの任意関連の同梱取得など、関係の有無や多段の到達可能性を問う画面・分析に直結します。 ⚠️ 注意点 ・変数で結ばれない複数MATCHは直積になり、件数が爆発します。`WITH`やWHEREで必ず結びます。 ・可変長(`*`)は上限なしだと巨大グラフで重くなります。`*1..5`のように上限を付けます。 ・パラメータ・ラベル動的指定(`$(labels)`)はバージョンによりインデックス活用が限定されます。性能要件があれば確認しましょう。 #Neo4j# #Cypher#

# Neo4jの機能と実践的な使い方 🔍 SQLで5段JOINになる問い合わせが、矢印の絵1行で書ける——Cypherはグラフのための宣言型クエリ言語です。 🏷️ タイトル: Cypher(宣言型グラフクエリ言語) 🔗 URL: 📘 概要 CypherはNeo4jのために設計された宣言型のグラフクエリ言語です。「どう取得するか」ではなく「どんなデータが欲しいか」を、アスキーアート的なパターンで表現します。アプリ・分析・運用すべてに共通する、グラフの共通言語です。 ⚙️ 機能の説明 Cypherの核はパターンマッチングです。 ・ノードは丸括弧 `(node)` で表す ・リレーションシップは角括弧と矢印 `-[rel]->` で表し、方向を矢印で示す ・ラベルや型、プロパティをパターン内に直接書ける(`(:User {id: $id})`) 主要な句は次の通りです。 ・`MATCH`: グラフ内のパターンを検索する ・`RETURN`: 返す結果を射影する ・`WHERE`: 条件で絞り込む ・`CREATE` / `MERGE`: 作成 / なければ作成あれば一致 ・`WITH`: 複数ステップのパイプラインを組む CypherはGQL(ISOのグラフクエリ言語標準)に準拠しつつNeo4j拡張を持ちます。Neo4j 2025.06以降、新機能はCypher 25に追加され、Cypher 5は凍結されています。 🛠️ 実践的な使い方 SQLで複数JOINになる問い合わせが、1つのパターンで書けます。 ```cypher MATCH (c:Customer {id: $id})-[:ORDERED]->(o:Order)-[:CONTAINS]->(p:Product) RETURN count(*) AS times ORDER BY times DESC ``` クエリには必ずパラメータ(`$id`)を使います。インジェクション防止と実行計画キャッシュの両方に効きます。 💡 ユースケース 顧客の購買履歴集計、レコメンド、不正検知の経路追跡、組織図のたどり方など、つながりを問う業務すべての基盤になります。可読性が高く、SQLより少ない行数で複雑なトラバーサルを表現できます。 ⚠️ 注意点 ・文字列連結でクエリを組み立てず、必ずパラメータ化します。 ・バージョン差に注意します。新機能はCypher 25中心で、Cypher 5は凍結済みです。互換性を確認しましょう。 ・宣言型ゆえ、書き方次第で実行計画が大きく変わります。重いクエリはPROFILE/EXPLAINで確認します。 #Neo4j# #Cypher#

# Neo4jの機能と実践的な使い方 🎨 ホワイトボードに描いた業務の絵が、ほぼそのままデータベースのスキーマになる——それがグラフモデリングの醍醐味です。 🏷️ タイトル: グラフモデリング手法(ホワイトボードモデル → 物理モデル) 🔗 URL: 📘 概要 グラフデータモデリングは、業務ドメインの「絵」を段階的に物理グラフモデルへ落とし込む手法です。Neo4jの公式ガイドは、概念モデル → 実装 → リファクタリングという流れと、RDBモデルからの移行、性能を高める設計の選択肢を体系的に示します。設計レビューで毎回問題になる論点に答えを与えます。 ⚙️ 機能の説明 モデリングは大きく次の段階で進みます。 ・概念設計: ドメインの実体を洗い出し、ノードと、それらをつなぐリレーションシップ(動詞)を決める ・実装: ホワイトボードの絵をそのままノード・ラベル・型・プロパティに対応づける ・リファクタリング: クエリパターンに合わせて反復的にモデルを改善する 最大の判断ポイントは、イベントを「中間ノードとして具象化(reify)」するか「直接エッジ」にするかです。 ・直接エッジ(`(:User)-[:ORDERED]->(:Product)`): 関係が単純で属性が少ないとき ・中間ノード(`(:User)-[:PLACED]->(:Order)-[:CONTAINS]->(:Product)`): 1つのイベントに複数の参加者・明細・状態・時刻が絡むとき 命名は「ラベル=単数の名詞」「リレーションシップ型=大文字スネークの動詞」を基本にします。 🛠️ 実践的な使い方 注文に「数量」「価格」「ステータス」が必要なら、関係ではなく中間ノードに具象化します。 ```cypher CREATE (u:User {id: 'u1'})-[:PLACED]->(o:Order {id: 'o1', status: 'shipped', at: datetime()}) CREATE (o)-[li:CONTAINS {qty: 2, price: 9.99}]->(p:Product {sku: 'sku1'}) ``` 不正検知では「口座・デバイス・電話番号・住所」をノード化し、共有関係をエッジで張ります。 ```cypher MATCH (a1:Account)-[:USED]->(d:Device)<-[:USED]-(a2:Account) WHERE a1 <> a2 RETURN a1, a2, d ``` 💡 ユースケース 不正検知で共有デバイス・住所からリングを発見する、ECで注文を中間ノード化して明細・配送・返品まで追う、といった「業務の絵=スキーマ」の設計に直結します。 ⚠️ 注意点 ・「すべてを中間ノードに」も「すべてを直接エッジに」も極端です。クエリパターン(どう辿るか)から逆算して決めます。 ・後から大量データのリファクタリングは高コストです。主要クエリを先に想定してモデルを固めましょう。 ・RDBの正規化の癖でテーブル相当のノードを作りすぎると、トラバーサルが冗長になります。 #Neo4j# #DataModeling#

📄 ドキュメントをアップロードするだけでナレッジグラフが構築できる時代へ。Neo4jの新機能「Document Intelligence」がAuraに登場！ タイトル: Introducing Document Intelligence: From documents to a knowledge graph, right inside Aura URL: 📦 概要 Neo4jのフルマネージドグラフDB「Aura」に、非構造化ドキュメントからナレッジグラフを直接構築する「Document Intelligence」機能が追加されました。PDF、契約書、技術文書などをアップロードするだけで、エンティティ抽出、名寄せ、グラフ構築までをプラットフォーム内で完結できます。 ❓ 解決する課題 企業データの大部分は非構造化ドキュメントに眠っていますが、そこからナレッジグラフを構築するには、LLMによるエンティティ抽出、エンティティ解決、グラフスキーマ設計といった複雑なパイプライン構築が必要でした。この技術的なハードルが、ナレッジグラフ活用を一部の専門チームに限定していました。 💡 方法論と提案手法 LLMベースのエンティティ抽出で人物・組織・概念を自動識別し、異なるドキュメント間の同一エンティティを名寄せして統合。抽出された関係性からグラフスキーマを推論してAuraDB上にナレッジグラフを構築します。構築したグラフはそのままAura Agent、GenAI Copilot、GraphRAGの知識基盤として活用可能です。 🛠 ユースケース ・法務チームが大量の契約書から義務関係を抽出してコンプライアンスチェックを自動化 ・製薬企業が論文や臨床試験レポートから分子と疾患の関係を構造化して創薬研究を加速 ・ベクトル検索だけでは捉えきれない構造的関係性をグラフが補完し、RAGの回答精度を向上 #KnowledgeGraph# #Neo4j#

「強い力士」は勝ち星の数では測れません。グラフアルゴリズムを連鎖させて“真の支配力”を炙り出す分析が面白いです🥋 タイトル: SumoDB in Neo4j: Chaining Multiple Graph Algorithms in Snowflake — Part 3 URL: 🥋 概要 Neo4j Graph AnalyticsとSnowflake SQLを組み合わせ、大相撲データから「勝利数では見えない支配力」を測る記事です。複数のグラフアルゴリズムを連鎖させ、合成指標「Chaos Score」を構築します。 ❓ 解決する課題 勝ち星の数だけで強さを測ると、弱い相手に勝っただけの力士を過大評価してしまいます。どちらか一方のツールでは見えない競争構造を、Neo4jとSnowflakeの組み合わせで浮かび上がらせます。 💡 方法論と提案手法 「勝者→敗者」の重み付き有向エッジを作り、3つのアルゴリズムを連鎖させます。 ・PageRank：強い相手に勝つほど高評価し、勝利の質を測る ・媒介中心性：上位陣と中位陣をつなぐ橋渡し力士を特定 ・3サイクル検出：A→B→C→Aのような三すくみを可視化 減衰係数0.85、エッジ逆転で威信を勝者に向け、20反復で収束させます。 🌍 ユースケース ・才能評価：水増し勝利と本物の支配力を区別 ・構造分析：取り除くと階層が分断される重要人物を発見 ・競争バランス：三すくみの密度でエコシステムの健全さを測定 #GraphDataScience# #Neo4j#