ERC-4337とEIP-7702の違いと使い分け｜判断を分ける4つの軸と併用構成

コラム

／約17分で読めます

コラム

／約17分

ERC-4337とEIP-7702の違いと使い分け｜判断を分ける4つの軸と併用構成
目次（タップで折りたたみ）

    「ERC-4337とEIP-7702のどちらを採用すべきか」への2026年時点の答えは、規格の優劣でも対象ユーザーの新旧でもなく、3つの要件で決まります。(1) 既存EOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント）のアドレス・資産・履歴を維持する必要があるなら、それができる唯一の規格であるEIP-7702。(2) 鍵を失っても資産を失わない設計や複数人承認の強制など、秘密鍵を最上位権限に残せない要件があるならERC-4337のスマートアカウント（アカウントとして機能するスマートコントラクト）を、単独鍵に絶対権限を残さない実装・設定と組み合わせて採用。(3) どちらにも当たらない新規アカウント発行では両規格とも選択肢になり、展開先チェーンとウォレット・SDKの対応状況で選びます。両者は競合規格ではなく、ガス代肩代わりや複数操作の一括実行を支える実行インフラ（Bundler・Paymaster・EntryPoint）を共有できる補完関係にあり、AAインフラ事業者のドキュメントでも「競合する提案ではない」と明記されています（Pimlico Docs）。

    本記事は、この結論に至る両規格の仕様上の構造差、判断を実際に分ける4つの軸、両方のユーザー層を抱えるサービスの併用構成、そして事業者の立場によっては規格選択そのものが不要になる切り分けまでを、2026年8月11日時点の一次情報と採用実数で整理します。それぞれの規格の仕組み自体はERC-4337の事業者向け解説とEIP-7702の事業者向け解説で扱っているため、本記事は「選ぶ・併用する」判断に集中します。アカウントアブストラクション（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移す技術群。以下AA）全体の俯瞰はAA完全マップ2026を参照してください。

    何が違うのか — 仕様上の3つの構造差

    どちらの規格も、ガス代の肩代わり、複数操作の一括実行、パスキー（passkey：生体認証で使えるWebAuthn系の公開鍵認証）による署名といったAAの機能を実現します。提供できる機能の一覧で比べても差はほとんど出ません。判断に効くのは、機能の裏側にある次の3つの構造差です。

    違い1: アカウントの作り方 — 新規デプロイか、EOAへの委任か

    ERC-4337は、ユーザーごとに新しいコントラクトアカウントをデプロイする方式です。アカウントのアドレスは既存EOAとは別になるため、既にEOAで資産を持つユーザーに適用するには資産の移動が必要です。ウォレットを持たない新規ユーザーに対しては、初回操作と同時にアカウントを生成でき、「ウォレットを作る」体験そのものを見せないオンボーディングを設計できます（ERC-4337仕様）。

    EIP-7702は、EOAのコード領域に委任先コントラクトへの参照を書き込む方式です。アドレス・資産・取引履歴はそのまま維持され、ユーザーは1つの認可署名でスマートアカウント機能を得ます。委任は取り消すまで持続し、ゼロアドレスへの委任で元のEOAへ戻せます。注意したいのは、委任できるのは「既存の」EOAに限らないことです。仕様上、認可の対象はコードが空か委任済みのアカウントであればよく、新規に生成したEOAも含まれます（EIP-7702仕様）。実際、新規ユーザーに新しいEOAを生成し、ガス代を事業者が肩代わりしながら7702委任する構成は、組み込みウォレットのAPIとして商用提供されています（Coinbase Developer Platform Docs、2026年8月11日閲覧）。

    違い2: 鍵の権限構造 — 実装で権限を定義できるか、秘密鍵が最上位に残るか

    ERC-4337では、署名の検証方法をアカウント実装（コントラクト）が定義し、プロトコル側にその検証を迂回する経路がありません（ERC-4337仕様）。このため、パスキー・マルチシグ・鍵のローテーション・ソーシャルリカバリ（信頼できる第三者の承認で鍵を再設定する仕組み）を、回避不能なアカウントのルールとして強制する設計が可能です。ただし、これは規格自体の保証ではありません。検証ロジックは実装に委ねられているため、公式の参照実装SimpleAccountのように、単一のEOA owner鍵によるECDSA署名で検証し、そのownerが直接実行・アップグレードできる実装も規格に適合します（eth-infinitism SimpleAccount v0.8）。単独鍵の絶対権限を無くしたい場合は、ERC-4337を選ぶことに加えて、単一owner鍵や単独のアップグレード権限を残さない実装・設定を選定し、検証する必要があります。

    EIP-7702では、委任後もEOAの秘密鍵がアカウントの最上位権限であり続けます。委任先コントラクトがどれほど厳密な承認ルールを実装していても、元の秘密鍵はそれを経由せずにアカウントを操作でき、委任の変更・取り消しも自由に行えます（EIP-7702仕様）。この性質のため、7702委任では「鍵が漏えいしても資産に触れられない」設計は原理的に作れず、複数人承認を強制する真のマルチシグも成立しません（Pimlico Docs）。実際、鍵漏えい済みEOAからの資産吸い出しを自動化する悪性委任が大規模に観測されており（CoinDesk 2025年6月2日）、7702は秘密鍵管理の重要性を下げるのではなく、むしろ上げる規格です。この性質は新規に生成したEOAへ委任する場合も同じで、7702を選ぶ限りEOAの鍵というセキュリティ境界が残ります。脅威モデルの全体像はAAセキュリティリスクで扱っています。

    違い3: 実行経路 — 専用インフラ経由か、通常トランザクションも使えるか

    ERC-4337のスマートアカウントの操作は、UserOperation（ユーザーの操作意図を表す専用データ形式）としてBundler（UserOperationを束ねてチェーンへ送る中継ノード）経由でEntryPoint（検証・実行・ガス精算を行う共通コントラクト）に届く経路を通ります。この経路が、ガス代の肩代わりや検証ロジックの自由度を支える一方、Bundlerとの接続やガス見積もりなど、通常のトランザクションにはない考慮点を持ち込みます。

    EIP-7702で委任したEOAは、従来どおり秘密鍵で通常のトランザクションを送れます。ユーザー自身がガス代を払う一括実行だけなら、Bundler等の専用インフラなしで動きます。ただしガス代の肩代わりを提供する段階になると、誰かがユーザーに代わってトランザクションを送り、ガスを立て替えるrelayer（中継者）の仕組みが必要になります。EIP-7702自体はrelayerの構成を規定しておらず複数のアーキテクチャがあり得ますが、ethereum.orgはインターフェースの標準化や検閲耐性の観点から、ERC-4337のBundler・Paymaster経路の利用を推奨しています（ethereum.org EIP-7702ガイドライン）。独自relayerの構築も可能ですが、標準インターフェースへの対応、検閲耐性、Paymaster連携などの比較検討が必要です。EntryPoint v0.8がEIP-7702をネイティブサポートし、7702委任先として設計された参照実装Simple7702Accountを同梱しているのは、この4337経路との合流を見込んだ整備です（eth-infinitism v0.8.0リリースノート）。

    観点ERC-4337EIP-7702
    規格の層アプリケーション層の標準（プロトコル変更なし）コア仕様の変更（2025年5月のPectraで導入）
    アカウント新規デプロイするコントラクトアカウントEOA（既存または新規生成）のまま委任先コードで拡張
    アドレスと資産既存EOAとは別アドレス（既存ユーザーは資産移動が必要）変わらない（移行の摩擦がない）
    秘密鍵の位置づけプロトコル上の迂回路はなく、権限構造は実装が定義（単一owner鍵を残す実装も規格適合）委任後も秘密鍵が最上位権限として残る
    実行経路UserOperation→Bundler→EntryPoint通常トランザクション。ガスレス等はrelayerが必要（4337経路が有力）
    採用実数（2026年8月時点）累計UserOperation約12.4億件、使用済みスマートアカウント約6,370万委任有効なEOA約4,656万、認可累計約2.19億件

    採用実数はいずれもAA統計サイトBundleBearの集計です（ERC-4337統計・EIP-7702統計、2026年8月11日閲覧）。どちらも実験段階ではなく、実運用の規模で使われています。

    判断を分ける4つの軸

    構造差を踏まえると、事業者の採用判断を実際に左右する軸は次の4つに絞れます。なお「どちらがガス代で有利か」という論点は、チェーン、アカウント実装、トランザクションのcalldata量・検証コストで結論が変わるため、一般論では決められません。絶対額が小さいL2（Ethereumの処理を肩代わりして高速・低コスト化する二層目のチェーン。以下L2）中心の展開では決め手になりにくい一方、トランザクション量の多いサービスやガス代を自社負担する構成では個別に試算すべき論点です（試算の枠組みはガスレストランザクションの経済性）。

    軸1: 既存のアドレス・資産・履歴を維持するか — 判断の起点

    これが判断の起点です。既存EOAユーザーのアドレス・資産・取引履歴を維持したままAA機能を足すなら、EIP-7702が唯一の選択肢です。ERC-4337への移行はアドレス変更と資産移動をユーザーに強います。7702の委任オプトインはMetaMaskのようにウォレット側の機能として提供が進んでおり（MetaMask Help Center、2026年8月11日閲覧）、事業者が委任フローを自作する必要はありません。むしろdApp（分散型アプリケーション）が認可署名を直接求める動線はフィッシングと区別できないため、置くべきではありません（詳細はEIP-7702の事業者向け解説）。

    一方、維持すべき資産・履歴がない新規ユーザーの獲得は、どちらか一方の規格の一択にはなりません。ERC-4337でスマートアカウントを発行する構成でも、新規にEOAを生成して7702委任する構成でも、ガス代の肩代わり、パスキー連携、アカウント復旧を備えた「ウォレットを意識させない」初回体験を作れます（ethereum.org 2026年版開発ガイド・Coinbase Developer Platform Docs、いずれも2026年8月11日閲覧）。両構成を分けるのは対象ユーザーの新旧ではなく、軸2の鍵の権限構造（7702では新規生成したEOAでも秘密鍵が最上位権限として残る）と、軸4のチェーン・ウォレット・SDK対応です。

    軸2: 鍵・復旧・マルチシグ要件 — 譲れない要件があれば4337＋実装選定

    次の要件がひとつでもあるなら、7702委任では満たせないためERC-4337のコントラクトアカウントを選びます。このとき、ERC-4337という規格の選択だけでは要件は満たせません。違い2で見たとおり単一owner鍵型の実装も規格に適合するため、単一owner鍵や単独のアップグレード権限を残さない実装・設定を併せて選定し、検証することまでがセットです。

    • 鍵を失っても資産を失わない設計：ソーシャルリカバリや鍵のローテーションを、回避不能なアカウントのルールとして組み込みたい場合。7702では元の秘密鍵が常に迂回路になります。
    • 複数人承認の強制：法人資産の管理などで「単独の鍵では動かせない」ことを保証したい場合。マルチシグはコントラクトアカウント（Safe等）の領域で、実装の比較はSmart Wallet スタック比較2026で扱っています。
    • 署名方式そのものの置き換え：ECDSA（従来のEOAが使う署名方式）の秘密鍵を廃してパスキーのみで運用する等、鍵の在り方自体を変えたい場合。7702はEOAの鍵を前提に機能を足す規格です（設計の詳細はPasskey（WebAuthn）× ERC-4337）。

    これらの要件は対象ユーザーの新旧と無関係に効きます。新規ユーザー向けにアカウントを新規発行する場合でも、該当する要件があるなら新規EOA＋7702委任ではなく、ERC-4337系の構成を要件を満たす実装・設定で選びます。

    軸3: 導入の重さ — 7702が軽いのは「インフラを持たない範囲」まで

    「7702は軽く、4337は重い」という比較は半分だけ正しい整理です。既存EOAユーザー向けに一括実行を提供するだけなら、7702はウォレット任せで済み、自社でBundlerやPaymasterを用意する必要がありません。導入の初速はここで大きく差が付きます。

    一方、ETHを持たないユーザーの操作を成立させるガス代肩代わりまで提供するなら、誰かがガスを立て替えて回収するrelayerの仕組みが必要になります。その有力な構成が、標準化が進みethereum.orgも推奨するERC-4337のBundler・Paymaster経路です（ethereum.org EIP-7702ガイドライン）。独自relayer構成を採ることも可能ですが、その場合も標準インターフェースとの互換性、検閲耐性、費用回収の設計を自前で比較・検証することになるため、提供したい機能がガスレスに及んだ時点で、7702を選んでいても4337インフラを含むrelayer構成の選定・運用が検討事項に入ります。費用構造はガスレストランザクションの経済性、Bundler・Paymaster・SDKの選定基準はAA開発スタックの選定2026で扱っています。

    軸4: 展開先チェーンとウォレット・SDKの対応 — 7702は環境側の対応が前提

    EIP-7702はコア仕様の変更であるため、展開先チェーンがハードフォーク（チェーン全体の仕様更新）で対応済みであることが前提になります。2026年8月時点でEthereumメインネットのほかBNB Chain、Base、OP Mainnet、Arbitrum、Unichain、Polygon、Gnosisなど主要EVMチェーンで委任が観測されていますが（BundleBear、2026年8月11日閲覧）、対応時期や周辺ツールの成熟度はチェーンごとに差があります。ERC-4337はコントラクト群のデプロイだけで成立するため、EVM互換チェーンであればほぼどこでも同じ構成を展開できます。マイナーチェーンや新興チェーンを含む多チェーン展開では、この差が効きます。

    チェーンだけでなく環境側の対応も同様です。新規EOA＋7702委任の構成を採るなら、EOAの生成・委任・ガス肩代わりを担うウォレット基盤やSDKが対象チェーンで7702をサポートしていることが、既存EOAユーザー向けなら利用者のウォレットが委任機能を提供していることが、それぞれ前提になります。

    併用という構成 — アカウント層は2系統、実行インフラは1系統

    4つの軸を適用した結果、「既存EOAユーザーの維持」と「新規ユーザーへの発行」の両方を抱えるサービスでは、ERC-4337型スマートアカウントとEIP-7702委任EOAを並走させる併用構成が有力な選択肢になります。

    併用と聞くと開発・運用コストの倍増を想像しますが、構造上そうはなりません。2系統に分かれるのはアカウント層（4337型スマートアカウントと7702委任EOA）だけで、その先の実行経路は合流するからです。EntryPoint v0.8以降、7702委任EOAはUserOperationの発行主体としてERC-4337のBundler・Paymasterをそのまま利用でき（eth-infinitism v0.8.0リリースノート）、ガス肩代わりの予算管理・残高監視・不正利用対策といった運用は1系統で共通化できます。主要なアカウント実装・SDKも両系統を同じインターフェースで扱う方向に整備が進んでいます（選定の詳細はAA開発スタックの選定2026）。ただし、ここで確認できるのは両系統が同一インフラへ合流できるという技術的な互換性までで、市場の大半が併用構成を採っているという採用実態の統計ではありません。自社で併用が必要かは、前掲のBundleBearの採用実数と自社ユーザー構成から判断してください。

    そもそも規格を選ばなくてよい事業者 — ERC-5792という答え

    ここまでの判断軸には重要な前提があります。この選択を本当に迫られるのは、ユーザーのアカウントを自社で発行・管理する事業者（ウォレット提供者、組み込みウォレットを持つサービス）だけだということです。

    ユーザーが外部ウォレットで接続するdApp・Webサービスの運営者は、規格を選ぶ必要がありません。ERC-5792（Wallet Call API、Final）のwallet_sendCallsを使えば、「複数の操作を一括で実行してほしい」「可能ならガス代を肩代わりしたい」という意図をウォレットへ渡すだけで、ユーザーのアカウントが7702委任EOAか4337スマートアカウントかはウォレット側が吸収します。ethereum.orgのdApp開発者向けガイドラインも、認可署名を直接扱わずこの経路を使うことを推奨しています（ethereum.org: EIP-7702ガイドライン）。dApp運営者にとっての実装対象は「4337か7702か」ではなく「ERC-5792対応と、非対応ウォレット向けのフォールバック」です。一括実行の具体的な実装はバッチトランザクションの実装で扱っています。

    選択フロー — 自社アカウントを持つ事業者の判断手順

    アカウントを自社で発行・管理する事業者向けに、ここまでの判断軸をフローとして整理します。

    ERC-4337とEIP-7702の選択フローチャート：既存EOAのアドレス・資産・取引履歴を維持する必要があればEIP-7702、秘密鍵を最上位権限に残せない要件（鍵レス設計・複数人承認の強制）があればERC-4337と単独鍵に絶対権限を残さない実装・設定の組み合わせ、どちらにも当たらない新規発行では展開先チェーンとウォレット・SDKの7702対応を確認し、対応していれば4337スマートアカウント発行と新規EOA＋7702委任の両方が候補、非対応ならERC-4337、迷う場合は両系統対応SDKで先行PoC
    図1: 選択フローチャート。起点は「既存のアドレス・資産・履歴を維持するか」
    • 既存アドレス・資産・履歴の維持が必須なら、それができる唯一の規格であるEIP-7702から入ります。ウォレット側の委任機能とERC-5792経由の呼び出しを使えば、自社インフラの初期投資を最小にできます。
    • 鍵レス設計・複数人承認の強制・回避不能なリカバリが要件なら、対象ユーザーに関わらずERC-4337系のコントラクトアカウントです。ただし規格の選択だけでは足りず、単独鍵に絶対権限を残さない実装・設定の選定と検証までがセットです。法人・マルチシグ要件はSafe系が定番です。
    • どちらにも当たらない新規アカウント発行なら、ERC-4337のスマートアカウント発行と、新規EOA生成＋7702委任の両方が候補です。展開先チェーンとウォレット・SDKの7702対応、そしてEOAの秘密鍵という境界が残ることを許容できるかで選びます。
    • 決め手がない段階なら、両系統を同一インターフェースで扱えるSDK・アカウント実装を選び、小さく検証してから決めます。規格ではなく抽象化レイヤーを先に決めることで、後からの切り替え余地を残せます。

    関連記事

    全体像と各規格の理解：

    実装・設計を進める：

    リスクを管理する：

    XTELAが支援できる範囲

    ERC-4337とEIP-7702の選択は、既存資産の維持要否、鍵・復旧要件、提供したい機能の範囲、展開先チェーンとウォレット・SDK対応が絡む意思決定です。XTELAは、この判断軸に沿った要件整理、アカウント実装・Bundler/Paymaster SaaS・SDKの比較選定、ERC-5792対応やガスレス構成のPoC実装、併用構成の設計まで、Web3サービスの技術面を支援しています。カストディ該当性など制度面の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術資料の整理を支援します。

    スマートアカウント・AA導入について相談する

    主要参考資料

    本記事の前提

    本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。両規格の採用統計、ウォレット・SDKの対応状況、チェーンごとの対応時期は今後変わり得ます。採用判断の際は最新の公式ドキュメントを確認し、法令・会計・税務の該当性判断は有資格の専門家に相談してください。

    記事一覧
    お問い合わせ

    どんなフェーズからでも、お持ちのアイデアや企画をもとにご提案可能です。
    まずはお気軽にご相談下さい！

    無 料当社PMに技術相談
    無料技術相談・お問い合わせ