Kernel（ZeroDev）の採用判断｜権限設計の自由度で選ぶモジュール型スマートアカウント

「Kernel（ZeroDev）を自社サービスのスマートアカウント実装として採用すべきか」への2026年8月時点の答えは、session key（限定権限の一時鍵）や多段承認のような権限設計の自由度が要件の中心なら第一候補、そこまでの自由度が不要なら運用の軽い他実装を先に検討するです。Kernelは、署名検証・実行・実行前後の検査といった機能をモジュールとして後付け・差し替えできるモジュール型スマートアカウント（アカウントとして機能するスマートコントラクト）の実装で、モジュール型スマートアカウントの標準案ERC-7579（ZeroDevチームも共同著者として策定に参加）にネイティブ準拠した代表的実装です。ファクトリー（アカウントを生成するコントラクト）別の累計デプロイは約568万アカウントと、判別可能なファクトリーではAlchemy系に次ぐ規模で使われています（BundleBearファクトリー統計、2026年8月12日閲覧）。

ただし、Kernelの採用判断で見誤りやすいのは機能ではなく依存の構造です。コントラクト本体はMITライセンスのオープンソースで、SDKは公式ドキュメントが他社製Bundler・Paymasterとの互換を明言しており、「Kernel採用＝ZeroDevのSaaSにロックイン」という単純な図式ではありません。また、開発元のZeroDevは2025年8月にArbitrum開発元のOffchain Labsに買収され、「小規模スタートアップへの依存」という従来の懸念も構図が変わりました。本記事は、モジュール構造が実際に可能にすること、v3.3とv4.0というバージョンの現在地、依存を層別に分解した評価、採用・見送りの切り分けまでを、2026年8月12日時点の一次情報で整理します。SafeやAlchemy等との横並び比較はSmart Walletスタック比較2026、アカウントアブストラクション（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移す技術群。以下AA）全体の俯瞰はAA完全マップ2026で扱っているため、本記事はKernel単体の採用判断に集中します。

何を採用することになるのか — Kernelはアカウント実装、ZeroDevはSDKとインフラの提供元

最初に押さえるべきは、「Kernel」と「ZeroDev」が指すものの違いです。Kernelはスマートアカウントのコントラクト実装で、GitHub上でMITライセンスのオープンソースとして公開されています（zerodevapp/kernel）。ZeroDevはそのKernelを使うためのSDKと、Bundler（UserOperationをまとめてチェーンへ送る中継ノード）・Paymaster（ガス代を肩代わりするコントラクトとサーバ）・管理ダッシュボードなどのインフラをSaaS（事業者がホスティングして提供するサービス）として提供する開発元です。この区別が採用判断の土台になります。後述するとおり、契約やコストの議論はほぼすべてSaaS層の話であり、コントラクト層には及ばないからです。

Kernelの適用範囲は、ERC-4337とEIP-7702の両系統をカバーします。ウォレットを持たない新規ユーザーにはERC-4337のコントラクトアカウントとして新規デプロイし、MetaMask等の既存EOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント）を持つユーザーにはEIP-7702の委任先コントラクトとして同じKernel（v3.3）を使えます（ZeroDev 7702クイックスタート）。どちらの規格から入るべきかという論点自体はERC-4337とEIP-7702の使い分けで扱っていますが、アカウント実装を1つに保ったまま両系統へ展開できることは、併用構成を取る事業者にとってKernelを選ぶ実務上の理由になります。

モジュール構造が可能にすること — モジュールの分類とpermissions

Kernelの設計の中心は、アカウントの機能をモジュールとして外付けする構造です。現行の本番系列であるv3系は、ERC-7579の分類に沿った4種類のモジュールを採用しています。従来型の実装では署名検証や実行ロジックがコントラクト本体に固定されているのに対し、Kernelではローンチ後にモジュールを追加・削除でき、しかもユーザー単位で構成を変えられます。

なお、次世代のv4ではこの分類自体が拡張されます。v4のREADMEは、上記4種に加えてPolicy・Signerを第一級のモジュール種別として明記しており、合計6種類（Validator・Executor・Fallback・Hook・Policy・Signer）になります（Kernel README、2026年8月12日閲覧）。v3系ではpermissions機構の内部要素だったPolicy・Signerが、v4で独立したモジュール種別に昇格したと捉えると差分を追いやすくなります。

実務でこの構造が最も効くのは権限の細分化です。現行のpermissions機構は、1つの権限を「1つのSigner（誰が署名するか）＋N個のPolicy（どの条件で許可するか：対象コントラクト・支出上限・有効期間など）＋1つのAction（どの実行関数に処理を委ねるか。多くの用途ではデフォルトのexecute関数のまま）」の組み合わせとして定義しており、root権限のValidatorに触れることなくsession keyを発行できます（ZeroDev permissions公式ドキュメント）。ゲーム内アイテムの購入を毎回の署名なしで通す、一定額以上だけ追加承認を要求する、といった「毎回フル署名させたくないが権限は絞りたい」要件に直結します。具体的な権限スコープと期限の設計はsession keyの設計と運用で、複数操作の一括実行はバッチトランザクションの実装で詳述しています。

逆に言えば、この自由度を使う予定がないならKernelを選ぶ決定的な理由は薄れます。ガス代の肩代わりとpasskeyログインだけであれば、モジュールの概念を学習しなくても済むマネージド一体型の実装で足ります。この切り分けは後段の採用判断で改めて扱います。

バージョンの現在地 — 本番はv3系、v4.0は監査報告の公開待ち（2026年8月時点）

Kernelはバージョンによって準拠規格と実務上の位置付けが大きく異なるため、採用時はバージョン選定そのものが設計判断になります。判断に関わる主要バージョンを抜粋します（Kernelリリース履歴）。

注意すべき点は2つあります。第一に、2026年7月7日に公開された次世代のv4.0を、現時点で本番採用するのは時期尚早だということです。v4.0はERC-4337の共通コントラクトEntryPointの最新版v0.9（2025年11月リリース。eth-infinitism v0.9.0）に対応した意欲的な再構成ですが（v4.0リリースノート）、リポジトリの監査報告一覧にv4.0の報告書はまだ掲載されていません（auditsディレクトリ、2026年8月12日閲覧）。監査済みバージョンを本番に使うという原則に従えば、現時点の選択はv3系です。

第二に、SDKはバージョンを暗黙に決めてくれないことです。ZeroDev SDKはv5.3以降、利用するKernelバージョンの明示指定を必須にしており（ZeroDev SDKドキュメント）、どの版のコントラクトに載るかはアプリ側の設計判断です。公式の案内も用途で分かれており、アカウント作成の一般ドキュメントはERC-4337の新規プロジェクトへ「Kernel v3.1＋EntryPoint 0.7」を推奨する一方、EIP-7702の委任先としてはv3.3（KERNEL_V3_3）を提示しています（ZeroDev 7702クイックスタート、いずれも2026年8月12日閲覧）。つまり「v3.3が現行系列の最新」であることは「すべての新規実装にv3.3を使う」ことを意味せず、ERC-4337経路かEIP-7702経路か、どのEntryPoint世代へ接続するかで版を選定します。監査状況はChainLightによるv3.0本体の監査に加え、Kalosによるplugin群・WebAuthn validator・リカバリ機構の監査報告がリポジトリで公開されています（同上）。第三者の比較資料でも、KernelはChainLightとKalosの監査を受けたガス効率の高い実装として整理されています（Pimlicoによるスマートアカウント比較）。

何に依存するのか — コントラクト・SDK・インフラの3層で分解する

「Kernelを使うとZeroDevに縛られるのか」という問いは、層を分けると答えが明確になります。

ポイントは、構造的なロックインが生じる層がほぼないことです。ZeroDevの公式ドキュメントは「ZeroDevはあらゆるAAインフラプロバイダと互換」と明記しており、Bundlerは接続先RPCの指定だけで他社へ切り替えられます（ZeroDev: インフラプロバイダの選択）。かつて「コントラクトはOSSだが、運用はZeroDevのSaaSが事実上の前提」と評価されることの多かった構成は、標準API（ERC-7677）の普及とSDKのプロバイダ非依存化で、現在は「デフォルトとして便利だから使う」性質のものに変わっています。

一方で、付加機能に依存するほど切り替えコストは静かに積み上がります。ZeroDevのSaaSには、Bundler・Paymasterを一体化して通常のBundler経由よりガスと遅延を抑えるとする独自リレーUltraRelay（公式ドキュメント。数値は提供元の説明）や、チェーンをまたいだ残高利用を可能にするチェーン抽象化機能が含まれ、これらはZeroDevのSaaSでのみ動きます。料金はSandbox（テストネット無料）・Launch（月69ドル）・Scale（月399ドル）・Enterpriseのcredit制で、ガス肩代わり額への手数料はSandbox・Launch・Scaleが8%、Enterpriseは料金・手数料とも個別条件（Custom）です（ZeroDev料金ページ、2026年8月12日閲覧）。ガス肩代わりの費用は事業者側の変動費として積み上がるため、単価と回収設計はガスレストランザクションの経済性で試算方法を含めて扱っています。Bundler・Paymaster・SDKをどの組み合わせで持つかという選定論はAA開発スタックの選定2026を参照してください。

供給者リスクの再評価 — 2025年8月、Offchain Labsによる買収

Kernelの採用判断で長らく挙げられてきた懸念が「開発元が小規模スタートアップである」ことでした。この前提は2025年8月13日に変わりました。Arbitrumの開発元であるOffchain LabsがZeroDevを買収し、チームはOffchain Labsへ合流しています（ZeroDev公式ブログ、Offchain Labsプレスリリース 2025年8月13日）。買収時点でZeroDevのインフラは30超のチェーンで500万超のスマートアカウントを支えており、現在の公式サイトは130超のチェーン対応・1,000万超のスマートアカウントを掲げています（ZeroDev公式サイト、2026年8月12日閲覧）。なおこの公式値はZeroDevによる自社集計のマーケティング値であり、冒頭で示したBundleBearの約568万という数値（オンチェーンで判別できるKernelファクトリー経由デプロイの集計）とは、集計主体も対象範囲も異なります。

事業継続性の観点では、単独スタートアップの資金枯渇によるサービス停止という古典的なリスクは後退したと評価できます。一方、これは推測として明示しますが、親会社がArbitrumエコシステムの当事者になったことで、今後の機能投資やチェーン対応の優先順位がArbitrum系に寄る可能性は、Arbitrum以外のチェーンを主戦場とする事業者ほど織り込んでおくべき変数です。買収後もマルチチェーン対応は維持されており、現時点で特定チェーン限定になる兆候が公表されているわけではありません。いずれにせよ、前節のとおりSDK・インフラ層は代替可能な構成を保てるため、この変数への備えは「乗り換えられる設計を維持すること」に帰着します。

採用に向くケース、別の実装が向くケース

ここまでの内容を採用判断に落とすと、次の切り分けになります。

Kernelが第一候補になるケース：

• 権限設計が要件の中心にある。session keyの粒度制御、金額条件付きの承認フロー、独自の署名検証など、permissions機構とモジュール差し替えを実際に使う見込みがある。
• 新規ユーザーへのERC-4337発行と既存EOAへのEIP-7702委任を、1つのアカウント実装で揃えたい。
• インフラ選定の自由を残したい。Bundler・Paymasterを将来他社製へ切り替える余地を、アカウント実装を変えずに確保したい。
• ERC-7579エコシステムのモジュール資産を活かしたい。標準準拠モジュールの再利用や自社モジュールの横展開を見込む。

別の実装を先に検討すべきケース：

• 共同資産管理・マルチシグの運用実績が最優先なら、機関利用の蓄積があるSafe系が候補です（Safe Modularの採用判断）。
• マネージド一体型で最短ローンチしたいなら、Alchemyのスタックに載るModular Account系が運用の手数を減らします（LightAccount/Alchemyの採用判断）。
• チェーン横断のガスレス実行が主要件なら、Biconomyのスタックも比較対象になります（Biconomyの採用判断）。
• モジュールの概念を学ぶ工数を確保できない短期案件では、Kernelの自由度は使われないまま学習コストだけが残ります。

5実装の横並び比較と選定手順はSmart Walletスタック比較2026にまとめています。

採用を決めたら見積もりに織り込むこと

最後に、Kernel採用を前提にした際、見積もり・設計段階で漏れやすい4点を挙げます。

• 独自モジュールの監査費は自社負担。リポジトリで公開されている監査はKernel本体と公式plugin群が対象です。自社開発のValidatorやHookは監査範囲外であり、資産を扱うロジックなら監査費用と期間を見積もりに含めます。
• SDKの追従コスト。SDK v5.3でKernelバージョン指定が必須化されたように、SDKには破壊的変更が入ります（ZeroDev SDKドキュメント）。EntryPointの世代交代（v0.7→v0.8→v0.9）と並走するため、年単位での追従工数を運用計画に置きます。
• インフラ障害時の切り替え経路。Bundlerは接続先RPCの差し替えで他社へ切り替えられる構造を最初から持たせ、単一プロバイダ障害でトランザクション送信が全停止する構成を避けます（ZeroDev: インフラプロバイダの選択）。
• ガス肩代わりの変動費。肩代わり額への手数料（Sandbox・Launch・Scaleで8%、Enterpriseは個別条件）とcredit消費は、ユーザー数×操作頻度×ガス単価で積み上がります。無料トランザクションを提供する設計なら、上限ポリシーと回収モデルを先に決めます（試算はガスレストランザクションの経済性）。

session keyの権限スコープを過度に広げないことなど、AA実装一般のセキュリティ論点はAAセキュリティリスクで体系的に扱っています。

関連記事

全体像と規格の理解：

• アカウントアブストラクション（AA）完全マップ 2026 — AA採用判断の全体像。本記事の親記事
• ERC-4337の事業者向け解説 — UserOperation・Bundler・Paymasterの仕組み
• EIP-7702の事業者向け解説 — 既存EOAを拡張する委任の仕組み
• ERC-4337とEIP-7702の使い分け — 対象ユーザーで決まる規格選択

実装を比較・選定する：

• Smart Walletスタック比較 2026 — Kernel/Safe/Alchemy/Biconomy/Base Accountの横並び比較
• Safe Modularの採用判断 — 共同資産管理・機関向けの対抗実装
• LightAccount/Alchemyの採用判断 — マネージド一体型の対抗実装
• Biconomyの採用判断 — チェーン横断ガスレスに軸足を置く対抗実装
• AA開発スタックの選定 2026 — Bundler・Paymaster・SDKの組み合わせ

設計を深める：

• session keyの設計と運用 — 本記事のpermissions機構を使った権限設計の詳細
• バッチトランザクションの実装 — 複数操作の一括実行
• ガスレストランザクションの経済性 — Paymaster費用の試算と回収設計
• Passkey（WebAuthn）× ERC-4337 — 秘密鍵を見せない認証UX
• AAセキュリティリスク — session key悪用を含む脅威モデルと対策

XTELAが支援できる範囲

Kernelの採用判断は、権限設計の要件定義、バージョンと監査状況の見極め、インフラ依存の設計、費用構造の試算が絡む意思決定です。XTELAは、この判断軸に沿った要件整理、スマートアカウント実装とBundler・Paymaster・SDKの比較選定、session keyや承認フローを含むPoC実装、切り替え可能なインフラ構成の設計まで、Web3サービスの技術面を支援しています。法令・会計・税務に関わる判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術資料の整理を支援します。

スマートアカウント・AA導入について相談する

主要参考資料

• zerodevapp/kernel（GitHubリポジトリ）
• Kernelリリース履歴（v3.3: 2025年4月3日、v4.0: 2026年7月7日）
• Kernel監査報告一覧（ChainLight・Kalos、2026年8月12日閲覧）
• ERC-7579: Minimal Modular Smart Accounts
• ZeroDev SDK: アカウント作成とKernelバージョン指定
• ZeroDev: permissions（Signer×Policies）ドキュメント
• ZeroDev: EIP-7702クイックスタート
• ZeroDev: インフラプロバイダの選択（他社互換の明記）
• ZeroDev料金ページ（2026年8月12日閲覧）
• ZeroDev公式ブログ: Offchain Labsによる買収
• Offchain Labsプレスリリース（2025年8月13日）
• BundleBear: アカウントファクトリー統計（2026年8月12日閲覧）
• eth-infinitism: EntryPoint v0.9.0リリースノート（2025年11月16日）
• Pimlico Docs: スマートアカウント実装の比較

本記事の前提

本記事は2026年8月12日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。Kernelのバージョン、監査状況、ZeroDevの料金・提供機能、採用統計は今後変わり得ます。採用判断の際は最新の公式ドキュメントと監査報告を確認し、法令・会計・税務の該当性判断は有資格の専門家に相談してください。