ERC-4337とは｜仕組みと4コンポーネントの役割を事業者向けに解説
約20分で読めます
約20分
目次（タップで折りたたみ）
ERC-4337（仕様）とは、Ethereum本体のプロトコルを変えずに、スマートコントラクトをユーザーのアカウント（スマートアカウント）として使えるようにする標準です。ユーザーの操作をUserOperationという専用の形式で表現し、それを検証・実行するEntryPoint・Bundler・Paymasterという共通の処理経路を定義することで、ガス代（取引手数料）の事業者による肩代わり、passkey（生体認証で使えるWebAuthn系の公開鍵認証）でのログイン、複数操作の一括実行を、従来のEOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント）ではできなかった形で実現します。2023年3月にEthereumメインネットで稼働を開始し、2026年8月時点で累計約12.4億件のUserOperationが処理された、実運用段階のインフラです（BundleBear、2026年8月11日閲覧）。
本記事は、ERC-4337を構成する4つのコンポーネント（EntryPoint・Bundler・Paymaster・Smart Account）の役割、UserOperationが署名から実行完了までにたどる流れ、2026年時点のEntryPointバージョンと普及の実数、そして事業者がどの層を自社で担うかの判断を、一次情報に基づいて整理します。アカウントアブストラクション（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移す技術群。以下AA）全体の俯瞰と採用形態の判断はAA完全マップ2026で扱っているため、本記事はERC-4337という規格そのものの理解に集中します。
ERC-4337は何を解決するのか — EOAの4つの制約
Ethereumのアカウントには、秘密鍵で直接操作するEOAと、プログラムとして動くコントラクトアカウントの2種類があります。従来、ユーザーのウォレットとして使えるのは事実上EOAだけでした。EOAには次の4つの制約があります。
- 鍵の喪失＝資産の喪失：署名鍵がアカウントそのものであるため、シードフレーズを失えば復元手段がなく、盗まれれば資産を守れません。リカバリの仕組みをプロトコル側に組み込めません。
- ガス代は本人がETHで払うしかない：ステーブルコインしか持たないユーザーでも、送金にはETHの事前入手が必要です。事業者が肩代わりする標準的な方法もありません。
- 署名方式がECDSA一択：スマートフォンの生体認証（passkey）やマルチシグなど、用途に合った認証方式をアカウント自体に組み込めません。
- 複数操作をまとめられない：「承認してからスワップ」のような一連の操作が複数トランザクションに分かれ、その都度署名とガス代が発生します。
スマートコントラクトをアカウントにできれば、署名の検証ルール・リカバリ・支払い方法をコントラクトのコードとして自由に設計でき、この4つはすべて解決します。課題は「秘密鍵を持たないコントラクトが、誰のガス負担で、どうやってトランザクションを開始するか」でした。Ethereum本体を改修してこれを解く提案（EIP-86、EIP-2938など）は、コンセンサス層の変更を伴う重さから実現に至りませんでした。
ERC-4337は2021年9月にVitalik Buterinらが提案した、プロトコルを一切変えずにコントラクトとオフチェーンインフラの組み合わせだけでこれを解く設計です。仕様の正式名称「Account Abstraction Using Alt Mempool」が示すとおり、通常のトランザクションとは別の代替mempool（未処理取引の待機領域）を用意し、そこを流れるUserOperationを共通コントラクトが検証・実行します。プロトコル変更が不要なため、EthereumだけでなくEVM互換チェーンやLayer 2（Ethereumの処理を肩代わりして高速・低コスト化する二層目のチェーン。以下L2）へも同じ仕組みをそのまま展開でき、これが後述する普及の実数につながっています。
4つのコンポーネントの役割 — 自社で持つ層と共有インフラ
ERC-4337の全体像は、4つのコンポーネントと1つのデータ形式（UserOperation）で説明できます。事業者の設計判断は「どのコンポーネントを自社で持ち、どれを外部に任せるか」に集約されるため、まず役割と運用者を対応させます。
| コンポーネント | 役割 | 誰が運用するか |
|---|---|---|
| EntryPoint | すべてのUserOperationの検証・実行・ガス精算を行う単一窓口 | 共有インフラ（eth-infinitismが開発し、外部監査を受ける。自社実装の対象外） |
| Smart Account | ユーザーのアカウントとして機能するコントラクト本体 | ウォレット・サービス事業者（差別化の中心） |
| Bundler | UserOperationを集めてEntryPointへ投入する中継ノード | SaaS事業者または自社ノード |
| Paymaster | ガス代の支払いをユーザー本人から差し替える仕組み | 事業者（ガスレスを提供する場合のみ） |
UserOperationはコンポーネントではなく、この経路を流れる取引データの形式です。以下、それぞれの動きを見ていきます。
EntryPoint — 検証・実行・精算の単一窓口
EntryPointは、チェーンごとにバージョン単位で同一アドレスにデプロイされる共通コントラクトで、ERC-4337のすべての取引がここを経由します。役割は3つです。第一に検証：各UserOperationについてSmart Accountに署名とnonce（リプレイ攻撃防止の連番）の確認を問い合わせ、Paymaster指定があればその支払い能力も確認します。第二に実行：検証を通過したUserOperationの内容をSmart Accountに実行させます。第三にガス精算：実際に消費したガス代をSmart AccountまたはPaymasterの預託金から差し引き、立て替えたBundlerへ支払います。
EntryPointの参照実装は、ERC-4337の提案者らが主導する開発チームeth-infinitismが開発し（eth-infinitism/account-abstraction）、OpenZeppelin・Spearbit・Cantinaなどによる外部セキュリティ監査を受けています（監査レポート一覧）。全参加者が同じコントラクトを共有することが安全性と互換性の前提であるため、事業者が自前のEntryPointを作ることは想定されていません。事業者にとってEntryPointは実装対象ではなく、「どのバージョンに対応したAccount実装・Bundlerを組み合わせるか」という制約条件です（バージョンの系譜は後述）。
UserOperation — 取引意図を表現するデータ形式
UserOperationは、EOAのトランザクションに相当するSmart Account用のデータ構造です。主なフィールドは、実行主体のアカウントアドレス（sender）、リプレイ防止のnonce、実行内容のエンコード（callData）、認証情報（signature：ECDSAに限らずpasskeyやマルチシグなどアカウント実装が定義した任意の方式）、ガス上限・手数料の指定、そしてガス代を肩代わりさせる場合のPaymaster指定です。アカウントが未デプロイの場合は、初回のUserOperationにアカウント生成の指示（EntryPoint v0.6ではinitCode、v0.7以降はfactoryとfactoryDataに分離）を含められます。この「初回利用時にアカウントを作る」仕組みにより、ユーザーは事前のコントラクトデプロイを意識せずにアカウントを持てます。
重要なのは、Ethereum本体はUserOperationを直接認識しないことです。UserOperationはあくまでアプリケーション層のデータであり、Bundlerが複数件を束ねて1本の通常トランザクションに詰めてチェーンへ送ります。チェーンから見えるのは「BundlerがEntryPointのhandleOps関数を呼んだ」という事実だけで、複雑さはすべてEntryPointとBundlerの内側に隠蔽されています。
Bundler — UserOperationの中継と事前検証
Bundlerは、専用mempoolからUserOperationを収集し、EntryPointのhandleOps呼び出しとしてチェーンへ送信するノードです。ここで押さえるべきは、Bundlerがガス代を先に立て替える存在だという点です。handleOpsのガス代はまずBundlerが支払い、EntryPointの精算処理で回収します。検証に失敗するUserOperationをチェーンに載せてしまうと回収できないガスをBundlerが自腹で負担することになるため、Bundlerは受信したUserOperationを必ずローカルでシミュレーションし、署名・残高・ガス見積もりに問題があるものを事前に弾きます。シミュレーション時のコントラクトの挙動には標準化された制限（ERC-7562：検証中に触れてよいストレージや命令の規則）があり、「ローカル検証は通ったのにオンチェーンで結果が変わる」攻撃を防いでいます。
Bundlerは標準に準拠していれば乗り換え可能で、Alchemy・Pimlico・Coinbase・Etherspot（Skandha）・Candideなどの商用サービス・OSS実装が併存しています。累計処理件数ではAlchemyが過半を占め、Pimlico・Coinbaseが続きます（BundleBear Bundler統計、2026年8月11日閲覧）。
Paymaster — ガス代の支払い差し替え
Paymasterは、UserOperationのガス代をユーザー本人に代わって支払うコントラクトで、「ユーザーにETHを持たせない」UXを実現する層です。実用化されている方式は主に3つあります。事業者が全額負担するスポンサー方式、ユーザーがUSDC等のトークンで支払い、PaymasterがETH建てのガス代を立て替えるERC-20方式、オフチェーンで承認判断を行いその署名を持ち込むVerifying方式です。追跡対象チェーン合算で、Paymasterが肩代わりしたガス代は累計約1,336万ドルに達しています（BundleBear、2026年8月11日閲覧）。
Paymasterを名乗るには、EntryPointへガス原資となるETHを事前にデポジットしておく必要があります（仕様上の要件。加えてmempool上の評判管理のためステークを求められます）。ガス代はこの預託金から引き落とされるため、残高が尽きれば、そのPaymasterを指定した取引は通らなくなります。誰のどの操作を肩代わりするかの条件設計と費用の試算はガスレストランザクションの経済性で詳しく扱います。
Smart Account — ユーザーのアカウント本体
Smart Account（スマートアカウント）は、ユーザーのアカウントとして機能するコントラクトです。EntryPointからの問い合わせに応じて署名を検証する関数（validateUserOp）と、検証後に実際の処理を行う実行関数を実装していれば、内部の設計は自由です。この自由度が、passkey認証・セッションキー・ソーシャルリカバリ・支出限度額といったプロダクト差別化の源泉になります。
実務では、ゼロから書くのではなくSafe・Kernel（ZeroDev）・Nexus（Biconomy）・LightAccount（Alchemy）などの既存実装から選ぶのが基本です。外部監査の実施状況は実装とバージョンごとに異なるため、採用候補ごとに監査レポートの有無と対象バージョンを公式リポジトリ・公式ドキュメントで個別に確認してください。モジュール拡張の共通規格（ERC-7579・ERC-6900）に準拠した実装を選ぶと、認証方式や機能の追加・乗り換えの余地が残ります。実装ごとの比較はSmart Wallet スタック比較2026を参照してください。
UserOperationのライフサイクル — 署名から実行完了まで
4つのコンポーネントの連携を、「ユーザーがスマートアカウントからUSDCを送金する」典型例で追います。
- 作成と署名（クライアント側）：ウォレットアプリのSDKが「USDCのtransferを呼ぶ」callDataを組み立て、アカウントのnonceとガス見積もりを取得し、ユーザーがpasskey・秘密鍵などアカウントに設定された方式で署名します。この時点でチェーンには何も送られていません。
- Bundlerの受信と事前検証：署名済みUserOperationはBundlerのRPCエンドポイントへ送られ、専用mempoolに入ります。Bundlerは前述のシミュレーションを行い、オンチェーンで失敗する見込みのものはこの段階で拒否します。ユーザーから見た「送信エラー」の多くはここで発生するため、原因調査はBundlerのシミュレーション結果から始めるのが定石です。
- 検証フェーズ（オンチェーン）：Bundlerが複数のUserOperationを束ねてhandleOpsを呼ぶと、EntryPointはまず全件について検証だけを行います。各Smart AccountのvalidateUserOpで署名とnonceを確認し、Paymaster指定があればvalidatePaymasterUserOpで支払い可否を確認し、ガス代上限相当額を預託金から先取りで確保します。
- 実行フェーズ：検証を通過したUserOperationについて、EntryPointがSmart Accountに実行を指示し、callDataの内容（この例ではUSDCのtransfer）が実行されます。
- 精算：実測のガス消費に基づき、EntryPointが確保していた額との差額をSmart AccountまたはPaymasterへ返金し、Bundlerへ立て替え分と手数料を支払います。ERC-20方式のPaymasterであれば、ここで実行される後処理（postOp）でユーザーからトークン建ての代金を回収します。
検証と実行がフェーズとして分離されているのは、Bundlerのガス立て替えを成立させるためです。「実行が失敗しても、検証を通った取引の手数料は必ず回収できる」ことをコントラクトレベルで保証しなければ、誰もBundlerを運営できません。Paymasterの事前デポジット、シミュレーションの厳格さ、検証中のストレージアクセス制限は、いずれもこの回収保証から導かれる設計です。
この構造は事業者の運用に直結する含意を持ちます。第一に、Paymasterの預託金残高が尽きると、そのPaymasterを指定したUserOperationは検証を通らず失敗します。ユーザー本人がガス代を払う経路や別のPaymasterを使う取引には影響しませんが、ガスレスを主経路とするサービスでは実質的な機能停止となるため、残高監視と自動補充は一級の運用項目です。第二に、EntryPoint v0.7で導入された未使用実行ガスへのペナルティがあります。現行仕様では、実行用に確保して使わなかったガス（callGasLimitとpaymasterPostOpGasLimitの未使用分）が40,000ガス以上の場合に、その10%が課されます（現行ERC-4337仕様。導入経緯はv0.7.0リリースノート）。ガス見積もりの精度がそのまま費用に響きます。第三に、バッチ実行（複数操作を1件のUserOperationにまとめる）を前提にすると署名回数もガスも減るため、callDataの設計はUX設計そのものです（バッチトランザクションの記事で詳述）。
2026年8月時点の現在地 — 普及の実数とEntryPointバージョン
「ERC-4337は実際に使われているのか」は公開データで確認できます。AA特化の統計サイトBundleBearによると、追跡対象のEVMチェーン合算で、累計UserOperationは約12.4億件、1件以上のUserOperationを実行したスマートアカウントは約6,370万に達しています（BundleBear、2026年8月11日閲覧）。ガス代の安いL2が件数の中心であること、アカウント数は「作られた数」ではなく「使われた数」ベースでもこの規模であることが、実験段階を越えたことを示しています。
事業者の実装判断に直結するのが、中核コントラクトEntryPointのバージョンです。互換性の断絶があるのはv0.6とv0.7の間です。v0.7でUserOperationの構造と検証インターフェースが再編されたため（factory/factoryData分離など）、v0.6向けに書かれたAccount実装やSDKはそのままではv0.7以降で動きません。一方、v0.7・v0.8・v0.9の3世代は、Account・Paymasterから見たインターフェースがABI互換で保たれており、既存のAccount・Paymaster実装はコード変更なしで新しいEntryPointに接続できます（新機能を使う場合の対応は別途必要です。v0.9.0リリースノート）。ただしEntryPointはバージョンごとに別アドレスのコントラクトとして併存するため、ABI互換の世代間でも、Account実装・Bundler・SDKがどのバージョン（アドレス）のEntryPointへ接続するかを揃えることは引き続き構成上の制約です。
| バージョン | 公開 | 主な変更 | 事業者にとっての意味 |
|---|---|---|---|
| v0.6 | 2023年4月 | 初期の普及版 | 対応実装が多いが世代交代が進行。新規採用は非推奨 |
| v0.7 | 2024年2月 | UserOperation構造の再編（factory/factoryData分離）、未使用実行ガスへの10%ペナルティ導入（現行仕様の適用条件は本文前述） | 広く使われる現行世代。ガス見積もり精度が費用に直結 |
| v0.8 | 2025年3月 | EIP-7702のネイティブ対応、EIP-712ベース署名、最小実装Simple7702Accountの同梱 | 7702委任EOAと4337インフラの合流点 |
| v0.9 | 2025年11月 | Paymaster署名の後付け（署名処理の並列化）、ブロック番号による有効期間指定。v0.7・v0.8とABI互換 | 最新版。ABI互換のため既存のAccount・Paymasterは変更なしで対応可 |
選定の考え方はシンプルです。新規に構成を組むなら、採用するAccount実装とBundlerが対応している範囲でv0.7以降を選びます。対応するEntryPointバージョンはBundler・SDKごとに異なるため、採用候補の公式ドキュメントで個別に確認してください。v0.6で運用中のプロダクトは、Account実装のアップグレード経路（プロキシ構造か、再デプロイと資産移行か）を含めた移行計画を持っておくべき段階です。なお複数バージョンのEntryPointは同時に併存・稼働しており、「最新版が出ると旧版が止まる」ことはありません。
EIP-7702との関係 — 置き換えではなく合流
2025年5月7日に有効化されたPectraアップグレード（Ethereum Foundation公式ブログ）で導入されたEIP-7702は、既存のEOAにスマートコントラクトの機能を委任するプロトコル変更です。「7702が入ったのでERC-4337は不要になった」わけではありません。7702はアカウントの入口（既存EOAをスマート化する）を増やしたもので、委任されたEOAがガス代肩代わりやバッチ実行を実際に使う際の処理経路としては、ERC-4337のBundler・Paymaster・EntryPointがそのまま機能します。EntryPoint v0.8以降が7702をネイティブ対応したのはこの合流の表れです。実務では「ウォレットを持たない新規ユーザーには4337型スマートアカウントを発行し、既存EOAユーザーには7702で同じ機能を届ける」併用構成が有力な選択肢です。規格の詳細はEIP-7702の事業者向け解説、選択の判断軸はERC-4337 vs EIP-7702の判断軸を参照してください。
RIP-7560 — その先にあるネイティブAAの提案
ERC-4337の機能をプロトコル自体に取り込む提案としてRIP-7560（Native Account Abstraction）があります。EntryPoint相当の処理をノードが直接扱うことでコントラクト経由のオーバーヘッドを削減する構想ですが、L2向けの提案（RIP）であり、2026年8月時点で提案段階です。Ethereum本体は当面ERC-4337の経路が前提であり、事業者としては標準準拠の実装を選んでおけば将来の移行余地を確保できる、という以上の対応は現時点では不要です。
事業者はどこを担うか — 3層の分担判断
EntryPointが共有インフラである以上、事業者が判断するのは残る3層（Account・Bundler・Paymaster）の持ち方です。層ごとに判断の性質が異なります。
- Smart Account層＝プロダクト判断：認証方式・リカバリ・権限設計はユーザー体験の差別化に直結するため、要件を自社で定義すべき層です。ただし実装はフルスクラッチではなく、既存実装（監査状況を個別確認したもの）の採用・fork・モジュール追加が基本です。
- Bundler層＝インフラ調達判断：標準準拠で乗り換え可能な層であり、まずSaaS利用から始めるのが現実的です。可用性を上げたい場合、自社ノード運用の前にまず検討すべきは、障害時に別のBundlerへ切り替えられるようにしておくfailover構成です（同一UserOperationを複数Bundlerへ同時送信する構成は、二重実行や余分な手数料の考慮が必要な別物であり、ここでは指しません）。自社運用が視野に入るのは、送信順序や検閲耐性まで自社で保証したい場合です。
- Paymaster層＝事業ポリシー判断：コントラクトやインフラはSaaSで賄えますが、「誰の・どの操作を・いくらまで肩代わりするか」は費用と不正利用リスクを直接決める事業判断です。無条件のスポンサーは預託金の吸い上げ被害（bot等による大量消費）を招くため、対象操作の限定・ユーザー認証・レート制限を初期設計に含めます。
運用の最低ラインは、Paymaster預託金の残高監視と補充手順、Bundler障害時の代替経路、EntryPointバージョンの移行計画の3点です。攻撃ベクトルと監査の観点はAAセキュリティリスク、Bundler・Paymaster・SDKの具体的な組み合わせはAA開発スタックの選定で扱っています。
まとめ
- ERC-4337は、Ethereum本体を変えずにスマートコントラクトをアカウントとして使えるようにする標準で、2023年3月の稼働開始から累計約12.4億件のUserOperationが処理されています（2026年8月11日時点）。
- 構成要素は4つ。EntryPoint（共有の検証・実行・精算窓口）、Smart Account（アカウント本体＝差別化の中心）、Bundler（中継とガス立て替え）、Paymaster（ガス代の支払い差し替え）です。
- 検証フェーズと実行フェーズの分離は、Bundlerのガス立て替えを回収保証するための設計であり、Paymasterの事前デポジットやシミュレーションの厳格さはその帰結です。
- EntryPointはv0.7が現行世代として広く使われ、v0.8でEIP-7702と合流、最新はv0.9（2025年11月、v0.7/v0.8とABI互換）。Account・Bundler・SDKの対応バージョンを揃えることが構成上の制約です。
- 事業者の判断は3層に分かれます。Accountはプロダクト判断、Bundlerはインフラ調達判断、Paymasterは事業ポリシー判断であり、それぞれ検討の主体と粒度が異なります。
関連記事
全体像と規格の選択：
- アカウントアブストラクション（AA）完全マップ 2026 — AA全体の俯瞰と「使う・組む・自社実装」の判断軸
- EIP-7702の事業者向け解説 — 既存EOAをスマート化する補完規格
- ERC-4337 vs EIP-7702の判断軸 — ユーザー層で使い分ける選択フロー
各コンポーネントの深掘り：
- Smart Wallet スタック比較 2026 — Safe / Kernel / LightAccount / Nexus / Coinbase系の比較
- ガスレストランザクションの経済性 — Paymasterの費用試算と回収設計
- AA開発スタックの選定 — Bundler・Paymaster・SDKの組み合わせ
- AAセキュリティリスク — Bundler / Paymaster / Accountの攻撃ベクトルと監査観点
- Passkey（WebAuthn）× ERC-4337 — 秘密鍵を見せない認証UX
- バッチトランザクション — approve+swapを1回の署名にまとめる実装と導入判断
XTELAが支援できる範囲
ERC-4337の採用は、対象ユーザー・ガス負担の設計・既存プロダクトとの接続が絡み合うため、「どの層をどこまで自社で持つか」の整理から始めるのが近道です。XTELAは、ブロックチェーン領域の受託開発・プロジェクト運用支援・技術顧問という形でWeb3サービスの技術面を支援しており、AA採用に関するご相談も、この整理の壁打ちから要件定義・開発・ローンチ後の運用まで、内容を伺ったうえで対応範囲をご案内します。カストディ該当性など制度面の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術資料の整理を支援します。
主要参考資料
- ERC-4337: Account Abstraction Using Alt Mempool
- ERC-7562: Account Abstraction Validation Scope Rules
- EIP-7702: Set Code for EOAs
- eth-infinitism: EntryPoint v0.6.0リリースノート（2023年4月24日）
- eth-infinitism: EntryPoint v0.7.0リリースノート（2024年2月22日）
- eth-infinitism: EntryPoint v0.8.0リリースノート（2025年3月26日）
- eth-infinitism: EntryPoint v0.9.0リリースノート（2025年11月16日）
- Ethereum Foundation Blog: Pectra Mainnet Announcement（2025年4月23日）
- BundleBear: ERC-4337統計（2026年8月11日閲覧）
- RIP-7560: Native Account Abstraction
本記事の前提
本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。規格のバージョン、各社の製品構成、利用統計は今後変わり得ます。採用判断の際は最新の公式ドキュメントを確認し、法令・会計・税務の該当性判断は有資格の専門家に相談してください。
