スマートコントラクトウォレットのスタック比較 2026｜Safe・Kernel・Alchemy・Biconomy Nexus・Base Accountの選び方

自社サービスに組み込むスマートコントラクトウォレット（ERC-4337のスマートアカウント実装。以下、規格上の呼称であるスマートアカウントも併用します）は、2026年8月時点では法人・DAOの共同資産管理ならSafe、権限設計やモジュールを自社で作り込むならKernel（ZeroDev）、組み込みウォレットまで含めて最短で立ち上げるならAlchemyのModular Account v2、複数チェーン横断のガスレス実行ならBiconomy Nexus、Baseを主戦場とするコンシューマ向けのpasskey最速オンボーディングならBase Account（旧Coinbase Smart Wallet）が、それぞれの第一候補です。そして、どれを選ぶにしても順序が重要です。スマートアカウントはデプロイ後のコントラクトアドレスがそのままユーザーのウォレットアドレスとして資産・履歴と結び付きます。同一実装系統の中にはupgradeやモジュール差し替えといった更新経路が用意されている一方、異なる実装系統への乗り換えは標準化されておらず、既存ユーザーのアドレス・資産の移行を伴う高コストな作業になりがちです。だからSDKやBundlerより先に、この層を要件から決めます。

加えて、2025年から2026年にかけて選定の前提が2つ変わりました。第一に、主要製品の名称と世代が大きく入れ替わりました。Coinbase Smart Walletは2025年7月にBase Accountへ改称され（Base公式発表）、Biconomyの現行実装はNexusへ世代交代し、AlchemyのSDKはAccount KitからSmart Wallets（Wallet APIs）へ再編されています。第二に、EIP-7702の有効化（2025年5月のPectraアップグレード）で、「新規にスマートアカウントを発行する」以外に「既存のEOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント）をそのままスマートアカウント化する」経路が加わりました。本記事はこの現状を前提に、5スタックを2026年8月11日時点の一次情報で比較します。AA（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移す技術群。以下AA）全体の仕組みと採用判断はAA完全マップ2026を参照してください。

なぜ「どの実装か」を最初に決めるのか

AAの開発スタックは、スマートアカウント実装・クライアントSDK・Bundler／Paymaster・EntryPointの4層に分解できます（層ごとの選び方はAA開発スタックの選定2026で詳述）。このうちBundler（ERC-4337で操作要求を表すデータであるUserOperationを、まとめてチェーンへ送信するノード）やPaymaster（ガス代を肩代わりする仕組み）は標準に準拠していればエンドポイントの差し替えで乗り換えられ、SDKもアプリケーション層の書き換えで移行できます。スマートアカウント実装の層で事情が変わるのは、コントラクトアドレスがユーザーの資産・取引履歴・各種許可設定と結び付いているためです。ここで正確に区別すべきは「アドレス」と「実装ロジック」です。アドレスを変えることは全ユーザーの引っ越しを意味しますが、実装ロジックが不変とは限りません。たとえばKernelの次世代実装は、同一のproxyアドレスを保ったまま実装コントラクトを更新できるUUPS方式（KernelUUPS）を標準のデプロイ形態にしており（Kernel公式リポジトリ、2026年8月11日閲覧）、ERC-7579／ERC-6900系のモジュール型アカウントは、そもそも機能単位（モジュール）の追加・差し替えを前提に設計されています。

それでも「後から自由に乗り換えられる」わけではありません。upgradeやモジュール差し替えが成立するのは、同一実装系統の中で、proxyのupgrade権限とstorage互換性が保たれている範囲に限られます。異なるfactory・実装系統への乗り換え（たとえばSafe系からKernel系へ）には標準化された経路がなく、原則として既存ユーザーのアドレスと資産の移行を伴います。同一ベンダー内の世代交代であれば、BiconomyがSmart Account V2からNexusへアドレス・残高・履歴を保持したまま移行する手順を提供しているように、公式の移行経路が用意される場合があります（Biconomy公式移行ガイド）。EIP-7702の委任なら、EOAのアドレスを維持したまま委任先コントラクトを後から変更できます。ただしいずれも系統をまたぐ移行を標準化するものではなく、実務では「新規ユーザーだけ新実装」という分割運用に落ち着きがちで、それ自体が恒久的な運用負債になります。最も動かしにくい判断だからこそ、最初に、要件から決めます。

2025〜2026年に変わった2つの前提

前提1: 主要製品の名称と世代が入れ替わった

この分野の情報は古くなるのが速く、2024年時点の製品名のままの記事が検索結果に多く残っています。2026年8月時点の対応関係は次のとおりです。

名称の変化は表面的な話ではありません。旧名称を前提にした技術選定資料は、サポート状況・SDK・料金の前提ごと古くなっている可能性が高く、この1年の再編（買収・改称・提供終了）はベンダー継続性というリスク軸が実在することの証拠でもあります。

前提2: EIP-7702で「既存EOAのまま」の経路が加わった

EIP-7702は、2025年5月7日にEthereumメインネットで有効化されたPectraアップグレードに含まれる仕様で、EOAに委任先コントラクトを設定し、EOAのアドレスを保ったままスマートアカウントの機能（バッチ実行、ガス肩代わり、passkey署名など）を使えるようにします（EIP-7702仕様、Ethereum Foundation公式ブログ）。ERC-4337と対立する仕組みではなく、EntryPoint v0.8以降は7702認可をネイティブに扱います（EntryPoint v0.8.0リリースノート）。両者の使い分けはERC-4337とEIP-7702の違いと使い分けで詳述しています。

普及も進んでいます。委任が有効なEOA（smart EOA）は累計約4,656万アカウントに達しています（BundleBear EIP-7702統計、2026年8月11日閲覧）。選定上重要なのは、5スタックの7702対応に明確な差があることです。ZeroDevはKernel v3.3以降で本番SDKに組み込み済み、BiconomyはNexus v1.2.0を7702委任先として設計し、AlchemyはWallet APIsで7702をデフォルト有効にしています。一方Safeの7702向け実装は公式ドキュメントが「実験的・未監査」と明記する段階で、Base Accountは製品としての7702提供を公式情報で確認できません（各出典は次章）。既存EOAユーザーの多いサービスほど、この差が効きます。

5スタックの現在地（2026年8月）

Safe — 共同資産管理の標準。組み込み用途では重量級

Safeはマルチシグ（複数の鍵によるしきい値承認）運用の実績が最も厚いスマートアカウントで、法人・DAO・機関の資産管理では事実上の標準です。Safe Foundationの四半期レポートによれば、2026年Q1時点で累計6,111万アカウント、保護資産は352.5億ドルに達し（Q1 2026レポート）、Q2には累計アカウントが6,300万を超えました。同レポートには、Ethereum Foundationが財務執行をSafeマルチシグから直接行った事例も記載されています（Q2 2026レポート）。

技術面では、コントラクト本体（Safe Smart Account）の最新版はv1.5.0（2025年7月リリース、GitHubリリース）。ERC-4337へはネイティブ対応ではなく、Safe v1.4.1以上にSafe4337Moduleを追加する方式で対応します（Safe公式ドキュメント）。ERC-7579モジュールはRhinestoneと共同開発したSafe7579 Adapter経由で利用できます（Safe7579ドキュメント）。注意すべきはEIP-7702で、Safeの7702向け実装（SafeEIP7702Proxy等）は公式ドキュメントが実験的・未監査と明記しており、2026年8月時点で本番利用できる7702プロダクトはありません（Safe EIP-7702ドキュメント）。

向いているのは、資産保全を最優先する法人・DAOのトレジャリー、複数承認者による運用が必須の資金管理です。逆に、エンドユーザー1人に1つずつ発行するコンシューマ組み込み用途では、後述の4スタックの方が設計上の主流です。詳細はSafeのモジュラー構成と採用判断を参照してください。

Kernel（ZeroDev）— ERC-7579ネイティブ。権限設計の自由度で選ぶ

KernelはERC-7579（モジュール型スマートアカウントの標準案）にネイティブ準拠したモジュール型実装で、Validator（誰が署名できるか）・Executor（何を実行できるか）・Fallback・Hook（実行前後の検査）を差し替えて構成します。現行の本番バージョンはv3.3（2025年4月リリース）で、EIP-7702対応もこの版からSDKに組み込まれています（Kernelリリース履歴、ZeroDev 7702クイックスタート）。次世代のv4.0コントラクトも2026年7月に公開されましたが、SDK・ドキュメントの本流は執筆時点でv3.3です。

実務上の強みは権限の細分化です。現行のpermissions機構は「Signer（誰が）×Policies（どの条件で: 対象コントラクト・支出上限・時間制限など）×Action（何を）」の組み合わせで session key（限定権限の一時鍵）を構成でき、ゲームや自動実行のような「毎回フル署名させたくない」ユースケースに直結します（permissions公式ドキュメント）。設計パターンはsession keyの設計と運用で詳述しています。ファクトリー別の累計デプロイ数では約568万アカウントと、判別可能なファクトリーとしてAlchemy系に次ぐ規模です（BundleBearファクトリー統計、2026年8月11日閲覧）。

事業面では、2025年8月にArbitrum開発元のOffchain Labsに買収されました（ZeroDev公式ブログ）。料金は公式ページで公開されており、メインネット利用は月69ドルから、ガス肩代わり額への8%の手数料が全プラン共通です（ZeroDev料金ページ、2026年8月11日閲覧）。コントラクトとSDKはオープンソースで、詳細はKernel（ZeroDev）の採用判断を参照してください。

Modular Account v2（Alchemy）— 一体型マネージドの最短ルート

Alchemyが新規開発に推奨するスマートアカウントはModular Account v2で、モジュール規格はERC-7579ではなくERC-6900に準拠します。ChainLightとQuantstampの監査（2024年12月）を経ており、デプロイ時のランタイムガスが10万未満と軽量な点も公式に公表されています（Modular Account v2公式ドキュメント）。旧世代のLightAccount系は、Wallet APIs上では既存デプロイメント向けの後方互換（backwards compatibility）と位置づけられており、新規統合の推奨・デフォルトはModular Account v2です（アカウント選択ガイド、Wallet APIsアカウント一覧、いずれも2026年8月11日閲覧）。

Alchemyの特徴は垂直統合です。メール・ソーシャルログイン等の組み込みウォレット機能、Bundler（OSS実装Rundler）、ガス肩代わりのGas Manager、そしてEIP-7702をデフォルト有効にしたWallet APIs（委任先はModular Account v2のみをサポート）までを一体で提供します（Alchemy 7702ドキュメント）。ファクトリー別の累計デプロイ数は約1,374万アカウントで最多です（BundleBear、2026年8月11日閲覧）。

選定上の注意は、ERC-6900系のモジュールがKernel・Nexusら（ERC-7579系）のモジュールと互換性を持たないことです。どちらの規格もEIP上はDraft段階であり（ERC-6900／ERC-7579、2026年8月11日閲覧）、モジュールのエコシステムごと選ぶ判断になります。組み込み速度と引き換えにAlchemyのマネージド構成への依存度は高くなるため、その損益分岐はAlchemyスタックの採用判断で整理しています。

Nexus（Biconomy）— チェーン横断のガスレス実行に軸足

Biconomyの現行スマートアカウントはNexusです。ERC-7579準拠のモジュール型で、v1.2.0（2025年4月）からはEIP-7702の委任先として動作するよう設計されています。監査はCodeHawks-Cyfrin・Spearbit・Zenith・Pashovの4件が公開されています（Nexusリポジトリ）。「Biconomy MSA（Modular Smart Account）」という旧通称の製品（Smart Account V2）は非推奨化が進行しており、前述のとおりアドレスを保持したままNexusへ移行する手順が公式提供されています。

現在のBiconomyの差別化はアカウント単体よりも実行基盤側にあります。MEE（Modular Execution Environment）とSupertransaction APIは、複数チェーン・複数操作を1回の署名でまとめて実行する仕組みで、通常のスマートアカウントモードに加え、既存EOAモードとEIP-7702委任モード（eoa-7702）を選べます（MEE公式発表、7702実行モードのドキュメント）。SDKはviemに近い書き味のAbstractJSへ世代交代しています（@biconomy/abstractjs、2026年8月11日閲覧）。

向いているのは、複数チェーンへ同時展開しながらガスレスUXを提供したいサービスです。ガス肩代わりの費用構造はガスレストランザクションの経済性と併せて検討してください。詳細はBiconomy Nexusの採用判断を参照してください。

Base Account（旧Coinbase Smart Wallet）— passkeyでの最速オンボーディング

Base Accountは、2025年7月にCoinbase Smart Walletから改称されたpasskey（WebAuthn：パスワードレス認証の標準規格）ベースのスマートアカウントです（Base公式発表）。ユーザーはウォレットアプリをインストールせず、端末の生体認証で生成されるpasskeyを署名鍵として使います。コントラクトはERC-4337準拠のマルチオーナー設計で、passkey（secp256r1公開鍵）とEOAアドレスの両方をオーナーに登録でき、v1.1コントラクトは248チェーンにデプロイ済みです（コントラクトリポジトリ、Base Account公式ドキュメント、いずれも2026年8月11日閲覧）。メインネットはBase・Ethereum・Arbitrum・Optimism・Polygon・BNB Chain・Avalanche・Zoraなどが標準で有効です。

ガス代は、事業者側がCDP（Coinbase Developer Platform）のPaymasterでコントラクト許可リストや支出上限を設定して肩代わりする方式が基本で（CDP Paymasterドキュメント）、ユーザー側はMagicSpendでCoinbase取引所残高をそのままオンチェーン利用できます（MagicSpendドキュメント）。開発者向けには、アプリ内で確認プロンプトなしの操作を可能にするSub AccountsとSpend Permissionsが提供されています（Sub Accountsドキュメント）。一方で注意点も明確で、フロントSDKのOnchainKitは2026年3月にサンセットが発表され、Base Account SDK＋wagmi／viemへの移行が必要です。モジュール規格（ERC-7579／6900）には対応せず機能は固定的で、EIP-7702の製品提供も公式情報では確認できません（2026年8月11日時点）。

向いているのは、Baseを主戦場に「ウォレットを持たない層」を最短で取り込みたいコンシューマアプリです。passkey認証の設計論点はpasskeyウォレットの仕組みとリスクで詳述しています。ファクトリー別の累計デプロイ数は約366万アカウントです（BundleBear、2026年8月11日閲覧）。

横断比較 — 検証可能な軸だけで並べる

5スタックを、2026年8月11日時点で一次情報から確認できる軸で比較します。UX・開発体験のような定性評価は要件依存のため、この表では扱いません。

2点補足します。第一に、BundleBearのファクトリー統計はERC-4337ファクトリー経由の累計デプロイ数であり、SafeのようにERC-4337以外の経路（通常のマルチシグ運用）が主流のスタックはこの統計に現れません。数字の出どころが異なるため、列同士の単純比較はできません。第二に、ERC-4337全体では累計UserOperationが約12.4億件、実行歴のあるスマートアカウントが約6,368万に達しており（BundleBear全体統計、2026年8月11日閲覧）、「規格自体が使われるかどうか」という2023年頃の不確実性は既に解消しています。

選定の手順とよくある落とし穴

実際の選定は、次の順で絞り込むと手戻りが少なくなります。

1. 運用形態で大きく分ける：複数承認者による共同資産管理が目的ならSafe系、エンドユーザー1人ひとりに発行する組み込みウォレットなら残る4スタック、とまず分岐します。
2. 既存ユーザーのアカウント形態を確認する：既にEOAユーザーを多く抱えているなら、新規発行（ERC-4337）だけでなくEIP-7702での既存アドレス継続を検討します。この場合、7702対応が本番段階のスタック（Kernel・Nexus・Modular Account v2）が候補になります。
3. モジュール規格のエコシステムを選ぶ：session keyやソーシャルリカバリー等を自社で組み合わせるならERC-7579系（Kernel・Nexus・Safe7579）、Alchemyの一体型に乗るならERC-6900系です。両者のモジュールは互換性がありません。
4. インフラの依存度を決める：Bundler・Paymasterを同一ベンダーで揃えると立ち上げは速く、分離すると乗り換え余地が残ります。層ごとの分離方法はAA開発スタックの選定2026を参照してください。
5. 実装の更新・乗り換え経路を個別に確認する：候補ごとに、(1) proxyのupgrade可否と、upgrade権限を誰が持つか、(2) upgrade時のstorage互換性がどう担保されるか、(3) モジュールの互換性（ERC-7579系とERC-6900系は非互換）、(4) ベンダー公式の世代移行手順の有無（例：Biconomy V2→Nexus）、(5) EIP-7702運用なら委任先コントラクトの変更手順、を分けて確認します。異なる実装系統への乗り換えは標準化されていないため、この5点が事実上の「撤退可能性」の評価になります。
6. 撤退条件まで文書化する：ベンダーの買収・改称・提供終了は2025〜2026年に実際に起きています。契約前に、データ・鍵・コントラクトの何が自社管理下に残るかを確認します。

あわせて、実際の案件で繰り返し見る落とし穴を挙げます。

• 「PoCの実装をそのまま本番に」問題：異なる実装系統への乗り換えが標準化されていないため、PoCで選んだスタックが暗黙のうちに本番の選定になりがちです。PoC開始時点で「本番もこの実装系統でよいか」を一度明示的に判断するだけで、後の移行コストを回避できます。
• モジュール規格の将来変動：ERC-7579もERC-6900もEIP上はDraft段階です（2026年8月11日閲覧）。現時点の採用実装が多いのは7579系ですが、規格自体が確定済みという前提では設計しないでください。
• Paymaster費用の見落とし：SaaS利用料とは別に、肩代わりしたガス代そのものは自社負担です。ユーザー数×操作頻度×ガス単価の試算を初期に行ってください。試算の枠組みはガスレストランザクションの経済性で提供しています。
• 自社モジュールの監査漏れ：コア実装が監査済みでも、自社で追加するValidator・Executor・Paymasterは別途監査対象です。攻撃事例と防御設計はAAのセキュリティリスクを参照してください。
• 7702委任先の安全性：EIP-7702はEOAに任意のコードを委任できるため、委任先コントラクトの検証を欠くと資産流出に直結します。既に実被害が報告されている領域です（詳細は上記セキュリティ記事）。

よくある質問

Coinbase Smart Walletはなくなったのですか？

製品は継続しており、2025年7月に「Base Account」へ名称が変わりました（Base公式発表）。既存のCoinbase Smart Walletユーザーはそのまま移行されています。なお、モバイルアプリの「Coinbase Wallet」が「Base App」になったのは同時期の別の改称で、スマートアカウント製品（Base Account）とは対象が異なります。

LightAccountは今から採用してもよいですか？

新規統合では原則Modular Account v2を選びます。AlchemyはLightAccountの提供とサポート自体を終了していませんが、Wallet APIs上ではLightAccount系を既存デプロイメント向けの後方互換（backwards compatibility only）と位置づけ、新規統合にはModular Account v2を推奨・デフォルトにしています（Wallet APIsアカウント一覧、アカウント選択ガイド、いずれも2026年8月11日閲覧）。既にLightAccountで運用中のデプロイメントはサポートが継続されるため、そのまま利用できます。これから始める統合であえてLightAccountを選ぶのは、モジュール機能やsession keyを使わずガスコスト最小化を最優先する構成など、限定的な場合に絞られます。

EIP-7702が使える今、ERC-4337のスマートアカウントは不要になりませんか？

なりません。EIP-7702は既存EOAに委任先コードを設定する仕組み、ERC-4337はUserOperationの検証・実行・ガス肩代わりを担うインフラで、補完関係にあります。実際、EntryPoint v0.8はEIP-7702認可をネイティブにサポートし、主要スタックは「7702で既存EOAを自社のスマートアカウント実装へ委任させる」形で両者を組み合わせています。新規ユーザー中心なら4337での新規発行、既存EOAユーザーの取り込みなら7702、という使い分けが2026年8月時点の実務解です。詳しくはERC-4337とEIP-7702の違いと使い分けを参照してください。

一度選んだスタックを後から乗り換えられますか？

どの範囲での乗り換えかで難易度が分かれます。同一実装系統の中であれば、proxyのupgrade（例：Kernelの次世代実装KernelUUPSは同一アドレスのまま実装コントラクトを更新可能）、モジュールの差し替え、ベンダー公式の世代移行（例：Biconomy Smart Account V2→Nexusはアドレス保持のまま移行可能）といった経路があります。EIP-7702で運用しているEOAなら、委任先コントラクトを後から変更できます。一方、異なるfactory・実装系統への乗り換えは標準化されておらず、既存ユーザーのアドレス変更（資産・履歴・許可設定の移行）を伴うため、実務上は困難です。将来の柔軟性を重視するなら、upgrade権限・storage互換性・公式移行手順を選定時に確認しておくこと、既存EOAユーザーが多いならEIP-7702前提の設計にしておくことが、現時点で有効な保険になります。

関連記事

全体像と規格を押さえる：

• AA完全マップ2026 — 採用判断の全体像。本記事の親記事
• ERC-4337の事業者向け解説 ／ EIP-7702の事業者向け解説 ／ ERC-4337 vs EIP-7702の判断軸

各スタックを深掘りする：

• Safe Modularの採用判断 ／ Kernel（ZeroDev）の採用判断 ／ Alchemyスタックの採用判断 ／ Biconomy Nexusの採用判断

実装と運用の論点：

• AA開発スタックの選定2026 — SDK・Bundler・Paymaster層の選び方
• session keyの設計と運用 ／ passkeyウォレットの仕組み ／ ガスレストランザクションの経済性 ／ AAセキュリティリスク

XTELAが支援できる範囲

スマートアカウント実装の選定は、異なる実装系統への乗り換えが標準化されていないからこそ、要件定義の段階で「マルチシグか組み込みか」「7702経路を使うか」「どのモジュール規格のエコシステムに乗るか」を確定させることが重要です。XTELAは、この選定の要件整理、候補スタックの比較評価、PoC実装、本番化に向けた移行・運用設計まで、Web3サービスの技術面を支援しています。カストディ該当性など制度面の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術資料の整理を支援します。

スマートコントラクトウォレットの選定について相談する

主要参考資料

• ERC-4337: Account Abstraction Using Alt Mempool ／ EIP-7702: Set Code for EOAs
• ERC-7579: Minimal Modular Smart Accounts ／ ERC-6900: Modular Smart Contract Accounts（いずれもDraft、2026年8月11日閲覧）
• Ethereum Foundation Blog: Pectra Mainnet Announcement（2025年4月23日）
• eth-infinitism: EntryPoint v0.8.0リリースノート
• Safe Foundation: Q1 2026 Quarterly Report ／ Q2 2026 Report
• Safe: ERC-4337ドキュメント ／ Safe: EIP-7702ドキュメント
• ZeroDev: Kernelリリース履歴 ／ ZeroDev: 料金ページ（2026年8月11日閲覧） ／ ZeroDev: Offchain Labsによる買収発表（2025年8月）
• Alchemy: Modular Account v2ドキュメント ／ Alchemy: EIP-7702ドキュメント
• Biconomy: Nexusリポジトリ（監査レポート含む） ／ Biconomy: V2→Nexus移行ガイド
• Base: A New Day One（Base Account改称発表、2025年7月） ／ Base Account公式ドキュメント ／ コントラクトリポジトリ
• BundleBear: ERC-4337統計 ／ EIP-7702統計 ／ ファクトリー統計（いずれも2026年8月11日閲覧）

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術選定上の論点整理であり、投資助言・法的助言ではありません。各製品の名称・バージョン・対応規格・料金・対応チェーンは今後変わり得ます。BundleBearの統計値は集計方法上の制約（ファクトリー判別に基づく累計値）を含むため、規模感の参考としてのみ利用してください。採用判断の際は必ず各社の最新の公式ドキュメントを確認してください。