Ethereum RPCとは？

2026年第1四半期、Ethereumネットワークは2億40万件のトランザクションを処理しました。前四半期比43%の増加です。ウォレットやDeFiプロトコルが行う残高照会、スマートコントラクトの呼び出し、トランザクションの送信は、そのすべてがRPCエンドポイントを経由しています。大規模なトラフィックの中でEthereum RPCが果たす役割とはまさにこのことです。アプリケーションとチェーンをつなぐインターフェースなのです。

RPCはRemote Procedure Call（リモートプロシージャコール）の略です。Ethereumの文脈では、ウォレット、取引所、DeFiプロトコルといったアプリケーションが、自身でノードを運用することなくEthereumノードと通信して結果を取得するための仕組みを指します。この通信を規定するプロトコルがJSON-RPCです。HTTPまたはWebSocket上でJSONオブジェクトとしてリクエストとレスポンスをやり取りする、軽量な標準規格です。

Ethereum上で開発するエンジニアにとって、RPCは飛ばしてよい細部ではありません。アプリケーションがブロックチェーンに触れる最も低いレイヤーです。Ethereumとやり取りするために使うライブラリ、フレームワーク、ツールは、その裏側ですべてJSON-RPC呼び出しを行っています。

Ethereum RPCの仕組み

Ethereum RPCはJSON-RPC 2.0仕様の上で動作します。ステートレスでトランスポートに依存しないプロトコルであり、ethereum.orgで管理・文書化されています。アプリケーションは、実行したい内容を記述したJSONオブジェクトを送信します。ノードがそれを処理し、JSONレスポンスを返します。

すべてのリクエストは同じ構造に従います。メソッド名（呼び出す操作）、params（入力値）、jsonrpcのバージョンフィールド、そしてレスポンスとリクエストを対応させるために自身で割り当てるidです。

ごくシンプルな例として、最新のブロック番号を照会してみます。

{
"jsonrpc": "2.0",
"method": "eth_blockNumber",
"params": [],
"id": 1
}

ノードは次の結果を返します。

{
"jsonrpc": "2.0",
"id": 1,
"result": "0x13f8a4c"
}

結果は16進数でエンコードされています。0x13f8a4cは10進数ではブロック20,939,852です。このパターンはすべてのメソッドで共通です。呼び出し内容を記述すると、ノードが現在のブロックチェーンの状態に対してそれを実行し、結果が返ってきます。

JSON-RPCがEthereumに適しているのは、そのシンプルさゆえです。このプロトコルはステートレスであり、持続的なセッションも、クライアントとサーバー間の継続的なネゴシエーションもありません。各リクエストは自己完結しています。そのため実装しやすく、キャッシュしやすく、デバッグも容易です。開発者はcurlだけでも任意のRPC呼び出しを再現できます。

準拠するすべての実行クライアントに共通する標準化されたメソッド一式を定義しているのがEthereum Execution API仕様です。メソッドは、接続先のノードがGeth、Nethermind、Besu、Erigonのどれであっても同じであり、どのRPCプロバイダーを使う場合も同じです。

Ethereum RPCの主要メソッド

以下は、最もよく使うことになるメソッドです。Ethereumアプリケーションに必要な中核的な操作、すなわち状態の読み取り、トランザクションの送信、イベントの照会、ブロックの検査をカバーしています。

• eth_blockNumber — 最新のブロック番号を返します。チェーンの同期状態の確認やブロックのポーリングに使います。
• eth_getBalance — 指定したブロック時点におけるアドレスのETH残高を返します。ウォレットの残高表示に使います。
• eth_call — トランザクションを生成せずに、読み取り専用のコントラクト呼び出しを実行します。コントラクトの状態読み取りに使います。ガスコストはかかりません。
• eth_sendRawTransaction — 署名済みでシリアライズされたトランザクションをブロードキャストします。ETHの送金、ERC-20トランスファー、コントラクトへの書き込みに使います。
• eth_getTransactionByHash — ハッシュでトランザクションの詳細を返します。送信済みトランザクションの追跡に使います。
• eth_getTransactionReceipt — 確認済みトランザクションのレシートを返します。成功の確認や、発行されたログの読み取りに使います。
• eth_getLogs — アドレス、トピック、ブロック範囲によるフィルターに一致するログを返します。コントラクトイベントのリスニングに使います。
• eth_getBlockByNumber — ブロック番号またはタグでブロックの詳細を返します。インデックス作成やチェーン分析に使います。
• eth_estimateGas — トランザクションに必要なガスを見積もります。送信前の事前チェックに使います。
• net_version — 現在のネットワークIDを返します。メインネットとテストネットの区別に使います。

eth_callはコントラクトデータを読み取るためのメソッドです。ノードの現在の状態に対して呼び出しをシミュレートし、ネットワークに何もブロードキャストせずに結果を返します。署名は不要で、ガスも消費されません。ビュー関数（トークン残高、プールのリザーブ、価格データなど）を照会するとき、裏で動いているのはeth_callです。

eth_sendRawTransactionは書き込み用です。トランザクションをクライアント側で構築・署名し、シリアライズして、署名済みのバイト列を送信します。ノードは署名を検証し、トランザクションをメモリプールへブロードキャストします。署名をクライアント側で行い、ブロードキャストをノードに任せるという分離は意図的なものです。秘密鍵がアプリケーションの外に出ることはありません。

eth_getLogsは強力ですが、ある程度の節度が求められます。アクティブなコントラクトに対する広範囲のブロッククエリは、パブリックエンドポイントではコストが高くなり、レート制限に達するおそれがあります。コントラクトアドレスと特定のイベントトピックでフィルターし、範囲を区切ってクエリしてください。

Ethereum RPCエンドポイントへの接続方法

Ethereum RPCへの接続は、結局のところURLひとつに行き着きます。どのプロバイダーも、登録時にURLを発行します。

https://rpc.yourprovider.com/YOUR_API_KEY

このURLに対して直接生のHTTP POSTリクエストを送ることもできますし、ライブラリに渡すこともできます。ethers.jsを使ったシンプルな例がこちらです。

const { ethers } = require("ethers");

const provider = new ethers.JsonRpcProvider("https://rpc.yourprovider.com/YOUR_API_KEY");

async function getBalance(address) {
const balance = await provider.getBalance(address);
console.log(ethers.formatEther(balance), "ETH");
}

getBalance("0xYourAddressHere");

依存関係を最小限に抑え、透明性を最大限に高めたい場合は、素のfetchでも同じことができます。

const response = await fetch("https://rpc.yourprovider.com/YOUR_API_KEY", {
method: "POST",
headers: { "Content-Type": "application/json" },
body: JSON.stringify({
jsonrpc: "2.0",
method: "eth_blockNumber",
params: [],
id: 1
})
});

const data = await response.json();
console.log(parseInt(data.result, 16)); // current block number as decimal

ノードのインストールも、同期の待ち時間も不要です。アプリケーションをエンドポイントURLに向けるだけで、Ethereumメインネット（またはプロバイダーが対応する任意のテストネット）に完全にアクセスできます。

パブリックとプライベート：Ethereum RPCエンドポイントの選択

Ethereum RPCエンドポイントを入手する方法は2つあります。サードパーティサービスが提供するものを使うか、自分で運用するかです。

パブリックエンドポイントは、ノードインフラを代わりに運用・管理するプロバイダーがホストします。登録してAPIキーを受け取り、接続するだけです。運用の負担はプロバイダー側にあります。ほとんどの開発作業と幅広い本番デプロイにおいて、これが現実的な選択肢です。数分で稼働でき、ローカルノードの管理は不要で、Ethereumクライアントソフトウェアの進化に伴うアップグレードもプロバイダーが処理してくれます。

トレードオフはレート制限です。パブリックエンドポイントは共有インフラであるため、広範囲のeth_getLogs呼び出しや、人気アプリケーションからのバーストトラフィックといった大量クエリは、スロットリングされる場合があります。ほとんどのプロバイダーは、スケールに応じてより高いレート制限を備えた段階的なプランを提供しています。

プライベートエンドポイントとは、自分でEthereumノードを運用することです。見返りは完全なコントロールです。レート制限はなく、サードパーティの稼働率に依存せず、アーカイブデータに完全にアクセスでき、要件に合わせてノードを細かく設定できます。コストは運用面にあります。フルのEthereumノードには、大きなストレージ（すべての履歴状態を保持するアーカイブノードなら数テラバイト）、安定したメモリと計算資源、そしてクライアントソフトウェアの進化に伴う継続的なメンテナンスが必要です。

このアーキテクチャの選択は恒久的なものではありません。多くのチームはパブリックエンドポイントから始めて製品を検証し、規模や固有の要件がそれを正当化する段階でプライベートインフラへ移行します。

Ethereum RPCとWebSocket：どちらを使うべきか？

HTTPとWebSocketは、いずれもJSON-RPCのトランスポート選択肢です。それぞれ適したユースケースが異なるため、どちらかに決める前に違いを理解しておく価値があります。

HTTP RPCはリクエスト・レスポンス型です。アプリケーションがリクエストを送り、結果を受け取り、接続が閉じます。設計上ステートレスです。Ethereumとのやり取りの大半（残高照会、トランザクション送信、コントラクトの読み取り、ブロック照会）には問題なく機能します。アプリケーション側から呼び出してレスポンスを処理する形であれば、HTTPが適切なデフォルトです。取り扱いがシンプルで、キャッシュやデバッグも容易です。

WebSocketは、アプリケーションとノードの間に持続的な双方向接続を維持します。これによりサブスクリプションが可能になります。アプリケーションはノードに「新しいブロックが到着したら知らせて」「このコントラクトがこのイベントを発行したら知らせて」と伝えることができ、ノードが発生した更新をプッシュしてくれるため、アプリケーションがポーリングする必要がありません。該当するメソッドはeth_subscribeで、これはWebSocket経由でのみ利用できます。

実務上の指針としては、まずHTTPから始めることです。新しいブロックを検出するためにeth_blockNumberを繰り返しポーリングしていたり、ループでトランザクションレシートをポーリングしていたりする場合は、そのやり取りをWebSocketのサブスクリプションに移すサインです。両方を並行して使うこともできます。オンデマンドのクエリはHTTP、イベントのリスニングはWebSocketという具合です。

無料のEthereum RPCエンドポイント：何を確認すべきか

本番グレードのプロバイダーの大半は無料ティアを提供しています。それぞれの状況は以下のとおりです。

• Infura — ConsenSysが後援し、MetaMaskとの直接統合を備える。無料ティアあり。登録開発者は40万人以上。
• Alchemy — 手厚い無料ティア（月間約3,000万コンピュートユニット）。トランザクションシミュレーションを含む拡張開発者API。
• QuickNode — 主要プロバイダーの中で公開ベンチマーク上最も低いレイテンシ（世界平均約86ms）。堅実なコンプライアンス体制。
• CoinsDo — 無料のEthereum RPCエンドポイントを提供。初期費用はなく、開始にクレジットカードも不要です。製品が実証される前から課金を気にせずテストと反復を行いたい開発者のために作られています。

無料ティアは実際に存在し、実用に耐えます。プロバイダーによって異なるのは上限の位置です。1秒あたりのリクエスト数、日次リクエスト制限、アーカイブデータの有無、そしてWebSocketサポートの内容です。

本番向けにプロバイダーを選ぶ前に、3点を確認してください。想定リクエスト量に対するレート制限、アプリケーションが履歴クエリを必要とする場合のアーカイブデータの可用性、そして稼働率保証に関するSLA条項です。アプリケーションがレイテンシに敏感であれば、レイテンシも重要です。ベンチマークはプロバイダーによって異なり、地理的条件も結果に影響します。

開発の初期段階では、CoinsDoの無料RPCエンドポイントは扱いやすい選択肢です。開始時の障壁がなく、本番アーキテクチャの方向性が固まる前に有料プランへのコミットを迫られることもありません。

よくある質問

Ethereum RPCノードとRPCエンドポイントの違いは何ですか？

ノードとは、ブロックチェーンを実行するEthereumクライアントソフトウェア（Geth、Nethermind、Besu、Erigonなど）のことです。ブロックの同期、トランザクションの検証、状態の維持を行います。RPCエンドポイントとは、そのノードと通信するために使うネットワーク上のアドレスです。CoinsDo、Infura、Alchemyなどのパブリックプロバイダーを利用する場合、ノードを運用するのはプロバイダー側であり、あなたにはエンドポイントURLが提供されます。

Ethereum RPCは無料ですか？

パブリックプロバイダー経由であれば、はい。主要プロバイダーの大半は、開発および中規模の本番利用に十分なスループットを備えた無料ティアを提供しています。CoinsDoはクレジットカード不要の無料エンドポイントを提供しています。有料プランでは、アプリケーションのスケールに応じてより高いレート制限や追加機能を利用できます。

EthereumメインネットのデフォルトRPC URLは何ですか？

普遍的なデフォルトは存在しません。Ethereumには標準で組み込みのパブリックエンドポイントが付属していません。プロバイダー（Infura、Alchemy、QuickNode、CoinsDo）が運用するエンドポイントか、自分で運用するノードに接続します。URLの形式はプロバイダー固有であり、APIキーが含まれます。

Ethereum RPCとWebSocketの違いは何ですか？

HTTP RPCはステートレスなリクエスト・レスポンス型で、アプリケーションはリクエストを送って結果を受け取ります。WebSocketは持続的な接続を維持し、eth_subscribeによるサブスクリプションに対応しているため、ノードは新しいブロックやコントラクトイベントなどのリアルタイム更新を、ポーリングなしでアプリケーションにプッシュできます。オンデマンドのクエリにはHTTPを、リアルタイムのイベント通知が必要な場合にはWebSocketを使いましょう。

ノードを運用せずにEthereum RPCを使えますか？

はい。それこそがパブリックRPCエンドポイントの中核機能です。ノードインフラはプロバイダーが運用し、アプリケーションはそのエンドポイントURLに接続します。クライアントのインストール、チェーン同期の待機、ローカルストレージの管理なしに、Ethereumメインネットに完全にアクセスできます。

eth_callは何をするメソッドですか？

eth_callは、スマートコントラクトに対する読み取り専用の呼び出しを実行します。ノードの現在の状態に対してコントラクトコードを実行し、トランザクションを生成せず、ネットワークに何もブロードキャストせずに結果を返します。ガスコストもオンチェーンの状態変更もありません。コントラクトからデータを読み取る必要があるとき（トークン残高、プール価格、ガバナンス状態、ビュー関数やpure関数経由で公開されているあらゆるデータ）は、常にこれを使いましょう。