Amazon Neptuneとは｜3つのクエリ言語・Analyticsとの違い・料金モデルを実装目線で解説【2026年版】

Amazon Neptuneは、AWSがフルマネージドで提供するグラフデータベースサービスです。ただし「Neptune DatabaseとNeptune Analyticsは何が違うのか」「Gremlin・openCypher・SPARQLのどれで書くべきか」「料金がどの単位で発生するのか」といった採用判断の核心は、曖昧なまま検討が止まりがちです。この記事では、AWS公式ドキュメントの数値と仕様を基準に、2つのエンジンの役割分担、クエリ言語の選び方、課金要素、そして「Neptuneを選ばないほうがよい場面」までを整理します。

まとめ：Amazon Neptuneの要点

• Neptuneはプロパティグラフ（Gremlin・openCypher）とRDF（SPARQL）の両モデルに対応します。Neptune DatabaseはVPC専用サービスで、VPC外からのアクセスは許可されません。
• 「Amazon Neptune」には、トランザクション処理を担うNeptune Databaseとインメモリ解析を担うNeptune Analyticsの2エンジンが含まれます。用途が違うため、比較対象ではなく併用対象です。
• ストレージはリージョン内3つのアベイラビリティゾーンに6コピーが保持され、クラスタボリュームは最大128TiBまで拡張されます。リードレプリカは最大15台です。
• 課金はインスタンス時間（またはServerlessのNCU時間）・ストレージ・I/O・バックアップ・データ転送に分かれます。Neptune Serverlessは1NCU＝2GiBメモリ相当で、下限1.0NCU・上限128.0NCUの範囲を指定します。
• エンジン1.2系は2026年11月30日にサポート終了予定です。バージョン管理を運用計画に組み込まないまま導入すると、意図しないタイミングで自動アップグレードが発生します。
• 単純なキー参照や定型の結合・集計しか行わない要件では、Neptuneはコストに見合いません。関係そのものを何ホップも辿る問い合わせがあるかどうかが分岐点です。

Amazon Neptuneの基礎：マネージド型グラフデータベースの位置づけ

グラフデータベースが有利になる問いの形

Neptuneは、数十億の関係（リレーションシップ）を保存し、ミリ秒単位のレイテンシーでグラフを辿ることを目的に設計されたエンジンです。AWSは可用性の設計目標として99.99%超を掲げています。

リレーショナルデータベースとの分かれ目は、テーブル数でもデータ量でもなく、「何ホップ辿るか」です。「この口座から3回以内の送金でつながる口座」のような問いは、SQLでは辿る回数だけ自己結合を重ねることになり、ホップ数が増えるほど記述もチューニングも破綻します。グラフモデルなら同じ問いをノードとエッジを直接たどる操作として書けるため、ホップ数が増えても記述量はほとんど変わりません。

データモデルの比較検討段階であれば、ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】でベクトル検索との使い分けを整理しています。

Neptune DatabaseとNeptune Analyticsの役割分担

「Amazon Neptune」という名称は、性格の異なる2つのエンジンを束ねた総称です。Neptune Databaseは、アプリケーションから継続的に読み書きされるトランザクション用のグラフデータベースです。AWSは、毎秒10万クエリ規模へのスケール、Multi-AZ構成による高可用性、マルチリージョン展開を必要とするワークロード向けと位置づけており、ソーシャルネットワーク、不正検知アラート、Customer 360といった用途を挙げています。

Neptune Analyticsは、グラフデータセットをメモリ上に展開して解析するエンジンです。データはAmazon S3、またはNeptune Databaseのエンドポイントやスナップショットから読み込みます。数百億規模のリレーションシップを対象に、グラフアルゴリズムやベクトル検索を使った分析を毎秒数千件の解析クエリとして処理できるとされています。

常時稼働してアプリケーションの読み書きを受けるのがDatabase、必要なときに立ち上げて分析し切るのがAnalyticsです。Analyticsは「Databaseの上位版」ではないため、置き換えを検討する対象ではありません。

クエリ言語の選び方：Gremlin・openCypher・SPARQL

3言語とグラフモデルの対応関係

Neptune Databaseは、プロパティグラフモデルに対してApache TinkerPopのGremlinとNeo4j由来のopenCypherを、RDFモデルに対してW3C標準のSPARQLを提供します。プロパティグラフの同一グラフに対しては、GremlinとopenCypherのどちらからでもアクセスできます。一方、Neptune Analyticsについて公式ドキュメントが挙げているクエリ言語はopenCypherのみです。

将来Neptune Analyticsでの解析まで視野に入れるなら、最初からopenCypherで書くべきです。プロパティグラフを選んだうえでGremlinを主軸にすると、Analyticsへ持ち込む段階でクエリ資産を書き直すことになります。RDFとSPARQLは、語彙やオントロジーを外部標準に合わせて公開・連携する要件がある場合の選択肢であり、社内アプリケーションのバックエンドとして選ぶ理由は多くありません。

Cypherの記述そのものに馴染みがない場合は、Neo4jとは？グラフデータベースの構造とCypher・エディション選定を実装視点で解説【2026年版】が同じ言語系統の入口になります。

同一の2ホップ探索を3言語で書き比べ

「山田という人物が知っている人が、さらに知っている人（山田自身は除く）」を取り出す2ホップ探索を、3つの言語で並べます。同じ問いが言語ごとにどう表現されるかを見ると、選定の感触がつかめます。

Gremlin（プロパティグラフ）の場合です。起点の除外はwhere(neq('a'))で行います。

g.V().has('person', 'name', '山田').as('a')
  .out('knows').out('knows')
  .hasLabel('person')
  .where(neq('a'))
  .values('name')
  .dedup()
  .limit(20)

openCypher（プロパティグラフ）の場合です。宣言的にパターンを書ける分、レビュー時の可読性は高くなります。

MATCH (a:person {name: '山田'})-[:knows]->()-[:knows]->(c:person)
WHERE c <> a
RETURN DISTINCT c.name
LIMIT 20

SPARQL（RDF）の場合です。語彙をIRIで指定するため、記述はプロパティグラフの2言語より冗長になります。

PREFIX ex: <http://example.com/ns#>
SELECT DISTINCT ?name WHERE {
  ?a a ex:Person ; ex:name "山田" .
  ?a ex:knows/ex:knows ?c .
  ?c a ex:Person ; ex:name ?name .
  FILTER(?a != ?c)
}
LIMIT 20

ホップ数が3、4と増えても、追加されるのは.out('knows')、-[:knows]->()、プロパティパスの/ex:knowsという1単位だけです。記述コストが探索の深さに比例しない点が、グラフモデルを採る実利にあたります。

アーキテクチャと可用性：3AZ・6コピーの構成

ストレージ層の冗長化とクォーラム書き込み

Neptuneのデータは、クラスタボリュームと呼ばれる共有ストレージに保持されます。公式ドキュメントによれば、このボリュームは1つのリージョン内の3つのアベイラビリティゾーンにまたがって6つのコピーを持ち、Multi-AZクラスタとして作成したかどうかに関係なくこの冗長度が確保されます。書き込みはクォーラム方式です。6つのストレージノードのうち4つが応答して初めて、その書き込みは永続化されたとみなされます。

クラスタボリュームの最大サイズは128TiBです。ディスク障害はデータベースの可用性を落とさずにバックグラウンドで修復され、バックアップはAmazon S3へ継続的に転送されます。

リードレプリカの構成とフェイルオーバー

1つのクラスタは、書き込みを担当するプライマリDBインスタンス1台と、最大15台のリードレプリカで構成されます。すべてのインスタンスが同じクラスタボリュームを共有するため、レプリカ間のデータ差はごく小さく、プライマリの更新からの遅延は通常100ミリ秒未満とされています（書き込み量が非常に多い場合はこれより長くなります）。

プライマリに障害が発生すると、指定した優先度に従ってレプリカの1台が昇格します。レプリカが1台も無いクラスタでは、プライマリの再作成が完了するまで利用できない状態が続き、復旧時間は昇格に比べて大幅に長くなります。可用性を要件にするなら、プライマリと同じインスタンスクラスのレプリカを別のアベイラビリティゾーンに置く構成が前提です。

スループットの上限：クエリスレッドとスロットリング

インスタンスサイズを決めるうえで実務上効いてくるのが、同時実行数の上限です。Neptuneの各DBインスタンスは、vCPU数の2倍のクエリスレッドを持ちます。16 vCPUのdb.r5.4xlargeなら32スレッド、つまり同時に処理できるクエリは32件までとなります。

スレッドが埋まった状態で到着したクエリはサーバー側のキューに入り、先入れ先出しで処理されます。キューが保持できるのは約8,000件で、あふれるとNeptuneはThrottlingExceptionを返します。滞留状況はCloudWatchのMainRequestQueuePendingRequestsで監視できます。クライアントから見た実行時間にはこのキュー待ちが含まれるため、「レイテンシーが伸びた」の切り分けでは滞留件数を先に見るのが近道です。

料金モデル：プロビジョンドとServerlessの分岐

課金要素の内訳

Neptuneの請求は単一の単価では決まらず、次の要素の合計になります。

加えて、一定の利用量（時間あたりの金額）を1年間コミットするDatabase Savings Plansが用意されており、最大35%の削減が示されています。対象にはNeptune Instances・Neptune Serverless・Neptune Analyticsが含まれます。単価はリージョンと時期で変動するため、実額の試算はAWSの料金ページと料金計算ツールで行ってください。

Neptune ServerlessのNCU設計

Neptune Serverlessは、負荷に応じて計算能力を自動で増減させる構成です。容量の単位はNCU（Neptune Capacity Unit）で、1NCUは2GiBのメモリと、それに対応するvCPUおよびネットワーク性能に相当します。仕様上の要点は次のとおりです。

• 指定できる最小容量の下限は1.0NCU、最大容量の上限は128.0NCUです。最大容量として設定できる最小値は2.5NCUです。
• 128NCUは256GBのメモリに相当し、プロビジョンドのr6g.8xlargeと同等の規模です。
• スケールの刻みは細かく、必要量がわずかであれば0.5NCU単位で追加されます。
• スケールするのは計算能力のみで、ストレージボリュームはServerless化の影響を受けません。
• ルックアップキャッシュはServerlessインスタンスでは機能しません。
• 利用にはエンジン1.2.0.1以降が必要です。
• 対応リージョンはNeptune本体より狭く、東京（ap-northeast-1）は含まれる一方、大阪（ap-northeast-3）は含まれません。国内2リージョン構成では大阪側をServerlessにできない制約になります。

最小容量を絞りすぎると、メモリを多く使うワークロードでタイムアウトが増えるうえ、スケールアップの初速も落ちます。Neptuneは現在の容量を基準に増分を決めるため、最小値が低いほど立ち上がりが緩やかになるからです。リーダーは昇格優先度でふるまいが変わり、ティア0と1はライターと同時に、ティア2〜15は独立してスケールします。プロビジョンドのライターとServerlessのリーダーを混在させる構成でリーダーの最小容量を低くすると、書き込みの多い局面でレプリケーション遅延が拡大します。

この容量モデルはAurora Serverless v2のACUと考え方が共通しているため、Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説の整理がそのまま流用できます。

Neptune Analyticsのm-NCUとレプリカ課金の落とし穴

Neptune Analyticsの容量単位はm-NCU（メモリ最適化Neptune Capacity Unit）で、1 m-NCUがおよそ1GiBのメモリと対応する計算・ネットワーク性能に相当します。グラフ作成時に最小・最大のm-NCUを指定し、既定値は128 m-NCUです。2024年7月には32 m-NCUと64 m-NCUが追加され、それまで128 m-NCUだった下限が引き下げられました。

見落としやすいのがレプリカです。可用性設定ではフェイルオーバーレプリカを0〜2台から選べ（既定は1台）、レプリカ1台につきグラフ本体と同等のm-NCU相当の料金が加算されます。検証用のグラフでレプリカを既定のまま放置すると、必要のない冗長構成に対して倍の費用を払うことになります。ベクトル検索を使う場合の次元数も、グラフ作成時に指定する設定です。

導入前に決める接続設計：VPC必須・TLS1.2・ロードの上限

Neptune DatabaseのVPC制約とTLS要件

Neptune DatabaseはVPC専用サービスで、インスタンスはVPC外からのアクセスを許可しません。アプリケーションを同一VPCに置くか、踏み台・VPN・専用線経由の経路を用意するかを、クラスタ作成より前に決めておく必要があります。DBサブネットグループには最低2つのアベイラビリティゾーンのサブネットが必要で、AWSは3つ以上を推奨しています。接続はエンジン1.0.4.0以降HTTPS経由のSSLのみで、TLS 1.2と公式が列挙する6種類の暗号スイートが必須です。

一方、Neptune Analyticsのグラフはこの制約の外にあります。作成時に「Allow from public」を選べばインターネットから到達できるパブリックエンドポイントが作られるため、検証用に作ったグラフの公開範囲は明示的に確認してください。

接続まわりの上限値も公式に明記されています。GremlinとSPARQLのHTTPリクエストは合計150MB未満である必要があり（超過するとHTTP 400: BadRequestException）、この制限はGremlinのWebSocket接続には適用されません。1つのプロパティやラベルのサイズ上限は55MBです。WebSocket接続はアイドル20〜25分で切断され、IAM認証を有効にした場合は確立から10日あまりで必ず切れます。WebSocketの同時接続数はインスタンスタイプ依存で、Serverlessと大きいインスタンスタイプが32,768接続、db.t4g.mediumは512接続。小さいインスタンスで検証して本番へ持ち込むと、この差がそのまま接続エラーとして表面化します。

一括ロードの制約

初期データはS3から一括ロードするのが基本で、Neptuneに読み取り権限を渡すIAMロールを事前に作成します。運用上知っておくべき上限は、キューに入れられる同時実行ロードジョブが64件、追跡されるジョブ履歴が直近1,024件、1ジョブあたり保存されるエラー詳細が最大10,000件という点です。大量ファイルを細かく分割して投入すると履歴が流れ、失敗の原因追跡が難しくなります。

なお、本番クラスタを用意する前に触って確かめたい段階では、AWSはNeptune用のJupyterノートブック環境（graph-notebook）を、費用をかけずに使える学習経路として案内しています。クエリ言語の選定はここで詰められます。

エンジンバージョンとEOL管理という運用課題

製品紹介では触れられることが少ない一方、運用チームの作業を確実に発生させるのがエンジンバージョンの寿命です。2026年8月時点で最新のエンジンリリースは1.4.8.0（2026年7月27日リリース、サポート終了予定2027年10月27日）です。そして、1.2系（1.2.0.0〜1.2.1.2）はいずれも2026年11月30日にサポート終了予定で、アップグレード先として1.3.0.0が案内されています。2022年から2024年前半にかけて構築されたクラスタは、この期限に該当する可能性があります。

提供期間の目安は、マイナーバージョンがリリースから最低6か月、メジャーバージョンが最低12か月です。終了3か月前にはアカウントのメールアドレス宛の通知とAWS Health Dashboardへの掲載が行われます。期限を過ぎたバージョンはメンテナンスウィンドウ中に自動でアップグレードされます。新規クラスタやインスタンスの作成もできず、オートスケーリングによるインスタンス追加も失敗します。

実務としては、（1）現行バージョンとEOL日を構成情報として管理台帳に載せる、（2）通知メールの宛先が運用チームに届く設定になっているか確認する、（3）自動アップグレードを待たず、検証環境で先に上げてメンテナンスウィンドウを自分で選ぶ、という3点を最初の運用設計に含めておくのが安全です。

Amazon Neptuneを選ぶべきでない場面

グラフデータベースは「関係を扱うなら常に有利」ではありません。次のような要件では、Neptuneを採用しないほうが結果的にコストも運用負荷も下がります。

• 主キーによる単一レコードの取得が中心の場合：セッション管理やユーザープロファイル参照のように、キーを指定して1件引くだけの用途であれば、DynamoDBのほうが低レイテンシーかつ低コストです。複数リージョンでの参照が必要な場合の設計はDynamoDB Global Tables（グローバルテーブル）とは｜複製の仕組み・強整合性・料金で扱っています。
• 結合が1〜2段で収まる集計・レポートが中心の場合：既存のSQL資産とBIツールを活かせるAuroraやRDSのほうが総コストは低くなります。判断材料はAmazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説にまとめています。
• 全文検索やスコアリングが主目的の場合：文字列マッチとランキングが要件の中心であれば、検索エンジン側で解くべき問題です。
• 既存のCypher資産が特定製品の拡張機能に依存している場合：グラフアルゴリズムライブラリやプロシージャ拡張に強く依存した実装は、openCypher互換だけでは移植できません。移行前に依存箇所を洗い出す工程が必須です。
• 常時稼働させない検証用途の場合：Serverlessでも最小容量分の課金は稼働中ずっと発生します。使わない期間の停止・削除を運用手順に組み込めないなら、費用は想定より膨らみます。

逆に、3ホップ以上の探索が業務要件に組み込まれている、関係の種類が今後増える見込みがある、同じデータに対して探索と分析の両方を行いたい、という条件が揃うなら、Neptuneは有力な選択肢になります。

よくある質問

Amazon Neptuneとは何ですか

AWSが提供するフルマネージド型のグラフデータベースサービスです。プロパティグラフ（Gremlin・openCypher）とRDF（SPARQL）の両モデルに対応し、数十億の関係をミリ秒単位のレイテンシーで辿ることを目的に設計されています。ハードウェアの調達、パッチ適用、バックアップといった管理作業はAWS側が担います。

Amazon Neptuneの料金はいくらですか

単一の定額ではなく、本文の課金要素表に挙げた6項目の合計で決まります。見積もりで外しやすいのはI/Oです。グラフ探索は1クエリあたりの読み取り量が読みにくいため、インスタンス費用だけの試算は当てになりません。単価はリージョンと時期で変わるため、実額はAWSの料金ページと料金計算ツールで確認してください。

Neptune Analyticsとは何ですか

グラフデータをメモリ上に展開して解析する、分析向けのエンジンです。Amazon S3、またはNeptune Databaseのエンドポイントやスナップショットからデータを読み込み、事前実装されたグラフアルゴリズムやベクトル検索をopenCypherから利用できます。継続的な読み書きを担うNeptune Databaseの置き換えではなく、併用する関係にあたります。

Neptune Serverlessは東京リージョンで使えますか

公式ドキュメントが挙げるServerlessの対応リージョンに東京（ap-northeast-1）は含まれています。ただしこの一覧はNeptune本体の対応リージョンより狭く、大阪（ap-northeast-3）は含まれません。東京・大阪の2リージョンで同じ構成を組む前提の設計では、この差が制約になります。利用にはエンジン1.2.0.1以降が必要で、ルックアップキャッシュはServerlessインスタンスでは機能しません。

Amazon Neptuneはどのクエリ言語に対応していますか

Neptune DatabaseはGremlin、openCypher、SPARQLに対応します。プロパティグラフの同一グラフに対しては、GremlinとopenCypherのどちらからでもアクセスできます。Neptune Analyticsについて公式ドキュメントが挙げているクエリ言語はopenCypherのみのため、将来的な分析利用を見込むならopenCypherで統一しておくと移行の手戻りが起きません。

関連記事

• Neo4jとは？グラフデータベースの構造とCypher・エディション選定を実装視点で解説【2026年版】
• ベクトルデータベースとグラフデータベースの違い｜比較表と使い分け・GraphRAGでの併用【2026年版】
• Amazon Auroraとは？仕組み・RDSとの違いと料金モデル・採用判断を実装者目線で解説
• Amazon Aurora Serverless v2とは？料金・スケーリングの仕組みとv1移行を解説
• DynamoDB Global Tables（グローバルテーブル）とは｜複製の仕組み・強整合性・料金