GitHub Copilot 2026年5月29日

GitHub Copilot 利用メトリクス API に「AI 採用フェーズ」コーホート追加 — 28 日利用パターンから 4 フェーズ分類、`ai_adoption_phase` / `totals_by_ai_adoption_phase` フィールド新設、code-first から multi-agent まで成熟度を測定可能

GitHub は 2026-05-29 公開の Copilot Changelog で、Copilot **利用メトリクス API** に **AI 採用フェーズ（adoption phase）コーホート** を追加したと発表した。エンゲージしているユーザーを **28 日間の利用パターン** から **4 つのフェーズ** に分類し、REST API レスポンスに **`ai_adoption_phase`** フィールドと **`totals_by_ai_adoption_phase`** 配列が追加された。フェーズは **「code-first（コード補完中心）」から「multi-agent ワークフロー」までの成熟度** を段階表現する設計で、組織は **単純なアクティビティカウント（誰がどのくらい使ったか）** ではなく **「Copilot をどこまで使いこなしているか」** を測定できるようになる。これにより、Enterprise 管理者・組織オーナーは社内チームの **AI 利活用成熟度** をセグメント別に集計し、低フェーズユーザー向けの enablement イニシアチブ（社内研修・支援投資・伴走サポート）を **的を絞って実施** できる。高フェーズユーザーは社内事例化のターゲットとして特定でき、社内発信やトレーニング教材の素材として活用可能。**「Copilot 活用率」というだけでは経営層に説明しづらかった ROI** を、「フェーズ別の到達度」と「フェーズ移行による生産性向上の証跡」として再構築できるため、GitHub Copilot Enterprise / Business 契約の継続判断材料が一段強くなる。BI ツール（Looker / Tableau / Power BI / Metabase）への流し込みで **社内ダッシュボード化** する運用が現実的になった。

ニュース原文を読む ↗

要約

GitHub は 2026 年 5 月 29 日に Copilot Changelog で、Copilot 利用メトリクス API に AI 採用フェーズ（adoption phase）コーホート を追加したと発表しました。エンゲージしているユーザーを 28 日間の利用パターン から 4 つのフェーズ に分類し、REST API レスポンスに ai_adoption_phase フィールドと totals_by_ai_adoption_phase 配列が追加されました。

分類設計

フェーズ範囲: 「code-first（コード補完中心）」から「multi-agent ワークフロー」までの成熟度を段階表現。
集計窓: 過去 28 日間 の利用パターンに基づく分類。
粒度: ユーザー単位の ai_adoption_phase、組織全体の totals_by_ai_adoption_phase 配列。

対象

プラン: GitHub Copilot Enterprise / Business（メトリクス API 利用権限を持つ管理者・組織オーナー）
エンドポイント: 既存の Copilot Usage Metrics API（REST）にフィールド追加

何が変わったか

利用メトリクス API レスポンスに ai_adoption_phase（ユーザー単位）と totals_by_ai_adoption_phase（組織単位）が追加。
4 フェーズ分類で「コード補完中心」から「multi-agent ワークフロー活用」までの成熟度を測定可能。
28 日窓の利用パターン解析に基づく分類。
BI ツール（Looker / Tableau / Power BI / Metabase）への流し込み・社内ダッシュボード化が現実的に。

業務インパクト（一般企業向け）

Copilot Enterprise / Business を運用している組織にとって、これは 「Copilot ROI を経営層に説明する」材料の構造的改善 です。これまで多くの組織が苦戦していた 「アクティブユーザー数だけ示しても『で、何の効果が？』と返される」 問題に対して、フェーズ別の成熟度分布 を提示できるようになりました。

例えば「全社の 60% は code-first 段階、20% は chat 活用段階、15% は edit ワークフロー段階、5% は multi-agent 段階」のような分布が出ると、enablement 投資の ROI を「何段階上に押し上げたか」で測れます。「アクティビティが増えた」ではなく「成熟度の階段を 1 段上げた」という説明が成立します。

逆に 「全員が code-first から進まない」状態の可視化 にも使えるため、社内の研修・伴走支援の必要性を定量的に示せます。「Copilot を契約したが使いこなされていない」を経営層に伝えるのは難しい話題ですが、フェーズ分布で示せば数値ベースで議論できます。

社内 enablement チーム（DevOps / DevRel / 内製化推進室）にとっては、フェーズ別ユーザーリストを抽出して個別の研修プログラム を設計するワークフローが組めます。「low-phase ユーザーに対する Copilot Edit / Agent ハンズオン」「high-phase ユーザーから社内事例を抽出して横展開」という回し方が現実的になりました。

BI ツールでダッシュボード化すると、四半期レビューや経営会議で 「Copilot 投資の成熟度推移」 を 1 枚で示せるようになります。組織のメトリクスポートフォリオに 1 行追加する価値があります。

ガバナンス側にとっても、「ライセンス購入したが使われていない」「使われているが浅い」 という 2 種類の問題を区別できるため、削減・再配分の意思決定 が早くなります。

ai_adoption_phase の具体的分類定義（4 フェーズの境界条件、28 日窓の集計ロジック）は今後のドキュメント更新と運用知見の蓄積で明確化していくはずです。まずは API 取得 → 自社ユーザーへの分布確認 → 想定との差分検証 というステップを 2026 年 6 月中に 1 サイクル回すのが現実的です。

副業・個人活用視点

副業で エンタープライズ向け Copilot 導入支援 / DevRel 案件 を請けている個人にとっては、これは 「Copilot 導入後の伴走支援を案件化する」材料 になります。「フェーズ分布の取得 → 低フェーズ層への研修設計 → 移行効果の測定」という伴走パッケージを提案できるようになり、単発の導入案件で終わらず継続案件に変えやすくなりました。

社内 enablement の経験がある個人にとっては、「Copilot 成熟度を上げるための研修教材設計」 を note / Zenn / Udemy などで販売する余地もあります。フェーズ分類が公式に存在することで、「フェーズ別の社内研修プログラム」というコンテンツ軸が立ちます。

個人開発者として Copilot を契約している人には直接の影響は限定的ですが、自分の使い方が ai_adoption_phase でどう分類されるかを意識すると、「multi-agent ワークフローまで到達する」 という個人的な成熟度目標を設定しやすくなります。