---
title: "ゼロ手数料、無限の複雑さ:ガスレストランザクションをスケールで構築する"
description: "コンシューマー向けアプリでは、ブロックチェーンが他の決済体験と変わらないものである必要がある。最大の障壁は、ほとんどのユーザーが理解することのない手数料層だ。ここでは、それを完全に取り除く方法を紹介する。"
---

# ゼロ手数料、無限の複雑さ:ガスレストランザクションをスケールで構築する

<ImageBlock
  src="https://media.alchemy.com/1772629973-technical-guide-blog.png"
  alt="ユーザー体験からガス代をなくすガスレストランザクションインフラ"
  width={1920}
  height={900}
  priority
/>

ブロックチェーンインフラは、即時決済、グローバルなリーチ、そして従来の金融を桁違いに上回るコスト構造を実現する。[Stablecoins](https://www.alchemy.com/dapps/top/stablecoins)は最新のL2上で1秒未満、1セント以下で決済される。レールはすでに存在しているが、この次世代のマネームーブメントを活用しようとする企業は大きな課題に直面している。

普及のボトルネックは速度でもコストでもセキュリティでもなく、ガスだ。すべてのブロックチェーントランザクションは、送信者がそのチェーンのネイティブトークンを保有してガス代を支払うことを要求する。10万ドル分のUSDCを持つユーザーでも、まず取引所でETHを取得しなければ1ドルすら送金できない。ガス価格は予測不能に変動する。チェーンごとに異なるネイティブトークンが必要になる。

[金融機関](/fintech)にとって、これは論外だ。銀行はバランスシート上に変動の激しいネイティブトークンを保有したくない。決済処理業者はエンドユーザーにガス残高の管理を求めることはできない。コンシューマーアプリは、Venmoのようなシンプルな体験が求められるフローにマルチトークンの複雑さを持ち込むことはできない。

[Gasless transactions](/gasless-transactions)は、アプリケーションがユーザーに代わってガス代を負担することでこの問題を解決する。ユーザーはネイティブトークンを保有することも、取得することも、意識することもない。開発者はドルで支払う。インフラプロバイダーがその間のすべてを処理する。

## ガスレストランザクションの仕組み

ガスレストランザクションは、ガス代の支払いをエンドユーザーからアプリケーション開発者へと移し、オンチェーンの仕組みと請求はインフラプロバイダーが管理する。

フローは以下の通り:

1. **開発者がガスポリシーを作成** — API またはダッシュボードを通じて、支出ルール（ユーザーごとの上限、ポリシーごとの上限）、許可リスト/拒否リスト、カスタムWebhookベースの適格性ルール、ERC-20トークンによる支払いオプションを設定する。
1. **ユーザーがトランザクションを開始** — アプリケーションがそれをAlchemyのTransaction APIに転送する。
1. **AlchemyがポリシーIchecks** — 支出上限、適格性ルール、カスタム条件をリアルタイムで検証する。
1. **Alchemyがpaymasterペイロードに署名** — Sponsorship ServiceがAWS KMSを通じて暗号署名を生成し、オンチェーンのpaymasterコントラクトにガス代の支払いを許可する。
1. **トランザクションがオンチェーンに反映** — paymasterスマートコントラクトが署名を検証し、ネイティブトークンでガス代を立て替える。
1. **開発者がUSD建ての請求書を受け取る** — Alchemyが確定したトランザクションを追跡し、ガスコストをUSDに換算して月次請求に加算する。

APIコール1回。統合にかかる時間は数分。その裏側では、ポリシー適用、暗号署名、マルチチェーンのガス見積もり、オンチェーン確定の追跡、請求の照合をインフラが処理している。

## 裏側のインフラ

Alchemyのガスレスインフラは3つのコアサービスで構成されている:

**Sponsorship Service** — リアルタイムの意思決定エンジン。すべてのスポンサーシップリクエストを開発者のポリシー設定と照合し、ほぼリアルタイムで集計された支出統計をチェックし、AWS KMSを通じてハードウェアレベルのセキュリティ保証付きでpaymasterペイロードに署名する。

**[Paymaster](/overviews/what-is-a-paymaster) Admin Service** — ガスポリシーの作成・管理を行うCRUD API。支出ルール、許可リスト/拒否リスト、カスタムWebhookベースの適格性、ERC-20トークンによる支払い設定、ポリシー期間の制御に対応する。

[**Bundler**](/overviews/what-is-a-bundler) — スポンサー対象の[UserOperations](/overviews/user-operations)（トランザクション）を集約し、バンドルされたトランザクションとしてオンチェーンに送信することで、より速い確定時間とより高いスループットを実現する。対応する各ネットワークでの送信戦略を処理し、オンチェーンへの取り込みを監視し、確定データを下流の請求・ポリシー適用システムに供給する。

これらのサービスは合わせて、対応するすべてのチェーンで毎秒数千件のスポンサーシップリクエストを処理しており、6億件以上（増加中）のレコードを扱い、書き込みスループットは毎秒800件（増加中）に達する。開発者側がやることはAPIコール1回だけだ。

## ガスを見えなくするために必要なこと

すべてのインフラチームは、自社で構築するか買うかという判断に直面する。私たちの基準はシンプルだ。製品の差別化にならないなら、それを自分たちで構築すべきではない。決済アプリがガスの負担方法によって選ばれることはなく、ガスレスインフラの構築にかかるリソースと時間は決して小さくない。ここでは、私たちが解決している課題のいくつかを、顧客がそれに悩まされずに済むように紹介する。

### データパイプラインの課題

すべてのスポンサーシップリクエストはレコードを生成し、それは書き込まれ、オンチェーンでの確定まで追跡され、請求と照合されなければならない。規模が大きくなると、これは高スループットなデータパイプラインの課題になる。

Worldは1日あたり350万件のスポンサーシップリクエストを送信している。3か月の保持期間で見ても、この1顧客だけで数億件のレコードが生成される。Alchemyのpaymasterデータベースは、合計6億件以上のレコードに対して毎秒800件の書き込みを処理しており、インフラは数十億件規模まで拡張できるよう設計されている——階層化された保持ポリシー、ストリーミングベースのチェーン監視、サービス層全体での水平スケーリングによって実現している。

### リアルタイムのポリシー適用

開発者がユーザー1人あたり月100ドルのスポンサーシップ上限を設定した場合、その上限はすべてのチェーン、すべてのトランザクションにわたって、毎秒数千件のリクエストの中で守られなければならない。確定した支出のソースオブトゥルースはオンチェーン上にあり、確定までに数分かかるため、オフチェーンのポリシー判断とオンチェーンの確定をほぼリアルタイムで照合し続ける継続的な集計パイプラインが必要になる。

Alchemyはこれらのパイプラインを常時稼働させており、ユーザーが設定した上限に達すると——たとえ複数チェーンで同時にトランザクションが発生していても——スポンサーシップを停止する。

### スループットを保った暗号署名

スポンサー対象のトランザクションはすべて、オンチェーンのpaymasterコントラクトがガス代を支払うべきことを証明する暗号署名を必要とする。Alchemyはこれを、銀行や政府機関が用いるのと同じ基準であるAWS KMSを通じて、ハードウェアレベルのセキュリティで生成している。

高スループットでこのセキュリティ基準を維持するには、水平方向の鍵管理戦略、低レイテンシの署名パイプライン、そして単一障害点がトランザクションをブロックしないための冗長性が必要になる。

### マルチチェーンのガス抽象化

ガスの仕組みはチェーンごとに大きく異なる。Ethereum L1のガス価格は需要に応じて変動する。L2にはそれぞれ異なるシーケンサー経済モデルがある。Solanaはまったく異なるモデルを採用しており、スマートアカウントのpaymasterではなく、トランザクション手数料と関連トークンアカウントのrentをスポンサーする。

Alchemyはこれらすべてを単一のAPI表面の裏に抽象化している。開発者はポリシーIDを付けて`prepareCalls`を呼び出すだけで、システムがチェーン固有のガス見積もり、スポンサーシップの検証、オンチェーンの確認を処理する。Ethereum、Arbitrum、Base、Solana、その他対応するすべてのチェーンで、開発者体験は変わらない。

### シンプルなUSD建て請求

開発者がガス代をスポンサーするために、ETHやSOLといったネイティブトークンを保有する必要はない。Alchemyはすべてのチェーンでネイティブトークンによりガス代を立て替え、月末に単一のUSD請求書を発行する。

これには、数十のチェーンにまたがるガス用トレジャリーの管理、リアルタイムでのUSDへのコスト換算、そして数百万件のスポンサー対象トランザクションを正確に照合する請求パイプラインが必要になる。自動の支出上限は、混雑時のガス価格急騰から開発者を守り、請求額に驚かされることがないようにする。結果として、本質的にボラティリティが高くマルチカレンシーであるものに対して、SaaSのような請求体験が実現している。

### プロトコルの進化

EVM上でのガスレストランザクションの標準は大きく進化してきた。**ERC-2771**（メタトランザクション）はスマートコントラクトの改変を必要とした。[**ERC-4337**](/overviews/what-is-account-abstraction)は、標準化されたBundlerとPaymasterを備えたAccount Abstractionを導入した。[**EIP-7702**](/overviews/eip-7702-ethereum-pectra-hardfork)は、既存のEOAがアドレスを移行することなく[smart wallet](https://www.alchemy.com/smart-wallets)の機能を得ることを可能にする。

Alchemyはこれらすべての移行を経て構築されており、Transaction APIをプロトコルのラッパーではなく機能レイヤーとして設計している。このAPIは、ガスのスポンサー、コールのバッチ処理、ERC-20によるガス支払いの受け入れといった開発者がしたいことを表現し、その裏にあるプロトコルの複雑さを処理する。新しい標準が登場したり、プロトコルが変化したりしても、私たちがそれを採用・対応する。開発者側の統合は変わらない。

### 開発者にとってのシンプルさ

開発者向けの統合はAPIコール1回で完結する:

<CodeSnippet
  language="typescript"
  code={`const { id } = await client.sendCalls({
  from: await signer.getAddress(),
  capabilities: {
    paymasterService: {
      policyId: config.policyId,
    },
  },
  calls: [{ to: "0x0000000000000000000000000000000000000000",value: "0x00", data: "0x" }]
});`}
/>
この裏側では、ポリシー検証、リアルタイムの支出適用、チェーン固有のガス見積もり、7702委任の検出、KMS署名、UserOperationの構築、bundlerへの送信、オンチェーン確定の監視、請求の照合が行われている。

同じprepare-sign-sendのパターンはどの言語でも機能し、既存のカストディソリューション（HSM、MPC、[Privy](https://www.alchemy.com/dapps/privy)、[Turnkey](https://www.alchemy.com/dapps/turnkey)）ともアーキテクチャの作り直しなしに統合できる。

## 市場の状況

ガスレストランザクションインフラは、収斂しつつある2つの市場において要件となりつつある。

**crypto市場に参入する金融機関。** 銀行、フィンテック、決済会社は、バランスシート上にネイティブトークンを保有できない。JPMorganは、JPMD預金トークンのフローで1日あたり100億ドル以上を処理している。Bank of China Hong Kongは、ステーブルコインのmint/burnオペレーションのためにガスレスインフラを展開している。これらの機関は、コンプライアンス管理、監査証跡、SLA保証を備えた本番グレードのガススポンサーシップを必要としている。

**目に見えないブロックチェーンを求めるコンシューマーアプリケーション。** [Slash](/case-studies/slash-stablecoin-banking)は、完全にガスレスなフローで10億ドル以上のステーブルコインによる事業支払いを処理してきた。Worldは、Alchemyのbundlerおよびpaymasterインフラを通じて週1,200万件以上のトランザクションを実行している。ユーザー体験の基準は、即時、無料、そして従来のフィンテックと見分けがつかないことだ。

Alchemyは現在、すべてのEVMチェーンおよびSolanaにおけるガスレストランザクションで約85%の市場シェアを保持しており、過去2年間で10億ドル以上を処理してきた。

## ガスレスインフラの上に構築する

paymasterインフラ、KMS署名、マルチチェーンのガス見積もり、プロトコルの移行を管理することは、製品の差別化にはならない。ユーザーは自分のガスがどのようにスポンサーされたかを知ることも気にすることもない——送金が速く、安く、簡単だったということだけを知っている。

Alchemyがインフラの複雑さを引き受けることで、チームは自社のビジネスを動かすもの——機能の出荷、ユーザーの拡大、収益の創出——に集中できる。最高のガスレストランザクション体験とは、誰も気づかない体験のことだ。

[gasless infrastructure](/gasless-transactions)を見る、[start building](https://dashboard.alchemy.com/)、そしてカスタム価格や統合に関する質問などは[contact us](/contact-sales)まで。お気軽にどうぞ。

## よくある質問

### ガスレストランザクションとは何ですか?

ガスレストランザクションとは、アプリケーションがユーザーに代わってガス代をスポンサーすることを可能にする仕組みで、エンドユーザーはブロックチェーントランザクションを完了するためにETHのようなネイティブトークンを保有・取得・意識する必要が一切なくなる。

### ガスレストランザクションはどのように機能しますか?

開発者がガスポリシーを作成し、ユーザーがアプリケーションを通じてトランザクションを開始し、Alchemyがそれをポリシーと照合して検証し、paymasterペイロードに署名する。paymasterスマートコントラクトがオンチェーンでガス代を支払い、開発者はUSD建ての請求書を受け取る。

### ガスレストランザクションにおけるpaymasterとは何ですか?

Paymasterとは、暗号署名を検証し、スポンサー対象のトランザクションについてネイティブトークンでガス代を立て替えるスマートコントラクトであり、これによりエンドユーザーではなくアプリケーションがガスコストを負担できるようになる。

### ユーザーのためにガス代をスポンサーするために、ETHやネイティブトークンを保有する必要はありますか?

いいえ、Alchemyが対応するすべてのチェーンでネイティブトークンによりガス代を立て替え、月末に単一のUSD請求書を発行するため、開発者が変動の激しいネイティブトークンを保有する必要は一切ない。

### ERC-4337とは何で、ガスレストランザクションとどう関係していますか?

ERC-4337は、標準化されたBundlerとPaymasterを備えたAccount Abstractionを導入したものであり、UserOperationsを通じてガス代の支払いをユーザーからアプリケーション開発者へと移すことで、ガスレストランザクションを可能にしている。

### Alchemyは異なるブロックチェーン間でガスレストランザクションをどのように扱っていますか?

Alchemyはチェーン固有のガスの仕組みを単一のAPI表面の裏に抽象化しており、Ethereum、Arbitrum、Base、Solana、その他対応するチェーンにわたって、ガス見積もり、スポンサーシップの検証、オンチェーンの確認を処理している。

### ガスレストランザクションの支出上限を設定できますか?

はい、開発者はユーザーごとの上限、ポリシーごとの上限、許可リスト/拒否リスト、カスタムWebhookベースの適格性ルールを備えたガスポリシーを設定でき、これらはすべてのチェーンにわたってリアルタイムで適用される。

### 自分のアプリケーションにガスレストランザクションをどれくらい早く統合できますか?

Alchemyの Transaction APIを使えば、統合はAPIコール1回で数分のうちに完了する。ポリシー検証、ガス見積もり、署名、請求の照合を含む裏側のインフラはすべてAPIが処理する。