アカウントアブストラクション（AA）は元が取れるか｜ガス代補助の費用と効果の測り方

あるWeb3サービスが、新しく来たユーザーのガス代を肩代わりする「ガスレス化」を入れました。翌月、初回の購入が増えています。グロース担当は「ガスレス化で売上が増えました」と報告しました。

ところが同じ月には、集客のキャンペーンがあり、価格も変えていました。市況も良かった。増えた分のうち、どこまでがガスレス化のおかげなのか。この報告からは分かりません。経営者が知りたい「この投資は元を取れるのか」にも、答えられません。

ガスレス化は、アカウントアブストラクション（AA）と呼ばれる技術でできることの1つです。ほかにも、パスキーでのログイン、複数の操作をまとめて実行すること、鍵をなくしたときの回復などができます。どれも使い勝手を良くする機能です。ただし、機能を入れても数字が良くなるとは限りません。どの数字がどれだけ変わったかを、自社のデータで測る必要があります。

測るのは、利用開始率だけではありません。継続率、サポート費、ガス代の負担、不正による損失まで合わせて見ます。離脱の原因が確かめられた工程に、機能を1つずつ入れます。そして、得られた効果と、開発・運用のコストを比べます。根拠のない転換率（CVR）の改善値は使いません。自社のデータで、投資の判断をやり直せる形にします。

この記事でわかること

• ガス代の補助にかかる費用の見積もり方と、元が取れるかの比べ方
• AAの効果を「増えた分」として正しく測る実験の組み方
• 採用・限定採用・再設計・不採用を決める基準と、試験導入の進め方

AAの仕組みそのものはERC-4337の解説が基礎になります。

ガス代の補助には、年間いくらかかるか

まず、規模の感覚をつかんでおきます。架空の前提で、ガス代の補助だけを試算すると次のようになります。数値はすべて例です。実際のガス代・手数料・件数は、自社のデータと最新の契約条件に置き換えてください。

手数料の8%は、実際の料金表にある数字です。Alchemyの公式料金表は、2026年9月24日時点でPay As You GoプランのGas Managerに「8% admin fee」（代わりに払ったガス代の8%）を示しています。Enterpriseは個別の条件です（Alchemy Pricing Plans）。

この259万円に、失敗・リバート（実行の取り消し）・悪用の分と、固定費を足したものが比べる出発点です。補助によって初回操作の完了率が何ポイント上がったか。その増えたユーザーの粗利が、年間いくらになるか。同じ期間で並べれば、ガス代の補助が元を取れるかを判断できます。

ここから先は、この比較に要る数字を1つずつ正しく求めていきます。「どこで離脱しているか」「機能で何が変わるか」「増えた分をどう測るか」「費用とリスクをどう数えるか」の順です。

今の利用の流れを分け、AAで変えられる離脱だけを探す

AAは、秘密鍵だけで操作する従来のアカウントの決まった認証・実行の条件を、スマートアカウントのプログラムに移す技術の集まりです。Ethereum公式は、代表的な効果として次の4つを挙げています（Ethereum.org「Account abstraction」）。

• 鍵をなくしたときの回復
• 柔軟なセキュリティのルール
• 第三者によるガス代の支払い
• 複数のトランザクションの一括実行

ただ、これらは技術の機能です。事業の成果そのものではありません。

そこでまず、ユーザーの流れを段階に分けます。

訪問 → 登録開始 → 認証完了 → ウォレット準備完了 → 初回操作の意図 → 署名 → オンチェーンでの成功 → 再利用

各段階で、離脱した数、かかった時間、エラーコード、チェーン、端末、ウォレットの方式、ガス代を誰が払ったかを記録します。「初回のトランザクションが少ない」だけでは、原因が分かりません。認証か、資金の用意か、署名か、ガスか、コントラクトの実行失敗か。分からなければ、どのAA機能を入れるかも選べません。

段階ごとに、AAで変えられる範囲と、よくある離脱の原因は次のとおりです。

各段階で記録するイベント名は、後半の「計測を組む人向けの詳細」にまとめました。

機能と事業の数字のあいだに、中間の指標を挟む

冒頭の報告のように、機能と最終の数字を直接つなぐと間違えます。キャンペーン、価格、流入の質、市況の影響まで、AAの効果に数えてしまうからです。機能が直接変える中間の指標と、その先の事業の数字を分けて見ます。

効果と同時に、機能ごとのコストとリスクも測ります。

• パスキー・埋め込み認証：認証サービスの費用、アカウントの乗っ取り、端末・ブラウザーの非対応率
• 一括トランザクション：一括処理全体の失敗、calldata・実行のガス、やり直しの率
• ガス代の代理支払い：アクティブユーザー1人当たりの補助額、悪用された額、Paymasterの手数料
• アカウント回復：不正な回復、回復を承認する人の運用、手作業の審査の費用
• セッションキー・権限の制限：権限からのはみ出し、失効の遅れ、監視・インシデント対応の費用

たとえばガス代の代理支払いは、「全部のトランザクションを無料にする」ものではありません。初回の特定の操作だけ、アドレスごとの回数・金額の上限、許可リスト、期間などを制御の方針として決められます。

Alchemyの公式ドキュメントにも、支出の上限や許可・拒否のリストが示されています。上限は、UserOperationごと、送信者ごと、方針全体で設定できます（Gas sponsorship、支出上限の公式ガイド）。この制御の単位を計測の区分とそろえると、補助額に対してアクティベーションがどれだけ増えたかを計算できます。上限の段数、予算の分け方、使い切ったときの止め方はPaymasterの不正利用・ガス枯渇対策で詳しく扱っています。

画面の操作とチェーン上の結果を、同じIDで結ぶ

効果を測るには、画面での操作とチェーン上の結果を同じIDでつなぐ必要があります。「送信ボタンを押した」とチェーン上の成功だけを数えると、間違いが起きます。同じ操作のやり直しを、別々の人として数えてしまう。Bundlerが受け付けた後の失敗を見落とす。そうした間違いです。

つなぐIDの組み方は、後半にまとめました。実験のどちらの組に入ったか、ガス代を補助した理由、実際のガス代と補助のコスト、問い合わせとの対応も、同じ試行にひも付けます。秘密鍵、署名の材料、パスキーの認証情報に含まれる秘密は、分析基盤に送りません。

イベントの一覧、試行IDの設計、誰がイベントを出すかの分担、失敗の分類はスマートウォレットの利用開始率を測る記事にまとめています。ここから先は、その数字を使って実験・費用・採否を判断する話です。

効果は、A/Bテストか段階導入で「増えた分」として測る

入れる前と後を比べるだけでは、冒頭の報告と同じ間違いになります。市況、集客のキャンペーン、価格の変更、チェーンの混雑が混ざるからです。

できれば、ユーザーを無作為に2つの組に分けます。今のままの組（対照群）と、AAを使う組です。同じ期間・同じ入口・同じ主な操作で比べます。ウォレットの方式をユーザー自身が選ぶ場合は、選んだ人の偏り（selection bias）が入ります。その結果を、AAが原因の効果だと言い切ってはいけません。

実験の前に、次の5つを決めておきます。

1. 主な指標を1つに決める：たとえば「組に割り当ててから7日以内に、初回の事業トランザクションを完了した率」。途中のクリック率だけを成功の条件にしない。
2. 守るべき基準を先に決める：不正による損失、実行の失敗率、p95の完了時間（遅いほうから5%の境目）、ユーザー当たりのサポート件数、利用を始めたユーザー当たりの補助コストを、同時に見張る。
3. 数える単位を決める：トランザクションの数ではなく、割り当てたユーザーを基本にする。よく使う一部のユーザーで数字がふくらむのを防ぐ。
4. 期間と、止める条件を前もって登録する：途中の良い数字だけで終わらせない。セキュリティの事故、予算の超過、組の割り当て比率の想定外の偏り（sample ratio mismatch）が大きいときは、すぐ止める。
5. ユーザーの層を混ぜない：新規／既存、デスクトップ／モバイル、地域、チェーン、入口、初回の操作を分けて見る。分けた後に人数が足りなければ、そう明記する。

無作為に分けられないときは、ほかのやり方もあります。チェーン・流入元・利用歴が近い層ごとに、順番に広げていく方法です。導入した層としていない層で、前後の変化の差を比べる方法（差の差法、difference-in-differences）も使えます。ただし、両方の層で別々の施策が同時に走っていたら、結論は弱めて扱います。

費用は、開発費だけでなく1件ごとの費用と損失まで数える

AAの年間の総保有コスト（TCO）は、考え方としては次のように整理できます。

年間TCO = 初期開発・移行費の年換算 + ウォレット／Bundler／Paymaster等の固定費 + ガス補助 + プロバイダー従量費 + 監視・サポート・監査費 + インシデント期待損失

プロバイダーの料金と利用の上限は変わります。記事の中の単価を、そのまま事業計画に固定しないでください。冒頭の試算の8%も、その時点の料金表の値です。採用するときは、候補のプロバイダーについて次のことを確かめ直します。

• 最新の契約、対応するチェーン、レート制限
• SLA（サービス水準の約束）、最低利用額
• 乗り換え・撤退にかかる費用

便益と費用の各項目は、次のように計算します。二重に数えないための注意もあわせて示します。

投資の判断は、次の式で比べます。

リスク調整後増分価値 = 増分粗利 + サポートコスト削減 + 回避損失 − 年間TCO

あわせて、初期投資を回収するまでの期間、アクティブユーザー1人当たりのコスト、ガス代補助の予算の上限、プロバイダーから撤退するときの移行費を、別々に確かめます。ガス代補助の損益の考え方はガスレストランザクションの経済性も参考になります。

不正と止まるリスクも、効果と同じ細かさで測る

プログラムで決められるアカウントは、セキュリティのルールを柔軟にできます。その一方で、責任を持つべき部品が増えます。検証のコントラクト、追加のモジュール、Paymaster、Bundler、裏側のサーバーの制御方針です。

Paymasterは、妨害攻撃（griefing）の的になりえます。無効な操作を大量に送る、費用の高い呼び出しをする、処理の競合を突く、などで、預けたお金を減らされるのです。ERC-4337 Docsも、試し実行やステークなどの守りとともに、悪意ある入力を前提に預けたお金を守る必要があるとしています（Security and Griefing Protection）。

• 認証のリスク：アカウントの乗っ取り率、認証情報の再設定、端末の追加、怪しい回復、手作業の審査での誤った承認を追う。
• 権限のリスク：セッションキーが触れるコントラクト、メソッド、トークン、金額、期間、失効が反映されるまでの時間を絞り、はみ出しの試験をする。
• 補助金のリスク：ユーザー・操作・方針ごとの金額と回数の上限、許可リスト、頻度の制限、予算の警報、緊急停止を用意する。
• プロバイダーのリスク：Bundler／Paymasterのタイムアウト、チェーン別の成功率、別の経路での二重送信、SLA、撤退されたときの移行を確かめる。
• コントラクトのリスク：アップグレードの権限、モジュールの追加、署名の検証、リエントランシー、試し実行との食い違いを、監査と監視の対象にする。

「不正は減ったが、手作業の審査費が増えた」「アクティベーションは上がったが、ガス代補助の悪用も増えた」。この両面を同時に見せるダッシュボードが必要です。セキュリティの基準を下回った実験のパターンは、コンバージョンが良くても採用しません。

向いているかは業界ではなく、使う頻度・金額・回復の責任で決まる

AAの仕組みは、入れた後も動かし続ける費用がかかります。一度しか使わない機能では、その費用を回収しにくくなります。反対に、少額の操作を何度もくり返すサービスなら、署名の手間やガス代の負担を減らす効果が、使うたびに積み重なります。

見る主なKPIも、性質ごとに違います。

• 消費者向け、少額・高頻度：初回の完了率、くり返し使う率、アクティブユーザー当たりのコスト
• ゲーム・ソーシャル：操作の回数、継続率、署名での離脱
• B2B業務・資金管理：処理時間、エラー、サポート、承認の統制
• 高額資産・長期保有：回復できるか、インシデント、運用の負担
• 一度だけ使う機能：単発のコンバージョン

同じ業界でも、既にウォレットを使っている人が中心か、Web2から初めてチェーン上の操作をする人かで、つまずく場所は変わります。外部のウォレットをつなぐのに慣れた人に埋め込みウォレットを押し付けると、かえって離脱することもあります。選べる形を残したパターンも、実験で比べます。

試験導入は、1つの機能・1つの流れ・1つのチェーンから始める

パスキー、Paymaster、一括処理、アカウント回復を同時に変えると、どの変更が効いたのか分かりません。原因が確かめられた、いちばん大きな離脱点に、1つの仮説を当てます。進め方は次の6段階です。

各段階で、戻る先を用意します。AAのアカウントに資産や権限を持たせた後は、画面を元に戻すだけでは戻したことになりません。運用手順書には、次のことまで入れます。

• 検証コントラクトの失効と、資産の移し替え
• 処理待ちのUserOperationの扱いと、Paymasterの停止
• プロバイダーの切り替え

既存のEOAからの移し方はEOAからスマートアカウントへの移行で扱っています。

採用・限定採用・再設計・不採用を、同じ基準で決める

• 採用：前もって登録した主な指標で、実際に意味のある増分がある。セキュリティ・コストの基準を守っている。年間の、リスクを調整した後の価値がTCOを上回る。
• 限定採用：新規ユーザーの初回トランザクション、特定の操作、上限付きのガス代補助など、一部の層だけで価値がある。全ユーザーには広げない。
• 再設計：効果はあるが、プロバイダーへの縛られ方、実行の失敗、アカウント回復、不正、サポートの負担が基準を超える。機能や責任の分け方を変えて、試験導入をやり直す。
• 不採用：離脱の原因が価格・商品の価値・流動性などでAAと関係ない。今のウォレットで足りる。増える価値がTCOを下回る。あるいは、重大なリスクを許せる範囲に抑えられない。

Ethereum公式が示すAAの利用実績は、技術が動いていることを示すだけです。自社の流れがどれだけ良くなるかは保証しません。同じように、「競合が採用した」「スマートウォレットが広まった」も、自社が投資する理由にはなりません。

採否の資料には、次のものを並べます。

• 今の値と、実験の組み方
• 良くなった幅（効果量、effect size）と、その幅がどこまで確かか（信頼区間、confidence interval）
• コスト、守るべき基準、まだ見えていないリスク

計測を組む人向けの詳細

ここからは、前半の数字を実際に取る分析・開発の担当者向けの内容です。

段階ごとに記録するイベント

画面とチェーンをつなぐID

最低限、匿名化したuser_id、experiment_id、intent_id、userop_hash、tx_hashを段階的に結びます。実験群の割当、ガス代補助の判定理由、実ガス代と補助コスト、問い合わせとの対応も、同じ試行に紐づけます。

関連して読む

• スマートウォレットの利用開始率を測る — イベント辞書・試行ID・失敗分類の詳細
• Paymasterの不正利用・ガス枯渇対策 — ガス代補助の上限・停止・復旧
• アカウントアブストラクション（AA）完全マップ2026 — 技術方式と採用形態の全体像
• パスキーウォレットの仕組み（WebAuthn×ERC-4337） — 認証・端末・復旧の設計
• ソーシャルリカバリー（Social Recovery）とは — 回復経路と不正対策
• Session Key（セッションキー）の設計 — 反復操作の権限範囲と失効
• ブロックチェーンウォレットの導入・開発 — ウォレット全体の基礎と運用

XTELAができること

私たちは、現行ファネルとオンチェーンの結果を同じ試行IDで結ぶ計測設計から、スマートアカウント・Bundler・Paymasterの構成比較、1機能に絞った試験導入の実装までを一緒に進めます。ガス代補助の制御方針、監視と切り戻しの手順、TCOの試算も、貴社の実データで組み立てます。自社の離脱点と費用構造からAAの採否を確かめたい場合は、お問い合わせください。

主要参考資料

• Ethereum.org「Account abstraction」（2026年8月12日確認）
• ERC-4337: Account Abstraction Using Alt Mempool
• EIP-7702: Set EOA account code
• ERC-4337 Documentation（構成要素とUserOperationの流れ）
• ERC-4337 Docs「Security and Griefing Protection」
• Alchemy Docs「Basic Gas Sponsorship」（補助ポリシーの製品例）
• Alchemy「Best practices to limit Gas Manager spend」（2026年9月24日確認）
• Alchemy Pricing Plans（2026年9月24日確認）

資料の確認日と注意

一次資料は2026年8月12日に確認しました。料金など動きの速い項目は、2026年9月24日に確認し直しています（Alchemyの手数料8%もこの日の料金表の値です）。技術設計と投資判断の枠組みの整理で、KPIの改善を保証するものではありません。法務・会計・税務・投資の助言でもありません。料金や仕様とあわせて、導入するときに最新の条件を確かめてください。