10月7日、Futurum Groupのアナリスト Brad Shimminが「Solving the Agentic Context Dilemma: Inside Neo4j's Strategy to Build an Operational World Model」と題した記事を公開した。この記事では、Neo4jがグラフデータベースを「エンタープライズ・コンテキストエンジン」として再定位し、自律型AIエージェントのコンテキスト問題を解決する戦略について詳しく紹介されている。フラットなテーブルや断片化したベクトル検索では届かない「業務の文脈」をどう与えるか——その答えとして注目されるのが、Neo4jが提唱するLagom戦略と6層オントロジーアーキテクチャだ。
エージェントAIが直面する「第三の消費者問題」
エンタープライズAIが抱える根本的な問題は、モデルの能力不足ではない。コンテキストの供給不足だ。
企業のデータ資産は、数百のリレーショナルDB・カラム型ウェアハウス・オブジェクトストア・業務アプリに断片化して散在している。これらをバラバラのままLLMに食わせると、ハルシネーション・実行計画の破綻・業務上の盲点が生じる。
Neo4jのCEO Emil Eifremは、GraphSummit New Yorkでこの問題を「データ消費者の構造変化」として整理した。従来のデータベースが相手にしてきた消費者は2種類だった。
- 決定論的アプリケーション（CRUDを実行するトランザクション処理）
- 人間のアナリスト（BIダッシュボードを参照する人々）
自律型AIエージェントは、これらとは本質的に異なる第三の消費者だ。エージェントはデータ資産を能動的に探索し、多段階の実行計画を組み立て、外部ツールを呼び出し、業務レコードを書き換える。このような消費者に対して、フラットなリレーショナルテーブルや孤立したベクトル埋め込みは根本的に不向きである。
Neo4jの答え：6層オントロジーアーキテクチャ
Neo4jが提示する解決策の核心は、「Meaning（意味）」「Reach（到達）」「Learning（学習）」の3機能を束ねたコンテキストエンジンだ。
- Meaning：ビジネスオントロジーによる決定論的な意味基盤。「与信リスク計算」や「顧客チャーン評価」において、組織横断で統一されたエンティティ定義をエージェントに提供する。
- Reach：分散システムをまたいだ多段ホップ（マルチホップ）関係の探索。ベクトル検索が意味的に近いテキスト断片を拾うだけなのに対し、ネイティブグラフ探索は10ホップから100ホップ規模の明示的なエッジを辿り、GraphRAG（グラフ構造を活用した RAG＝Retrieval-Augmented Generation：外部知識を検索してLLMの回答精度を高める手法）パイプラインの精度とコンテキスト再現率を大幅に向上させる。
- Learning：エージェントの実行トレースを永続的な組織知識に昇華させる。成功した実行パスを「バージョン管理された手続きスキル」として蒸留し、MCP（Model Context Protocol）エンドポイント経由で再利用可能にする。
この3機能を実装するために、Neo4jは以下の6層オントロジー構造を定義している。
| レイヤー | 役割 |
|---|---|
| L1 ビジネスプロセス層 | ローン借換やAML調査などの業務ワークフローを宣言的にエンコード。エージェントが恣意的なプロンプトで次ステップを推測するのではなく、明示的なビジネスルールに従って動く |
| L2 ドメインセマンティクス層 | ビジネスエンティティ・分類・関係を業務言語で定義。エージェントの概念モデルとなる |
| L3 データ製品層 | 関連する技術資産をキュレーションされたビジネス向けデータ製品として集約 |
| L4 物理層（技術オントロジー） | スキーマ・テーブル・カラム・ネットワーク位置をカタログ化。Customer.firstName→F_NAME（レガシーDB）のような物理マッピングを管理 |
| L5 MCPツール層 | エージェントが外部環境でアクションを実行するためのガバナンス済みAPI・ツール定義・MCPエンドポイントを公開 |
| L6 実行トレース・メモリ層 | エージェントの実行ログ・ツール引数・推論パスを記録し、永続的な事実抽出と将来のワークフロー改善に活用 |
このアーキテクチャが意識しているのは、過去のセマンティック技術の失敗だ。RDF（Resource Description Framework）やOWL（Web Ontology Language）を基盤とするSemantic Webは、専門知識と複雑なツールチェーンの重さに潰れた。Neo4jはLabeled Property Graph（LPG）パターンで開発者の実用性を優先し、学術的純粋主義より運用パフォーマンスを取る。
ストレージ戦略：ゼロコピーVirtual Graphsとネイティブブロックストレージの使い分け
データをどこに置き、どう処理するかはアーキテクチャ上の核心的なジレンマだ。企業のガバナンスルール・データ重力・転送コストは、多くの場合でデータの移動を禁じる。
Neo4jはこれを3つのストレージパターンで対処する。
Virtual Graphs（ゼロコピー）は、Cypherクエリ（Neo4jのグラフ専用クエリ言語）をSnowflake・Databricks・BigQuery内で実行されるプッシュダウンSQLに変換する。データは元の場所に留まり、既存のRBAC（ロールベースアクセス制御）やETLパイプラインをそのまま活かせる。ある大手ゲーム会社はSnowflake上でこの仕組みを使い、複雑な多テーブルSQLジョインを手書きせずに自然言語でのビジネス分析を実現している。
ただし、ゼロコピー仮想化には明確なトレードオフがある。カラム型エンジンは数百万行のフラット集計は得意だが、数十エンティティにまたがる深い再帰的マルチホップジョインには著しいパフォーマンス劣化を起こす。不正取引チェーンの発見や取引先エクスポージャーの即時評価など、10ホップ以上のリアルタイムグラフ探索が必要な場面では、ネイティブグラフブロックストレージが不可欠だ。
Neo4jはインデックスフリー隣接（index-free adjacency）によって、ノードが隣接する関係への直接メモリポインタを保持する構造を採用しており、250ms未満のレイテンシでのグラフ探索を実現すると主張している。
実際の導入事例として、ある大手銀行はSemantic Webの複雑さを社内エンジニアに意識させることなくオントロジーベースのセマンティック層を展開。あるモーゲージ会社は顧客インタラクションログ・通話記録・ローンサービス記録・CRMファイルを単一のコンテキストストアに統合し、個別最適化されたリファイナンス提案の自動化を実現している。
「Lagom戦略」：MDM疲れを回避する段階的展開
記事でBrad Shimminが特に注意喚起しているのは、過去のMDM（マスターデータ管理）やSemantic Web失敗の轍を踏まないための現実主義だ。
Neo4jが提唱するのは「Lagom（ラーゴム）」戦略——スウェーデン語で「ちょうどよい」を意味する——で、単一の業務ワークフローから始めて必要なデータモデルを段階的に本番環境に引き込む、ユースケース主導の展開モデルだ。全社横断のデータ統合を一気に目指すのではなく、成功した小さなユースケースを積み重ねることで、過去のエンタープライズデータ統合プロジェクトが陥りがちな「完璧な設計のまま本番稼働しない」罠を回避する。
Shimmin自身はこのコメントを残している。
「業界はメタデータの野心の残骸に満ちている——カタログのカタログ、といった具合に。私のアドバイスは、たとえサイロ化・断片化していても、まず堅実なメタデータ資産を構築することだ。Neo4j自身のアドバイスにあるように、これによって全部か無かというアプローチを必要としない、実現可能なプロジェクトの探索が可能になる。」
競合との比較について記事は明示している。DatabricksのGenie Ontology、SnowflakeのCortex、AWSのContext Service、MicrosoftのFabric IQ Graphは、それぞれ自社ウェアハウスのメタデータ抽象化とアクセスガバナンスに主眼を置く。Neo4jはマルチクラウドおよびオンプレミスにまたがる独立したクロスプラットフォームの知識基盤として差別化を図る。ただし、この戦略の成否は実際の導入規模と企業側の採用意欲にかかっており、Shimminも「プディングの証明は食べてみること」と断言している。
詳細はSolving the Agentic Context Dilemma: Inside Neo4j's Strategy to Build an Operational World Modelを参照していただきたい。
