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

GitHub Copilot Enterprise が Spaces と Usage Metrics API を用いて、エンジニアリング組織全体での文脈付け、ガバナンス、導入トラッキングをどのように提供するかを学びます。

更新 2026年6月2日 · 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 を最大限に活用している企業は、これを社内インフラの重要コンポーネントとして扱っています。組織コンテキストを丁寧に設定し、導入状況を継続的に測定し、仮説ではなく利用データに基づいてポリシーを調整します。

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

Enterprise と Business／Pro+ の違い

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

組織レベルの使用状況メトリクス
拡張されたガバナンス制御
エンタープライズ全体のポリシー継承
より大きなプレミアムリクエスト割当（Business の 300 に対し 1,000）
追加のモデルアクセスと管理

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

機能	Pro+	Business	Enterprise
個人での利用	Yes	No	No
座席の一元管理	No	Yes	Yes
監査ログ	No	Yes	Yes
ファイル除外	No	Yes	Yes
Spaces サポート	Yes, with Copilot	Yes, Limited admin visibility	Yes, Full enterprise management
Usage Metrics API	No	Org-level	Enterprise + Org-level
エンタープライズのポリシー継承	No	No	Yes

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

GitHub Copilot Enterprise の対象

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

典型的な Enterprise 顧客には次が含まれます。

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

なお、これは Copilot の性能自体を本質的に向上させるものではありません。多くのチームが初期段階で過剰購入してしまう点は重要です。Enterprise =「より良い Copilot」と思い込みがちですが、実際には Enterprise が追加するのは主にガバナンスと測定のためのツール群です。

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

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

箱から出した直後の Copilot は、公開されているプログラミング知識をある程度理解しています。しかし、社内の API、アーキテクチャ上の意思決定、コーディング規約、デプロイワークフロー、オンボーディング文書を自動的に理解するわけではありません。

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

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

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

Spaces がサポートするもの

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

サポートされるコンテンツタイプは次のとおりです。

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

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

コードファイルは Copilot が実装パターンを理解する助けになります。Markdown ファイルはアーキテクチャの説明やオンボーディングの手引きを提供します。プルリクエストはレビューの議論や過去の技術的意思決定を露出します。これらの組み合わせにより、Copilot は組織の開発プラクティスをよりよく把握できます。

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

Knowledge Bases のサンセット

GitHub は旧来の Copilot Knowledge Bases 機能を 2025 年 11 月 1 日にサンセットしました。

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

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

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

Copilot Spaces の作成と設定

管理の観点では、Copilot Spaces の作成は比較的シンプルです。課題は、チーム横断で数十から数百の Space を管理することにあります。

初期に選んだ構造はその後も残りがちです。所有ルールを事前に定めなかったために、Spaces 内で「ドキュメントの乱立」を招いてしまった組織を見てきました。

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

Space のセットアップ

Space の作成は概ね次のワークフローに従います。

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

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

右側の「+ Add sources」ボタンをクリックしてソースを追加

この段階で Space を共有するか、共有設定を行うことも可能

チャットのやり取り中に Copilot がコンテンツを参照できることを確認

エンタープライズユーザー向けの注意：管理者は個人 Spaces の共有をオフにできます。個人アカウントを使用している場合、エンタープライズのリポジトリを使っていない 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 つの可視性モデルをサポートします。

個人用 Spaces
組織全体の Spaces

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

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

よくある失敗は過度の集中化です。全社共通の巨大な 1 つの Space はノイズが多くなり、Copilot が効果的に活用しづらくなります。

チームまたはドメインごとの Space 編成

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

一般的なパターンには、チームごとに 1 つ、プロダクト領域ごとに 1 つ、共有の標準 Space などがあります。いずれもスコープが異なり、同じ設定スペースを使い分けます。

チームごとに 1 つの Space

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

例：

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

プロダクト領域ごとに 1 つの Space

部門ではなくプロダクトを軸に構成された組織に有効です。

例：

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

共有の標準 Space

多くの組織は次のために別の共有 Space を維持しています。

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

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

Copilot Usage Metrics API

Spaces はコンテキストの問題を解決します。Usage Metrics API は測定の問題を解決します。これは 2026 年の API 統合で GitHub が廃止した複数の旧来テレメトリシステムを置き換えました。

明確な測定がなければ、組織は Copilot 導入の成否をすぐに把握できなくなります。投資が開発者のワークフローを改善しているのか、単にサブスクリプションが増えただけなのかを、経営層は証拠で知りたがります。

ダッシュボードは 2026 年 2 月に GA に到達し、エンタープライズアカウント → 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 data ドキュメントを参照してください。

ユーザーレベルレポートには 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

↓

スケジュール実行の Python スクリプト

↓

PostgreSQL / CSV / スプレッドシート

↓

Power BI / Tableau / Looker

まとめ

GitHub Copilot Enterprise の肝は、AI 対応のコード基盤を築くことです。Spaces は、実際のエンジニアリング環境で Copilot を有用にする組織コンテキストを提供します。Usage Metrics API は、導入が成功しているかどうかを理解するために必要なテレメトリを提供します。

Copilot Enterprise で最も強い成果を上げている組織には、共通のパターンがあります。