GitHub Advanced Security（GHAS）の「Hard budget limits」は、GHASのライセンス予算を超えないように、上限到達後の追加利用を制御できる新機能です。従来の予算設定は主に通知目的でしたが、今回の更新により、Enterprise管理者やbilling managerはGHASのSKUごとにライセンス数ベースの上限を設定し、新しいリポジトリへの有効化を抑止できるようになりました。公式Changelogでは2026年5月28日付で公開されており、既存利用を止める機能ではなく、「これ以上広げない」ためのコスト統制機能として理解するのが重要です。(The GitHub Blog)
GitHub Advanced Securityのハード予算上限で何が変わったのか
今回の変更点は、GitHub Advanced Securityの予算管理が「ソフト予算」から「ハード予算」へ広がったことです。
これまでGHASのようなライセンスベースの製品では、管理者が予算目安を設定し、使用量が75％、90％、100％に達したタイミングで通知を受け取る運用が中心でした。ただし、通知後も利用自体は止まらないため、IdPグループのプロビジョニングや自動割り当ての流れで、想定以上にライセンスが増える可能性がありました。(The GitHub Blog)
新しいハード予算上限では、GHASの予算しきい値に達すると、追加のライセンス利用がブロックされます。具体的には、新しいリポジトリにGHASを有効化できなくなり、予算を増やすか、利用中のライセンスを解放するまで追加展開を抑止できます。(The GitHub Blog)
ソフト予算とハード予算の違い
| 項目 | 従来のソフト予算 | 新しいハード予算上限 |
|---|---|---|
| 主な目的 | 利用状況の把握と通知 | 予算超過の抑止 |
| 上限到達時の動作 | メール通知は届くが利用は継続 | 追加のGHAS有効化やライセンス割り当てを制御 |
| 通知 | 75％、90％、100％で通知 | 同じく75％、90％、100％の通知を維持 |
| 管理単位 | 予算目安としての管理 | GHAS SKUごとのライセンス数ベース管理 |
| 実務上の意味 | 気づいた時には超過している可能性がある | 組織・コストセンター単位で利用拡大を止めやすい |
重要なのは、ハード予算上限は「セキュリティ機能を突然停止するスイッチ」ではないという点です。GitHub Docsでは、Advanced SecurityのSKUレベル予算で「Limit usage when budget limit is reached」を使えるようになり、上限到達時には追加リポジトリへの新規有効化を防ぐ一方、すでに有効化済みのリポジトリではAdvanced Securityが引き続き動作すると説明されています。(GitHub Docs)
対象になるGHASのSKU
GitHub Advanced Securityには、主に次の2つのライセンスSKUがあります。
| SKU | 含まれる主な機能 | 影響を受ける確認ポイント |
|---|---|---|
| GitHub Secret Protection | secret scanning、push protectionなど | 秘密情報の漏えい検出・防止を新規リポジトリへ広げる計画 |
| GitHub Code Security | code scanning、Dependabotの高度な機能、dependency reviewなど | 脆弱性検出や依存関係レビューを新規リポジトリへ展開する計画 |
GitHub Docsでは、GHASのライセンス利用は、対象機能を有効化したリポジトリにおける「unique, active committers」を基準に計算されると説明されています。active committerは、過去90日以内に対象リポジトリへコミットがプッシュされたユーザーとして扱われます。(GitHub Docs)
そのため、単純に「リポジトリ数」だけで予算を見積もると失敗します。実務では、次のような差が出ます。
| リポジトリの状態 | ライセンス影響の見方 |
|---|---|
| 少人数の新規サービス用リポジトリ | 追加ライセンスは小さく見積もりやすい |
| 多くの開発者が触る共通基盤リポジトリ | 有効化時に一気にactive committerが増える可能性がある |
| 過去90日以内に多くの人がコミットした移管直後のリポジトリ | 予算消費が想定より大きく見えることがある |
| すでに同じ開発者が別のGHAS対象リポジトリでカウント済み | 追加ライセンスが少なく済む場合がある |
管理者とbilling managerが最初に確認すべきこと
ハード予算上限を設定する前に、まず「現在どのリポジトリで、どのSKUが、何人分使われているか」を確認します。上限値だけを先に決めると、既存利用を正しく反映できず、必要な新規展開が止まる原因になります。
確認すべき設定項目
| 確認項目 | 見るべき理由 | 実務での判断基準 |
|---|---|---|
| 現在のGHAS利用ライセンス数 | 上限の初期値を決める基準になる | 現在値ぴったりではなく、短期の増加分を見込む |
| Secret ProtectionとCode Securityの利用状況 | SKUごとに予算設計が必要 | 全社必須のSKUと任意展開のSKUを分ける |
| 自動有効化ポリシー | 新規リポジトリ作成時の想定外利用を防ぐ | 重要組織だけ自動有効化し、検証用組織は申請制にする |
| IdP／SCIM／グループ連携 | ユーザー追加とライセンス増加が連動する場合がある | 入社・異動時のグループ割り当てを確認する |
| コストセンター | 部門別の予算管理に直結する | 事業部・プロダクト・顧客案件単位で分ける |
| アラート受信者 | 通知が届いても対応者が不明だと意味がない | 請求担当だけでなく、開発責任者も含める |
GitHubの予算設定は、OrganizationまたはEnterpriseの「Billing & Licensing」から「Budgets and alerts」に進んで管理します。予算作成時にはProduct-level budget、SKU-level budgetなどを選択し、予算スコープと予算額またはライセンス数を設定します。(GitHub Docs)
GHASのハード予算上限を使う場合は、Advanced SecurityのSKUレベル予算で「Limit usage when budget limit is reached」を選ぶ点がポイントです。この選択をしない場合、上限を超えてもメール通知は届きますが、利用は停止されません。(GitHub Docs)
影響範囲：既存リポジトリは止まらないが、新規展開は止まる可能性がある
今回の更新で誤解しやすいのは、「予算上限に達したらGHASが無効化されるのか」という点です。
結論として、すでにGHASが有効になっているリポジトリでは、Advanced Securityの機能は通常どおり継続します。上限到達後に制御されるのは、主に追加リポジトリへの新規有効化です。GitHub Docsでも、上限到達後は既存リポジトリのAdvanced Securityは動作し続け、追加リポジトリへの有効化ができなくなると説明されています。(GitHub Docs)
管理者への影響
管理者は、GHASの展開計画を「セキュリティ方針」だけでなく「予算枠」とセットで管理する必要があります。
たとえば、全社的にSecret Protectionを広げたい場合でも、予算上限が低すぎると新規リポジトリへの有効化が途中で止まります。反対に、上限を高くしすぎるとコスト統制の意味が薄れます。
現実的には、次のように段階を分けると運用しやすくなります。
| 展開フェーズ | 推奨する管理方法 |
|---|---|
| 試験導入 | 特定のOrganizationまたはコストセンターに限定する |
| 重要リポジトリへの展開 | 本番・顧客影響の大きいリポジトリを優先する |
| 全社展開 | 部門別に予算上限と責任者を分ける |
| 運用定着後 | 月次でライセンス消費とアラート履歴を確認する |
開発者への影響
開発者側では、既存リポジトリで急にcode scanningやsecret scanningが止まるわけではありません。ただし、新しいリポジトリを作成したときや、既存リポジトリにGHASを追加しようとしたときに、予算上限の影響で有効化できないケースが出ます。
そのため、開発チームには次のルールを共有しておくと混乱を防げます。
- 新規プロジェクト開始時に、GHASの利用予定を管理者へ伝える
- Secret ProtectionとCode Securityのどちらが必要かを明確にする
- リポジトリ作成後にGHASが有効化されているか確認する
- 有効化できない場合の申請先をチーム内ドキュメントに記載する
- 予算上限によるブロックを、権限不足やGitHub障害と混同しない
特に、セキュリティレビューをリリース条件にしている組織では、GHASが有効化されていない新規リポジトリが混ざると、後工程で検出漏れや再作業が発生します。予算設定は請求部門だけの作業ではなく、開発プロセス全体に関わる変更として扱うべきです。
ハード予算上限を設定する手順
実際の設定では、いきなり全社上限を作るより、現在利用の棚卸しから始めるのが安全です。
| 手順 | 作業内容 | 注意点 |
|---|---|---|
| 1 | 現在のGHAS利用状況を確認する | SKU別、Organization別、コストセンター別に見る |
| 2 | 予算スコープを決める | Enterprise全体か、Organization／コストセンター単位かを決める |
| 3 | SKU-level budgetを作成する | Secret ProtectionとCode Securityを混同しない |
| 4 | ライセンス数ベースの上限を設定する | 現在値に短期増加分を加えて決める |
| 5 | 「Limit usage when budget limit is reached」を有効にする | これを選ばないと通知のみの運用になる |
| 6 | 75％、90％、100％のアラート受信者を設定する | 請求担当と開発責任者の両方に届くようにする |
| 7 | 新規リポジトリで挙動を確認する | 自動有効化、テンプレート、権限設定と合わせて確認する |
| 8 | 運用ルールを周知する | 予算増額、例外承認、GHAS有効化申請の流れを決める |
既存のソフト予算を使っている場合は、GitHubの画面上のフローで新しいライセンスベース形式へ移行できます。公式Changelogでも、新規顧客と既存顧客のどちらもハード予算を作成でき、既存のソフト予算は製品内フローで移行できると案内されています。(The GitHub Blog)
予算上限の決め方：現在利用ぴったりにしない
GHASのハード予算上限は、低く設定すれば安全というものではありません。低すぎる上限は、必要なセキュリティ展開を止めてしまいます。
判断基準は、次の3つです。
現在の請求対象ライセンス数を基準にする
GitHubは、既存のGHAS利用があるEnterpriseでは、現在の請求対象ライセンス数を下回らないように新しい予算の下限を設定すると説明しています。これは既存利用への影響を避けるための挙動です。(The GitHub Blog)
ただし、現在値はあくまで「今日の利用状況」です。来月の新規プロジェクト、組織変更、外部協力者の追加、リポジトリ統合などがある場合は、その増加分を見込む必要があります。
active committerの増減を考慮する
GHASのライセンス利用は、過去90日以内のactive committerに影響されます。つまり、ある開発者が別チームへ移ったとしても、直ちにカウントから外れるとは限りません。GitHub Docsでも、過去90日以内に対象リポジトリへコミットがプッシュされていればactive committerとして扱われると説明されています。(GitHub Docs)
そのため、予算設計では次のような余白を持たせると安定します。
| 組織の状態 | 予算上限の考え方 |
|---|---|
| 新規開発が少ない安定運用 | 現在利用数に小さめの余白を足す |
| 新規サービスが複数立ち上がる | 四半期単位の増加見込みを反映する |
| 外部委託や短期メンバーが多い | 一時的なactive committer増加を見込む |
| 大規模移行直後 | 移行後の実コミット状況を見て段階的に上げる |
SKUごとに優先順位を分ける
Secret ProtectionとCode Securityは、同じGHASに含まれていても運用上の意味が異なります。
たとえば、秘密情報漏えいを防ぐpush protectionは、広範囲に有効化したい組織が多いはずです。一方で、Code Securityは言語、リポジトリの重要度、CI/CDの成熟度によって優先度が変わる場合があります。
予算が限られている場合は、次のように整理すると判断しやすくなります。
| 優先度 | 対象例 | 推奨方針 |
|---|---|---|
| 高 | 本番サービス、顧客データを扱うリポジトリ、認証・決済関連 | Secret ProtectionとCode Securityを優先的に有効化 |
| 中 | 社内業務アプリ、継続開発中の共通ライブラリ | Code Securityの対象化を計画的に進める |
| 低 | 検証用、短期PoC、アーカイブ予定 | 必要性を確認してから有効化 |
展開時に失敗しやすいポイント
GHASのハード予算上限は便利ですが、設定の仕方を誤ると「予算は守れたが、必要なセキュリティ機能が広がらない」という状態になります。
予算が残っていても超過する場合がある
Advanced Securityのハード予算は、完全にすべての超過を機械的に防ぐものではありません。GitHub Docsでは、上限を超える可能性があるケースとして、すでにGHASが有効なリポジトリで新しいcommitterがactiveになる場合や、残り予算を超えるactive committerを持つリポジトリにGHASを有効化する場合が挙げられています。(GitHub Docs)
たとえば、残り5ライセンスの状態で、過去90日以内に20人がコミットしているリポジトリへCode Securityを有効化すると、想定より大きく利用数が増える可能性があります。上限設定だけに頼らず、有効化前に対象リポジトリのcommitter数を確認する運用が必要です。
既存リポジトリのコスト削減にはならない
上限到達後も、すでにGHASが有効なリポジトリは通常どおり動作し、active committerは引き続きカウントされます。つまり、ハード予算上限は「これ以上増やさない」ための仕組みであり、「今のコストを自動的に下げる」機能ではありません。(GitHub Docs)
コストを下げたい場合は、次のような別の作業が必要です。
| 目的 | 実施する作業 |
|---|---|
| 不要なライセンス消費を減らす | GHASが不要なリポジトリで対象SKUを無効化する |
| 部門ごとの負担を明確にする | コストセンターを整理する |
| 対象範囲を絞る | 重要リポジトリから優先して有効化する |
| 新規利用を承認制にする | 自動有効化ポリシーと申請フローを見直す |
予算の重複設定で予期せずブロックされる
GitHub Docsでは、製品単位とSKU単位、Organization単位とRepository単位など、重複する予算を作ると、どれか1つのハード上限に達した時点で利用がブロックされる可能性があるため、重複予算は避けることが推奨されています。(GitHub Docs)
たとえば、Enterprise全体でGHASの上限を設定し、さらに特定Organizationにも厳しい上限を設定すると、全体予算に余裕があっても、そのOrganizationだけ新規有効化できないケースがあります。
重複設定を使う場合は、「どの予算が最終的なブレーキなのか」を明文化しておきましょう。
予算スコープは後から変更できない
GitHub Docsでは、予算の編集や削除は可能ですが、作成後に予算スコープは変更できないと説明されています。(GitHub Docs)
つまり、最初に「Enterprise全体」「Organization」「コストセンター」のどれで管理するかを慎重に決める必要があります。迷う場合は、いきなり全社一括ではなく、コストセンターや主要Organization単位で小さく始める方が運用しやすくなります。
利用データの反映には時間差がある
GHASを有効化・無効化した直後に、Billing and Licensing上の使用量がすぐ変わらない場合があります。GitHub Docsでは、GitHub Secret Protection、GitHub Code Security、GitHub Advanced Securityを有効化した場合、利用データに反映されるまで最大2時間の遅延があると説明されています。(GitHub Docs)
設定変更後すぐに数値が変わらなくても、短時間で何度も設定を変更しない方が安全です。運用では、変更時刻、対象リポジトリ、変更者、確認予定時刻を記録しておくと、請求確認がしやすくなります。
移行・展開時の実務チェックリスト
既存のGitHub環境へハード予算上限を導入する場合は、次の順番で進めると失敗を減らせます。
| チェック項目 | 完了の目安 |
|---|---|
| 現在のGHAS SKU別利用数を確認した | Secret ProtectionとCode Securityを分けて把握している |
| 主要リポジトリのactive committer数を確認した | 新規有効化時のライセンス増加を見積もれる |
| 予算スコープを決めた | Enterprise、Organization、コストセンターのどれで管理するか決まっている |
| ハード上限を有効にした | 「Limit usage when budget limit is reached」を選択している |
| アラート受信者を設定した | 請求担当、Platform管理者、開発責任者が通知を受け取れる |
| 自動有効化設定を確認した | 新規リポジトリ作成時のGHAS有効化条件が分かっている |
| 例外申請の流れを決めた | 予算増額や一時的な有効化の承認者が明確 |
| 月次レビューを設定した | 利用数、アラート、ブロック発生状況を確認する予定がある |
特に大規模なEnterpriseでは、「セキュリティ部門がGHASを広げたい」「開発部門は新規リポジトリをすぐ作りたい」「経理部門は予算超過を避けたい」という利害がぶつかりやすくなります。ハード予算上限は、その調整をGitHubの設定に落とし込むための機能です。設定値そのものよりも、誰が増額を判断し、どのリポジトリを優先するかを決めておくことが重要です。
GitHub Enterprise Serverと併用している場合の注意点
GitHub Enterprise CloudとGitHub Enterprise Serverの両方でAdvanced Securityを使っている組織では、ライセンス使用状況の同期も確認しておきましょう。GitHub Docsでは、両環境でAdvanced Securityを使っている場合、不要な重複ライセンス消費を避けるために、GitHub Enterprise ServerからCloudへライセンス利用を同期できると説明されています。(GitHub Docs)
また、GitHub Enterprise Server単体の利用では、契約形態やバージョン、GitHub Connectの有無によって課金・管理方法が異なります。ハード予算上限だけで全環境のコストが統制できると考えず、自社の契約形態と対象環境を確認してから展開してください。
管理者が取るべき次のアクション
今回のGitHub Advanced Securityのハード予算上限は、セキュリティ機能の導入を止めるためのものではなく、必要な範囲に計画的に広げるための機能です。
まず行うべきことは、現在のGHAS利用状況をSKU別に確認することです。そのうえで、重要リポジトリを守るための最低ライン、四半期内に増える見込み、部門別の予算責任を整理します。次に、Budgets and alertsでSKU-level budgetを作成し、必要に応じて「Limit usage when budget limit is reached」を有効化します。
最後に、開発チームへ「新規リポジトリでGHASが有効化されない場合の確認先」を周知してください。ハード予算上限は、設定して終わりではありません。アラートを見て、予算を調整し、展開対象を見直すことで、GitHub Advanced Securityをコストとセキュリティの両面から運用しやすくなります。
コメント