Graph Node でブロックチェーンのデータを GraphQL で提供する仕組みと運用の実態
Graph Node は、Ethereum などのブロックチェーンからのデータにインデックスを付け、それを GraphQL 経由で提供します。
ひと目でわかる
- これは何？
- The Graph のコアコンポーネントである Graph Node は、イーサリアムなどのブロックチェーン上のデータを Subgraph として索引化し、GraphQL で公開する Rust 製のソフトウェアです。本稿では、その仕組み、起動手順、制約、そして代替案との比較を通して、採用判断に必要な情報を整理します。
- 誰に向いている？
- Graph Node は、Subgraph 開発者がローカルで索引化をテストする用途と、The Graph プロトコルに参加してデータを提供したい運用者に向いています。一方、単一チェーンの小規模なデータを扱うだけなら、運用コストに見合わない可能性があります。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 21 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
ブロックチェーンの生データを扱う苦労を解消する索引化レイヤー
イーサリアムのようなブロックチェーンから必要なデータを取り出そうとすると、スマートコントラクトのイベントを監視し、ログを解析し、状態を組み立てる処理を自前で書くことになります。Graph Node はこの処理を Subgraph と呼ばれる定義ファイルに基づいて自動化し、結果を GraphQL エンドポイントとして提供します。対象は Subgraph 開発者と、Graph Node 自体に貢献したい開発者です。README は、まず公式ドキュメントで Subgraph の概念を理解するよう強く推奨しています。
Subgraph の定義から GraphQL 公開までのデータフロー
Graph Node は、Subgraph のマニフェストに従って、指定されたイーサリアムの RPC エンドポイントからブロックデータを取得します。取得したデータは、PostgreSQL に保存され、GraphQL スキーマとして公開されます。このとき、RPC エンドポイントには能力の指定が必要です。たとえば `mainnet:archive,traces:https://provider.io/some/path` のように、ネットワーク名、能力、URL をコロンで区切って渡します。archive と traces は、履歴データとトランザクショントレースを必要とする Subgraph にとって重要です。データの流れは、ブロックチェーンから RPC 経由で Graph Node に取り込み、PostgreSQL に蓄積し、GraphQL で検索可能にする、という単純な一方通行ではありません。索引化の進捗管理や再編成への対応も内部で行われますが、README からは詳細を確認できません。
Docker とソースからの2つの起動経路
Subgraph 開発者は、Docker イメージを使うのが推奨されています。docker/README.md に手順がまとまっています。ソースからビルドする場合は、Rust の最新安定版、PostgreSQL、IPFS、Protobuf コンパイラが必要です。データベースの初期化では、`create user graph with password '<password>';` に続いて、`create extension pg_trgm;`、`create extension btree_gist;`、`create extension postgres_fdw;` を実行します。postgres_fdw は外部データベースへの接続に使うもので、複数データベース構成の土台です。起動コマンドは次の形です。`cargo run -p graph-node --release -- --postgres-url $POSTGRES_URL --ethereum-rpc NETWORK_NAME:[CAPABILITIES]:URL --ipfs 127.0.0.1:5001`。起動後は、デフォルトで `http://localhost:8000` で GraphQL サーバーが待ち受けます。
ログの保存と検索は GraphQL から行う
Graph Node は、Subgraph のログを複数のバックエンドに保存できます。ファイル、Elasticsearch、Loki、無効、の4つです。デフォルトは無効で、ローカル開発にはファイルバックエンドが推奨されています。ファイルバックエンドを使うには、`--log-store-backend file` と `--log-store-file-dir ./graph-logs` を指定します。ログの検索は、GraphQL の `_logs` クエリで行います。たとえば `query { _logs(subgraphId: "QmYourSubgraphHash", level: ERROR, first: 10) { timestamp level text } }` のように実行します。ログを GraphQL で統一的に扱えるのは便利ですが、Elasticsearch や Loki を本番で使う場合は、それらの運用コストが追加で発生します。
大規模構成では設定ファイルと複数データベースが必要になる
README は、複数のチェーンに接続する場合や、索引化とクエリ処理を複数のデータベースに分割する場合には、設定ファイルを使う必要があると説明しています。環境変数も用意されていますが、詳細は docs/environment-variables.md にあります。つまり、小規模な開発環境ではコマンドライン引数で足りますが、本番運用でスケールさせるには、設定ファイルによる管理が前提になります。この分割構成は、postgres_fdw の拡張機能を最初に有効にしておく理由でもあります。
Rust と PostgreSQL に依存する運用コスト
Graph Node をソースからビルドする場合、Rust の最新安定版が必要です。README は、このディレクトリで `rustup install stable` を実行するよう指示しています。つまり、特定のバージョンに固定するのではなく、常に最新の安定版を追従する方針です。これは、依存クレートの更新に伴うビルドの破損リスクを常に抱えることを意味します。また、PostgreSQL の拡張機能を複数導入する必要があり、データベースの管理は避けられません。ライセンスは MIT と Apache-2.0 のデュアルライセンスです。商用利用は可能ですが、ライセンス表示などの条件は各ライセンスに従う必要があります。
代替案: 自前のインデクサーとサブグラフの手動実装
Graph Node を使わない選択肢として、自前でブロックチェーンのイベントを監視し、データベースに保存して API を公開する方法があります。この場合、ブロックの再編成への対応、トランザクションのトレース解析、GraphQL スキーマの設計をすべて自分で実装することになります。Graph Node はこれらの処理を抽象化してくれますが、その代わりに PostgreSQL と IPFS という外部依存が発生します。小規模で単一チェーンだけを扱うなら、自前実装のほうが運用は軽いかもしれません。ただし、Subgraph として公開されている既存の定義を再利用したい場合は、Graph Node が標準の実行環境であるため、採用しやすくなります。
編集部の結論
Graph Node は、Subgraph 開発者がローカルで索引化をテストする用途と、The Graph プロトコルに参加してデータを提供したい運用者に向いています。一方、単一チェーンの小規模なデータを扱うだけなら、運用コストに見合わない可能性があります。採用を検討する際は、まず Docker イメージでローカル環境を構築し、対象チェーンの RPC が archive と traces の能力を満たすか確認してください。本番運用では、PostgreSQL の拡張機能と複数データベースの構成が必須になるため、ドキュメントの config.md を事前に読むことを推奨します。
コミュニティノート