GitHub Actions料金を完全整理｜無料枠・課金条件・見積もり手順まで

GitHub Actionsを使い始めると、最初に気になるのが「結局いくらかかるのか」という点ではないでしょうか。パブリックなら無料と聞く一方で、プライベートリポジトリやmacOSジョブ、成果物の保存が絡むと、思った以上に費用が増えることがあります。
本記事では、GitHub Actions料金が発生するポイントを最初に整理し、プラン別の無料枠、分の計上ルール、ストレージ課金の考え方まで、迷わず判断できる形で解説いたします。さらに、見積もり手順とコストを抑える設定・運用ルールまで一気通貫でまとめます。読み終える頃には、料金の不安が消え、根拠を持って「使い方」と「費用」をコントロールできる状態を目指します。

※本コンテンツは「記事制作ポリシー」に基づき、正確かつ信頼性の高い情報提供を心がけております。万が一、内容に誤りや誤解を招く表現がございましたら、お手数ですが「お問い合わせ」よりご一報ください。速やかに確認・修正いたします。

GitHub Actions料金が発生するポイントを先に整理

GitHub Actions料金は何に対して課金されるか

GitHub Actionsの料金は、「どこで」「何を」「どれくらい」使ったかによって決まります。最初に押さえるべきは、課金対象が大きく3つに分かれる点です。

1. 実行時間（分）
   ワークフローで動いたジョブの実行時間が、分単位で計上されます。ビルド、テスト、デプロイなど、Runner上で処理が動いている時間が対象です。短いジョブでも回数が多いと積み上がります。

2. 成果物ストレージ（Artifacts）
   actions/upload-artifact などでアップロードした成果物（ビルド成果、テストレポート、ログなど）を保存する容量です。「保存している期間」と「容量」によって蓄積されるタイプで、使い方によっては実行時間よりも気づきにくいコスト要因になります。

3. キャッシュストレージ（Cache）
   actions/cache を使った依存関係のキャッシュが対象です。CIを高速化する強力な手段ですが、キャッシュキー設計が雑だと、似たようなキャッシュが大量に残って膨らむことがあります。

この3つのうち、初学者がまず引っかかりやすいのは「実行時間（分）」です。一方で、運用が長くなるほど効いてくるのが「成果物」「キャッシュ」のストレージです。料金が膨らんだときは、分だけでなくストレージもセットで疑うのが基本になります。

まず見るべきはリポジトリ種別とrunner種別

料金の話は、前提条件が混ざると一気に難しくなります。迷わないために、最初に以下の3点を固定してください。

• リポジトリはパブリックか、プライベートか

• Runnerは標準（standard）か、larger runnerか

• 実行場所はGitHub-hostedか、self-hostedか

特に重要なのは「Runner種別」です。標準Runnerであれば無料枠（含まれる分）が適用されるケースが多い一方、larger runnerは無料枠が使えない（または扱いが異なる）ため、同じワークフローでもコスト構造が変わります。

まずは「今のワークフローがどのRunnerで回っているのか」を棚卸ししてください。Actions画面のログや、ワークフローファイルの runs-on、組織/リポジトリのRunner設定を見ると把握できます。

GitHub Actions料金の無料枠をプラン別に把握する

無料枠の内訳は分・成果物ストレージ・キャッシュ

GitHub Actionsは、プランに応じて「毎月使える無料枠（含まれる使用量）」が設定されています。ここで大事なのは、無料枠が分（実行時間）だけではないことです。多くの人が「分」だけ見て安心してしまい、後から「ストレージ」が効いてきて驚きます。

代表的な無料枠のイメージを整理すると、次の3系統で理解するとわかりやすいです。

• 含まれる実行時間（分/月）：毎月リセットされる「使える分」

• 成果物ストレージの無料枠：保存容量に関する上限（プランにより異なる）

• キャッシュストレージの無料枠：キャッシュに割り当てられる目安（プランにより異なる）

ここでは「無料枠＝毎月リセットされる一定量」と覚えるのが第一歩ですが、ストレージは「使った瞬間に固定料金」ではなく「置いている間に積み上がる」性質があり、これが混乱の原因になります。

実務上のコツは、無料枠を“数字”で覚えるよりも、次の運用ルールを最初から入れておくことです。

• 成果物（Artifacts）は保存期間を短めに設定する

• キャッシュ（Cache）はキー設計を安定させ、不要キャッシュを増やさない

• 「分」だけでなく、ストレージの使用状況も月1回は確認する

無料枠はいつリセットされるか

無料枠のリセットは、基本的に請求サイクルに合わせて行われます。請求サイクルの開始日がいつかは、組織/アカウントのBilling設定で確認できます。

ただし、ここで落とし穴があります。分（実行時間）は「使って終わり」ですが、ストレージは「保存している限り積み上がる」ため、リセットの感覚がズレやすいのです。

• 分（実行時間）：請求サイクル内で消費し、次サイクルでまた使える

• ストレージ（成果物/キャッシュ）：保存中はサイクル内で蓄積し続け、削除や期限切れで減る

よくある誤解が「成果物を削除したら当月の請求がゼロになるのでは？」というものです。実際には、当月の途中まで保存していた分は、その時間分だけ“蓄積”されています。削除によって「これ以上増えない」状態にはできますが、「過去分の蓄積が巻き戻る」わけではありません。
この性質があるため、ストレージは「月末にまとめて消す」より、「最初から溜めない」設計のほうが効きます。

GitHub Actions料金の単価と計算方法を理解する

分は切り上げで計上される

Actionsの実行時間は、体感の秒数そのままではなく、分単位で計上されます。ここで効いてくるのが「端数」の扱いです。一般に、分課金のサービスでは次のような現象が起きます。

• 30秒のジョブでも「1分」として扱われる

• 61秒のジョブは「2分」になり得る

• “短いジョブを大量に実行”すると、端数が積み上がりやすい

この端数の影響を抑えるには、次の2つが効きます。

• ジョブの粒度を極端に細かくしすぎない
  例えば、lint・unit test・buildを別ジョブに分けすぎると、それぞれで端数が発生します。並列化で速くなる一方、課金上は不利になるケースがあり、速度とコストのバランスが必要です。

• 無駄な実行を減らす
  変更のないときに走らせない（pathsフィルタ）、PRのDraft時は実行しない、などの制御で回数を削ると、端数の総量も減ります。

2026年1月1日以降の標準ランナー単価

単価は、主に「OS」「Runnerの種類（標準/大規模）」「サイズ」によって変わります。標準Runnerでも、Linux・Windows・macOSで単価が異なり、特にmacOSは高くなりやすい傾向があります。

また、単価は改定されることがあるため、古い記事の数字をそのまま信じるのは危険です。社内説明や稟議で数字を使う場合は、必ず公式の単価表で確認し、参照日をメモしておくのがおすすめです。

単価を見るときの実務ポイント

• 見積もりは「最大構成」でなく、実際のワークフローに合わせる
  例：普段はLinux、特定ジョブだけWindows、など

• “回数×時間”だけでなく、分の切り上げを踏まえる

• “macOSを使う理由”が明確か見直す
  例：iOSビルドだけなら、その部分のみmacOSに限定する

larger runnerは無料枠が使えない

larger runner（大規模Runner）は、標準RunnerよりCPU/メモリが大きく、ビルドやテストが速くなるメリットがあります。一方で、料金面では扱いが変わることが多く、無料枠（含まれる分）の適用外になりやすい点が要注意です。

larger runner採用で失敗しがちなのは、「速くなるから正義」と思って全ジョブを載せ替え、結果的に想定外の従量課金になってしまうケースです。判断の筋道は次のとおりです。

• larger runnerで実行時間がどれくらい短縮されるか（例：40%短縮）

• その短縮によって、分課金の総量がどれくらい減るか

• それでもなお、単価や無料枠適用の差で増えるのか減るのか

つまり、「速くなる」だけではなく、「総コストが下がるか」を見積もってから決めるのが安全です。目安としては、ビルドが極端に重い、並列数が多い、開発者の待ち時間がボトルネックになっている、など“速度が価値になる”状況で採用意義が高まります。

ストレージ課金はGB-hoursで増える

ストレージ料金が理解しづらい最大の理由は、「容量×時間」で積み上がる点です。感覚としては「冷蔵庫に入れておくと電気代がかかる」イメージに近いです。

• 1GBを1時間保存 → 1GB-hour

• 10GBを24時間保存 → 240GB-hours

• 50GBを10日保存 → 50×10×24 = 12,000GB-hours

成果物を大きなzipで毎回保存していると、気づかないうちに“置いている時間”が効いてきます。とくに以下は典型的な増加パターンです。

• ビルド成果物を毎回保存し、保存期間（retention）が長い

• テストレポートやログを過剰に残している

• キャッシュキーが日付やコミットに紐づき、似たキャッシュが増殖する

対策は「置かない・小さくする・短くする」です。

• 置かない：本当に必要な成果物だけ保存（デプロイ済みなら不要、など）

• 小さくする：成果物の中身を見直す（不要ファイル除外、圧縮）

• 短くする：保存期間を短縮、目的に応じて期限を変える

GitHub Actions料金の見積もり手順

5つの判定ステップで課金有無を確定する

料金見積もりは、いきなり計算に入ると迷子になります。まず「課金されるかどうか」を判定し、そのあとに「いくらか」を計算するとスムーズです。以下の5ステップで整理してください。

1. リポジトリはパブリックか、プライベートか

2. Runnerは標準か、larger runnerか

3. 実行場所はGitHub-hostedか、self-hostedか

4. プランの無料枠（分・成果物・キャッシュ）を確認したか

5. 分（切り上げ）とストレージ（GB-hours）を前提に計上する

この5点が揃うと、見積もりが「条件分岐」と「計算」に分離されます。
ここから先は、計算ミスを減らすために“テンプレ”を使うのが現実的です。

見積テンプレ（まずはこれだけ埋める）

• 月間ジョブ回数（例：PR 200回、push 300回、夜間 30回）

• 1回あたり実行時間（平均、最大）

• OS比率（Linux何割、Windows何割、macOS何割）

• 成果物サイズ（平均GB）と保存期間（日）

• キャッシュサイズ（ピークGB）と増殖しやすいキー設計の有無

このテンプレを埋めるだけでも、「分」と「ストレージ」の両輪で見積もれるようになり、想定外を減らせます。

代表的な見積例3パターン

ここでは、考え方が伝わるように、代表的なパターンで見積もりの流れを示します。実際の単価は必ず公式表を参照し、ここでは「計算の組み立て」を中心に理解してください。

例1：Teamでプライベート、Linux標準runner中心（月4,000分）

• 前提：Teamプラン、プライベートリポジトリ、標準Runner（Linux中心）

• 月の実行時間：4,000分

• 無料枠（含まれる分）：3,000分（Team想定）

• 従量対象：1,000分

計算の流れ

1. 4,000分 − 3,000分 ＝ 1,000分（課金対象）

2. 課金対象分 × Linux単価 ＝ 月額（USD）

ここに成果物/キャッシュのストレージが無料枠を超える場合は、別途ストレージ分が上乗せされます。つまり、分だけで見積もると「後から増える」リスクが残ります。

例2：Freeでプライベート、Windows標準runner（月2,500分）

• 前提：個人Free、プライベート、Windowsが中心

• 月の実行時間：2,500分

• 無料枠：2,000分（Free想定）

• 従量対象：500分

WindowsはLinuxより単価が高めになりやすいので、同じ従量分でも金額は上がりやすいです。もしWindowsが必須でないジョブが混ざっているなら、Linuxに寄せるだけで効く場合があります。

例3：macOSが絡む（月600分、無料枠は残っている）

• 前提：プライベート、標準Runner、macOSジョブあり

• 月のmacOS実行：600分

• 無料枠：まだ十分残っている

このケースは、無料枠の残量があれば、分課金は発生しない可能性があります。ただし、次の点に注意が必要です。

• macOSジョブが増えると、一気に無料枠を食い潰す

• 端数切り上げが効きやすい

• 成果物やキャッシュのストレージが別で増えている可能性

macOSは「必要なところだけ」に限定し、ジョブの回数を抑える設計が安全です。

公式の料金計算ツールで検算する

見積もりを社内説明に使うなら、「自分の計算が正しいか」を検算できる仕組みがあると安心です。GitHubの案内する料金計算ツールやBilling画面の使用量表示を使い、次の2点をチェックしてください。

• 「分」の見積が大きくズレていないか（平均実行時間の見積が甘くないか）

• ストレージ（成果物/キャッシュ）が想定より増えていないか

また、見積の信頼性を上げる小技として、直近1〜2週間の実績から「平均分」「成果物サイズ」を拾い、1か月換算する方法があります。過去のログと現実の運用に基づくため、机上計算より説得力が出ます。

GitHub Actions料金を抑える設定と運用ルール

支出上限と予算アラートで想定外請求を防ぐ

コスト削減の前に、まず「暴走防止」を入れるのが鉄則です。Actionsは便利なぶん、設定や運用次第で急に回数が増え、気づいたときには請求が膨らむことがあります。

入れておきたいのは次の2つです。

• 支出上限（spending limit）：一定額に達したら従量課金を止める/制限する

• 予算アラート：指定した金額に近づいたら通知する

これを入れるだけで、「知らないうちに高額」になりにくくなります。特に、チーム開発で複数人がワークフローを触る場合、安心材料として非常に効きます。

チェックリスト：想定外請求を防ぐ基本設定

• 支出上限を設定した

• 予算アラートを設定した

• 誰がBillingを見られるか権限を確認した

• 月1回、Actions使用量（分・ストレージ）を確認する担当を決めた

成果物とキャッシュの整理でストレージ課金を抑える

ストレージは、放置すると積み上がります。効果が出やすい順に、対策を並べると以下のとおりです。

1. 成果物の保存期間（retention）を短くする
   「3日で十分」「1週間で十分」など、目的に合わせて期限を設定します。とくにPRごとの成果物を長期保存する必要がないケースは多いです。

2. 成果物を保存する条件を絞る
   例えば、毎回保存せず、リリースタグのときだけ保存する、mainブランチだけ保存する、失敗時だけログを保存する、などにすると劇的に減ります。

3. キャッシュキーを安定させ、増殖を抑える
   キャッシュキーにコミットハッシュや日付を入れると、毎回別キャッシュができやすくなります。依存が変わったときだけ更新されるよう、ロックファイルなどに基づいたキー設計にするのが一般的です。

4. キャッシュ対象を絞る
   何でもキャッシュすると増えます。本当に効果がある（再利用が多い）ものに限定します。

実行時間を短くするワークフロー改善

分課金は「速くすれば安くなる」という、改善がわかりやすい領域です。典型的な改善ポイントは次のとおりです。

• 依存関係のインストールを速くする
  キャッシュの当たり率を上げる、依存を減らす、差分インストールを工夫する。

• テストの対象を絞る
  すべてのテストを毎回回すのではなく、変更範囲に応じてテストセットを分ける。例えば、フロント変更ならフロント系テストだけ、など。

• 無駄なトリガーを減らす
  同じコミットでpushとPRで二重に走っている、Draftでも走っている、などの無駄を削る。

• 並列化は“速度”と“端数”のバランスで考える
  並列化で総時間が短くなるなら得ですが、ジョブを細切れにしすぎると端数切り上げが増え、コスト面で不利になる場合があります。最適点を探すのが大切です。

runner選択でコストと速度を最適化する

Runner選びは、コストにも開発体験にも直結します。基本方針は次のとおりです。

• 最初はLinux標準Runnerを基準にする
  多くの言語・フレームワークでLinuxが最も素直で、単価も抑えやすい傾向があります。

• Windows/macOSは“必要なジョブだけ”に限定する
  たとえば、.NETやiOSビルドなど、OS依存の領域だけに限定します。

• larger runnerは、速度価値が明確なときに限定採用
  例えば、重いビルドで待ち時間が開発のボトルネックになっている、並列数やメモリ不足で失敗が多い、など「速くすること自体が価値」になる状況で強い選択肢です。
  ただし、無料枠適用の有無や単価の差を踏まえて、総コストで判断してください。

GitHub Actions料金改定の最新動向を押さえる

2026年1月1日からホストrunnerは値下げ

料金の話で見落としやすいのが、単価改定の反映です。Actionsは過去にも単価や対象の整理が行われてきており、「昔のブログ記事の単価」を前提に見積もるとズレます。

見積もりや社内資料を作る場合は、次の運用にすると安全です。

• 単価は必ず公式の単価表を参照する

• 資料には「参照日（例：2026年1月）」を明記する

• 改定があれば、見積テンプレも更新する

この3点を徹底すると、後から「その単価、古いですよね？」と言われて混乱するのを防げます。

セルフホスト課金は情報が揺れているため確認が必要

セルフホストRunnerは、「自前のマシンで実行するから、実行時間課金がないのでは？」と考えたくなります。実際、セルフホストはインフラコスト（サーバ代、運用工数）が別にかかる一方、Actions側の課金構造が変わる可能性もあるため、注意が必要です。

重要なのは、「セルフホストなら必ず安い」「セルフホストなら課金がゼロ」と短絡的に決めないことです。次の視点で判断するとブレません。

• GitHub側の課金（ルールが変わる可能性がある）

• 自前インフラのコスト（サーバ費用、保守、セキュリティ、監視）

• 開発体験（待ち時間、キュー、スケール）

• 障害時の責任範囲（誰が復旧するか）

セルフホストは、コスト最適化の武器になり得ますが、「運用の現実」がセットです。料金だけでなく、運用負荷も含めて意思決定するのが安全です。

GitHub Actions料金のよくある質問

パブリックリポジトリは本当に無料か

一般に、パブリックリポジトリは無料で使える範囲が広く、「まず試す」には最適です。ただし、Runner種別や使い方（大規模Runner、特殊な課金対象など）によって扱いが変わる可能性があります。

不安な場合は、次を確認すると早いです。

• そのワークフローは標準Runnerで動いているか（runs-on を確認）

• Billing画面でActions使用量が発生していないか（使用量を確認）

• 成果物やキャッシュが不必要に溜まっていないか

無料枠を超えたら自動で課金されるか

従量課金が有効になっている場合、無料枠を超えれば課金対象になり得ます。「自動で課金されるのが怖い」という不安があるなら、最初にやるべきは節約ではなく、支出上限と予算アラートです。

• 支出上限：上限を超えない仕組みを作る

• アラート：気づける仕組みを作る

この2つが揃うと、心理的な不安が大きく下がり、落ち着いて最適化に取り組めます。

どこで使用量と請求を確認できるか

確認すべき場所は大きく2つです。

• Billing/請求設定の使用量画面：分やストレージの使用状況を把握する

• Actionsの実行ログ：どのワークフローが長いのか、どのジョブが重いのか原因を特定する

「請求が増えた」と感じたら、まず使用量画面で分・ストレージのどちらが増えているかを見て、次にActionsログで犯人（重いワークフロー）を特定すると、短時間で改善方針が立ちます。

成果物を削除すれば当月請求はゼロになるか

成果物の削除は有効ですが、「当月がゼロになる」とは限りません。ストレージは“保存していた時間”が蓄積されるため、月の途中まで置いていた分は、その時間分だけ積み上がっています。

削除で得られるのは、主に次の効果です。

• これ以上、ストレージの蓄積が増えない

• 翌月以降のストレージ使用量が減る（継続的なコスト低下）

したがって、緊急対処としての削除も有効ですが、根本対策としては「最初から溜めない」設計（保存条件・保存期間・キャッシュキー設計）が最も効きます。

GitHub Actions料金の要点整理と次にやること

ここまでの要点を、行動に落とし込める形でまとめます。GitHub Actionsの料金は、結局のところ次の3点で管理できます。

1. 課金される条件を整理する（リポジトリ種別×Runner種別×実行場所）

2. 分（切り上げ）とストレージ（GB-hours）の2軸で把握する

3. 暴走防止（支出上限・予算アラート）を先に入れる

最後に、すぐ実行できる“次のアクション”を提示します。

次にやることチェックリスト

• 自分のプランの無料枠（分・成果物・キャッシュ）を確認する

• ワークフローごとに runs-on を棚卸しし、OS比率を出す

• 直近1〜2週間の実行時間から、月間分数を概算する

• 成果物の保存条件と保存期間（retention）を見直す

• キャッシュキー設計を確認し、増殖を抑える

• 支出上限と予算アラートを設定する

この一連を整えるだけで、「無料だと思っていたのに請求が来た」「どこが増えたのかわからない」といった混乱は大きく減ります。料金体系は一見複雑ですが、条件分岐を固定し、分とストレージを分けて見積もるだけで、十分にコントロール可能になります。