Hasuraとは？DBから即GraphQL APIを生成するOSSとDDNの最新像

Hasuraは、PostgreSQLなどのデータベースに接続するだけで、テーブル構造から読み取り・書き込み・購読に対応するGraphQL APIを自動生成するソフトウェアです。この記事では、その基本動作から、現在二系統に分かれているHasura v2(GraphQL Engine)とHasura DDN(v3)の違い、Docker自己ホストとマネージドの選び分け、アクティブモデル課金という独特の料金体系、そして2025年に整備されたPromptQLとMCPサーバによるAIエージェント連携までを、公式ドキュメントとGitHubの一次情報に基づいて整理します。最後に、Hasuraを採用すべき場面と避けるべき場面の判断基準まで踏み込みます。

まとめ：Hasura採用判断とv2・DDNの選び分けの要点

結論から述べます。Hasuraは「既存のリレーショナルデータベースを、API実装をほとんど書かずにGraphQL化したい」という要件に最も強く効きます。スキーマ定義からCRUD・リレーション・購読・権限制御までを自動生成するため、社内ツールや管理画面、PoF段階のプロダクトでは実装工数を大きく圧縮できます。

系統の選び分けはこう考えます。単一〜少数のデータベースを安定運用したいなら、現行の安定版であるv2 GraphQL Engine(v2.49系)で十分です。複数データソースを1つのGraphQL APIに束ねる「スーパーグラフ」や、エッジ配信、AIエージェント連携まで視野に入るなら、Rustで再設計されたHasura DDN(v3)が選択肢になります。両系統ともコアエンジンはApache License 2.0で公開されており、自己ホストなら無償で始められます。

逆に、GraphQLスキーマを業務ドメインに合わせて緻密に設計し、複雑なビジネスロジックをサーバ側で握りたいプロジェクトでは、Hasuraの自動生成は足かせになりがちです。判断基準の詳細と典型的な失敗パターンは後半で具体的に示します。

Hasuraの基本：データベースから即時にGraphQL APIを生成する仕組み

HasuraはGraphQLそのものではなく、GraphQLを「自動で提供する」ためのエンジンです。GraphQL自体の文法や設計思想は別記事で扱っているため、ここではHasuraが何を肩代わりするのかに絞って説明します。

Hasuraの定義と、既存DBへ接続して即GraphQL APIを生成する基本動作

Hasuraは、接続したデータベースのテーブルやビューを読み取り(イントロスペクション)、それぞれに対応するGraphQLの型・クエリ・ミューテーション・サブスクリプションを生成します。たとえばusersテーブルを追跡対象にすると、一覧取得のusersクエリ、絞り込み用のwhere引数、挿入用のinsert_usersミューテーションなどが、コードを書かずに即座に使える状態になります。アプリケーション側はこのエンドポイントに対してクエリを投げるだけで済みます。GraphQLの基本概念から確認したい場合はGraphQLをわかりやすく解説した記事を起点にすると理解が早まります。

GraphQL自動生成がREST API手書きと比べて削減する開発工数の中身

REST APIを手書きする場合、エンドポイント設計、シリアライズ、ページネーション、フィルタ、N+1対策まで自前で実装します。Hasuraはこれらを生成物として提供するため、削減されるのは主に定型的なCRUD層の実装です。クライアントが必要なフィールドだけを指定して取得できるGraphQLの性質上、オーバーフェッチ・アンダーフェッチの調整も不要になります。GraphQLとRESTの設計思想の違いはGraphQLとREST APIを比較した記事で詳しく整理しています。一方で、自動生成されるのはあくまでデータアクセス層であり、決済処理や外部連携のようなビジネスロジックは別途用意する必要があります。

権限制御・イベントトリガー・リモートスキーマという中核機能の整理

Hasuraの価値はAPI生成だけではありません。実務で効く中核機能は次の3つです。

• 行・列レベルの権限制御：ロールごとに「自分の行だけ参照可」といったルールをセッション変数で宣言的に定義でき、認可ロジックをアプリ側に散らさずに済みます。
• イベントトリガー：テーブルへの挿入・更新・削除を契機にWebhookを呼び出し、メール送信や非同期処理を起動できます。
• リモートスキーマ：別のGraphQLサービスや外部APIを同一エンドポイントに統合し、データベースと横断したクエリを実現します。

このうち権限制御は導入効果が最も大きく、まずここを押さえると評価がぶれません。イベントトリガーとリモートスキーマは、要件に応じて段階的に足していく機能と捉えると整理しやすくなります。

Hasura v2(GraphQL Engine)とHasura DDN(v3)という二系統の現在地

日本語の解説記事の多くはv2時代に書かれており、現行のDDN(v3)との関係が整理されていません。ここが混乱の元になるため、二系統の現在地を先に固定します。

安定版v2 GraphQL Engine(現行v2.49系)の位置づけと対応データベース

Hasura V2は、公式が「current stable version(現行の安定版)」と位置づけるGraphQL Engineで、執筆時点の最新はv2.49系のパッチリリースが続く状態です。v2.0以降は複数データベース接続に対応し、PostgreSQLに加えてMS SQL Server、MySQL、BigQueryなどを単一のGraphQL APIに束ねられます。Enterprise Editionには長期サポート(LTS)版が用意され、初回リリースから2年間、重要なセキュリティ修正とバグ修正が提供されます。すでにv2で安定運用している環境を、無理にDDNへ移す必要はありません。

Rust製エンジンとNDC/OpenDDで再設計されたHasura DDNの特徴

Hasura DDN(Data Delivery Network)は、コアエンジンをHaskellからRustへ書き換えて再設計した次世代製品です。エンジンはOpenDD仕様(Open Data Domain Specification)とNDC仕様(Native Data Connector Specification)に基づいて動作し、データベースへ直接クエリを発行しません。代わりに抽象化した中間クエリを各データコネクタへ渡し、コネクタが実データソースへのクエリを担います。GA時点の対応データソースはPostgreSQL系・MongoDB・ClickHouse・MS SQL Serverで、カスタムビジネスロジックはTypeScript・Python・Goのコネクタ用SDKで記述できます。すべてのデータコネクタはApache License 2.0で公開されています。

ビルドとランタイムを分離するControl Plane/Data Plane構成の意味

v2とDDNの最大の構造差は、ビルドタイムとランタイムの分離です。DDNではControl Planeがプロジェクトのメタデータをビルドし、生成された各「スーパーグラフビルド」がData Plane上で固有のGraphQL APIとして提供されます。Data Planeはリクエストごとに設定をオンデマンドで読み込んで破棄するサーバレス的なランタイムで、Anycast IPによる近接ルーティングでGCP・AWS・Azureのマルチリージョンに配置できます。複数チームが1つのスーパーグラフを分担して育てる開発体制を前提にした設計であり、単一サービスの小規模APIではこの分離が過剰になることもあります。

Hasuraの始め方：Docker自己ホストとマネージド(Cloud/DDN)の選び分け

導入経路は大きく、自己ホストとマネージドの2つに分かれます。まず手元で挙動を確かめたいなら、v2 GraphQL EngineをDockerで起動するのが最短です。

Docker Composeでローカルにv2 GraphQL Engineを立ち上げる手順

v2のローカル検証は、PostgreSQLとHasuraをComposeでまとめて起動する構成が定番です。最小の流れは次のとおりです。

1. 公式が配布するdocker-compose.yamlを取得し、PostgreSQLとGraphQL Engineのサービス定義を確認します。
2. HASURA_GRAPHQL_METADATA_DATABASE_URLなどの接続情報を環境変数に設定します(v2ではメタデータ用DBの指定が必須です)。
3. docker compose up -dで起動し、ブラウザからhttp://localhost:8080のConsoleにアクセスします。
4. Consoleでテーブルを追跡(track)すると、その時点でGraphQL APIが生成されます。

この段階ではコードを一行も書いていません。生成されたエンドポイントをそのまま叩いて、自動生成の範囲を体感するのが最初の到達点になります。

Hasura CLIとConsoleによるメタデータ・マイグレーションの管理

検証から開発・本番へ進むと、Consoleの手作業だけでは構成を再現できなくなります。ここでhasura CLIを使い、テーブル定義の変更をマイグレーションとして、権限やリレーションの設定をメタデータとしてファイルに書き出します。これらをGitで管理することで、環境間で同じ構成を再構築でき、レビューや巻き戻しも可能になります。Consoleは可視化と試行錯誤、CLIは構成のコード化という役割分担で運用すると破綻しにくくなります。

セルフホストとマネージド(Hasura Cloud/DDN)を分ける判断軸

自己ホストは、インフラを自社で管理する代わりにライセンス費用がかからず、データを外部に出さない構成を取れます。一方マネージドは、スケーリング・監視・運用保守をHasura側が担い、APIが即座に利用可能になります。判断軸はシンプルで、運用人員とコンプライアンス要件で決まります。専任のインフラ担当を割けず、可用性と監視を任せたいならマネージド、データの所在やネットワークを完全に制御したいなら自己ホストが向きます。DDNにはセルフホスト型のData Planeを選べるPrivate DDNもあり、両者の中間を取る選択肢も用意されています。

Hasura DDNの料金体系：アクティブモデル課金と4プランの構成

“hasura 料金”を調べても体系的な解説は見つかりにくいのが現状です。DDNは従量制(リクエスト数課金)とは発想が異なる「アクティブモデル課金」を採用しており、ここを理解しないとコスト試算を誤ります。

Free・Base・Advanced・Private DDNという4プランの適用範囲

DDNのプランは4段階です。Freeはベースコストがかからず個人開発や検証に適し、Base/AdvancedとPrivate DDNが商用利用の中心になります。Private DDNはデータプレーンを専用インフラに隔離し、VPCピアリングやSAMLシングルサインオン、HIPAAなどの規制対応を可能にします。

BaseとAdvancedには30日間の無料トライアルがあり、期間終了後は課金されず直前の非トライアルプラン(FreeまたはBase)へ自動的に下がります。具体的なモデル単価は改定されるため、契約前に公式の料金ページで最新値を確認してください。

「アクティブモデル(月1000ヒット以上)」課金が従量制と異なる理由

DDNの課金単位は「アクティブモデル」です。Hasuraはアクティブモデルを、月1000ヒット以上のリクエストを受けたモデルと定義し、ほとんど使われないアイドルなモデルは課金対象から外します。これは「橋(API)を架けることに対して課金し、橋を渡る通行料は取らない」という考え方で、アプリの人気が出てリクエストが急増しても、モデル数が増えなければコストが跳ね上がらない点が従量制との決定的な違いです。コスト試算では、想定リクエスト数ではなく「実際に稼働するモデル数」を見積もりの軸に置くのが正しいアプローチになります。

HasuraとPromptQL・MCPサーバで社内データをAIエージェントに接続する構成

2025年以降のHasuraで最も新しく、かつ既存の日本語記事がほぼ触れていないのが、AIエージェントとのデータ連携です。中心になるのがPromptQLと、そのMCPサーバです。

PromptQLが自然言語クエリをDDNコネクタ経由で実行する仕組み

PromptQLはHasuraの自然言語データエージェントで、「第2四半期の地域別売上は」といった問いを受け取り、データの探索・取得・加工・整形の計画を立て、それをコードとして実行します。データへの到達はDDNのコネクタを経由するため、PostgreSQL・MySQL・SQL Serverといった複数のデータソースへ統一的にアクセスできます。実行結果はHasuraの権限モデルを継承するため、AIはユーザーの権限で許された範囲のデータしか取得できません。これは、AIにデータを開く際の認可制御という難所を、既存のアクセス制御で解く構成です。

PromptQL MCPサーバでAIクライアントから社内データを問い合わせる手順

MCP(Model Context Protocol)は、AIモデルと外部ツールを接続する標準仕様です。HasuraはオープンソースのPromptQL MCPサーバを公開しており、これを介してClaude DesktopなどのMCP対応クライアントから、自然言語で社内データを問い合わせられます。設定の流れは、PromptQLのAPIキーとプレイグラウンドURLをMCPサーバに登録し、クライアント側の設定ファイルにサーバ起動コマンド(python -m promptql_mcp_server)を記述するというものです。サーバはPython 3.10以上で動作し、公開DDN・プライベートDDNの双方の認証モードに対応します。社内のデータ基盤をAIアシスタントの問い合わせ先にしたいDX案件で、現実的な接続口になります。

Hasuraを採用すべき場面と、避けるべき場面の具体的な判断基準

ここでは玉虫色を避け、条件付きで言い切ります。Hasuraは万能ツールではなく、要件との相性がはっきり出る製品です。

Hasuraが効く要件：既存DBの即API化・社内ツール・短期PoC

Hasuraが最も価値を出すのは、すでにスキーマが固まったデータベースを短期間でAPI化したいケースです。社内の管理画面、ダッシュボード、検証段階のプロダクトのように、データアクセス層が主役でビジネスロジックが薄い場面では、実装コストの削減効果が素直に出ます。リアルタイム更新が必要なアプリでも、サブスクリプションが標準で使えるため追加実装を抑えられます。

Hasuraを採用すべきでない場面と、現場で起きやすい失敗パターン

逆に、次の条件が重なるプロジェクトでは採用を見送るべきです。第一に、GraphQLスキーマを業務ドメインに合わせて緻密に設計したい場合。Hasuraの自動生成はDBスキーマに強く結びつくため、DB構造とは独立した理想的なAPI設計を志向すると、両者の乖離を埋める作業が増えていきます。第二に、複雑な業務ロジックをAPI層の中心に据えたい場合。Hasuraはデータアクセスに最適化されており、重いロジックはActionsや外部サービスへ逃がす前提のため、ロジック主体の設計とは噛み合いません。よくある失敗は、DBの正規化が甘いまま自動生成し、使いにくいAPIがそのまま露出してしまうパターンです。Hasuraは「整ったDBを速くAPI化する」道具であって、「設計の甘さを吸収する」道具ではない、と理解しておく必要があります。

自前GraphQLサーバ・Directus等の代替手段との使い分け

代替手段との比較で立ち位置が明確になります。スキーマやロジックを完全に手で握りたいなら、Spring for GraphQLのようなフレームワークでサーバを自前実装する選択が向きます。データベースのGUI管理やコンテンツ運用まで含めたいなら、ヘッドレスCMS型のDirectusが候補になります。フロントエンドからHasuraのAPIを扱う際は、Apollo Clientのようなクライアントと組み合わせるのが一般的です。

「速く出すか、緻密に握るか」という軸で見ると、Hasuraは前者に大きく振った道具だと位置づけられます。

よくある質問

Hasuraの導入検討でよく挙がる質問に、一次情報に基づいて回答します。

Hasuraは無料で使えますか？

はい、無料で使い始められます。v2 GraphQL Engineのコアエンジンも、DDN(v3)のコアエンジンも、データコネクタもApache License 2.0で公開されており、自己ホストすればライセンス費用はかかりません。マネージドのHasura DDNにもベースコストのかからないFreeプランがあります。商用で性能メトリクスやチーム協業機能、規制対応が必要になった段階で、Base・Advanced・Private DDNといった有償プランを検討する形になります。

HasuraとFirebaseの違いは何ですか？

最大の違いは、データベースの主導権の所在です。Firebaseはバックエンドをまとめて提供するBaaSで、データはGoogleが管理する基盤に乗ります。対してHasuraは、自分たちが用意した既存のリレーショナルデータベースをそのままGraphQL化する発想で、DBの選定と所在を握り続けられます。SQLや既存のデータ資産を活かしたい、データの所在を自社で管理したいという要件ではHasura、モバイル向けに認証やストレージまで一式を素早く揃えたいならFirebaseが向きます。

Hasura DDNとHasura v2のどちらを選ぶべきですか？

単一〜少数のデータベースを安定運用するなら、現行安定版のv2 GraphQL Engine(v2.49系)で要件を満たせます。複数データソースを1つのGraphQL APIに統合する「スーパーグラフ」、エッジでのグローバル配信、PromptQLによるAI連携まで見据えるなら、Rustで再設計されたDDNが選択肢です。すでにv2で問題なく動いている環境を、機能上の必要性がないまま移行する理由はありません。新規でマルチソース統合やAI連携が前提なら、最初からDDNで設計するのが合理的です。

HasuraはMySQLなどどのデータベースに対応していますか？

系統によって対応範囲が異なります。v2 GraphQL EngineはPostgreSQL、MS SQL Server、MySQL、BigQueryなど複数のデータベースに対応し、それらを単一のGraphQL APIへ束ねられます。DDN(v3)はGA時点でPostgreSQL系・MongoDB・ClickHouse・MS SQL Serverに対応し、NDC仕様に沿ったデータコネクタを追加することで対象を広げられます。さらにTypeScript・Python・Goのコネクタ用SDKを使えば、独自のデータソースやAPIをコネクタとして接続できます。

Hasura DDNのAI連携(PromptQL/MCP)では何ができますか？

自然言語で社内データを問い合わせ、分析・可視化までを行えます。PromptQLが質問から実行計画を立ててコードとして処理し、DDNのコネクタ経由でPostgreSQLやMySQL、SQL Serverのデータへ到達します。オープンソースのPromptQL MCPサーバを使えば、Claude DesktopなどのMCP対応クライアントからこの仕組みを呼び出せます。取得範囲はHasuraの権限モデルを継承するため、ユーザーごとに許可されたデータだけが返る点が、AIにデータを開くうえでの安全装置になります。

関連記事

• GraphQLをわかりやすく解説：基本概念と具体例：Hasuraが自動生成するGraphQLそのものの基礎を確認できます。
• GraphQLとREST APIの違いは何か？その主要な特徴を比較：自動生成APIの設計思想を理解する前提として有用です。
• Spring for GraphQLとは？基本概念と可観測性の重要性：GraphQLサーバを自前実装する代替手段の検討に役立ちます。
• Directusの主要な特徴と機能概要：柔軟なデータ管理を実現：DBをAPI化する類似ツールとの比較に使えます。
• Apollo Clientとは何か？その基本的な概念と役割について：生成したAPIをフロントエンドから扱う際の定番クライアントです。