公開2026.08.18更新2026.09.27 39 人が閲覧（直近 30 日） CI/CD

GitHub Actionsの料金｜2026年改定後の分単価・無料枠とコスト削減の判断基準

GitHub Actionsの請求は「実行時間×ランナー種別の分単価」と「ストレージの時間按分」という二本立てで決まります。2026年1月1日に価格が改定され、公式ドキュメントの記載も倍率表からSKUごとの分単価へ整理されました。この記事では2026年9月時点の公式ドキュメントとGitHubの変更履歴を一次情報として、無料枠の範囲・実額の分単価・月額の計算式・使用量をAPIで取り出す手順・費用を下げる打ち手を整理します。ワークフローにそのまま貼れる設定例も併せて載せました。

まとめ：2026年改定後の料金体系と無料枠で押さえる要点

結論から示します。パブリックリポジトリの標準ランナーは無制限に無料で、セルフホストランナーも2026年9月時点では無料のままです。課金されるのはプライベートリポジトリで標準ランナーを回した場合と、大型ランナーを使った場合の2つです。プライベートでの実行は無料枠（Freeで月2,000分、Teamで3,000分、Enterprise Cloudで50,000分）を消費し、超過分だけが分単価で請求されます。

分単価はLinux 2コアが0.006ドル、Windows 2コアが0.010ドル、macOS 3〜4コアが0.062ドル、Linux 1コアの軽量ランナーは0.002ドルです。同じ処理でもランナーの選び方だけで単価は30倍以上ひらきます。費用を下げる順序は、ランナー種別の見直し→同時実行の打ち切りとパス絞り込み→キャッシュと成果物の保管期間の調整、の順で効きます。セルフホストへの移行を検討する目安は、月額300ドルを超え、かつジョブの大半がLinuxである場合です。まず手を動かすなら、後述のREST APIでSKU別の実績を1か月分取り出すところから始めてください。

GitHub Actionsで課金が発生する条件と無料で使える範囲

まず請求書に載る条件を切り分けます。ここを取り違えたまま試算すると、無料の実行まで原価に積んでしまいかねません。GitHub Actionsの基本的な仕組みと使い方を先に押さえておくと、課金単位の話が読みやすくなります。

パブリックリポジトリとセルフホストランナーが無料になる実際の範囲

GitHub Actionsの課金に関する公式ドキュメントは、標準のGitHubホストランナーが無料になる対象として、パブリックリポジトリ、GitHub Pages、Dependabotの3つを挙げています。パブリックリポジトリでは実行時間の上限もありません。2025年にパブリックプロジェクトで消費された時間は合計115億分、約1億8,400万ドル相当が無料で提供されたとGitHubは公表しています。

セルフホストランナーは、2026年3月1日から1分あたり0.002ドルを課金する計画が発表されたものの、2025年12月18日に延期が公表され、2026年9月時点でも適用されていません。同ドキュメントの記載も「セルフホストランナーは無料」のままです。撤回ではなく再検討である点は試算の前提に入れてください。なお大型ランナーは例外で、パブリックでも無料枠が残っていても常に課金対象になります。

GitHub Actionsの課金がリポジトリのオーナーに請求される原則

実行時間の費用は、ワークフローを起動した人ではなくリポジトリのオーナーに請求されます。書き込み権限があれば誰でも回せるため、外部委託メンバーの実行分もオーナー側の枠から引かれます。

受託開発では、開発期間中は受託側のOrganizationにリポジトリを置き、納品時に発注側へ移管する進め方をよく採ります。この移管で課金先も切り替わる点は見落とされがちです。移管先がFree（月2,000分）だった場合、受託側のTeam（月3,000分）で回っていたCIがそのまま動くと、初月から枠を超えて請求が立ち上がります。

実行時間の切り上げとストレージの時間按分という二つの計測方法

実行時間はジョブ単位で計測され、1分未満の端数は1分に切り上げられます。10秒で終わるlintジョブも1分として計上されるため、細かく分割しすぎると切り上げの積み重ねが効いてきます。途中で失敗したジョブは失敗までの時間が計上され、再実行分は別途加算という扱いです。

ストレージ側は時間按分です。公式ドキュメントは請求が「月を通じて使用した総量をGB-Hoursで測ったもの」だと説明しており、3GBを10日間×24時間保持すれば720 GB-Hoursという計算例を挙げています。月末に月の総時間数で割ってGB-Monthsへ換算する仕組みです。成果物を月の途中で削除すると現在の使用量はすぐ減りますが、その月に積み上がった分は請求から消えません。削除は将来の発生を止めるだけの操作だと考えてください。

プラン別に付与される無料枠とランナー別の分単価を実額で押さえる

ここからが実額です。数字は2026年9月時点の公式ドキュメントに合わせています。料金は改定されうるため、見積書に載せる際は同じページを都度確認してください。

Free・Pro・Team・Enterprise Cloudの無料枠を並べて比べる

プライベートリポジトリの無料枠は、実行時間・成果物ストレージ・キャッシュ・カスタムイメージ保管の4系統に分かれます。実行時間は毎月の請求サイクル開始時にゼロへ戻り、ストレージの累積課金も同時にリセットされます。

プラン	実行時間（月）	成果物ストレージ	キャッシュ	カスタムイメージ
GitHub Free	2,000分	500MB	10GB	対象外
GitHub Pro	3,000分	1GB	10GB	対象外
GitHub Team	3,000分	2GB	10GB	75GB
Enterprise Cloud	50,000分	50GB	10GB	150GB

キャッシュの10GBはアカウント単位ではなくリポジトリ単位の枠です。成果物ストレージはGitHub Packagesと枠を共有するため、コンテナイメージを同じOrganizationで保管しているなら、その分だけActions側の余地が減ります。大型ランナー向けのカスタムイメージ保管は別枠で、TeamとEnterprise Cloudにだけ付与されます。

GitHub Actions標準ランナーの分単価はOSとコア数でどれだけ差が開くか

無料枠を超えた分は、ランナー種別ごとの分単価で課金されます。請求明細には課金SKU名が並ぶため、公式のランナー価格リファレンスのSKU名も併記しておきます。

ランナー	課金SKU	分単価（USD）
Linux 1コア（x64）	actions_linux_slim	0.002
Linux 2コア（x64）	actions_linux	0.006
Linux 2コア（arm64）	actions_linux_arm	0.005
Windows 2コア（x64）	actions_windows	0.010
Windows 2コア（arm64）	actions_windows_arm	0.010
macOS 3〜4コア	actions_macos	0.062

ワークフローラベルとの対応も押さえておきます。GitHubホストランナーのリファレンスによれば、プライベートリポジトリのubuntu-latestとwindows-latestは2コア・メモリ8GB、macos-latestはM1の3コア・メモリ7GB、ubuntu-slimは1コア・メモリ5GBです。パブリックリポジトリではubuntu-latestとwindows-latestが4コア・メモリ16GBに上がります。非公開へ移して実行時間が伸びたら、まずコア数の違いを疑ってください。

大型ランナーとGPUランナーが無料枠の対象外になるという扱い

大型ランナーはTeamとEnterprise Cloudのみで使え、無料枠を消費できません。1分目から全額課金です。x64のLinuxは4コアのlinux_4_coreが0.012ドル、96コアのlinux_96_coreが0.252ドルまであり、Windowsは同じコア数でおおむね倍近く（windows_4_coreが0.022ドル、windows_96_coreが0.552ドル）になります。arm64版は一段安く、linux_4_core_armが0.008ドル、linux_64_core_armが0.098ドルです。

macOSの大型は12コアのmacos_lが0.077ドル、5コアのM2 Proであるmacos_xlが0.102ドル。GPU付きはlinux_4_core_gpuが0.052ドル、windows_4_core_gpuが0.102ドルという価格帯です。支払い方法が未登録なら、大型ランナーは最初からブロックされます。

ストレージ超過の単価が成果物とキャッシュで別建てになっている点

ストレージ側の超過単価は3系統で異なります。成果物とGitHub Packagesが共有する枠は1GB月あたり0.25ドル、Actionsキャッシュとカスタムイメージ保管はどちらも0.07ドルです。成果物が最も高く、キャッシュの3.5倍以上の単価になります。

枠を共有する構造上、コンテナレジストリの使い方がActions側の請求に効いてきます。イメージの保管量とタグの整理方針はGitHub Container Registry（ghcr.io）の料金と無料枠の条件で整理しているので、Packages側の消費が読めていないなら先にそちらを確認してください。なおキャッシュは、リポジトリの保管上限を既定の10GBより高く設定している場合にだけ超過分が課金されます。

2026年1月の価格改定で変わった点とセルフホスト課金の現在地

料金を調べると、改定前の数字を載せた解説が今も多く残っています。どこが変わったのかを切り分けておきます。

最大39%の値下げとクラウドプラットフォーム料金の組み合わせ

2026年1月1日から、GitHubホストランナーの実質コストが最大39%引き下げられました。値下げを告知した変更履歴は、下げ幅がマシンタイプによって異なることと、パブリックリポジトリの標準ランナーが引き続き無料であることを明記しています。内訳は、全ランナーサイズに対する約40%の値下げと、新設された1分あたり0.002ドルのActionsクラウドプラットフォーム料金の合算です。この新料金はレートにすでに含まれているため、掲載されている分単価をそのまま使えば二重計上にはなりません。

値下げ幅は小型ほど小さく、大型ほど大きくなります。GitHubが公開した価格改定の解説によれば、全顧客の96%は請求額が変わらず、影響を受けた4%のうち85%は減額、残り15%の増加額の中央値は約13ドルでした。GitHub Enterprise Serverの価格は対象外です。

セルフホストランナーへの分単位課金が延期されたままである現状

同時に発表されたのが、セルフホストランナーへの1分あたり0.002ドルの課金です。2026年3月1日開始の予定でしたが、発表から48時間ほどでコミュニティの反発を受け、2025年12月18日にGitHubが延期を表明しました。当初の告知に追記された更新には「セルフホストのGitHub Actionsについて発表した課金変更を延期し、アプローチを再評価する時間を取る」と書かれています。2026年9月時点でも適用日は決まっていません。

試算では、現状の無料を前提にしつつ復活時の増分も併記しておくのが安全です。月10万分をセルフホストで回しているなら、0.002ドル換算で月200ドルの新規発生になります。この金額が運用の損益分岐を跨ぐかどうかは、移行判断の前に計算しておいてください。

旧来のWindows2倍・macOS10倍という倍率表記との読み替え

改定前のドキュメントは、Linuxを1としてWindowsが2倍、macOSが10倍という「分の倍率」で無料枠の消費を説明していました。2026年9月時点の公式ドキュメントに倍率表の記載はなく、SKUごとの分単価表に置き換わっています。

実額で読み替えると、Windows 2コアの0.010ドルはLinux 2コアの0.006ドルの約1.7倍、macOSの0.062ドルは約10.3倍です。macOSはほぼ従来どおりですが、Windowsは2倍より軽くなりました。無料枠についてGitHubは「リスト価格に基づいて枠を消費する」と説明しており、分数ではなく金額換算で減ると理解しておくと請求ダッシュボードと食い違いません。古い倍率のまま見積もっているなら、Windows側を過大に積んでいる可能性があります。

月額コストの見積もり計算とダッシュボードでの使用量の確認手順

単価がそろったので、見積書へ転記できる形で計算式と確認手順を示します。

受託開発の現場でそのまま使える月額コストの計算式と試算の手順

月額は次の3項目の合計で求められます。

ランナー種別ごとに「1回あたりの実行分（切り上げ後）×月間実行回数×分単価」を求めて合計する
合計から無料枠相当額を差し引く（枠はリスト価格ベースで消費される）
成果物とキャッシュの平均保管量から、超過分のGB月額を足す

まず主要ワークフローごとに直近1か月の平均実行時間と回数を洗い出します。プルリクエスト起点のジョブは開発人数とレビュー回数に比例するため、増員計画がある案件では人数の伸びを係数に掛けてください。

中規模の受託チームのCIを想定した月額コストの試算例をたどる

開発者6名、Teamプラン、プライベートリポジトリ、営業日22日という前提で試算します。プルリクエスト起点のテストが1日30回、1回8分、ubuntu-latestで走るなら、月間は30×8×22で5,280分。無料枠3,000分を引いた2,280分に0.006ドルを掛けて13.68ドルです。

ここにWindows向けのビルド検証を1日10回、1回6分足すと1,320分で13.20ドルの追加になります。さらにfastlaneを使ったiOSリリースの自動化のようなmacOSジョブを1日3回、1回12分回すと792分となり、0.062ドルを掛けて49.10ドルに達します。合計はおよそ76ドルで、その6割強をmacOSが占める計算です。実行回数が最も少ないOSが費用の主因になるという逆転が、見積もりの勘所になります。

REST APIで使用量サマリーをSKU別に取得して集計する手順

試算の精度を左右するのは、実績データをどれだけ細かく取れるかです。請求の使用量エンドポイントは、Organizationなら GET /organizations/{org}/settings/billing/usage で叩けます。year・month・day・product・sku・repository のクエリパラメータで絞り込めるため、Actions分だけを月単位で抜き出せます。

gh api -H "X-GitHub-Api-Version: 2022-11-28" \
  "/organizations/YOUR_ORG/settings/billing/usage?year=2026&month=8&product=actions"

認証には classic の個人アクセストークンが必要です。使用状況レポートの自動化チュートリアルは「請求の使用量エンドポイントはfine-grainedの個人アクセストークンをサポートしない」と明記しています。ここでつまずく例が多いので、先にトークン種別を確認してください。

Web UIからCSVで落とした場合の列名は請求レポートのリファレンスに載っています。date product sku quantity unit_type net_amount organization repository が共通列で、ワークフロー単位の workflow_path と username は詳細な使用状況レポートにだけ含まれます。詳細レポートはWebインターフェース限定で、REST APIからは取得できません。手元でSKU別・リポジトリ別に積み上げるなら、この列名をそのまま使って集計します。

import csv, collections

agg = collections.defaultdict(float)
with open("usage.csv", encoding="utf-8") as f:
    for row in csv.DictReader(f):
        if row["product"] != "actions":
            continue
        agg[(row["sku"], row["repository"])] += float(row["net_amount"])

for key, amount in sorted(agg.items(), key=lambda x: -x[1])[:10]:
    print(key, round(amount, 2))

上位10件を出すだけで、費用の8割を生んでいるリポジトリとSKUの組み合わせが見えます。削減の着手順を決める材料は、この一覧で足ります。

詳細な使用状況レポートと予算アラートで請求前に異常を捕まえる

画面から見る場合は、アカウント設定の「Billing and licensing」から使用状況を開きます。詳細な使用状況レポートはCSVで落とせて、ランナー種別・リポジトリ・ワークフロー単位まで分解できます。どのワークフローが枠を食っているかは、この粒度でしか分かりません。

予防側の設定が予算です。予算設定の手順によれば、「Budgets and alerts」から製品単位（Actions全体）でもSKU単位（Linux 96コアだけ、といった粒度）でも上限を置けます。「Stop usage when budget limit is reached」を有効にすると、上限到達時点でGitHubホストランナーの利用がブロックされます。有効にしない場合は実行が続き、メールで通知されるだけです。閾値アラートを選べば、予算の75%・90%・100%でメールとバナーが届きます。

あわせて無料枠の90%と100%で届くメール通知も残っています。支払い方法が未登録なら、枠を使い切った時点で実行そのものが停止します。本番デプロイがワークフロー経由なら、停止の副作用まで見てから設定を決めてください。

コスト削減の打ち手をランナー選択と実行制御と保管期間に分ける

削減策は、単価に効くもの、実行回数に効くもの、ストレージに効くものへ分けて、単価から順に潰していきます。

軽量ランナーへの切り替えで分単価を三分の一まで落とせるジョブの条件

最も効くのは単価の切り下げです。ubuntu-slimは1コア・メモリ5GBで分単価0.002ドル、ubuntu-latestの3分の1にあたります。1 vCPUランナーは2026年1月22日に一般提供へ移行し、パブリック・プライベートの両方で使えます。切り替えはラベルを差し替えるだけです。

jobs:
  lint:
    runs-on: ubuntu-slim
    timeout-minutes: 10
    steps:
      - uses: actions/checkout@v7
      - run: npx eslint .

ただし制約が2つあります。ubuntu-slimはフルVMではなくコンテナ内で動き、コンテナは非特権モードです。そして1コアランナーのジョブ上限は15分で、超えたジョブは打ち切られて失敗します。公式リファレンスも「自動化タスク・issue操作・短時間のジョブ向けであり、一般的な重いCI/CDビルドには向かない」と書いています。lint、静的解析、ドキュメント生成、通知系なら収まるはずです。制限と向くタスクの詳細は軽量ランナーUbuntu-slimの仕様と切り替え手順にまとめています。

arm64への切り替えも単価差を生みます。Linux 2コアはx64が0.006ドル、arm64が0.005ドルで、依存ライブラリがarm64のビルドを持つなら約17%下がります。逆に切り替えてはいけないのが、メモリを多く使うビルドやE2Eテストです。1コアで実行時間が2倍に伸びれば、単価が3分の1でも総額は増えます。切り替え後は実行時間を測り直してください。

concurrencyとパス絞り込みで無駄なワークフロー起動を止める

次は実行回数です。同じブランチへ連続でプッシュした際に古い実行を走らせたままにすると、破棄される結果のために課金されます。同時実行の制御は数行で入ります。

concurrency:
  group: ci-${{ github.ref }}
  cancel-in-progress: true

pathsフィルタも効きます。ドキュメントだけを直したプルリクエストでバックエンドのテストまで回っているなら、そのぶんは丸ごと無駄です。ワークフロー構文のリファレンスのとおり、同一イベントに対して paths と paths-ignore を同時指定はできないため、どちらか片方に寄せます。あわせて timeout-minutes も入れてください。

on:
  pull_request:
    paths:
      - 'apps/api/**'
      - '.github/workflows/api.yml'

jobs:
  test:
    runs-on: ubuntu-latest
    timeout-minutes: 20
    steps:
      - uses: actions/checkout@v7
      - run: npm ci && npm test

ジョブのタイムアウトは既定で360分です。無限ループに入ったジョブが6時間走り切ると、Linux 2コアでも1回2.16ドルの料金です。マトリックスの刈り込みも有効で、OSとバージョンの全組み合わせはマージ時だけに寄せ、プルリクエスト時は代表的な1組へ絞ります。ワークフロー自体をこれから組む段階なら、ビルドと自動テストのワークフローの作り方を先に読むと、絞り込みを初期設計へ織り込めます。

2026年6月追加のステップ並列実行でジョブ分割と切り上げを減らす条件

ジョブを細かく割ると、1分未満の切り上げとランナー起動の待ち時間が回数分だけ積み上がります。2026年6月25日にステップの並列実行が追加され、この分割を減らせるようになりました。background: true でステップを非同期に走らせ、wait または wait-all で合流させる形です。cancel でバックグラウンドのステップを終了でき、parallel は一群のステップをまとめて並列化する糖衣構文にあたります。

並列化そのものが安くなるわけではありません。効くのは、依存関係のない短いジョブを3本に割っていた構成を1ジョブへ束ね直したときです。1回3本×切り上げ1分の無駄が消え、ランナーの起動も1回で済む計算です。逆に、長時間のビルドを分けて実行時間を縮めたいなら、従来どおりジョブ分割のほうが並列度を稼げます。判断軸は所要時間で、目安として1本あたり2分未満のジョブが並んでいるなら束ね直す価値があります。

キャッシュと成果物の保管期間の見直しでストレージ課金を抑える

3つ目はストレージです。actions/cache による依存関係のキャッシュは実行時間を縮めるため、単価と回数の両面に効きます。ただしキャッシュ枠を既定の10GBより広げていれば、超過分は1GB月あたり0.07ドルの課金対象になります。

成果物のほうは保管期間の既定が90日です。actions/upload-artifactのリポジトリによると、retention-days は1〜90日の範囲で指定でき、0を渡すとリポジトリの既定値が使われます（上限はリポジトリ設定で変更可）。7日から14日程度へ縮めるだけで、GB-Hoursの積み上がりが大きく減ります。

- uses: actions/upload-artifact@v7
  with:
    name: build-output
    path: dist
    retention-days: 7

すでに溜まっている分は成果物の削除手順で消せますが、当月の請求は下がりません。単価がキャッシュの3倍以上である以上、着手は成果物が先です。

セルフホストや代替ランナーへ移す判断の分岐点を月額いくらに置くか

ここは条件を付けて言い切ります。月額50ドル未満（Linux 2コア換算でおよそ8,000分）の段階では、セルフホストへ移すべきではありません。構築・OS更新・障害対応の工数が削減額を上回ります。この規模なら、軽量ランナーへの振り分けとconcurrencyの設定だけで足ります。

月額300ドルを超え、かつジョブの大半がLinuxであれば移行の検討に入ります。セルフホストランナーの導入手順とhosted版との違いを踏まえ、運用工数を月あたり何時間見込むかを先に決めてください。運用を抱えたくない場合の中間解が、Blacksmithによる代替ランナーの仕組みと移行手順のような外部サービスです。ツールごと乗り換える選択肢まで含めて比べるなら、無料枠と料金で選ぶCI/CDツール比較で他サービスの条件も並べています。

一方、macOSのビルドが月2,000分を超える場合でも、セルフホスト化は勧めません。0.062ドル×2,000分で月124ドルですが、Mac実機の調達・設置・OS更新・Xcode管理を自前で持つと、初年度でこの金額を上回るのが通例です。macOSはGitHubホストのまま、ビルド回数を絞るほうが総額は下がります。

受託開発の現場でGitHub Actionsの費用が膨らむ典型と対処

ここからは、単価表を読んだだけでは避けられない失敗の型を挙げます。いずれも実案件で請求が跳ねやすい箇所です。

リポジトリの移管でオーナーが変わり請求先がずれてしまう事故の型

納品時のリポジトリ移管で課金先が変わる点は、契約書のどこにも書かれていないことが多い落とし穴です。受託側のTeamプラン（3,000分）で回っていたCIが、発注側のFreeプラン（2,000分）へ移ると、同じワークフローのまま枠が3分の2になります。

対処は2つです。移管前に直近3か月の実行分数を使用状況レポートで出し、移管先プランの枠に収まるかを確認すること。収まらないなら、プラン変更を提案するか、起動条件を絞る作業を納品スコープに含めることです。CI/CDの設計そのものを見直す段階なら、CI/CDの仕組みと導入判断の基準から前提をそろえ直すほうが早く片付きます。

モノレポで全ジョブが起動し無料枠を月の前半で使い切ってしまう失敗

フロントエンドとバックエンドと管理画面を1つのリポジトリに収めた構成で、pathsフィルタを設定しないまま運用すると、どこを直しても全ジョブが起動します。1回のプルリクエストで3系統×各5分が動けば15分、1日20回で300分、営業日22日で6,600分となり、Teamの3,000分は月の前半で尽きます。変更のあった系統だけを起動する設定に切り替えると実測で半分以下まで落ちるため、モノレポではパス条件の設計を初期構築の必須項目として扱ってください。

成果物の保管期間が既定の90日のままで課金が積み上がっていく状態

成果物は消さない限り時間按分で積み上がり続けます。1回のビルドで500MBの成果物が出て、1日10回、90日保管という条件だと、平均保管量は数百GB規模へ届きます。Teamの成果物枠は2GBなので、超過分に0.25ドルが掛かり続ける計算です。月初に前月分をまとめて削除しても、その月のGB-Hoursは請求から消えません。

CI/CDの費用管理をワークフロー設計と一体で見直したいなら、保守運用・内製化支援で現行のパイプラインの棚卸しから対応しています。

よくある質問

判断が分かれやすい点をまとめました。

パブリックリポジトリなら本当に無料で使い続けられますか？

標準のGitHubホストランナーであれば無料で、実行時間の上限もありません。GitHub PagesとDependabotも同じ扱いです。ただし大型ランナーはパブリックリポジトリでも課金対象になります。無料枠の残量とも無関係に、1分目から請求が立つ点に注意してください。

無料枠はWindowsやmacOSでも同じ分数だけ使えますか？

いいえ。GitHubは無料枠がリスト価格に基づいて消費されると説明しています。Linux 2コアの0.006ドルに対しmacOSは0.062ドルなので、同じ1分でも約10倍の速さで枠を減らします。Windowsは約1.7倍です。分数ではなく金額で減ると考えると、請求ダッシュボードの表示と一致します。