GitHub Copilot Enterpriseの料金変更を受けて、現場の運用を見直した話

みなさん、こんにちは！
現役IT執行役員のグイグイです⚡

GitHub Copilot Enterpriseの料金体系が、2026年6月から大きく変わりました。

これまでは、月額契約の範囲で比較的気軽に使いやすい感覚がありました。
少なくとも開発者側としては、「Copilotは契約しているから、必要な場面でどんどん使えばいい」と考えやすかったと思います。

しかし、今回の変更でGitHub AI Creditsという単位で利用量が管理される形になりました。

GitHub AI Creditsは、Copilot Business / Enterpriseにおける利用量の課金単位です。
利用時には、入力トークン、出力トークン、キャッシュされたトークンが消費され、使用するモデルごとの単価に応じてCreditsへ換算されます。

つまり、これからは「Copilotを使う」ではなく、「どのモデルで、どのくらいの情報を読み、どのくらい生成させるか」まで、ある程度意識する必要が出てきました。

特に影響が大きいのは、コード補完よりもAIエージェント系の利用です。

コード補完やNext Edit Suggestionsは、従来どおり使いやすい領域です。
一方で、Ask、Plan、Agent、Cloud agent、Copilot code review、Copilot CLIのような使い方は、実際にどの程度Creditsを消費するのかを見ながら運用する必要があります。

今回のプロジェクトで起きていること

私の現場では、現在GitHub Copilot Enterpriseを使ってAI駆動開発を進めています。

今回のプロジェクトでは、2026年6月から8月が開発のメイン期間です。

そして、ちょうどこのタイミングでCopilot Enterpriseの料金体系変更が入りました。

通常、Copilot Enterpriseでは1ユーザーあたり月3,900 Creditsが付与されます。
ただし、2026年6月から8月までは移行期間として、既存顧客向けに1ユーザーあたり月7,000 Creditsが付与されます。

今回のプロジェクトに限って言えば、これは少し幸いでした。

AIエージェントを本格的に使いたい開発メイン期間と、Creditsに余裕がある移行期間が重なっているからです。

ただし、この3ヶ月を「多く使える期間」とだけ見るのは危険です。

9月以降は通常の3,900 Creditsに戻る前提です。
そのため、6月から8月は「使い放題期間」ではなく、9月以降の通常運用に向けた検証期間として捉えることにしました。

まず毎日Creditsを見ることにした

料金体系が変わった直後なので、AIエージェントを動かしたときの実際の消費量がまだ読み切れません。

そのため、しばらくは毎日AI Creditsの利用状況を確認することにしました。

見たいのは、単純な合計だけではありません。

誰が、どの作業で、どれくらいCreditsを使っているのか。
Agent modeを使うと、どのくらい消費するのか。
Plan modeを挟むことで、Agent modeの手戻りが減るのか。
通常のAskやChat利用と、実装を伴うAgent利用では、どの程度差があるのか。

このあたりを実測しないと、9月以降の運用設計ができません。

特にAI駆動開発では、AIにただ質問するだけでは終わりません。

設計書を読ませる。
実装させる。
テストコードを書かせる。
実行結果を渡して修正させる。
静的解析の警告を直させる。

こうした流れになるため、単発のチャットより消費量は大きくなるはずです。

だからこそ、まずは実際の利用状況を見ながら判断することにしました。

モデルはClaude Sonnet 4.6で統一

開発者が使用するモデルは、基本的にClaude Sonnet 4.6で統一することにしました。

理由は、モデルをバラバラにすると、品質もCredits消費量も比較しづらくなるからです。

ある人は軽量モデルを使っている。
別の人は高性能モデルを使っている。
さらに別の人は作業ごとにモデルを切り替えている。

この状態だと、後から利用状況を見ても、消費量の差がモデルによるものなのか、作業内容によるものなのか分かりにくくなります。

Sonnet 4.6で統一しておけば、少なくともモデル差によるブレは減らせます。

そのうえで消費が大きい場合は、対象ファイルが多すぎたのか、出力させる量が多かったのか、エラー修正ループが増えたのか、Cloud agentを長く動かしたのか、といった原因を見やすくなります。

AI駆動開発では、モデル選択も運用ルールの一部として考える必要があると感じています。

自動クレジット追加はオフにした

次に、全体としての自動クレジット追加はオフにしました。

想定外にCreditsを使い切った場合でも、自動的に追加課金され続ける状態にはしたくなかったからです。

AIエージェント系は、作業内容によって消費量が読みにくいところがあります。

特に、複数ファイルを読み、実装し、テストし、修正するような作業では、裏側でどの程度処理が走るのかを利用者側から完全には把握しづらい。

そのため、まずは自動追加を止め、上限の中で実測する方針にしました。

これはAIを使わせないためではありません。

むしろ、安心して使うためです。

開発者単位でも上限を設定した

GitHub Copilot Enterpriseでは、Creditsが個人ごとに完全に分離されるのではなく、Enterprise内の共有プールとして扱われます。

この仕組み自体は便利です。

あまり使わない人の分を、同じ月内でよく使う人が活用できるからです。

ただし、逆に言えば、1人の開発者がAIエージェントを大量に使い、他のメンバーが使うはずだったCreditsまで消費してしまう可能性もあります。

そこで、開発者単位でも一旦利用上限を設定しました。

目的は、1人の利用が共有プール全体に影響しすぎないようにするためです。

ただし、この上限は固定的な制限ではありません。

実際にAIエージェントを有効活用していて、業務上必要な利用で上限に達した場合は、その開発者の上限だけ個別に引き上げればよいと考えています。

最初から全員に大きな枠を渡すのではなく、まずは一定のキャップを置く。
そのうえで、使い方を見ながら必要な人の枠を広げていく。

この方が、共有プールを守りながら、AIをうまく使える人の生産性も止めずに済みます。

つまり、開発者ごとの上限は「使わせないための制限」ではありません。

安全に使うための初期キャップです。

上限がない状態で「自由に使っていい」と言われても、使いすぎたときにどうなるのかが分からず、逆に使いづらくなります。

一定のキャップがあれば、その範囲内では安心して試せます。
そして、本当に価値のある使い方をしている人には、個別に枠を広げればいい。

この運用であれば、チーム全体のCreditsを守りつつ、AIエージェントを有効活用する余地も残せます。

AI駆動開発を業務で使うなら、こうした予算上のガードレールも開発プロセスの一部として考える必要があると思っています。

Ask / Plan / Agentの使い分けも見直した

今回あらためて考えたのが、Ask mode、Plan mode、Agent modeの使い分けです。

この3つは、固定で単価が違うというより、AIが読む量、出す量、内部で動くステップ数が変わることで、結果的に消費量が変わると見ています。

ざっくり言えば、Askは軽い確認や相談向き。
Planは実装前の方針整理向き。
Agentは実装や修正の実行向きです。

単純な消費量だけを見ると、Agent modeは重くなりやすいはずです。

ただし、だからといってPlan modeを省いて、いきなりAgent modeに任せればよいかというと、そうでもありません。

Agent modeで一番もったいないのは、AIが迷うことです。

広く読みすぎる。
不要なファイルまで触る。
間違った方向で実装する。
テストで落ちる。
修正ループが増える。

この手戻りが増えると、結果的にCreditsも時間も使います。

そのため、中規模以上の作業では、先にPlan modeで計画を出させ、人間が確認してからAgent modeに渡す方針にしました。

Plan modeでは、修正対象ファイル、参照のみのファイル、触ってはいけないファイル、実装方針、影響範囲、テスト方針、完了条件などを整理させます。

そのうえで、Agent modeに実装させる。

Plan modeの分だけ一時的にはCreditsを使います。
しかし、Agent modeの手戻りが減るなら、全体としてはその方が安く、品質も安定する可能性があります。

現時点の運用方針

現時点では、以下の方針で運用しています。

コード補完は原則自由。
AskやChatは通常利用OK。
軽微な修正はAgent mode直行も可。
中規模以上の作業はPlan → Agent。
Cloud agentは対象者と用途を限定。
Copilot code reviewは必要なPRに絞る。
開発者の標準モデルはClaude Sonnet 4.6。
全体の自動クレジット追加はオフ。
開発者単位で初期上限を設定。
必要に応じて個別に上限を引き上げる。
AI Creditsは毎日確認。

かなり現実的な運用に寄せたつもりです。

AIを使うこと自体を止めたいわけではありません。

むしろ、今回のプロジェクトではAIエージェントをしっかり使うつもりです。

ただし、業務として使う以上、品質だけでなくコストも見なければいけません。

まとめ

今回のGitHub Copilot Enterpriseの料金体系変更は、かなり大きい変更だと感じています。

ただ、これは単なる値上げの話ではありません。

Copilotがコード補完ツールから、AI実行基盤に近づいている。
だからこそ、利用量に応じた課金になり、現場側にも運用設計が求められるようになった。

そう受け止めています。

今回のプロジェクトでは、6月から8月の開発メイン期間と、Credits増量の移行期間が重なりました。

この期間を使って、AIエージェントを実際にどのくらい使えるのか、どの作業がCreditsを消費するのか、9月以降にどんな上限設定が必要なのかを見極めていきます。

AI駆動開発は、いよいよ「便利だから使う」だけではなくなってきました。

どこまでAIに任せるのか。
誰にどこまで使わせるのか。
どの作業がコストを食うのか。
どうすれば手戻りを減らせるのか。

ここまで含めて設計する段階に入ったと感じています。

#GitHubCopilot
#GitHubCopilotEnterprise
#AI駆動開発
#生成AI活用
#AIエージェント
#システム開発
#開発現場
#プロジェクト管理
#エンジニアリングマネジメント
#業務改善