要約：RPCエンドポイントとは、アプリケーションがブロックチェーンノードと通信するために使用するURLのことです。RPCは「リモート・プロシージャ・コール（Remote Procedure Call）」の略で、あるプログラムがネットワークを介して別のプログラムにデータや処理を要求するためのプロトコルです。ブロックチェーンにおいて、RPCエンドポイントは、ウォレットが残高を確認したり、dAppがスマートコントラクトを実行したり、開発者がオンチェーンデータを読み書きしたりするための手段となります。ユーザーが意識しているかどうかに関わらず、ブロックチェーンとのあらゆるやり取りは、RPCエンドポイントを経由して行われます。
わかりやすい説明
ウォレットアプリを開いてETHの残高を確認するとき、そのウォレットが何らかの形でブロックチェーン「上」にあるわけではありません。それは、スマートフォンやブラウザ上で動作する通常のアプリケーションであり、残高を確認するためにブロックチェーンに問い合わせる必要があります。その問い合わせを行うために、アプリはRPCエンドポイントにリクエストを送信します。エンドポイントがリクエストを受信すると、その背後にあるノードが回答を検索し、レスポンスを返します。その後、ウォレットがその結果を表示します。
RPCエンドポイントを、レストランの正面玄関のようなものと考えてみてください。厨房（ブロックチェーンノード）は、トランザクションの検証、状態の維持、ブロックの生成といった実際の作業が行われる場所です。しかし、厨房に直接入ることはできません。正面玄関（RPCエンドポイント）から入り、注文（リクエスト）をすると、ウェイター（RPCプロトコル）が料理（レスポンス）を運んでくるのです。 RPCエンドポイントは、ノードの機能を外部に公開するためのアクセスポイントです。
技術的な用語で言えば、RPCエンドポイントとは、アプリケーションがJSON-RPC仕様に従ってフォーマットされたHTTPまたはWebSocketリクエストを送信するURL（例：https://your-endpoint.quiknode.pro/your-token/）のことです。JSON-RPCは、リクエストとレスポンスをJSONオブジェクトとしてどのように構成するかを定義する軽量なプロトコルです。 主要なブロックチェーンはすべて、この標準の何らかのバージョンを採用しています。つまり、イーサリアムでRPC呼び出しを行う方法を一度理解すれば、Solana、Polygon、Arbitrum、Base、その他数十のチェーンでも同様のパターンが適用されます。
RPC呼び出しの仕組み
一般的な RPC 通信は、単純なリクエスト・レスポンスのパターンに従います。アプリケーションは、呼び出したいメソッドと必要なパラメータを指定した JSON-RPC リクエストを作成し、HTTP POST を使用してエンドポイント URL に送信します。ノードはリクエストを処理し、対応するロジックを実行した後、結果を JSON 形式のレスポンスとして返します。
たとえば、EVMチェーンの最新のブロック番号を取得するには、アプリケーションがメソッド「eth_blockNumber」と空のパラメータ配列を含むリクエストを送信します。ノードは、現在のブロック番号を16進数で返します。アカウントのETH残高を確認するには、ウォレットアドレスとブロックパラメータ（現在のブロックの場合は「latest」など）を指定して「eth_getBalance」を呼び出します。 トランザクションを送信するには、署名済みのトランザクションデータを引数として「eth_sendRawTransaction」を呼び出します。
これらの標準的なJSON-RPCメソッドは、各ブロックチェーンの仕様によって定義されています。イーサリアムのJSON-RPC APIには、ブロックデータの読み取り、アカウントやコントラクトの状態の照会、ガスの見積もり、トランザクションの送信、WebSocketを介したイベントの購読などを行うためのメソッドが含まれています。ソラナは、アカウントベースのアーキテクチャに最適化された、類似しているが独自のRPCメソッドセットを採用しています。各チェーンには独自のAPIインターフェースがありますが、RPCエンドポイントを通じた基盤となる通信パターンは一貫しています。
WebSocket接続は、基本的なRPCパターンを拡張したもので、リアルタイムの双方向通信を可能にします。アプリケーションがノードに対して更新情報を繰り返しポーリングする（これは非効率的で時間がかかります）代わりに、WebSocket接続を利用することで、ノードが新しいデータをアプリケーションにプッシュできるようになります。
アプリケーションのリアルタイムな動作。これは、新しいブロックが生成されるのを監視したり、特定のスマートコントラクトのイベントをリアルタイムで監視したり、トランザクションの確認通知を受け取ったりといったユースケースにおいて不可欠です。
パブリック RPC エンドポイントとプライベート RPC エンドポイント
パブリックRPCエンドポイントは、ブロックチェーン財団やコミュニティプロジェクトによって管理されている、無料で公開されているURLです。認証なしで誰でも接続できます。これらは、簡単なテスト、プロトタイピング、教育目的には有用ですが、本番環境のアプリケーションには適していません。パブリックエンドポイントは、厳しいレート制限（1秒あたりに送信できるリクエスト数に制限があること）が課されており、数千人の同時ユーザーによって頻繁に過負荷状態になり、稼働時間、レイテンシ、データの鮮度については一切保証されません。 アプリケーションがパブリックエンドポイントに依存しており、トラフィックの急増時にそのエンドポイントがダウンした場合、アプリケーションも同様にダウンしてしまいます。
プライベートRPCエンドポイントは、通常はインフラストラクチャサービスによって提供される、アプリケーション専用に確保された接続です。これらは、より高速な応答時間、より高いレート制限、安定したパフォーマンス、およびSLAに基づく稼働時間の保証を提供します。プライベートエンドポイントには、トークンベースの認証、IPホワイトリスト、分析ダッシュボード、標準のJSON-RPC仕様を超える拡張APIへのアクセスなど、追加機能が含まれていることがよくあります。
実際のユーザー、実際の資金、あるいはリアルタイムデータを扱うアプリケーションにおいては、プライベートRPCエンドポイントは「追加機能」ではなく、必須の要件です。本番環境におけるパブリックエンドポイントとプライベートエンドポイントの違いは、共有の公衆Wi-Fiネットワークと専用光ファイバー回線の違いに例えられます。どちらも技術的にはインターネットに接続できますが、ビジネスを運営するのに適しているのはそのうちの1つだけです。
基本的なRPCを超えて
標準的なJSON-RPCメソッドは、ブロックチェーンデータの読み書きという基本機能をカバーしていますが、実稼働環境のアプリケーションのほとんどには、それ以上の機能が必要です。拡張APIは、基本となるRPC仕様を拡張し、データを集約してアプリケーションが必要とする呼び出し回数を削減する、より高レベルなメソッドを提供します。例えば、ウォレットのトークン保有状況を再構築するために数十回もの個別の呼び出しを行う代わりに、拡張APIであれば、1回のリクエストですべてのトークン残高を取得することができます。
ストリーミングおよびイベント駆動型アーキテクチャは、リクエスト・レスポンス型のRPCを超えた次の進化形です。アプリケーションがRPCエンドポイントに対して新しいブロックやイベントがあるかどうかを絶えずポーリングする代わりに、ストリーミングサービスはデータが利用可能になり次第、アプリケーションにデータをプッシュします。これにより、レイテンシが低減され、無駄なリクエストが排除され、バックエンドアーキテクチャが簡素化されます。
gRPCは、特定のブロックチェーンにおいて、JSON-RPCと併用される、あるいはその代わりとして使用されるもう1つのプロトコルです。例えば、SolanaのYellowstone gRPCは、トレーディングボットやリアルタイム分析といった高頻度なユースケース向けに最適化された、超低遅延のデータ配信を実現しています。gRPCはJSONの代わりにProtocol Buffersを使用しており、Protocol Buffersはよりコンパクトでシリアライズも高速であるため、遅延が1ミリ秒単位で重要となるアプリケーションに最適です。
Quicknodeの役割
QuicknodeのCore APIは、80以上のブロックチェーンネットワークにわたって、本番環境レベルのRPCエンドポイントを提供します。Quicknodeでエンドポイントを作成すると、HTTPSおよびWebSocketのURLが発行され、これによりアプリケーションを、世界中に分散した高性能なノードインフラストラクチャに接続できます。このインフラストラクチャは、99.99%の稼働率を保証するSLAを備え、平均して競合他社よりも2.5倍高速な応答時間を実現しています。 すべてのエンドポイントには、完全なデータおよびアーカイブデータへのアクセス、リアルタイム分析、トークンベースの認証、ならびにリファラーのホワイトリスト登録やドメインマスキングなどのセキュリティ機能が含まれています。
Quicknodeは、標準的なRPCにとどまらず、リアルタイムおよび過去のブロックチェーンデータ配信を実現する「Streams」、超高速なSolanaデータを提供する「Yellowstone gRPC」、DeFiデータ、NFT API、セキュリティツール向けの「Marketplace」アドオンエコシステム、そしてJavaScriptやTypeScriptでのシームレスな統合を可能にする「Quicknode SDK」を通じて、開発者の体験をさらに拡充しています。 週末のプロジェクトで単一のエンドポイントが必要な場合でも、エンタープライズプラットフォーム向けのマルチチェーン・マルチリージョンインフラストラクチャが必要な場合でも、Quicknodeはあらゆる基盤となるRPCレイヤーを提供します。
RPCエンドポイントとノードの違いは何ですか？
これらの用語は関連していますが、同一ではありません。ノードとは、ブロックチェーンのコピーを保持し、トランザクションを検証し、状態を追跡するソフトウェアのことです。RPCエンドポイントとは、そのノードと通信するために接続するネットワークアドレスのことです。1つのノードが複数のエンドポイントの背後に配置されることもあり、また、1つのエンドポイントが冗長性を確保するために、負荷分散されたノード群全体にリクエストをルーティングすることもあります。マネージドプロバイダーを利用する場合、エンドポイントとやり取りするだけで、自分でノードを運用する必要は一切ありません。 URLの背後で何が実行されているかについて詳しく知りたい場合は、「ブロックチェーンノードとは」を参照してください。また、リクエストのライフサイクル全体については、「RPCリクエストの仕組み」を参照してください。
HTTP、WebSocket、gRPC――どのRPCトランスポートを使うべきか？
RPCエンドポイントは複数のトランスポートを提供しており、適切な選択は、単発のクエリを行うのか、それとも継続的なデータフィードを利用するのかによって異なります。HTTPは、リクエスト・レスポンス型の呼び出しにおける普遍的なデフォルトです。WebSocketは永続的な接続を維持するため、ノードから更新情報をプッシュ受け取ることができます。gRPCは、対応しているチェーン上で高頻度のワークロードに対して、最も低いレイテンシを実現します。以下の表では、これら3つを一覧で比較しています。
輸送 | 接続モデル | こんな方に最適 | トレードオフ |
|---|---|---|---|
HTTP | ステートレスなリクエストとレスポンス | 標準的な読み取り、トランザクションの送信、バッチ呼び出し | サーバーからのプッシュ通知はないため、更新の有無をポーリングする必要があります |
WebSocket | 持続的、双方向 | 新しいブロック、ログ、および保留中のトランザクションへのサブスクリプション | 接続は維持し、切断された場合は再接続する必要があります |
アプリケーションで、繰り返しポーリングを行うのではなく、継続的なデータ配信が必要な場合、QuicknodeStreamsのようなマネージド・ストリーミング・レイヤーを利用すれば、ソケットのライフサイクルを管理することなく、ブロック、レシート、トレースをバックエンドに直接配信することができます。
RPCエンドポイントの遅延やレート制限は、どのような原因で発生するのでしょうか？
RPCエンドポイントの利用体験を左右する要因として、最も一般的なのは「応答速度」と「許容リクエスト数」の2つです。 レイテンシは、ノードまでの地理的な距離、呼び出すメソッドの複雑さ、および基盤となるインフラストラクチャの負荷状況によって左右されます。レート制限が存在するのは、すべてのノードには有限の処理能力があるためであり、プロバイダーは共有リソースを保護するために1秒あたりのリクエスト数に上限を設けています。これら両方を理解することで、トラフィックが増加する前にエンドポイントの規模を適切に設定することができます。詳細については、「RPCのレイテンシとは」および「RPCのレート制限とは」をご覧ください。
生のRPCの代わりにインデックス化をいつ使用すべきか？
生のRPCは、現在の状態の読み取りやトランザクションの送信には理想的ですが、「このウォレットが過去1年間に実行したすべての送金」といった分析的なクエリには対応が困難です。 RPCだけでこれに答えるには、何千回もの連続した呼び出しが必要になります。インデックス化では、オンチェーンデータをクエリ可能なデータベースに前処理することでこの問題を解決し、履歴データや集計データの検索を単一のクエリで実行できるようにします。「RPCとインデックス化」で2つのアプローチを比較し、ブロックチェーンデータのクエリにおいて大規模なクエリがなぜ難しいのかをご確認ください。
よくある質問
RPCとは何の略ですか？
RPC は「リモート・プロシージャ・コール（Remote Procedure Call）」の略です。これは、あるプログラムが、あたかもローカルの関数を呼び出すかのように、ネットワークを介して別のプログラムにデータの取得を要求したり、アクションを実行させたりできるプロトコルです。ブロックチェーンでは、アプリケーションは RPC を使用して、ノードに状態の読み取りやトランザクションの送信を依頼します。
RPCエンドポイントとAPIは同じものですか？
RPCエンドポイントは、APIの一種です。これは、単一のURLを通じて、JSON-RPC標準に基づいてブロックチェーンノードの機能を公開するものです。多くのプロバイダーは、基本的なRPCインターフェースの上に、拡張されたRESTやより高レベルのAPIを重ねていますが、中核となるエンドポイントは、ノードが理解できるJSON-RPCプロトコルで通信を行うものです。
無料のパブリックRPCエンドポイントは、本番環境で安全に使用できますか？
これらはテストや学習には適していますが、本番環境向けには設計されていません。パブリックエンドポイントは厳格なレート制限が課されており、頻繁に過負荷状態になり、稼働時間やレイテンシの保証もありません。トラフィックが急増した際にパブリックエンドポイントのパフォーマンスが低下すると、アプリケーションのパフォーマンスもそれに伴って低下してしまいます。そのため、本番環境のアプリケーションでは専用のプライベートエンドポイントが利用されています。
1つのRPCエンドポイントで複数のブロックチェーンに接続することは可能ですか？
通常、1つのエンドポイントURLは、イーサリアムメインネットやソラナメインネットなど、1つのネットワークに対応しています。複数のチェーンに対応するには、ネットワークごとに個別のエンドポイントを作成します。ほとんどのチェーンはJSON-RPCのパターンを共有しているため、あるエンドポイント用に作成したコードは、わずかな変更を加えるだけで他のエンドポイントにも流用できることが一般的です。
絶えずポーリングを行わずに、オンチェーンのイベントについて通知を受けるにはどうすればよいですか？
ポーリングの代わりにプッシュ型の仕組みを利用しましょう。WebSocketのサブスクリプションや、Quicknode Webhooksなどのイベント駆動型サービスは、関連するブロックやイベントが発生した瞬間にバックエンドに通知するため、レイテンシを低減し、無駄なリクエストを排除できます。ステップバイステップのチュートリアルについては、『Builders Guide』で一般的なパターンについて詳しく解説しています。
参考資料
Quicknode Core API
Quicknode API ドキュメント
Quicknode 製品紹介
ストリームの始め方- Quicknode ドキュメント
