AA開発スタックの選定 2026｜viem・permissionless.js・Pimlico・Alchemy・Biconomyの組み合わせ方

AA（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移し、ガス代の肩代わりやpasskeyログインなどを可能にする技術群。以下AA）の開発スタックは、変更の影響が最も大きいスマートアカウント実装（Safe・Kernel・Nexus・Modular Account V2など）から先に決め、クライアントコードはviem＋permissionless.jsを基本線とし、Bundler・Paymasterは標準準拠のSaaSを「後から差し替え可能な部品」として選ぶのが2026年8月時点の実務解です。理由は、層ごとにベンダーロックインの強さがまったく違うからです。スマートアカウント実装は、proxy経由の実装アップグレードやモジュール交換であればアドレスを維持したまま変更できますが、別系統の実装への乗り換えにはアドレス変更と資産移行が必要になり、どの変更でもユーザーの資産を保持するコントラクトに直接手を入れることになります。SDKはアプリケーション層の書き換えで移行でき、Bundlerは標準に準拠していればエンドポイントURLの差し替えで乗り換えられます。この「乗り換えやすさの勾配」に沿って、影響が大きく巻き戻しにくい判断ほど先に・慎重に決めるのが選定の基本構造です。

この分野は2025年から2026年にかけて前提が大きく動きました。viemはv2.18.0でERC-4337のAA拡張を本体に取り込み（viem 2.18.0リリースノート）、permissionless.jsは「viemの薄い拡張」へ位置付けが変わりました（permissionless.jsドキュメント）。Bundler SaaSの一角だったStackupは開発者向けインフラから暗号資産企業向けの財務・支払いプラットフォームへ事業の軸足を移し（Stackup公式サイト、2026年8月11日閲覧）、BiconomyはERC-4337型のBundler・Paymaster提供から独自のMEEスタックへ主軸を移しました。さらにEIP-7702の有効化で「既存EOAをそのままスマートアカウント化する」構成が加わっています。本記事はこの現状を前提に、層ごとの選択肢と選定基準、要件別の構成パターンを2026年8月11日時点の一次情報で整理します。AA自体の仕組みや採用判断の全体像はAA完全マップ2026を参照してください。

選定の全体像 — 層ごとに「乗り換えやすさ」が違う

AA開発スタックは次の4層に分解でき、選定の重み付けはロックインの強さと逆順になります。つまり、いちばん乗り換えにくい層から順に決めます。

UserOperation（ユーザーオペレーション）は、ERC-4337（仕様）でスマートアカウントの操作要求を表すデータ構造で、従来のEOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント）のトランザクションに相当します。EntryPointはERC-4337仕様が定める共有のsingletonコントラクトで、仕様上も「監査と形式検証を要する中心的な信頼点」と位置付けられており、eth-infinitismが開発するreference implementationの監査済みの版が各チェーンへデプロイされています（ERC-4337仕様）。事業者が独自に実装する対象ではありませんが、アカウント実装とBundlerが前提とするEntryPointのバージョン・アドレス・対象チェーンの整合確認は選定チェック項目として残ります。したがって事業者が実際に選ぶのは上3層で、以降を層ごとに見ていきます。規格レベルの詳細はERC-4337の事業者向け解説で扱っています。

クライアントSDK — viemが土台、その上で「中立SDK」か「ベンダーSDK」かが分岐点

TypeScriptでAAを開発する場合、土台となるEthereumクライアントライブラリはviemを選ぶのが実務の基本線です。本記事で扱う主要AA SDK（permissionless.js、Alchemy Smart Wallets SDK、Biconomy AbstractJS）がいずれもviemを基盤または前提としているためです。重要な変化として、viemはv2.18.0でERC-4337のAccount Abstraction拡張を本体へ追加し、Bundlerクライアント・Paymasterクライアント・スマートアカウント操作といった基本機能を内蔵しています（viem 2.18.0リリースノート、viem Account Abstractionドキュメント）。かつて「AAヘルパーは別ライブラリが必須」だった状況は終わり、単純な構成ならviemだけでUserOperationを送信できます。

その上で、実務の分岐点は次の2択です。

ベンダー中立SDK（permissionless.js）：Pimlicoがメンテナンスするオープンソースのライブラリで、viemの流儀を保った薄い拡張として設計されています。Safe・Kernel・Biconomy・LightAccount・SimpleAccountなど主要なスマートアカウント実装を共通のインターフェースで扱え、ERC-4337標準に準拠するBundlerであれば接続先をPimlicoに限定しません（permissionless.jsドキュメント）。アカウント実装やBundlerを固定せずに選択肢を残したい場合の基本線です。

ベンダー一体型SDK：AlchemyのSmart Wallets SDK（リポジトリ名はaa-sdk。@alchemy/wallet-apis、@alchemy/smart-accounts、@alchemy/aa-infraなどの@alchemy系パッケージで構成）は、Wallet APIsを中心に、同社が推奨するERC-6900準拠のModular Account V2（ChainLight・Quantstampの監査済み）、ガス肩代わりポリシーを管理するGas Manager、メール・passkeyログイン等の組み込みウォレット機能までを一体で提供します（aa-sdkリポジトリ、Modular Account V2ドキュメント、2026年8月11日閲覧）。BiconomyのAbstractJSは、viemに近いAPIでERC-7579準拠のスマートアカウントNexusと、複数チェーン・複数操作を1署名でまとめるMEE（Modular Execution Environment）を操作します（Biconomyドキュメント）。いずれも自社インフラとの組み合わせで最短の実装体験を提供する一方、SDKの流儀がベンダー機能と密結合しているため、後から別ベンダーへ移る場合はアプリケーション層の書き換えが発生します。

判断基準は単純で、ベンダー固有機能（Gas Managerのポリシー管理、MEEのチェーン横断実行など）を製品の中核に使うならベンダーSDK、そうでなければviem＋permissionless.jsで中立性を保つのが目安です。なお、ethers.jsからの移行可否は記事末尾のFAQで扱います。

Bundler・Paymaster — 「どの社か」ではなく「継続性と料金モデル」で選ぶ

Bundler（UserOperationを集約してEntryPointへ送信するノード）とPaymaster（ガス代を肩代わりする仕組み）は、自社運用も可能ですが、可用性の確保・ガス見積もり・チェーン再編成対応などの運用負荷が重く、まずSaaSエンドポイントの利用から始めるのが現実的です。2026年8月時点で、標準準拠のBundler・Paymasterを横並びで比較できるSaaSはPimlico、Alchemy、ZeroDev、Coinbase Developer Platformなどです。自社ホスト向けにはAlto（Pimlico）、Rundler（Alchemy）などのオープンソース実装が公開されています（Alto、Rundler）。市場規模の実数としては、AA統計サイトBundleBearが追跡するEVMチェーン合算で累計UserOperationは約12.3億件、1件以上を実行したスマートアカウントは約6,360万に達しています（BundleBear、2026年8月11日閲覧）。

Biconomyはこの横並び比較には載せない方が正確です。現行の公式ドキュメントは、MEEが従来のPaymasterを置き換え、ガス肩代わりを含むスポンサーシップ機能をMEEの統一インターフェースで提供すると説明しており、課金は月末締めの後払い請求です（Biconomy Sponsorshipドキュメント、2026年8月11日閲覧）。従来型のERC-4337 Bundler・Paymaster基盤（EntryPoint v0.6／v0.7向け）は既存対応チェーンでの提供にとどまり、新規チェーンへは展開せずMEEスタックのみを展開すると明記されています（Biconomy Supported Chains、2026年8月11日閲覧）。したがってBiconomyの採用は「差し替え可能な標準Bundlerの1社」としてではなく、「チェーン横断実行を含むMEEという上位レイヤーを使うかどうか」という別軸の判断になります。

この層の選定で2025年以降に重みを増したのがベンダーの事業継続性と提供形態の変化です。かつて主要Bundler SaaSの一角だったStackupは、開発者向けBundler・Paymaster事業から、ERC-4337スマートアカウントを基盤とする暗号資産企業向けの財務・支払いプラットフォームへ事業の中心を移しました（Stackup公式サイト、2026年8月11日閲覧）。Biconomyの旧ERC-4337基盤の新規展開停止も同様に、この層では「撤退・方針転換があり得る」ことを示す実例です。Bundlerは標準準拠なら乗り換えやすい層とはいえ、Paymasterのスポンサーポリシーや課金統合は移行作業を伴います。特定ベンダーの独自RPCメソッドへの依存を避け、標準メソッドの範囲で組んでおくことが、この層の実務的な保険になります。

料金は各社でモデル自体が異なるため、単純な横並び比較よりも「自社のUserOperation数と肩代わりガス総額でいくらになるか」の試算が必要です。参考として、公式ページで確認できる料金体系は次のとおりです。

いずれもSaaS利用料とは別に、Paymasterで肩代わりするガス代そのものは自社負担です。ガスレス設計の費用構造と回収モデルはガスレストランザクションの経済性で詳しく扱っています。選定基準はおおむね次の4点に集約されます。

• 対応チェーン：自社が展開するチェーン（特にマイナーなL2や独自チェーン）に対応しているかを各社の対応表で確認する
• 料金モデルとの相性：UserOperation数が多く単価を抑えたいのか、RPC等の既存契約と統合したいのかで有利な課金体系が変わる
• アカウント実装との組み合わせ：ベンダーSDK一体型を選ぶ場合は、そのベンダーのBundler・Paymaster（またはMEEのような上位スタック）が前提になる
• 継続性とSLA：商用SLAの明示された有料契約が必要か、標準準拠の範囲で組んで乗り換え余地を保てているか

スマートアカウント実装 — 変更の影響が最も大きく、最初に決める判断

スマートアカウント実装は、デプロイされたコントラクトのアドレスがそのままユーザーのウォレットアドレスになる層です。ERC-4337仕様は、多くのSmart Contract Accountがproxy構成またはEIP-7702経由でアップグレード可能になることを想定しており、実装の変更時には新旧コントラクトのstorage layoutに衝突がないことを必ず確認するよう求めています（ERC-4337仕様）。つまり「一度デプロイしたら何も変えられない」わけではありません。変更のコストは、次の3段階で整理できます。

• モジュール交換（アドレス維持・最も軽い）：ERC-7579・ERC-6900準拠のモジュール型実装では、署名方式や権限管理などの機能をモジュール単位で追加・交換でき、アカウント本体のimplementationは変わりません。
• 同一系統内の実装アップグレード（アドレス維持・条件付き）：proxy構成のアカウントでは、implementationコントラクトの差し替えによりアドレスを維持したまま機能を更新できます。ただし、誰の署名でアップグレードを実行できるかというupgrade authorityの設計と、新旧implementation間のstorage layout互換性の検証が前提です。仕様もこの互換性確保の手法としてERC-7201（diamond storage）に言及しています。
• 別系統の実装への乗り換え（アドレス変更・最も重い）：Safe系からKernel系のように、proxy構造やstorage layoutが異なるaccount familyへ移る場合は、原則として新しいアドレスのデプロイと資産移行が必要です。実務上は「新規ユーザーだけ新実装、既存ユーザーは旧実装のまま」という並行運用になりがちです。

この層を最初に決めるべき理由は、「変更できないから」ではなく、どの変更もユーザーの資産を保持するコントラクトへの操作になるからです。アドレスを維持できるアップグレードであっても、upgrade authorityとstorage互換性の管理という最もセキュリティ感度の高い運用責任が発生し、別系統への乗り換えに至っては資産移行そのものが必要になります。だからこそ、SDKやBundlerより先に、要件からこの層を決めます。

2026年8月時点の主要な選択肢と性格は次のとおりです。いずれも監査済みのオープンソース実装をそのまま採用するのが基本で、独自フォークは監査責任を自社で負うことになるため、明確な理由がある場合に限られます。

• Safe：マルチシグ運用の実績が最も厚い系統で、機関・大口資産管理の標準。Safe Foundationの2026年Q1報告では累計6,111万アカウント、預かり資産352.5億ドルを公表しています（Safe Foundation Q1 2026報告）。詳細はSafe Modularの採用判断
• Kernel（ZeroDev）：ERC-7579準拠のモジュール型で、Validator・Executor等の差し替えによるカスタマイズ自由度が特徴。詳細はKernel（ZeroDev）の採用判断
• Nexus（Biconomy）：ERC-7579準拠。ガス肩代わり前提のサービスやMEEによるチェーン横断実行と一体で使う設計。詳細はBiconomy Nexusの採用判断
• Modular Account V2（Alchemy）：ERC-6900準拠のモジュール型で、Alchemyのインフラ・SDKとの一体運用が前提。同社の旧世代軽量実装LightAccountの位置付けはLightAccount（Alchemy）の採用判断を参照
• Simple7702Account：EntryPoint v0.8に同梱される、EIP-7702委任先として設計された監査済みの最小実装（eth-infinitism v0.8.0リリースノート）。既存EOAユーザーへの機能提供が主目的の場合の起点

モジュール型の共通規格（ERC-7579・ERC-6900）に準拠した実装を選ぶと、前述の3段階のうち最も軽い「モジュール交換」で対応できる範囲が広がり、将来の要件変化に実装ごと乗り換えずに対応できる余地が残ります。機能面の詳細な横並び比較はSmart Walletスタック比較2026で扱っています。

EIP-7702はスタック選定をどう変えたか

EIP-7702（仕様）は2025年5月7日に有効化されたEthereumのPectraアップグレードで導入され（Ethereum Foundation公式ブログ）、既存EOAがアドレスを変えないままコントラクトのコードを委任先として紐付けられるようになりました。スタック選定への影響は2つあります。

第一に、対象ユーザーによってアカウント層の入口が2系統になりました。ウォレットを持たない新規ユーザーにはERC-4337型のスマートアカウントを発行し、MetaMask等の既存EOAユーザーにはEIP-7702で同等の機能を委任する併用構成が、有力な選択肢として加わっています。ただしこの構成が成立するかは前提条件に依存します。対象チェーンで7702が有効化されているか、対象ユーザーのウォレットが委任（delegation）の設定・解除に対応しているか、選んだアカウント実装が7702の委任先として設計・監査されているか、を個別に確認する必要があります。どちらの系統を主とするかで、選ぶアカウント実装と実装順序が変わります。この判断軸はERC-4337 vs EIP-7702の判断軸とEIP-7702の事業者向け解説で詳しく扱っています。

第二に、インフラ層の多くは7702でも共通です。EntryPoint v0.8はEIP-7702をネイティブサポートし、委任したEOAが既存のBundler・Paymasterエコシステムをそのまま使う方向で整備されています（eth-infinitism v0.8.0リリースノート）。Pimlico・Alchemy・Biconomyの各社も7702向けの実装ガイドやSDK機能を提供しています（Pimlico EIP-7702ガイド、Alchemy Walletsドキュメント、Biconomy Docs）。ただし対応の内容は各社・各チェーンで揃っているわけではないため、選定時は「7702対応の有無」だけでなく、対応チェーン、対応するアカウント実装とdelegation方式、SDKでどこまで抽象化されているかという対応範囲を確認してください。

要件別の構成パターン — 3つの起点と乗り換えの現実

ここまでの選定基準を、起点となる要件別に組み合わせると次の3パターンに整理できます。

乗り換えコストの実態も層ごとに異なります。Bundlerの変更は標準メソッドの範囲ならエンドポイントURLとAPIキーの差し替えが中心で、Paymasterのスポンサーポリシーと課金統合の再設定が主な作業です。SDKの変更（ベンダーSDK→permissionless.js等）はアプリケーション層の書き換えを伴いますが、アカウント実装が共通ならユーザーへの影響なく実施できます。アカウント実装の変更は内容によって段階が分かれます。モジュール交換や同一系統内のproxyアップグレードであればアドレスを維持したまま実施できますが、upgrade authorityとstorage互換性の検証が前提になり、別系統の実装への乗り換えは既存ユーザーのアドレスを維持できないため、新規ユーザーからの切り替えと旧実装の並行運用が現実解になります。PoC段階でベンダー一体型を使って最短で検証し、本番化の際に「アカウント実装を本当にそのベンダーに固定してよいか」を判断し直す、という2段階の進め方は、この構造を踏まえた運用です。

なお、Bundler・Paymaster・アカウントのどの層を選んでも、鍵管理と署名方式（passkey、Session Key、ソーシャルリカバリー等）の設計は別途必要です。Passkey（WebAuthn）× ERC-4337、Session Keyの設計、AAセキュリティリスクを併せて参照してください。

よくある質問

ethers.jsを使っているプロジェクトでもAA開発はできますか？

可能ですが、2026年8月時点の主要なAA向けSDK（permissionless.js、Alchemy Smart Wallets SDK、Biconomy AbstractJS）はいずれもviemを前提または基盤としており、ethers.js向けの一次サポートは主流ではありません。既存のethers.js資産は残したまま、AA関連のコードだけviem系で書く共存構成が現実的です。新規プロジェクトであればviemから始めるのが素直です（permissionless.jsドキュメント、2026年8月11日閲覧）。

BundlerやPaymasterは自社運用すべきですか？

大半のケースでは、まずSaaSの利用が合理的です。Alto（Pimlico）やRundler（Alchemy）などのオープンソースBundler実装は公開されており技術的には自社運用できますが、可用性の確保、ガス見積もりの精度、チェーン再編成への対応といった運用負荷を自社で負うことになります。規制・コンプライアンス・鍵管理の要件で外部SaaSを使えない場合や、UserOperationの規模が大きく従量課金が見合わなくなった場合に、標準準拠の範囲で組んだ構成からの移行先として評価するのが実務的な順序です。

無料枠だけでPoC（概念実証）はできますか？

テストネットでの検証はできます。2026年8月11日時点で、Pimlicoの無料枠は月100万クレジットでテストネット限定、Alchemyの無料枠は月3,000万コンピュートユニットでメインネットも対象です（Pimlico Pricing、Alchemy Pricing）。ただしメインネットでガス肩代わりを伴うPoCを行う場合、肩代わりするガス代そのものはどのプランでも自社負担です。無料枠の条件は変更されることがあるため、着手時に各社の料金ページで最新条件を確認してください。

関連記事

本記事はAA記事群のうち「実装スタックの選定」を扱う詳細編です。前後の判断は以下で扱っています。

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

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

スマートアカウント実装を深掘りする：

• Smart Walletスタック比較2026 — 機能面の横並び比較
• Safe Modularの採用判断 ／ Kernel（ZeroDev）の採用判断 ／ LightAccount（Alchemy）の採用判断 ／ Biconomy Nexusの採用判断

設計・運用の論点：

• ガスレストランザクションの経済性 — Paymaster費用の試算と回収設計
• バッチトランザクションの実装 ／ AAセキュリティリスク ／ AAと日本規制

XTELAが支援できる範囲

AAの実装スタックは、対象ユーザー・チェーン選定・鍵管理・ガスレスの経済性と絡み合うため、「どの層をどこまでベンダーに委ね、どこを差し替え可能に保つか」の整理から始めるのが近道です。XTELAは、スタック選定の要件定義、スマートアカウント実装とBundler・Paymaster SaaSの比較評価、PoC実装、本番化に向けた移行設計まで、Web3サービスの技術面を支援しています。カストディ該当性など制度面の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術資料の整理を支援します。

AA開発スタックの選定について相談する

主要参考資料

• ERC-4337: Account Abstraction Using Alt Mempool
• EIP-7702: Set Code for EOAs
• viem 2.18.0リリースノート（Account Abstraction拡張の追加）
• viem: Account Abstractionドキュメント
• Pimlico: permissionless.jsドキュメント
• Pimlico: Pricing（2026年8月11日閲覧）
• Alchemy: aa-sdk（Smart Wallets SDK）リポジトリ
• Alchemy: Modular Account V2ドキュメント
• Alchemy: Pricing（2026年8月11日閲覧）
• Biconomy: Sponsorshipドキュメント（2026年8月11日閲覧）
• Biconomy: Supported Chains（2026年8月11日閲覧）
• Stackup公式サイト（2026年8月11日閲覧）
• eth-infinitism: EntryPoint v0.8.0リリースノート
• Ethereum Foundation Blog: Pectra Mainnet Announcement（2025年4月23日）
• BundleBear: ERC-4337統計（2026年8月11日閲覧）
• Safe Foundation: Q1 2026 Quarterly Report

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術選定上の論点整理であり、投資助言・法的助言ではありません。各社の製品構成・料金・対応チェーン、ライブラリのバージョン、規格の対応状況は今後変わり得ます。採用判断の際は必ず各社の最新の公式ドキュメントを確認してください。