GitHub Copilot impact dashboardは、単にアクティブユーザー数を見る画面ではありません。2026年7月22日に公開されたこのダッシュボードは、開発者がコード補完中心なのか、エージェント中心なのか、マルチエージェントやCopilot appまで進んでいるのかを採用段階ごとに可視化し、プルリクエストの量と速度まで重ねて判断できるのがポイントです。7月17日に追加されたrepository-level metrics、Copilot app usage、7月20日に改善されたAI creditの可視化やcost center運用と組み合わせると、「誰が使っているか」ではなく「どこで深く使われ、どこに次の展開余地があるか」まで運用判断しやすくなります。
GitHub Copilot impact dashboardで何が見える？
GitHubの公式 changelog によると、impact dashboardは enterprise administrators と organization owners 向けに提供され、Passive、Phase 1、Phase 2、Phase 3 の4つのセグメントでユーザーを整理します。Phase 1 は Code-first、Phase 2 は Agent-first、Phase 3 は Multi-agent または Copilot app 活用です。各カードには、月あたりの平均マージPR数、中央値のPR merge velocity、その段階にいるユーザー数、全体に占める比率、1日あたり平均 lines of code が並ぶため、採用の深さと開発アウトプットを同じ会話で扱えるようになりました。
最初に確認したい4つの数字
まず見るべきなのは、1. Passive比率が高すぎないか、2. Phase 1からPhase 2へ進んでいるか、3. adoption multiplierで受動層と利用層の差がどれだけ開いているか、4. 6カ月トレンドで cohort growth と pull request throughput が同時に伸びているか、の4点です。ライセンスを配った直後はDAUだけでも前進に見えますが、Passiveが厚いままだと「付与しただけ」で止まっている可能性があります。反対にPhase 2やPhase 3が増え、merge velocityが改善しているなら、単発チャットではなく実務フローの中にCopilotが入り始めていると読めます。
AI adoption phaseはどう使い分けるべき？
Phase 1 が多い組織では、まず補完と通常チャットが定着している状態です。この段階で必要なのは、使う/使わないの啓発より、Planモードやagent利用の具体的な業務例を横展開することです。Phase 2 が増えているなら、複数ファイル編集やPR作成など、エージェント型の使い方が始まっています。ここで重要なのは、安全に広げるための対象リポジトリ選定です。Phase 3 は Multi-agent や Copilot app 活用まで進んだ層なので、単なる利用促進ではなく、内製標準やレビュー基準、チーム別の予算管理に話題を移すべきです。段階ごとに打ち手を変えないと、研修だけ増えて現場の定着は進みません。
repository-level metricsとどう組み合わせる？
7月17日に一般提供となった repository-level metrics では、Copilot coding agent が作成・マージしたPRと、Copilot code review がレビューしたPRを、日単位かつリポジトリ単位で確認できます。実務では、impact dashboardで Phase 2 や Phase 3 が伸びている組織を見つけ、その次に repos-1-day エンドポイントで対象リポジトリを掘る流れが有効です。たとえば、ある組織で adoption multiplier は高いのに成果が偏っている場合、特定の基幹リポジトリだけで使われているのか、レビュー用途に偏っているのかを切り分けられます。展開優先度を決める順番は、組織 → cohort → repository の3段階にすると、Enablementの無駄打ちを減らしやすくなります。
コスト統制で一緒に見るべき項目
採用深度だけを見ると「伸びているから良い」で終わりがちですが、2026年6月以降のCopilotは usage-based billing が前提です。GitHub Docsでは、Copilot Business は1ユーザーあたり月1,900 AI credits、Copilot Enterprise は3,900 AI creditsが標準で、既存顧客には6月1日から9月1日までのプロモ期間として Business 3,000、Enterprise 7,000 credits が案内されています。7月20日に cost center の AI credit pool を UI から管理できるようになり、同日ユーザー本人も billing cycle 内の利用量を見られるようになったので、管理者は「どの部署にどれだけ配るか」、利用者は「今月どこまで使ったか」をそれぞれ自走で確認しやすくなりました。運用上は、cost center budget と AI credit pool を別物として扱うことが大切です。pool は各グループが自分たちのライセンス相当分を超えすぎないようにする仕組みで、budget は pool 枯渇後の追加課金を止める仕組みです。
導入判断で見落としやすい注意点
GitHub Docsには見落としやすい前提がいくつかあります。まず、usage metrics は2フルUTC日以内に反映される仕組みなので、当日の研修や展開施策を即日評価する用途には向きません。次に、指標にはIDEやCLIのテレメトリが中心で、GitHub.com上のCopilot ChatやGitHub Mobileは通常の usage metrics には含まれません。一方で、7月17日から Copilot app usage は専用フィールドとして enterprise と organization の1日/28日レポートに追加されました。つまり、「全部のCopilot利用が完全に一枚で見える」と考えるのではなく、どの surface が可視化対象かを確認したうえで運用会議に載せる必要があります。権限面でも、enterprise owners、organization administrators、billing managers、または View Enterprise Copilot Metrics 権限を持つカスタムロールが必要です。
関連記事
あわせて確認したいテーマとして、既存の「GitHub Copilotの利用可視化は何が変わる？7月17日GAのrepository-level metrics・7月20日のAI credit pool UI・billing cycle表示を整理する予算統制ガイド【2026年速報】」があります。今回の impact dashboard はその続編として、可視化した数字をどう展開判断とEnablementに使うかを補う位置づけで読むと理解しやすくなります。
まとめ
GitHub Copilot impact dashboard の価値は、利用者数を増やしたかどうかではなく、採用段階とPRアウトプットを結びつけて次の打ち手を決められる点にあります。2026年7月17日から22日にかけて公開された repository-level metrics、Copilot app usage、billing cycle利用量表示、AI credit pool UI を一緒に使えば、導入状況、リポジトリ別の成果、部署別のコスト統制を分断せずに見直せます。Copilot導入が「席配布」と「現場定着」の間で止まっている企業ほど、impact dashboard を起点に、どの部門をPhase 2に進めるか、どのリポジトリで先に成功例を作るかを決める価値があります。
GitHub Copilotの展開設計、予算統制、AI導入ルールの整備をまとめて進めたい場合は、 HelloCraftAIへご相談ください 。現場の利用促進だけでなく、管理者向けの運用フロー設計まで含めて支援できます。
