GitHub Copilotの「値上げ」を気にする企業は多いですが、2026年6月1日に起きた本質的な変化は、料金表よりも課金の考え方です。GitHubは2026年6月1日にリクエスト課金を終了し、組織向けCopilotをAI creditsベースのusage-based billingへ移行しました。いま情シスが見るべきなのは、席単価の増減だけでなく、クラウドエージェントやCLI、Chatの使い方がどこまで追加費用に跳ねるかです。
2026年7月31日時点の公式Docsでは、Copilot Businessは1席あたり月19ドルで1,900 AI credits、Copilot Enterpriseは1席あたり月39ドルで3,900 AI creditsが標準です。さらに既存顧客には、2026年6月1日から9月1日までBusiness 3,000、Enterprise 7,000のプロモーション枠が付いています。この記事では、予算再予測と承認フローをどの順番で整えるべきかをチェックリスト化します。
1. まず押さえるべき変更点：6月1日から何が変わるのか
usage-based billingでは、Copilot Chat、Copilot CLI、Copilot cloud agent、Copilot Spaces、Spark、third-party coding agentsなど、AIモデルを使う機能がAI creditsを消費します。一方で、コード補完とnext edit suggestionsは引き続き無制限です。つまり「補完中心のライトユーザー」と「長いagent作業を回すヘビーユーザー」で、実質コスト差が大きくなりました。
AI creditsは1 credit = 0.01 USDで計算され、各ユーザーに付与される枠は請求単位でプールされます。たとえばCopilot Businessを100席付けると、100人が個別に1,900 creditsを持つのではなく、190,000 creditsの共有プールとして扱われます。高負荷ユーザーを吸収しやすい一方、放置すると一部チームが全社プールを先に使い切るリスクもあります。
さらに、未使用枠は翌月へ繰り越されず、毎月1日の00:00:00 UTCにリセットされます。月末駆け込み利用や、月初のPoC集中でコストが偏る企業は、このUTCリセット前提でレポートを見ないと判断を誤ります。
2. 予算再予測で見るべき3つの数字
第1に見るべきは、席数から計算できる標準付与枠です。Business中心なのかEnterprise中心なのかで、最初から使えるcreditsが倍近く変わります。既存顧客なら2026年9月1日までのプロモーション枠と、その終了後の標準枠を分けて試算してください。キャンペーン中の数字だけで年予算を作ると、秋以降に必ずズレます。
第2は追加予算です。GitHubはAI credits paid usage policyを既定で有効にしているため、管理者が明示的に止めない限り、プール枯渇後も追加費用で利用が続きます。ここを認識しないまま「込み料金だと思っていた」で月末を迎えるのが一番危険です。追加予算をゼロにする部門、上限付きで許可する部門、実験枠を持たせる部門を最初に分けておくべきです。
第3は高消費ワークロードです。長いcloud agentセッション、複数ファイルをまたぐCLI作業、モデルを切り替えながらのChat運用は、軽い補完より消費が重くなります。利用レポートを見て、誰が大量に使うかではなく、どの業務パターンが大量に使うかまで分解すると、追加予算の根拠を説明しやすくなります。
3. 承認フローは「全社一律」ではなく3段階に分ける
おすすめは、標準利用者、条件付き追加利用者、高額利用者の3層に分ける設計です。標準利用者は付与枠のみ、条件付き追加利用者はチーム責任者承認で追加利用可、高額利用者は部門長または情シス承認を必須にします。こうしておくと、追加費用の責任分界が曖昧になりません。
さらに、費用負担の単位も先に決める必要があります。GitHubの公式ドキュメントでは、user-level budget、cost-center budget、organization-level budget、enterprise spending limit を組み合わせて制御できます。部門配賦をしたいならcost center単位、全社天井だけ決めたいならenterprise spending limit中心、と目的ごとに使い分けるのが実務向きです。
4. 見落としやすい設定：Paid usage policy と停止条件
追加請求を止めたい企業が最初に確認すべきなのは、paid usage policyが有効かどうかです。有効なら枯渇後も従量課金で継続し、無効ならその時点で利用停止になります。「上限に達したら軽いモデルへ自動フォールバックする」といった動きは前提にしない方が安全です。止まるか、課金されるかの二択として設計してください。
停止条件も多層です。ユーザー個別のbudget、cost centerのbudget、組織やenterprise全体のspending limitのどれかに当たると、想定より早く利用制限がかかる場合があります。特にPoCチームだけ高く、他部署は低く抑える構成では、どの天井が先に効くかを図にしておくと説明しやすいです。
5. 情シス向けチェックリスト：今決めること
チェックリストは6点で十分です。1つ目は席数とプラン比率から標準creditsを確定すること。2つ目は2026年9月1日以降の通常枠で再試算すること。3つ目はpaid usageを許可する部署と禁止する部署を明文化すること。4つ目はcost center設計を決めること。5つ目はcloud agentやCLIなど高消費ユースケースの承認ルールを作ること。6つ目は月次レビューKPIをcredits消費、追加費用、停止件数の3つに絞ることです。
加えて、経理や部門長向けの短い説明資料を1ページ作っておくと、月末の混乱を減らせます。「Copilotは席課金だけでなく従量課金がある」「追加利用の責任者は誰か」「停止したときの問い合わせ先はどこか」を先に共有しておくと、情シスだけに判断が集中しにくくなります。
6. FAQ：Copilot Enterpriseへ上げるべきか
Enterpriseへの切り替えは、全社一律ではなく高頻度利用者だけに絞る方が合理的です。補完中心のライトユーザーはBusinessのままでも十分なケースが多く、逆にagent作業や大規模な横断調査を日常的に行うユーザーはEnterpriseの方が予算ブレを抑えやすいです。プラン変更の判断軸は「役職」ではなく「実際の利用ワークロード」に置くべきです。
今回の見直しでやるべきことは、全社アップグレードではなく「誰に追加利用を認めるか」を定義することです。席単価の話だけで終わらせず、予算再予測、budget設定、承認フローをセットで整えておくと、Copilot利用拡大とコスト統制を両立しやすくなります。
AI・Claude研修のご相談は /contact/ へ。Copilot運用ルール整備、承認フロー設計、部門別配賦の設計まで含めて支援できます。
