GitHub Copilotの利用量可視化とレビュー自動化が強化

何が変わったのか：3つの更新をまとめて読む

2026年7月17日〜20日にかけて、GitHubはCopilot関連の更新を3本立てで公開した。単独ではマイナーに見えるが、組み合わせると「コスト可視化→品質管理」の流れを一気通貫で設計できる構成になっている。

小中規模チームの悩みは「Copilotにいくら使っているかわからない」「AIレビューをチームルールに合わせられない」の2点に集約されやすい。今回の更新はその両方を正面から解消する。

リポジトリ単位の利用量をAPIで取得する

Repository-level GitHub Copilot usage metrics generally availableにより、Copilot usage metrics REST APIがリポジトリレベルの活動を返すようになった。

追加されたエンドポイントは2本。エンタープライズ向けは GET /enterprises/{enterprise}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD、組織向けは GET /orgs/{org}/copilot/metrics/reports/repos-1-day?day=YYYY-MM-DD で、どちらも日付1日分のリポジトリ別PRデータを返す。

返却値には「Copilot coding agentが作成してマージされたPR数」と「Copilot code reviewがレビューしたPR数・コメントタイプ別の提案数」が含まれる。アクセス権限はエンタープライズオーナー、課金マネージャー、組織オーナー、および"View Copilot Metrics"を付与したカスタムロールに限定される。利用には事前にCopilot usage metricsポリシーの有効化が必要だ。

「どのリポジトリがAIに依存しているか」「どこでレビュー自動化が機能しているか」をダッシュボードに流し込むことで、投資対効果の議論を数字で進められる。

個人ユーザーが「今月何クレジット使ったか」を確認できる

従来のCopilot usage pageは予算に対する使用割合のみを表示していた。予算を設定していないユーザーは月次の消費量を確認する手段がなく、請求額が届いて初めて気づく状況が続いていた。

Copilot users can now see AI credits used per billing cycleにより、Copilot BusinessおよびEnterpriseのユーザーは、予算設定の有無にかかわらず当月の総AIクレジット数を確認できるようになった。管理者が予算を設定している場合は使用数と上限の両方が表示される。

複数のエージェントツールを並走させるとクレジット消費は想定外に膨らむ。月の途中で使用量を確認し、残りの期間で利用方針を調整できる基本的な管理サイクルがようやく整った。

Copilot code reviewにチーム固有のルールを組み込む

Copilot code review: Customization and configurability improvementsは、レビュー品質のカスタマイズ面で最も変化が大きい更新だ。

カスタム指示の読み込み先が増えた

Copilot code reviewはPRのヘッドブランチから copilot-instructions.md、*.instructions.md、AGENTS.md、agent skillsを読み込むようになった。リポジトリ直下の REVIEW.md、GEMINI.md、CLAUDE.md も参照対象に加わっている。Claude CodeやGeminiのルールファイルをそのままCopilotレビューに流用できる、実用的な互換性だ。

実行環境をYAMLで宣言できる

.github/workflows/copilot-code-review.yml を置くと、依存関係のインストール・ランナー設定・ツールのセットアップを事前ステップとして定義できる。このファイルが存在しない場合は copilot-setup-steps.yml にフォールバックする。型チェックやlintを先に走らせてからAIレビューを実行する、という順序制御を宣言的に書ける。

ファイアウォールとランナーの分離

Copilot code reviewはデフォルトでファイアウォール下で動作し、レビュー中のネットワークアクセスを制限する。設定は リポジトリ設定 → Copilot → Internet access から変更できる。セルフホストランナーは現時点でファイアウォール非対応のため、社内環境でセルフホストを使っているチームは注意が必要だ。

Copilot code reviewとCopilot cloud agentのランナー設定は、従来1つの設定を共有していたが、組織設定 → Copilot → Runner type の2セクションに分割された。agentとreviewで異なるランナーを割り当てたい場合に設定が衝突しなくなる。

3つの更新をどう組み合わせるか

設計の基本線は「計測→判断→自動化」の順に構築することだ。

まずusage metricsポリシーを有効化し、組織エンドポイントをcronで定期取得してリポジトリ別の日次PRデータを蓄積する。1週間分のデータが揃えば「どのリポジトリでCopilot agentが活発か」「レビュー提案の受理率が低いリポジトリはどこか」が見えてくる。個人ユーザーはusage pageで月次クレジットを確認し、消費ペースが想定を超えていれば使うエージェント機能を絞る判断ができる。

次にコードレビューの自動化品質を上げる。既存の AGENTS.md や copilot-instructions.md を整備済みのチームは、そのままCopilot code reviewが参照する。新たにルールを書き直す必要はない。copilot-code-review.yml でlintや型チェックを先行させれば、AIが構文エラーではなくロジックの問題に集中できる状態を作れる。

セルフホストランナーを使っているチームは、ファイアウォール非対応という制約を把握したうえで、cloud agentとの役割分担を設計しておきたい。ランナー設定が2セクションに分離されたことで、agentはセルフホスト・reviewはGitHub-hostedという構成を明示的に管理できる。

まとめ

利用量の可視化とレビュー自動化は、それぞれ単独では効果が薄い。メトリクスで「使われている場所」を特定し、そこにカスタム指示とYAML設定を当てることで、AIへの投資が品質向上に直結する構造を作れる。まず組織のusage metricsポリシーを有効化して1週間データを取ること——それが最初の一手になる。