GitHub の「Cost centers now support AI credit pools」は、GitHub Enterprise Cloud で GitHub Copilot を組織利用している企業向けに、コストセンターごとに月次の included AI credits の使い過ぎを防げるようにする更新です。これまでは企業全体で共有される AI クレジットプールを、特定の部署やチームが先に多く消費してしまう可能性がありました。今回の変更により、各コストセンターが自分たちの Copilot Business / Copilot Enterprise ライセンスに紐づく分を超えて included AI credits を使い続けないよう制御できます。2026年7月2日の GitHub Changelog では、現時点では REST API で利用可能で、コストセンター設定画面での管理は今後提供予定とされています。(The GitHub Blog)
GitHub の新機能・変更点：「Cost centers now support AI credit pools」で確認すべきポイント
今回の更新で重要なのは、GitHub Copilot の AI クレジット管理が「企業全体のプール」だけでなく、コストセンター単位の公平な取り分管理に近づいたことです。
GitHub Copilot の組織・Enterprise 向け請求では、Copilot の利用が AI credits として計測されます。各ライセンスは enterprise の共有プールに AI credits を提供し、プールを超えた利用は追加利用として課金されます。GitHub Docs では、Copilot Business は標準でユーザーあたり月 1,900 AI credits、Copilot Enterprise はユーザーあたり月 3,900 AI credits を含むと説明されています。ただし、既存顧客向けのプロモーション期間などで実際の included credits が変わる場合があるため、最終的な数値は管理画面と最新の契約情報で確認してください。(GitHub Docs)
今回の AI credit pool 対応は、特に次のような組織に影響します。
| 対象 | 確認すべきこと |
|---|---|
| Enterprise 管理者 | コストセンターごとに included AI credits の利用上限を有効化するか |
| 課金・FinOps 担当 | 部署別のチャージバック、ショーバック、予算管理に使えるか |
| 開発部門の責任者 | チームの Copilot 利用が途中でブロックされる可能性があるか |
| 一般ユーザー | 所属チームの上限到達時に Copilot の一部利用が制限される可能性があるか |
何が変わったのか
今回の変更では、コストセンターに対して AI credit pool を有効化できるようになりました。これにより、あるコストセンターが enterprise 全体の shared pool から、自分たちのライセンスが拠出した分を超えて included AI credits を使い続けることを防げます。
GitHub の説明では、AI credit pool はコストセンター予算とは別の制御です。AI credit pool は included usage pool からどれだけ引き出せるかを制御し、cost center budget は共有プールが枯渇した後の metered phase、つまり追加利用分の支出を制御します。両方を同じコストセンターに設定できます。(The GitHub Blog)
| 項目 | 今回の更新前 | 今回の更新後 |
|---|---|---|
| included AI credits の扱い | enterprise 全体の共有プールとして消費 | コストセンターごとに取り分相当の上限を設定可能 |
| 部署別の公平性 | 利用量の多い部署が先に共有プールを消費する可能性がある | ライセンスに基づく自動上限で偏りを抑えやすい |
| 設定方法 | cost center budget などで追加利用を制御 | REST API で AI credit pool を有効化可能 |
| UI 対応 | 該当設定なし | 管理 UI 対応は今後提供予定 |
AI credit pool と cost center budget の違い
混同しやすいのが、AI credit pool と cost center budget の違いです。どちらも Copilot の費用管理に関係しますが、効くタイミングが異なります。
| 制御 | 何を制御するか | 効くタイミング | 主な用途 |
|---|---|---|---|
| AI credit pool / included usage control | コストセンターが共有 included pool から使える量 | 追加課金が始まる前 | 部署ごとの included credits の公平な配分 |
| Cost center budget | コストセンターの追加利用による metered charges | 共有プール枯渇後 | 部署ごとの追加課金上限 |
| Cost center user-level budget | コストセンター内の各ユーザーが使える AI credits | included pool と metered phase の両方 | 部署内の1人あたり利用上限 |
| Universal user-level budget | enterprise 全体のユーザー共通の1人あたり上限 | included pool と metered phase の両方 | 特定ユーザーの過剰消費防止 |
GitHub Docs でも、cost center budget は共有プールの消費量を制限せず、共有プールが枯渇した後の metered charges を制限するものだと説明されています。一方、included usage controls は、metered phase に入る前に、コストセンターが共有 AI credits pool から引き出せる量を制限します。(GitHub Docs)
実務では、AI credit pool だけで追加課金対策が完了するわけではありません。included credits の公平な配分には AI credit pool、追加課金の上限には cost center budget、ユーザー単位の暴走防止には user-level budget を組み合わせるのが現実的です。
どのように上限が決まるのか
AI credit pool を有効化した場合、管理者が手入力で「このコストセンターは何 credits まで」と設定するわけではありません。GitHub が、そのコストセンターに割り当てられた Copilot Business / Copilot Enterprise ライセンスに基づいて上限を自動計算し、ライセンスの追加・削除に応じて調整します。(The GitHub Blog)
REST API の cost centers ドキュメントでは、ai_credit_pool_enabled を true にすると、コストセンターはメンバーのライセンス権利から導かれる量に上限設定されると説明されています。また、この場合に許可されるリソースは User と Team のみです。(GitHub Docs)
ここは実務上かなり重要です。すでに組織やリポジトリを中心にコストセンターを作っている企業では、AI credit pool を使うために、ユーザーまたは enterprise team ベースの割り当てへ見直しが必要になる場合があります。
利用できる対象と前提条件
2026年7月2日の GitHub Changelog では、この機能は GitHub Enterprise Cloud 上の Copilot Business と Copilot Enterprise で利用できるとされています。現時点では REST API で利用可能で、cost center settings UI での管理は今後提供予定です。(The GitHub Blog)
確認すべき前提は次のとおりです。
| 確認項目 | 判断ポイント |
|---|---|
| GitHub Enterprise Cloud を使っているか | GitHub Enterprise Server だけの環境では対象外となる可能性があるため、契約形態を確認する |
| Copilot Business / Enterprise を使っているか | AI credits と usage-based billing の対象か確認する |
| コストセンターを作成済みか | 部署・チーム・事業部単位で cost center が整理されているか確認する |
| コストセンターに User または enterprise team が含まれるか | AI credit pool を有効化する場合、User / Team ベースの割り当てが重要 |
| REST API を使える運用体制があるか | UI 対応前は API で設定・確認する必要がある |
REST API で確認すべき項目
GitHub の REST API ドキュメントでは、cost center API のレスポンスに ai_credit_pool_enabled と ai_credit_pool_state が含まれる例が示されています。ai_credit_pool_state には target_amount と current_amount が含まれ、対象コストセンターの上限と現在量を確認する手がかりになります。(GitHub Docs)
まずは、いきなり設定を変えるよりも、現在のコストセンター一覧を取得して状態を棚卸しするのが安全です。
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/enterprises/ENTERPRISE/settings/billing/cost-centers有効化する場合は、コストセンター更新 API で ai_credit_pool_enabled を指定します。GitHub Docs では、cost center の作成・更新パラメータとして ai_credit_pool_enabled が説明されています。作成時・更新時の必須項目や権限はエンドポイントごとに確認してください。(GitHub Docs)
curl -L \
-X PATCH \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
https://api.github.com/enterprises/ENTERPRISE/settings/billing/cost-centers/COST_CENTER_ID \
-d '{"name":"Engineering","ai_credit_pool_enabled":true}'認証方式にも注意が必要です。Cost center API の該当エンドポイントは、GitHub App user access token、GitHub App installation access token、fine-grained personal access token では動作しないと説明されています。既存の GitHub App ベースの社内自動化でそのまま使えるとは限らないため、検証時点で認証方式を確認してください。(GitHub Docs)
上限に達したときの挙動
AI credit pool の上限に達した場合、GitHub はそのコストセンターのメンバーをブロックするか、enterprise で overage が許可されていれば追加支出として継続させるかを選べると説明しています。(The GitHub Blog)
この設定は、単なる技術設定ではなく運用方針そのものです。
| 方針 | 向いているケース | 注意点 |
|---|---|---|
| 上限到達後にブロック | 部署別予算を厳格に守りたい、追加課金を避けたい | 月末に開発者の作業が止まる可能性がある |
| 上限到達後に追加利用を許可 | 重要プロジェクトの停止を避けたい | cost center budget や enterprise budget を併用しないと支出が膨らむ |
| 一部チームだけ高めに許可 | AI 利用が業務成果に直結する開発チームを優先したい | 部署間のルールを明文化しないと不公平感が出やすい |
開発組織では、最初から全チームを厳格ブロックにするより、利用実績を1〜2請求サイクル確認し、どのチームがどれくらい AI credits を使うのかを見てから調整する方が失敗しにくいです。
実務でよくある誤解と注意点
cost center budget だけでは included pool の消費を止められない
cost center budget は、共有 AI credits pool が枯渇した後の追加課金を制御する仕組みです。つまり、共有プールの段階で「A 部署が B 部署の分まで先に使ってしまう」問題には、cost center budget だけでは十分に対応できません。included pool の公平な取り分を守るには、AI credit pool / included usage control を検討する必要があります。(GitHub Docs)
設定しても過去の消費は再配分されない
GitHub Docs では、included usage controls を有効にしても、すでに消費された enterprise の共有 AI credits pool が遡って再配分されるわけではないと説明されています。有効化後、対象コストセンターのユーザーは、そのコストセンターに紐づくライセンスが拠出した included AI credits を共有します。(GitHub Docs)
月の途中で設定する場合は、導入前にすでに多く消費しているチームがあるかを確認してください。月初からの利用量を見ずに有効化すると、「設定したのに想定より早く上限に達した」と見えることがあります。
User / Team ベースの割り当てを軽視しない
一般的な cost center は、organizations、repositories、users、enterprise teams などをリソースとして割り当てられます。GitHub Docs では、enterprise team を cost center に割り当てると、チームメンバーの参加・離脱に応じてメンバーシップが自動で最新化されると説明されています。(GitHub Docs)
AI credit pool を使うなら、特に enterprise team ベースの設計が有効です。人の異動や入退社が多い組織でユーザーを手動追加し続けると、実際の組織構造とコストセンターがずれやすくなります。
organization budget だけに頼ると予測しづらい場合がある
ユーザーが複数 organization から Copilot ライセンスを受け取る構成では、どの organization に支出が紐づくかが月ごとに予測しにくくなる場合があります。GitHub Docs では、このようなケースではユーザーを直接 cost center に割り当てることで、より予測可能な制御にできると説明されています。(GitHub Docs)
複数 organization をまたぐ enterprise では、「部署別に organization を作っているから大丈夫」と考えるのではなく、Copilot ライセンスの付与経路と cost center の割り当てを照合しましょう。
管理者がまず行うべき確認手順
今回の更新を受けて、Enterprise 管理者や課金担当者は次の順で確認すると実務に落とし込みやすくなります。
| 手順 | 作業内容 | 目的 |
|---|---|---|
| 1 | Copilot Business / Enterprise のライセンス数を部署別に確認 | AI credit pool の基礎となるライセンス配分を把握する |
| 2 | 既存の cost center 構成を確認 | 部署・チーム単位で正しく切れているか確認する |
| 3 | User / enterprise team が cost center に割り当てられているか確認 | AI credit pool を使える構成か判断する |
| 4 | REST API で ai_credit_pool_enabled の状態を取得 | 既に有効な cost center と未設定の cost center を分ける |
| 5 | 上限到達時にブロックするか overage を許可するか決める | 開発停止リスクと追加課金リスクのバランスを決める |
| 6 | cost center budget と user-level budget も併用設計する | included pool と追加課金の両方を制御する |
| 7 | 月次レポートを作る | 設定後の利用傾向、上限到達、追加課金を継続監視する |
特に重要なのは、AI credit pool を「費用削減機能」とだけ見ないことです。実際には、部署間の公平性を保ち、請求説明をしやすくするためのガバナンス機能です。過度に低い制限をかけると開発スピードを落とす可能性があるため、利用データを見ながら調整する運用が向いています。
開発者・一般ユーザーに伝えるべきこと
この変更は管理者向けの更新に見えますが、開発者や一般ユーザーにも影響します。とくに Copilot Chat、エージェント機能、大きなコードベースを対象にした作業などで AI credits を多く使うチームでは、コストセンターの上限到達によって利用が制限される可能性があります。
社内周知では、次の3点を明確にしておくと混乱を避けやすくなります。
| 伝える内容 | 具体例 |
|---|---|
| 上限がある理由 | 部署ごとの included credits を公平に使うため |
| 影響が出る場面 | 上限到達後に Copilot の一部 AI 利用が止まる、または追加課金扱いになる |
| 困ったときの連絡先 | 開発基盤チーム、IT 管理者、FinOps 担当など |
「Copilot が突然使えなくなった」と受け止められると現場の不満につながります。導入前に、上限到達時のメッセージ、申請フロー、例外対応の基準を決めておくことが重要です。
どのような組織で有効化すべきか
すべての企業が同じ設定にすべきではありません。判断基準は、利用量の偏りと部署別の会計管理がどれくらい重要かです。
| 組織の状況 | 推奨方針 |
|---|---|
| 小規模で利用者が少なく、部署別請求が不要 | まずは universal user-level budget と enterprise budget を優先 |
| 部署別のチャージバックが必要 | cost center ごとに AI credit pool と cost center budget を検討 |
| 特定チームだけ AI 利用が極端に多い | AI credit pool に加えて、個別 user-level budget も検討 |
| 人事異動が多い | enterprise team を cost center に割り当て、メンバー同期を活用 |
| 追加課金を極力避けたい | 上限到達時にブロックする設定と budget の停止設定を確認 |
GitHub Docs の最適化ガイドでも、各 business unit が自分たちのライセンスで拠出した AI credits の範囲に収まるようにしたい場合は、cost center に included usage control を適用する構成が紹介されています。(GitHub Docs)
まとめ：AI credit pool は Copilot 費用管理を部署単位で現実的にする更新
GitHub の「Cost centers now support AI credit pools」は、Copilot の AI credits を enterprise 全体で共有しつつ、部署やチームごとの公平性を保つための重要な更新です。
今回のポイントは次のとおりです。
| ポイント | 内容 |
|---|---|
| 目的 | コストセンターが自分たちのライセンス分を超えて included AI credits を消費しすぎないようにする |
| 対象 | GitHub Enterprise Cloud の Copilot Business / Copilot Enterprise |
| 現在の提供形態 | REST API で利用可能、UI 管理は今後提供予定 |
| 設定単位 | User または enterprise team を含む cost center が実務上の中心 |
| 併用すべき制御 | cost center budget、user-level budget、enterprise budget |
| 注意点 | 設定は過去の消費を再配分せず、追加課金対策には別途 budget 設計が必要 |
まずは REST API で既存 cost center の ai_credit_pool_enabled と ai_credit_pool_state を確認し、部署別のライセンス数、利用実績、追加課金方針を整理しましょう。そのうえで、開発を止めない範囲で included AI credits の公平な配分と予算統制を両立させることが、今回の更新を実務で活かす最短ルートです。
コメント