GitHub Copilot Enterprise：Spaces と Usage Metrics API のガイド

GitHub Copilot Enterprise が Spaces と Usage Metrics API を活用し、エンジニアリング組織全体でコンテキスト、ガバナンス、採用トラッキングをどのように提供するかを学びます。

更新 2026年5月27日 · 12 分読む

GitHub Copilot Enterprise を組織全体に導入し、シートを割り当て、ポリシーを構成し、開発者はほぼすぐに IDE 内で Copilot の利用を開始しました。ここからは、難しい質問に答える番です。

Copilot が自社のエンジニアリング文脈をより良く学習できるように、どのように整備すればよいか？
Copilot の価値はどう測るのか？どの部門がうまく採用し、どの部門がまったく使っていないのか？

そこで登場するのが GitHub Copilot Spaces と Usage Metrics API です。Spaces は Copilot に組織の技術知識を吸収させ、Usage Metrics API は管理者がエンタープライズ全体の採用状況、定着度、生産性のトレンドを測定できるようにします。

この記事では次の内容を取り上げます。

GitHub Copilot Enterprise に含まれるもの
Copilot Spaces の仕組み
大規模環境での Spaces の設定方法
GitHub Copilot Usage Metrics API のエンドポイント
認証とレポート作成のワークフロー
実践的な ROI 測定戦略

GitHub の組織、プルリクエスト、権限モデルに不慣れな場合は、Intermediate GitHub Concepts コースで基礎を確認してください。Copilot 自体が初めてであれば、GitHub Copilot の使い方チュートリアルで本ガイドの前提となるコア機能を解説しています。

GitHub Copilot Enterprise とは？

GitHub Copilot Enterprise は、GitHub の Copilot プラン階層の最上位に位置します。

GitHub Copilot Business や Pro+ と比べると、Enterprise はガバナンス、組織コンテキスト、測定機能に大きく重点を置いています。個人開発者や小規模チームではなく、大規模なエンジニアリング環境で運用する企業向けに設計されています。

実際に最も重要となるのは次の 2 つの機能です。

Spaces によるカスタムな組織コンテキスト
Usage Metrics API による組織全体のテレメトリ

これら 2 つの機能により、Copilot は「スマートなオートコンプリート」から、社内向けの AI エンジニアリングプラットフォームに近いものへとシフトします。

GitHub Copilot Enterprise の価値を最大化している企業は、Copilot を内部インフラの重要なコンポーネントとして扱っています。組織コンテキストを慎重に構成し、採用状況を継続的に測定し、仮説ではなく使用データに基づいてポリシーを調整します。

GitHub エコシステム全体を俯瞰するには、Introduction to GitHub Products ガイドをおすすめします。

Enterprise が Business や Pro+ と異なる点

GitHub Copilot Enterprise は、Business サブスクリプションを拡張し、次のような機能を追加しています。

組織レベルの利用状況メトリクス
強化されたガバナンス管理
エンタープライズ全体のポリシー継承
より多いプレミアムリクエスト枠（Business の 300 に対して 1,000）
追加のモデルアクセスと管理

Enterprise には Copilot Enterprise サブスクリプションに加えて GitHub Enterprise Cloud が必要です。ユーザーごとに追加コストが発生するため、ガバナンス、テレメトリ、エンタープライズレベルの管理が本当に必要かを必ず確認してください。

Feature	Pro+	Business	Enterprise
Individual usage	Yes	No	No
Centralized seat management	No	Yes	Yes
Audit logs	No	Yes	Yes
File exclusions	No	Yes	Yes
Spaces support	Yes, with Copilot	Yes, Limited admin visibility	Yes, Full enterprise management
Usage Metrics API	No	Org-level	Enterprise + Org-level
Enterprise policy inheritance	No	No	Yes

Note: Business サブスクライバーは組織レベル（/orgs/{org}/…）で Usage Metrics API にアクセスできます。Enterprise サブスクライバーは、すべての組織を 1 つのビューでカバーするエンタープライズ全体の集計レポート（/enterprises/{enterprise}/…）にもアクセスできます。

GitHub Copilot Enterprise の対象

GitHub Copilot Enterprise は、すでに成熟した GitHub 環境を運用している組織を対象としています。

代表的な Enterprise 顧客層：

大規模なエンジニアリング組織
規制産業
複数チームからなるプラットフォームエンジニアリング部門
社内の開発標準を持つ企業
一元的なガバナンスを必要とする組織

これは Copilot 自体の性能を本質的に向上させるわけではありません。この違いは、多くのチームが最初に過剰購入しがちであるため重要です。Enterprise ＝「より良い Copilot」と考えがちですが、実際にはガバナンスと測定ツールが主に追加されるだけです。

Copilot Spaces：組織向けのカスタムコンテキスト

Copilot Spaces は、汎用的な AI コーディングアシスタントの大きな弱点の 1 つを解決します。

Copilot は、箱から出してすぐに公開知識としてのプログラミングは一定程度理解します。しかし、社内 API、アーキテクチャの決定、コーディング規約、デプロイのワークフロー、オンボーディング資料を自動的に理解するわけではありません。

Spaces は、Copilot が会話やコーディング支援の際に参照できる、厳選された組織コンテキストを提供します。

実務的には、Spaces によって Copilot は次のような質問に答えやすくなります。

「社内では API ハンドラーをどのように構成しているか？」
「プラットフォームチームが推奨する認証ライブラリはどれか？」
「このマイクロサービスはどのデプロイワークフローを使うべきか？」
「バックエンドチームの命名規則は？」

Spaces がサポートするもの

Spaces は、旧来の Knowledge Bases システムよりも幅広い組織コンテンツをサポートします。

サポートされるコンテンツタイプ：

コードファイル
Markdown ドキュメント
JSON ファイル
アップロードしたファイル
画像
GitHub Issues
プルリクエスト

各コンテンツタイプは異なる形で寄与します。

コードファイルは実装パターンの理解を助け、Markdown はアーキテクチャの説明やオンボーディングの指針を提供します。プルリクエストはレビューの議論や過去の技術判断を示します。これらの組み合わせにより、Copilot は組織の開発プラクティスをより適切に把握できます。

重要だが見落とされがちな点として、Spaces は GitHub に紐づく単なるベクターデータベースではありません。エンタープライズ環境向けに設計された共有コントロールやガバナンスのワークフローを備えています。

Knowledge Bases のサンセット

GitHub は旧来の Copilot Knowledge Bases 機能を 2025 年 11 月 1 日に終了しました。

Spaces は次の点で Knowledge Bases を置き換えました。

より広いコンテンツサポート
優れた共有コントロール
管理機能の改善
柔軟な組織レベルの管理

Knowledge Bases に言及する古いドキュメントやブログ記事は依然として見つかります。2025 年から 2026 年への移行期間に多くのエンドポイントやワークフローが変更されたため、古いチュートリアルを参照する際は注意してください。

Copilot Spaces の作成と設定

管理の観点では、Copilot Spaces の作成は比較的シンプルです。難しいのは、チーム横断で数十〜数百のスペースを管理することです。

初期に選んだ構造は定着しやすいものです。所有ルールを事前に決めなかったために、Spaces 内で「ドキュメントの散在」が偶発的に起きてしまう組織を見たことがあります。

誰でも Copilot Space を作成できるので、個人リポジトリで試してみましょう。Enterprise レベルでも手順はほぼ同じで、一部ページが異なる程度です。

Space のセットアップ

Space の作成は一般的に次のワークフローに従います。

Enterprise 管理エリアの Copilot Spaces ページに移動
新しい Space を作成

リポジトリとコンテンツソース（MCP やその他の有用なツールを含む）を選択

ソースの追加は、右側の「+ Add sources」ボタンから実行

この段階でスペースの共有や共有設定の構成を選択可能

チャット時に Copilot がコンテンツを参照できるかを検証

エンタープライズユーザー向けの注意：管理者は個人スペースの共有をオフにできるため、個人アカウントを使用している場合は、エンタープライズのリポジトリを使用していない Copilot Space の共有が制限されることがあります。

セットアップ後、管理者は実用的なプロンプトで Space をテストする必要があります。

例：

How does our authentication middleware handle token refresh logic?

または：

Show me an example of how our backend services structure database migrations.

Copilot が正確に答えられない場合、問題はたいてい次のいずれかです。

リポジトリの不足
ドキュメント品質の低さ
権限設定の誤り
インデックス化時間の不足

共有とアクセス制御

Spaces には主に 2 つの可視性モデルがあります。

個人スペース
組織全体スペース

エンタープライズのメンバーは、より大きなエンタープライズ設定によって個々のスペースを管理されることがあります。エンタープライズ管理者は、プレビューや機能の提供ポリシーも集中管理できます。

プライベートスペースは、実験的なチームや機密性の高い社内プロジェクトに適しています。組織全体のスペースは、エンジニアリング標準、オンボーディング資料、全社的なフレームワークに適しています。

よくある間違いの 1 つは、過度な集中化です。巨大な全社スペース 1 つだけにすると、ノイズが増え、Copilot が効果的に活用しづらくなります。

チームまたはドメイン別に Spaces を整理する

普遍的に正しい組織構造はありません。

一般的なパターンには、チームごとのスペース、プロダクト領域ごとのスペース、共有スタンダード用スペースなどがあります。それぞれスコープが異なり、同じ設定領域を別の使い方で活用します。

チームごとのスペース

エンジニアリンググループが比較的独立して活動している場合に有効です。

例：

プラットフォームエンジニアリング
データエンジニアリング
モバイル開発

プロダクト領域ごとのスペース

部門ではなくプロダクトを軸に組織化されている場合に有効です。

例：

決済
アナリティクス
インフラストラクチャ
カスタマープラットフォーム

共有スタンダード用スペース

多くの組織では、次のような用途に別途共有スペースを設けています。

セキュリティガイドライン
コーディング規約
デプロイワークフロー
アーキテクチャ標準

実務では、ハイブリッドなアプローチが最も機能することが多いです。各チームに専用スペースを用意し、より大きな標準スペースをチーム間で共有します。

Copilot Usage Metrics API

Spaces はコンテキストの課題を解決します。Usage Metrics API は測定の課題を解決します。これは、2026 年の API 統合の際に GitHub が廃止した複数の旧テレメトリシステムの代替となりました。

明確な測定がなければ、組織は Copilot の採用が成功しているかどうかの可視性をすぐに失います。経営層は、投資が開発者のワークフローを改善していることを、単なるサブスクリプションの追加行ではなく、証拠で示すことを求めます。

ダッシュボードは 2026 年 2 月に一般提供となり、エンタープライズアカウント → AI Controls → Copilot → Metrics → Insights タブの Copilot usage metrics からアクセスできます。

github.blog に掲載の Copilot Usage Metrics ダッシュボード例

API が測定するもの

Usage Metrics API は、いくつかの運用テレメトリカテゴリを公開します。

一般的なメトリクス：

アクティブユーザー数
提案行数と受け入れ行数の比較
IDE の利用パターン
モデルの利用
エージェントとのやり取り
使用言語の内訳

これにより、単なるシート数よりもはるかに精緻な把握が可能になります。

100 のシートを割り当てたチームでも、アクティブユーザーが 15 人しかいない場合と、日常的に一貫して使用され受け入れ率が高い場合とでは、採用プロファイルは大きく異なります。

2026 年の API 移行

GitHub は 2025〜2026 年の移行期間に、ユーザーレベルの Feature Engagement Metrics API、Direct Data Access API、Copilot Metrics API など複数の旧テレメトリ API を廃止し、2026 年 4 月までに完全終了しました。

具体的には次のものが含まれます。

レガシー Metrics API
Feature Engagement APIs
Direct Data Access APIs

2026 年 2 月以降に提供されている新しい Usage Metrics エンドポイントは、これらのレポートシステムをより統一的なモデルに集約し、破壊的変更に備えたバージョニングも含みます。

これは、多くの古いブログ記事や GitHub の例が非推奨エンドポイントを参照しているため重要です。Usage Metrics API を利用する際は、自動化を構築する前に、常に最新の GitHub API リファレンスでドキュメントを確認してください。

Usage Metrics API のクエリ

Usage Metrics API の目的を理解したところで、実際の使い方を見ていきましょう。

認証と権限

GitHub Copilot Usage Metrics の各エンドポイントを使うには、一般的にパーソナルアクセストークン（PAT）にいくつかの権限を設定する必要があります。クラシック PAT とファイングレインド PAT のどちらでも可能です。

クラシック PAT の場合、エンタープライズ管理者から manage_billing:copilot と read:org の権限を付与してもらう必要があります。
ファイングレインドアクセストークンの場合は、Enterprise Copilot metrics enterprise permissions (read) 権限を持つ GitHub アプリのユーザーアクセストークンまたはインストールアクセストークンを使用してください。

通常は、不要な権限の露出を減らせるため、ファイングレインドトークンの使用が推奨されます。

組織レベルのエンドポイント

最も一般的な組織レベルのレポートは次の 2 つです。

organization-1-day
organization-28-day

1 日の組織レベルレポート

1 日レポートは、運用監視や短期トレンド分析に適しています。履歴データは 2025 年 10 月 10 日まで遡って利用可能で、現在から 1 年間アクセスできます。

以下の curl コマンドは 1 日レポートのメトリクス API を呼び出し、利用レポートのダウンロードリンクを含む JSON レスポンスを返します。ベアラー認証の YOUR_TOKEN を含め、レポートの対象日 DAY を YYYY-MM-DD 形式で指定してください。

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
"https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-1-day?day=DAY"

download_links の URL は署名付きで有効期限が短く、取得後まもなく失効します。同一の実行内でダウンロード URL を取得し、直ちにファイルを取得する必要があります。これらの URL を後で使用するために保存することはできません。

レスポンスには download_links と report_day のみが含まれる場合もありますが、想定される完全なスキーマは以下のとおりです。

{
  "type": "object",
  "title": "Copilot Metrics 1 Day Report",
  "description": "Links to download the Copilot usage metrics report for an enterprise/organization for a specific day.",
  "properties": {
    "download_links": {
      "type": "array",
      "items": {
        "type": "string",
        "format": "uri"
      },
      "description": "The URLs to download the Copilot usage metrics report for the enterprise/organization for the specified day."
    },
    "report_day": {
      "type": "string",
      "format": "date",
      "description": "The day of the report in YYYY-MM-DD format."
    }
  },
  "required": [
    "download_links",
    "report_day"
  ]
}

28 日の組織レベルレポート

28 日レポートは、より広い採用パターンや長期的な利用変化を把握するのに役立ちます。コマンドはほぼ同じで、28 日 API を使うよう小さく変更します。

リクエスト例：

curl -L \
 -H "Accept: application/vnd.github+json" \
 -H "Authorization: Bearer <YOUR_TOKEN>" \
-H “X-GitHub-Api-Version: 2026-03-10” \
https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/enterprise-28-day/latest

返される内容は類似していますが、response_start_day と response_end_day が含まれます。

組織レベルレポートの構造

1 日・28 日いずれの組織レポートも、JSON は次のような形になる場合があります。

[
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  },
  {
    "user_id": 1001,
    "user_login": "octocat",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 43,
    "slug": "backend"
  },
  {
    "user_id": 1002,
    "user_login": "hubot",
    "day": "2026-05-14",
    "organization_id": "999",
    "team_id": 42,
    "slug": "frontend"
  }
]

ご覧のとおり、特定の組織内のユーザー、その所属チーム、チームタグの概要を高いレベルで把握できます。

ユーザーレベルのエンドポイント

ユーザーレベルのレポートは、より詳細な採用状況の可視化を提供します。つまり、個々のユーザーが Copilot をどのように利用しているかを高い解像度で把握できます。

一般的なエンドポイント：

users-1-day
users-28-day
user-teams-1-day

これらのレポートにより管理者は次の点を特定できます。

非常にアクティブなユーザー
採用が進まないチーム
トレーニングの機会
部門レベルの利用トレンド

これらのリクエストは、組織レベルの 1 日・28 日レポートと非常によく似ており、単に異なる API を指しているだけです。

1 日のユーザーレベルレポート

users-1-day API 呼び出しの例：

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
  "https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-1-day?day=DAY"

28 日のユーザーレベルレポート

users-28-day API 呼び出しの例：

curl -L \
  -H "Accept: application/vnd.github+json" \
  -H "Authorization: Bearer <YOUR-TOKEN>" \
  -H "X-GitHub-Api-Version: 2026-03-10" \
   https://api.github.com/enterprises/ENTERPRISE/copilot/metrics/reports/users-28-day/latest

1 日の user-teams レポート

ユーザーをチーム所属にマッピングする user-teams-1-day エンドポイントも存在します。利用メトリクス自体は含まず、ユーザーレベルのデータをチーム単位に集計する際の結合キーとして機能します。

ユーザーレベルレポートの構造

これらのレポートは特定ユーザーの利用データを対象とするため、詳細度ははるかに高くなります。

[{
  "code_acceptance_activity_count": 1,
  "code_generation_activity_count": 1,
  "day": "2025-10-01",
  "enterprise_id": "1",
  "loc_added_sum": 8,
  "loc_deleted_sum": 0,
  "loc_suggested_to_add_sum": 10,
  "loc_suggested_to_delete_sum": 0,
  "totals_by_cli": {
    "last_known_cli_version": {
      "cli_version": "1.0.8",
      "sampled_at": "2025-10-01T00:01:43.000Z"
    },
    "prompt_count": 2,
    "request_count": 2,
    "session_count": 2,
    "token_usage": {
      "avg_tokens_per_request": 4400.0,
      "output_tokens_sum": 5000,
      "prompt_tokens_sum": 3800
    }
  },
  "totals_by_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_ide": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "ide": "vscode",
    "last_known_ide_version": {
      "ide_version": "1.85.0",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "last_known_plugin_version": {
      "plugin": "",
      "plugin_version": "",
      "sampled_at": "2025-10-01T00:00:02.000Z"
    },
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0,
    "user_initiated_interaction_count": 0
  }],
  "totals_by_language_feature": [{
    "code_acceptance_activity_count": 1,
    "code_generation_activity_count": 1,
    "feature": "code_completion",
    "language": "unknown",
    "loc_added_sum": 8,
    "loc_deleted_sum": 0,
    "loc_suggested_to_add_sum": 10,
    "loc_suggested_to_delete_sum": 0
  }],
  "totals_by_language_model": [],
  "totals_by_model_feature": [],
  "used_agent": false,
  "used_chat": false,
  "used_cli": true,
  "user_id": 1,
  "user_login": "login1",
  "user_initiated_interaction_count": 0,
  "etl_id": "green",
  "day_partition": "2025-10-01",
  "entity_id_partition": 1
}]

これらのメトリクスは、チームレベルの採用状況シグナルとして最も価値があります。受け入れ率や利用回数は運用上のシグナルであり、開発者の品質を測る指標ではありません。

想定されるメトリクスの全体像については、最新の GitHub usage metrics データドキュメントを参照してください。

ユーザーレベルのレポートには CLI のインタラクションデータが含まれます。チームがコマンドラインで Copilot を使用している場合は、GitHub Copilot CLI チュートリアルでセットアップと一般的なワークフローを解説しています。

Copilot レポーティングワークフローの構築

スキーマ理解や試行には手動での API 呼び出しが有用ですが、実務で活用するには自動化されたワークフローを作成するのが望ましいです。

Copilot Enterprise の価値を最大化しているチームは、利用テレメトリと社内のエンジニアリングメトリクスを組み合わせた軽量のレポーティングパイプラインを構築するのが一般的です。

ROI を証明するための主要メトリクス

すべての Copilot メトリクスが同じ重みを持つわけではありません。特に有用なのは次の指標です。

アクティブユーザーの増加
受け入れ率のトレンド
提案コードと維持コードの比較
PR サイクルタイムの短縮
IDE へのエンゲージ頻度

GitHub は次のようなベンチマークを公開しています。

タスク完了が 55% 高速化
コード保持率 88%

これらの数字は生産性の大幅な向上を示します。結果はチームやワークフローによって異なるため、まさにそのために Usage Metrics API が存在します。バックエンドのインフラチームとフロントエンドのプロトタイピングチームでは、Copilot との関わり方が異なるでしょう。

生データからチームダッシュボードへ

軽量なレポーティングワークフローは次のような形が一般的です。

スケジュール実行の API 呼び出し
レスポンスをデータベースまたはスプレッドシートに保存
レポート用テーブルへのデータ変換
既存の BI プラットフォームで可視化

スタック自体よりも、継続性のほうが重要です。

スケジュール実行の Python スクリプトと CSV エクスポートといったシンプルなワークフローでも、運用上の可視性は十分に得られます。

アーキテクチャ例：

GitHub API

↓

Scheduled Python Script

↓

PostgreSQL / CSV / Spreadsheet

↓

Power BI / Tableau / Looker

まとめ

GitHub Copilot Enterprise は、AI 対応のコード基盤を構築することに主眼があります。Spaces は、実際のエンジニアリング環境で Copilot を有用にする組織コンテキストを提供し、Usage Metrics API は採用が成功しているかを把握するためのテレメトリを提供します。

Copilot Enterprise で最も良い成果を上げている組織には共通点があります。