GitHub Copilotは2026年6月1日から、組織・エンタープライズ向けでもrequestベースではなくGitHub AI Creditsを基準にしたusage-based billingへ移行します。移行直後に経理と情シスが最初にぶつかるのが、請求書とGitHub画面の数字が一見そろわない問題です。席数の固定費、AI Creditsの含み枠、超過利用、保留中の認証オーソリ、UTC基準の締め時刻が別々に効くためです。この記事では、6月移行後の初回請求書をどこで照合すべきかをGitHub公式ドキュメントベースで整理します。
先に結論を書くと、初回請求書の確認は「請求書そのもの」だけでは足りません。最低でも Billing & Licensing の Metered usage、AI usage、usage report の3点を並べ、席数と追加利用を分けて照合する必要があります。特に既存顧客は2026年6月1日から9月1日まで、Copilot Businessが1ユーザー月3,000 AI Credits、Copilot Enterpriseが7,000 AI Creditsのプロモ枠になるため、標準枠だけで計算すると差分を誤読しやすいです。
6月の初回請求で何が変わるのか
GitHub公式の usage-based billing for organizations and enterprises では、Copilot Chat、CLI、cloud agent、Spaces、Spark、third-party coding agents などの利用がAI Credits課金の対象で、コード補完とnext edit suggestionsはAI Credits課金の対象外とされています。つまり、初回請求では「席は増えていないのに利用額だけ増えた」ケースが起こり得ます。これは無駄ではなく、モデル利用やagent系機能の増加が原因である可能性があります。
AI Creditsは1 credit = 0.01米ドルで、組織全体またはenterprise全体の共有プールとして扱われます。Businessは通常1,900、Enterpriseは3,900 AI Creditsが各ライセンスに含まれますが、既存顧客は移行後3か月だけ増量枠が入ります。6月請求を読むときは、標準枠とプロモ枠のどちらが適用されている月かを先に確認しないと、超過課金だと誤認しやすいです。
請求書と一緒に必ず開く3つの画面
1つ目は Billing & Licensing の Metered usage です。GitHub公式はここで product や SKU、期間を切って利用額を追えると案内しています。初回請求の照合では product: Copilot に絞り、ライセンス系の固定費と metered usage を分けて見ます。請求書の総額だけを追うのではなく、どこまでが席コストで、どこからが追加利用かを分離して見るのが第一歩です。
2つ目は AI usage です。GitHub公式では enterprise owner や billing manager が、ユーザー別・モデル別のAI Credits消費をここで深掘りできるとされています。請求額が想定より高い月は、いきなり誰かを責めるのではなく、重いモデルやcloud agent利用が増えたのか、特定チームに偏ったのかをこの画面で切り分けます。組織オーナーがユーザー別データを直接見られない場合は usage report をダウンロードして補います。
3つ目は usage report です。GitHub公式の billing reports reference では、`date`、`sku`、`quantity`、`gross_amount`、`discount_amount`、`net_amount`、`organization`、`cost_center_name`、`model` などが確認できます。特に初回請求では、discount_amount が含み枠ぶん、net_amount が実際の請求対象ぶんという読み方を揃えると、経理と情シスの会話が噛み合いやすくなります。
初回請求書で照合したい6項目
確認順は6つで十分です。1. 請求対象月がUTC基準でどこからどこまでか。2. 月末時点の席数が想定どおりか。3. Business席とEnterprise席が混在していないか。4. 含み枠のAI Creditsがどれだけ discount として吸収されたか。5. 超過利用の net_amount が発生しているか。6. 保留中の認証オーソリが一時表示されていないか。GitHub公式の billing cycle はCopilotの請求サイクルがUTCで動くこと、usage-based costs に対して一時的な authorization hold が表示される可能性があることを明記しています。
実務では、請求書の総額と usage report の gross_amount を直接比べないことが重要です。gross_amount は利用総額で、含み枠や割引前の数字です。請求照合に使うべきなのは net_amount 側です。一方で、超過利用がゼロでも pending charge が見えていると経理が不安になりやすいため、authorization hold は確定請求と別物だと共有しておくと混乱を減らせます。
経理と情シスで役割を分けると早い
経理側は、請求対象期間、固定費と超過利用費の分離、保留中請求の有無、cost center配賦の元データ確保に集中すると効率的です。情シス側は、Seat assignment、AI usage、モデル別消費、budget設定、停止条件を確認します。初回請求を1人で見ると、請求の読み方とプロダクト設定の読み方が混ざって原因特定が遅れます。役割を分けて同じ usage report を見るほうが早いです。
特にenterprise配下で複数orgが同じユーザーに席を付けている場合は注意が必要です。GitHub公式の seat assignment では、同一enterprise内で同一ユーザーに複数orgから席が付与されても enterprise は1回だけ請求され、どのorgに計上されるかは月ごとにランダムだと説明されています。つまり、部門別の見え方が先月と今月で変わっても、重複請求とは限りません。初回請求時は organization 列つきの usage report で説明可能な状態にしておくべきです。
差分が出たときの典型パターン
差分の多くは4パターンに分けられます。1つ目は、月末ぎりぎりの席削除がUTCでは翌月扱いになっているケースです。2つ目は、含み枠で相殺される前の gross_amount を見て高いと感じているケースです。3つ目は、追加利用を許可していたため net_amount が出ているケースです。4つ目は、authorization hold を確定請求と見間違えているケースです。初回請求の社内説明では、この4パターンを先回りで書いておくと問い合わせが減ります。
もし追加利用が想定外だった場合は、budget controls の見直しも必要です。GitHub公式は user-level、cost-center、enterprise spending limit、organization-level の予算管理を案内しており、追加利用を許可するかどうかと、予算上限到達時に止めるかどうかは別設定です。請求照合で終わらせず、翌月の再発防止までつなげると運用が安定します。
よくある質問
Q. 初回請求書だけ見れば十分ですか。A. 不十分です。GitHub公式は Metered usage、AI usage、usage report の併用を前提にしています。Q. 組織オーナーでもユーザー別の重い利用者を見られますか。A. 直接は見えない場合があり、そのときは usage report をダウンロードして確認します。Q. 複数orgから同じ人に席が付いていたら二重請求ですか。A. 同一enterprise内なら原則1回請求で、どのorgに計上されるかはランダムです。
Copilotの初回請求書チェック表や、経理と情シスが同じ数値で会話できる運用テンプレを整えたい場合は、AI・Claude研修のご相談はこちらから。
