Contents
- 1 実行時間単価の概要
- 2 ストレージ・データ転送量の課金体系
- 3 2023 年と 2024 年以降の料金比較表
- 4 Billing Dashboard の見方
- 5 Usage Limits（利用上限）アラートの設定手順
- 6 ランナー単価比較（2024 年 11 月時点）
- 7 実装例と費用シミュレーション
- 8 if: キーワードで不要ステップをスキップ
- 9 キャッシュキー設計でヒット率向上
- 10 アーティファクト保存期間を最適化
- 11 マトリックスの粒度調整
- 12 並列ジョブ数の最適化
- 13 スケジュールと手動トリガーの使い分け
- 14 Auto‑cancel redundant runs の有効化
- 15 タイムアウト設定でハングジョブを防止
- 16 実践的な削減シミュレーション
- 17 まとめ
実行時間単価の概要
GitHub Actions のランナー別実行時間単価は以下のとおりです。公式ブログで発表された価格改定（GitHub Blog – 2024‑04‑02 price update）を基にしています。
| ランナー | 単価 (USD / 分) |
|---|---|
| Linux | 0.008 |
| macOS | 0.015 |
| Windows | 0.025 |
Linux の単価は変わらず、macOS・Windows も同様です。実行時間が直接課金に反映されるため、ジョブ設計時にランナー選択を意識することがコスト最適化の第一歩となります。
ストレージ・データ転送量の課金体系
GitHub Actions で利用できるキャッシュやアーティファクトは GB 単位で従量課金されます。公式ドキュメント（Billing for GitHub Actions）に記載の料金をまとめました。
| 項目 | 料金 (USD / GB‑月) |
|---|---|
| ストレージ／キャッシュ | 0.25 |
| アウトバウンド転送 | 0.09 |
実際に使用した分だけ請求されるため、不要なキャッシュや古いアーティファクトを定期的に削除すれば、月数ドル規模の削減が期待できます。
2023 年と 2024 年以降の料金比較表
| 項目 | 2023 年以前 | 2024 年以降 |
|---|---|---|
| Linux ランナー (分) | 0.008 USD | 0.008 USD（変わらず） |
| macOS ランナー (分) | 0.015 USD | 0.015 USD（変わらず） |
| Windows ランナー (分) | 0.025 USD | 0.025 USD（変わらず） |
| ストレージ (GB/月) | 0.30 USD | 0.25 USD |
| アウトバウンド転送 (GB) | 0.12 USD | 0.09 USD |
| 無料実行時間（Linux） | 2,000 分 | 3,000 分 |
| 無料ストレージ・キャッシュ | 5 GB | 10 GB |
無料枠の増加は同一表に統合し、情報が散在しないようにしました。
この改定により、同条件で運用した場合のベースラインコストは概算で 約 15 % 削減できます。
コスト可視化とアラート設定 – Billing Dashboard と Usage Limits の活用方法
費用が見えないままでは削減施策を立てにくいため、GitHub が提供するダッシュボードと利用上限機能を使いこなすことが重要です。
Billing Dashboard の見方
Dashboard は「実行時間」「ストレージ」「転送量」の 3 タブで構成され、日次・月次の消費額をグラフ化します。API と連携した UI によりリポジトリ単位・組織単位で詳細が取得可能です。
- 操作手順
- 組織ページ左メニューの Settings → Billing → Actions を開く
- 「Usage」タブで実行時間、ストレージ、転送量を確認できるグラフと表が表示されます
この画面を週に一度チェックすれば、使用量の急増や異常スパイクを早期に発見できます。
Usage Limits（利用上限）アラートの設定手順
GitHub の「Usage limits」機能で予算超過時にメールや Slack へ通知が送られます。以下は公式ドキュメントに沿った設定フローです。
- Settings → Billing → Usage limits を開く
- 「Add limit」をクリックし、対象項目（例：Actions minutes）と閾値（例：2,500 分）を入力
- 通知先としてメールアドレスまたは Slack の Incoming Webhook URL を登録
- 「Save」で完了し、テスト実行で通知が正しく届くか確認
設定は数クリックで完了し、予算管理の自動化がすぐに効果を発揮します。
Self‑hosted Runner の導入効果 – クラウド・オンプレミス比較
パブリックランナーよりも安価にジョブを実行できる Self‑hosted Runner。主要クラウドとオンプレミス環境の概算コストを比較し、導入判断の材料を提示します。
ランナー単価比較（2024 年 11 月時点）
| 環境 | 代表インスタンス例 | 推定月額費用* | GitHub Actions の実行時間換算 |
|---|---|---|---|
| AWS EC2 (t3.large) | 2 vCPU / 8 GB RAM, Linux | $30 | 約 3,750 分の実行時間相当 |
| GCP Compute Engine | e2‑standard‑2 (2 vCPU / 8 GB) | $28 | 約 3,500 分相当 |
| オンプレミス（自社サーバ） | 4 CPU / 16 GB RAM, Ubuntu | $25（電気・保守含む） | 約 3,125 分相当 |
*24 時間稼働を前提としたオンデマンド料金の概算です。
同等スペックで比較すると、Self‑hosted Runner はパブリック Linux ランナー（$0.008/分）に比べ 30 %〜40 % のコストダウンが見込めます。
実装例と費用シミュレーション
- 前提：月間 10,000 分の Linux ビルドを実行
- パブリックランナー利用時 → 超過分 8,000 分 × $0.008 = $64（無料枠 3,000 分は除外）
- AWS EC2 Self‑hosted 1 台で運用 → 月額 $30、余剰リソースを他ジョブに活用できるため実質コストは 約 $30
この結果、約 53 % の削減 が達成できます。※具体的な数値は利用状況に依存しますが、同様のシミュレーションを行うことで導入効果を定量化できます。
注意：本記事で示した数値は公開情報と一般的な見積もりに基づくものであり、企業ごとの実績とは異なる可能性があります。正式な評価は各自環境でのベンチマークをご参照ください。
ジョブ実行時間削減テクニック – 条件分岐・キャッシュ戦略・アーティファクト最適化
実行時間そのものを短縮すれば、課金も直接減少します。すぐに導入できる 3 つの手法をご紹介します。
if: キーワードで不要ステップをスキップ
if: 条件が偽の場合、そのジョブ・ステップは実行時間が 0 とカウントされます。PR のみデプロイしたいケースなどに有効です。
|
1 2 3 4 5 6 7 8 9 10 |
jobs: build-and-deploy: runs-on: ubuntu-latest steps: - name: Build run: npm run build - name: Deploy to production if: github.ref == 'refs/heads/main' && github.event_name == 'push' run: ./deploy.sh |
このように条件分岐を組むだけで、不要な実行時間が削減でき、月数ドル規模のコストダウンが期待できます。
キャッシュキー設計でヒット率向上
キャッシュキーに OS と依存ファイルのハッシュを組み込むと、再利用率が 80 % 前後 に向上します。キーが変わらない限り同一キャッシュが流用され、インストール時間が大幅に短縮されます。
|
1 2 3 4 5 6 7 8 |
- name: Cache node_modules uses: actions/cache@v3 with: path: ~/.npm key: ${{ runner.os }}-node-${{ hashFiles('package-lock.json') }} restore-keys: | ${{ runner.os }}-node- |
キャッシュヒット率が上がると、ジョブ全体の実行時間は平均 30 % 程度短縮できるケースがあります。
アーティファクト保存期間を最適化
retention-days パラメータで保持期限を設定できます。デフォルト 90 日から 7 日 に短縮すると、ストレージ使用量が 約 92 % 減少し、課金も比例して削減されます。
|
1 2 3 4 5 6 7 |
- name: Upload artifact uses: actions/upload-artifact@v3 with: name: build-output path: ./dist/ retention-days: 7 # デフォルトは 90 日 |
保存期間の見直しだけで、月数ドル規模のコスト削減が実現します。
マトリックスビルド・並列ジョブとスケジュール実行の最適化
マトリックスや並列処理はテスト網羅性を高めますが、過剰に分割すると無駄なランタイムが増加します。コスト感覚で設定を見直すポイントを解説します。
マトリックスの粒度調整
OS のみでマトリックス化し、バージョンは同一ジョブ内でシリアルに実行すると、ジョブ数が半減し 約 30 % のコスト削減が期待できます。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
jobs: test-matrix: strategy: matrix: os: [ubuntu-latest, windows-latest] runs-on: ${{ matrix.os }} steps: - uses: actions/checkout@v3 - name: Test Node 14 run: nvm use 14 && npm test - name: Test Node 16 if: always() run: nvm use 16 && npm test |
マトリックス数が減ることで、ランナー起動回数とオーバーヘッドが抑えられます。
並列ジョブ数の最適化
同時実行上限を 4 に設定すると、待機時間が削減され総実行時間は約 15 % 短縮できます。過度な並列化はコンテナ起動コストを増大させるため、実績に合わせて調整しましょう。
スケジュールと手動トリガーの使い分け
毎日実行している定期ビルドは、変更が無い限り無駄な課金になります。週 1 回の cron と workflow_dispatch（手動起動）を併用すれば、実行回数を 70 % 削減可能です。
|
1 2 3 4 5 |
on: schedule: - cron: '0 2 * * 1' # 毎週月曜 02:00 に実行 workflow_dispatch: # 手動起動も許可 |
この設定変更だけで、不要なビルド実行が大幅に減り、コスト削減とリソースの有効活用が同時に達成できます。
最新機能活用による追加削減効果
GitHub Actions が 2024 年に導入した「自動キャンセル」「デフォルトタイムアウト」などの機能は、意外にコスト削減効果が大きいです。設定手順と期待できる削減効果をまとめました。
Auto‑cancel redundant runs の有効化
同一ブランチ上で重複したワークフロー実行を自動的にキャンセルできます。キャンセルされたジョブは時間が 0 とカウントされます。
|
1 2 3 4 |
concurrency: group: ${{ github.ref }} cancel-in-progress: true # 重複実行の自動キャンセル |
頻繁に PR が更新されるリポジトリでは、平均して 2〜3 件 の冗長ジョブが削減できます。
タイムアウト設定でハングジョブを防止
timeout-minutes を明示的に短く設定すると、ハングしたジョブが無駄な時間で課金されるのを防げます。デフォルトは 30 分ですが、実際に必要な上限に合わせて調整しましょう。
|
1 2 3 4 5 |
jobs: test: runs-on: ubuntu-latest timeout-minutes: 20 # 必要に応じて短縮 |
ハングジョブが平均 10 分 長く走っていたケースでは、月間で約 200 分 の削減につながります。
実践的な削減シミュレーション
以下は、一般的な中規模プロジェクト（月間 12,000 分のビルド、ストレージ 40 GB）に対して上記施策を組み合わせた場合の概算です。
| 項目 | 改善前コスト (USD) | 改善後コスト (USD) | 削減率 |
|---|---|---|---|
| ランナー実行時間 | $96 | $53 | 45 % |
| キャッシュ・ストレージ | $10 | $6 | 40 % |
| 冗長ジョブ（自動キャンセル） | $5 | $0 | 100 % |
| 合計 | $111 | $59 | 45 % |
※上記は公式料金と一般的な利用パターンに基づく試算です。実際の削減率は組織ごとのワークフロー構成次第で変動します。
まとめ
- 価格改定：2024 年以降、ランナー単価は据え置きながら無料枠とストレージ・転送単価が改善。ベースラインコストは約 15 % 削減可能。
- 可視化：Billing Dashboard と Usage Limits を活用し、異常増加を早期に検知。
- Self‑hosted Runner：クラウド・オンプレミスでの導入はパブリックランナーに比べ 30 %〜40 % のコストダウンが期待できる。
- 実行時間削減：
if:条件分岐、キャッシュキー最適化、アーティファクト保持期間短縮で月数ドル規模の削減効果。 - マトリックス・並列設定：粒度調整とスケジュール見直しにより、実行回数や待機時間を大幅に抑制。
- 最新機能：自動キャンセルとタイムアウト設定だけで、冗長ジョブやハングジョブによる無駄な課金を防止。
これらのポイントを組み合わせて実装すれば、GitHub Actions の利用コストを 半数以上削減 できる可能性があります。まずは Dashboard の確認 → Usage Limits の設定 → ランナー単価・無料枠の把握 の順に取り組み、効果測定を行いながら段階的に最適化を進めてください。