GitHub Copilotの課金体系が2026年6月1日から大きく変わりました。Copilot Business / Enterpriseは使用量ベース課金に移行し、座席の固定費に加えて1 AI Credit = $0.01 USD での従量課金が加わります。この変化により、どの部門がどれだけAI Creditsを消費するかが予算管理の中心になり、部門別の配賦設計が避けられなくなったのです。
特に開発・QA・情シスの3部門では、Copilotの使われ方が大きく異なります。開発はコード生成や設計支援、QAはテストケース作成や不具合分析、情シスはポリシー設計や横断的なナレッジ活用と、消費パターンも承認フロー も異なるのです。この記事では、GitHub公式の予算管理機能（cost center、user-level budget）を活用しながら、実務的な配賦モデルと3段階の承認フローを整理します。結論から言うと、共通基盤費、変動費、例外費の3層に分け、cost centerごとに可視化し、月次で調整する設計が現実的です。
GitHub Copilotの課金で、まず押さえるべき前提
GitHub公式ドキュメントによれば、Copilot Businessは1ユーザー月額19ドル（座席費）、Copilot Enterpriseは1ユーザー月額39ドルとされています。ただし、これは座席の固定費であり、実際の課金はここに使用量ベースのAI Credits が加算される二層構造になっています。
AI Creditsについて、公式では以下のように定義されています。1 AI Credit = $0.01 USD という固定レート。Copilot Business は1ユーザー月1,900 AI Credits、Copilot Enterprise は1ユーザー月3,900 AI Credits の月額枠が含まれます。ただしこれは個別ユーザーの固定枠ではなく、請求主体単位（organization / enterprise レベル）のプールとして扱われます。つまり、100人のBusiness ユーザーなら190,000 AI Credits が月間プールになり、ヘビーユーザーとライトユーザーが共有する仕組みです。
注意点として、2026年6月1日から2026年9月1日までの間、既存顧客向けプロモーション枠があります。この期間、Business は月3,000 credits、Enterprise は月7,000 credits が提供されます。9月1日以降は標準枠に戻るため、7月・8月の利用パターンを月次で可視化しておくと、9月以降の予算調整がしやすくなります。
AI Credits の対象機能は、Copilot Chat、Copilot CLI、Copilot cloud agent、Copilot Spaces、Spark、およびサードパーティー製 coding agents です。一方、コード補完とnext edit suggestions は AI Credits 課金の対象外であり、すべての有料プランで無制限に利用できます。この点が配賦設計に影響を与えるため、どの機能をどの部門が多く使うかの確認が最初のステップになります。
部門別配賦は『共通基盤費』『変動費』『例外費』に分ける
Copilot費用を部門別に配賦するなら、最初から3つの層に分解して考えるのが実務的です。
第1層『共通基盤費』は、全社導入の基盤として情シスが管理する部分です。最低限の座席費や、全部門共通で使う想定のAI Credits 枠をここに含めます。新入社員研修、全社AI リテラシー向上、方針・ナレッジ検索といった横断的な利用が想定される領域です。この層は情シス部門予算に計上し、個別部門には配賦しません。
第2層『変動費』は、実際のAI Credits 消費を部門・cost center ごとに配賦する部分です。GitHub 公式の budget controls では cost center 単位で消費を追跡できるため、月次で各部門の実利用量をレポートし、その実績をベースに按分します。開発部門がChat を多く使い、QA がテストケース生成で使い、情シスがポリシー設計で使うなら、その比率を月々変動させながら配賦します。この層がCopilot導入効果と直結するため、月次の振り返りで改善されやすい部分です。
第3層『例外費』は、標準運用を超える利用を別枠管理する部分です。frontier モデルの継続利用、cloud agent の長時間実行、新機能PoC 時の追加投資といった、月次の標準利用を想定していないケースがここに入ります。この層は月次承認制にすることで、全社として『ここまでなら許可できる』という裁量を保ちやすくなります。
この3層設計の利点は、配賦のアンバランスを早期に発見しやすい点です。たとえば、初期設計では『開発40% : QA 30% : 情シス30%』と想定していても、実利用で『開発55% : QA 25% : 情シス20%』と異なれば、次月の配賦ルールを調整できます。逆に全額従量課金で各部門に即転嫁すると、学習コストまで現場に押しつけることになり、利用が伸びません。
開発・QA・情シスでの負担按分モデル
実務では、導入初期と定着後で異なる按分モデルを用意するのが現実的です。
【導入初期3か月のモデル】シンプルさを優先して『座席費は情シス一括管理、AI Credits の追加消費分のみ部門配賦』という方式が扱いやすいです。この期間は全社が学習段階であり、部門ごとの消費パターンもまだ不安定なため、固定化すると後で調整が煩雑になりやすいからです。GitHub 公式ドキュメントでも、organization / cost center / user の4階層で予算管理できるため、まずは cost center ごとに可視化し、月次で多い部門だけ利用ルールを見直す流れが無理がありません。
【定着後の安定配賦モデル】3か月のデータが揃ったら、『固定層（共通基盤費）40% + 従量層（部門別配賦）50% + 例外層（承認制）10%』のような構成も検討できます。固定層は情シスが全社基盤として管理し、従量層は各部門の実績配分で按分、例外層は月次に個別判断する流れです。たとえば実績が『開発55% : QA 25% : 情シス20%』なら、従量層25,000 credits の配分は『開発13,750 : QA 6,250 : 情シス5,000』という按分になります。この配分なら全社導入の意思決定コストは本部が持ちつつ、過剰利用は現場の予算に反映できます。
部門ごとのAI Credits 消費特性も参考になります。開発部はコード生成、実装サポート、code review での利用が多くChat やcloud agent への消費が大きい傾向にあります。QA はテストケース作成や不具合再現シナリオの要約で中程度の消費。情シスは利用頻度は少なくても、セキュリティポリシー設計や全社FAQ 作成など、横断的で高価値の利用をします。この特性を無視して人数按分だけすると、開発部に不公平感が出やすいため、最低限『実績ベース月次配分』を導入することが、円滑な運用に不可欠です。
承認フローは『通常利用』『高額利用』『拡張利用』の3段階にする
承認フローを細かくしすぎるとCopilot導入の価値が減ります。おすすめは3段階の設定です。
【第1段階『通常利用』】標準モデル（例：Claude 3.5 Sonnet など）と月次配分予算内の利用は、申請不要です。ユーザーは必要なときにすぐCopilot を使え、意思決定コストがかかりません。この許容範囲を月次で見直し、実績が予算内に収まっていれば、次月も同じ枠で継続します。
【第2段階『高額利用』】frontier モデル（最新・高性能モデル）の継続利用、cloud agent による夜間実行、複数ファイルにまたがる長時間セッションなど、1回の操作で大きくAI Credits を消費する場合は、チームマネージャー承認を経ます。GitHub 公式の user-level budget で『このユーザーは月$30 まで、高額モデルは別途申請』という制御ができるため、承認フローとの相性が良いです。承認者はチームマネージャーとし、月1回の振り返りで判断する流れが回しやすいです。
【第3段階『拡張利用』】部門の月次予算を超える見込みがある、新しいユースケース（新プロジェクト向けのagent 開発など）で追加投資が必要な場合は、情シスと経営企画を含む月次承認に上げます。この層は全社的なリソース配分の議論になるため、『なぜそこまで必要か』『期間はいつまでか』『期待効果は何か』を簡潔に記述する定型書式を用意すると、審査が進めやすくなります。
重要な技術的ポイントとして、GitHub 公式ドキュメントでは『追加使用を許可するか、予算到達で停止するか』を設定できるとされています。デフォルトは『許可』ですが、コスト統制を厳しくしたいなら『停止』に変更し、user-level budget と組み合わせることで『全社プールには余力があるが、このユーザーは個人上限に達したから停止』という制御ができます。これを3段階の承認フローと組み合わせれば、『通常利用は制限なし、高額利用は都度判断、拡張利用は月次判断』という階段的なガバナンスが実装できます。
導入前に確認したいチェックリストとFAQ
導入前のチェックリストとして、以下の5点を確認しておくと、公開後の運用トラブルが減ります。
1) 開発・QA・情シスのどこまでをAI Credits 課金の対象にするか。コード補完は無制限ですが、Chat やagent 利用をすべて対象にするか、職種で制限するか。2) cost center を部門単位で切るか、プロジェクト単位で切るか。GitHub 公式では cost center 単位で include usage cap を自動計算できるため、設計次第で配賦の手間が大きく変わります。3) frontier モデルや長時間エージェント利用の承認者は誰にするか。チームマネージャーか、部門長か。4) 月次の経営指標として『座席数』だけでなく『AI Credits / 人』や『利用部門別比率』まで見るか。可視化の粒度が予算配分の精度に影響します。5) 予算到達時に『停止』するか『追加課金を許す』か。GitHub のデフォルトは追加使用許可なので、明示的に選択する必要があります。
よくある質問のひとつは『コード補完も従量課金になるのか』です。GitHub 公式ドキュメントでは、code completions と next edit suggestions はすべての有料プランで無制限であり、AI Credits 課金の対象外とされています。一方、Copilot Chat、Copilot CLI、Copilot cloud agent、Copilot Spaces、Spark、およびサードパーティー製coding agents は課金対象です。つまり、レビュー機能を多用するチーム、エージェント運用を活発にしたい組織ほど、この違いを正確に理解して配賦ルールに組み込むことが重要になります。
もう一つの質問は『予算超過時はどう止まるか』です。GitHub 公式では user-level budget が『ユーザーが個人で使える上限』を決め、cost center budget が『チーム全体の上限』を決めるとされています。この2つが連動して、『全社プール → cost center → user』の順に制御されます。たとえば全社プールに余力があっても、ユーザーのuser-level budget に達すれば、そのユーザーの利用は止まります。逆に、cost center budget に達すれば、そのチーム全体が止まり、他のチームは影響を受けません。
3つめは『cost center を部門単位か案件単位か』です。開発部全体で月3万円、その中で各プロジェクトはuser-level budget で制限するなら部門単位が良いです。逆に、プロジェクトAとプロジェクトBでAI Credits 予算を分けたいなら、cost center を案件単位で分けることもできます。GitHub 公式では『複数の cost center を跨いだユーザー割り当て』もサポートされているため、柔軟な設計ができます。ただしこうなると月次の集計・配賦計算が複雑になるため、導入初期は『部門 = cost center』で単純化し、実績データが出た後に見直すほうが無難です。
GitHub Copilot や Claude の全社導入で、usage-based billing の予算設計・cost center 設定・承認フロー・利用ルールまでまとめて整えたい場合は、 こちらからお問い合わせください 。部門別配賦設計からPoC 運用、月次レポーティング体制まで一緒に設計できます。
