ERC-7702 AI エージェント向け EOA 委任入門

要約

ERC-7702 (Pectra 以降に稼働、2025-05)は、既存の外部所有アカウント(EOA)に対し、アドレスを変更することなく、一時的に — あるいは持続的に — スマートコントラクトウォレットであるかのように実行することを可能にする。AI エージェントにとってこれが重要なのは、EOA(MetaMask、Rabby、ハードウェアウォレット、取引所の出金アドレス)に存在する Ethereum 価値の約 90% が、これまでエージェントスタックから到達不能だったからである:いかなるエージェント統合も、ユーザーがまず新規の SCW アドレスへ移行することを要求したが、これは ENS、NFT、稼働中の DeFi ポジションを持つ者にとっては論外である。7702 があれば、長年ユーザーのアイデンティティであり続けた同じアドレスが、コントラクト — 典型的にはセッションキー対応のウォレット実装 — を指す 委任指定子(delegation designator) をインストールでき、その時点以降、エージェントはそのアドレス上にスコープ付き署名者を保持でき、ERC-4337 SCW が提供するのと同じ validateUserOp 方式のポリシー強制を伴う。この入門では、SET_CODE_TX メカニズム、その上のエージェント側セッションキーパターン、ERC-7715 や ERC-7715 と agent payment stack · x402 + AP2 + 4337/7702 協調とどう構成されるか、そして純粋な 4337 経路と比べて意味のある形で異なるセキュリティ姿勢を扱う。

ウィキ上の位置づけ

このエントリは ERC-7702 のエージェント実行の読み解きとしてエージェント経済の下に位置する。SCW 側の経路については AI エージェントのための ERC-4337 アカウント抽象化入門と、汎用的なプロトコルの観点については ERC-7702 と ERC-4337 · Ethereum AA デュアルトラック対照と、その上に乗る権限レイヤーについては ERC-7715 と併せて読むこと。より広範なプロトコルマップについては AI Agent 決済プロトコル全体図 · 7プロトコル俯瞰と AI Agent 決済7プロトコル分層表。より広範なシステム / 規制境界についてはシステム基盤。

メカニズム · `SET_CODE_TX` と委任指定子

EIP-7702 は、Pectra ハードフォークでプロトコルレイヤーに新しい Ethereum トランザクションタイプ(0x04、「set code」)を追加した。その形は:

ユーザーは delegationDesignator — 認可タプル (chainId, contractAddress, nonce) と、それに対する secp256k1 署名 — に署名する。署名されたオブジェクトは「この EOA は、チェーン Y、nonce N において、コントラクト X を自身のコードとしてインストールすることを認可する」と述べる。
その署名済み委任を含む SET_CODE_TX が(ユーザーまたは任意のリレイヤーによって — リレイヤーがガスを支払う)ブロードキャストされる。マイニングされると、EVM は EOA のコードを薄いトランポリンとして扱い、以降のすべての呼び出しに対して指定されたコントラクトへ DELEGATECALL する。
指定は、ユーザーが新しいものに署名する(別のコントラクトを指す、または削除のために address(0) を指す)まで持続する。EIP 自体には有効期限が組み込まれていない — 持続がデフォルトであり、取り消しは意図的なオンチェーンアクションである。

決定的に重要な EVM セマンティクス:EOA のアドレス、残高、nonce、履歴は変わらない。5 年間ユーザーの ENS / NFT / Aave ポジションを保持してきたアドレスは同じアドレスのままである — 変わるのはその実行可能コードだけである。あらゆるコントラクトやインデクサーの観点からは、そのアドレスへの呼び出しは今や指定された実装ロジックを経由するが、ストレージは依然としてアドレス自身に属する(これが、指定されたロジックがセッションキーやスコープなどを保持するためにストレージを使用できる仕組みである)。

メカニズム · セッションキー、エージェント側

EOA がセッションキーをサポートするウォレット実装(Safe バリアント、Kernel バリアント、MetaMask Smart Account、Rhinestone Account など)に委任すると、エージェント統合パターンは AI エージェントのための ERC-4337 アカウント抽象化入門と構造的に同一になる:

委任後のユーザーの既存 EOA は、セッションキーモジュールのエントリポイントを公開する。
ユーザーは、スコープ付きポリシー(対象コントラクト、セレクタ、価額上限、期間ごとの限度、有効期限)を伴って、エージェントの公開鍵に対するセッションキーエントリをインストールするトランザクション(または 4337 経由でルーティングされる場合は UserOp — 下記参照)に署名する。
エージェントは対応する秘密鍵を堅牢な環境(Privy MPC シェア、AWS Nitro Enclave、Apple Secure Enclave、Coinbase CDP 署名者サービス)で保持する。
エージェントはセッションキーで署名されたトランザクションを送信する。EOA は今やウォレット実装コードを実行するため、実装の validateUserOp(4337方式)またはそのネイティブトランザクションガードロジックが、実行前にセッションキーの署名とスコープを確認する。
ユーザーは、セッションキーエントリを削除するトランザクションに署名するか、委任を完全に削除するために address(0) を指す新しい SET_CODE_TX に署名することで取り消せる。

新規の 4337 SCW との主要な運用上の違いは、ユーザーが資金を移動する必要がなかった ことである。同じ DeFi ポジション、NFT 保有、ENS 逆引き、オンチェーンレピュテーションが、依然として同じアドレスに紐づいている。エージェントは履歴全体を継承する。

メカニズム · 7702 + 4337 の構成

最もクリーンな本番デプロイは 7702 と 4337を構成する:

EOA は(SET_CODE_TX 経由で)ERC-4337 の validateUserOp インターフェースを実装するウォレット実装に委任する。
委任後、EOA は EOA としても(レガシーな txs は依然として動作する)かつ 4337互換 SCW としても(Bundler は sender == EOA address の UserOp を拾える)アドレス指定できる。
4337 インフラのすべて — Bundler、Paymaster、EntryPoint v0.7 — は変更なしで動作する。EntryPoint の唯一の要件は sender が正しい検証インターフェースを持つことであり、委任されたコードがそれを提供するからである。
セッション、ガススポンサーシップ、スコープ強制は、純粋な 4337 のケース(ERC-4337 UserOp / Bundler / EntryPoint フロー詳解)と同一に動作する。

これが、「7702 は 4337の競合か?」というエージェント経済の読み解きが、概ね「いいえ、両者は構成される」となる理由である。7702 は アドレス移行 の問題を解決し;4337 は 実行セマンティクス の問題を解決する;両者を合わせると、同じエージェントに、ユーザーの既存アドレス上で新規 SCW と同じスコープ付き・スポンサー可能・取り消し可能な実行サーフェスを与える。

7702のみのデプロイ(4337なし)も可能である — ウォレット実装は独自の内部セッションキーロジックを搭載し、標準的なレガシートランザクションで動作できる。これは運用上よりシンプルだが(Bundler / Paymaster 依存なし)、ETH 不要の UX、Bundler バッチングによる節約、標準化された EntryPoint の信頼ルートを失う。

2026年半ばの時点でほとんどのエージェントスタックエンジニアリングガイドにおける実践的推奨は:両モードをネイティブにサポートするウォレット実装(Safe-7579, Kernel、Rhinestone Account、MetaMask Smart Account バリアント)を選び、既存 EOA ユーザー向けには 7702 経由でそれに委任し、呼び出し元が真の 4337 SCW か 7702委任された EOA かにかかわらず、エージェント経路には同じ validateUserOp インターフェースを使わせる、というものである。下流のコードパスは収束する。

メカニズム · 委任指定子の署名ライフサイクル

委任指定子の署名はそれ自体が負荷を担うオブジェクトであり、エージェントセキュリティの角度からより詳しく見る価値がある:

署名されるペイロードは EIP に従い (MAGIC || chain_id || address || nonce) であり、MAGIC はドメイン分離バイトである。署名はそのペイロードの keccak256 に対するもので、EOA の secp256k1 鍵によって生成される。
chain_id フィールドが決定的に重要である — これは、あるチェーンで署名された委任が、別のチェーンで同じ EOA に対してリプレイされるのを防ぐものである。chain_id == 0 で署名された委任はチェーン横断でリプレイ可能であり(EIP は明示的なクロスチェーン委任のためにこれを許可する。例:「このアドレスをあらゆる場所でこの実装に委任する」)、したがって UX の観点からは最も危険なモードである。
nonce フィールドは、署名時ではなく SET_CODE_TX がマイニングされた時点での EOA のアカウント nonce から取られる。同じ EOA によって署名された複数の委任をキューに入れることができる;マイニング時に実際のオンチェーン nonce と一致するものだけが有効になる。

悪意ある委任の取り消しをユーザーに 手助け したい AI エージェントは、address(0) を指す新しい SET_CODE_TX を構築し、EOA で署名しなければならない。エージェントはセッションキー単独ではこれを行えない — 取り消しにはルート EOA の署名が必要である。この非対称性は意図的である:エージェントのセッションキーインフラが侵害されても、ユーザーは常に取り消す能力を保持しなければならない。これを誤解し、セッションキー経由で取り消しを可能にしようとするウォレット実装は、セキュリティホールを作っている。

メカニズム · 一時的認可、7702固有のパターン

真に 7702ネイティブなパターン(4337にきれいな類似物がない)は、単一トランザクション委任 である:SET_CODE_TX 認可を、それを使用するのと同じトランザクションに含め、その後直ちに取り消す。具体的には:

ユーザーは delegationDesignator と後続の呼び出しを一つのバンドルで署名する。
バンドルがリレイヤーによって送信される。EVM は委任を適用し、後続の呼び出し(EOA が通常持たないセッションキー / バッチ / スポンサーシップ機能を使用する)を実行し、その後最後の操作で委任を削除する。
正味の効果:EOA はちょうど一つのトランザクションの間 SCW の挙動を持ち、その後純粋な EOA に戻った。

エージェントにとって、エージェント固有の読み解きは 「エージェントにワンショットの時間制限付き認可を渡す」 ことである。ユーザーは、持続的なセッションキーをエージェントに与えることなく、エージェントに単一のバッチ操作 — 例えば「USDC を承認 + スワップを実行 + マーチャントへ送金、を一つのアトミックな UserOp ライクなシーケンスで」 — を実行させることができる。これは OAuth ベアラートークンよりも OAuth 2.0の認可コードフローに形が近い:ユーザーが単一使用のクレデンシャルを発行し、エージェントがそれを消費し、認可が蒸発する。

持続的委任(より一般的なケース)は、OAuth リフレッシュトークンや ERC-7715 のスコープ付き権限により近い類似物である:エージェントは境界付きスコープを持つ長寿命の署名者を得る。

エージェント固有のシナリオ

シナリオ A — 長年の MetaMask ユーザーが自律エージェントを追加する。 LP ポジション、NFT、ENS を保持する 5 年前の MetaMask アドレスを持つ DeFi ユーザーが、厳格なリスク枠内でエージェントに毎週ポジションをリバランスさせたいと考える。7702以前:彼女はすべてを新しい SCW に移行しなければならなかった。7702があれば:彼女は一つの SET_CODE_TX に署名して Safe スタイルのウォレット実装に委任し、その後「トークン X/Y/Z に対して Aave.repay/borrow/withdraw を呼び出せる、週あたり最大 N USDC、有効期限 90 日」というスコープでエージェントのセッションキー認可に署名する。同じアドレスがすべての履歴を保持する。

シナリオ B — 単一使用のトレーディング認可。 ユーザーは、エージェントに今日限りで特定の裁定取引を一度だけ実行させたい、持続性なし。パターン:ユーザーは 7702 単一トランザクション委任に署名し、エージェントが承認+スワップ+返済のシーケンスを一つのアトミック操作で実行できるようにし、その後 EOA は通常の EOA 状態に戻る。エージェントはオンチェーン署名者を一切保持しない;認可は消費されて消える。

シナリオ C — セキュリティのための EOA「ダウングレード」。 昨年 7702 委任をインストールしてエージェントにセッションキーを与えたユーザーが、エージェントプラットフォームが侵害されたと疑い、すべてを取り消したいと考える。address(0) を指す一つの SET_CODE_TX が委任を完全に削除する;インストールされたすべてのセッションキーが単一のアトミック操作で到達不能になる。これは、取り消しに通常 SCW のモジュールアンインストールロジックとのやり取りが必要な 4337 SCW よりも意味のある形でシンプルである。

シナリオ D — 一つのアイデンティティ上のマルチチェーンエージェント。 ユーザーの同じ EOA アドレスは、Ethereum メインネット、Base、Arbitrum、Optimism に存在する(EOA はチェーン非依存であり、ユーザーがそのアドレスをあらゆる場所で使ってきたため)。彼女は異なるチェーンで 異なる ウォレット実装に委任できる — 高頻度の x402 エージェントトラフィック向けに Base 上でセッションキーが豊富な実装を、コールドストレージ向けにメインネット上でマルチシグスタイルの実装を。エージェントは一つのアイデンティティから動作するが、チェーンに適した実行セマンティクスを伴う。

シナリオ E — プラットフォームがプロビジョニングする EOA。 プラットフォーム(Stripe、AWS AgentCore)はプロビジョニング時にエージェントごとに新規 EOA を生成する。7702 以前は自然な選択はエージェントごとの 4337 SCW であり、それはエージェントごとのコントラクトデプロイを意味した。7702 があれば、プラットフォームは単純に新規 EOA をプロビジョニングし、USDC を入金し、初回使用時にエージェントに SET_CODE_TX で既知の良好な実装へ委任させるよう署名させればよい。ファクトリデプロイなし、反実仮想的アドレス計算なし。数千万規模のエージェントフリートにとって、これは実際のオンチェーンコストを節約する。

規制上の位置づけ · 「EOA は依然としてユーザーである」

7702 アーキテクチャは有用な規制上の性質を持つ:SET_CODE_TX に署名する EOA アドレスは、以前ユーザーのアイデンティティだったのと同じアドレスである。ほとんどの法域の AML / KYC / 制裁フレームワークは、自然人をそのウォレットアドレスによって識別する(銀行口座番号で識別するのと同じように)。7702 はそのマッピングを保持する — ユーザーのアドレスは変わらず、履歴は変わらず、コンプライアンスベンダーがそのアドレスに対して構築してきたオンチェーンレピュテーションとトランザクショングラフのすべてが依然として適用される。唯一の変化は、そのアドレスが今やより豊かなロジックを実行できることである。

これは、すべてのコンプライアンスベンダーがユーザーアイデンティティを新しいアドレスに再アンカーしてグラフを再構築しなければならない 4337の「新規 SCW アドレス」パターンとは運用上異なる。機関投資家ユーザーや、厳格なトラベルルール要件を持つ法域のユーザーにとっては、規制上のアイデンティティがアップグレード全体で持続するため、7702 はより摩擦の少ない経路である。

裏面は、委任指定子そのもの が以前は存在しなかった新しいアテステーションであり、ほとんどの法域がそれが何を意味するかをまだ成文化していないことである。悪意あるコントラクトへの委任に署名したユーザーは、事実上、そのアドレスのあらゆる資産のカストディを署名で手放したことになる — それは通常のトランザクションに署名するよりはるかに重大なアクションであり、「委任に署名するよう騙された」という主張の法的地位は本当に未解決である。

エージェントユースケースにおける ERC-4337 との比較

次元	ERC-4337 経路	ERC-7702 経路
開始状態	ユーザーはまだ Ethereum ウォレットを持たない、または持っていて移動を受け入れる	ユーザーは保持したい履歴を持つ既存 EOA を持つ
アドレス	新規 SCW アドレス	既存 EOA アドレス
オンボーディングコスト	反実仮想的デプロイ + 初回 UserOp	一つの `SET_CODE_TX` 署名(~30k–50k ガス)
セッションキーサポート	SCW モジュールインストール経由でネイティブ	委任後、委任された実装のストレージ経由でネイティブ
ガススポンサーシップ	Paymaster(4337ネイティブ)	4337と構成すれば Paymaster;さもなくばレガシーリレイヤー
取り消し	UserOp 経由でモジュールアンインストール	モジュール削除、または核オプションとして `address(0)` への `SET_CODE_TX` 署名
単一使用認可	不格好(各 UserOp が持続的状態を作る)	単一トランザクション委任パターン経由でネイティブ
履歴上のエージェントアイデンティティ	エージェントは実績のない新しいアドレス経由で行動する	エージェントは完全な実績を持つユーザーの既存アドレス経由で行動する
コンプライアンス / KYC の連続性	アイデンティティの再アンカーが必要	アイデンティティが持続する
セキュリティ最悪ケース	SCW ロジックのバグ = SCW 資金がリスクに	委任ロジックのバグ = EOA 履歴全体がリスクに

エージェントユースケースに対する実践的ガイド:

組み込みウォレットプラットフォーム経由の新規ユーザーオンボーディング → 4337 SCW。ユーザーは EOA を持ったことがない;委任元がない。Privy / Coinbase CDP / Alchemy はこの経路をデフォルトとする。
既存 EOA ユーザー(MetaMask、Rabby、ハードウェアウォレット)でエージェント機能を望む者 → 7702 委任、おそらく実行セマンティクスのために 4337 と構成。これは MetaMask と Rabby が 2026に搭載する経路である。
機関投資家マルチシグ → 4337 + Safe モジュール;機関投資家にはアップグレードする EOA がないため 7702 は概ね無関係である。
単一使用、高信頼の認可 → 7702 単一トランザクション委任。
リテール SaaS 向け長寿命エージェントフリート → プラットフォームがプロビジョニングする 4337 SCW。

詳細な切り分けは、システム側からは ERC-7702 と ERC-4337 · Ethereum AA デュアルトラック対照にある。

出典

EIP-7702 仕様 — eips.ethereum.org/EIPS/eip-7702。
EIP-4337 仕様 — eips.ethereum.org/EIPS/eip-4337。
「EIP-7702: Set EOA Account Code」 — オリジナルの ethresear.ch / ethereum-magicians 提案スレッド。
Vitalik Buterin, 「EIP-7702 Optimizations」ノート — notes.ethereum.org/@vbuterin/eip_7702_optimizations。

要約