AzureのグラフDBはどれを使う？Gremlin・Fabric Graph・Apache AGEとCosmos AI Graphの正体

Azureで「グラフデータベース」を探すと、Cosmos DBのGremlin API、Microsoft FabricのGraph、PostgreSQLの拡張機能Apache AGE、さらに「Cosmos AI Graph」という名前が並びます。このうち最後のCosmos AI Graph（正式名 CosmosAIGraph）はAzureのサービスではありません。Cosmos DBチームがGitHubで公開しているRAGのリファレンス実装です。

この記事では、グラフDBとして契約・作成できる3つのサービスを制約値と対応版で比べ、CosmosAIGraphが中で何をしているかをソースコードから読み解きます。

まとめ：AzureのグラフDBは用途と既存DBで選び、CosmosAIGraphは作り方の見本として読む

• アプリから低遅延で辿るグラフ（OLTP）は Azure Cosmos DB for Apache Gremlin。ただし1回のトラバーサルは30秒・repeat()は32回まで、推奨ドライバーは3.4.13で、トランザクションは使えません。
• 分析用のグラフ（OLAP）や既存Gremlinアプリの移行先は Graph in Microsoft Fabric。2026年6月にGAし、クエリ言語はISO標準のGQLです。Gremlin APIの公式ドキュメント自体が移行先として案内しています。
• 既存のPostgreSQLに関係データと一緒にグラフを置きたいなら Azure Database for PostgreSQL の Apache AGE（openCypher）。2026年5月にGAし、公式ブログはPostgreSQL 16・17・18を対象と明記しています。拡張機能の版はPG17/18がAGE 1.7.0、PG16が1.6.0です。
• CosmosAIGraphはMITライセンスのリファレンス実装で、Microsoftの製品としてのサポートはありません。Cosmos DB for NoSQL（DiskANNベクトル検索）とApache Jenaのインメモリグラフを組み合わせ、質問の意図に応じて「DB・ベクトル・グラフ」のどれを引くかを切り替えます。

Azureで使えるグラフDBの比較

グラフ専用に選ばれることが多いAzureのマネージドサービスは次の3つで、この記事ではこれらを比較します。このほかAzure SQL DatabaseとAzure SQL Managed Instanceにも、T-SQLのノード表・エッジ表と MATCH 句で多対多の関係を辿るSQL Graphがあります。アプリがすでにAzure SQLで動いているなら、別のDBを足す前にSQL Graphで足りるかを確かめる価値があります。CosmosAIGraphは比較の軸が違うため、表には入れていません。

迷ったときの目安は「誰がグラフを辿るか」です。エンドユーザーのリクエストごとに数ホップ辿るならGremlin、アナリストが集計や経路分析をするならFabric Graph、アプリの本体がすでにPostgreSQLならAGEを先に検討します。グラフDBとベクトルDBの役割の違いはベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】で整理しています。

Cosmos DB for Apache Gremlinの制約値と非対応機能

Cosmos DB for Apache GremlinはApache TinkerPopのワイヤプロトコル互換のグラフAPIで、Cosmos DBの自動インデックス・5段階の整合性レベル・マルチリージョン複製をそのまま使えます。一方で、Learnの各ページ冒頭には「高可用性が必要ならCosmos DB for NoSQLを、OLAPグラフや既存Gremlinアプリの移行ならGraph in Microsoft Fabricを検討してください」という案内が入っています。新規採用の前にこの位置づけを確認しておくべきです。Cosmos DB全体の仕組みとAPIの選び方はAzure Cosmos DBとは？マルチモデルNoSQLの仕組み・整合性レベル・RU課金と採用判断を実装者目線で解説を参照してください。

トラバーサルの上限値

Gremlinエンジン固有の制限は次のとおりです（Learn「Azure Cosmos DB for Apache Gremlin limits」）。上限に達したトラバーサルは x-ms-status-code 429で打ち切られます。

30秒のタイムアウトについて、Learnは「OLTPデータベースで大半のトラバーサルはミリ秒で終わる」と説明し、OLAPクエリにはApache SparkのGraphFramesとCosmos DB Sparkコネクタを使うよう案内しています。グラフ全体を走査して集計するクエリは、データが増えるほど30秒の上限に近づくため、Gremlin APIではなくSparkかFabric Graphに回す前提で設計します。

TinkerPopとの互換性の差

Learnの互換性ページに明記されている差分で、既存のTinkerPopアプリを移すときに引っかかるのは次の5点です。

• Gremlin Bytecode非対応：言語バインディングのトラバーサル（GLV）は使えず、GremlinClient.SubmitAsync() などで文字列として送る必要があります。
• 推奨ドライバーは3.4.13（.NET・Java・Python・Node.js・コンソール）。3.5系・3.6系には既知の互換性問題があると書かれています。
• ラムダ式と match() ステップが非対応：.map{}・.by{}・.filter{} はGremlinステップで書き直します。
• トランザクション非対応：整合性レベルとオプティミスティック同時実行制御で競合を解消します。
• 探索順が幅優先：TinkerPopは深さ優先、Cosmos DBは幅優先です。結果の並び順に依存するコードは移行時に検証が要ります。

課金はCosmos DBの他のAPIと同じくRU（Request Unit）で正規化され、プロビジョニングしたRU/秒（サーバーレスなら消費RU）と消費ストレージで決まります。1リクエストの実コストは、応答の最後のチャンクに付く x-ms-total-request-charge ヘッダーで確認できます。

RUを最も左右するのはパーティションキーです。Learnのパーティション設計ページは、/id と /label をキーにできないこと、エッジは始点の頂点と同じパーティションに格納されるため out() 方向の探索は安く、in() 方向は常にパーティションをまたぐfan-outクエリになることを明記しています。「逆向きに辿る」頻度が高い関係は、逆向きのエッジも張っておく設計が現実的です。

Graph in Microsoft Fabric：分析用グラフとGremlinの移行先

Graph in Microsoft Fabricは、OneLake上の構造化データからラベル付きプロパティグラフを組み立て、GQL（ISO/IEC 39075）で問い合わせるFabricのアイテムです。2026年6月2日のMicrosoft Build 2026で一般提供（GA）が発表され、Fabricの更新履歴にも2026年6月の「Fabric Graph (Generally Available)」として掲載されています。

Gremlin APIとの違いは、グラフ用のデータを自分で書き込まない点にあります。データソースはOneLakeとミラーリングされたデータベースで、Lakehouseのテーブルとノード型・エッジ型の対応付け（どの列をキーにし、どのテーブルが関係を表すか）をモデルとして定義して保存すると、ETLのパイプラインを組まずにグラフが構築されます。ただしグラフは読み込み（load）と更新（refresh）で作られるモデルです。元テーブルの変更は更新するまで反映されず、スキーマを変えると再読み込みになります。自然言語からGQLを生成するNL2GQLも備え、Fabric Data Agentのデータソースにグラフを指定することもできます（Data Agent側の連携はプレビュー）。

Learnの制限事項ページ（英語版・2026年9月19日更新）に載っている数値は次のとおりです。

• グラフの規模は約20億要素（ノード＋エッジ）まで。大きなグラフの読み込みには数時間かかり、24時間を超えたらサポートへの問い合わせを求めています。
• クエリAPIのタイムアウトは継続リクエストを含めて合計20分で、超えるとHTTP 408（QueryTimeout）が返ります。
• 応答は内部表現で64MBを超えると打ち切られ、省かれた行を取りにいく継続トークンはありません。中間結果は128MBが上限と記載されています。

可変長パスのホップ数は、ExploreのUIのパスビルダーでは8ホップまでですが、コードエディターで書くGQLにはこのUI上の制限はかかりません。Gremlin APIの「30秒・32ホップ」と比べると、Fabric Graphは長いタイムアウトで分析クエリを流す用途に寄せた設計です。逆にWebアプリのリクエストごとに数ミリ秒で隣接ノードを返す、といったOLTPの置き換えにはなりません。Fabricでグラフの意味（エンティティと関係）を定義するオントロジーは、Fabricオントロジーとは？Fabric IQの作成手順と新エクスペリエンスの変更点【2026年9月】で扱っています。

Azure Database for PostgreSQLのApache AGEの対応版と導入手順

Apache AGEはPostgreSQLにグラフの格納とopenCypherクエリを足す拡張機能です。Azure Database for PostgreSQL フレキシブルサーバーでは2026年5月4日の公式ブログで一般提供（GA）が告知され、対象はPostgreSQL 16・17・18です。Learnの有効化手順とは別に、拡張機能一覧に載っている版は次のとおりで、GAの対象外であるPG13〜15にも版が掲載されています。新規に使うならGA対象の16以降を選びます。

有効化の手順と LOAD ‘age’ の罠

ポータルのサーバーパラメーターで azure.extensions と shared_preload_libraries の両方にAGEを追加して保存すると、サーバーが自動で再起動します。shared_preload_libraries を忘れると、最初のCypherクエリで unhandled cipher(cstring) function call error が出ます。

注意したいのは、OSS版AGEの手順書にある LOAD 'age'; です。Azureでは起動時に読み込み済みのため、Learnは「実行すると権限エラーになる」と明記しています。OSSの手順をそのまま流すと、ここで止まります。

Cypherで2ホップ先まで辿る例

CosmosAIGraphのサンプルと同じ「ライブラリの依存関係」を、AGEで表した例です。ローカルのPostgreSQL 18.6にAGE 1.7.0（PG18ブランチ）をビルドして実行しました。Azure上ではポータルでパラメーターを設定して再起動した後に、このSQLを先頭から順に実行します。LOAD は実行しません。

CREATE EXTENSION IF NOT EXISTS age CASCADE;
SET search_path = ag_catalog, "$user", public;
SELECT create_graph('libs');

SELECT * FROM cypher('libs', $$
  CREATE (f:Library {name:'flask'})-[:USES_LIB]->(w:Library {name:'werkzeug'}),
         (f)-[:USES_LIB]->(j:Library {name:'jinja2'}),
         (j)-[:USES_LIB]->(m:Library {name:'markupsafe'})
$$) AS (v agtype);

SELECT * FROM cypher('libs', $$
  MATCH (:Library {name:'flask'})-[:USES_LIB*1..2]->(dep:Library)
  RETURN dep.name ORDER BY dep.name
$$) AS (dep agtype);

     dep
--------------
 "jinja2"
 "markupsafe"
 "werkzeug"
(3 rows)

戻り値は agtype 型なので、文字列もダブルクォート付きのJSON表現で返ります。アプリ側で素の文字列として扱うには、agtype を解釈するドライバー（AGE公式のPythonドライバーなど）を使うか、SQL側で変換します。可変長パス *1..2 は、SQLなら再帰CTE（WITH RECURSIVE）で書く探索をパターン1つで表せます。関係データの更新と同じトランザクションでグラフも更新でき、DBを増やさずに済む点が、PostgreSQLを使い続けるチームにとってAGEを選ぶ理由になります。

Cosmos AI Graph（CosmosAIGraph）の正体と中身

「Azure Cosmos DB AI Graph」はAzureポータルで作成できるサービスではありません。GitHubの AzureCosmosDB/CosmosAIGraph リポジトリ（MITライセンス・2024年9月19日作成・最新コミットは2026年7月22日）の説明は「CosmosAIGraph implementation of OmniRAG pattern」で、FAQは「Is CosmosAIGraph a supported Microsoft product?」に It is a reference implementation rather than a product. と答えています。作ったのはCosmos DBのGlobal Black Beltチームで、顧客案件の中で支援する位置づけです。

FAQはさらに「Spring Bootのようなフレームワークか」という問いにも「No」と答え、利用者がコードを大きく書き換える前提だとしています。導入に必要なスキルとしてJava・Python・Web UI・プロンプト設計が挙げられている点からも、組み込んで終わりの部品ではないことがわかります。設計パターンとしてのOmniRAGはOmniRAGとは？意図に応じてDB・ベクトル検索・ナレッジグラフを使い分けるRAG設計パターンで解説しています。

構成要素：Cosmos DB for NoSQLとインメモリのJena

グラフはCosmos DBに格納されたドキュメントから起動時に組み立てられ、Graph appのメモリ上にRDFトリプルとして保持されます。グラフ層はGremlin APIではなく、RDF・OWL・SPARQLの世界です。FAQによると2,000万トリプル超で試験済みで、Container Appsのワークロードプロファイルなら最大880GBのメモリを使えるとしています。ただしContainer Appsの仕様で880GiBに届くのはA100搭載のGPUプロファイル（West US 3・North Europe）で、GPUなしのメモリ最適化プロファイル（E4〜E32）は256GiBまでです。SPARQLの書き方はSPARQLとは？RDFを検索するクエリ言語の書き方とSQLとの違いを実行例で解説【2026年版】、Jenaのサーバー運用はApache Jena Fusekiとは？Jena 6の変更点とインストール・Docker運用を実装目線で解説が詳しいです。

意図判定は「短文のルール判定」＋「LLMの一語分類」

OmniRAGの肝である意図判定は、impl/web_app/src/services/strategy_builder.py の StrategyBuilder クラスが担います。処理は2段です。

1. 4語未満で、先頭が lookup・find・fetch・search・get・retrieve・show のいずれか、かつ既知のエンティティ名を含む質問は、LLMを呼ばずに db（Cosmos DBの name を条件にしたドキュメント検索）へ振る。
2. それ以外はLLMに「db・vector・graph のどれか一語で答えよ」と分類させ、返答を正規化する。解釈できない返答は vector に倒す。

このルール判定部分と正規化部分を簡略化して、Python 3で動かした結果が次のとおりです。元実装にあるエンティティ辞書の読み込み、JSON形式の返答の解釈、「find」「lookup」など単語を含む返答を db に寄せる判定は省いています。

KNOWN_ENTITIES = {"flask", "django", "pandas"}
LOOKUP_WORDS = "lookup,find,fetch,search,get,retrieve,show".split(",")

def rule_based(nl):
    words = nl.split(" ")
    if len(words) < 4 and words[0].lower() in LOOKUP_WORDS:
        for w in words[1:]:
            if w.lower() in KNOWN_ENTITIES:
                return {"strategy": "db", "name": w.lower()}
    return None

def normalize(raw):
    text = str(raw).strip().lower() if raw is not None else ""
    if text in ("database", "db", "dbms"):
        return "db"
    if text in ("db", "vector", "graph"):
        return text
    if "graph" in text:
        return "graph"
    if "vector" in text or "embedding" in text:
        return "vector"
    return "vector"

for q in ["lookup flask", "find library Flask", "What libraries does flask depend on?"]:
    print(q, "->", rule_based(q) or "LLMへ回す")
for raw in ["Graph", "database", "unknown"]:
    print(repr(raw), "->", normalize(raw))

lookup flask -> {'strategy': 'db', 'name': 'flask'}
find library Flask -> {'strategy': 'db', 'name': 'flask'}
What libraries does flask depend on? -> LLMへ回す
'Graph' -> graph
'database' -> db
'unknown' -> vector

「依存関係を教えて」のような関係を問う質問は、ルール判定を通らずLLMの分類に回ります。そこで graph と判定されると、LLMがOWLのオントロジーを参照してSPARQLを生成し（READMEの言う「Runtime NL2Query conversion」）、Graph appへPOSTしてJenaのグラフを引きます（rag_data_service.py）。自動判定でdb・graphになった質問が1件も取れなかったときはvectorへフォールバックし（画面で経路を明示指定した場合は切り替えない）、画面から「all」を選ぶと3経路を並行で引きます。解釈できない返答をvectorに倒す既定値は、分類に失敗しても処理を止めないための設計です。回答が正しくなるかは別問題で、自社で作るなら、分類結果とフォールバックの発生回数を記録し、意図別の正解データで経路の選び方を評価してから既定値を決めます。

CosmosAIGraphを本番に持ち込む前の判断材料

リファレンス実装をそのまま本番へ載せると、次の4点で詰まります。いずれもリポジトリの設定ファイルとFAQから読み取れる事実です。

• グラフが揮発する：既定のグラフバックエンドは in_memory で、グラフは起動時にCosmos DBから組み直します。FAQは可用性のため2インスタンス以上を推奨していますが、稼働中の更新は「リファレンス実装では示していない」とし、変更フィードで反映する方式を案として挙げるだけです。
• Fusekiバックエンドは単一レプリカ前提：Bicepの第2の選択肢 fuseki は、データセットが一時的で起動時に再投入されるため、レプリカを1つに固定するよう書かれています。
• ローカル用のFusekiイメージが古い：docker-compose.yml が参照する stain/jena-fuseki:latest は、Docker Hub上で2024年7月31日の5.1.0が最後です。現行のJenaは6系なので、本番では自前ビルドのイメージに置き換えます。
• Microsoft製品としてのサポートはない：SUPPORT.mdは「supported Microsoft software product」ではないと明記し、問い合わせはGitHub Issuesへの報告になります。FAQにある顧客支援は、Global Black Beltチームが関わる案件の中での話です。

この4点から、判断ははっきりしています。CosmosAIGraphは「意図判定・自然言語からのSPARQL生成・ベクトルとグラフの併用」をどう組むかを学ぶ見本として読み、本番のグラフ層は、再起動で消えない永続化した構成で設計し直すべきです。移し先を選ぶときは、SPARQLとOWLの資産を残すか捨てるかで道が分かれます。残すならJena（Fuseki）やその他のRDFストアを永続化して運用する形になり、Gremlin API・Fabric Graph・AGEはいずれもプロパティグラフなので、オントロジーとSPARQL生成のプロンプトを作り直すことになります。インメモリ構成のまま本番寄りに育てられるのは、グラフに載せる属性を絞ったうえで、ピーク時のメモリ使用量が割り当ての範囲に収まり、再起動時の再構築時間と更新の反映遅れを業務として許容できると測定で確かめた場合です。

ナレッジグラフをLLMで自動抽出するMicrosoft ResearchのGraphRAGは、FAQが「別プロジェクト」と明言している別物です。AzureでGraphRAGを動かす構成はGraphRAGをAzureで動かす方法｜Accelerator終了後の現行構成と実装手順【2026年版】を参照してください。Azure以外のマネージドグラフDBと比べるなら、Neo4jとは？グラフデータベースの構造とCypher・エディション選定を実装視点で解説【2026年版】とAmazon Neptuneとは｜3つのクエリ言語・Analyticsとの違い・料金モデルを実装目線で解説【2026年版】が比較材料になります。

よくある質問

AzureにグラフDB専用のサービスはありますか？

「グラフDB専用」の単独サービスはなく、Cosmos DB for Apache Gremlin（OLTP）、Graph in Microsoft Fabric（OLAP・2026年6月GA）、Azure Database for PostgreSQLのApache AGE拡張が主な選択肢で、Azure SQL Database・Managed InstanceのSQL Graphも使えます。

Azure Cosmos DB AI Graphはどこで作成できますか？

Azureポータルでは作成できません。GitHubの AzureCosmosDB/CosmosAIGraph リポジトリをクローンし、BicepでContainer Appsへ配備するリファレンス実装です。Microsoftの製品サポートは付きません。

Cosmos DBとは何ですか？グラフDBなのですか？

Cosmos DBはマルチモデルのNoSQLデータベースで、NoSQL・MongoDB・Cassandra・Gremlin・Tableの各APIを選べます。グラフDBとして使うのはGremlin APIを選んだ場合だけです。ベクトル検索を含むNoSQL APIの選び方はAzure Cosmos DB for NoSQLとは｜API選定・RU料金・整合性・ベクトル検索で扱っています。

Cosmos DBのGremlin APIで最新のGremlinドライバーは使えますか？

Learnの推奨は3.4.13です。3.5系・3.6系は既知の互換性問題があるとされ、Gremlin Bytecodeにも対応していないため、トラバーサルは文字列で送ります。

Neo4jをAzureで使うことはできますか？

マネージド版のNeo4j AuraをAzure Marketplaceから従量課金で購読できます。2026年1月13日より前に購読した旧リスティングはAuraDB Professionalしか使えず、2026年9月19日に非推奨になったため、Neo4jのドキュメントに沿って新リスティングへの切り替えが必要です。Azureのネイティブサービスではないため、サポートはNeo4j側の契約に従います。

関連記事

• OmniRAGとは？意図に応じてDB・ベクトル検索・ナレッジグラフを使い分けるRAG設計パターン
• Azure Cosmos DBとは？マルチモデルNoSQLの仕組み・整合性レベル・RU課金と採用判断を実装者目線で解説
• ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】
• GraphRAGをAzureで動かす方法｜Accelerator終了後の現行構成と実装手順【2026年版】
• Neo4jとは？グラフデータベースの構造とCypher・エディション選定を実装視点で解説【2026年版】