L2の手数料が月末に合わない理由｜L1データ費を含めた費用の見える化と予算管理

L2の上で決済サービスを動かしている会社で、開発責任者が費用のダッシュボードを作りました。取引ごとの結果（receipt）から、使ったガスの量とガス単価を掛けて、毎日の手数料を足し上げる仕組みです。ところが月末、ウォレットから実際に出ていった額と、ダッシュボードの合計が合いません。

OP Stack系のL2では、取引の手数料は3つの合計です。

• L2で処理する代金（L2実行費）
• 取引データをL1に載せる代金（L1データ費、L1 data fee）
• チェーン運営者が上乗せする手数料（operator fee）

ところが、実行費だけを receipt.gasUsed × effectiveGasPrice で集計すると、残りの2つが抜け落ちる実装があります。この会社のダッシュボードも、手数料の一部しか数えていなかったのです。

費用が読めなくなる理由は、ほかにもあります。見積もりと実績と請求を同じ欄に入れてしまう。チェーン全体の月額しか見ていないので、増えた理由が分からない。「月の予算を超えたら通知」しかなく、月末まで異常に気づけない。

では、L2の費用を「今月いくらかかりそうか」まで説明できるようにするには、どうすればよいか。短く言えば、次の3つです。

1. 利用者の手数料、アプリの負担、独自L2の運営費を分けて測る
2. 確定した費用を、取引件数・成功率・データ量と結びつける
3. 1件あたりの単価と月の予算の両方から、異常と月末の着地を見る

以下では、この決済サービスの開発責任者が計測を組み直す順に追います。後半では、OP Stackなどで独自L2を運営する場合の事情と、データの形などの実装の詳細を扱います。

その費用は誰が払うのかを最初に分ける

L2の費用には2種類あります。利用者がチェーンへ払うネットワーク手数料と、サービス運営者が負担する原価です。

利用者がガスを直接払うサービスでも、RPC、インデクサー、監視、鍵管理は運営者の負担です。Paymasterや中継者（relayer）でガスを肩代わりすれば、ネットワーク手数料も運営者の原価に移ります。独自L2では、さらにチェーンを動かす費用が加わります。

費用は4つの層に分けて考えます。層ごとに、何で増えるか、誰の予算かが違います。

バッチの充填率とは、L1へまとめて送るデータの入れ物が、どれだけ埋まっているかです。層ごとに測る具体的な値は、後半の「層ごとに記録する値」にまとめました。

冒頭の3つの内訳は、OP Stackの公式ドキュメントにもとづきます。operator feeはIsthmusアップグレードで入り、計算式はJovianアップグレードで変わりました。使うチェーンのreceiptの追加項目、手数料を返すコントラクト（GasPriceOracle）、SDKの計算仕様を確かめてください（OP Stack Transaction Fees、2026年9月24日確認）。

見積もり・実績・請求は別々に記録する

同じ「手数料」でも、いつ・何のために取った数字かで3種類あります。

• 見積もり：送信の前に出す予想。残高の確認や、利用者への表示に使う
• 確定値：receiptの実績。利用量の分析に使う
• 会計値：請求書やクラウドの明細。帳簿との突き合わせに使う

取った時点も目的も違うので、同じ欄を上書きせず、別の値として保存します。見積もりは実行費・データ費・運営手数料の予想、確定値は同じ3つの実績です。会計に回す値は、確定値にRPCやノードの費用の按分と、再送の費用を足したものです。

見積もったときのブロック、料金パラメータ、SDKのバージョンも残します。そうすれば、確定値との差を後から再現できます。

円などへの換算では、どの価格をどの時刻で使うかを決めます。送信時、確定時、日次の終値、請求の計上時。これらが混ざると、ガスの使い方が変わったのか、ETHの値段が動いたのかを見分けられません。技術運用のダッシュボードではネイティブトークン建てと法定通貨建てを並べ、会計上の換算は社内の方針に従います。

何ごとに集計すれば、増えた理由が分かるか

費用が増える理由は、いくつもあります。

• 利用が増えた、正常な増加
• コードの変更でガスが増えた
• L1データ費の急騰、またはrevert（取り消し）の増加

チェーン全体の月額だけでは、このどれなのかを区別できません。receiptだけを長く保存しても、どの機能の予算かは分かりません。そこで、送信するときに業務上の識別子を付け、チェーン上の結果と結びます。個人情報や取引先の機密をチェーン上に足す必要はありません。対応表は、アクセスを制限したチェーン外の観測基盤に置きます。

集計の切り口は、少なくとも次の5つです。

• チェーン、業務操作、支払者
• 環境（本番か検証か）、時間帯

成功件数、試行件数、送信バイト数、gasUsedも同じ細かさで持ちます。こうすると、試行1件あたりの費用と、成功した業務1件あたりの費用を比べられます。

予算を3つの方向から見張る

「月の予算を超えたら通知」だけにしておくと、月末近くになるまで異常に気づけません。次の3つを組み合わせて見張ります。

1. 絶対額：チェーン・環境・費用の層ごとの、日次・月次の支出。契約や経理の上限を守る。
2. 単価：成功1件あたり、ユーザーあたり、業務操作あたりのp50/p95（中央値と、95%が収まる値）。プロダクトの効率の悪化に気づく。
3. 消化速度：直近1時間・1日・7日の使うペースと、月末の着地予測。急な跳ね上がりと、ゆっくりしたずれを見分ける。

着地予測は単純な計算で出せます。月の予算をB、月初からの支出をS、経過日数をd、月の日数をDとすると、着地予測は S / d × D です。

数値で見てみます。月予算100万円・30日の月で、10日目までに45万円を使ったとします。着地予測は45万円÷10日×30日＝135万円。予算を35万円超える見込みです（金額は例示）。

ただし、曜日によって利用に偏りがあるなら、前年同じ週の実績や、予約済みのバッチも加味します。

判定に使う時間の幅も、目的で分けます。

• 短時間の急騰：「直近1時間の単価が7日中央値の2倍」など
• 続いているずれ：「7日予測が予算の90%超」など

この2つは、同じ通知にまとめません。

アラートが鳴ったら、まず何を見るか

兆候ごとに、最初に見る数字と、安全な最初の手は次のとおりです。

主な原因の候補は、兆候ごとに次のとおりです。

• L2実行費の上昇：コード変更、ストレージの肥大、再試行、混雑
• L1データ費の上昇：データの増加、バッチが小さい、L1/Blobの需要
• 総額だけの上昇：正常な事業の成長、またはbot・スパム
• 見積もりの誤差の拡大：古い料金パラメータ、送信までの遅延、入力の差

予算を超えそうなとき、全部止めずに「絞る・待たせる・続ける」を決めておく

予算アラートで全取引をすぐに止めると、決済や出庫の食い違いを生むことがあります。そこで業務操作ごとに、通常のほか、次の4つの状態を決めておきます。

• 抑制：無料枠、キャンペーン、bot疑い、優先度の低い処理に流量制限をかける。ガス代を肩代わりしている場合の予算の分け方と止める目安はPaymasterの不正利用・ガス枯渇対策で扱っています。
• 延期：決済の期限に余裕のあるバッチを待ち行列に残し、手数料が下がってから送る。期限と待ち行列の上限は決めておく。
• 緊急継続：資産を守るためや障害の復旧に要る取引は、別の予算と承認の手順で続ける。
• 停止：新しい受付は止めても、送信済みの取引の追跡、置き換え、突き合わせは続ける。

送り直した取引（置き換え取引）を、元の取引と別件として数えると、失敗のコストがどこから来たか見えません。元の取引とひもづけ、最終的に採用された取引と、試した分の費用の合計を残します。

revertした取引も手数料を使います。成功率が落ちたときは、総額より「成功した業務1件あたりの費用」を先に確かめます。

観測だけの段階から、少しずつ自動の制御へ進める

1. 範囲を決める：対象のチェーン、支払者、業務操作、環境、費用の層、換算のルール、保持期間を決める。
2. 影の計測：送信処理は止めずに、見積もり・receipt・請求明細を集め、日次で突き合わせる。
3. 数字が合うか確かめる：総額の95%以上が、どの取引・どのバッチ・どの基盤費の分かを説明できるか確認する。説明できない分をゼロとして扱わない。
4. 通知：絶対額、単価、消化速度のアラートを動かし、誤検知と通知先を調整する。
5. 手動での制御：手順書に沿って、流量制限、延期、予算の増額を人が判断する。
6. 限られた範囲の自動化：資産の移動を伴わない、優先度の低い処理から自動で抑える。解除の条件と、手動で上書きする権限もテストする。

採用の条件は、費用データが取れることだけではありません。次のことまで確かめます。

• データが欠けたとき、支出をゼロと取り違えない
• 収集処理をやり直しても、二重に数えない
• チェーンの再編成の後に集計を直せ、料金仕様のアップグレードに気づける

OP Stackのように、手数料の内訳や計算式がアップグレードで変わるチェーンもあります。計算式をアプリに埋め込まず、chain ID・ブロック範囲・仕様のバージョンを記録します。

採用の前に確かめること

• L2実行費、L1 data fee、operator fee、基盤費を別々に集計できる
• 見積もり・確定値・請求値と、換算の時刻・価格の出どころを区別している
• チェーン、業務操作、支払者、環境、成功／失敗で費用を分解できる
• 絶対額、成功1件当たり単価、消化速度に別の閾値がある
• 欠測、再編成、置き換え取引、重複収集を訂正できる
• 予算超過時の抑制・延期・緊急継続・停止と、解除の責任者が決まっている

ガス代を事業者が肩代わりする設計の費用モデルはガスレストランザクションの経済性、L1からL2へ移したアプリの費用を移行時にどう測るかはL1からL2へのアプリ移行も参照してください。

独自L2を運営する場合：L1データ費はバッチとBlobの相場で変わる

ここからは、OP Stackなどで自社のL2を動かしている場合の話です。独自L2では、バッチの投稿、シーケンサー、出力の提案者（proposer）、異議申立者（challenger）または証明者（prover）などの費用も加わります。

RollupはL2の取引データをL1に公開するので、L1側の費用を負担します。EIP-4844は、Blobに実行ガスとは別の手数料市場で値段を付けます。そのため、L2の実行の需要が変わらなくても、Blobの需要で費用が変わります（EIP-4844）。Ethereum.orgも、Optimistic Rollupの費用の要素として、状態データの投稿とBlob gasを分けて説明しています（Optimistic Rollups）。

独自L2で費用を取引に割り振るときは、「投稿したL1取引の実費」と「そのバッチに入ったL2取引」を結びます。件数で単純に割ると、データ量の大きい取引を少なく見積もってしまいます。

保存するのは、圧縮前のバイト数、圧縮後の推定バイト数、バッチID、投稿した取引のhash、Blob数、投稿の遅れです。少なくとも業務操作ごとのデータ量で割り振ります。

バッチが埋まるまで待てば、1件あたりの費用は下がりえます。ただし、確定までの時間は延びます。Ethereumの研究資料も、Blobを満たす費用効率と、投稿の遅れの引き換えを指摘しています（EIP-4844 Economics and Rollup Strategies）。

ですから、費用を最小にすることだけでバッチの間隔を変えてはいけません。safe/finalized（取引が覆りにくい段階・覆らない段階）に届くまでの時間や、出金の要件を、目標値（SLO）として同時に見張ります。

実装する人向けの詳細

ここからは、さきほどの決済サービスで計測を実装する担当者向けに、記録する値とデータの形を示します。

層ごとに記録する値

• L2実行：gasUsed、base fee、priority fee、operator fee
• L1データ可用性：L1 data fee、投稿したBlob数、圧縮後のバイト数、Blob/base fee
• 運用基盤：RPCリクエスト、ノード、ストレージ、外部転送量、監視、署名処理
• 障害・再実行：revert、置き換え取引、重複送信、再投稿、手動対応の時間

見積もり・確定値・会計値の式

estimated_native = estimate_l2_execution + estimate_l1_data + estimate_operator
actual_native    = receipt_l2_execution + receipt_l1_data + receipt_operator
allocated_cost   = actual_native + allocated_rpc + allocated_node + retry_cost
actual_fiat      = allocated_cost * fx_rate_at_accounting_rule

Baseの公式ドキュメントは、L1手数料を返す関数を2つに分けています。

• getL1Fee(bytes)：完全にシリアライズした取引について、正確なL1手数料を返す。署名前の詳しい見積もりに使える
• getL1FeeUpperBound(uint256)：おおよそのバイト長から上限を返す。取引ができあがる前の上限管理に使える

（Base Network Fees、2026年9月24日確認）

取引ごとのレコード

{
  "chain_id": 8453,
  "tx_hash": "0x…",
  "operation": "settlement",
  "tenant_budget_key": "hashed-or-internal-id",
  "submitted_at": "…",
  "confirmed_at": "…",
  "status": "success|revert|dropped|replaced",
  "l2_execution_wei": "…",
  "l1_data_wei": "…",
  "operator_fee_wei": "…",
  "estimated_total_wei": "…",
  "retry_of": "0x…|null",
  "quote_source": "…",
  "collector_version": "…"
}

集計キーは chain_id × operation × payer × environment × time_bucket（チェーン、業務操作、支払者、環境、時間帯）です。これで cost per attempted tx（試行1件当たり費用）と cost per successful operation（成功した業務1件当たり費用）を出します。

置き換え取引は、nonce、業務上の冪等性キー、retry_of で元の取引と結びます。冪等性キーは、同じ要求を何度送っても1回分として扱うための識別子です。

XTELAができること

XTELAは、L2を使うアプリや独自チェーンについて、費用計測のデータモデル、取引とバッチの照合、ダッシュボード、アラート、予算の制御、障害時の手順書を設計し、PoCと開発まで行います。貴社の「今月いくらかかりそうか」を、取引単位の根拠から説明できる状態をつくります。L2の費用管理について相談する

主要参考資料

• Optimism Docs: Transaction fees on OP Mainnet（2026年9月24日確認）
• Optimism Docs: Fee vaults
• Base Docs: Network Fees（2026年9月24日確認）
• EIP-4844: Shard Blob Transactions
• ethereum.org: Optimistic Rollups
• Ethereum RIG: EIP-4844 Economics and Rollup Strategies

資料の確認日と注意

最終確認日は2026年9月24日（OPの手数料構成とBaseの見積もり関数。そのほかの資料は2026年8月12日確認）です。手数料の計算式、料金パラメータ、RPCの応答、ネットワークのアップグレードは変わるため、実装時は対象チェーンと利用するブロック範囲の公式仕様を確かめてください。