3行まとめ
GitHub Copilotのusage-based billingが有効化され、code reviewもAI Creditsの確認対象になる。
レビューのモデル利用はAI Credits、agentic infrastructureはGitHub Actions minutesとして分けて見る。
private repositoryでGitHub-hosted runnerを使う場合は、Actions minutes枠と超過分を確認する。
public repositoryでは標準GitHub-hosted runnerのActions minutesは無料だが、AI Creditsの確認は別に残る。
- GitHub Copilot code reviewは、2026年6月1日からGitHub AI Creditsに加えて、条件に応じてGitHub Actions minutesも見る必要がある。焦点は単純な値上げではなく、Copilot側のAI使用量と、GitHub Actions側のrunner使用量を別々に追うことだ。
- private repositoryで標準のGitHub-hosted runnerを使うレビューは、既存のActions minutes枠を消費し、超過分は通常のGitHub Actions料金の対象になる。public repositoryでは標準GitHub-hosted runnerのActions minutesは無料だが、Copilot code review自体のAI Credits消費まで無料になるわけではない。
- 2026年6月2日JST時点のGitHub ChangelogとGitHub Docsで確認すると、管理者が最初に見るべきなのは、AI Creditsの帰属、repository種別、runner設定、user-level budget、非ライセンスユーザーと自動レビューの扱いである。
GitHub Copilotのusage-based billingが2026年6月1日に有効化されたことで、Copilot Chatやagent系機能だけでなく、Copilot code reviewの請求も見直しが必要になった。直近ではGitHub Changelog、GitHub Docs、コミュニティ投稿で、AI Creditsの消費、Actions minutes、budget上限の見え方に関心が集まっている。ただし、この記事で事実として扱うのはGitHub公式のChangelog、Docs、Blogで確認できる内容に限る。
Microsoft Watch JapanはMicrosoft Corporation、GitHub, Inc.および関係会社とは非提携である。本記事はGitHub CopilotとGitHub Actionsの利用条件を整理するもので、投資助言、売買推奨、短期株価見通しではない。
MicrosoftとGitHubの開発者向け更新は、製品・サービス・ソリューションの中でも確認範囲が広がりやすい。今回の記事では、GitHub Copilot code reviewの課金変更だけに絞り、Microsoft 365 CopilotやAzure AI Foundryの更新とは分けて読む。月内の関連更新は2026年6月 重要トピックまとめからも追える。
このテーマをもう少し広げて見るなら、GitHub Copilot appがBuild 2026でプレビュー拡大：使える対象、キャンバス、サンドボックス確認ポイント と GitHub Copilot CLIがBuild 2026で刷新：音声入力、スケジュール実行、Rubber Duckの確認ポイント も合わせて確認してください。code reviewの課金確認後に、同じGitHub Copilot領域で使える新しいアプリ体験を確認できる。
AI CreditsとActions minutesはどこで分かれるか
Copilot code reviewを単に二重課金と呼ぶより、AI CreditsとActions minutesを別々の確認面として扱うほうが実務では読み違えにくい。
今回の変更でいちばん混乱しやすいのは、Copilot code reviewの費用が一つの画面、一つの単位だけでは見えにくいことだ。GitHub Docsでは、Copilot code reviewは二つの側面で扱われる。レビューそのもののモデル利用はAI Credits、レビューを支えるagentic infrastructureはGitHub Actions minutesだ。
ここをまとめて「二重課金」とだけ呼ぶと、実務ではかえって判断しにくい。AI Creditsは誰のCopilot利用として発生したかを見る。Actions minutesはどのrepositoryで、どのrunnerを使って、どの枠を消費したかを見る。この二つは帰属先も、確認画面も、止め方も違う。
AI Credits側で見るもの
根拠
GitHubの2026年6月1日Changelogでは、usage-based billingが全Copilotプランで有効化され、各プランは消費したGitHub AI Creditsにもとづいて請求されると説明されている。2026年4月27日のChangelogでも、Copilot usageはcode reviewを含めてusage-based billingの下でAI Creditsとして扱われると案内されていた。
GitHub Docsのmodels and pricingページでは、ほとんどのCopilot機能では利用モデルを見て価格表と照合できる一方、Copilot code reviewは例外だとされている。code reviewではモデルが自動選択され、利用者には開示されないため、レビューごとのトークン単価を単純に逆算しにくい。
AI Creditsは、Copilotがモデルへ送る入力、出力、キャッシュされた文脈などのトークン使用量に応じて消費される。GitHub Docsでは、1 AI creditは0.01米ドルに換算されると説明されている。これは見積もりの単位として重要だが、code reviewではモデルが非表示であるため、通常のチャットよりも事前の精密見積もりが難しい。
帰属
AI Creditsの帰属は、レビューの起点で変わる。手動でCopilot reviewをリクエストした場合は、そのリクエストをしたユーザーを見る。repository policyでpull request作成時に自動レビューが走る場合は、pull requestの作成者を見る。
GitHub Docsでは、pull requestがGitHub Actionsやbotによって作られた場合、識別できるtrigger user、またはdesignated billing ownerが関係すると説明されている。人間の開発者が明示的に押したレビューだけでなく、bot、CI、テンプレート生成、外部連携で作られるPRも含めて、誰の利用として出るのかを確認しておきたい。
Actions minutes側で見るもの
条件
Copilot code reviewのagentic capabilitiesは、broader repository contextを集めたり、public preview中の機能を動かしたりするためにGitHub Actionsを使う。既定では標準のGitHub-hosted runnerを使うため、private repositoryではActions minutesを消費する。
GitHubの4月27日Changelogでは、private repositoryで実行されるレビューは、既存プランのActions minutes枠から分が消費され、含まれる分を超えた使用は通常のGitHub Actions料金で請求されると説明されている。public repositoryではActions minutesは引き続き無料とされている。
この「無料」はActions minutesについての話だ。public repositoryでも、Copilot code reviewのAI Credits消費は別の確認対象として残る。公開OSSのメンテナーや企業の公開repository担当者は、Actions分とAI Credits分を切り離して見る必要がある。
注意点
GitHub Docsでは、Actions minutesはrepositoryに帰属し、そこからenterpriseやcost centerへ紐づく場合があると説明されている。一方、AI Creditsはレビューを依頼したユーザーやPR作成者に寄る。つまり、Copilotの利用者別画面だけを見ても、repository側で増えたActions minutesまでは見切れない。
逆も同じだ。Actions usageを見て「今月はレビューのrunner分が少ない」と分かっても、code reviewで使ったAI Creditsまで少ないとは限らない。モデル側の利用、context gathering、runner実行時間は、別々の数字として突き合わせる。
二つの確認面を同じ表で突き合わせる
確認項目
GitHub Docsでは、Copilot code reviewに関連するGitHub Actions usageを見る方法として、GitHub Actions metricsでcopilot-pull-request-reviewer workflowをfilterすること、Billing Usage Reportでworkflow_pathを見ることが示されている。2026年6月1日以降のworkflow_pathはdynamic/agents/copilot-pull-request-reviewerとして扱われる。
管理者は、少なくとも次の組み合わせで確認したい。
- Copilot側では、AI Creditsの消費、追加使用、user-level budget、対象ユーザーを見る。
- Actions側では、repository、workflow、runner type、included minutes残量、超過分を見る。
- Billing Usage Reportでは、期間、workflow_path、repository、cost center、enterpriseを合わせる。
上振れと下振れ
費用が上振れしやすいのは、全pull requestで自動レビューを有効にしているrepository、PR数が多いチーム、巨大なrepository、レビュー再実行が多い運用、larger GitHub-hosted runnerを選んだ環境だ。レビュー品質を上げるために広いcontextを使うほど、AI CreditsとActions minutesの両方に影響が出る可能性がある。
下振れ、つまりレビューが止まる側のリスクもある。user-level budgetやenterpriseのspending limitに達すると、AI Creditsを消費する機能がブロックされる場合がある。GitHub-hosted runnersを無効にしている組織では、agentic capabilitiesが使えず、より限定的なreviewへ戻る可能性もある。費用を抑える設定は、レビュー体験を同時に変える。
private repositoryとpublic repositoryで何が違うか
- 1まずpublic/privateを分ける
Actions minutesの扱いはrepository種別で読み分ける。AI Creditsの確認はどちらにも残る。
- 2標準runnerのActions minutesは無料
public repositoryで標準GitHub-hosted runnerを使うActions usageは無料として扱われる。
- 3含まれる分と超過分を見る
標準GitHub-hosted runnerの利用はActions minutes枠を消費し、超過分は通常のActions料金の対象になる。
- 4性能と分単位料金を別に確認
標準runnerより高い性能を使える一方、分単位料金は高くなる。
- 5Actions minutesではなく運用負担を見る
Actions minutesを消費しないが、ネットワーク、隔離、保守、セキュリティ監査が必要になる。
無料と書ける範囲は標準GitHub-hosted runnerのActions minutesに限り、Copilot code review全体が無料になるという意味ではない。
Copilot code reviewの課金変更を読むときは、まずrepositoryがprivateかpublicかを分ける。この分岐を飛ばすと、Actions minutesの説明がすべてのrepositoryに同じように当てはまると誤解しやすい。
public repositoryの扱い
根拠
GitHub Actions billingのDocsでは、public repositoryで標準のGitHub-hosted runnerを使う場合、Actions usageは無料と説明されている。GitHubの4月27日Changelogも、Copilot code reviewのActions minutesについて、public repositoryでは無料のままだと説明している。
OSSや公開SDK、公開ドキュメントrepositoryでCopilot code reviewを使うチームにとって、この点は大きい。Actions minutesの枠を減らさずにレビューを回せる可能性があるからだ。
注意点
ただし、public repositoryならCopilot code review全体が無料になる、とは読まない。AI CreditsはCopilot usageの単位として別に存在する。public repositoryの無料扱いは、標準GitHub-hosted runnerのActions minutesに関する説明だ。
また、public repositoryでもレビュー対象の情報公開範囲、外部contributorのPR、botが作るPR、レビューコメントの品質確認は残る。Copilotのフィードバックは必ず人間が検証する必要があるとGitHub Docsでも注意されている。
private repositoryの扱い
根拠
private repositoryでは、標準のGitHub-hosted runnerを使うActions usageが、アカウントやorganizationの含まれる分に対して計測される。含まれる分を超えれば、追加のGitHub Actions料金が発生する。
Copilot code reviewも、agentic capabilitiesのためにGitHub Actionsを使うため、private repositoryではこの枠に乗る。既存のCI、test、deploy workflowが使うActions minutesに、Copilot review由来のworkflowが加わるイメージで見たほうがよい。
確認項目
private repositoryで最初に見る項目は、included minutes、月次リセット、repository owner、cost center、enterprise budget、Actions spending limitだ。すでにCIでActions minutesを多く使っている組織では、Copilot code reviewが小さく見えても、月末の超過に寄与する可能性がある。
Actions minutesは、レビューを依頼した個人のCopilotプランだけで完結しない。repositoryの所有者、organizationの請求、enterpriseやcost centerの割り当てまで確認する。開発チームだけでなく、billing managerやplatform teamが同じ数字を見られるようにしておきたい。
書き分けるべき表現
注意点
今回の変更を「Copilot code reviewが有料化」とだけ書くと、すでにCopilotの有料プランで使っている利用者には意味が曖昧になる。正確には、2026年6月1日以降、Copilot usageはAI Creditsへ移行し、Copilot code reviewのagentic infrastructureは条件に応じてGitHub Actions minutesも消費する、という整理だ。
無料、有料、追加請求という言葉を使うときは、何についての話かを毎回分ける。AI Creditsなのか、Actions minutesなのか。private repositoryなのか、public repositoryなのか。standard runnerなのか、larger runnerなのか。ここが実務の分かれ目になる。
評価基準
管理者は、すべてのrepositoryを次の4区分で棚卸しすると見通しがよくなる。
- public repositoryで標準GitHub-hosted runnerを使うもの
- private repositoryで標準GitHub-hosted runnerを使うもの
- private repositoryでlarger GitHub-hosted runnerを使うもの
- self-hosted runnerを使う、または使う予定があるもの
その上で、自動レビューの対象branch、PRの平均件数、large PRの頻度、botが作るPRの扱いを重ねる。課金変更は料金表だけでなく、pull request運用の設計変更でもある。
runner設定で費用と挙動はどう変わるか
runner設定は費用だけでなく、レビュー品質、ネットワーク到達性、Copilot cloud agentへの影響も一緒に確認する。
Copilot code reviewは、ただコメントを返すだけの軽い処理ではない。GitHub Docsでは、full project context gatheringなどのagentic capabilitiesを動かすためにGitHub Actions runnersを使うと説明されている。runnerの選び方は、費用、性能、ネットワーク、セキュリティの話になる。
defaultはstandard GitHub-hosted runner
根拠
GitHub Docsでは、Copilot code reviewは既定で標準のGitHub-hosted runnerを使うと説明されている。private repositoryでは、このrunner利用がActions minutesの消費につながる。
また、GitHub-hosted runnersを無効化している組織ではagentic capabilitiesが使えず、code reviewはより限定的なreviewへ戻る可能性があるとされている。費用を抑えるためにrunnerを止めると、レビューの挙動も変わる。
注意点
標準runnerを使う場合、導入の手間は小さい。すでにGitHub Actionsが使えているrepositoryであれば、追加のrunner管理をせずに始めやすい。一方で、private repositoryのレビュー数が増えると、CIと同じActions minutes枠を使うため、既存のbuildやtestと競合する可能性がある。
Copilot code reviewだけを見て「1回のレビューが短いから問題ない」と判断せず、CI全体の月次使用量に重ねるべきだ。特にrelease前、依存関係更新、renovateやdependabotの大量PR、モノレポの大きな変更では、短期間にreview workflowが増えやすい。
larger runnerとself-hosted runnerの違い
条件
larger GitHub-hosted runnerは、標準runnerより高いCPU、メモリ、disk、場合によってはAzure private networkingなどを使える。GitHub Docsでは、larger runnerの利用は標準runnerより高い分単位料金になると注意されている。レビュー速度や大規模repositoryでの性能を優先する場合は選択肢になるが、費用は別に見積もる必要がある。
self-hosted runnerはActions minutesを消費しないとGitHub Docsで説明されている。Copilot code reviewでself-hosted runnerを使う場合、公式にサポートされるのはARC、Actions Runner Controllerで管理されるrunnerだ。さらに、Copilot code reviewはUbuntu x64 Linux runnersに対応するとされている。
確認項目
self-hosted runnerを使う場合、費用の見方はGitHub Actions minutesから自社のインフラ運用へ移る。runnerの更新、scale set、隔離、秘密情報、ネットワーク、ログ、脆弱性対応を自社で管理する必要がある。
GitHub Docsでは、self-hosted runnerのnetwork security controlsを設定し、GitHub Actions self-hosted runnerに必要な標準hostに加え、api.githubcopilot.com、uploads.github.com、user-images.githubusercontent.comへの接続を許可する必要があると説明されている。これは単なる節約策ではなく、セキュリティ設計を伴う運用変更だ。
organization-level default runner
根拠
2026年6月1日のGitHub Changelogでは、organization adminsがCopilot code reviewで使うdefault runnerを組織横断で設定できるようになったと案内されている。repositoryごとに個別設定しなくても、標準のrunner選択を管理できる。
Changelogでは、このdefault runner設定はCopilot code reviewだけでなく、Copilot cloud agentにも関係するものとして説明されている。したがって、code reviewの費用だけを見て変更すると、cloud agentの開発体験にも影響する可能性がある。
注意点
組織レベルのdefault runnerを設定する場合は、repository overrideを許すかどうかも運用ルールになる。全repositoryで一律にself-hosted runnerへ寄せるのか、特定のprivate repositoryだけlarger runnerを使うのか、公開repositoryは標準runnerに残すのか。開発者が勝手に変えられる状態だと、請求とセキュリティの説明責任が曖昧になる。
runner設定は、platform team、security team、billing manager、repository ownerの共同管理に近い。Copilot導入担当だけで完結させないほうがよい。
budgetsとレポートはどこを見るか
AI Credits消費を制限する。user-level budgetはbilling cycle内でhard stopとして働く。
private repositoryのGitHub-hosted runner利用、included minutes、超過分、larger runnerを確認する。
期間、repository、user、cost center、workflow_pathを合わせてCopilot code review由来の使用量を見る。
review workflowを切り出し、通常のCIやdeploy workflowと分けて追う。
Actions minutesはrepositoryからenterpriseまたはcost centerへ紐づくため、部門別の見え方を確認する。
AI CreditsのbudgetでCopilot機能が止まっても、すでに発生したActions minutesやActions spending limitの扱いは別に確認する。
6月1日以降のGitHub Copilotでは、budgetの見方も重要になった。特にCopilot BusinessやCopilot Enterpriseでは、AI Creditsのbudget controlsとGitHub Actions側の使用量管理を分けて理解する必要がある。
AI Creditsのbudget
根拠
GitHub Docsのbudgets for usage-based billingでは、user-level budget、cost center budget、enterprise budget、organization-level budgetが説明されている。このうちuser-level budgetは、特定ユーザーがbilling cycle内で消費できるAI Creditsを制限する。shared poolと追加のmetered usageの両方に対して働き、hard stopになる。
また、budgetを0米ドルに設定すると、その対象ユーザーのAI Credits消費は即時に止まる。budget到達時には、自動で安いモデルへfallbackするのではなく、対象機能がブロックされる。Code completions and next edit suggestionsはAI Credits対象外であり、paid plansでは引き続き含まれると説明されている。
注意点
cost center budgetやenterprise budgetは、license feeを含む総額予算ではない。GitHub Docsでは、enterprise budgetはshared poolが尽きた後のmetered chargesを制限するものだと説明されている。たとえばライセンス費用と追加使用予算を混ぜて「これ以上は絶対に請求されない」と見ると、読み違える。
AI Creditsのbudgetは、Copilotのモデル利用を止めるための強い制御だ。一方で、すでに発生したActions minutesの表示や、Actions側のspending limitとは別だ。Copilot budgetを設定しただけで、GitHub Actions全体の超過が止まるとは考えない。
GitHub Actionsのbudgetとspending limit
根拠
GitHub Actions billingのDocsでは、private repositoryでGitHub-hosted runnerを使う場合、アカウントのplanに応じた無料分、artifact storage、cache storageなどがあり、含まれる分を超えた使用はアカウントへ請求されると説明されている。Copilot code reviewのActions minutesも、この文脈で見る。
GitHubの4月27日Changelogは、Copilot code reviewの準備として、billing managersがActions usageとentitlementsを確認し、spending limitsやbudgetを見直すことを推奨している。
確認項目
Actions側では、organization billing settings、Actions minutes、included quota、repository owner、larger runner、spending limitの状態を見る。Copilot code reviewのworkflowは、通常のCIと同じActions全体の中に混ざるため、repositoryごとのworkflow名で切り分ける。
GitHub Actionsの利用がすでに多い組織では、Copilot code reviewだけの導入効果を見ても不十分だ。CIの最適化、重複workflow、bot PR、schedule workflow、large runnerの使い方と同じ棚に置いて、月次の推移を見る。
レポートで突き合わせる
確認項目
管理者は、Copilot usage metrics、GitHub Actions metrics、Billing Usage Reportを横断して見る。見る軸は、期間、repository、user、workflow_path、cost centerだ。6月1日以降のCopilot code reviewのworkflow_pathは、Docs上ではdynamic/agents/copilot-pull-request-reviewerとして確認対象になる。
AI Credits側で増えたユーザーと、Actions側で増えたrepositoryが一致するとは限らない。自動レビューではPR作成者がAI Credits側の帰属になり、Actions minutesはrepository側に寄る。ここを突き合わせると、どの運用が費用を押し上げているか見えやすい。
注意点
user-level budgetでAI Creditsが止まっても、すでに走ったreview workflowのActions minutesは別に確認する。反対に、Actions spending limitでrunner利用が抑えられても、Copilotの他機能でAI Creditsが消費される可能性は残る。
費用管理の説明では、CopilotのbudgetとActionsのspending limitを同じ制御として扱わない。請求先、対象機能、止まり方、レポート上の見え方が違うためだ。
非ライセンスユーザーと自動レビューはどう扱うか
- 1リクエストユーザーに帰属
手動でCopilot code reviewを依頼した場合は、そのユーザーのAI Credits消費として見る。
- 2PR作成者に帰属
repository policyで自動レビューが走る場合は、pull requestの作成者を確認する。
- 3trigger userまたはdesignated billing owner
GitHub Actionsやbotが作るPRでは、識別できるtrigger userまたはdesignated billing ownerを見る。
- 4個人のallowanceに収まらない
Copilot code reviewを含むライセンスがないユーザーの利用分は、paid additional usageとして扱われる。
- 5追加使用を別に追う
ライセンスなしメンバー、自動レビュー、bot PRをbilling report上で分けて確認する。
自動レビューは便利だが、PR数、bot PR、large PR、レビュー再実行によってAI CreditsとActions minutesの両方が増える可能性がある。
企業導入で見落としやすいのが、Copilot licenseを持たないメンバーや、全pull requestに対する自動レビューだ。便利な設定ほど、誰が使った扱いになるのかが曖昧になりやすい。
レビューを誰が発生させたか
根拠
GitHub Docsでは、手動でCopilot code reviewをリクエストした場合は、そのリクエストユーザーにAI Credits消費が帰属する。自動レビューでは、pull requestの作成者に帰属する。
pull requestがGitHub Actionsやbotで作られた場合は、識別できるtrigger user、またはdesignated billing ownerを見る。botが大量にdependency updateを出す環境では、この扱いを先に決めておかないと、後からbilling reportを読みにくくなる。
条件
repository policyで全pull requestに自動レビューをかける場合、開発者が明示的にCopilotを呼ばなくてもレビューが発生する。これは品質面では便利だが、AI CreditsとActions minutesの両方を増やす可能性がある。
対象branch、draft PR、bot PR、外部contributor、large PR、再実行のルールを分けておく。すべてのpull requestを同じ扱いにするより、重要なrepositoryやbranchから始めるほうが、費用と品質の両方を観察しやすい。
Copilotライセンスがないユーザー
根拠
GitHub Docsでは、organization members without a Copilot licenseも、管理者が有効化した場合にGitHub.com上でCopilot code reviewを使えると説明されている。この機能はCopilot BusinessまたはCopilot Enterpriseのorganizationで利用でき、enterprise administratorまたはorganization ownerが有効化する必要がある。
有効化には、AI credits paid usageのpolicyと、ライセンスがないメンバーにGitHub.comでCopilot code reviewを許可するpolicyが関係する。後者は既定で無効と説明されている。
注意点
Copilot code reviewを含むライセンスがないユーザーは、そのための月次AI Credits allowanceを持たない。GitHub Docsでは、このようなユーザーの利用分はorganizationまたはenterpriseのpaid additional usageとして扱われると説明されている。個人のuser-level budgetに自然に収まるものではない。
また、ライセンスなしユーザーのCopilot code reviewはIDEでは利用できないと説明されている。GitHub.com上でのレビュー運用と、VS CodeやJetBrainsなどのIDE運用を混ぜない。
自動レビュー設定の見直し
確認項目
見直すべき項目は、全PR自動レビュー、対象branch、bot PR、large PR、レビュー再実行、外部contributor、ライセンスなしメンバーの扱いだ。特に、dependency updateが多いrepositoryや、生成AIエージェントがPRを作る運用では、PR件数が人間の開発ペースより速く増える。
自動レビューは、品質の最低ラインを広く見るには便利だ。一方で、すべてのPRで同じ深さのレビューが必要とは限らない。費用を抑えるというより、必要な場所にレビューを寄せる設計が必要になる。
上振れと下振れ
上振れ要因は、PR数の増加、自動レビュー範囲の広さ、large repository、bot起点PR、レビュー再実行、larger runnerだ。下振れ要因は、budget到達によるcode review停止、runner制限によるagentic capabilitiesの低下、self-hosted runner運用の障害だ。
費用だけを見ると、レビューを止めれば安くなる。だが、それでは本来の目的である品質確認や人間のreviewer負荷軽減が失われる。必要なreviewを残し、低価値なreviewを減らす方針にしたい。
開発チームと管理者の6月1日以降チェックリスト
AI Credits consumed、additional usage、Actions minutes、included minutes残量、Billing Usage Report、cost centerを確認する。
public/private、organization default、repository override、GitHub-hosted runnersの有効/無効を棚卸しする。
user-level budget、cost center budget、enterprise budget、Actions spending limitを分けて見る。
自動レビュー対象、非ライセンスユーザー、bot PR、budget到達時の連絡先、人間のreviewerとの分担を決める。
よい設定は費用を止めるだけでなく、必要なレビューを止めすぎない設定である。
ここからは、2026年6月1日以降に実務で確認する順番だ。GitHub Docsは更新されるため、この記事の確認日は2026年6月2日JSTであることを前提に、自社画面の表示を優先して照合してほしい。
請求で見る項目
確認項目
まず、AI Credits consumed、additional usage、Actions minutes、included minutes残量、Billing Usage Report、cost centerを確認する。Copilot側だけ、Actions側だけではなく、同じ期間で並べる。
次に、Copilot code reviewに関連するworkflowを切り出す。GitHub Actions metricsではcopilot-pull-request-reviewer workflowを見て、Billing Usage Reportではworkflow_pathをfilterする。6月1日以降の値がdynamic/agents/copilot-pull-request-reviewerになっているかも確認する。
評価基準
評価基準は、費用が増えたかどうかだけではない。レビューあたりの人間の作業時間が減ったか、重大な指摘を拾えたか、不要な指摘が増えていないか、reviewerの待ち時間が短くなったかを見る。Copilot code reviewはコスト項目であると同時に、レビュー運用の品質項目でもある。
runnerとrepositoryで見る項目
確認項目
repositoryごとに、public/private、standard GitHub-hosted runner、larger GitHub-hosted runner、self-hosted via ARC、organization default、repository override、GitHub-hosted runnersの有効/無効を確認する。特にprivate repositoryで自動レビューを使う場合は、runner設定を請求表と同じ場所で管理したほうがよい。
self-hosted runnerを検討する場合は、Actions minutesを消費しないことだけで判断しない。ARC、Ubuntu x64 Linux runner、network security controls、許可host、runner隔離、ログ、秘密情報の扱いを確認する。
注意点
larger runnerは性能面では魅力があるが、標準runnerより高い分単位料金になる。self-hosted runnerはActions minutesを抑えられる可能性があるが、自社インフラ、運用、セキュリティ監査の負担を持つ。どちらも「安くなる」とは限らない。
また、organization-level default runnerはCopilot code reviewだけでなくCopilot cloud agentにも影響し得る。GitHub Copilotをagentic development全体で使っている組織は、code reviewだけの目線でrunnerを変えないようにしたい。
運用ルールで見る項目
確認項目
誰がレビューをリクエストできるか、自動レビューをどのrepositoryに許すか、非ライセンスユーザーを許可するか、budget到達時の連絡先は誰かを決める。budgetで止まったときに、開発者が「Copilotが壊れた」と誤解しないよう、事前にメッセージを用意する。
人間のreviewerとの分担も決める。Copilotの指摘を必ず検証する、セキュリティや仕様判断は人間が見る、外部contributorへのコメントはmaintainerが確認してから扱う、といった運用が必要だ。
評価基準
よい設定は、費用を止めるだけではなく、必要なレビューを止めすぎない設定だ。user-level budgetを厳しくしすぎると、重いPRを扱う開発者だけが早く止まる可能性がある。反対に、budgetを緩くしすぎると追加使用が読みにくくなる。
6月1日以降の最初の1か月は、いきなり全社最適を狙うより、repository種別、runner、review trigger、AI Credits、Actions minutesを同じ表で追う。次のbilling cycleで、対象範囲やbudgetを調整するほうが現実的だ。
MicrosoftとGitHubの公式発表、製品更新、月次まとめの更新通知を追う場合は、ニュースレターも利用できる。本文の判断材料を確認した後の補助導線として置いておく。
次に読むなら
次に読むなら
参照した主な情報源
- GitHub Changelog「Updates to GitHub Copilot billing and plans」: https://github.blog/changelog/2026-06-01-updates-to-github-copilot-billing-and-plans/ （確認日: 2026-06-02 JST）
- GitHub Changelog「GitHub Copilot code review will start consuming GitHub Actions minutes on June 1, 2026」: https://github.blog/changelog/2026-04-27-github-copilot-code-review-will-start-consuming-github-actions-minutes-on-june-1-2026/ （確認日: 2026-06-02 JST）
- GitHub Docs「Models and pricing for GitHub Copilot」: https://docs.github.com/en/copilot/reference/copilot-billing/models-and-pricing （確認日: 2026-06-02 JST）
- GitHub Docs「About GitHub Copilot code review」: https://docs.github.com/en/copilot/concepts/agents/code-review （確認日: 2026-06-02 JST）
- GitHub Docs「Configuring runners for GitHub Copilot code review」: https://docs.github.com/en/copilot/how-tos/copilot-on-github/set-up-copilot/configure-runners （確認日: 2026-06-02 JST）
- GitHub Docs「GitHub Actions billing」: https://docs.github.com/en/billing/concepts/product-billing/github-actions （確認日: 2026-06-02 JST）
- GitHub Docs「Budgets for usage-based billing」: https://docs.github.com/en/copilot/concepts/billing/budgets-for-usage-based-billing （確認日: 2026-06-02 JST）
- GitHub Blog「GitHub Copilot is moving to usage-based billing」: https://github.blog/news-insights/company-news/github-copilot-is-moving-to-usage-based-billing/ （確認日: 2026-06-02 JST）
更新履歴
- 2026-06-02 JST: GitHubの2026年6月1日Changelog、2026年4月27日Changelog、GitHub Docsのbilling、code review、runner、Actions billing、budget関連ページを確認し、初版を作成した。
- 次回確認: 次のbilling cycleで、Copilot code reviewのBilling Usage Report表示、GitHub Actions metrics、organization-level default runner、user-level budgetのDocs更新を確認する。