EOAからスマートアカウントへの移行手順｜EIP-7702とERC-4337の選び方

あるWeb3サービスが、自社で運用しているEOA（普通の秘密鍵で動くアカウント）を、スマートアカウントへ移すことにしました。複数人の承認や、鍵をなくしたときの回復を入れたいからです。

最初に思いつく手順は、新しいアカウントを作り、残高を送ることです。ところが旧アドレスには、残高のほかにも、次のようなものが結び付いています。

• トークンの利用許可（allowance）や、期限の長い署名（permitや注文）
• 処理中の取引や、ログインのセッション
• 取引先のアドレス帳に登録された、旧アドレスへの入金

利用許可や署名は、資産を動かせる権限です。残高を送っただけでは、これらは旧アドレスに残ったままです。つまり、それだけでは移行は終わりません。

さらに最初に決めることがあります。アドレスを今のまま残すのか、別のアドレスへ移るのか、です。前者はEIP-7702、後者はERC-4337型のスマートアカウントが候補になります。そのうえで、残高以外のものまで洗い出し、段階を踏んで切り替えます。

以下では、このサービスのプロダクト責任者・設計者・運用担当が、方式を選び、移すものを洗い出し、切り替えて、戻す手順まで決める流れを追います。AAの規格比較ではなく、動いているアカウントを止めずに移す話です。AA（アカウントアブストラクション）の全体像はアカウントアブストラクション（AA）完全マップ2026で解説しています。

アドレスを残すか、最上位の鍵を変えるか

方式は機能の多さでは決まりません。決め手は「守るべき不変条件（変えてはいけないもの）」です。

取引先に登録されたアドレスや、残高・取引履歴・相手方のアドレス帳をそのまま残したいとします。それなら、EIP-7702で今のEOAに委任先のコードを設定する方式が候補です。

一方、次のような要件なら、別アドレスのERC-4337型スマートアカウントへ移します。

• 元のEOAの鍵を、最上位の権限として残せない
• 複数人承認を、1本の鍵で迂回できないようにしたい
• 鍵を交換した後、旧鍵を無効にしたい

方式そのものの違いはERC-4337とEIP-7702の違いと使い分けとEIP-7702の事業者向け解説で解説しています。ここでは、動いているアカウントを移す立場だけで比べます。

EIP-7702は、アドレスを変えない分、移行の手間を減らせます。ただ、仕様上、元の鍵は委任を変えられます。また、不備のある委任先は、EOAをほぼ完全に操れてしまいます。

つまりEIP-7702は、「秘密鍵からスマートアカウントへ安全性を移す」規格ではありません。「アドレスを残す」と「旧鍵を無効にする」の両方が必須なら、2026年9月24日時点でFinal（最終版）のEIP-7702だけでは満たせません。

残高のほかに、何を洗い出すか

オンチェーンの残高は、移すものの一部にすぎません。切り替えの前に、チェーンと環境ごとに次の6つの台帳を作ります。

1. 資産：ネイティブトークン、ERC-20、NFT、ステーキング持分、ブリッジ中の資産、請求（claim）前の報酬。
2. 権限：ERC-20 allowance、NFT operator、コントラクトの所有者（owner）・管理者（admin）・ロール、Safe等の署名者、Paymasterの許可リスト。
3. 署名：未使用のpermit、注文、ログインセッション、API認証、EIP-712ドメイン、期限の長いオフチェーン承認。
4. 届く先：取引先のアドレス帳、入金画面、請求書、定期送金、ブリッジ・取引所の出庫先、ENS等の名前解決。
5. 処理中のもの：送信済みで未確定の取引、UserOperation、クロスチェーンメッセージ、タイムロック、出金待ちのキュー。
6. 運用：監視、会計の突き合わせ、障害対応、鍵保管、ガスの補充、Bundler・Paymaster・RPCが止まったときの代わりの道。

項目ごとに、次のことを書いておきます。

• 旧い持ち主と新しい持ち主、切り替え方
• 確かめるための問い合わせ（検証クエリ）
• 戻し方と責任者

署名の扱いにも注意が要ります。別アドレスへ移るなら、コントラクトの署名を確かめる仕組みが相手側に必要です。相手のサービスがERC-1271のisValidSignatureに対応しているかを確かめます。EOAの署名（ECDSA）だけを前提にしたログイン、注文、permitは、新しいアカウントでは同じ方法で確かめられません。

EIP-7702でアドレスを残す場合も、試すことがあります。既存のコントラクトやバックエンドが「相手は普通のEOAか」を判定していないかです。コードの有無やtx.originで判定している仕組みは、移行後に動きが変わるおそれがあります。

準備・併走・切替・確定の4段階で進める

移行を1本の取引にまとめるほど、失敗したときにどこまで反映されたかが分かりにくくなります。そこで4段階に分け、段階ごとに入る条件、出る条件、止める条件を決めます。

code hashは、コントラクトのコードを識別するハッシュ値です。

途中で止めるときの動きも、段階ごとに決めておきます。

• 準備：資産・権限は移さず、設計へ戻る。
• 併走：新規の受付を止め、処理中の操作を確定させるか失効させる。
• 切替：終わっていない項目を再実行しない。取引ハッシュ（tx hash）と現在の値から、再開する地点を決める。
• 確定：旧EOAをすぐには廃止しない。決めた期間は、回収の道を残す。

ERC-4337では、「送信を受け付けた」を「実行が終わった」と取り違えないことが大切です。確かめ方は後半の「実装する人向けの詳細」にまとめました。

EIP-7702では、初期化の乗っ取りと保存データの衝突を別々に試す

EIP-7702の認可は、通常のコントラクト作成とは違います。作成用のコード（initcode）を実行して、初期状態を一度に設定する仕組みではありません。

そのため、委任を設定してから初期化するまでの間に、第三者が先に初期化してしまうおそれがあります。仕様は、初期化のデータ（calldata）がEOAの鍵で署名済みかを、委任先で確かめるよう求めています。委任の設定だけを先に済ませ、誰でも初期化できる時間を作ってはいけません。

もう1つは、保存データの衝突です。別の委任先に切り替えても、EOAのアドレスに保存されたデータ（ストレージ）は残ります。新旧の実装で保存場所がぶつかると、アカウントがロックされたり、権限が壊れたりします。

EIP-7702のSecurity Considerationsは、名前空間で分けた保存領域（ERC-7201）を使うことや、事前に状態を消すことを勧めています。

再委任の試験には、空のテスト用EOAだけでは足りません。本番と同じ順序でデータを書き込んだEOAを、フォーク環境（本番のチェーンを写した試験環境）に複製して使います。委任、実行、解除、旧実装への復帰まで確かめます。そのほかの確認項目は後半にまとめました。

別アドレスへ移るなら、権限を先に、資産を後に

ERC-4337型のスマートアカウントへ移る場合は、順番が大事です。新しいアカウントからは、必要なコントラクト操作や緊急の回収が、まだできないことがあります。その状態で資産を先に移すと、困ったときに戻せなくなります。

次の順で進めます。

1. 計算で決まるスマートアカウントのアドレスと、factory（アカウントを作るコントラクト）、実装、EntryPointの組み合わせを固定する。別のチェーンで同じに見えるアドレスを取り違えない。
2. 少額で、デプロイ、ERC-1271署名、一括実行、失敗時の再試行、回復、ガス代補助の上限を試す。ガス代補助の上限と止める線の決め方はPaymasterの不正利用・ガス枯渇対策で扱っています。
3. 旧EOAが持つ管理ロールを、新アカウントにも付ける。新アカウントから実際に操作できると確かめてから、旧ロールを消す。
4. 長期署名を失効させ、allowanceを必要最小限に減らす。無期限のpermitや注文は、サービス側でも拒否する。
5. 資産を種類ごとに移す。残高だけでなく、ステーキング・未請求の報酬・クロスチェーンの状態も突き合わせる。
6. 旧EOAへの誤入金の監視と回収手順を残す。案内期間が終わったら、鍵保管の方針を変える。

切り替えてよいかを、5つの失敗で確かめる

うまくいくデモでは判定しません。次の失敗をわざと起こし、復旧にかかる時間と責任者を測ります。

• 署名者・端末をなくした：回復者の共謀、待機期間、旧鍵の失効、サポートの本人確認まで含めて復旧できるか。
• Bundler・Paymasterが止まった：代わりの事業者、利用者の自己負担、通常の取引などの道へ切り替えられるか。
• 移行の途中で止まった：同じ資産・権限を二重に移さず、オンチェーンの今の値から再開できるか。
• 委任先・モジュールに不具合がある：緊急停止、再委任、モジュールの無効化を、障害中の実装に頼らずに実行できるか。
• 旧EOAに入金が続く：自動で気づき、利用者に知らせ、回収し、会計を突き合わせられるか。

先へ進む条件は、次の5つです。台帳の差分ゼロ、重大な未解決の脆弱性ゼロ、復旧訓練の成功、監視アラートが届くこと、権限者の承認です。

止める条件には、次のものを含めます。

• 想定外のcode hash、署名の確かめ方の違い
• シミュレーションと実行結果の食い違い、二重送信
• 説明できない残高の差、回復できない状態

フロントエンドを戻しても、Paymasterのルール、受付API、処理中のキュー、オンチェーンの権限は、それだけでは止まりません。止めるときは、これらを同時に凍結します。

移行後の利用開始率を、離脱と処理失敗に分けて測る方法はスマートウォレットの利用開始率を測るを参照してください。

移行を見送るのはどんなときか

• 今のEOAで必要な操作を安全にこなせている。移行によるUX・統制の改善が、新しいコントラクトの攻撃の入り口と運用費を上回らない。
• EIP-7702を使いたいが、対象チェーン、利用ウォレット、委任先の実装、監視基盤のどれかが未対応である。
• 元のEOA鍵を失効させる要件があるのに、アドレスを残したいという理由だけでEIP-7702を選ぼうとしている。
• 取引先、プロトコル、署名の確認、会計システムが新アカウントを扱えず、併走・回収の期間を取れない。
• 障害時の緊急権限が1社・1本の鍵に集まり、その失敗に気づけない・制限できない。

実装する人向けの詳細

ERC-4337で「実行の完了」を確かめる

ERC-4337では、UserOperationがBundlerを経て、EntryPointで検証・実行されます。仕様が定めるeth_getUserOperationReceipt等の結果だけで完了としません。対象チェーンのトランザクションと、アカウントの状態も突き合わせます。

dAppからの一括操作は、ERC-5792 Wallet Call APIで対応状況を照会します。非対応のウォレットでは、個別のトランザクションに切り替えます。

EIP-7702の委任で確かめること

• 認可するchain ID、委任先アドレス、nonceを、画面と署名内容で一致させる。
• dAppが任意の委任認可を直接求めない。ウォレットが監査・許可した実装だけを扱う。
• 委任先のcode hash、実装バージョン、監査範囲、アップグレード権限を監視する。
• 解除後も残るストレージ、署名、セッションキー、モジュール権限を見落とし、「元のEOAへ戻った」と取り違えない。

関連記事

• アカウントアブストラクション（AA）完全マップ2026 — AA全体と4層の役割
• ERC-4337とEIP-7702の違いと使い分け — 方式選択の前提
• AAセキュリティリスク — 委任、モジュール、Bundler・Paymasterの脅威モデル
• ソーシャルリカバリー（Social Recovery）とは — 回復者、閾値、待機期間
• Paymasterの不正利用・ガス枯渇対策 — 移行後のガス代補助の上限と停止・復旧

XTELAができること

XTELAは、既存EOAの資産・権限・署名・外部連携の棚卸しから、EIP-7702とERC-4337の方式比較、移行用スマートアカウントとBundler・PaymasterのPoC、フォーク環境での回帰試験、監視と切り戻し手順の設計までを行います。貴社のアカウントを止めずに移すための台帳と判定条件を、一緒に組み立てます。スマートアカウントへの移行について相談する

主要参考資料

• EIP-7702: Set Code for EOAs（Final、2026年9月24日確認）
• ERC-4337: Account Abstraction Using Alt Mempool（2026年8月12日確認）
• ERC-1271: Standard Signature Validation Method for Contracts
• ERC-5792: Wallet Call API（Final、2026年9月24日確認）
• ERC-7779: Interoperable Delegated Accounts（Draft、2026年9月24日確認。再委任時のストレージ管理の論点の補助資料）

資料の確認日

一次仕様の最終確認日は2026年9月24日（ERC-4337は2026年8月12日）です。EIP-7702・ERC-5792のステータスは、この日に確認し直しています。対象チェーンのEIP-7702対応、スマートアカウントの実装、ウォレット、Bundler・Paymasterの対応状況は、導入時にあらためて確かめてください。