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の選定基準とCosmosAIGraphの位置づけ

• アプリから低遅延で辿るグラフ（OLTP）は Azure Cosmos DB for Apache Gremlin。ただし1回のトラバーサルは30秒・repeat()は32回まで、推奨ドライバーは3.4.13で、トランザクションは使えません。東日本の400 RU/秒のスループット料金は月26.28ドルです（ストレージは別・無料枠を使わない場合）。
• 分析用のグラフ（OLAP）や既存Gremlinアプリの移行先は Graph in Microsoft Fabric。2026年6月にGAし、クエリ言語はISO標準のGQLです。稼働中は1秒あたり10 CU秒を消費し、ストレージは最低100GBが確保されます。
• 既存のPostgreSQLに関係データと一緒にグラフを置きたいなら Azure Database for PostgreSQL の Apache AGE（openCypher）。2025年5月にGAし、PostgreSQL 18への対応は2026年4月リリースで追加されました。拡張機能の版はPG17/18がAGE 1.7.0、PG14〜16が1.6.0です。
• アプリがAzure SQLで動いているなら、DBを増やす前にSQL Graph（MATCH・SHORTEST_PATH）で足りるかを確かめます。
• CosmosAIGraphはMITライセンスのリファレンス実装で、Microsoftの製品としてのサポートはありません。Cosmos DB for NoSQL（DiskANNベクトル検索）とApache Jenaのインメモリグラフを組み合わせ、質問の意図に応じて「DB・ベクトル・グラフ」のどれを引くかを切り替えます。

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

グラフ専用に選ばれることが多いAzureのマネージドサービスは次の3つです。CosmosAIGraphは比較の軸が違うため、表には入れていません。

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

Azure SQLのSQL Graphで足りる場合

Azure SQL DatabaseとAzure SQL Managed Instanceには、T-SQLのノード表・エッジ表を SELECT の WHERE 句に書く MATCH 句で辿るSQL Graphがあります。可変長の探索は SHORTEST_PATH を MATCH の中で使い、対象のノード表・エッジ表に FOR PATH を付けます。制約は2つです。SHORTEST_PATH が返すのは重みなしの最短経路1本だけで、同じ長さの経路が複数あっても全部は返しません。MATCH のパターンには OR と NOT を書けません。「取引先の取引先を3段まで辿る」程度の要件なら、既存のAzure SQLに表を足すだけで済み、別のDBを運用する費用がかかりません。

AzureのグラフDB料金：東日本リージョンの単価比較

3つは課金の単位がそろっていないため、Azure Retail Prices APIから2026年10月30日に取得した東日本（japaneast）の従量単価（米ドル・税抜）で、最小に近い構成を1か月730時間として換算しました。

Cosmos DBの手動プロビジョニングは、Learnのスループット設定ページのとおり400 RU/秒が入口です。Gremlin APIもサーバーレスに対応しますが、サーバーレスのアカウントは1リージョンでしか動きません。マルチリージョン複製が要るなら、プロビジョニングを選びます。無料枠（1,000 RU/秒と25GB）もGremlinのアカウントで使えます。GremlinのFAQによると、RUは返した結果の大きさではなく、トラバーサルが処理した作業データの量で決まります。結果が1行でも、途中で大量の頂点を読めばRUは膨らみます。クエリの末尾に executionProfile() を付けると、頂点・エッジの取得時間と作業データの大きさが出るので、見積もりの前に重いクエリをこれで確かめます。

Fabric Graphの計算は、Learnの概要ページの「Pricing and capacity units」によると、CPUの稼働1秒ごとに10 CU秒を消費し、稼働の区切りは分単位に切り上げます。グラフ専用のライセンスやSKUは無く、組織のFabric容量（予約または従量）から引かれます。表の2.10ドルは、10 CUを東日本の従量単価0.21ドル/CU時で換算した値です。実際には容量を他のワークロードと分け合うので、既存のFabric容量に空きがあれば追加の支払いは発生せず、空きが無ければ容量を上げる判断になります。東日本・西日本とも提供リージョンに入っています。

月に1回の分析でも、Fabric Graphのほうが安いとは限りません。最低100GBのグラフストレージ料金と、既存のFabric容量の余力、新規に必要な容量の費用を含めて比較します。アプリが24時間リクエストを投げる用途では、Fabric Graphの計算は730時間で1,533ドル相当になります。400 RU/秒やB1msで同じ処理性能を満たせるかは別途検証が必要ですが、常時稼働のOLTPに向いた課金ではありません。AGEには専用の課金メーターが価格APIに見当たらず、既存のPostgreSQLサーバーに載せるなら追加費用はCPUとストレージの増分だけです。

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・コンソール。PHPは3.1.0）。3.5系・3.6系には既知の互換性問題があると書かれています。
• ラムダ式と match() ステップが非対応：.map{}・.by{}・.filter{} はGremlinステップで書き直します。
• トランザクション非対応：整合性レベルとオプティミスティック同時実行制御で競合を解消します。
• 探索順が幅優先：TinkerPopは深さ優先、Cosmos DBは幅優先です。結果の並び順に依存するコードは移行時に検証が要ります。

Pythonからクエリを文字列で送る例

LearnのPythonクイックスタートは pip install gremlinpython と版を指定していません。2026年10月30日時点のPyPI最新版は3.8.2（Python 3.10以上3.14未満）で、Python 3.10〜3.13の環境ならこれが入ります。互換性ページの推奨は3.4.13（2022年1月公開）なので、版を固定して入れます。3.4.13は依存に tornado<6.0 を持つため、検証はPython 3.8で行いました。

# pip install gremlinpython==3.4.13
from gremlin_python.driver import client, serializer

c = client.Client(
    url="wss://<account>.gremlin.cosmos.azure.com:443/",
    traversal_source="g",
    username="/dbs/<database>/colls/<graph>",
    password="<primary-key>",
    message_serializer=serializer.GraphSONSerializersV2d0(),
)

def run(q, **b):
    return c.submit(message=q, bindings=b).all().result()

# 検証用の空のグラフをパーティションキー /pk で作成済みとする
# この登録処理を再実行すると頂点とエッジが重複するため、実行は1回とする
for name in ["flask", "werkzeug", "jinja2", "markupsafe"]:
    run("g.addV('library').property('name', n).property('pk', n)", n=name)
for src, dst in [("flask", "werkzeug"), ("flask", "jinja2"), ("jinja2", "markupsafe")]:
    run("g.V().has('library','name',s).addE('uses_lib').to(g.V().has('library','name',d))", s=src, d=dst)

print(run("g.V().has('library','name',n).repeat(out('uses_lib')).emit().times(2).values('name').dedup()", n="flask"))
print(run("g.V().has('library','name',n).in('uses_lib').values('name')", n="markupsafe"))
c.close()

接続先だけを手元のApache TinkerPop Gremlin Server 3.4.13（既定の設定に無いGraphSON v2のシリアライザーを追加）に替えて実行した結果が次のとおりです。

['werkzeug', 'jinja2', 'markupsafe']
['jinja2']

ポイントは3つあります。トラバーサルは文字列で送り、値は bindings で渡します。文字列連結で組み立てると、Gremlinのインジェクションを招きます。シリアライザーはクイックスタートと同じGraphSON v2を指定します。username は /dbs/<database>/colls/<graph> の形式で、頂点を作るときは必ずパーティションキーのプロパティ（ここでは pk）を入れます。

パーティションキーとRUの関係

課金はCosmos DBの他のAPIと同じくRU（Request Unit）で正規化され、1リクエストの実コストは、応答の最後のチャンクに付く x-ms-total-request-charge ヘッダーで確認できます。RUを最も左右するのはパーティションキーです。Learnのパーティション設計ページは、/id と /label をキーにできないこと、エッジは始点の頂点と同じパーティションに格納されるため out() 方向の探索は安く、in() 方向は常にパーティションをまたぐfan-outクエリになることを明記しています。上の例の最後のクエリ（in('uses_lib')）がそれに当たります。「逆向きに辿る」頻度が高い関係は、逆向きのエッジも張っておく設計が現実的です。また、掲載コードでは名前だけで頂点を検索していますが、パーティションキーが分かる本番の検索では、その値も条件に指定します。この例なら名前と同じ値を持つ pk を絞り込みに追加できます。

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でグラフの意味（エンティティと関係）を定義するオントロジーは、Microsoft Fabricのオントロジーとは？Fabric IQでの作成手順・課金・MCP接続【2026年10月】で扱っています。

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

Apache AGEはPostgreSQLにグラフの格納とopenCypherクエリを足す拡張機能です。Azure Database for PostgreSQL フレキシブルサーバーでは、2025年5月19日のTech Communityの公式ブログで一般提供（GA）が告知されました。PostgreSQL 18への対応は2026年4月のメンテナンスリリースで追加され（2026年4月22日以降に作成したサーバーから適用）、2026年5月4日の公式ブログが「PostgreSQL 16・17でGA、18にも対応を拡大」と紹介しています。拡張機能の版一覧に載っている版は次のとおりです。

2026年のブログが名前を挙げているのは16〜18だけです。新しくサーバーを作るなら、AGE 1.7.0が入る17か18を選びます。

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

ポータルのサーバーパラメーターで azure.extensions と shared_preload_libraries の両方にAGEを追加して保存すると、サーバーが自動で再起動します。その後 CREATE EXTENSION age CASCADE; を実行します。shared_preload_libraries を忘れると、最初のCypherクエリで unhandled cypher(cstring) function call error が出ます（Learnの日本語・英語ページはこのメッセージを「cipher」と誤記しており、2025年のGA告知ブログは「cypher」です）。

注意したいのは LOAD 'age'; です。LearnのAGE概要ページは、起動時に読み込み済みのため実行は不要で、実行すると権限エラーになると明記しています。ところが2026年5月4日の公式ブログのサンプルコードは、先頭で LOAD 'age'; を実行しています。OSS版AGEの手順書も同じです。ブログやOSSの手順をそのまま流すと、ここで止まります。Azureでは LOAD の行を消してから実行します。

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

上のGremlinの例と同じ「ライブラリの依存関係」を、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を本番に持ち込む前の判断材料

リファレンス実装をそのまま本番へ載せると、次の点で詰まります。いずれもコミット7bce339（2026年7月22日）時点のcaig.bicep・build.gradle・コミット履歴・FAQから読み取れる事実です。

• グラフが揮発する：既定のグラフバックエンドは in_memory で、グラフは起動時にCosmos DBから組み直します。FAQは可用性のため2インスタンス以上を推奨していますが、稼働中の更新は「リファレンス実装では示していない」とし、変更フィードで反映する方式を案として挙げるだけです。
• 既定のコンテナーイメージが個人の名前空間にある：2026年7月6日のコミットで、Bicepの既定イメージが omnirag から alexsavat/caig_graph:latest・alexsavat/caig_web:latest（Docker Hub）に変わりました。タグが latest なので、配備のたびに中身が変わりえます。本番では自分でビルドしたイメージをACRに置き、環境変数 CAIG_GRAPH_SERVICE_IMAGE・CAIG_WEB_APP_IMAGE で差し替えます。
• Fusekiバックエンドは単一レプリカ前提で、MCPサーバーも付いてくる：第2の選択肢 fuseki はデータセットが一時的で起動時に再投入されるため、レプリカを1つに固定します。この構成ではMicrosoft Foundry IQのナレッジソース向けに、第三者のリポジトリ（alekseys/mcp-jena）からビルドしたMCPサーバーも配備されます。Fusekiの管理パスワードとMCPのAPIキーは配備スクリプトが乱数で作ります。Bicepのパラメーターファイルを直接使う場合、Fusekiの管理パスワードの既定値は admin で、MCPのAPIキーの既定値は空文字です（空のままだと配備が失敗するよう書かれています）。
• 依存の版が古い・未確定：Graph appは Spring Boot 4.0.0-M2（マイルストーン版）とJena 5.5系に固定されています。Jenaの最新は6.2.0です。docker-compose.yml が参照する stain/jena-fuseki:latest は、Docker Hub上で2024年7月31日の5.1.0が最後です。
• Microsoft製品としてのサポートはない：SUPPORT.mdは「supported Microsoft software product」ではないと明記し、問い合わせはGitHub Issuesへの報告になります。FAQにある顧客支援は、Global Black Beltチームが関わる案件の中での話です。一方で、2026年7月にはFoundryとCosmos DBのRBACでマネージドIDを使う変更が入っており、キーを置かずに配備する構成には寄ってきています。

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

ナレッジグラフをLLMで自動抽出するMicrosoft ResearchのGraphRAGは、FAQが「別プロジェクト」と明言している別物です。AzureでGraphRAGを動かす構成はGraphRAGをAzureで動かす方法｜graphrag 3.3の設定とAccelerator終了後の選択肢【2026年10月】を参照してください。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拡張（2025年5月GA）が主な選択肢で、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にも対応していないため、トラバーサルは文字列で送ります。Pythonなら gremlinpython==3.4.13 と版を固定して入れます。

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

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

関連記事

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