ガス代とは、オンチェーン操作の料金計算の対象となる使用量に実効単価を掛けた費用です。通常のEthereumメインネット取引では、必要資金をガス上限と最大単価で確認し、実費は実行記録であるレシートで確かめます。Ethereum.org「Gas and fees」もこの違いを説明しています。見積もりは取り込みや成功を保証しません。失敗時も、ブロック取り込み前の拒否と、取り込み後の実行取り消しを分けます。
ウォレットでは0.0032 ETHを用意するよう表示されたのに、実際には0.001404 ETHしか使わなかったとします。ETHはEthereumのネイティブ資産です。差額はどこへ行ったのでしょうか。別の取引は失敗したのに、なぜ手数料が発生したのでしょうか。上限、使用量、失敗原因を混同すると、上限を増やせば必ず多く払う、失敗すれば必ず返る、という逆方向の誤解につながります。
単位を分け、同じ仮定値で必要資金と実費を計算した後、一つだけ条件を変えて待機と失敗の分岐を確認します。「最速」を選ぶ前に、各欄の意味を理解しましょう。
ガス使用量とETH建ての費用を区別する
ガスは計算作業量を測り、ETH建ての手数料はその作業に払う金額です。 間には一単位当たりの価格があります。Gas LimitをETHの金額と扱ったり、単価だけで全操作の安さを判断したりしてはいけません。
本記事はEthereumメインネットの通常のEIP-1559取引について、実行手数料だけを計算します。EIP-1559は基本料金、優先料金、最大単価を区別する料金方式です。例では送信アカウント自身が払い、第三者による手数料負担は扱いません。送受金全体の順序は暗号資産ウォレットの基本で確認できます。
Gas Limitは作業量の上限、Gweiは単価の単位
Gas Limitはその取引が使えるガスの最大量です。Gas Usedは最終的に料金計算へ含まれる使用量です。GweiはETHの小額単位で、1 Gweiは10億分の1 ETHです。使用量50,000、実効単価20 Gweiなら、50,000 × 20 ÷ 10億＝0.001 ETHになります。
複雑な操作は多くの作業を要する場合があり、ネットワーク需要の増加は単価を変える場合があります。Ethereum.org「Gas and fees」は、この二つを分けて説明しています。通常のETH送金、トークン送金、多段階のコントラクト操作に同じ固定上限を使わず、見積もりエラーを数値だけ下げて無理に安くしないでください。
最大単価と優先料金上限は同じものではない
Base Feeはプロトコルが決める基本単価、Max Priority Feeは追加で払う優先単価の上限、Max Feeは全体の一単位当たり最大単価です。後二つはEIP-1559のmaxPriorityFeePerGasとmaxFeePerGasに対応します。二つの上限を加算して、さらに払える合計単価と考えてはいけません。
元のEIP-1559仕様では、Max FeeがそのブロックのBase Fee以上で、かつMax Priority Fee以上であることを先に求めます。その条件下で、実効優先料金は「優先料金上限」と「Max Fee − Base Fee」の小さい方です。それにBase Feeを足して実効単価を求めます。最大単価までの余地が少なければ、設定した優先料金を満額払えるとは限りません。仕様の確認日は2026年10月27日です。以下で数値を代入します。
必要資金を先に計算し、実費はレシートで確認する
事前の資金確認は取引の上限、実費の照合は取り込み後のレシートを使います。 残高0.004 ETHのアカウントが、ネイティブETHを送らないトークンコントラクト操作を行うと仮定します。Gas Limitは80,000、Max Feeは40 Gwei、Max Priority Feeは2 Gweiに固定します。取り込みブロックのBase Feeを25 Gwei、最終Gas Usedを52,000と仮定します。実際の送信もレシートもありません。
手順1：一件のコントラクト操作の入力値を固定する
送信前の上限は80,000 × 40 Gwei＝0.0032 ETHです。残高0.004 ETH、送るネイティブETHはゼロなので、この資金確認は通過します。ETH自体も送る場合は送金額を加え、手数料だけで確認しないでください。
この計算が答えるのは、上限条件で資金が足りるかです。実際の支払い額や取り込み成功は保証しません。見積もりは実行状態にも左右されます。見積もりエラー、コントラクト不明、操作内容不明なら原因を調べ、残高に収めるために安全余裕を削らないでください。
手順2：小さい方の値から実効単価を求める
最大単価40から基本単価25を引くと15 Gwei残ります。優先料金上限2と比べ、小さい2を選びます。実効単価は25＋2＝27 Gweiであり、40＋2でも40全額でもありません。
式では、実効優先料金＝min（2、40－25）＝2、実効単価＝25＋2＝27です。minは小さい方を選ぶ意味です。25は仮定した取り込みブロックの条件であり、実送信前の古い画面から、後でも同じ数値になるとは保証できません。
手順3：実際の使用量で料金を照合する
成功したと仮定し、レシートのGas Usedが52,000、実効単価が27 Gweiなら、実行手数料は52,000 × 27 ÷ 10億＝0.001404 ETHです。ほかのETH移動がない条件では、残高は0.002596 ETHになります。
0.0032は事前上限、0.001404は仮定の実費です。差は0.001796 ETHですが、引き算だけで独立した返金取引があったとは記録できません。プロトコルには未使用ガスなどの精算規則があり、画面表示も異なり得ます。レシートと実残高で照合し、上限全額がすでに引かれたと決め付けて差額を別送金として追加しないでください。
同じ費用を分けると、基本部分は52,000 × 25 Gwei＝0.0013 ETH、優先部分は52,000 × 2 Gwei＝0.000104 ETHです。合計は同じ0.001404です。内訳を示しただけなので、合計へもう一度足して二重計上しません。
ネイティブETHを送っていないから、最初の0.004から実費だけを引けます。ETHを相手へ払う取引なら送金額も別途引きます。トークン数量の変化も別に確認し、ガス代をトークン取引の利益や損失と混同しないでください。
手順4：一つの欄だけ変えて結果を比べる
Gas Limitだけを120,000へ上げ、仮定の実使用量52,000と実効単価27 Gweiを据え置きます。事前上限は0.0048 ETHへ増え、固定残高0.004 ETHを超えます。この分岐は停止し、送信可能や完了とは記録しません。 別の純粋な算式比較として52,000 × 27 Gweiは同じ0.001404 ETHですが、この掛け算で資金不足の取引が実行可能になるわけではありません。作業上限を増やすことと実際の作業量が増えることは別です。
次は80,000へ戻し、仮定のBase Feeだけを39 Gweiへ変えます。最大単価まで残り1なので、優先料金はmin（2、1）＝1、実効単価は40です。同じ52,000使用なら0.00208 ETHになります。これは別の並行例で、前の27 Gweiの結果を上書きしません。
取り込み候補ブロックのBase Feeが41なのにMax Feeが40なら、そのブロックの単価条件を満たしません。元の取引、見積もり、ウォレットの処理を調べます。Gas Limitを上げても単価不足は解消せず、どれか一項目を変えればすぐ処理されるとも保証できません。
失敗した段階で手数料の扱いは変わる
ブロックに入る前の拒否と、取り込まれてからの実行失敗では料金が異なります。 Ethereum.org「Gas and fees」は検証での拒否と実行中のガス不足を区別しています。赤い「失敗」表示を全部同じ料金規則で扱ってはいけません。
取り込み前の拒否とオンチェーンのREVERTを分ける
有効性条件を満たさず、取り込み前に拒否された場合、料金を課すオンチェーン実行量はありません。これは実行手数料の話で、サービス独自の手数料まで推論しません。ウォレットの表示だけでなく、レシートと取り込み記録があるか調べます。
取り込み後にコントラクトがREVERT、つまり実行を取り消した場合、予定した操作の状態変更は戻りますが、使った計算資源には料金が発生し得ます。同じ27 Gweiで、失敗までの料金計算の対象となる使用量を30,000と別途仮定すると0.00081 ETHです。目的の結果が得られなくても、計算が行われなかったわけではありません。
ガスを使い切った失敗は別の分岐として計算する
実行中に80,000の上限を使い切るOut of Gasなら、同じ27 Gweiで0.00216 ETHです。30,000のREVERTとは別の仮定分岐で、両方を一件の費用として加算しません。すべての失敗が上限全量を消費するわけでもありません。
再試行前に、ガス量不足、コントラクト条件不成立、資金不足、単価条件不適合のどれかを調べます。Gas Limitを増やしてもコントラクトの条件違反は自動解消せず、繰り返すと追加費用になり得ます。
画面の最安値だけでは判断できない理由
安さは、同じネットワーク、操作、許容する待ち時間で比較します。最小の数値だけを選ぶと受取経路を変えたり、実行可能な操作を失敗しやすい入力に変えたりすることがあります。
低い上限・変わる見積もり・処理待ちを分ける
Gas Limit不足は実行未完了につながる場合があります。単価上限の不適合は取り込みに影響します。単位が違うので、変更前にどの欄か確認します。送信済みで待機中なら元の取引を調べ、同じ支払いをすぐ二件目で行いません。
同じ操作でもネットワーク需要やコントラクト状態で見積もりは変わります。比較時点の条件を残し、今日の低料金を昨日払うべき値として書き戻さないでください。ここで使う仮定値も現在の見積もりではありません。
別ネットワークでは費用モデル全体を確認し直す
Ethereumメインネットの一つの実行費式を、すべてのレイヤー2の総費用として使えません。レイヤー2は主ネットワークの処理能力を拡張する別の層です。OP Mainnet公式「Transaction fees」はデータ料金や、該当設定での運営者料金も分けています。確認日は2026年10月27日です。Gwei欄一つでなく、そのネットワークの完全な見積もりを比較します。
安い経路でも受取側がその資産とネットワークをサポートする必要があります。不一致は差額以上の問題になり得ます。送金ネットワークと着金確認で受取条件も照合してください。
予定を崩さず不要な費用を減らす
必要のない重複操作を減らす方が、各上限をむやみに下げるより先です。何を完了させたいかを理解し、必要な署名と取引を選びます。一回の料金を惜しんで不明な権限を受け入れないでください。
承認が必要な理由を理解して重複を避ける
アプリによっては承認と後のトークン利用が別になり、取引が一件とは限りません。各操作に料金がかかるかは方式次第です。EIP-2612のPermitでは、署名、nonce（再利用を防ぐ値）、期限などを満たせば、後から他人がオンチェーンへ提出できます。署名時にガス代がないだけで、単なるログインだと考えてはいけません。
反対に、承認回数を減らすため未知の相手へ無制限額を与えるのも適切ではありません。料金と権限は別の判断です。トークン承認と取り消しで権限を確認してください。ここでの計算は署名内容の正当性を保証しません。
見積もり・上限・実費を別欄に記録する
送信前見積もり、ガスと単価の上限、取引識別子TxID、取り込み後の使用量と実効単価を分け、ETH残高を照合します。レシートがなければ実費は未確認とし、不明をゼロと書いたり、上限を実際の支出にしたりしません。本例は「残高0.004、上限0.0032、仮定実費0.001404、精算後0.002596」です。最初が開始時点、次が事前制約、後二つが仮定の完了分岐です。待機中なら最初の二つと元の識別子だけを残し、完了後残高を先に埋めません。
レシートでは識別子、ネットワーク、成功状態も元の操作と照合します。近い料金の取引が見つかっても自分の取引とは限りません。使用量と実効単価は同じ取り込み済み取引から取得します。見積もりだけしかないなら待機として残し、本記事の仮定値を実際の帳簿へ代入しないでください。
本記事は料金の仕組みと仮定計算の学習用で、投資助言ではありません。すべての金額と単価は仮定です。実際のネットワーク、操作、手数料負担方式は異なり、見積もりは取り込み、成功、固定費用を保証しません。