GitHub Copilotの利用監視を強化したい企業は、2026年7月8日に公開されたenterprise-managed OpenTelemetry exportを先に押さえると判断が早くなります。今回の更新で、VS CodeとCopilot CLIの両方に対して、管理者がOTLP collectorの送信先やヘッダー、content captureの可否を中央設定できるようになりました。開発者ごとにOTEL環境変数を配る運用から抜け出しつつ、どこまでログを取り、どこからは取らないかをルール化しやすくなったのが一番の変化です。
何が変わったのか
GitHubの7月8日告知によると、Copilot managed settings の telemetry block で OpenTelemetry export を一括制御できるようになりました。対象は VS Code の Copilot Chat 拡張と、Copilot CLI を支える agent host process です。管理者は endpoint、protocol、service name、resource attributes、exporter headers、promptやresponseやtool contentを収集するかどうかまで指定できます。しかも managed value が入ると、個人の user settings や環境変数より優先されます。
対象環境と前提条件
公式ドキュメントでは、enterprise-managed settings は enterprise owners が GitHub Copilot plan のユーザーへ配る前提です。配布方法は server-managed、MDM-managed、file-based の3通りで、GitHub Docsでは server-managed を既定、MDM を端末グループ配布向け、file-based をコンテナや Codespaces を含む補完手段と整理しています。つまり、まずは自社がどのチャネルで managed-settings.json を配るかを決めないと、OTel だけ設定しても運用がばらつきます。
telemetry block で決められる項目
VS Code の enterprise AI settings では、telemetry.enabled、telemetry.endpoint、telemetry.protocol、telemetry.captureContent、telemetry.lockCaptureContent、telemetry.serviceName、telemetry.resourceAttributes、telemetry.headers が整理されています。実務では、この中でも endpoint と headers で collector を統制し、captureContent と lockCaptureContent でセンシティブ情報の扱いを止めるか固定する設計が重要です。特に headers は認証トークンを入れやすい項目ですが、GitHubは managed exporter headers を環境変数へ渡さず、Copilot Chat extension 側の OTLP exporter だけで使うと明記しています。
- endpoint: どの collector に送るかを固定する
- protocol: otlp-http か otlp-grpc を統一する
- captureContent: prompt・response・tool content を収集するか決める
- headers: collector 認証を個人設定に依存させない
監視で実際に見えるもの
VS Code の monitoring-agents ガイドでは、OTel を有効にすると traces、metrics、events が出力され、agent interaction 全体の invoke_agent span の下に chat span、execute_tool span、execute_hook span がぶら下がる構造だと説明されています。加えて model、token usage、cache read、tool call、hook decision、repository、branch、commit まで属性として取れます。ここが重要で、可視化の目的は『誰が使ったか』ではなく『どのリポジトリで、どのモデルが、どのツールを呼び、どこで遅くなったか』を追うことにあります。
導入時に先に決めたい3つの論点
第1に、content capture を本当に有効化するかです。公式には既定で無効で、コードやファイル内容、ユーザープロンプトなどの機微情報を含み得るため trusted environment のみで有効化すべきと注意されています。第2に、server-managed と MDM のどちらを主軸にするかです。GitHub Docsでは server-managed は約1時間で反映、再起動か再サインインで即時反映、MDM は端末再起動不要で定期同期です。第3に、何をアラート対象にするかです。token usage、time to first token、tool call失敗、特定repositoryの遅延など、可視化だけで終わらせない条件を先に置くべきです。
導入手順はこの順番が無難
まず小さな開発チームで collector と dashboard を用意し、captureContent は切ったまま metadata だけで運用を始めます。次に managed-settings.json で telemetry block を配り、VS Code と Copilot CLI の両方で span が上がることを確認します。その後、リポジトリ、モデル、tool failure を軸にダッシュボードを作り、最後に必要なチームだけ content capture の是非を個別に審査する流れが安全です。いきなり全社一斉に詳細ログを取るより、まずは最小収集で価値が出るかを確かめた方が社内説明が通しやすくなります。
まとめ
GitHub Copilot の enterprise-managed OpenTelemetry export は、単なる監視機能追加ではなく、VS Code と Copilot CLI の運用を同じ統制線に載せる更新です。確認すべきポイントは、どの配布チャネルで managed settings を届けるか、collector 認証をどう守るか、content capture をどこまで許すか、そして可視化をどの運用指標に結びつけるかの4点です。GitHub Copilot の監視設計やログ統制、部門導入ルールを見直したい場合は、
HelloCraftAIへ相談してください。収集項目の線引き、ダッシュボード要件整理、開発現場への周知まで伴走できます。
