GitHub Codespaces料金を止める90%通知と自動停止Runbook

GitHub Codespacesは便利ですが、放っておくと料金がじわっと増えやすいですよね。この記事は「GitHub Codespaces 料金が読めない」「GitHub 使用量しきい値 通知を入れたい」「GitHub 課金 防止 自動停止までやりたい」という方に向けて書いています。読むと、90%通知の設定から自動停止Runbookまで、今日中に運用へ落とし込めます。僕は福祉事業のIT全般を担当しながら複業でAI×SaaS開発も回しているので、時間もコストも溶かさない実務目線で整理しました。

GitHub Codespaces料金が増える仕組みを先に押さえる

最初に構造をシンプルにします。GitHub Codespacesの課金は、compute と storage の2つです。computeは「稼働時間×マシン倍率（コア数）」、storageは「保存容量×時間」で積み上がります。つまり 請求 ≒ core-hours + GB-hours です。イメージとしては、computeがタクシーのメーター、storageが倉庫代です。走っている間は前者が伸び、置いてある間は後者が伸びます。

ここで見落としやすいのが、ブラウザタブを閉じてもcodespaceは止まらないことです。GitHub公式のStopping and starting a codespaceでも、明示的に停止しない限りアイドルタイムアウトまで稼働し続けると説明されています。「閉じた＝止まった」ではないが第一ポイントです。

• Running中 — computeとstorageの両方が増えます
• Stopped中 — computeは止まり、storageのみ増えます
• Deleted後 — その時点から将来分のstorage増加が止まります

たとえば4-core環境を平日20日で「1日2時間」使うと約160 core-hoursです。同じ環境を止め忘れて「1日8時間」動かすと約640 core-hoursになり、単純計算で4倍です。しかもアイドルタイムアウトのデフォルトは30分なので、ちょっと席を外したつもりが積み上がることが普通にあります。

GitHub 使用量しきい値 通知を90%で受ける設定手順

ここから通知設定です。2026年3月時点のGitHub公式ドキュメントでは、通知は2種類あります。ひとつは「プラン内利用量が90%/100%に達したとき」のIncluded usage alerts、もうひとつは予算金額に対する75%/90%/100%のBudget threshold alertsです。設定画面は Billing overview → Budgets and alerts です。

1. Included usage alertsをON — まず90%/100%通知を受け取れる状態にします
2. Codespacesの予算を作成 — Product-levelまたはSKU-levelで作成します
3. 75%/90%/100%通知をON — メールとGitHubバナー通知を有効化します
4. 必要ならStop usageをON — 上限到達時に追加利用を止めます
5. 受信者を追加 — 個人運用でも別メールを1つ追加すると見逃しが減ります

注意点は「予算を作った最初の請求サイクル」です。GitHub公式では、予算作成前に発生した利用分は当月計算に含まれないため、初月は想定より超過する可能性があると明記されています。ここを知らないと「Stop usageを入れたのに超えた」と感じやすいです。

結論として、通知は「90%で気づく仕組み」、予算は「75%から調整する仕組み」、Stop usageは「最終ブレーキ」です。3つをセットで入れると、請求の予測精度が一気に上がります。

GitHub 課金 防止 自動停止Runbookを実装する

通知だけだと、忙しい日に見逃します。ここはRunbook化が大事です。僕が実運用で使う設計は「検知→判定→停止→記録」の4段です。たとえば30分おきに実行して、最終利用から90分以上経った稼働codespaceを止める運用にすると、手作業がほぼ不要になります。

1. 検知 — gh codespace list --json ... で一覧取得
2. 判定 — lastUsedAt からidle分を計算
3. 停止 — 対象に gh codespace stop --codespace NAME を実行
4. 記録 — 停止件数を日次で残して閾値を見直す

#!/usr/bin/env bash
set -euo pipefail

MAX_IDLE_MINUTES="${MAX_IDLE_MINUTES:-90}"

gh codespace list --json name,state,lastUsedAt,repository --limit 100 \
| jq -r --argjson max "$MAX_IDLE_MINUTES" '
  .[]
  | select(.lastUsedAt != null)
  | select(.state != "Shutdown")
  | . + {idleMin: ((now - (.lastUsedAt | fromdateiso8601)) / 60 | floor)}
  | select(.idleMin >= $max)
  | [.name, .repository.fullName, (.idleMin|tostring)] | @tsv
' | while IFS=$'\t' read -r name repo idle; do
  echo "Stopping ${name} (${repo}) idle=${idle}m"
  gh codespace stop --codespace "$name"
done

REST APIで実行するなら、GitHub公式のCodespaces APIにある POST /user/codespaces/{codespace_name}/stop も使えます。CLIでもAPIでも本質は同じです。「止める担当者」を人間から仕組みに移すと、コスト事故はかなり減ります。

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

個人とチームで設定を分けると無駄課金が減る

同じGitHub Codespacesでも、個人開発と組織開発では正解が違います。個人は「作業を止めない快適さ」、組織は「再現性と説明責任」が重くなります。なので、最初から設定を分けるのがおすすめです。タイムアウトは5〜240分、保持期間は0〜30日で調整でき、デフォルトはどちらも長め寄りです。

組織リポジトリでは、個人設定より組織ポリシーが優先される場合があります。たとえばtimeoutやretentionの上限が組織側で短く設定されていれば、個人側で長く設定していても適用されません。「自分の設定が反映されない」時は仕様通りのことが多いので、まずはポリシーを確認してください。

運用メモとして、外部導線ではなく、実測ログ・設定差分・再現手順を同じ場所に残してチーム内で確認できる形にしてください。

15分で終わる初回セットアップ手順

最後に、今日から実践できる最短手順を置いておきます。ここまで設定すれば、通知と停止の両輪が回り始めます。難しく見えますが、やることはシンプルです。

1. Billing画面で通知ON — Included usage 90%/100%、Budget 75%/90%/100%
2. Codespaces予算を作成 — Product-levelでまず1本作る
3. Stop usageのON/OFF方針を決める — 月末だけONなどでもOK
4. idle timeoutを短縮 — まず30分→15分から試す
5. retention periodを短縮 — デフォルト30日から3〜7日に寄せる
6. 自動停止ジョブをCron化 — 30分おき実行で十分です

# 現在のcodespace状況を可視化
gh codespace list --json name,state,lastUsedAt,machineName,repository --limit 100 \
| jq -r '.[] | [.repository.fullName,.name,.state,.machineName,.lastUsedAt] | @tsv'

prebuildは見えにくく、storageが増える原因になりやすいです。ここを週1で見るだけでも、請求の読みやすさがかなり上がります。「通知で気づく→Runbookで止める→週次で見直す」の3点セットで回していきましょう。

通知と自動停止を入れないまま四半期を過ごすと

このテーマを放置すると、痛みは遅れて出ます。月次請求の時点で「想定より高い」と気づいても、どのcodespaceが原因だったか追えないケースが多いからです。さらにStop usageが未設定だと、上限超過がそのまま継続する可能性があります。知らないままだと、予算だけでなく開発計画まで崩れることがあるので、最低限の通知と停止だけは先に入れておくのがおすすめです。

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

僕自身、SES、人材育成、福祉領域のIT運用と、非ITの現場にITを持ち込む形でキャリアを作ってきました。業務効率化ツールで月80時間の工数削減を出した時も、派手な技術より先に「運用ルールの言語化」が勝ち筋でした。550名以上のキャリア面談でも、困るポイントはだいたい同じです。だからこそ、GitHub Codespacesのような便利な仕組みほど、通知とRunbookを先に渡したいと思っています。使いこなしは才能より設計です。

次のアクション

まずは今日、90%通知と予算だけ設定してみてください。そこまでできたら、自動停止Runbookを乗せれば十分スタートできます。設定後のつまずきは気軽に共有してもらえたら嬉しいです。