EIP-7702の事業者向け解説｜既存EOAをアドレス変更なしでスマートアカウント化する仕組みと実装経路

コラム

／約14分で読めます

コラム

／約14分

EIP-7702の事業者向け解説｜既存EOAをアドレス変更なしでスマートアカウント化する仕組みと実装経路
目次（タップで折りたたみ）

    EIP-7702（仕様）は、2025年5月7日に有効化されたEthereumのPectraアップグレードで導入されたコア仕様で、EOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント）が、アドレス・資産・取引履歴をそのまま維持したまま、スマートコントラクトへアカウントの実行ロジックを委任（delegation）できるようにします（Ethereum Foundation公式ブログ）。事業者にとっての意味は明確で、MetaMask等の既存ウォレットのユーザーに「ウォレットの作り直し」や資産の移動を求めることなく、複数操作の一括実行、ガス代の肩代わり、パスキー署名といったスマートアカウント機能を提供できるようになりました。採用は既に実運用段階で、AA統計サイトBundleBearの集計では、委任を有効化した状態のEOAは主要EVMチェーン合算で約4,656万、認可（authorization）の累計は約2.19億件に達しています（BundleBear、2026年8月11日閲覧）。

    一方で、検索上位の解説には「トランザクションの間だけ一時的にコードを持つ」という説明が今も流通していますが、これは正確ではありません。EIP-7702の委任は、ユーザーが取り消すか別の委任で上書きするまで持続します（EIP-7702仕様）。1回の署名が持続的な権限委譲になるというこの性質は、UX上の価値と、後述するフィッシング・スイーパー問題の両方の起点です。本記事では、仕組み、2026年8月11日時点の採用状況、事業者が取るべき実装経路、セキュリティ設計の責任範囲を一次情報ベースで整理します。AA（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移し、ガス代の肩代わりやpasskeyログインなどを可能にする技術群。以下AA）全体の採用判断はAA完全マップ2026を参照してください。

    仕組み — 1つの署名でEOAに「委任先」が書き込まれる

    EIP-7702は、Ethereumに新しいトランザクションタイプ0x04（set codeトランザクション）を追加します。このトランザクションは通常のフィールドに加えて認可リスト（authorization list）を含み、各認可は[chain_id, address, nonce, y_parity, r, s]という組で構成されます。addressが委任先コントラクトで、EOAの秘密鍵による署名（y_parity, r, s）が「このコントラクトを自分のアカウントの実行ロジックとして認める」という意思表示です（EIP-7702仕様）。

    認可が処理されると、EOAのコード領域に0xef0100 || 委任先アドレスという23バイトのデリゲーション指示子（delegation designator）が書き込まれます。以後このEOAへの呼び出しは委任先コントラクトのコードへ転送して実行され、その際もmsg.senderは当該EOAのままです。事業者が設計判断のために押さえるべき仕様上のポイントは次の4点です。

    • 秘密鍵は最上位権限のまま：委任は「鍵の置き換え」ではなく「実行ロジックの追加」です。委任後もEOAの秘密鍵はアカウントを完全に支配し続け、鍵が漏えいすれば委任内容に関係なく資産を失います。
    • 委任は持続する：委任は取り消すか上書きするまで残ります。取り消しはゼロアドレス（0x0000…0000）を委任先に指定する認可で行い、アカウントのコードがクリアされます。
    • chain_idの範囲指定：認可のchain_idを0にすると、全EVM互換チェーンで有効な認可になります。意図しないチェーンでの有効化を避けるため、実務ではチェーンごとに明示するのが原則です。
    • nonceによるreplay防止：認可はEOAの現在のnonceと一致している必要があり、処理時にnonceが1進みます。同じ認可を再利用する攻撃（replay）はこの仕組みで抑止されます。

    事業者にとって何が変わるのか — 「新規ユーザー限定」だったAA機能が既存ユーザーに届く

    複数操作の一括実行、ガス代の肩代わり、セッションキーやパスキーによる署名といった機能自体は、ERC-4337のスマートアカウント（詳細はERC-4337の事業者向け解説）で2023年から技術的に提供可能でした。実務上のボトルネックは、これらの機能が「新しくスマートアカウントを作成した（＝既存資産の移動を受け入れた）ユーザー」にしか届かなかったことです。EIP-7702の事業インパクトは、この一点の解消に集約されます。既存EOAユーザーへ提供できるようになった価値は、主に次の3つです。

    承認と実行の一括化：ERC-20トークンのapprove（利用許可）と本体操作を、1回の署名・1トランザクションにまとめられます。DEX（分散型取引所）での交換、決済、ゲーム内購入などで「2回署名して2回待つ」離脱要因を取り除けます。実装パターンはバッチトランザクションの実装で扱っています。

    ガス代の肩代わり：Paymaster（ガス代を肩代わりする仕組み）と組み合わせることで、ETHを保有していないユーザーでも操作を完了できます。NFT配布やロイヤリティ施策など、暗号資産に不慣れな層を対象にするサービスで初回体験の障壁を下げます。費用構造と回収設計はガスレストランザクションの経済性を参照してください。

    鍵と権限の再設計：委任先ロジック次第で、時間・金額・呼び出せる関数を限定した一時権限（セッションキー）や、Face ID・Windows Hello等で署名するパスキー（WebAuthn）検証を既存EOAに追加できます。設計の詳細はPasskey（WebAuthn）×ERC-4337の設計で扱っています。

    採用の現在地（2026年8月）— 普及はウォレット主導で進んでいる

    BundleBearの集計（EIP-7702統計、2026年8月11日閲覧）では、追跡対象チェーン（Ethereum、BNB Chain、Base、OP Mainnet、Arbitrum、Unichain、Polygon、Gnosis）の合算で、委任が有効な状態のEOAが約4,656万、認可の累計が約2.19億件、set codeトランザクションの累計が約9,080万件です。有効化から1年強で、EIP-7702はEthereumメインネットだけでなく主要EVMチェーンにまたがる規模で使われています。

    この普及を牽引しているのはdApp（分散型アプリケーション）ではなくウォレットです。例えばMetaMaskは、アカウント詳細画面からの明示的なオプトインで既存EOAをスマートアカウントへ切り替える機能を提供しています。切り替えはネットワーク単位で、少額のガス代を支払って有効化し、同じ手順でいつでも元のEOAへ戻せます。その間アドレスは変わらず、資産も移動しません（MetaMask Help Center、2026年8月11日閲覧）。

    事業者への含意は、ユーザーの委任状態を自社で作りにいく必要はなく、また作りにいくべきでもないということです。委任のオプトインと管理はユーザーとウォレットの間で完結しつつあり、事業者側は「委任済みユーザーがこれからも増えていく」前提で、ウォレット経由で機能を検出して活用する設計を取ります。その具体的な経路を次章で整理します。

    実装の正規経路 — 認可署名を自社で集めない

    ethereum.orgのdApp開発者向けガイドラインは、dAppがEIP-7702の認可署名をユーザーへ直接要求するのではなく、標準化されたウォレットインターフェースを経由して機能を利用することを推奨しています（ethereum.org: Pectra EIP-7702ガイドライン）。事業者の立場ごとに取るべき経路は次のとおりです。

    事業者の立場取るべき経路使う標準・実装（2026年8月時点）
    dApp・Webサービス運営者ウォレットに一括実行やガス肩代わりを「依頼」する。認可署名を直接要求しないERC-5792のwallet_sendCalls（Final）。一括実行（atomic）やPaymaster連携をcapabilityとして検出して使う。ユーザーのアカウントが7702委任か4337スマートアカウントかはウォレット側で抽象化される（ERC-5792仕様）
    自社ウォレット・組み込みウォレット提供者委任先コントラクトを選定し、認可フローと取り消しフローを実装する監査済みの委任先実装（Simple7702Account、MetaMask Delegation Framework、Alchemy Modular Account、Uniswap Calibur等。ethereum.org掲載）。クライアント側はviemのsignAuthorization等（viem EIP-7702ドキュメント）
    ERC-4337ベースの既存サービス既存インフラのまま7702委任ユーザーを受け入れるEntryPoint v0.8がEIP-7702をネイティブサポートし、7702委任先として設計された最小実装Simple7702Accountを同梱。Bundler・Paymasterは既存のものをそのまま利用可（eth-infinitism v0.8.0リリースノート）

    共通する原則は2つです。第一に、委任先コントラクトを自作・独自フォークしないこと。委任先はユーザー資産の実行ロジックそのものであり、独自実装は監査責任を自社で負うことを意味します。第二に、委任先ロジックの更新方法を最初に決めておくことです。ethereum.orgはproxyパターンによるアップグレード（再認可を不要にする）を推奨していますが、その場合は後述するとおり、運営者がユーザーに気付かれずロジックを差し替えられるという裏面を設計で抑える必要があります。SDK・Bundler・Paymasterを含むスタック全体の選定基準はAA開発スタックの選定2026で扱っています。

    セキュリティ — 「委任の97%が悪性」の正しい読み方と事業者の設計責任

    マーケットメイカーWintermuteの研究チームは2025年6月、当時のEIP-7702委任の97%超が、同一バイトコードを使い回した悪性コントラクトへ向けられていたと報告しました。これらは「スイーパー（sweeper）」、つまりEOAに入ってきた資産を即座に攻撃者のアドレスへ吸い出す自動化コントラクトで、同チームはCrimeEnjoyorと命名してバイトコードの逆コンパイルと注意喚起タグ付けを行いました（Wintermute（X投稿）、CoinDesk 2025年6月2日）。

    この数字は「EIP-7702が危険な仕様である」ことを意味しません。スイーパーの標的は既に秘密鍵が漏えいしているEOAです。攻撃者は盗んだ鍵で被害者のEOAに委任を仕込み、後から入ってくる資産の回収を自動化します。つまり7702が鍵を盗むのではなく、鍵漏えい後の被害回収を高速化・自動化する道具として最初に大規模利用された、というのが統計の実態です。事業者が読み取るべき教訓は2つあります。第一に、秘密鍵漏えいの致命度が上がったこと。第二に、委任署名そのものが新しいフィッシングの標的になったことです。1回の署名で持続的な実行権限を渡せる性質を突き、偽の無料ミント等で悪性コントラクトへの認可署名へ誘導する手口は、学術研究でも新しい攻撃類型として分析されています（arXiv:2512.12174「EIP-7702 Phishing Attack」、2025年12月）。

    これを踏まえ、EIP-7702に関わるサービスを提供する事業者が設計段階で確認すべき項目は次のとおりです。

    • 認可署名を直接求めるUI・APIを置かない：dAppとしてはERC-5792経由に限定します。「サイトがEOAに任意のコントラクトを委任させる」動線は、それ自体がフィッシングと区別できません。
    • 委任先の変更に統制をかける：自社ウォレットの委任先は監査済み実装から選び、ロジック差し替えができるproxy構成にする場合は、差し替え時の再認可要求や変更告知を設計に組み込みます。
    • chain_id=0の一括認可を既定にしない：全チェーン有効の認可はユーザーの認識と乖離しやすく、意図しないチェーンでの露出を生みます。
    • 取り消し動線を用意する：委任の取り消し（ゼロアドレスへの委任）に対するウォレットのUI対応は2026年時点でもまちまちです（Curvegrid 2026年2月13日）。自社サービスのユーザー向けに、取り消し手順の案内とサポート手順を整備します。
    • 委任状態を確認してから重要操作を行う：EtherscanはEIP-7702委任済みアドレスに「Delegated to」を表示し（Etherscan Information Center）、CurvegridのDelegation Checkerのような確認ツールもあります。入出金や高額操作の前に委任先を確認するオペレーションを組み込みます。

    フィッシング以外も含むAA全体の脅威モデルと対策はAAセキュリティリスクで体系的に扱っています。

    ERC-4337との関係 — 置き換えではなく、既存EOAを4337インフラへつなぐ入口

    「EIP-7702はERC-4337を置き換えるのか」という問いへの答えは明確で、置き換えではなく補完です。ERC-4337はEthereumのコア仕様を変えずに、UserOperation・Bundler・EntryPoint・Paymasterという独自のインフラでAAを実現するアプリケーション層の規格です。一方EIP-7702はコア仕様の変更で、既存EOAに「コントラクトのロジックを持たせる」能力を与えます。7702で4337互換のウォレット実装へ委任したEOAは、UserOperationを処理できるようになり、既存のBundler・Paymasterエコシステムをそのまま利用できます。EntryPoint v0.8が7702をネイティブサポートしたことで、この合流はインフラレベルで整備済みです（eth-infinitism v0.8.0リリースノート）。

    実務では「ウォレットを持たない新規ユーザーにはERC-4337でスマートアカウントを発行し、既存EOAユーザーにはEIP-7702で同等機能を届ける」という併用が標準形です。自社サービスでどちらを主にすべきかの判断軸はERC-4337 vs EIP-7702の判断軸で詳しく扱っています。

    よくある質問

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

    取り消せます。委任先にゼロアドレス（0x0000…0000）を指定する認可を発行すると、EOAのコードがクリアされ委任前の状態に戻ります（EIP-7702仕様）。ただし取り消し用UIの実装状況はウォレットによって差があり（Curvegrid、2026年2月時点）、MetaMaskのように切り替え・解除の双方向をサポートするウォレットでも、それぞれにガス代がかかります。

    EIP-7702を使うと秘密鍵は不要になりますか？

    不要になりません。委任後もEOAの秘密鍵がアカウントの最上位権限であり続け、漏えいすれば委任内容に関係なく資産を失います。パスキー署名やセッションキーは、委任先コントラクトが検証する「追加の鍵」であり、秘密鍵の置き換えではありません。秘密鍵の管理体制が引き続きセキュリティの土台になります。

    EIP-7702はEthereumメインネット以外でも使えますか？

    使えます。2026年8月時点で、BNB Chain、Base、OP Mainnet、Arbitrum、Unichain、Polygon、Gnosisなど主要EVMチェーンでEIP-7702の委任が観測されており、統計上はEthereum単独ではなく多チェーンの現象になっています（BundleBear、2026年8月11日閲覧）。ただしチェーンごとに対応時期や周辺ツールの成熟度は異なるため、展開先ごとの動作確認が必要です。認可のchain_idはチェーンごとに明示し、0（全チェーン有効）を既定にしないでください。

    関連記事

    全体像を押さえる：

    実装・設計を進める：

    リスクを管理する：

    XTELAが支援できる範囲

    EIP-7702への対応は、対象ユーザー層（既存EOAか新規か）、ウォレット戦略、委任先実装の選定、ERC-5792対応、Paymaster連携の経済性が絡む意思決定です。XTELAは、7702対応の要否と優先度の整理、委任先コントラクト・ウォレットSDKの比較評価、ERC-5792やガスレス構成のPoC実装、本番化に向けたセキュリティ設計まで、Web3サービスの技術面を支援しています。カストディ該当性など制度面の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術資料の整理を支援します。

    EIP-7702対応について相談する

    主要参考資料

    本記事の前提

    本記事は2026年8月11日時点で確認した一次情報に基づく技術解説であり、投資助言・法的助言ではありません。委任統計、ウォレットの機能、各実装の対応状況は今後変わり得ます。採用判断の際は必ず各プロジェクトの最新の公式ドキュメントを確認してください。

    記事一覧
    お問い合わせ

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

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