GitHub Copilotの料金｜AIクレジットで見る5項目
目次
はじめに
月額単価を確認して人数を掛けた。それでGitHub Copilotの予算申請を出そうとすると、2026年6月以降は説明が足りない。
現在の法人向けプランには、ユーザー単位の月額料金に加えてAIクレジットが含まれる。エージェント、チャット、コードレビューなど、使う機能によって消費量が変わり、上限を超える利用には追加費用が発生し得る。つまり、GitHub Copilotの料金は「シート数×月額」だけでは決まらない。
導入前に決めたいのは、誰へ配るか、何に使うか、どこまで使えるか、超過時にどう止めるか、何を成果とするかの5項目だ。料金表を眺める順番ではなく、チームの運用を設計する順番で整理する。
GitHub Copilotの料金体系を先に整理する
2026年8月6日時点の組織・企業向け公式料金では、Copilot Businessは1ユーザーあたり月額19ドルで月1,900 AIクレジット、Copilot Enterpriseは月額39ドルで月3,900 AI クレジットが含まれる。EnterpriseはGitHub Enterprise Cloudが前提になる。
| 法人向けプラン | 月額料金 | 標準のAIクレジット | 既存顧客向け移行枠（9月1日まで） |
|---|---|---|---|
| Copilot Business | 19ドル／ユーザー | 1,900／ユーザー | 3,000／ユーザー |
| Copilot Enterprise | 39ドル／ユーザー | 3,900／ユーザー | 7,000／ユーザー |
AIクレジットは組織または企業内でプールされる。含有量を超えて利用する場合の基準は1 AIクレジットあたり0.01ドルで、追加利用には予算設定が関わる。一方、コード 補完や次の編集候補は有料プランで無制限とされている。すべての操作が同じ従量課金になるわけではない。
また、2026年6月1日の料金改定で、利用量に基づく課金とAIクレジットの考え方が導入された。6月1日時点の既存顧客には、9月1日までBusinessで3,000、Enterpriseで7,000クレジットという移行枠がある。上表の標準枠と混同せず、申請時には自社契約画面に表示される付与量と適用期間を確認したい。
1. シート数は「配る人数」ではなく役割で決める
最初の判断は、全エンジニアへ一斉配布するかどうかではない。役割ごとに利用場面を分けることだ。
- 日常的に実装する開発者
- プルリクエストをレビューするリードエンジニア
- 障害調査や保守で既存コードを読む担当者
- 要件・受け入れ条件を確認するPMやテスト担当者
- 検証期間だけ参加する協力会社
同じ「開発メンバー」でも、毎日エージェントを使う人と、月に数回レビューで使う人では消費が違う。利用目的が曖昧なまま人数だけで契約すると、使われないシートと、一部ユーザーへの消費集中が同時に起きる。
公式の請求説明では、シートを月途中で追加すると日割りで請求される一方、削除したシートの課金は請求サイクルの終了まで続くとされている。入退場が多い案件では、付与・回収の担当者と実施日を運用表へ入れておきたい。
最初は対象組織やチームを絞り、2週間程度の検証で「役割」「利用機能」「利用頻度」を記録する。その結果から本配布数を決めるほうが、使わないシートを抱えにくい。
2. AIクレジットは機能別に分けて見積もる
次に、AIクレジットを一つの総量としてだけ見ない。何に消費したかを分ける。
たとえば、コード補完、チャット、エージェントによる実装、コードレビューでは、仕事の性質が違う。さらに同じ機能でも、選ぶモデル、入力・出力トークン量、キャッシュの利用、処理回数によってクレジット消費が変わる。レビュー機能はAIクレジットだけでなくGitHub Actionsの実行時間も消費する場合がある。導入後に総額だけを見ても、どの機能とモデルが費用と成果を生んだか判断しにくい。
機能別の利用台帳には、次を置く。
| 利用 場面 | 対象者 | 測る利用量 | 対応する成果 |
|---|---|---|---|
| コード補完 | 開発者 | 利用人数・頻度 | 実装時間、入力負荷 |
| エージェント | 開発者 | モデル・入出力・処理回数・AIクレジット | 完了した作業、手戻り |
| コードレビュー | レビュー担当 | モデル・AIクレジット・Actions時間 | 待ち時間、指摘の有効率 |
| 調査・説明 | 保守担当 | モデル・入出力・キャッシュ・AIクレジット | 調査時間、引き継ぎ時間 |
「月1,900クレジットあれば足りるか」という問いには、平均だけでは答えられない。軽量なモデルで短い質問を繰り返す使い方と、高性能モデルへ大きな文脈を渡して長時間のエージェント処理を行う使い方では、同じ回数でも消費が変わる。プール方式では、重い利用者が全体の枠を使う可能性もある。個人別・機能別・モデル別・案件別の四つで偏りを確認すると、予算超過の原因を説明しやすい。
3. BusinessとEnterpriseは管理要件で選ぶ
BusinessとEnterpriseの差を、含まれるAIクレジットだけで判断すると危ない。どの単位でポリシーを管理し、どこまでGitHub上の知識と連携し、誰が利用状況を監査するかで選ぶ。
GitHubの法人向けプラン選定ガイドでは、BusinessとEnterpriseを組織ごとに選べること、EnterpriseではGitHub.com上の体験や企業向けのカスタマイズを広げられることが示されている。プラン比較ページでは、法人プランにライセンス・ポリシー管理や知的財産に関する補償が含まれる点も確認できる。
選定会議では、次の質問を使う。
- 利用者を組織単位で一元管理したいか
- 利用を許可・禁止する機能を誰が決めるか
- 企業内のGitHub情報との連携をどこまで必要とするか
- 利用状況をどの粒度で監査したいか
- GitHub Enterprise Cloudをすでに利用しているか
Enterpriseの月額が高いから高機能、という選び方ではなく、必要な管理要件を満たす最小のプランを選ぶ。管理要件が定まっていなければ、料金差の妥当性も説明できない。
4. 超過費用には予算上限と停止条件を置く
GitHub Copilotの料金で見落としやすいのが、追加利用を許可する条件だ。予算を設定すれば超過利用が可能になるが、誰が上限を決め、到達時に何を止めるかを先に定義しておく必要がある。
20人へBusinessを配る単純な例なら、基本料金は月380ドル、標準枠は合計38,000クレジットになる。Enterpriseなら月780ドル、標準枠は合計78,000クレジットだ。6月1日時点の既存顧客に適用される移行枠なら、9月1日まではそれぞれ60,000、140,000クレジットになる。これは公式単価と付与量を掛けた例であり、税、為替、Actions利用料、個別契約条件は含まない。
ここへ次のルールを足す。
- GitHub標準の75%、90%、100%の予算通知を受ける管理者を決める
- ユーザー別の上限を設け、例外申請の承認者を決め る
- 顧客案件では案件コードと利用者をひも付ける
- 上限到達時もコード補完を続けるか、追加消費機能を止めるか決める
- 月末に未使用シートと消費上位者を見直す
予算上限だけでは不十分だ。「超えたら止まる」では、納期直前に開発が詰まる。通知、承認、縮退動作、翌月の見直しまでセットにする。
協力会社が参加するSIer案件では、誰の契約へシートを載せるか、AI利用料を見積もりへ含めるか、生成物のレビュー責任を誰が持つかも明確にする。自社共通費にするのか、案件別原価にするのか、協力会社が負担するのかで見積額は変わる。顧客見積へ載せる場合は、基本シート、追加クレジット、Actions利用料のどこまでを含むか、上限超過を変更見積にするかを明記する。料金・契約固有の責任分界を残しておけば、月末に消費が増えても顧客と協力会社の間で押し付け合いになりにくい。
5. 費用対効果はコード量ではなく工程時間で測る
最後に、導入効果を「生成したコード行数」だけで測らない。コードが増えても、レビューや修正が増えれば全体は速くならない。
効果測定は、導入前後で次を比べる。
- 要件確定から最初のプルリクエストまでの時間
- プルリクエストのレビュー待ち時間
- AI生成部分への修正回数
- 受け入れテス トでの差し戻し件数
- 障害調査と引き継ぎにかかった時間
- AIクレジット1,000あたりの完了作業数
Copilotが期待外れになる前提条件でも整理した通り、入力する要件が曖昧なら、生成速度が上がっても手戻りが増える。AIコーディングの費用対効果は、ツールの性能だけでなく、要件、設計、レビュー、受け入れ条件の品質で変わる。
2週間の試行なら、最初の週で利用量と作業時間を記録し、2週目で対象機能と上限を調整する。試行終了時には、継続、対象者の変更、プラン変更、停止の四つから判断する。なんとなく便利だった、で本契約へ進めないことが重要だ。
導入前に作る一枚の利用設計表
料金試算と運用判断を分けず、一枚の表へまとめる。
| 項目 | 決める内容 | 証跡 |
|---|---|---|
| 利用者 | 役割、人数、付与・回収日 | シート台帳 |
| 利用機能 | 補完、チャット、エージェント、レビュー | 利用方針 |
| 予算 | 基本料金、追加上限、通知閾値 | 予算設定画面 |
| 権限 | 許可機能、対象リポジトリ、承認者 | ポリシー設定 |
| 成果 | 時間、品質、手戻り、継続条件 | 導入前後の記録 |
この表に担当者と見直し日を加える。契約担当だけで作らず、開発責任者、セキュリティ担当、経理、案件PMが同じ数字を見る。料金、権限、成果が別々の資料にあると、利用を増やす判断と費用を止める判断がつながらない。
AI開発ツールが上流工程へ広がる変化やAIが既存コードを理解する仕組みも合わせて読むと、費用だけでなく、ツールへ渡す設計情報とレビュー責任まで整理できる。
AIコーディングの料金を開発仕様へつなぐ
GitHub Copilotの料金を正しく見積もるとは、最安プランを選ぶことではない。利用者、機能、上限、停止条件、成果指標を合意し、予算と開発プロセスをつなぐことだ。
AIコーディングツールは、要件が曖昧な状態を自動で解決してはくれない。むしろ生成量が増えるほど、レビュー条件、権限境界、受け入れ基準が必要になる。料金設計と仕様設計を同じタイミングで行えば、「使い始めたが費用と成果を説明できない」という事態を避けやすい。
株式会社Atsumellは、AIコーディングを導入するチームに向けて、利用範囲、権限、予算上限、レビュー条件を開発仕様として整理している。ツール選定だけでなく、要件・設計・検証まで一緒に整えたい場合は、Atsumellへ相談してほしい。
