アカウントアブストラクション（AA）完全マップ 2026｜ERC-4337とEIP-7702の関係と採用判断

コラム

／約21分で読めます

コラム

／約21分

アカウントアブストラクション（AA）完全マップ 2026｜ERC-4337とEIP-7702の関係と採用判断
目次（タップで折りたたみ）

    ERC-4337とEIP-7702は、どちらか一方を選ぶ競合規格ではなく補完関係にあります。ERC-4337は「スマートコントラクトそのものをアカウントとして新規に使う」ためのアプリケーション層の標準、EIP-7702は「既存のEOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント。MetaMask等の標準はこれ）にスマートコントラクトの機能を委任する」プロトコル変更です。2026年時点では、ウォレットを持たない新規ユーザーにはERC-4337型のスマートアカウントを発行し、既存EOAユーザーにはEIP-7702で同じ機能を提供する併用構成が有力な選択肢であり、本記事もこの構成を推奨します。したがって事業者が決めるべきことは「どちらの規格に賭けるか」ではなく、アカウントアブストラクションを構成する4つの層（EntryPoint・Bundler・Paymaster・Account）のうちどこまでを外部サービスに任せ、どこからを自社で持つかです。

    本記事は、アカウントアブストラクション（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移し、ガス代の肩代わりや生体認証ログインなどウォレットUXを柔軟にする技術群。以下AA）の全体像を、Web3サービスの採用判断に使える形で整理するマップです。規格の関係、4層構造、普及状況の実数、採用形態の判断軸、実装の選択肢、認証・鍵管理、ガスレスの経済性、セキュリティと日本の制度動向までを2026年8月11日時点の一次情報で更新し、個別の深掘りは各詳細記事へ接続します。

    ERC-4337とEIP-7702の関係 — 競合ではなく補完

    2つの規格は「アカウントをプログラマブルにする」という同じゴールに、別の入口から到達します。

    ERC-4337（仕様）は、EthereumのプロトコルにもEVMにも変更を加えず、コントラクトとオフチェーンインフラの組み合わせでAAを実現する標準です。ユーザーの操作は通常のトランザクションではなくUserOperationという形式で表現され、Bundler（ユーザー操作をまとめてチェーンへ送信する中継役）が束ねてEntryPointコントラクトに投入します。アカウントはスマートコントラクトとして新規にデプロイされるため、署名方式（passkey等）、権限管理、リカバリをコントラクト側で自由に設計できます。2023年3月からメインネットで稼働しており、プロトコル変更が不要という性質上、EVM互換チェーン・Layer 2（Ethereumの処理を肩代わりして高速・低コスト化する二層目のチェーン。以下L2）へ広く展開済みです。

    EIP-7702（仕様）は、2025年5月7日に有効化されたEthereumのPectraアップグレード（Ethereum Foundation公式ブログ）で導入されたプロトコル変更です。EOAが署名付きの委任（authorization）を発行すると、そのEOAのアドレスに指定したコントラクトのコードが紐付き、アドレスを変えないままバッチ実行・ガス代肩代わり・柔軟な署名検証といったスマートアカウントの機能を使えるようになります。既存ユーザーに「新しいアドレスへの資産移動」を求めずにAAの恩恵を届けられる点が本質です。

    使い分けの基準は対象ユーザー層です。

    対象適する経路理由
    ウォレットを持たない新規ユーザーERC-4337型スマートアカウントpasskey等で最初からコントラクト型アカウントを発行でき、EOAを経由する理由がない
    MetaMask等の既存EOAユーザーEIP-7702委任アドレスと資産をそのままに、バッチ実行・ガス代肩代わりを追加できる
    機関・DAOの資産管理ERC-4337型（マルチシグ）複数承認者・権限分掌が要件になり、恒久的なコントラクトアカウントが自然

    2つの経路は基盤も共有し始めています。ERC-4337の中核コントラクトEntryPointは、2025年3月公開のv0.8でEIP-7702をネイティブサポートし、EOAが安全に委任先へ指定できる監査済みの最小実装「Simple7702Account」がこのv0.8で追加されました（eth-infinitism v0.8.0リリースノート）。2025年11月16日公開の最新版v0.9もこの対応を引き継ぎ、v0.7・v0.8とABI互換を保ったままPaymaster処理の並列化などの改善を加えています（eth-infinitism v0.9.0リリースノート）。7702で委任したEOAが、既存のBundler・Paymasterエコシステムをそのまま使う方向で整備が進んでいます。規格それぞれの深掘りはERC-4337の事業者向け解説とEIP-7702の事業者向け解説、選択の判断軸はERC-4337 vs EIP-7702の判断軸で扱っています。

    AAを構成する4つの層 — 「どこまで自社で持つか」を決める単位

    AAシステムはERC-4337の主要コンポーネントに沿って4つの層に分解でき、採用判断・費用見積もり・責任分界はこの層の単位で行うのが実務的です。

    AAの4層構造（EntryPoint・Bundler・Paymaster・Account）の関係図
    図1: AAの4層構造。事業者の設計判断は層の境界で行う。図内の事業者名とEntryPointのバージョン表記は図作成時点（2025年前半）のもので、Coinbase Smart Walletは現在のBase Accountに改称済み、EntryPointの最新版はv0.9（2025年11月公開）。現行の主要事業者は本文の各層の説明を参照

    EntryPoint（検証・実行の単一窓口）：UserOperationの署名・nonce・ガス・Paymasterの支払い能力を検証してから実行する共通コントラクトです。ERC-4337の提案者らが主導する開発チームeth-infinitismが参照実装を開発・監査しており、バージョンごとに定められた同一アドレスのシングルトンとして各チェーンへデプロイされます。2026年8月時点ではv0.6／v0.7／v0.8の各デプロイと、2025年11月16日公開の最新版v0.9（v0.7・v0.8とABI互換）が併存しています（eth-infinitism v0.9.0リリースノート）。事業者が独自に実装・改変するのではなく公式デプロイをそのまま使うのが前提で、確認すべきは、(a) 採用するアカウント実装・Bundlerが対応するEntryPointバージョン、(b) 接続先のデプロイアドレスとcode hashが公式リリース・監査報告と一致していること、の2点です。v0.9.0リリースノート自身も、更新前にデプロイアドレスとcode hashを公式監査報告と照合するよう明記しています。

    Bundler（UserOperationの中継層）：ユーザー操作を集めてEntryPointへ投入するノード事業者です。Pimlico、Alchemy、Coinbase、Etherspot（Skandha）、Candideなどの商用・OSS実装が複数併存しており、標準に準拠していれば事業者間の乗り換えが可能です。自社運用は高可用性・ガス見積もり・チェーン再編成（reorg）対応などの運用負荷を伴うため、まずSaaS利用を前提に検討し、要件が固まってから自社ホストを評価するのが現実的です。

    Paymaster（ガス代の支払い差し替え層）：ユーザーの代わりに事業者やスポンサーがガス代を支払う仕組みです。全額を事業者が負担するスポンサー方式、ユーザーがステーブルコイン等で支払うERC-20方式、オフチェーンの承認判断を署名で持ち込むVerifying方式が実用化されています。ガスレスUXの費用が直接発生する層であり、経済性の設計は後述します。

    Account（スマートアカウント本体）：ユーザーのアカウントとして機能するスマートコントラクトです。署名方式、権限管理、リカバリ、モジュール拡張など、プロダクトの差別化に最も直結する層で、Safe、Kernel（ZeroDev）、Nexus（Biconomy）、LightAccount（Alchemy）などの監査済み実装から選ぶのが基本です。モジュール型の共通規格としてERC-7579・ERC-6900があり、準拠実装を選ぶと将来の乗り換え・機能追加の余地が残ります。

    4層で見る利点は3つあります。第一に、「Bundlerは外部SaaS、PaymasterとAccountは自社設計」のように自社範囲を層の境界で言語化できること。第二に、費用構造が層ごとに異なる（EntryPointは無償の共有インフラ、BundlerはSaaS利用料、Paymasterはガス原資と運用、Accountは実装・監査費）ため見積もりが層単位で立てられること。第三に、標準準拠の範囲では層ごとに代替事業者へ移行できるため、どの層のベンダーロックインを許容するかを選べることです。

    2026年8月時点の現在地 — 実数とマイルストーン

    「AAは本当に使われているのか」への答えは、公開データで確認できます。AA特化の統計サイトBundleBearによると、追跡対象のEVMチェーン合算で累計UserOperation数は約12.3億件、1件以上のUserOperationを実行したスマートアカウントは約6,360万に達しています（BundleBear、2026年8月11日閲覧）。マルチシグ型の代表であるSafeは、2026年Q1報告で累計6,111万アカウント、預かり資産352.5億ドル、四半期1.229億件のトランザクション、累計処理価値1.4兆ドル超を公表しています（Safe Foundation Q1 2026四半期報告）。

    規格・インフラ・業界構造の主要マイルストーンを時系列で並べると、規格の整備と大手事業者の参入が2025年から2026年に集中し、採用判断の前提が実験段階から大きく変わったことが分かります。

    時期出来事事業者にとっての意味
    2023年3月ERC-4337がEthereumメインネットで稼働プロトコル変更なしのAAが実用開始
    2025年3月26日EntryPoint v0.8公開EIP-7702ネイティブ対応、EIP-712ベース署名で4337と7702の基盤が合流。Simple7702Accountを追加
    2025年5月7日PectraアップグレードでEIP-7702有効化既存EOAへの機能委任が可能に。既存ユーザーを移行なしでAAへ
    2025年6月StripeがEmbedded Wallet大手Privyの買収を発表（CoinDesk）決済大手がウォレット基盤を内製化。WaaS層の再編が進行
    2025年7月Coinbase WalletがBase Appへ改称、Smart WalletはBase Accountに（CoinDesk）大手取引所が大衆向けアプリの中核にpasskey型スマートアカウントを採用
    2025年11月16日EntryPoint v0.9公開（最新版）v0.7・v0.8とABI互換のまま改善。既存のAccount・Paymaster実装は変更不要
    2025年12月3日FusakaアップグレードでEIP-7951（P-256検証プリコンパイル）有効化（Ethereum Foundation公式ブログ）passkey署名（secp256r1）の検証がL1でネイティブ化し、生体認証ログインのコストが低下
    2026年6月1日改正資金決済法が施行（金融庁2026年5月22日公表資料）「電子決済手段・暗号資産サービス仲介業」が新設。国内でのウォレット関連事業の位置付けに影響
    2026年7月15日暗号資産規制を金融商品取引法へ移管する改正法が成立（日本経済新聞）暗号資産が金融商品として規制される時代へ。施行は2027年度にも

    この2年で「使えるインフラがあるか」という問いは解消され、論点は「複数ある選択肢のどれを、どの深さで採用するか」へ移りました。以降の章はその判断のための材料です。

    採用形態は3つ — 「使う・組む・自社実装」

    AAをプロダクトへ取り込む深さは、次の3形態に整理できます。

    形態A「使う」：Embedded Wallet／WaaS（Wallet as a Service：ウォレット発行・鍵管理・署名をSDKで提供する外部サービス）を組み込み、アカウント発行から署名・リカバリまでをベンダーに任せる形です。Privy（Stripe傘下）、Dynamic、Web3Auth、Turnkeyなどが該当します。実装工数が最小で、Web2ユーザー向けのオンボーディングを最短で作れる一方、鍵管理の構造がベンダー依存になります。採用時に必ず確認すべきは、鍵またはアカウントのエクスポート経路（ユーザー数が伸びた後に他構成へ移行できるか）と、後述するカストディ該当性の整理です。

    形態B「組む」：Safe・Kernel・Nexus等の監査済みオープンソース実装を土台に、自社でアカウント構成・Paymaster条件・カスタムモジュールを設計し、BundlerはSaaSを使う形です。自社ブランドのウォレット体験や独自の権限設計を作り込めますが、コントラクト部分の監査費用と、スポンサー条件・残高監視などの運用設計が自社責任になります。

    形態C「自社実装」：アカウント実装からBundler運用までを内製する形です。ウォレット自体が中核事業である場合や、外部インフラに置けない規制・機密要件がある場合に限られます。継続的な監査・運用体制が前提となるため、「要件を分解すると形態Bと外部サービスの組み合わせで足りないか」を先に検証する価値があります。

    判断軸A: 使うB: 組むC: 自社実装
    主な費目SaaS利用料＋スポンサーガス実費実装・監査費＋Bundler SaaS＋スポンサーガス実費開発・監査・ノード運用・24時間監視体制
    差別化の余地小（UIとスポンサー条件）中〜大（アカウント設計・権限・モジュール）大（全層）
    セキュリティ責任主にベンダー側コントラクト部分は自社全層で自社
    ロックインの所在鍵管理・SDK選定した実装とモジュール規格なし（全て自社資産）
    移行のしやすさエクスポート経路次第ERC-7579等の準拠実装なら比較的容易—

    実務では「形態Aで検証し、事業が伸びたら形態Bへ移す」段階移行を前提に置くのが安全です。その際に効くのが、最初の選定時点でエクスポート経路とモジュール規格（ERC-7579／ERC-6900）準拠を確認しておくことです。移行できない構成を選ぶと、ユーザー資産の引っ越しという最も難しい問題を後で抱えることになります。

    スマートアカウント実装の主要な選択肢

    Account層の代表的な実装は次の5系統です。いずれも複数の第三者監査を経て本番運用されています（各実装の詳細は個別記事で扱います）。

    実装提供主体特徴向く用途
    SafeSafe Ecosystem Foundationマルチシグの事実上標準。Q1 2026時点で預かり資産352.5億ドル（公式報告）機関・DAO・社内トレジャリー
    KernelZeroDevERC-7579準拠のモジュール型。passkey・Session Key等のプラグインが充実スタートアップ・B2CのdApp
    NexusBiconomyERC-7579準拠。ガス代肩代わり（ガスレス）と一体の設計、マルチチェーン実行ゲーム等の小口・高頻度操作
    LightAccountAlchemyガス効率重視の軽量実装。Alchemyのインフラと一体で導入が速いAlchemy採用組織の最短ルート
    Base Account（旧Coinbase Smart Wallet）Coinbasepasskey前提の大衆向け設計。2025年7月にBase Appへ統合（CoinDesk）Web2大衆向けB2C

    選定の観点は、(a) 対象ユーザー（機関か大衆か）、(b) モジュール規格への準拠（将来の移行・拡張余地）、(c) Bundler・Paymasterを同一ベンダーで揃えるか独立に選ぶか、の3つに集約されます。5実装の横並び比較はSmart Walletスタック比較 2026、Bundler・SDKまで含めた組み合わせはAA開発スタックの選定で詳しく扱っています。

    認証と鍵管理 — 秘密鍵を見せないUXの部品

    スマートアカウントの価値の中心は「秘密鍵・シードフレーズをユーザーに管理させない」ことにあり、その部品は4つです。

    passkey（WebAuthn）：スマートフォンやPCのセキュア領域に鍵を保管し、Face ID・指紋認証で署名する方式です。passkeyが使うP-256（secp256r1）曲線の署名検証は従来EVM上で高コストでしたが、主要L2が先行導入したP-256検証プリコンパイル（RIP-7212）に続き、L1でも2025年12月3日のFusakaアップグレードでEIP-7951としてネイティブ化され、コスト面の障壁が解消に向かいました（Ethereum Foundation公式ブログ）。詳細はPasskey（WebAuthn）× ERC-4337を参照してください。

    Session Key（一時権限鍵）：用途・期限・上限額を限定した一時的な操作権限を発行し、ゲームなどで毎回の署名確認なしに操作を続けられるようにする仕組みです。権限の絞り込み設計を誤ると資産流出につながるため、設計論点はSession Keyの設計で整理しています。

    Social Recovery（ソーシャルリカバリ）：事前に指定した復旧承認者（Guardian）の合意で署名鍵を再設定できる仕組みで、「シードフレーズ紛失＝資産喪失」を構造的に避けられます。Guardianを誰にするか（事業者自身がなる場合はカストディ該当性の検討が必要）が主要論点です。実装パターンはSocial Recoveryの実装パターンで扱います。

    MPC（Multi-Party Computation：秘密計算による鍵分散）：秘密鍵を単一の完全な形で存在させず、複数の鍵シェアの分散計算で署名する方式です。厳密にはAAとは独立のオフチェーン技術ですが、Embedded Walletの多くが内部で採用しており、スマートアカウントと組み合わせる構成が機関向けで一般的です。MPC × AAで詳述しています。

    実プロダクトでは単一方式ではなく、「passkeyで日常署名＋Social Recoveryで復旧＋Session Keyでアプリ内連続操作」のように組み合わせて設計するのが実務的です。バッチ実行（複数操作の1トランザクション化）と合わせると、Web2アプリと遜色ない操作感を実現できます（バッチトランザクション）。

    ガスレスの経済性 — 「誰がガス代を払うか」の設計

    ガスレスは「ユーザーが払わない」だけで、ガス代そのものは消えません。Paymaster層の設計は、負担者の置き方で3つに大別されます。

    • 全額スポンサー方式：事業者がガス代を全額負担します。オンボーディング効果が最も大きい一方、負担額はそのまま事業コストです。
    • ERC-20ガス決済方式：ユーザーがステーブルコイン等でガス代相当を支払い、Paymasterがネイティブトークンを立て替えます。事業者負担は小さく、「ETHを持っていないと動けない」問題だけを解消します。
    • 条件付きスポンサー方式：初回N回・特定操作・認証済みユーザーのみなど、承認条件を絞って負担します。スポンサー費用を管理しながらオンボーディング効果を得られるため、本記事では検討の起点に置くことを推奨します。条件設計そのものが競争力になります。

    スポンサー総額の概算は「月間アクティブユーザー数 × 1人あたり月間操作回数 × 1操作あたりガス単価」で置けますが、ガス単価はチェーンと操作内容で桁単位に変わるため、机上の仮定ではなく対象チェーン・対象操作での実測値を使うべきです。また、スポンサー原資を狙ったbot・大量作成アカウントによるただ乗り（Free-rider）と、原資枯渇時に全ユーザーの取引が止まる障害は、ガスレス運用の二大リスクです。承認ロジック・上限・監視アラートを実装してから本番公開する必要があります。損益分岐の考え方とモデル別の試算手順はガスレストランザクションの経済性で詳しく扱っています。

    セキュリティと日本の制度動向

    EIP-7702の委任フィッシング — 実際に起きたこと

    EIP-7702の有効化直後から、委任機能はフィッシング被害の拡大に悪用されました。Wintermuteのリサーチチームは2025年5月末、メインネット上のEIP-7702委任の97%超が、同一コードをコピーした「sweeper」（流出済みの秘密鍵で管理されたアドレスに入ってくる資産を自動で抜き取るコントラクト）へ向いていたと報告しています（Wintermute公式X、2025年5月30日、CoinDesk）。これは規格自体の欠陥ではなく、すでに秘密鍵が漏洩したアカウントの資金回収を7702が自動化・効率化してしまったという構図ですが、その後は委任署名を騙し取るフィッシングも観測されており、攻撃対象領域が広がったことは事実です（EIP-7702 Phishing Attack、2025年12月）。

    事業者側の対策は明確です。(1) ユーザーに委任させる場合は、EntryPoint v0.8で追加されv0.9にも引き継がれているSimple7702Accountのような監査済みの委任先実装のみを提示する、(2) 委任先アドレスと権限内容をユーザーが確認できる署名UIを実装する、(3) Session Key等の権限は最小範囲に絞る、(4) アカウント実装・カスタムモジュールは第三者監査を通す。攻撃パターンの全体像と監査観点はAAセキュリティリスクで整理しています。

    日本の制度動向 — 2025〜2026年の2つの改正

    日本でAAを組み込んだサービスを提供する場合、技術設計と並行して制度の確認が必要です。直近の変化は2つあります。第一に、2025年6月に成立した改正資金決済法が2026年6月1日に施行され、利用者資産を預からずに取引の媒介のみを行う登録業として「電子決済手段・暗号資産サービス仲介業」が新設されました（施行に係る政令等は金融庁2026年5月22日公表資料）。第二に、暗号資産規制を資金決済法から金融商品取引法へ移管する改正法が2026年7月15日に成立し、施行は2027年度にも見込まれます（金融庁 法律案説明資料、日本経済新聞）。

    AA設計への直接の含意は「誰が鍵を管理しているか」の整理です。Embedded WalletやSocial Recoveryの構成によっては、事業者がユーザー資産を実質的に管理する（カストディに該当し得る）構造になり、暗号資産カストディ業務の該当性検討が必要になります。逆に、ユーザーのみが署名でき事業者が鍵に触れない構成を取るなら、それを技術的に説明できる文書（鍵管理アーキテクチャ、監査報告）を用意しておくことが制度対応の土台になります。該当性の判断そのものは弁護士等の有資格専門家の領域であり、本記事および当社が行うのは技術設計側の論点整理までです。制度の詳細はAAと日本規制で扱っています。

    よくある質問

    EIP-7702の委任は取り消せますか？

    取り消せます。EIP-7702の委任はアドレスに紐付くdelegation designator（委任先の指定情報）を書き換えることで変更でき、委任先をゼロアドレスに指定する新しいauthorizationを発行すればコードの紐付けを解除して通常のEOAに戻せます（EIP-7702仕様）。ただし取り消しにもトランザクションが必要なため、ウォレットUI側の対応状況を確認してください。

    アカウントアブストラクションはEthereum以外のチェーンでも使えますか？

    ERC-4337はスマートコントラクトとオフチェーンインフラだけで成立するため、Base・Arbitrum・Optimism・Polygon等の主要なEVM互換チェーン・L2で広く利用でき、チェーン横断の利用統計も公開されています（BundleBear）。一方EIP-7702はプロトコル変更のため、各チェーンが対応アップグレードを実施している必要があります。採用予定チェーンごとに、EIP-7702対応の有無とEntryPointのデプロイ状況を公式ドキュメントで確認してください。

    既存のdApp（コントラクト）側は、AA対応のために変更が必要ですか？

    多くの場合、コントラクト本体の変更は不要です。スマートアカウントからの呼び出しは通常のコントラクト間呼び出しとして届くためです。ただし2点だけ確認が必要です。第一に、tx.originとmsg.senderの一致チェックや「コードを持つアドレスを拒否する」実装は、スマートアカウント（および7702委任後のEOA）からの利用を壊します。第二に、オフチェーン署名（ログイン認証や注文署名など）を検証している場合は、コントラクトアカウントの署名検証標準であるERC-1271への対応が必要です。

    目的別に読み進める — 関連記事マップ

    本記事は全体像のマップです。判断・実装を進める段階に応じて、以下の詳細記事へ進んでください。

    規格を正確に理解する：

    実装を選定する：

    認証・鍵管理を設計する：

    経済性・リスク・制度を確認する：

    XTELAが支援できる範囲

    AAの採用判断は、対象ユーザー・収益モデル・チェーン選定・鍵管理の各判断が絡み合うため、「どの層をどこまで自社で持つか」の整理から始めるのが近道です。XTELAは、AA採用の要件定義、スマートアカウント実装・WaaSの比較選定、PoC実装、スポンサー承認ロジックと監視・アラートの運用設計まで、Web3サービスの技術面を支援しています。カストディ該当性など制度面の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術資料の整理を支援します。

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

    主要参考資料

    本記事の前提

    本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。規格のバージョン、各社の製品構成・料金、利用統計、法令の施行時期・内容は今後変わり得ます。採用判断の際は最新の公式ドキュメント・官庁資料を確認し、法令・会計・税務の該当性判断は有資格の専門家に相談してください。

    記事一覧
    お問い合わせ

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

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