CI の超過課金とは何か？無料枠を超えて支払う

超過課金とは、CI の使用がそのサイクルの含まれる割り当てを超えた時点で発生する、分あたりおよびギガバイトあたりの課金です。

含まれる割り当ての範囲内では CI は無料に感じられますが、それを超えた瞬間に、追加の1分ごと、1ギガバイトごとが従量課金されます。その切り替わりが超過課金であり、静かに累積していくため、CI 請求額の驚きの最大の原因となっています。

超過はどう始まるか

超過は、そのサイクルの含まれる分数またはストレージを使い切った瞬間に始まります。その時点から、各分は runner のサイズと OS に応じた標準料金で課金され、追加のストレージ1ギガバイトごとにギガバイト月単位で課金されます。

超過は請求サイクル内で累積し、サイクルがリセットされると同時にリセットされます。自動的に行われるため、月の早い段階で一線を越えた使用は、リセットまで課金を積み上げ続けます - これが、小さな日々の超過が大きな請求書になる仕組みです。

よくある落とし穴は、より大きな runner（無料枠がなく、最初の1分から課金される）と、想定よりはるかに速く割り当てを使い切る macOS/Windows の倍率です。「無料」だった pipeline が、runner の種類を変えただけで重い超過に切り替わることがあります。

支出上限は、サイクルごとに許可する超過額を制限し、それに達すると以降の従量課金 workflow がブロックされます。上限をペース警告と組み合わせることで、workflow が止まってからではなく止まる前に対応できます。

持続的な解決策は、従量課金される分数を減らすことです - cache を使い、flaky な再実行を止め、runner を適正サイズにし、重い作業を Linux に保ちます。無駄が減れば、超過に入るのがサイクルの後半になるか、まったく入らなくなります。

超過が避けられないとき、重要なのは料金です。Latchkey のマネージド runner は超過を GitHub ホスト型より約70%低い料金で計上し、独自の無料分を含むため、同じ超過使用がはるかに安く済み、自己修復により flaky な再実行が超過を水増しするのを防ぎます。