GitHub Copilotの企業管理OpenTelemetry出力とは？VS Code・CLIの変更点と導入判断

GitHubが公開した「GitHub Copilot adds enterprise-managed OpenTelemetry export for VS Code and CLI」の要点は、GitHub CopilotのOpenTelemetry（OTel）送信先や取得範囲を、開発者ごとの設定ではなく企業ポリシーで統一できるようになったことです。

すでにOTEL_*環境変数やVS Code設定でテレメトリーを収集している場合、収集基盤を全面的に作り直す更新ではありません。ただし、企業の管理値が環境変数やユーザー設定より優先されるため、既存の送信先、プロトコル、コンテンツ取得設定が意図せず上書きされないか確認が必要です。特に、認証ヘッダーがCopilot CLI側に渡らない点と、ターミナルで動くCLIがOTLP/HTTPのみを使用する点は、導入前に必ずテストすべきです。(The GitHub Blog)

2026年7月9日時点で確認できるGitHub公式Changelogの表記は、2026年7月8日付です。また、MDM・ファイルベースの配布機能は一般提供と案内されている一方、GitHub DocsのEnterprise managed settings referenceにはPublic Previewの表記があります。全社展開の前に、小規模なパイロット導入を行うのが安全です。(The GitHub Blog)

まず確認したい結論：対応が必要な環境と不要な環境

今回の変更は、GitHub Copilotの利用者全員が設定を変更しなければならない更新ではありません。対応要否は、現在のOTel利用状況と企業のデータ統制方針で判断できます。

現在の状況	対応優先度	取るべき対応
開発者ごとに`OTEL_*`環境変数を設定している	高	現在の設定を棚卸しし、企業管理設定への移行を検討する
Copilotのトレースを承認済みコレクターへ集約したい	高	`telemetry`ブロックを使った集中管理を導入する
認証必須のOTLPコレクターを利用している	高	VS CodeとCopilot CLIを分けて認証テストする
OTLP/gRPC専用のコレクターを利用している	高	ターミナルCLIのOTLP/HTTP送信を受けられるか確認する
MDM、サーバー管理、ファイル配布を併用している	高	管理チャネルの優先順位と設定の集約先を見直す
OTelを使っておらず、開発者による任意送信も許容している	低	直ちに変更する必要はない
OTelを使っていないが、外部送信を禁止したい	高	`telemetry.enabled`を`false`で管理し、ユーザーによる有効化を防ぐ

OTel出力は標準では無効です。ただし、管理ポリシーがなければ、開発者はVS Code設定や環境変数で個別に有効化できます。厳格なデータ持ち出し管理が必要な企業では、「使うための設定」だけでなく「使わせないための設定」としても検討する価値があります。(Visual Studio Code)

GitHub CopilotのOpenTelemetry管理で何が変わったのか

最大の変更は、GitHub Copilot Chat拡張機能とCopilot CLIを動かすエージェントホストに対し、共通の企業管理設定を配布できるようになったことです。

項目	従来の主な方法	今回追加された企業管理
OTelの有効化	開発者がVS Code設定や環境変数を変更	管理者が有効・無効を指定
送信先	端末ごとにOTLPエンドポイントを設定	承認済みコレクターへ固定
プロトコル	開発者がHTTPまたはgRPCを選択	管理者が`otlp-http`または`otlp-grpc`を指定
サービス名	`OTEL_SERVICE_NAME`などで個別指定	企業共通のサービス名を配布
リソース属性	チームごとに環境変数で設定	部門や環境などの属性を集中管理
コンテンツ取得	開発者がオン・オフを変更	管理値と変更可否を指定
認証ヘッダー	主に環境変数で設定	管理設定から安全に配布
優先順位	環境変数がユーザー設定より優先	管理ポリシーが最優先

公式情報では、新しい独自テレメトリー形式を追加する更新ではなく、既存のOTel出力に企業向けの管理レイヤーを追加するものとして説明されています。そのため、既存のOTLP対応コレクターを利用している企業では、主に設定配布、認証、優先順位を見直すことになります。(The GitHub Blog)

企業が管理できるtelemetry設定

企業管理設定では、managed-settings.jsonのtelemetryブロックを使用します。

管理キー	用途	初期導入時の考え方
`telemetry.enabled`	OTel出力の有効・無効	パイロット対象だけ有効にする
`telemetry.endpoint`	OTLPコレクターの送信先	検証用と本番用を分ける
`telemetry.protocol`	`otlp-http`または`otlp-grpc`	最初はCLIとの互換性が高いHTTPを推奨
`telemetry.captureContent`	プロンプト、応答、ツール内容の取得	原則として`false`から始める
`telemetry.lockCaptureContent`	コンテンツ取得設定の変更を禁止	`captureContent:false`と併用する
`telemetry.serviceName`	OTelの`service.name`	集計しやすい固定名称を付ける
`telemetry.resourceAttributes`	部門、環境などの付加属性	個人情報や機密情報を入れない
`telemetry.headers`	認証・ルーティング用ヘッダー	CLIには届かない点を踏まえて設計する

管理値は、対応するVS Codeポリシーやエージェントホスト設定へ変換されます。コンテンツ取得については、取得値に加えて、開発者が変更できるかどうかも管理できます。(Visual Studio Code)

基本的な設定例は次のとおりです。

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.com",
    "protocol": "otlp-http",
    "captureContent": false,
    "lockCaptureContent": true,
    "serviceName": "copilot",
    "resourceAttributes": {
      "deployment.environment": "pilot",
      "department": "engineering"
    }
  }
}

認証ヘッダーが必要な場合は、次のようなheadersを追加できます。

{
  "telemetry": {
    "headers": {
      "Authorization": "Bearer <TOKEN>"
    }
  }
}

実際には、上記の断片だけで既存ファイルを上書きしてはいけません。すでにpermissions、model、enabledPluginsなどを管理している場合は、既存のトップレベル設定を残したままtelemetryブロックを追加します。

また、サンプルのトークンを長期固定トークンへ置き換えるだけでは不十分です。設定ファイルやMDMを閲覧できる管理者の範囲、漏えい時の失効手順、トークンの更新手順まで決めておく必要があります。

既存のVS Code設定や環境変数との互換性

既存のOTel設定は、今回の更新後も利用できます。変わるのは、どの値が最終的に採用されるかという優先順位です。

優先順位は2段階で考える

企業管理では、次の2種類の優先順位があります。

管理チャネルの優先順位
Native MDM > Server-managed > File-based

各テレメトリー値の優先順位
管理ポリシー > 環境変数 > ユーザー設定 > 既定値

管理チャネルはマージされません。最も優先度の高いチャネルに何らかの管理設定があれば、そのチャネルが全体の管理元となり、下位チャネルは無視されます。VS Codeでは、このチャネル優先制御がバージョン1.128から適用されます。(Visual Studio Code)

たとえば、Native MDMにはモデル設定だけを置き、Server-managed設定にはtelemetryブロックを置いたとします。この場合、Native MDMが管理チャネルとして選ばれるため、サーバー側のテレメトリー設定が適用されない可能性があります。

管理設定を複数チャネルに分散させず、最上位となる1つのチャネルへ集約することが重要です。

既存設定と管理キーの対応

目的	既存のローカル設定	企業管理キー
有効化	`github.copilot.chat.otel.enabled`、`COPILOT_OTEL_ENABLED`	`telemetry.enabled`
エンドポイント	`github.copilot.chat.otel.otlpEndpoint`、`OTEL_EXPORTER_OTLP_ENDPOINT`	`telemetry.endpoint`
プロトコル	`github.copilot.chat.otel.exporterType`、`OTEL_EXPORTER_OTLP_PROTOCOL`	`telemetry.protocol`
コンテンツ取得	`github.copilot.chat.otel.captureContent`、`COPILOT_OTEL_CAPTURE_CONTENT`	`telemetry.captureContent`
サービス名	`OTEL_SERVICE_NAME`	`telemetry.serviceName`
リソース属性	`OTEL_RESOURCE_ATTRIBUTES`	`telemetry.resourceAttributes`
認証ヘッダー	`OTEL_EXPORTER_OTLP_HEADERS`	`telemetry.headers`

管理対象になっていない項目は、従来どおり環境変数やユーザー設定へフォールバックします。一方、同じ項目に管理値がある場合、開発者が環境変数を変更しても管理値は上書きできません。(Visual Studio Code)

すべてのOTel機能が企業管理されるわけではない

既存のローカルOTel機能には、今回の企業管理スキーマに含まれていない項目もあります。

consoleやfileへのデバッグ出力
属性サイズを制限するmaxAttributeSizeChars
ローカルSQLiteへトレースを保存するDB Span Exporter
OTelのログレベル
HTTPレベルの追加計装
JSON Linesファイルへの出力先

企業管理のtelemetry.protocolで指定できるのは、公開仕様上otlp-httpとotlp-grpcです。ローカルのコンソール出力やファイル出力まで、今回の設定ですべて集中管理できるわけではありません。(Visual Studio Code)

既存のサーバー管理ファイルも確認する

サーバー管理では、.github-privateリポジトリ内のcopilot/managed-settings.jsonが推奨パスです。従来の.github/copilot/settings.jsonも引き続きサポートされています。既存環境では、両方の場所に設定が分散していないか確認してください。(GitHub Docs)

VS CodeとCopilot CLIで異なる仕様

「VS CodeとCLIの両方に適用される」と聞くと、完全に同じ方法で送信されるように見えます。しかし、実際には実行プロセスや対応プロトコルに差があります。

確認項目	VS CodeのCopilot Chat	Copilot CLI・エージェントホスト
主な送信元	Copilot Chat拡張機能	CLI SDKまたは独立したCLIプロセス
管理エンドポイント	対応	対応
`otlp-http`	対応	対応
`otlp-grpc`	対応	ターミナルCLIはHTTPを使用
管理された認証ヘッダー	拡張機能のExporterへ適用	エージェントホストには渡されない
トレースの親子関係	拡張機能内で関連付けられる	ターミナルCLIは独立したルートトレースになる
設定変更の反映	再読み込みが必要な場合がある	起動時に設定を計算するため再起動・再読み込みが重要

VS Code内のバックグラウンドエージェントとして動くCopilot CLI SDKでは、拡張機能側のラッパースパンとCLI側のネイティブスパンが同じトレースに表示されます。一方、「New Copilot CLI Session」から起動するターミナルCLIは別プロセスで動作し、独立したルートトレースとして送信されます。(Visual Studio Code)

ターミナルCLIはOTLP/HTTPのみを使用する

公式監視ガイドでは、ターミナルCLIのランタイムはotlp-httpのみをサポートするとされています。管理側でotlp-grpcを指定していても、ターミナルCLIはHTTPを使用します。(Visual Studio Code)

そのため、初回導入では次の構成が扱いやすいでしょう。

管理プロトコルはotlp-httpにする
コレクター側でVS CodeとCLIの両方を受け付ける
gRPCを使う場合も、同じ送信先でHTTPを処理できるか確認する
VS Codeの成功だけで導入完了と判断しない

管理された認証ヘッダーはCLI側へ渡らない

telemetry.headersは、Copilot Chat拡張機能のOTLP Exporterにのみ適用されます。認証トークンがエージェントホストから起動されるツールのサブプロセスへ漏れることを防ぐため、環境変数としては受け渡されません。その結果、このリリースでは管理ヘッダーがエージェントホストへ配布されません。(Visual Studio Code)

コレクターが認証ヘッダーを必須としている場合、次のような状態が起こり得ます。

VS Codeのトレースは届く
Copilot CLIのトレースは認証エラーになる
管理画面上は同じエンドポイントに見える
コレクター側では一部のサービスだけが欠落する

この制約があるため、telemetry.headersを設定しただけでVS CodeとCLIの認証が統一されたと判断してはいけません。

OpenTelemetryで取得される情報とプライバシー

標準設定では、プロンプト本文、応答本文、ツール引数などのコンテンツは取得されません。モデル名、トークン数、処理時間、ツール名、エラー情報などのメタデータが中心です。(Visual Studio Code)

captureContentを有効にすると、次の情報がスパン属性へ含まれる可能性があります。

ユーザーのプロンプト
Copilotの応答
システムプロンプト
ツールのスキーマ
ツールの引数と実行結果
コードやファイル内容
シェルコマンドやファイルパス

公式ドキュメントも、コンテンツ取得にはコード、ファイル内容、ユーザープロンプトなどの機密情報が含まれる可能性があるとして注意を促しています。(Visual Studio Code)

企業での初期値は、次の組み合わせが安全です。

{
  "captureContent": false,
  "lockCaptureContent": true
}

メタデータだけで、モデル別の処理時間、トークン使用量、ツール呼び出し回数、エラー傾向など、多くの運用分析が可能です。コンテンツ本文が本当に必要かは、メタデータのみのパイロットを実施した後に判断するとよいでしょう。(Visual Studio Code)

また、resourceAttributesには個人名、メールアドレス、顧客名、機密プロジェクト名を直接入れないようにします。チームや部門で集計したい場合は、社内で定義した識別子や分類コードを使用するほうが安全です。

導入に必要な条件と3つの配布方法

企業管理設定は、Native MDM、Server-managed、File-basedの3経路で配布できます。

配布方法	主な用途	配布先・場所	注意点
Native MDM	Intune、Jamf、Group Policyなどによる端末管理	Windowsレジストリ、macOS管理対象設定	Linuxでは利用できない
Server-managed	GitHub上でのレビュー・履歴管理	`.github-private`内の`copilot/managed-settings.json`	GitHubアカウントへのサインインが必要
File-based	Chef、Puppet、Ansibleなど	OSごとの既定パス	配布漏れとファイル権限に注意

Native MDMの主な場所は次のとおりです。

OS	場所
Windows	`HKEY_LOCAL_MACHINE\SOFTWARE\Policies\GitHubCopilot`
macOS	`com.github.copilot`のManaged Preferences

ファイルベースの配置先は次のとおりです。

OS	`managed-settings.json`の配置先
Windows	`%ProgramFiles%\GitHubCopilot\managed-settings.json`
macOS	`/Library/Application Support/GitHubCopilot/managed-settings.json`
Linux	`/etc/github-copilot/managed-settings.json`

ファイルベース設定は、安全な所有者と権限で管理し、全ユーザーが書き込める状態やシンボリックリンクを避ける必要があります。また、設定ファイルが配布されなかった端末には制限が適用されません。(The GitHub Blog)

サーバー管理設定は通常、約1時間以内に更新されます。クライアントの再起動または再サインインで、より早く最新設定を取得できます。MDM管理では定期的にポリシーを確認し、VS CodeのDeveloper: Sync Account Policyコマンドでテスト用の同期を実行できます。(GitHub Docs)

ただし、ポリシーの取得が完了しても、起動中のエージェントホストは古いテレメトリー設定を保持することがあります。エンドポイントやプロトコルを変更した後は、VS Codeを再読み込みしてから検証してください。(Visual Studio Code)

導入手順

現在の設定を棚卸しする

最初に、開発者端末、開発コンテナー、CI環境、シェルプロファイルに設定されているOTel関連変数を確認します。

macOSやLinuxでは、次のコマンドで確認できます。

env | grep -E '^(OTEL_|COPILOT_OTEL_)'

PowerShellでは次のように確認できます。

Get-ChildItem Env: |
  Where-Object Name -Match '^(OTEL_|COPILOT_OTEL_)'

あわせて、VS Code設定で「copilot otel」を検索し、次の項目を確認します。

OTelが有効になっているか
現在のOTLPエンドポイント
HTTPとgRPCのどちらを使用しているか
コンテンツ取得が有効か
ファイルやSQLiteへのローカル出力を使用しているか

収集目的を決める

「収集できるから収集する」のではなく、先に目的を決めます。

具体的には、次のどれを知りたいのかを明確にします。

モデル別の応答時間
トークン使用量
ツール呼び出しの成功率
エージェント処理の所要時間
エラーの種類
AI生成コードの受け入れ・拒否傾向

目的がメタデータで達成できるなら、captureContentを有効にする必要はありません。

管理チャネルを1つに集約する

既存のMDM管理があるなら、テレメトリー設定をサーバー管理へ分離せず、MDM側へまとめることを検討します。

反対に、端末グループ単位の制御が不要で、GitHub上のレビュー履歴を重視する場合は、Server-managed設定が適しています。

重要なのは、異なる管理項目を複数チャネルへ分散しないことです。

検証用コレクターを準備する

本番の監視基盤へ直接送る前に、検証用のOTLPエンドポイントを用意します。

次の項目を確認します。

OTLP/HTTPを受信できるか
OTLP/gRPCを使う場合もCLIのHTTP送信を処理できるか
TLS証明書をクライアントが信頼できるか
プロキシやファイアウォールを通過できるか
認証ヘッダーなしのCLIをどう扱うか
属性サイズやデータ量の上限
保存期間と閲覧権限

小規模グループへ配布する

GitHub Docsでは、どの配布方法でも小規模な端末グループでパイロットを行ってから、広範囲へ展開することが推奨されています。(GitHub Docs)

パイロットでは、次の利用者を含めると問題を見つけやすくなります。

WindowsとmacOSの利用者
Linuxまたは開発コンテナーの利用者
VS CodeのCopilot Chat利用者
Copilot CLIの利用者
プロキシ経由の利用者
複数のGitHubアカウントを切り替える利用者

適用されたポリシーを確認する

VS Codeでは、Developer: Policy Diagnosticsコマンドを実行すると、適用中のポリシーと使用されている管理チャネルを確認できます。(Visual Studio Code)

設定ファイルの内容だけを確認するのではなく、クライアントが実際に解決した値を確認することが重要です。

VS Codeを再読み込みしてからテストする

テレメトリー設定を変更した後は、次の順序で確認します。

管理ポリシーを同期する
VS Codeを再読み込みする
新しいCopilot Chatセッションを開始する
読み取り専用のツール操作を1回実行する
Copilot CLIでも別のセッションを開始する
コレクター側で両方のトレースを確認する

導入テストで確認すべき項目

テスト	操作	期待する結果
管理チャネル	Policy Diagnosticsを実行	想定したMDM、Server、Fileのいずれかが表示される
エンドポイント強制	異なる`OTEL_EXPORTER_OTLP_ENDPOINT`を設定	管理された送信先が使用される
VS Code送信	Chatで安全な質問を実行	拡張機能のトレースが届く
CLI送信	Copilot CLIで安全な処理を実行	CLI側のスパンが届く
プロトコル	`otlp-grpc`構成でターミナルCLIを実行	HTTPでの送信をコレクターが受け付ける
コンテンツ非取得	`captureContent:false`で実行	プロンプトや応答本文が保存されない
設定ロック	ユーザーがコンテンツ取得を有効化	管理ポリシーにより変更できない
認証	ヘッダー必須コレクターへ送信	VS CodeとCLIを別々に確認する
設定変更	エンドポイントを変更して再読み込み	古い送信先への新規送信が止まる
停止	`telemetry.enabled:false`を配布	新しいOTelデータが送信されない

コンテンツ取得の確認では、機密コードを使わないテスト用ワークスペースを用意してください。誤ってcaptureContentが有効になっていた場合でも、実データを外部コレクターへ送らずに済みます。

失敗しやすいポイント

Server-managed設定が反映されない

Native MDMに別の管理設定が1つでも存在すると、MDMが管理チャネルとして選ばれ、Server-managedやFile-basedの設定が無視される可能性があります。

テレメトリー設定だけを見るのではなく、モデル、プラグイン、権限設定を含む管理設定全体を確認してください。

VS Codeでは届くがCLIでは届かない

代表的な原因は次の2つです。

管理された認証ヘッダーがエージェントホストへ渡っていない
コレクターがgRPCのみを受け付け、CLIが送るHTTPを処理できない

まず、コレクターの401・403エラーと、HTTPエンドポイントの待ち受け状況を確認します。

設定変更後も古いコレクターへ送られる

エージェントホストは起動時にテレメトリー設定を計算します。ポリシー同期後にVS Codeを再読み込みしていない場合、古い設定が使われ続けることがあります。

一部の端末だけ設定が適用されない

ファイルベースでは、配布されていない端末にポリシーは適用されません。配置先、ファイル所有者、書き込み権限、シンボリックリンクの有無を確認します。

管理設定を削除したらOTelが再び有効になった

管理設定を削除すると、環境変数やユーザー設定へフォールバックします。緊急停止時にtelemetryブロックを削除するだけでは、開発者のOTEL_EXPORTER_OTLP_ENDPOINTによって再び有効になる可能性があります。

停止を確実にする場合は、まず次の設定を明示的に配布します。

{
  "telemetry": {
    "enabled": false
  }
}

その後、下位の管理チャネル、環境変数、VS Code設定に残っている値を整理します。

まとめ：最初に行うべきこと

GitHub Copilotのenterprise-managed OpenTelemetry exportは、OTelそのものを新しく導入する機能というより、VS CodeとCopilot CLIの観測設定を企業が統制するための更新です。

すでにOTelを利用している企業は、まずOTEL_*環境変数、VS Code設定、既存のmanaged-settings.jsonを棚卸ししてください。そのうえで、管理チャネルを1つに集約し、captureContent:falseとlockCaptureContent:trueを基本にパイロットを開始します。

検証では、VS Codeのトレースが届くだけで完了とせず、Copilot CLIのプロトコルと認証を必ず別に確認します。OTelを利用しない企業でも、開発者による任意の外部送信を防ぐ必要があるなら、telemetry.enabled:falseの企業管理を検討するのが次の行動です。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。

GitHub Copilotの企業管理OpenTelemetry出力とは？VS Code・CLIの変更点と導入判断

まず確認したい結論：対応が必要な環境と不要な環境

GitHub CopilotのOpenTelemetry管理で何が変わったのか

企業が管理できるtelemetry設定

既存のVS Code設定や環境変数との互換性

優先順位は2段階で考える

既存設定と管理キーの対応

すべてのOTel機能が企業管理されるわけではない

既存のサーバー管理ファイルも確認する

VS CodeとCopilot CLIで異なる仕様

ターミナルCLIはOTLP/HTTPのみを使用する

管理された認証ヘッダーはCLI側へ渡らない

OpenTelemetryで取得される情報とプライバシー

導入に必要な条件と3つの配布方法

導入手順

現在の設定を棚卸しする

収集目的を決める

管理チャネルを1つに集約する

検証用コレクターを準備する

小規模グループへ配布する

適用されたポリシーを確認する

VS Codeを再読み込みしてからテストする

導入テストで確認すべき項目

失敗しやすいポイント

Server-managed設定が反映されない

VS Codeでは届くがCLIでは届かない

設定変更後も古いコレクターへ送られる

一部の端末だけ設定が適用されない

管理設定を削除したらOTelが再び有効になった

まとめ：最初に行うべきこと

この記事を書いた人

コメント

コメントするコメントをキャンセル

GitHub Copilotの企業管理OpenTelemetry出力とは？VS Code・CLIの変更点と導入判断

まず確認したい結論：対応が必要な環境と不要な環境

GitHub CopilotのOpenTelemetry管理で何が変わったのか

企業が管理できるtelemetry設定

既存のVS Code設定や環境変数との互換性

優先順位は2段階で考える

既存設定と管理キーの対応

すべてのOTel機能が企業管理されるわけではない

既存のサーバー管理ファイルも確認する

VS CodeとCopilot CLIで異なる仕様

ターミナルCLIはOTLP/HTTPのみを使用する

管理された認証ヘッダーはCLI側へ渡らない

OpenTelemetryで取得される情報とプライバシー

導入に必要な条件と3つの配布方法

導入手順

現在の設定を棚卸しする

収集目的を決める

管理チャネルを1つに集約する

検証用コレクターを準備する

小規模グループへ配布する

適用されたポリシーを確認する

VS Codeを再読み込みしてからテストする

導入テストで確認すべき項目

失敗しやすいポイント

Server-managed設定が反映されない

VS Codeでは届くがCLIでは届かない

設定変更後も古いコレクターへ送られる

一部の端末だけ設定が適用されない

管理設定を削除したらOTelが再び有効になった

まとめ：最初に行うべきこと

この記事を書いた人

関連記事

コメント

コメントする コメントをキャンセル

コメントするコメントをキャンセル