バッチトランザクション｜approve+swap を 1 回の署名にまとめる AA 実装と導入判断

最終確認日：2026年8月11日

「approve を承認したのに、次の swap でまた署名を求められる」「2 回のトランザクションそれぞれでガス代を払う体験が離脱要因になっている」——この長年のボトルネックは、Account Abstraction (AA、口座抽象化) のバッチトランザクション (複数のスマートコントラクト呼び出しを、ユーザの 1 回の署名でまとめて atomic (不可分) に実行する仕組み) で解消できます。ただし、バッチ化の価値の中心はガス代の削減ではなく UX にあります。Ethereum メインネットでは AA のオーバーヘッドにより、合計ガスがむしろ増える場合もあります。本記事では、DEX (分散型取引所)・DeFi (分散型金融)・NFT (非代替性トークン)・GameFi (ゲーム+金融) などのプロダクトを運営する事業責任者・プロダクト責任者・開発リードに向けて、バッチトランザクションの仕組み、UX 改善効果、ガス費用の構造、会計上の論点、実装パターンと落とし穴を整理します。

目次

1. バッチトランザクションとは
2. EOA の制約 — approve → swap が 2 Tx になる理由
3. AA の解決 — 1 回の署名でまとめて実行する
4. ガス費用の構造 — 必ず安くなるわけではない
5. UX 改善効果 — 離脱要因の除去
6. 税務・会計上の取扱論点 (一括 vs 個別計上)
7. 実装パターン — executeBatch / multicall / EIP-7702
8. 失敗時のロールバック仕様
9. 実装の落とし穴
10. FAQ
11. まとめ

1. バッチトランザクションとは

バッチトランザクション (Batch Transaction) とは、複数のスマートコントラクト呼び出しを、ユーザの 1 回の署名でまとめて実行する仕組みです。AA (ERC-4337 など) を前提とした Smart Account (口座契約) では、executeBatch のような関数を通じて、1 回の署名から複数の呼び出しを atomic (不可分) に実行できます。

• 「approve + swap」「mint + transfer + list」など複数手順を 1 回の署名・1 つの実行単位にまとめられます
• まとめた呼び出しは、すべて成功するか、すべて失敗して巻き戻される (ロールバック、取消) かの 2 択になります
• ユーザは 1 度署名するだけで複数操作が完了します

なお「1 つのトランザクションにまとめる」と表現されることも多いですが、オンチェーンの transaction 単位は実装経路によって異なります。ERC-4337 では、複数の呼び出しは「UserOperation」という transaction とは別のデータ構造にまとまり、オンチェーンでは bundler の transaction 内で実行されます (詳細は 3 章)。一方、EIP-7702 で委任した EOA が transaction を直接送る経路では文字どおり 1 つの transaction になります (EIP-7702 には ERC-4337 経由の経路もあります。7 章パターン E)。この違いは、ガス費用の構造 (4 章) と会計上の論点 (6 章) に影響します。

この「1 署名で複数操作」が、UX の面で事業インパクトを持ちます。

2. EOA の制約 — approve → swap が 2 Tx になる理由

EOA (Externally Owned Account, 外部所有口座) の構造

EOA は秘密鍵から導出される標準的な Ethereum アカウントです。従来の EOA が 1 トランザクションで実行できるのは 「1 つの宛先への 1 つの呼び出し」だけでした。複数操作を行う場合、ユーザ側で複数 Tx を順番に送る必要があります。

approve + swap の典型シーケンス

[Tx 1] ユーザ → ERC-20 トークン契約: approve(DEX, amount)
       署名 → mempool → ブロック取り込み → 確定

[Tx 2] ユーザ → DEX 契約: swap(tokenIn, tokenOut, amount)
       署名 → mempool → ブロック取り込み → 確定

各 Tx ごとに、次の負荷が発生します。

• ユーザ署名 (ウォレットからの確認モーダル)
• ガス代の支払い
• ブロック確定の待ち時間 (Ethereum メインネットなら数秒〜数十秒)

既存の workaround と限界

EOA のままでも、multicall と総称される仕組みで複数呼び出しを 1 つのトランザクションにまとめる方法はあります。ただし、方式ごとに制約が異なります。

• 独立した multicall 契約 (Multicall3 など) を呼ぶ方式: 束ねられるのは任意のコントラクトへの呼び出しですが、各呼び出し先が見る msg.sender は multicall 契約自身になります。残高照会など読み取りの集約には広く使われる一方、「本人からの操作」を要求する状態変更には使えません
• コントラクト自身が実装する multicall (Uniswap V3 の Router が持つ multicall など): ユーザが Router の multicall を 1 回呼ぶと、Router が自分自身へ delegatecall して複数の自関数を順に実行します。入口として束ねられるのは Router に実装済みの関数に限られますが、各関数の内部から token や pool など別コントラクトへの external call は行えます。msg.sender は 2 段階で異なり、Router の各関数が見る sender は呼び出した本人 (EOA) のまま、Router から先の external call を受けるコントラクトが見る sender は Router です

どちらの方式でも、EOA が「任意のコントラクト群への状態変更を、各呼び出し先から見て自分自身が msg.sender のまま束ねる」ことはできません。ERC-20 の approve はトークン保有者本人からの操作である必要があるため、approve だけは別トランザクションになる構造が長年残ってきました。EIP-2612 (Permit、署名による approve) で部分的に解決できますが、すべてのトークンが対応しているわけではありません。

なお、この「EOA ではバッチできない」という前提自体が、2025 年 5 月 7 日の Pectra アップグレードによる EIP-7702 の有効化で変わり始めています (Ethereum Foundation の Pectra 告知)。既存 EOA のままバッチ実行へ進む経路は、7 章のパターン E で整理します。

3. AA の解決 — 1 回の署名でまとめて実行する

AA で導入される Smart Account (口座契約) は、それ自体がコントラクトです。ユーザの複数操作は「UserOperation」という単位にまとめられ、1 回の署名で atomic に実行されます。

ここで押さえておきたいのは、UserOperation は Ethereum の transaction とは別のデータ構造だという点です。ERC-4337 では、bundler (UserOperation をブロックへ載せる役割) が複数ユーザの UserOperation を専用の mempool から集め、1 つの handleOps transaction としてオンチェーンへ送信します。つまり「ユーザから見た 1 回の操作 (1 つの UserOperation)」と「オンチェーンの 1 transaction」は、1 対 1 に対応するとは限りません。

バッチ実行フロー (ERC-4337 の場合)

ユーザ操作 (署名 1 回)
  ↓
UserOperation を作成
  callData = executeBatch([
    USDC.approve(Router, amount),
    Router.swap(USDC, ETH, amount),
  ])
  ※ transaction ではなく、専用 mempool に入る別のデータ構造
  ↓
Bundler が複数ユーザの UserOperation を集約
  ↓
[on-chain transaction]
EntryPoint.handleOps([userOp_A, userOp_B, ...])
  ├─ 各 UserOperation の正当性を検証 (validateUserOp)
  └─ 各 UserOperation の callData を実行 (executeBatch)
       → バッチ内の呼び出しがすべて成功すれば、その UserOperation は確定
       → 1 つでも失敗すれば、その UserOperation の実行分だけ巻き戻し

• ユーザに求められる署名操作は 1 回です。オンチェーン側では、EntryPoint が UserOperation ごとに Smart Account の validateUserOp を呼んで正当性を検証しますが、検証の中身 (単一署名、マルチシグ、パスキーなど) は Smart Account 実装に依存します。ERC-4337 には、複数 UserOperation の署名をまとめて検証する signature aggregator (署名集約) の仕組みもあります (ERC-4337 仕様)。UX 上の署名回数とオンチェーンの検証方式は分けて考えてください
• 検証後の実行ステップでは、Smart Account 自身が msg.sender として各呼び出しを発行します。approve も swap も Smart Account 名義で発行されるため、1 つのバッチに同居できます
• atomic 性が保証される範囲は「1 つの UserOperation 内のバッチ」です。同じ handleOps transaction に含まれる他ユーザの UserOperation とは、互いに独立に成否が決まります

4. ガス費用の構造 — 必ず安くなるわけではない

「バッチ化すればガス代も安くなる」と期待されがちですが、Ethereum メインネットでは合計ガスがむしろ増える場合があります。ガス消費は Smart Account 実装・バッチ内容・チェーン・時点によって大きく変わり、単一の試算値が独り歩きしやすいため、本記事では特定の数値比較は示さず、「何が減って、何が増えるか」の構造を整理します。

バッチ化で減る費目

• トランザクション基本コストの重複: Ethereum の transaction には、1 件あたり 21,000 gas の基本コストがかかります (ethereum.org のガス解説)。EOA で approve と swap を別々の transaction として送ると、この基本コストを 2 回払います。バッチ化で送信単位が 1 つになれば、この重複が解消されます
• 送信の重複に伴う付帯コスト: 送信ごとの署名・nonce 管理・calldata の重複などです

バッチ化 (ERC-4337 経由) で増える費目

• 検証オーバーヘッド: Smart Account の署名検証 (validateUserOp) は、EOA の署名検証より多くの計算をオンチェーンで行います。EntryPoint の処理が加わり、Paymaster (ガス代スポンサー) を使う場合はその検証分も加わります
• bundler transaction のコスト負担: ERC-4337 では、bundler が支払う handleOps transaction の基本コストや calldata 費用を、各 UserOperation が preVerificationGas などの項目を通じて負担します (ERC-4337 仕様)。そのため「transaction の数が減った分、21,000 gas がまるごと浮く」という単純な差し引きにはなりません

実務上の整理

• Ethereum メインネットでは、検証オーバーヘッドが基本コストの削減分を上回り、合計ガスが EOA 2 Tx より増えるケースがあります
• L2 (Optimism、Arbitrum、Base など) では、同じ操作のガス費用がメインネットより低くなることが多い一方、実際の負担額は chain、L1 データ手数料、利用件数、Paymaster などスポンサー負担の設計、事業規模によって変わります。「絶対額が小さいから影響も小さい」と決めつけず、自社構成・件数での実測を前提に、UX 改善効果と合わせて判断してください
• 自社ケースの実額は、採用予定の Smart Account と bundler を使い、テストネットまたは本番相当環境での実測 (実際の UserOperation の gas trace) で確認してください。公開データでは BundleBear で実際の UserOperation のガス統計を確認できます。bundler / Paymaster のガス構造の解説は Pimlico Docs が参考になります

導入判断は「ガスが安くなるから」ではなく、次章の UX 改善効果を主軸に行い、ガスの実額は実測で確認するのが安全です。

5. UX 改善効果 — 離脱要因の除去

体験差分

ステップ数と離脱の関係

Web2 の EC でも、チェックアウトの手順や入力負荷が増えるほど離脱が増えることが知られています。Baymard Institute の集計 (2026 年 8 月 11 日確認) では、カート放棄率は平均で約 7 割にのぼり、「チェックアウトが長い・複雑」であることが放棄理由の上位に挙げられています。Web3 のトランザクションでは、これに次の負荷が加わります。

• 各署名モーダルで「ガス代の妥当性」を確認する心理負荷
• 1 回目成功・2 回目失敗時のサポート問い合わせ
• 「approve だけ完了して swap 失敗」状態の経理処理

署名 2 回・支払い 2 回・確定待ち 2 回の構造を 1 回ずつに減らすバッチ化は、この Web3 特有の離脱要因を構造的に取り除く施策と位置づけられます。

6. 税務・会計上の取扱論点 (一括 vs 個別計上)

本節は技術設計の立場からの論点整理であり、税務・会計助言ではありません。個別の会計処理・税務申告の判断は、貴社の顧問税理士・公認会計士にご相談ください。

論点 1: バッチ内の各操作をどの単位で認識するか

バッチで「approve + swap」を実行した場合、取引記録の整理には次の 2 つの単位が考えられます。

• (A) 送信単位 (transaction / UserOperation) で 1 つの取引として扱う
• (B) バッチ内の各内部呼び出し (swap など) ごとに扱う

どちらを会計上の認識単位とすべきかについて、本記事の執筆時点で確認できた公的資料には、バッチトランザクション内の内部呼び出しの認識単位を直接定めた記載を見つけられませんでした。国税庁の暗号資産等に関する公表資料 (2026 年 8 月 11 日確認) は暗号資産取引の税務上の取扱いを一般的に示すもので、バッチ実行の粒度には触れていません。この論点は未確定のものとして、顧問税理士・公認会計士と協議のうえ自社の方針を決める必要があります。

技術設計の側で注意したいのは、内部呼び出しの記録が自動的にオンチェーンへ残るわけではない点です。transaction receipt の log に記録されるのは、各コントラクトが実装上 event を emit した内容だけです (Solidity 公式ドキュメント: Events)。ERC-20 の Transfer や主要 DEX の Swap のように event が定義された操作は log から追えますが、event を emit しない内部呼び出しを含むバッチの全容を把握するには、ノードの execution trace (debug_traceTransaction など、transaction 実行の内部呼び出しを追跡する機能) が必要です。したがって「後から (B) の整理にも必ず対応できる」かどうかは、データ基盤の設計次第です。内部呼び出し単位の整理に備えるには、少なくとも次の 4 点を前提にした設計が必要です。

• event coverage の確認: 会計上意味を持つ操作が、対象 protocol ごとに event として emit されるかを事前に調査する
• trace の取得・保存: event で足りない部分は execution trace を取得して保存する。trace の取得にはアーカイブノードまたは trace 対応のノードプロバイダが必要になる
• chain reorg (ブロック再編成) への対応: 取り込んだデータの確定判定と、reorg 発生時の再取得を設計に含める
• decode とバージョン管理: コントラクトのアップグレードや ABI の変更に追随できるよう、event / trace の decode 定義をバージョン管理する

送信単位でしかデータを保存しない設計の場合、後から内部呼び出し単位の整理が必要になると、過去分の trace をアーカイブノード等から再取得して復元する作業とコストが発生します。なお、こうしたデータ設計はあくまで「どの整理にも対応しやすくする」ための技術的な備えであり、会計上の認識単位そのものを技術ログの粒度が保証するわけではありません。認識単位の判断は顧問専門家との協議事項です。

論点 2: ガス代の按分

バッチ 1 回分のガス代を、内部の複数操作にどう対応付けるかも設計論点になります。

• すべてを「swap の付随費用」に寄せる
• gas 使用比で按分する
• 「送信単位の管理コスト」として別建てで扱う

どの整理が適切かも、論点 1 と同様に顧問専門家との協議事項です。技術側では、内部呼び出しごとの gas 消費は log ではなく execution trace から取得するため、按分に備えるなら trace の取得・保存を論点 1 のデータ設計に含めておく必要があります。

論点 3: 失敗時の処理

ロールバック (実行失敗) で全戻しになった場合、トークンの入替は発生していませんが、支払ったガス代は返還されません。この「取引が成立しなかったのに発生したガス代」をどう処理するかも、事前に整理しておくべき論点です。

論点 4: 法人運用での内部レポーティング

バッチで複数送金 (例: 100 ウォレットへの一括配布) を行う場合、社内会計 ID との紐づけを Tx ハッシュ単位だけでなく、event や trace から復元した内部呼び出し単位でも持てる設計にしておくと、認識単位がどちらに決まっても対応しやすくなります。ただし復元できる範囲は、論点 1 で挙げた event coverage と trace 取得の設計に依存します。

7. 実装パターン — executeBatch / multicall / EIP-7702

パターン A: executeBatch (AA Smart Account 内蔵)

ERC-4337 系の Smart Account (Kernel、Safe、Biconomy、ZeroDev、Alchemy Light Account など) の多くが executeBatch 相当の機能を実装しています。各実装の仕様は Safe、ZeroDev、Biconomy、Alchemy の公式 Docs を参照してください。

// 疑似コード — 教育目的、本番未保証
interface ISmartAccount {
    function executeBatch(
        address[] calldata targets,
        uint256[] calldata values,
        bytes[]   calldata datas
    ) external;
}

// UserOperation の callData に以下を埋め込む
bytes memory callData = abi.encodeWithSelector(
    ISmartAccount.executeBatch.selector,
    [USDC, ROUTER],
    [0, 0],
    [
        abi.encodeWithSignature("approve(address,uint256)", ROUTER, amount),
        abi.encodeWithSignature("swap(...)", ...)
    ]
);

• 利点: 各呼び出しの msg.sender が Smart Account 自身になります。approve も Smart Account 名義です
• 注意: Smart Account 実装ごとに関数名・引数が微妙に違います (executeBatch / executeBatchCall / multiSend)

パターン B: multicall (汎用 Helper)

multicall は、複数 call を 1 つの関数呼び出しで処理する仕組みの総称です。2 章で整理したとおり、方式によって「何を束ねられるか」と「各呼び出し先が見る sender」が異なります。

• 独立した multicall 契約 (Multicall3 など): 任意コントラクトへの call を束ねられますが、各呼び出し先が見る sender は multicall 契約です。読み取りの集約向きで、本人名義を要求する状態変更には使えません
• Router 型 (self-delegatecall。Uniswap V3 Router の multicall など): 入口は Router に実装済みの関数に限られ、各関数の内部から token や pool への external call も実行されます。Router の関数が見る sender は本人のまま、Router から先の呼び出し先が見る sender は Router です

どちらも「本人名義の approve を含む、任意コントラクトをまたぐバッチ」には使えません。それを解決するのがパターン A の executeBatch です。AA と組み合わせる場合は、Smart Account の executeBatch から multicall 対応コントラクトを呼ぶ二段構造も可能です。

パターン C: EIP-2612 Permit + 1 Tx swap

EIP-2612 対応トークン (USDC 等) なら、permit 署名 (オフチェーン署名) + swap の 1 Tx で実質的なバッチを実現できます。AA 未導入の段階でも UX 改善を部分的に先取りできます。

パターン D: EIP-5792 (wallet_sendCalls)

EIP-5792 は、Dapp がウォレットに「複数 call の一括送信」を依頼するための Wallet Call API 標準で、すでに Final ステータスに到達しています (2026 年 8 月 11 日確認)。対応ウォレットが広がるにつれ、Dapp 側は AA 実装の詳細に立ち入らずに wallet_sendCalls でバッチ送信を依頼できます。

注意したいのは、EIP-5792 経由のバッチが常に executeBatch と同じ all-or-nothing になるわけではない点です。リクエスト側の atomicRequired 指定と、ウォレット側が申告する atomic capability の組み合わせにより、atomic に実行される場合と、順次実行されて一部だけ完了し得る場合があります。atomic 性が必須の業務フローでは、ウォレットの capability を確認したうえで atomicRequired: true を指定してください (仕様は EIP-5792)。対応状況はウォレットごとに異なるため、自社ユーザのウォレット分布を確認して採否を判断します。

パターン E: EIP-7702 (既存 EOA のバッチ化)

EIP-7702 は、2025 年 5 月 7 日の Pectra アップグレードでメインネット有効化されました (Ethereum Foundation の告知)。EOA が authorization (委任の署名) によって自分の口座にコントラクトコードを委任できるため、新規に Smart Account を発行しなくてもバッチ実行へ進めます。既存 EOA ユーザ基盤を持つプロダクトにとって重要な経路ですが、次の 2 点を押さえてください。

• バッチ機能は委任先コードが提供します: executeBatch 相当の機能は EIP-7702 自体の機能ではなく、委任先のコード (Smart Account 実装など) が実装するものです。委任先に何を選ぶかは、パターン A の Smart Account 実装選定と同じ論点になります
• 実行経路は 1 つではありません: (a) 委任済みの EOA 宛てに transaction を直接送って委任先コードのバッチ関数を呼ぶ経路では、操作は文字どおり 1 つの transaction に載ります。なお authorization 自体は、本人以外の sender (スポンサー) が自分の transaction に含めて設定することも仕様上認められています (EIP-7702)。(b) 委任後の EOA を ERC-4337 の Smart Account として使う経路もあります。この経路では、authorization tuple は UserOperation そのものには含めません。eth_sendUserOperation が UserOperation と並ぶ追加パラメータ eip7702Auth として受け取り、bundler が bundle 内の各 UserOperation の authorization をまとめて、外側の SET_CODE_TX_TYPE transaction の authorizationList に入れて実行します (ERC-4337: Support for EIP-7702 authorizations、2026 年 8 月 11 日確認)。この場合も実行単位は 3 章と同じ UserOperation です

8. 失敗時のロールバック仕様

Atomic 性

executeBatch によるバッチでは、バッチ内の 1 つでも revert すれば、バッチ全体が revert します。これが atomic 性です。ユーザが意図しない中間状態 (approve 済みだが swap 失敗) を作らない設計になります。なお、3 章のとおり ERC-4337 で atomic 性が保証される範囲は 1 つの UserOperation 内であり、また EIP-5792 経由の場合は atomicRequired とウォレット capability により non-atomic になり得ます (7 章パターン D)。

部分成功を許容したい場合

「失敗してもよい呼び出し」を含めたいケース (例: 複数の NFT mint で、売り切れたものはスキップしたい) では、次の実装が考えられます。

• try/catch で個別に失敗を握りつぶす (low-level call)
• failure flag を含めたカスタム executeBatch を実装する

ただし、部分成功を許容すると会計・サポートの両面で複雑度が上がるため、原則は all-or-nothing を推奨します。

ロールバック時のガス消費

revert しても、そこまでの計算で消費した gas は返ってきません。バッチの後半で失敗するほど無駄なガスが増える構造のため、validation 段階での事前チェック (残高、approve 上限、価格スリッページ) が重要です。

Bundler/Paymaster との関係

ERC-4337 では Bundler (UserOperation をブロックに乗せる役割) が UserOperation の事前シミュレーションを行います。シミュレーション段階で失敗が確実な UserOperation は、そもそもチェーンに届かず弾かれます。これにより、ユーザがガスを払って失敗するケースを減らせます。

9. 実装の落とし穴

落とし穴 1: 無制限 approve の残存リスク

バッチに組み込む approve の額を「無制限」に設定すると、その後に呼び出し先コントラクトの脆弱性が見つかった場合に、残高全体が引き出されるリスクが残り続けます。バッチ化すれば approve の追加署名コストは消えるため、スポット approve (必要額ぴったり) をバッチに組み込む設計が安全です。

落とし穴 2: Smart Account 実装の差異

executeBatch の関数シグネチャ・引数順序は実装ごとに違います。Kernel / Safe / Biconomy / Alchemy / ZeroDev のどれを採用するかで SDK 側の実装が変わるため、最初に Smart Account 実装を 1 つ決め切る判断が事業上重要です。

落とし穴 3: ガス見積りの精度

バッチは内部呼び出しが多いため、gas 見積りが外れやすくなります。見積り不足で実行段階に失敗すると、そこまでに消費したガスは返還されません。採用する Smart Account とバッチ内容の組み合わせで実測した値を基準に余裕を持った上限を設定し、送信前の事前シミュレーション (bundler の見積り API や Tenderly 等) を組み込んでください。

落とし穴 4: Paymaster ポリシー違反

Paymaster (ガス代スポンサー、Gasless 体験の担い手) を併用する場合、バッチ内に Paymaster ポリシー外の呼び出しが混じると拒否されます。「approve + swap までは OK、別の DEX 呼び出しは NG」など、ポリシー設計とバッチ設計を整合させる必要があります。

落とし穴 5: ブロック確定とユーザ通知の UX

署名が 1 回になったとはいえ、ブロック確定までの数秒〜数十秒は残ります。「署名後に何も起きないように見える時間」をどう埋めるか (進捗バー、内部呼び出しのステップ表示) で離脱率が変わります。

落とし穴 6: 監査対象範囲の拡大

executeBatch のロジック自体が脆弱性を抱えると、Smart Account に紐づく全資産が危険にさらされます。Smart Account 実装と自社追加ロジックの両方を監査対象に含めてください。

落とし穴 7: アップグレード時の互換性

Smart Account 実装をアップグレード (Proxy 経由) するときに、executeBatch の挙動・関数選択子 (selector) が変わると、既存のフロントエンド・SDK と非互換になります。バージョン管理と互換性レイヤを初期から計画してください。

10. FAQ

Q. 既存の EOA ユーザにもバッチトランザクションを提供できますか？

A. 提供できる可能性があります。2025 年 5 月の Pectra アップグレードで EIP-7702 が有効化され、既存 EOA のままコード委任によるバッチ実行が可能になりました。ただし実際に使えるかはウォレット側の対応に依存するため、自社ユーザのウォレット分布と、EIP-5792 (wallet_sendCalls) への対応状況を確認して判断します。

Q. バッチにすれば必ずガス代は安くなりますか？

A. 必ず安くなるわけではありません。ERC-4337 経由では、Smart Account の署名検証や EntryPoint の処理、bundler の transaction 費用の負担 (preVerificationGas) が加わるため、Ethereum メインネットでは EOA で 2 回に分けて送るより合計ガスが増える場合があります。バッチ化の本質的な価値は「署名 1 回・支払い 1 回・中間状態なし」という UX 側にあり、ガスの実額は採用する Smart Account 実装とチェーンでの実測で確認する必要があります。

Q. バッチ内の 1 つの呼び出しだけ失敗したらどうなりますか？

A. 標準的な executeBatch では、1 つでも失敗すればバッチ全体がロールバックされます (all-or-nothing)。部分成功を許容する実装も可能ですが、会計処理とユーザサポートが複雑になるため、明確な理由がない限り all-or-nothing を推奨します。なお EIP-5792 経由のバッチは、ウォレットの capability と atomicRequired 指定によっては順次実行になり、一部だけ完了する場合があります。

Q. バッチトランザクションの会計処理は Tx 単位でよいですか？

A. 執筆時点 (2026 年 8 月 11 日) で確認できた公的資料には、バッチ内の内部呼び出しをどの単位で認識すべきかを直接定めた記載がなく、未確定の論点です。技術面でも、内部呼び出しの記録が自動でオンチェーンに残るわけではありません。transaction receipt の log に残るのは各コントラクトが emit した event だけで、内部呼び出しの全容を追うには execution trace が必要です。内部呼び出し単位の整理に備えるには、対象 protocol の event coverage 確認と trace の取得・保存を含むデータ設計を事前に行う必要があります (詳細は本文 6 章)。会計・税務上の認識単位そのものは、国税庁の最新の公表資料を踏まえ、貴社の顧問税理士・公認会計士にご確認ください。

11. まとめ

本記事の要点は次の 3 つです。

1. AA バッチの本質は「1 回の署名で approve+swap が atomic に完了する」という UX 価値です。Ethereum メインネットでは検証オーバーヘッドにより合計ガスが増える場合があるため、ガス削減を前提にした導入判断は避け、ガスの実額は実測で確認してください。EIP-7702 の有効化により、既存 EOA のままバッチへ進む経路も現実的になりました
2. 会計上の認識単位 (送信単位か内部呼び出し単位か) は未確定の論点です。内部呼び出しの記録は自動では残らないため、技術側でできる備えは、event coverage の確認と execution trace の取得・保存を含むデータ基盤を事前に設計しておくことです。ただし、それが会計上の認識単位を保証するわけではなく、最終判断は顧問税理士・公認会計士へ確認してください
3. all-or-nothing の atomic 性が事故防止の最大価値です。ただし保証範囲は経路により異なります。executeBatch は 1 つの UserOperation 内で保証され、EIP-5792 経由はウォレット capability と atomicRequired 指定に依存します

参考情報

いずれも 2026 年 8 月 11 日に到達・内容確認済みです。

• ERC-4337: Account Abstraction Using Alt Mempool (Final)
• EIP-2612: Permit Extension for EIP-20 Signed Approvals
• EIP-5792: Wallet Call API (Final)
• EIP-7702: Set Code for EOAs (Final)
• Ethereum Foundation: Pectra Mainnet Announcement (2025年4月23日、5月7日有効化)
• ethereum.org: Gas and Fees (transaction 基本コスト 21,000 gas)
• Solidity Documentation: Events (log に残るのは emit された event である旨)
• Multicall3 (独立 multicall 契約の実装)
• Uniswap v3-periphery Multicall.sol (Router 型 self-delegatecall multicall の実装)
• Pimlico Docs (ERC-4337 Bundler / Paymaster)
• BundleBear (ERC-4337 採用状況・ガス統計)
• Safe Docs / ZeroDev Docs / Biconomy Docs / Alchemy Docs
• Baymard Institute: Cart Abandonment Rate Statistics
• 国税庁: 暗号資産等に関する税務上の取扱い

本記事は XTELA JAPAN 株式会社が作成しました。 AA バッチトランザクション実装のご相談は無料技術相談からお問い合わせください。