GitHub Copilotの請求は、席数だけ見ていれば安全という段階を過ぎつつあります。2026年6月1日からGitHubはCopilotをrequest-based billingからusage-based billingへ移行予定で、すでにBusinessは1ユーザー月300件、Enterpriseは1ユーザー月1000件のpremium requests枠を前提に、超過分は1件あたり0.04ドルで管理する考え方が必要です。情シスや開発部門の予算オーナーは、固定費のseatと変動費のpremium requestsを分けて設計しないと、月末に『誰が何に使ったか分からない』状態になりがちです。この記事では、アラート設計・部門別配賦・運用ルールまで、予算管理で先に決めるべきポイントを整理します。
GitHub Copilot従量課金で先に押さえる3つの変更点
第1に、費用はseat課金だけでなくpremium requestsの超過利用まで含めて見る必要があります。第2に、licenses向けbudgetは監視用で、上限到達後も自動停止しません。一方でpremium requestsは『Stop usage when budget limit is reached』を有効にすれば停止できます。第3に、重複budgetがあると、どれか1つでも上限到達で利用が止まるため、Product-levelとSKU-levelを無造作に重ねる設計は避けるべきです。
料金体系は固定費と変動費に分けて見る
2026年5月時点の公式情報では、Copilot Businessは1席19ドル/月、Copilot Enterpriseは1席39ドル/月です。premium requestsの月次枠はBusinessが300件、Enterpriseが1000件で、追加分は1件0.04ドル。たとえばBusinessを50席配布すると固定費は月950ドルです。さらに20人が1日4件ずつ超過し、20営業日続いた場合、超過は1600件で64ドル。Seat費用より小さく見えても、特定チームだけが集中利用すると差が出るので、固定費と変動費を分けた台帳が必要です。
予算管理の基本設計は『seat・premium・6月移行』の3レイヤー
おすすめは、①seat配布数を管理するライセンス台帳、②premium requestsの月次使用量レポート、③6月1日のusage-based billing移行を前提にした見直し枠、の3レイヤーです。GitHub公式は、organization ownerがライセンス付与で請求に影響すると説明しています。まず誰が席を付与できるかを固定し、次にpremium request usage reportで超過ユーザーを確認し、最後に移行前後で『固定費中心の月』と『利用量中心の月』を比較できるようにしておくと、稟議と実績のズレを追いやすくなります。
CopilotやClaudeの予算設計を部門横断で整理したい場合は、 AI・Claude研修のご相談 から要件整理を進めるとスムーズです。
アラート設計は75%・90%・100%と停止条件を分ける
GitHubのbudgetは75%・90%・100%で通知できますが、何を通知し、どこで止めるかは別設計です。実務では、75%で部門責任者へ共有、90%で情シスと経理へ再確認、100%でpremium requestsのみ停止、という3段階が扱いやすいです。重要なのは、licenses budgetはモニタリング専用で止まらない点と、premium requestsはbudget exhaustedで停止可能な点を混同しないことです。開発を止めたくない部署にはEnterpriseへの切替、検証用途の部署には0ドルbudget付きcost centerを割り当てると差配しやすくなります。
部門別配賦はcost centerで『誰の超過か』を見える化する
GitHubはcost centerで組織やユーザー単位の支出管理を推奨しています。営業支援開発、社内ツール、研究開発のように利用目的が違うなら、少なくとも2〜3個のcost centerに分けるのが無難です。予算が不要な組織には0ドル、超過を許可する組織にはBundled premium requests budget、さらに厳密に管理したい場合はCopilot Premium RequestのSKU-level budgetを設定します。Businessユーザーが月800件超のpremium requestsを常用するなら、GitHub公式の目安どおりEnterprise移行の方がコスト効率を見直しやすいです。
月次運用ルールは『配布前・週次・月末』で固定する
配布前は、席付与権限者、対象部門、budget scope、停止条件を決めます。週次は、premium request usage reportを見て超過上位ユーザーと未活用ユーザーを確認し、未活用席は回収候補にします。月末は、seat固定費・premium超過費・cost center別実績を1枚にまとめ、翌月の上限とEnterprise切替候補を判断します。よくある質問は『budgetを作れば全部止まるのか』ですが、止められるのはpremium requests側だけです。ライセンス費用は監視とアラート中心、利用量は停止条件つき、という分担で設計するのが安全です。
GitHub Copilotの導入ルール整備、AI開発組織のガバナンス設計、研修までまとめて進めたい場合は、 /contact/ からご相談ください。
