Biconomy Nexusの採用判断｜ガスレス特化Smart AccountとEIP-7702後の選定軸
約15分で読めます
約15分
目次（タップで折りたたみ）
Biconomy（biconomy.io）の現行スマートアカウント基盤「Nexus」は、ガス代を事業者が肩代わりする（ガスレス）Web3サービスを作る場合の有力候補です。採用判断の中心は、製品機能の細かな優劣よりも「事業者がガス代を負担してでも、ユーザーからウォレットとガス代の複雑さを隠す価値がある収益モデルか」という一点にあります。この条件を満たすサービス、たとえば小口・高頻度のオンチェーン操作をWeb2並みのUXで提供したいゲーム、NFTを使った会員証・キャンペーン、既存サービスのオンチェーン拡張などではBiconomyのスタックが強みを発揮します。逆に、ユーザー自身がガス代を払う前提のサービスでは、その強みの大半は生きません。
なお、日本語で「Biconomy」を検索すると、同名の暗号資産取引所（Biconomy.com）の情報が混在しますが、本記事で扱うのはアカウント抽象化インフラを提供するBiconomy（biconomy.io）で、別の事業者です。また同社のスマートアカウントは、旧世代の「Modular Smart Account（v2）」からERC-7579準拠の「Nexus」へ世代交代しています。本記事は2026年8月11日時点の一次情報に基づき、現行製品ラインの整理、採用が成立する条件、EIP-7702以降の選定軸、費用構造、運用リスクまでを事業者目線で解説します。
Biconomyの現行製品ライン（2026年8月時点）
Biconomyは2019年創業のアカウント抽象化（Account Abstraction：ウォレットの署名・実行ロジックをスマートコントラクトへ移し、UXを柔軟にする技術群。以下AA）インフラ企業です。2026年8月時点の製品構成は次のように整理できます。
| 構成要素 | 役割 | 状況（2026年8月時点） |
|---|---|---|
| Nexus | ERC-7579準拠のモジュール型スマートアカウント本体。署名検証（Validator）や実行（Executor）などの機能をモジュールとして差し替えできる | 現行世代。複数の第三者監査を経て主要EVMチェーンへデプロイ済み（Biconomy Docs） |
| AbstractJS | TypeScript製の現行SDK。viemに近いAPIでNexusアカウントとガススポンサーを操作する | 現行SDK。旧SDK（smartAccountsV2系）は旧世代として別ドキュメントに残置 |
| MEE / Supertransaction | 複数チェーン・複数操作を1つの署名でまとめて実行するオーケストレーション層。現行SDK（AbstractJS）の標準的な実行経路 | mainnet運用中。公式の対応チェーン一覧ではEthereum、Base、Polygonなど22のmainnetに対応（2026年8月11日確認時点）。新規対応チェーンは旧世代のBundler・Paymaster基盤ではなくMEEスタックでのみ追加される（Biconomy Docs） |
| ガススポンサー（Paymaster） | ユーザーの代わりに事業者がガス代を支払う仕組み。Biconomyがホストする方式と、自社バックエンドで承認判断を行う方式がある | ダッシュボードからプロジェクト単位で利用（Biconomy Docs） |
注意したいのは、2024年以前の解説記事で紹介されている「Biconomy Modular Smart Account（v2）」が旧世代である点です。公式ドキュメントは現在、Nexus＋AbstractJSを中心とした構成を新系列として案内しており、v2のドキュメントは旧版として分離されています。これから新規に開発するなら、比較・検証の対象はNexusです。
採用が成立する条件：ガス代を「誰が払うか」で決まる
Biconomyのスタックを採用すべきかは、次の3つの問いでほぼ決まります。
- UX要件：ユーザーにシードフレーズの管理やガス代用トークンの購入を見せたくないか。見せてもよいサービスなら、ガスレス特化基盤を選ぶ理由は弱くなります。
- 操作特性：小口・高頻度のオンチェーン操作が発生するか。1回あたりのガス代が小さいLayer 2（Ethereumの処理を肩代わりして高速・低コスト化する二層目のチェーン。以下L2）上の頻繁な操作ほど、事業者負担モデルが成立しやすくなります。
- 回収源：肩代わりしたガス代を吸収する収益があるか。ゲーム内課金、NFTの販売・二次流通手数料、月額課金、マーケティング予算など、負担の出所を事前に決められないなら採用は時期尚早です。
この3条件を満たしやすいのは、ゲームのように頻繁な小口オンチェーン操作を課金収益で回収できるサービス、NFTの配布・会員証をマーケティング予算で賄うキャンペーン、既存Web2サービスのポイント・特典をユーザーに意識させずオンチェーン化する拡張などです。反対に、ユーザーがガス代を払うことに違和感が薄い取引金額の大きなDeFi、マルチシグでの機関向け資産管理（この用途はSafe系が定番です）、低頻度・1回きりの大型取引では、ガスレス特化の強みは生きません。他のスマートアカウント実装との横並び比較はSmart Walletスタック比較を、ガスレスが不要な場合の軽量な選択肢はLightAccount（Alchemy）の採用判断を参照してください。
技術基盤としての信頼性：確認できる一次情報
ベンダー選定で「信頼できるか」を判断する材料は、公開されている一次情報で確認できます。
標準準拠とロックイン回避：NexusはERC-7579（モジュール型スマートアカウントの最小共通インタフェースを定める規格）に準拠しています。ERC-7579はValidator（署名検証）、Executor（実行）、Fallback、Hookの4種のモジュールを共通化するため、準拠実装間でモジュールを再利用でき、将来ほかの準拠アカウント（Safeのアダプタ経由、ZeroDevのKernelなど）へ乗り換える余地が残ります。ただしERC-7579自体は2026年8月時点でまだDraft（草案）段階の規格であり、確定仕様ではない点は把握しておくべきです。
監査：Nexus本体は複数の第三者監査を受けており、監査レポートはGitHubリポジトリで公開されています。CodeHawks-Cyfrin（2024年9月）、Spearbit（2024年10〜11月）、Zenith（2025年3月）、Pashov（2025年3月）の各最終報告が確認できます。コードはMITライセンスで公開されています。ただし、複数の監査を経ても脆弱性がゼロになるわけではありません。実際にBiconomyは、Nexusの初期化処理に関するSecurity Advisory（セキュリティ勧告）を1件公開しており、影響条件と修正版を明示しています（詳細は後述の運用リスクで扱います）。既知の脆弱性を公表し、影響範囲と修正版を特定できる形で開示する運用は、ベンダー選定時に確認すべき情報開示の姿勢そのものです。
実運用の実績：Biconomyの公式ドキュメントは、累計200万以上のアカウントデプロイと5億ドル超の処理実績を公表しています（自社公表値）。外部の採用例としては、暗号資産取引所Geminiのセルフカストディウォレットがpasskey認証とNexusアカウントを基盤に構築されたことが2025年8月に発表されています（Biconomy公式ブログ、2025年8月15日）。それ以前にも、Trust WalletがBiconomyのPaymaster（ガス代肩代わり）・Bundler（ユーザー操作をまとめてチェーンへ送信する中継役）の基盤を使ったスマートコントラクトウォレット「SWIFT」を、2024年2月に公開ベータとして発表しています（Decrypt、2024年2月）。
EIP-7702以降の選定軸：ウォレットの種類で実装方式が決まる
2025年5月7日に有効化されたEthereumのPectraアップグレードでEIP-7702が使えるようになり、既存のEOA（Externally Owned Account：秘密鍵で直接操作する従来型アカウント。MetaMask等の標準はこれ）にスマートコントラクトの機能を委任できるようになりました。「EOAをそのままスマート化できるなら、ERC-4337型のスマートアカウントは不要になるのではないか」という疑問が出る局面ですが、Biconomyの現行ドキュメントが示す実装方式の分岐は、ユーザーが新規か既存かではなくユーザーのウォレットに何ができるかで決まります（Biconomy Docs: External Wallets）。
- 組込ウォレット（Privy、Dynamic、Turnkey等でサービス内に発行するウォレット）：EIP-7702の委任に必要なauthorization署名（EOAの実行権限をコントラクト実装へ委任するための専用署名）に対応しているため、EOAのアドレスそのものへNexusのロジックを直接導入できます。アドレスを維持したままガスレスやバッチ実行を適用でき、後述のCompanion Accountは不要です（Biconomy Docs）。
- 外部ウォレット（MetaMask、Rabby、Trust Wallet等）：アプリ側からauthorization署名の取得やアカウントロジックの導入ができないため、EIP-7702構成は使えません。この場合BiconomyはFusion Modeを提供しています。ユーザーの1回のトリガー署名で資金を一時的なCompanion Account（ユーザーが所有権を持つ非カストディの中継用スマートアカウント）へ移し、そこで一連の操作を実行して結果を元のウォレットへ返す方式で、Companion Accountはこの外部ウォレット構成のためだけに使われます。
- ウォレットを持たない新規ユーザー：passkey等で新規にアカウントを発行するなら、EOAを経由せず最初からERC-4337型のNexusアカウントを作成する構成が自然です。
Fusion Modeには採用判断に影響する制約があります。1回のアクションで入力に使えるトークンは1種類で、ガス代はそのトークンから同一チェーン上で支払われます。また、トークンがERC-2612 permit（トランザクションなしの署名だけで支払い承認を与える規格）に対応していればトリガー署名はガスレスで完結しますが、非対応のトークンではapprove（承認）トランザクションのガス代をユーザーが一度負担します。既存の外部ウォレットユーザーへ完全なガスレス体験を提供できるかは扱うトークンのpermit対応に依存するため、設計段階で確認が必要です（Biconomy Docs: External Wallets）。
つまりERC-4337とEIP-7702は「どちらかが勝つ標準戦争」ではなく、ウォレットの能力に応じて使い分ける補完関係にあり、どの構成でも基盤は同じNexusです。ERC-4337の中核コントラクトであるEntryPointもv0.8でEIP-7702をネイティブサポートしており（eth-infinitism v0.8.0リリースノート）、7702で委任したEOAが既存のBundler・Paymasterのエコシステムをそのまま使える方向で整備が進んでいます。両者の使い分けの詳細はERC-4337 vs EIP-7702の判断軸で扱っています。
費用構造：スポンサーガスの総額をどう見積もるか
ガスレス設計の費用は、次の3層に分けて見積もります。
- スポンサーするガス代の実費：ユーザーの操作ごとに発生するガス代そのもので、費用の本体です。チェーンと操作内容（データ量・コントラクトの複雑さ）で1操作あたりの単価は桁単位で変わります。
- インフラ利用料：Biconomyのホスト型スポンサーはダッシュボードでプロジェクト単位に設定し、後払い（クレジットカードまたはエンタープライズ契約）で利用します（Biconomy Docs）。公開ドキュメントには料率・手数料の記載がないため（2026年8月時点）、想定トラフィックを前提にダッシュボードまたは問い合わせで個別に確認する必要があります。
- 自社側の実装・運用工数：SDK統合に加えて、後述するスポンサー承認ロジックと監視・アラートの構築が必要です。ここを省くと運用リスクが費用に跳ね返ります。
スポンサー総額の概算は「月間アクティブユーザー数 × 1人あたり月間オンチェーン操作回数 × 1操作あたりガス単価」で置けます。重要なのは、この単価を机上で仮定しないことです。対象チェーン・対象操作で実測した値を使い、売上に対するガス代負担の比率（ガス代率）に上限を決めて管理します。全額負担が重い場合は、ユーザーがステーブルコイン等でガス代を払うERC-20モード（Paymasterがトークンを受け取り、ガスを立て替える方式）へ部分的に切り替える中間形態もあります。誰がガスを負担するかの設計パターン全体はガスレストランザクションの経済性で詳しく扱っています。
運用リスク：Free-rider問題と実装の落とし穴
ガスレス設計で最大の運用リスクはFree-rider（ただ乗り）問題です。事業者がガス代を負担する以上、botや大量作成アカウント（Sybil攻撃：1人が多数のアカウントを作って1人分以上の便益を得る攻撃）が無料のガスを目的に殺到すると、スポンサー費用が想定外に膨らみます。防御の本質は「どのユーザーの、どの操作を、どこまでスポンサーするか」という承認ロジックを事業者自身が設計することです。
- スポンサー対象を自社コントラクトの特定操作に限定します。
- ユーザーあたりの回数・金額に上限を設けます。
- 高価値なキャンペーンでは、電話番号認証など本人性の確認を通過したユーザーに限定します。
- Biconomyの自社ホスト型スポンサーを使い、自社バックエンドで任意のロジックによる承認・拒否を行います（Biconomy Docs）。
- スポンサー費用のしきい値超過アラートを必ず設定し、異常時に自動停止できるようにします。
Free-rider以外にも、実装・運用段階で典型的な落とし穴が4つあります。
ガス原資の枯渇：スポンサー用の残高・与信が尽きると、ユーザー側に落ち度がないまま全員の取引が失敗します。残高監視と自動アラート、枯渇時に「ガスレス一時停止中」を示すフォールバックUIを用意してから本番公開すべきです。
Validatorモジュールの自前実装：署名検証（Validator）はアカウント乗っ取りに直結する部分です。passkeyやSession Key（用途・期限を限定した一時的な操作権限）を自前実装すると署名フォーマットやnonce管理で脆弱性が入りやすいため、監査済みの既製モジュールを第一選択にします。この領域のリスク全体像はAAセキュリティリスク、Session Keyの設計はSession Keyの設計を参照してください。
公表済み脆弱性への追随漏れ：監査済みの基盤でも、リリース後に脆弱性が見つかることはあります。Nexusでは、初期化処理に関するSecurity Advisory「Stale transient initialization flag（GHSA-q47q-h6x2-f5qg）」が公式リポジトリで公開されています（GitHub bcnmy/nexus SECURITY.md、2026年8月11日確認）。影響を受けるのは、Nexus 1.2.0以降のERC-4337型（非EIP-7702）アカウントのうち、まだデプロイされていないcounterfactualアドレス（デプロイ前に事前計算されるアカウントのアドレス）に残高を保有しているものに限られます。デプロイ済みのアカウント、EIP-7702構成、Fusion Mode、旧Smart Account V2は対象外です。デプロイ済みコントラクトはNexus 1.3.3（MEEコントラクトスイート2.2.3として提供）で修正済みで、リポジトリをフォークして自社デプロイしている場合は、mainブランチのcommit 272c408 以降からビルドすること、修正前のデプロイで未デプロイのアドレスに残高があるなら該当アカウントをデプロイしておくこと（資金の移動は不要）が公式に案内されています。採用判断の観点で重要なのは、この個別の脆弱性そのものよりも、Advisoryを追跡して自社構成が影響範囲に入っていないかを確認し、修正版へ追随する体制を運用設計に含めることです。
ガスレスに慣れたユーザーの離脱事故：ガス代を意識せずに使ってきたユーザーは、自社サービスの外へ資産を移した瞬間に「ガス代が払えず動けない」状態に陥りがちです。出金時のガイダンスや、サービス内で完結する設計など、境界部分のUXを事前に決めておく必要があります。
採用判断のまとめ
- Biconomy採用の成否は、機能比較よりも「ガス代を事業者が負担し、それを回収できる収益モデルか」で決まります。
- 新規に使うのは現行世代のNexus＋AbstractJSです。旧Modular Smart Account（v2）を新規開発で選ぶ理由は基本的にありません。
- 信頼性は、公開された監査レポート、Security Advisory、採用事例、公表値という一次情報で確認できます。監査済みでも既知の脆弱性（GHSA-q47q-h6x2-f5qg）は公表されており、修正版への追随体制まで含めて評価します。準拠先のERC-7579がまだDraft段階である点は理解しておきます。
- EIP-7702以降の実装方式は、ユーザーの新規・既存ではなくウォレットの種類で決まります。組込ウォレットはEIP-7702でEOAへNexusを直接導入、MetaMask等の外部ウォレットはFusion Mode＋一時的なCompanion Account、新規発行はERC-4337型Nexusの直接作成が基本で、いずれも基盤は同じNexusです。
- 最大の運用リスクはFree-riderとガス原資の枯渇です。スポンサー承認ロジックと監視・アラートを実装してから本番に出します。
XTELAが支援できる範囲
スマートアカウントとガスレス設計の採用判断は、収益モデル・対象ユーザー・チェーン選定と切り離せません。XTELAは、ガスレス設計の要件定義、Nexus・Safe・Kernel等のスタック比較選定、PoC実装、スポンサー承認ロジックと監視・アラートの運用設計まで、Web3サービスの技術面を支援しています。
主要参考資料
- Biconomy公式サイト
- Biconomy Docs: Nexus
- GitHub bcnmy/nexus（監査レポート一覧・MITライセンス）
- GitHub bcnmy/nexus SECURITY.md（Security Advisory GHSA-q47q-h6x2-f5qg、2026年8月11日確認）
- ERC-7579: Minimal Modular Smart Accounts（Draft）
- Ethereum Foundation Blog: Pectra Mainnet Announcement（2025年4月23日）
- eth-infinitism: EntryPoint v0.8.0リリースノート
- Biconomy Docs: Sponsor Gas for Users
- Biconomy Docs: MEE + EIP-7702（Embedded Wallets）
- Biconomy Docs: External Wallets + AbstractJS（Fusion Mode）
- Biconomy Docs: Supported Chains（MEE対応チェーン一覧）
- Biconomy Blog: Introducing the Biconomy MEE Devnet（2025年2月、沿革）
- Biconomy Blog: Gemini Builds on the Biconomy Nexus Stack（2025年8月15日）
- Decrypt: Trust Wallet launches SWIFT（2024年2月）
本記事の前提
本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言や特定トークンの推奨ではありません。製品構成、対応チェーン数、料金体系、規格の状態（ERC-7579のステータス等）、脆弱性情報（Security Advisory）は今後変わり得るため、採用検討の際は最新の公式ドキュメント、監査情報、公式リポジトリのSecurity Advisoryを確認してください。なお本記事の対応チェーン数はSupported chains一覧、脆弱性の影響範囲・修正版はSECURITY.mdと、それぞれ別の一次情報を2026年8月11日に個別確認した値です。
