ERC-4337とは？ガス代の肩代わりやパスキーログインを実現する仕組み

ステーブルコインで送金できるアプリを作ったとします。ユーザーのウォレットにはUSDCが入っています。ところが送金ボタンを押すと「ETHが足りません」と表示されます。Ethereumでは、取引のたびに手数料（ガス代）をETHで払う決まりがあるからです。

ユーザーは取引所でETHを買い、ウォレットへ移してから、ようやく送金できます。この手間で多くの人が離れていきます。「ETHを買わせずに、アプリの中で送金を終わらせたい」。この悩みに応える共通のルールがERC-4337（仕様）です。

ERC-4337は2023年3月にEthereumメインネットで動き始めました。2026年9月25日時点で、処理された取引は累計約12.9億件あります（BundleBear）。すでに実際に使われている仕組みです。

なぜユーザーはETHを先に買う必要があるのか

Ethereumのアカウントには2種類あります。秘密鍵で直接動かす普通のアカウント（EOA：Externally Owned Account）と、プログラムとして動くコントラクトアカウントです。これまで、ユーザーのウォレットとして使えるのは事実上EOAだけでした。EOAには次の4つの弱点があります。

• 鍵をなくすと資産もなくなる：署名鍵がアカウントそのものです。シードフレーズを失えば取り戻す手段がなく、盗まれれば資産を守れません。復旧の仕組みを後から組み込むこともできません。
• ガス代は本人がETHで払うしかない：ステーブルコインしか持たないユーザーでも、送金の前にETHが要ります。事業者が肩代わりする標準的な方法もありません。
• 署名のやり方が1種類しかない：方式はECDSAだけです。スマートフォンの生体認証（passkey）や複数人の承認（マルチシグ）を、アカウント自体に組み込めません。
• 複数の操作をまとめられない：「承認してからスワップ」のような一連の操作が、別々の取引に分かれます。そのたびに署名とガス代が必要です。

ERC-4337で何ができるようになるのか

アカウントをプログラム（スマートコントラクト）にできれば、署名の確かめ方や支払い方法をコードで自由に決められます。上の4つの弱点は、これで解けます。

• ガス代を事業者が肩代わりする。またはユーザーがUSDCなどで払う
• passkeyでログインし、生体認証だけで送金する
• 複数の操作を1回の署名でまとめて実行する

難しかったのは「秘密鍵を持たないプログラムが、誰のお金で、どうやって取引を始めるのか」という点です。Ethereum本体を作り変えて解く提案（EIP-86、EIP-2938など）もありました。しかし本体の合意ルールまで変える必要があり、重すぎて実現しませんでした。

そこで2021年9月、Vitalik Buterinらが別のやり方を提案しました。本体には手を付けず、共通のプログラムと外部のサーバーの組み合わせだけで解く方法です。これがERC-4337です。本体を変えないので、Ethereumと互換のある他のチェーンでも同じ仕組みがそのまま使えます。Layer 2（Ethereumの処理を肩代わりして速く安くする二層目のチェーン。以下L2）でも使えます。

4つの部品はそれぞれ何をしているのか

ERC-4337は、4つの部品と、そこを流れる依頼書（UserOperation）でできています。郵便にたとえると分かりやすくなります。

• UserOperation＝依頼書：「USDCを誰々へ送る」という中身と、本人の署名が入った封書です。まだチェーンには送られていません。
• Bundler＝集配：依頼書を集めて、何通もまとめて1台のトラックで運びます。運ぶための送料（ガス代）は、いったん集配側が立て替えます。
• EntryPoint＝本局の窓口：全員が共通で使う1つの窓口です。封書の署名を確かめ、中身を実行し、立て替えた送料を集配へ精算します。
• Paymaster＝料金受取人払い：返信はがきのように、送る人ではなく会社が送料を持つ仕組みです。会社は窓口にお金（デポジット）を前もって預け、送料はそこから引き落とされます。
• Smart Account＝ユーザーの口座：「この署名なら本人とみなす」といったルールを、口座ごとに決められます。

郵便と違うのは、立て替えの回収まで仕組みで決まっている点です。窓口の確認を通った依頼なら、Bundlerは送料を必ず回収できます。回収元はユーザーの口座か、Paymasterのデポジットです。

事業者が考えるのは、どの部品を自社で持ち、どれを外部に任せるかです。部品ごとの役割と、実際に動かしている人を並べると次のとおりです。

送金1回はどう流れるのか

冒頭のアプリで、ユーザーがUSDCを送る場面を追います。

1. ユーザーがアプリで送金を指示し、passkeyなどで署名します。この時点では、まだチェーンに何も送られていません。
2. 依頼書がBundlerに届きます。Bundlerは手元で試しに動かし、失敗しそうなものはここで断ります。
3. Bundlerが何件かをまとめてEntryPointへ送ります。EntryPointは署名と、Paymasterの支払い能力を確かめます。
4. 確かめられた依頼だけが実行され、USDCが相手に届きます。最後にガス代が精算されます。

ユーザーはETHを一度も持たずに送金を終えています。ガス代はPaymasterのデポジットから払われました。

もう使われているのか

AAの統計サイトBundleBearによると、追跡しているEVMチェーンの合計は次のとおりです（BundleBear）。AAはアカウントアブストラクション（Account Abstraction）の略で、アカウントの仕組みをプログラムに移す技術の総称です。

• 累計のUserOperation：約12.9億件
• 1件以上の取引をしたスマートアカウント：約6,770万
• Paymasterが肩代わりしたガス代：累計約1,433万ドル

件数の中心はガス代の安いL2です。アカウント数は「作られた数」ではなく「使われた数」で数えています。それでもこの規模なので、試しに使う段階は過ぎたと言えます。

Bundlerは標準に従っていれば乗り換えられます。Alchemy・Pimlico・Coinbase・Etherspot（Skandha）・Candideなどの商用サービスやオープンソースの実装があります。累計の処理件数ではAlchemyが過半を占め、Pimlico・Coinbaseが続きます（BundleBear Bundler統計）。

自社で持つ部分と、外部に任せる部分

EntryPointは全員が共有する窓口なので、自社で作ることはありません。事業者が考えるのは残りの3つです。部品ごとに、考える人も中身も違います。

• Smart Account＝どんな体験にするか：認証方式・復旧・権限の設計は、ユーザー体験を大きく左右します。要件は自社で決めるべき部分です。ただし実装はゼロから書かず、監査状況を確かめた既存の実装を使うか、それに機能を足すのが基本です。
• Bundler＝どこから調達するか：標準に従っていれば乗り換えられます。まずはSaaSから始めるのが現実的です。止まったときに備えるなら、自社ノードより先に、別のBundlerへ切り替えられる構成を考えます。自社で動かすのは、送る順番や検閲されないことまで自社で保証したい場合です。
• Paymaster＝どこまで肩代わりするか：仕組み自体はSaaSで賄えます。一方で「誰の・どの操作を・いくらまで」払うかは、費用と不正利用の危険を直接決める事業の判断です。無条件に肩代わりすると、botなどに大量に使われてデポジットを吸い取られます。対象の操作を絞る、ユーザー認証を入れる、回数を制限する。この3つを最初から設計に入れます。

運用で最低限用意したいのは3つです。

• Paymasterのデポジット残高の見張りと、補充の手順。残高が尽きると、ガスレスで動くサービスは実質止まります
• Bundlerが止まったときに別の送り先へ切り替える手段
• EntryPointの新しい版へ移るときの計画

肩代わりの条件と費用の見積もりはガスレストランザクションの経済性で詳しく扱います。攻撃の手口と監査で見る点はAAセキュリティリスク、Bundler・Paymaster・SDKの組み合わせ方はAA開発スタックの選定にまとめています。

EIP-7702が入った今も、ERC-4337は必要なのか

2025年5月7日、EthereumのPectraアップグレードが有効になりました（Ethereum Foundation公式ブログ）。ここで入ったEIP-7702は、今あるEOAにスマートコントラクトの機能を持たせる仕組みです。

「7702が入ったので4337は要らない」わけではありません。7702が増やしたのは、スマートアカウントになる入口です。そのアカウントでガス代の肩代わりや一括実行を使うときは、4337の仕組みがそのまま働きます。Bundler・Paymaster・EntryPointです。EntryPointはv0.8から7702に直接対応しました。

実際には、両方を使う構成が有力です。ウォレットを持っていない新しいユーザーには4337のスマートアカウントを発行します。すでにEOAを持つユーザーには、7702で同じ機能を届けます。規格の詳細はEIP-7702の事業者向け解説、どちらを選ぶかはERC-4337 vs EIP-7702の判断軸を参照してください。

実装する人向けの詳細

ここからは、実際に組み込む人に向けた細部です。

UserOperationには何が入っているか

UserOperationは、EOAの取引に当たるSmart Account用のデータです。主な項目は次のとおりです。

• 実行するアカウントのアドレス（sender）と、同じ依頼の使い回しを防ぐ連番（nonce）
• 実行内容（callData）と認証情報（signature）。signatureはECDSAに限らず、passkeyやマルチシグなどアカウント側が決めた方式でよい
• ガスの上限と手数料の指定、ガス代を肩代わりさせる場合のPaymasterの指定

アカウントがまだデプロイされていなければ、初回のUserOperationにアカウントを作る指示を入れられます。EntryPoint v0.6ではinitCode、v0.7以降はfactoryとfactoryDataに分かれました。この仕組みで、ユーザーは事前のデプロイを意識せずにアカウントを持てます。

Ethereum本体は、UserOperationを直接は扱いません。Bundlerが何件かを束ね、1本の通常の取引に詰めて送ります。チェーンから見えるのは「BundlerがEntryPointのhandleOpsを呼んだ」ことだけです。

署名から実行完了までの流れ

図1の流れを、関数の名前まで含めて追います。

1. 作成と署名（アプリ側）：ウォレットアプリのSDKが、USDCのtransferを呼ぶcallDataを組み立てます。nonceとガスの見積もりを取り、ユーザーがアカウントに設定された方式で署名します。
2. Bundlerの受信と事前検証：署名済みのUserOperationはBundlerのRPCへ送られ、専用のmempool（未処理の取引の待ち場所）に入ります。Bundlerはシミュレーションを行い、チェーン上で失敗しそうなものを拒否します。ユーザーから見た「送信エラー」の多くはここで起きます。原因を調べるときは、Bundlerのシミュレーション結果から見るのが近道です。
3. 検証フェーズ（チェーン上）：BundlerがhandleOpsを呼ぶと、EntryPointはまず全件の検証だけを行います。各Smart AccountのvalidateUserOpで署名とnonceを確かめます。Paymasterの指定があればvalidatePaymasterUserOpで支払えるかを確かめ、ガス代の上限相当額をデポジットから先に確保します。
4. 実行フェーズ：検証を通ったUserOperationについて、EntryPointがSmart Accountに実行させます。この例ではUSDCのtransferが動きます。
5. 精算：実際に使ったガスをもとに、確保していた額との差をSmart AccountまたはPaymasterへ返します。Bundlerには立て替え分と手数料を払います。ERC-20方式のPaymasterなら、ここで動く後処理（postOp）でユーザーからトークンで代金を受け取ります。

検証と実行が分かれている理由

handleOpsのガス代は、まずBundlerが払います。検証に失敗するUserOperationをチェーンに載せると、Bundlerはそのガス代を回収できません。実行が失敗しても、検証を通った取引の手数料は必ず回収できる。これをコントラクトの仕組みで保証しないと、誰もBundlerを運営できません。だから検証と実行が別のフェーズになっています。

Bundlerがローカルで厳しくシミュレーションするのも、同じ理由です。検証中にコントラクトが触ってよいストレージや命令には、決まった制限があります（ERC-7562）。これで「手元の検証は通ったのに、チェーン上では結果が変わる」攻撃を防いでいます。Paymasterに事前のデポジットが必要なのも、この回収の保証のためです。

費用と停止に響く3つの点

• Paymasterのデポジット：Paymasterとして使うには、EntryPointへガス代の元手となるETHを前もって預けます。ストレージの使い方によっては、mempoolでの評判管理のためにステーク（ロックされる担保）も必要です。デポジットが尽きると、そのPaymasterを指定したUserOperationは検証を通りません。本人がガス代を払う取引や、別のPaymasterを使う取引には影響しません。
• 使わなかったガスへのペナルティ：EntryPoint v0.7で入りました。対象は、実行用に確保して使わなかったガスです（callGasLimitとpaymasterPostOpGasLimitの未使用分）。これが40,000ガス以上なら、その10%が課されます（現行ERC-4337仕様。導入の経緯はv0.7.0リリースノート）。ガス見積もりの精度が、そのまま費用に響きます。
• 一括実行（バッチ）：複数の操作を1件のUserOperationにまとめると、署名の回数もガスも減ります。callDataの設計は、そのままUXの設計です（バッチトランザクションで詳しく扱います）。

EntryPointの版をどう選ぶか

EntryPointは、チェーンごと・版ごとに同じアドレスへデプロイされる共通コントラクトです。参照実装を作っているのは、ERC-4337の提案者らが中心のチームeth-infinitismです（eth-infinitism/account-abstraction）。OpenZeppelin・Spearbit・Cantinaなどの外部監査も受けています（監査レポート一覧）。全員が同じコントラクトを使うことが安全と互換性の前提なので、自前のEntryPointを作ることは想定されていません。

互換性が切れているのはv0.6とv0.7の間です。v0.7でUserOperationの構造と検証のインターフェースが組み直されました。v0.6向けのAccount実装やSDKは、そのままではv0.7以降で動きません。

一方、v0.7・v0.8・v0.9の3世代は、Account・Paymasterから見たインターフェースがABI互換です。既存のAccount・Paymasterは、コードを変えずに新しいEntryPointへつなげます。新機能を使う場合は別に対応が要ります（v0.9.0リリースノート）。ただし版ごとにアドレスが違う別のコントラクトです。Account実装・Bundler・SDKが同じ版（アドレス）を向いているかは、互換の世代どうしでも揃える必要があります。

2026年9月25日時点で、最新はv0.9のままです。各版の違いは次のとおりです。

新しく組むなら、採用するAccount実装とBundlerが対応している範囲で、v0.7以降を選びます。対応する版はBundler・SDKごとに違うので、候補の公式ドキュメントで一つずつ確かめてください。v0.6で運用中なら、移行の計画を持っておく時期です。計画には、Account実装の上げ方（プロキシで差し替えるか、作り直して資産を移すか）も含めます。なお、複数の版のEntryPointは同時に動いています。新しい版が出ても、古い版が止まることはありません。

Smart Accountの実装をどう選ぶか

Smart Accountは、EntryPointからの問い合わせに応えて署名を確かめる関数（validateUserOp）と、実行用の関数を持っていれば、中身は自由に作れます。passkey認証・セッションキー・ソーシャルリカバリ・支出の上限といった機能の違いは、ここから生まれます。

実際には、ゼロから書かずに既存の実装から選ぶのが基本です。Safe・Kernel（ZeroDev）・Nexus（Biconomy）・LightAccount（Alchemy）などがあります。外部監査の状況は実装と版ごとに違います。候補ごとに、監査レポートの有無と対象の版を公式リポジトリやドキュメントで確かめてください。機能を足す共通規格（ERC-7579・ERC-6900）に従った実装を選ぶと、認証方式の追加や乗り換えがしやすくなります。実装ごとの比較はSmart Wallet スタック比較2026にあります。

RIP-7560（ネイティブAA）はどう関わるか

ERC-4337の機能をプロトコル自体に取り込む提案に、RIP-7560（Native Account Abstraction）があります。EntryPointに当たる処理をノードが直接行い、コントラクトを通す分の負担を減らす構想です。L2向けの提案（RIP）で、2026年9月25日時点ではまだ草案（Draft）です。Ethereum本体では当面ERC-4337の仕組みが前提です。標準に沿った実装を選んでおけば、将来移る余地は残せます。今の時点でそれ以上の対応は要りません。

まとめ

• ERC-4337は、Ethereum本体を変えずにスマートコントラクトをアカウントとして使えるようにする標準です。ユーザーにETHを持たせずに送金させることができます。
• 部品は4つです。共通の窓口EntryPoint、ユーザーの口座Smart Account、集配と立て替えのBundler、送料を肩代わりするPaymasterです。
• 事業者が自社で決めるのは3つです。Smart Accountはどんな体験にするか、Bundlerはどこから調達するか、Paymasterはどこまで肩代わりするか、です。
• 運用では、Paymasterのデポジット残高、Bundlerの切り替え手段、EntryPointの版の移行計画を用意します。
• EntryPointの最新はv0.9（2025年11月）です。v0.7・v0.8とABI互換ですが、Account・Bundler・SDKが向く版は揃える必要があります。

関連記事

全体像と規格の選び方：

• アカウントアブストラクション（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は、3つの部品をどこまで自社で持つかの整理から、要件定義・開発・公開後の運用まで、ブロックチェーンの技術面を担当します。法的な判断は弁護士と連携して進めます。

スマートアカウント・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統計
• RIP-7560: Native Account Abstraction

数値と版の情報は2026年9月25日に確認しました（BundleBearの統計、EntryPointの最新版、RIP-7560の状態）。規格の版や各社の製品、利用統計は今後変わることがあるため、採用の際は最新の公式ドキュメントと、必要に応じて専門家の意見を確かめてください。