アカウントアブストラクションのセキュリティリスク｜ERC-4337・EIP-7702で実際に起きた被害と事業者の防御設計

アカウントアブストラクション（AA：ウォレットをスマートコントラクトとして扱い、認証や資産管理のロジックを設計できるようにする仕組み）の導入で、ウォレットは従来より危険になるのか——2026年8月時点の答えは「ERC-4337やEIP-7702という規格そのものの欠陥による資金流出は公表されていないが、攻撃される場所が変わる」です。2025年から2026年にかけて実際に起きた被害は、①漏洩済みの秘密鍵からの資産回収を自動化するsweeper（着金した資産を即座に流出させる自動送金コントラクト）によるもの、②バッチ実行の署名を騙し取るフィッシング、③署名画面を配信するインフラの侵害（Bybitからの約15億ドル流出）の3経路に集中しており、いずれも規格のコントラクト自体は破られていません。一方で、AAを導入する事業者が守るべき対象は「秘密鍵1点」から「アカウント実装・ガス肩代わりの原資・トランザクション中継・署名画面と運用」へ広がります。

本記事は、2025〜2026年の実被害の内訳、ERC-4337の層別の攻撃面、EIP-7702が既存EOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント）に追加した攻撃面、導入事業者の防御設計、監査の位置づけまでを、2026年8月時点の一次情報で整理します。ERC-4337の基本の仕組みはERC-4337の事業者向け解説、EIP-7702の仕組みはEIP-7702の事業者向け解説、スマートアカウント領域全体の俯瞰はAA完全マップ2026で扱っているため、本記事はセキュリティに集中します。

実際に起きた被害の内訳 — 破られたのは規格ではなく「鍵・署名・画面」

スマートコントラクト型のウォレットに関わる主要な被害事例を、「何が破られたのか」の観点で並べると、規格・コントラクトの欠陥が直接の原因になった事例と、その外側（鍵管理・署名判断・配信インフラ）が原因になった事例をはっきり区別できます。

EIP-7702は2025年5月7日のEthereumのPectraアップグレードで有効化されました（Ethereum Foundation: Pectra Mainnet Announcement）。直後の2025年5月末、トレーディング企業Wintermuteの調査チームは、EIP-7702の委任（delegation：EOAが自分のアドレスにコントラクトのコードを紐付けること）の97%超が、同一バイトコードをコピーした資産流出用コントラクトへの委任だったと公表し、このコードを「CrimeEnjoyor」と名付けて警告しました（Wintermute、2025年5月末）。攻撃者は約2.88 ETHのガス代で約79,000アドレスに委任を設定していましたが、報道時点で流出先への着金はほとんど確認されていません（CoinDesk、2025年6月2日）。

この数字だけを見ると「EIP-7702は危険な規格」に見えますが、Wintermuteは2025年6月上旬に「EIP-7702に欠陥はなく、利用は安全である」と明確化しています。sweeperが委任されていたのはすでに秘密鍵が漏洩していたアカウントであり、EIP-7702は盗難の原因ではなく、盗んだ鍵からの資産回収を自動化・高速化する道具として使われました（Wintermute、2025年6月上旬）。セキュリティ企業SlowMistの2025年半期レポートや、2025年12月投稿の学術論文でも同じ因果の整理がされています（SlowMist半期レポート、2025年7月、arXiv: EIP-7702 Phishing Attack、2025年12月）。

一方、秘密鍵が漏れていなくても成立した被害がフィッシングです。2025年5月には、MetaMaskの正規の委任先コントラクトへアップグレード済みのアカウントが、バッチ実行（複数の送金・承認を1回の署名にまとめる機能）の署名を騙し取られ、約14.6万ドルを流出しました（SlowMist半期レポート、前掲）。2025年8月には約154万ドルの単独被害を含む大型2件・計約254万ドルが報告されています。フィッシング対策企業Scam Snifferの集計では、2025年通年のウォレット向けフィッシング被害総額は約8,385万ドルと前年から83%減少した一方、EIP-7702のバッチ署名を悪用する手口は2025年後半の新しい増加要因になりました（Scam Sniffer 2025年通年レポート）。

最大の被害額を出したのは、2025年2月21日のBybitからの約15億ドル流出です。破られたのはSafeのコントラクトではなく、署名画面を配信するインフラ（AWS S3上のJavaScript）と、画面表示を信頼して署名内容を検証できていなかった運用でした。いわゆるblind signing（署名内容を実質確認できないまま署名すること）の問題です（Sygnia調査報告、FBI IC3公表、2025年2月26日）。事件の詳細と署名運用の設計論点はSafeのモジュラー構成と採用判断で扱っています。

業界全体の統計でも同じ傾向が確認できます。Chainalysisの集計では、2025年の暗号資産盗難総額は34億ドルを超え、うちBybit単体が15億ドル、上位3件の大型事件だけで全体の69%を占めました。個人ウォレットの侵害は総額の約2割（約7.1億ドル・約15.8万件）です（Chainalysis、2025年12月）。つまり2026年8月時点の実態は、「AAだから危ない」でも「監査済みコントラクトだから安全」でもなく、規格・実装は監査の反復で守られてきた一方、被害は鍵管理・署名判断・配信インフラという「コントラクトの外側」で発生している、というものです。ただしこれは、AAの導入で新しい攻撃面が増えないという意味ではありません。次章から、事業者が実装・運用範囲として引き受ける攻撃面を層別に見ていきます。

ERC-4337の攻撃面 — EntryPoint・アカウント・Paymaster・Bundlerの層別整理

ERC-4337は、UserOperation（取引意図を表すAA専用のデータ構造）をBundler（UserOperationを束ねてEthereumに送信する中継者）が収集し、単一のEntryPointコントラクトが検証と実行を統括し、必要に応じてPaymaster（ガス代を肩代わりするコントラクト）が手数料を負担する構成です。累計UserOperationは12億件超、実行アカウントは6,300万超という規模で稼働しています（BundleBear、2026年8月11日閲覧）。攻撃面はコンポーネントごとに性質が異なります。

EntryPoint — 全体の「中央の信頼点」

ERC-4337仕様は、EntryPointを全体の中央の信頼点（central trust point）と位置づけ、監査と形式検証を必要条件として仕様自身に明記しています。その代わり、個々のアカウント実装の検証負荷を小さくできる、という分担です（ERC-4337仕様（Final））。実際にEntryPointは反復監査を経ています。OpenZeppelinが2023年の初回監査と2024年2月の増分監査を、2025年3月リリースのv0.8はSpearbitが、2025年11月リリースのv0.9はCantinaが監査しています（eth-infinitism/account-abstraction: audits）。

バージョンの推移にもセキュリティ上の意味があります。v0.7（2024年2月）ではシミュレーション機能をオンチェーンのEntryPointから分離し、v0.8（2025年3月26日）ではEIP-7702委任のネイティブサポートと、EOAが安全に委任できる監査済みの最小実装Simple7702Accountを追加しました（v0.8.0リリースノート）。v0.9（2025年11月16日）では、正当に署名されたUserOperationを第三者が先回りで意図的に失敗させ、ユーザーにガス代を負担させられる問題（資金流出ではなく妨害・嫌がらせにあたる挙動）が修正されています（リリース履歴、ERC-4337公式ニュースレターによる解説、2026年2月5日）。EntryPoint起因の資金流出被害は、2026年8月時点で公表されていません。

事業者の実務論点は、EntryPointを独自に実装・改造しないこと（仕様もその想定を置いていません）、そして利用するバージョンを把握し移行を計画することです。既存アカウントが自動で新バージョンへ移行することはありません。

アカウント実装とモジュール — 資産に直結する層

スマートアカウント本体のコードの欠陥は、資産の流出・凍結に直結します。これはAA以前の2017年に、Parityのマルチシグウォレットが実証しています。同年7月にはライブラリの初期化機能の不備で約15.3万ETHが流出し（OpenZeppelinによる事件分析、2017年7月）、11月には未初期化のライブラリコントラクトを第三者が破棄したことで、587ウォレット・約51.4万ETHが恒久的に凍結されました（Parity公式ポストモーテム、2017年11月）。

この教訓から、AAでは「長期運用と監査を経た共通実装を使い、独自要件はモジュールとして足す」構成が定石になっています。ただし、モジュール機構自体が新しい攻撃面です。Safeの公式ドキュメントは「Moduleは任意のトランザクションを実行できるためセキュリティリスクになり得る。信頼でき監査されたModuleだけを追加すべきで、悪意のあるModuleはSafeを乗っ取り得る」と明確に警告しています（Safe Docs: Safe Modules）。モジュール規格のERC-7579（Draft）はValidator（署名検証）・Executor（代行実行）・Fallback Handler（未定義呼び出しの委譲）・Hook（実行前後の検証）の4種を規格化していますが、その仕様のSecurity Considerationsには、信頼できないHookの追加によるアカウントの実行不能化、モジュールの導入・削除処理を経由したreentrancy（再入攻撃）、Fallback Handlerの認可不備といった論点が明記されています（ERC-7579仕様（Draft））。

この層では、監査・リサーチが実被害の手前で脆弱性を潰してきた実例が公開されています。2023年10月、FireblocksのリサーチチームはUniPassウォレットのERC-4337モジュールに「アカウントが信頼するEntryPointを差し替えることで完全に乗っ取れる」脆弱性を発見し、ホワイトハット作戦による先回りの修正で実被害ゼロに抑えました（Fireblocks、2023年10月）。Biconomyのスマートアカウントでは、2023年1月の公開監査コンテストでHIGH評価7件を含む15件の脆弱性（Factoryのデプロイを先回りしてバックドアを仕込める問題など）が発見・修正されています（Code4rena監査レポート、2023年1月）。

実務上の含意は明確です。アカウント実装をフルスクラッチで書くことを避け、監査履歴が公開された実装を選ぶこと（比較はSmart Walletスタック比較を参照）、そしてカスタムモジュールを作る場合はコアと同等の権限を持ち得るものとして監査対象に含めることです。

Paymaster — ガス肩代わりの原資が狙われる層

Paymasterの攻撃面は、EntryPointに預けたガス代原資（deposit）の枯渇と、スポンサー条件の悪用です。大量のリクエストで原資を消耗させられればサービス停止に直結し、肩代わり条件が緩ければ自社と無関係な取引のガス代まで負担させられます。Paymaster起因の大規模な実被害は2026年8月時点で公表を確認できていませんが、原資の枯渇はそのままサービス障害になるため、設計段階からの対策が必要です。

仕様側にも防御が組み込まれています。ERC-4337は検証（validation）と実行（execution）を分離し、実行前に支払い可否を確定させることでDoS（サービス不能攻撃）の成立条件を狭めています。また、検証失敗を繰り返すPaymasterやFactoryをmempool（未確定トランザクションの待機領域）から絞り込む・締め出すreputation（評判管理）の仕組みと、その偽装をコスト高にするstake（預託）を定義しています。このstakeは没収される担保ではなく、大量のなりすましを高価にするためのものです（ERC-4337仕様、前掲）。mempoolのDoS防止ルールはERC-7562として策定が続いています（ERC-7562仕様（Draft））。

実運用では、商用インフラがスポンサー条件のポリシー化を提供しており、レート制限や許可リストを自作する必要は必ずしもありません。Pimlicoは全体・ユーザー・UserOperation単位の支出上限を設定できるSponsorship Policiesを（Pimlico Docs）、AlchemyのGas Managerは送信者単位の支出・件数上限、アドレスのallowlist・blocklist（許可・拒否リスト）、スポンサー署名の有効期限を（Alchemy Docs）、CoinbaseのCDP Paymasterはユーザー単位・全体の上限と肩代わり対象コントラクトのallowlistを提供しています（Coinbase CDP Docs。いずれも2026年8月11日閲覧）。誰がどこまでガスを負担するかという経済設計はガスレストランザクションの経済性で扱っています。

Bundler — 取り込みと順序の権限を持つ層

BundlerはUserOperationをブロックに載せる経路を握るため、特定ユーザーの取引を取り込まない検閲、内容を見たうえでの順序操作（先回り）、mempoolを無効なUserOperationで詰まらせるDoSがリスクになります。Bundler起因の実被害の公表事例は2026年8月時点で確認できていませんが、単一のBundlerに依存する構成では、その事業者の障害・方針変更がそのまま自社サービスの停止になります。

仕様側の防御はERC-7562の検証ルール群です。「mempoolに受け入れたトランザクションは手数料の支払いを保証しなければならない」という原則のもと、検証時には有効だったUserOperationを後から一括で無効化してBundlerのリソースを空費させる攻撃（mass invalidation）を防ぐための、検証フェーズの制約とreputationルールを定義しています（ERC-7562仕様、前掲。Draft段階のため今後変わり得ます）。

事業者側の基本は、複数のBundler経路を持つ冗長化、一定時間内にオンチェーン確定しない場合の監視と再送、そして高額・重要な取引の経路を分ける設計です。Bundler・Paymasterプロバイダの選定と組み合わせはAA開発スタックの選定で整理しています。

EIP-7702の攻撃面 — 既存EOAに追加された「委任」というレバー

EIP-7702は、EOAが自分のアドレスに委任先コントラクト（delegate）のコードを紐付ける署名（authorization）を発行し、以後そのEOAをスマートアカウントとして振る舞わせる仕組みです（仕組みの詳細はEIP-7702の事業者向け解説を参照）。セキュリティ観点で重要なのは、委任の署名1つで、そのEOAが持つ全資産の制御構造が変わることです。EIP-7702仕様（Final）のSecurity Considerationsは、次の論点を明記しています（EIP-7702仕様）。

• 委任先実装の要件：委任先コントラクトが実行内容・金額・リプレイ保護（nonce）を署名で拘束していないと、第三者がそのアカウントを完全に操作できます。
• 初期化の先回り（initialization front-running）：通常のコントラクトと異なりデプロイ時にストレージを初期化できないため、初期化処理自体に署名検証がないと、攻撃者に初期化を横取りされます。
• ストレージ衝突：委任先を変更した際、新旧コントラクトのストレージレイアウトが衝突し得ます。仕様はERC-7201などの名前空間化されたストレージを挙げています。
• 全チェーンで有効な署名：チェーンID 0で署名した委任はすべてのチェーンで有効です。マルチチェーン運用では、意図しないチェーンでの委任成立を前提に設計する必要があります。
• 「EOAである」前提の崩壊：msg.sender == tx.originによる「呼び出し元はコードを持たないEOA」という既存コントラクト側の判定が成り立たなくなり、それを前提にした防御（再入攻撃対策など）に影響します。

これらは主に開発者が設計で塞ぐ論点であり、前述のとおり、実際に起きた被害の大半は「漏洩済みの鍵への委任設定」と「フィッシングによる署名の騙し取り」で、規格の欠陥によるものではありません。SlowMistはウォレット事業者に対し、委任署名時に委任先コントラクトを目立つ形で表示するよう勧告しています（SlowMist半期レポート、前掲）。なお、委任は委任先をゼロアドレスに指定した再署名でいつでも解除でき、アカウントは素のEOAに戻ります（EIP-7702仕様、前掲）。

自社サービスでEIP-7702を使う事業者の防御は次の4点に集約されます。①提供する委任先コントラクトは監査済みかつアップグレード不能（変更する場合はユーザーの再署名を必須）にする。②設計の基準として、EntryPoint v0.8に同梱された監査済みの最小実装Simple7702Accountのような参照実装から出発する。③ユーザーに提示する委任先を許可リストで管理し、第三者の委任先を推奨しない。④自社が管理するアカウント群の委任状態を定期的に監視し、解除手順を運用に組み込む。

導入事業者の防御設計 — 層別の対応表と運用の要点

ここまでの攻撃面を、事業者が設計時に割り当てる防御とあわせて一覧にします。

この表で注目すべきは、右列の多くがコントラクトの外側の設計——ポリシー設定、監視、手順、訓練——だということです。Bybit事件が示したのは、コントラクトの承認ルールが正しく動いていても、署名者が「何に署名しているか」を検証できなければ突破される、という事実でした。署名検証運用の具体的な設計はSafeのモジュラー構成と採用判断で扱っています。

運用の監視対象は最低限、Paymasterの原資残高と失敗率（reputationの劣化検知）、自社管理アカウントの委任状態、UserOperationの取り込み遅延の3つです。また、秘密鍵そのものの保護はAAとは別のレイヤーの論点で、鍵の分散管理（MPC）との組み合わせはMPCウォレットとAAの違いと組み合わせ、エンドユーザーの鍵紛失への備えはSocial Recoveryの実装パターンで整理しています。なお、他者の暗号資産を自社の管理下に置く構成は、技術設計と別に資金決済法上のカストディ該当性の論点が生じます。構成ごとの整理はAAの規制該当性を参照してください（該当性の判断自体は弁護士等の専門家の領域です）。

監査の位置づけと費用感 — 「監査済み」を成立させる条件

AAの監査には明確な分担構造があります。ERC-4337仕様はEntryPointについて監査と形式検証を必要条件として明記しており、この共通部分の検証は規格のエコシステム側が反復的に担ってきました。事業者が監査対象として引き受けるのは、自社の実装範囲——アカウントのカスタム部分、独自モジュール、Paymasterの肩代わりロジック、EIP-7702の委任先コントラクト——です。前述のUniPassやBiconomyの事例は、この範囲の脆弱性が監査・リサーチによって実被害の手前で発見・修正されてきたことを示しています。

費用については、大手監査会社の公式な料金表は公開されていません。公開されている実例として、Arbitrum DAOの公募（2024年2月）でTrail of Bitsが提示した条件は、エンジニア1人・1週間あたり25,000ドル、24人週で総額60万ドルでした（Arbitrum DAOフォーラム、2024年2月）。実際の費用と期間は対象コードの規模・複雑さ・レビュー人週で大きく変わるため、複数社への見積もりと、修正後の再監査までを含めた計画が前提になります。

同時に、監査の限界も設計に織り込む必要があります。監査が検証するのは主にコントラクトとその前提であり、署名画面の配信インフラ、鍵管理、署名者の運用はスコープ外になりがちです。2025〜2026年の実被害がまさにその領域で起きている以上、「コントラクト監査済み」を安全の同義語として扱わず、フロントエンドの完全性検証と運用設計を含めた全体のレビューを別途行うことが、AA導入時のセキュリティ設計の実態です。

よくある質問

EIP-7702の委任（delegation）は解除できますか？

はい。EIP-7702の仕様上、委任先をゼロアドレス（0x0000…0000）に指定した委任トランザクションを実行すると委任は解除され、アカウントは素のEOAに戻ります。逆に言えば、解除するまで委任は永続し、アプリやブラウザを閉じても消えません。自分のアドレスに心当たりのない委任が設定されていないかは、Etherscanなどのブロックエクスプローラーでアカウントのコード欄（委任インジケーター）から確認できます。ただし、秘密鍵がすでに漏洩している場合は、解除しても攻撃者が再委任できるため、解除ではなく新しいアカウントへの資産退避が先決です。

EntryPointが攻撃されたら、ERC-4337を使うウォレット全体が危険になりませんか？

構造上はその通りで、ERC-4337仕様自身がEntryPointを全体の「中央の信頼点」と位置づけ、監査と形式検証を必要条件としています。実際にEntryPointはOpenZeppelin（2023年・2024年）、Spearbit（2025年、v0.8）、Cantina（v0.9）による反復監査を経ており、EntryPoint起因の資金流出被害は2026年8月時点で公表されていません。2025年11月リリースのv0.9では、正当なUserOperationを第三者が意図的に失敗させてガス代を負担させる問題（流出ではなく妨害にあたる挙動）が修正されました。なお、既存のアカウントやサービスが自動で新バージョンへ移行することはないため、事業者は利用中のEntryPointバージョンの把握と移行計画を持つ必要があります。

秘密鍵を漏らさなければ、EIP-7702関連の被害は心配しなくてよいですか？

いいえ。2025年に確認された被害には、秘密鍵の漏洩なしに、正規の委任先を設定済みのアカウントがバッチ実行の署名をフィッシングで騙し取られて資産を一括流出した事例があります（2025年5月の約14.6万ドル、同年8月の約154万ドルなど。SlowMist・Scam Snifferの各レポート）。委任先が正規でも、「何に署名しているか」を確認できなければ被害は成立します。署名前に委任先アドレスと実行内容を表示するウォレットを使い、緊急性を煽る署名要求には応じないことが、鍵管理と同じ重みで必要です。

関連記事

仕組みから理解する：

• ERC-4337とは — 4コンポーネントの基本動作と役割分担
• EIP-7702の事業者向け解説 — 委任の仕組みと実装経路
• AA完全マップ2026 — スマートアカウント領域の全体俯瞰と本記事の位置づけ

設計・運用の個別論点：

• Safeのモジュラー構成と採用判断 — Bybit事件の詳細と署名検証運用の設計
• Smart Walletスタック比較2026 — 監査履歴を含む実装の比較選定
• ガスレストランザクションの経済性 — Paymasterの費用実勢と負担設計
• MPCウォレットとAAの違いと組み合わせ — 鍵の分散管理という別レイヤーの防御
• AAの規制該当性 — 構成ごとのカストディ該当性の論点

XTELAが支援できる範囲

AAのセキュリティは、どの実装を選ぶかと同じくらい、「どの層の防御を仕様・商用インフラ・自社実装・運用のどれに割り当てるか」という設計の比重が大きい領域です。XTELAは、脅威の整理とアーキテクチャ設計、ERC-4337・EIP-7702系スタックの比較選定、Paymasterポリシー・モジュール構成・委任先設計のレビュー、PoC・実装、監査に出す前の設計文書化（脅威モデル・信頼境界の整理）、署名手順・監視を含む運用設計の技術文書化まで、Web3サービスの技術面を支援しています。カストディ該当性など法令・会計・税務の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術構成の整理を支援します。

AA・スマートウォレットのセキュリティ設計について相談する

主要参考資料

• ERC-4337: Account Abstraction Using Alt Mempool（Final、2026年8月11日閲覧）
• EIP-7702: Set Code for EOAs（Final、2026年8月11日閲覧）
• ERC-7562: Account Abstraction Validation Scope Rules（Draft、2026年8月11日閲覧）
• ERC-7579: Minimal Modular Smart Accounts（Draft、2026年8月11日閲覧）
• Ethereum Foundation: Pectra Mainnet Announcement（2025年4月23日）
• eth-infinitism/account-abstraction: Releases（EntryPoint v0.6〜v0.9）
• eth-infinitism/account-abstraction: Audit Reports
• Wintermute: EIP-7702委任の97%超が同一sweeperコード（2025年5月末）
• Wintermute: EIP-7702 is not flawed（2025年6月上旬）
• CoinDesk: Post-Pectra Malicious Contracts（2025年6月2日）
• SlowMist: 2025 Mid-Year Blockchain Security and AML Report（2025年7月）
• Scam Sniffer: 2025 Crypto Phishing Losses（2026年1月）
• Sygnia: Investigation into the Bybit Hack（2025年）
• FBI IC3: North Korea Responsible for $1.5 Billion Bybit Hack（2025年2月26日）
• Chainalysis: 2025 Crypto Hacking Trends（2025年12月）
• Fireblocks: First Account Abstraction Wallet Vulnerability（2023年10月）
• Code4rena: Biconomy Audit Report（2023年1月）
• Parity Technologies: Postmortem on the Multi-Sig Library Self-Destruct（2017年11月）
• OpenZeppelin: On the Parity Wallet Multisig Hack（2017年7月）
• Safe Docs: Safe Modules（2026年8月11日閲覧）
• Pimlico Docs: Sponsorship Policies（2026年8月11日閲覧）
• Alchemy Docs: Gas Manager Policy（2026年8月11日閲覧）
• Coinbase CDP Docs: Paymaster（2026年8月11日閲覧）
• BundleBear: ERC-4337 Overview（2026年8月11日閲覧）
• Arbitrum DAO Forum: Trail of Bits ARDC Application（2024年2月）
• arXiv: EIP-7702 Phishing Attack（2025年12月）

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。仕様のうちERC-7562とERC-7579はDraft段階であり今後変わり得ます。統計値、被害額、製品の提供条件も更新されるため、導入判断の際は最新の一次情報を確認してください。セキュリティ実装・監査の個別判断は監査会社等の専門家に、法令・会計・税務の判断は有資格の専門家に相談してください。