ガスレストランザクションの経済性｜Paymasterの費用実勢と「誰がガスを負担するか」の設計

ガスレストランザクションとは、ユーザーがETHなどのネイティブトークン（そのチェーンのガス代支払いに使う基軸通貨）を持たずにブロックチェーン上の取引を実行できる仕組みです。ただし、ガス代そのものが消えるわけではありません。ERC-4337のPaymaster（ガス代の支払いをユーザー本人から差し替えるコントラクト。仕様）などを通じて、事業者が肩代わりするか、ユーザーがUSDC等の別トークンで支払うかのどちらかに、負担が付け替わるだけです。この仕組みはすでに実運用段階にあり、Paymasterが肩代わりしたガス代は追跡対象チェーン合算で累計約1,336万ドルに達しています（BundleBear、2026年8月11日閲覧）。費用の実勢は2026年8月時点で、主要SaaSを使う場合でガス実費に7〜10%の手数料を上乗せした額、ガス実費自体はLayer 2（Ethereumの処理を肩代わりして低コスト化する二層目のチェーン。以下L2）なら1取引あたり数円以下のオーダーです。

つまりガスレスの導入判断は、「技術的に可能か」ではなく「誰の負担でいくら払い、どう回収するか」という事業設計の問題です。本記事は、ガス代が付け替わる仕組み、負担と回収の4類型、2026年8月時点の費用実勢、費用を狂わせる不正利用のリスク、そして導入前に費用を読める状態を作る手順を、一次情報に基づいて整理します。前提となるERC-4337の全体構造（EntryPoint・Bundler・Smart Account）はERC-4337の事業者向け解説で、アカウントアブストラクション（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移す技術群。以下AA）全体の俯瞰はAA完全マップ2026で扱っているため、本記事は経済性に集中します。

ガスレスの仕組み — ガス代は「消える」のではなく「付け替わる」

ERC-4337では、ユーザーの操作はUserOperation（ユーザーの取引意図を表現するデータ形式）として送られ、共通コントラクトEntryPointが検証・実行・ガス精算を行います。Paymasterはこの精算段階に割り込み、本来ユーザーのアカウントから引き落とされるガス代を、自分の預託金から支払うコントラクトです。Paymasterとして機能するには、EntryPointへガス原資となるETHを事前にデポジットしておく必要があり、ガス代はこの預託金から引き落とされます（ERC-4337仕様）。

Paymasterコントラクトの役割は2つの関数に集約されます。検証フェーズで呼ばれるvalidatePaymasterUserOpが「このUserOperationのガス代を払ってよいか」を判定し、実行後に呼ばれるpostOpが徴収や記録などの後処理を行います。この2点の設計が、後述する費用管理と不正利用対策の実装箇所になります。

誰の負担に付け替えるかで分けると、実用化されている支払モデルは2つです。

• スポンサーモデル：事業者が自らの預託金から全額を負担し、ユーザーは完全に無料で取引できます。
• ERC-20支払モデル：ユーザーがUSDC等のトークンで支払い、PaymasterがETH建てのガス代を立て替えます。ユーザーから見れば「ETHを持たなくてよい」だけで、負担自体はユーザーに残ります。

これとは別の軸に、「どのUserOperationに適用するか」を判定する検証方式があります。代表的なVerifying Paymasterは、事業者のサーバーがオフチェーンで承認判断を行い、その署名をvalidatePaymasterUserOpで検証してから支払う実装方式です。これは支払モデルと並ぶ第3の選択肢ではなく、スポンサーモデルにもERC-20支払モデルにも組み合わせられる判定の仕組みで、「最初の10回だけ無料」「特定操作だけ無料」のような条件付きスポンサーはこの組み合わせで実装します。

なお、ガス代の肩代わり自体はERC-4337の専売ではありません。2025年5月のPectraアップグレードで導入されたEIP-7702により、既存のEOA（秘密鍵で直接操作する従来型アカウント）でも、ユーザーが署名した操作を第三者が代理送信してガス代を負担する構成が取れます。ただしEIP-7702仕様自体が、委任の無効化や資産の引き抜きによって代理送信者がガス代を回収できなくなるリスクを明記しており、保証金や評判管理を求めています（EIP-7702 Security Considerations）。実務では、EntryPoint v0.8以降が7702委任EOAをネイティブ対応したことで（v0.8.0リリースノート）、7702ユーザーへのガス肩代わりもERC-4337のPaymaster経路に合流しつつあります。規格の詳細はEIP-7702の事業者向け解説を参照してください。

運用面で最初に押さえるべき性質は、Paymasterの預託金残高が切れた瞬間、対象ユーザーの取引がすべて通らなくなることです。ガスレスを提供するサービスにとって預託金は単一障害点であり、残高監視と自動補充は品質保証の一部です。

誰がガスを負担するか — 回収設計の4類型

上記の支払モデルは「技術的に誰の残高から払うか」の分類であり、「事業としてどう回収するか」は別の設計です。実務で使われる回収設計は次の4類型に整理できます。

• 類型1：事業者の全額負担（獲得コスト型）。ガス補助を顧客獲得・継続の費用として計上し、収益は別の課金（アイテム販売、手数料、広告等）で確保します。オンボーディング障壁を最も下げられる一方、利用量に比例して費用が伸びるため、後述の上限設計が必須です。基盤側がこのモデルを補助する動きもあり、Coinbase Developer PlatformはBase上のアプリ向けに最大15,000ドルのガスクレジットを提供しています（CDP Paymaster Docs、2026年8月11日閲覧）。
• 類型2：ユーザーのトークン建て負担（支払手段の置換）。ユーザーがUSDC等で支払うため事業者のキャッシュアウトはなく、レート変動と手数料設計だけが論点になります。Circle Paymasterが代表例で、ユーザーはUSDCでガス代を払い、ArbitrumとBaseではガス実費に10%の手数料が上乗せされます（Circle Paymaster Docs、2026年8月11日閲覧）。ステーブルコイン送金や決済のように「ETHは持たないがUSDCは持っている」ユーザー層と整合します。
• 類型3：定額プランへの内包。月額課金に「月N回までのガス代込み」を含め、Paymasterで消化します。売上が先に確定するため費用の読みやすさは高い一方、上限に達したユーザーの扱い（追加課金へ切り替えるか、制限するか）を先に決めておく必要があります。
• 類型4：成立取引の手数料から回収。マーケットプレイスのように取引成立時に手数料を得るサービスで、その一部をガス原資に充てます。取引が成立しなかった操作（入札、キャンセル等）のガスは回収できないため、不成立比率と、手数料収入を狙った自作自演取引への対策が損益を左右します。

支払モデルと回収類型は1対1ではありません。たとえば「新規ユーザーの最初の10回は類型1で無料、以降は類型2でUSDC徴収」のような組み合わせが実務では標準的で、Verifying Paymasterの承認条件として実装します。主要SaaSのダッシュボードは、この条件（対象コントラクト、回数上限、期間）をポリシーとして設定できるように作られています。

実際いくらかかるのか — 2026年8月時点の実勢

ガス消費のオーバーヘッド

ERC-4337経由の取引は、EntryPointでの検証・精算処理のぶん、EOAで直接送信するより多くのガスを消費します。ウォレット開発元Ambireが2026年4月に公開した実測比較では、同一ネットワーク（Optimism）上の同じUSDC送金1件に対して、EOA直接送信が約4.5万gasであるのに対し、ERC-4337＋Gas Tank（ガス事前入金）経路は約13.3万gas、ERC-20支払経由では約14.0万gasと、約3倍のガスを消費しています（Ambire: ERC-4337 Gas Overhead Analysis、2026年4月28日公開）。Gas TankはAmbireのユーザーがガス代を事前入金しておく仕組みで、冒頭の分類でいえば事業者が全額を負担するスポンサーモデルではなく、ユーザー負担側の経路です。このGas Tank経路とOptimism EOA基準との差分・約8.8万gasが、ERC-4337を経由すること自体のオーバーヘッドです。なおEOA直接送信の基準値はネットワークで異なり、同分析ではEthereumメインネットの同送金は約6.2万gasです。

このオーバーヘッドを金額に直すといくらか。同分析は、上乗せ分（約8.8万gas）だけを分離した費用を、ETH価格3,900ドルの前提で試算しています。ガス価格0.3 gwei（2025年10月時点のEthereumメインネット水準）なら1件あたり約0.10ドル、0.1 gwei（ガス価格が高めのL2の水準）なら約0.03ドル、混雑を想定した10 gweiでは約3.4ドルです。これらは取引の総費用ではなく、ERC-4337を使うことで追加される差分だけの金額である点に注意してください（取引全体の実費水準は次項の実運用統計で確認します）。オーバーヘッドはガス価格に比例して費用化するため、単価の小さい操作を高頻度でスポンサーする設計はL2が前提になり、L1で成立するのは1件あたりの事業価値が大きい操作に限られます。

実運用でPaymasterが支払っている実額

実勢の水準は公開統計から確認できます。AA特化の統計サイトBundleBearによると、累計約12.4億件のUserOperationに対し、Paymasterが肩代わりしたガス代は累計約1,336万ドルです。事業者別では、Alchemyが約6.5億件で約199万ドル、Coinbaseが約1.1億件で約302万ドル、Pimlicoが約7,800万件で約267万ドルを処理しています（BundleBear Paymaster統計、2026年8月11日閲覧）。単純計算すると、肩代わり額は1件あたり0.3〜3.4セントの範囲に収まります。ガスレスの実費は「1取引数十円」ではなく、L2中心の実運用では1取引1円未満〜数円のオーダーというのが2026年時点の実勢です。

SaaS手数料の実勢 — ガス実費+7〜10%

Paymasterを自社で運用せずSaaSを使う場合、ガス実費に手数料が上乗せされます。主要事業者の公表料金は次のとおりです（いずれも2026年8月11日閲覧）。

ここで見落とされがちなのは、L2ではガス実費よりも手数料・インフラ利用料のほうが大きくなり得ることです。前述のとおりL2の肩代わり実費は1件1セント未満のことも多く、その7〜10%は0.1セント未満にすぎません。一方、たとえばPimlicoの従量プランではUserOperation 1件あたり約0.0075〜0.0105ドル相当のクレジットを消費するため、ガス実費と同等以上の固定的な処理コストがかかります。低単価・高頻度の取引をスポンサーする場合、費用構造の主因はガス代そのものではなく、SaaSの課金体系と後述の不正利用対策の設計に移ります。

費用を狂わせる要因 — 不正利用と失敗時の負担

ガスレスの予算超過は、ガス価格の高騰よりも先に、スポンサー条件の甘さから起きるのが典型です。無条件でガスを肩代わりするPaymasterは、botや複数アカウントを使った無償利用の消化（フリーライダー問題）によって預託金を吸い上げられます。さらに、ERC-4337の仕様に根差した攻撃も報告されています。監査会社OtterSecが2025年12月に公開した分析では、次の2点が具体的に示されています（OtterSec: ERC-4337 paymasters: better UX, hidden risks）。

• 未使用ガスペナルティの悪用：EntryPoint v0.7以降は、実行用に確保して使わなかったガスの10%がペナルティとして課されます（v0.7.0リリースノート）。攻撃者が意図的に過大なガス上限を指定すると、このペナルティがPaymasterの預託金から支払われ、Bundler（UserOperationを束ねてチェーンへ送信する中継ノード）を兼ねる攻撃者はペナルティ分を利益にできます。
• postOp失敗時の取りはぐれ：ERC-20徴収型で「実行後にpostOpで代金を回収する」設計にしていると、実行直前にトークンの承認を取り消されるなどでpostOpが失敗しても、Bundlerへの支払いはPaymasterの預託金から行われます。徴収は失敗し、ガス代だけが出ていく構図です。

対策は、Paymasterの判定ロジックと運用の両面で組み合わせます。

• 対象操作の限定：肩代わりするのは自社コントラクトの特定関数だけに絞り、validatePaymasterUserOp（またはSaaSのポリシー設定）で宛先と関数を検査します。無条件スポンサーを公開しないことが最初の防衛線です。
• ユーザー認証とレート制限：メール認証やソーシャルログインを通過したアカウントに限定し、1ユーザー・1期間あたりの回数上限を設けます。
• 予算上限とフォールバック：ユーザー単位・全体単位の予算上限を設定し、超過時はERC-20徴収へ自動で切り替えるか、スポンサーを停止します。
• 徴収は検証時に行う：ERC-20徴収型では、postOp頼みにせず検証フェーズで全額を先に徴収する設計が推奨されています（前掲OtterSec）。
• ガス見積りの保守化と残高監視：過大なガス上限の申告を弾き、預託金残高の閾値監視と自動補充を運用に組み込みます。

ガス価格の上振れも、L1を使う場合には無視できません。前述のとおり費用はガス価格に比例するため、「ガス価格が閾値を超えたらスポンサーを一時停止する／ユーザー負担に切り替える」条件を、事後判断ではなく事前のポリシーとして決めておきます。Paymasterを含むAA構成全体の攻撃ベクトルはAAセキュリティリスクで扱っています。

導入判断の手順 — 費用が読める状態を先に作る

ここまでの材料を、導入前の検討手順に落とすと次のようになります。

1. 肩代わりする操作を限定する：「すべての取引を無料にする」ではなく、オンボーディングの初回設定、特定機能の利用など、事業価値に直結する操作だけを対象にします。対象が絞れないうちは費用も絞れません。
2. チェーンと方式を決める：高頻度・低単価の操作をスポンサーするならL2が前提です。ユーザーがUSDC等を保有する層なら、類型2（トークン建て負担）で自社のキャッシュアウト自体をなくせないかを先に検討します。
3. 1件あたりの総費用を実測する：費用は「ガス実費 ×（1 + SaaS手数料率）＋ 1件あたりインフラ利用料」で構成されます。対象操作のガス消費はテストネットや本番相当環境で実測し、公表料金と合わせて単価を出します。
4. 月間費用の幅を見積もる：概算例として、L2で月10万件をスポンサーする場合、前述の実勢単価（1件0.3〜3.4セント）を当てはめるとガス実費は月300〜3,400ドル、これに手数料7〜10%とインフラ利用料が加わります。実勢の幅だけで一桁変わるため、必ず自社の対象操作の実測値で置き換えます。
5. 上限とフォールバックを先に決める：ユーザー単位・全体単位の予算上限、超過時の切り替え先（ERC-20徴収・スポンサー停止）、ガス価格の停止閾値を、リリース前にポリシーとして固定します。

自社でPaymasterコントラクトを実装・運用するか、SaaSを使うかの分岐は、この単価構造で判断できます。自社運用は手数料7〜10%を節約できる代わりに、コントラクトの監査費用、預託金の資金管理、レート制限やポリシー基盤の開発・運用が固定費として乗ります。分岐点は、月間のスポンサー件数から出る手数料負担の総額がこれらの固定費を上回るか、そして対象チェーンのSaaS対応状況や必要とするSLAをSaaS側が満たせるかで決まります。取引量がまだ読めない立ち上げ期や、監査・運用体制を自前で持たない段階では、SaaSから始めて実測を取り、上記の分岐点を越えてから自社運用を検討するのが順当です。Bundler・Paymaster・SDKの具体的な組み合わせはAA開発スタックの選定で比較しています。また、複数操作を1件のUserOperationにまとめるバッチ化は、スポンサーする件数そのものを減らす費用対策にもなります（バッチトランザクションで詳述）。

まとめ

• ガスレストランザクションはガス代を消す仕組みではなく、ERC-4337のPaymaster等を通じて負担を事業者またはユーザー（別トークン建て）へ付け替える仕組みです。
• 回収設計は「事業者の全額負担」「トークン建てのユーザー負担」「定額プランへの内包」「成立手数料からの回収」の4類型で、支払モデル・検証方式とは独立に選び、組み合わせられます。
• 2026年8月時点の実勢は、主要SaaS経由でガス実費+7〜10%。実運用の肩代わり額は1件0.3〜3.4セントのオーダーで、L2ではガス実費よりインフラ利用料・手数料が費用の主因になり得ます。
• 予算超過の主因は無条件スポンサーの不正利用です。対象操作の限定、認証、レート制限、予算上限、検証時徴収を初期設計に含め、預託金残高は単一障害点として監視します。
• 導入判断は「対象操作の限定 → チェーンと方式 → 1件単価の実測 → 月間費用の幅 → 上限とフォールバック」の順で、費用が読める状態を先に作ってから行います。

関連記事

前提となる規格の理解：

• アカウントアブストラクション（AA）完全マップ 2026 — AA全体の俯瞰と採用形態の判断軸
• ERC-4337の事業者向け解説 — EntryPoint・Bundler・Paymaster・Smart Accountの役割分担
• EIP-7702の事業者向け解説 — 既存EOAをスマート化する補完規格
• ERC-4337 vs EIP-7702の判断軸 — ユーザー層で使い分ける選択フロー

設計・実装の深掘り：

• AA開発スタックの選定 — Bundler・Paymaster・SDKの組み合わせ比較
• AAセキュリティリスク — Paymaster預託金の枯渇攻撃を含む攻撃ベクトルと監査観点
• バッチトランザクション — 複数操作の1件化によるUX改善と費用圧縮

XTELAが支援できる範囲

ガスレスの導入は、対象ユーザー・負担類型の選択・費用上限の設計・不正利用対策が絡み合うため、「どの操作を誰の負担で肩代わりするか」の整理から始めるのが近道です。XTELAは、ガス負担モデルの選定と費用試算、Paymaster SaaSの比較選定、Verifying Paymasterの承認条件設計（対象操作の限定・レート制限・予算上限）、PoC実装、預託金の残高監視を含む運用設計まで、Web3サービスの技術面を支援しています。ステーブルコインでのガス支払いに関わる制度面の該当性判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術資料の整理を支援します。

ガスレス・Paymaster設計について相談する

主要参考資料

• ERC-4337: Account Abstraction Using Alt Mempool
• EIP-7702: Set Code for EOAs
• eth-infinitism: EntryPoint v0.7.0リリースノート（2024年2月22日）
• eth-infinitism: EntryPoint v0.8.0リリースノート（2025年3月26日）
• BundleBear: ERC-4337統計（2026年8月11日閲覧）
• BundleBear: Paymaster統計（2026年8月11日閲覧）
• Pimlico: Pricing（2026年8月11日閲覧）
• Alchemy: Gas Manager FAQs（2026年8月11日閲覧）
• Coinbase Developer Platform: Paymaster Overview（2026年8月11日閲覧）
• Circle: Paymaster Overview（2026年8月11日閲覧）
• Ambire: Is ERC-4337 Really Bloated? Real World Gas Analysis（2026年4月28日）
• OtterSec: ERC-4337 paymasters: better UX, hidden risks（2025年12月2日）

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。各社の料金、対応チェーン、規格のバージョン、利用統計は今後変わり得ます。導入判断の際は最新の公式ドキュメントを確認し、ステーブルコインの取り扱いなど法令・会計・税務の該当性判断は有資格の専門家に相談してください。