GitHub Actions課金防止術 90%通知とDependabot設定

GitHub Actionsは本当に便利ですが、AI開発でジョブ数が増えた瞬間に「今月の請求、思ったより高いな…」となりやすいですよね。この記事は、GitHub Actionsの使用量通知を整えたい人、Dependabot pre-commitで更新作業を減らしたい人、Mac mini self-hosted runnerを現実的に運用したい人に向けて書いています。読むと、課金を防ぐための設定が今日のうちに実装できます。僕は福祉事業のIT全般を担当しつつ、AI×SaaS開発を複業で回しているので、机上論ではなく「運用で詰まりやすい場所」もあわせて共有します。

2026年3月版：GitHub Actions 使用量 通知の前提を先にそろえる

まず押さえたいのは、2026年3月3日からIncluded usageの90%/100%到達メール通知が使えるようになった点です。詳細はGitHub ChangelogとBudgets and alerts公式ドキュメントに明記されています。ここを最初にONにするだけで、無料枠を超える直前に気づける体制が作れます。

「無料枠監視」と「金額予算監視」は別物です

ここは混同されやすいですが、Included usage alertはプラン無料枠の消費率、Budget alertは自分で設定した金額予算の監視です。つまり、前者は「無料枠の残量」、後者は「請求見込み」の監視です。両方を併用すると、見落としが一気に減ります。

単価も実行先で大きく変わります。Linux 2-coreは$0.006/分、Windows 2-coreは$0.010/分、macOS 3/4-coreは$0.062/分、Linux 1-core（actions_linux_slim）は$0.002/分です。しかも1分単位の切り上げ計算なので、30秒ジョブでも1分として積み上がります。イメージとしては、タクシーの初乗りが毎回発生する感じです。

なおself-hosted runnerは、2026年3月時点では利用自体の追加課金はなく、自己負担はインフラ維持費です。過去の価格改定アナウンスは更新情報付きなので、「現行仕様」と「過去提案」を分けて説明すると、チーム内の認識ズレを防げます。

90%通知を有効化する実務手順（Included usage alertとBudget alert）

通知設計は難しく見えますが、手順はシンプルです。大事なのは設定そのものより、通知後に誰が何をするかを決めることです。通知は「受け取る仕組み」ではなく「行動を起こす仕組み」にしておくのがポイントです。

1. Billing設定を開く — 組織または個人の請求設定からBudgets and alertsへ進みます。
2. Included usage alertをON — 90%と100%の通知を有効化します。
3. Budget alertを追加 — 75/90/100%を初期値として作成します。
4. 通知先を複数人にする — CI担当だけでなく、予算判断する人も入れます。
5. 月次レビューを固定 — 月1回、どのworkflowが増えたかを確認します。

ここで一番ミスしやすいのは、「通知先が1人だけ」な状態です。休暇や業務集中で見逃すと、気づいたときには100%を超えていることがあります。僕の現場では、通知先を最低2系統にして、片方が見逃してももう片方で拾えるようにしています。これだけで運用の安心感が全然違います。

「設定したけど運用が回るか不安」というときは、まず1週間だけログを見て、最も分を使っているジョブを1本特定してください。改善の起点が1本決まるだけで、無駄な調整が減ります。必要ならXのDM相談窓口で、設定画面の確認ポイントを一緒に整理できます。

Dependabot pre-commitを導入して、更新作業を自動化する

2026年3月10日からDependabotがpre-commitをネイティブ対応しました。これで.pre-commit-config.yamlのrev更新を自動PR化できます。手動でhookのバージョンを追いかける時間を、ほぼゼロに近づけられます。CIの信頼性を上げたいチームほど、先に入れておく価値が高いです。

# .github/dependabot.yml
version: 2
updates:
  - package-ecosystem: "pre-commit"
    directory: "/"
    schedule:
      interval: "weekly"
    groups:
      pre-commit-hooks:
        patterns:
          - "*"

運用はこの3点だけ押さえれば十分です。

• グループ更新 — 関連hookを1PRにまとめ、レビュー回数を減らします。
• 固定管理 — # frozen:を使えば、再現性重視のhookだけ更新対象から外せます。
• レビュー期限 — pre-commit更新PRは「48時間以内レビュー」など期限を決めます。

つまり、Dependabot pre-commitは「更新作業の自動化」だけでなく、「チームの意思決定を定期化する仕組み」でもあります。スマホのOS更新を後回しにしない感覚に近いです。公式情報はChangelogとサポートエコシステム一覧をセットで見ると、仕様の取りこぼしがありません。

Mac mini self-hosted runner設定手順（登録・ラベル・group・workflow）

Mac mini self-hosted runnerは、macOS必須のジョブを安定して回したいときに相性がいいです。僕はMac mini M4 Pro（24GB）を24時間稼働させて、Node.js+TypeScriptのnpm workspacesモノレポを回しています。実際に運用して感じるのは、最初の登録設計を丁寧にやると、後のトラブル対応がめっちゃ減るという点です。

1. トークン発行 — registration tokenは1時間で失効するので、発行後すぐ登録します。
2. ラベル設計 — macOS、ARM64、用途ラベル（例: ios-build）を先に決めます。
3. runner group割当 — 組織運用なら、アクセス対象リポジトリをgroupで絞ります。
4. workflowルーティング — runs-onでself-hostedを先頭に置いて明示します。

./config.sh --url <REPOSITORY_URL> --token <REGISTRATION_TOKEN> --labels gpu,x64,linux
./config.sh --url $org_or_enterprise_url --token $token --runnergroup rg-runnergroup

jobs:
  ci:
    runs-on: [self-hosted, macOS, ARM64]
    steps:
      - uses: actions/checkout@v5
      - run: npm ci && npm test

僕はGhostty + tmuxでrunner常駐プロセスを管理していますが、「死活監視」「再起動手順」「更新手順」の3点を運用メモに残しておくと、担当交代が起きても回しやすいです。ここまで作っておけば、Mac mini運用はかなり現実的になります。

課金を防ぐ運用設計：ジョブ配分と1分切り上げ対策

ここは毎月の差が出るところです。基本は、macOSは本当に必要なジョブだけ、その他はLinuxへ寄せることです。「実行先の最適化」と「不要実行の削減」を同時にやると、請求は読みやすくなります。

もう1つ重要なのが1分切り上げです。たとえば20秒ジョブを1日100回回すと、実時間は約33分でも課金計算は100分です。これが30日続くと3,000分になります。つまり「短いジョブを細かく乱発する構成」が、静かにコストを押し上げます。

• トリガー整理 — pathsやbranches条件を入れて、無関係変更時の実行を止めます。
• ジョブ統合 — 20〜40秒の細切れジョブは、可能な範囲でまとめます。
• 実行先分離 — Linuxで回せる処理をmacOSへ置かないようにします。
• 週次棚卸し — 上位3ジョブだけ分消費を確認し、改善対象を固定します。

このあたりは、コード最適化より先にやったほうが成果が見えやすいです。数字ベースで設計を見直したい方は、GitHub Actions運用の相談窓口で実行ログを見ながら一緒に整理できます。

通知と更新を後回しにした先に待つ現実

GitHub Actionsの通知・更新・実行先設計を放置したままだと、気づかないコスト増が積み上がる可能性があります。怖がる必要はないですが、早めに知っておくと回避しやすいです。

• 予算超過に気づくのが遅れる — 月末に請求を見て初めて把握する状態になります。
• CIの不安定化が増える — pre-commit hook更新遅れで突然失敗しやすくなります。
• 運用が属人化する — runner更新や再起動手順が担当者依存になります。

つまり、知らないままだと「開発は進んでいるのに、運用が苦しくなる」状態に入りやすいです。先に小さく整えるだけで、未来の負担はかなり軽くできます。

この記事を書いている理由

僕自身、Mac miniを24時間稼働させてAIエージェント運用とモノレポCIを回す中で、設定の甘さがそのままコストと手戻りになる場面を何度も経験しました。2026年3月も監視・自動復旧・死活管理まわりの記事を継続して書いていますが、結局いちばん伝えたいのは「派手な新機能より、運用設計のほうが先に効いてくる」という実感です。

ITの知見を非IT領域に持ち込む“異世界転生”の文脈でも、再現可能な手順に落とし込めるかが価値になります。だからこそ、今回も設定画面でそのまま実行できる粒度でまとめました。

次のアクション

まずは今週、通知設定とpre-commit自動更新だけ先に入れてみてください。そこまでできたら、Mac mini runnerの見直しに進む流れがスムーズです。