GitHub Copilotは、VS CodeとCopilot CLIのOpenTelemetry送信先を企業管理設定で統一できるようになった。可観測性を中央化できる一方、content取得を有効にするとprompt、response、tool内容がcollectorへ複製されるため、監査とプライバシーを同時に設計する必要がある。
何が変わったか
企業はCopilot managed settingsのtelemetry blockを使い、VS CodeのCopilot Chat拡張とCopilot CLIを動かすagent hostへ同じOTel設定を強制できる。OTLP endpoint、HTTPまたはgRPC、service name、resource attributes、exporter header、prompt・response・tool contentを取得するかを管理できる。
管理値は環境変数やユーザー設定より優先する。配布経路はnative MDM、GitHubアカウントから解決するserver-managed settings、managed-settings.jsonのfile-based設定がある。
変更前後の差
| 項目 | 開発者個別設定 | 企業管理設定 |
|---|---|---|
| 送信先 | OTEL_*環境変数ごと | 承認collectorへ統一 |
| 対象 | 端末・clientごとに差 | VS CodeとCLIへ共通適用 |
| protocol | 個人設定 | otlp-http・otlp-grpcを強制 |
| content取得 | 利用者判断 | 管理者が設定・lock可能 |
| resource属性 | 不統一 | 組織・環境タグを統一 |
| 優先順位 | 環境差が残る | managed valueが常に優先 |
誰に影響するか
Copilot Agent利用をSIEM、APM、FinOps基盤へ統合する企業、開発者端末の設定をMDMで管理する組織、VS CodeとCopilot CLIを併用するチームに影響する。単に利用者数を確認するだけなら、promptやresponse本文を収集せず、span・metricの最小情報から始めるべきである。
期限
強制移行期限はない。企業管理設定は段階的に配布できる。collectorと保存方針を準備せずに全端末へ有効化すると、送信失敗や機密収集が同時発生するため、少数端末で検証する。
必要な対応
既定はcaptureContent=falseとし、必要性を立証できる環境だけで本文取得を検討する。OTLP headerへtokenを設定する場合は、設定ファイルやRegistryの読み取り権限を制限し、collector側で短期credentialやmTLSを使う。resource attributesには組織、環境、端末区分を付けるが、個人名やrepository秘密情報を含めない。
MDM、server、fileのどのchannelが有効かをPolicy Diagnosticsで確認する。
実装・移行手順
- 収集目的と必要なspan・metric・logを定義する。
- collectorのTLS、認証、rate limit、保存期間を設定する。
- captureContentを無効にした設定を検証端末へ配布する。
- VS CodeとCopilot CLIの両方からtraceが届くか確認する。
- managed設定が環境変数・user設定へ優先することを試す。
- secret、prompt、response、tool引数がpayloadへ入っていないか検査する。
- collector停止時のclient影響とbuffer上限を故障試験する。
失敗しやすい点
可観測性を高めるために最初からcontent取得を有効化する、OTLP認証tokenを平文のfile-based設定へ配る、MDMとserver設定がmergeされると誤認する、Linux端末へWindows・macOS向けMDM設定を期待する、collector障害をCopilot障害と誤判定することが問題になる。
リスク
source code、prompt、tool引数、応答に含まれる秘密情報の流出、collector token漏えい、個人単位の過剰監視、trace保存期間の長期化、endpoint誤設定による外部送信がある。管理値が強く優先されるため、誤った設定は全開発者へ一斉に波及する。
評価方法
- 管理対象端末の設定適用率
- VS Code・CLI別trace受信率
- collectorへの送信失敗率
- payload内のsecret検出件数
- captureContent有効端末数
- trace取り込みから検索可能までの遅延
- 保存期限を超えたtelemetry件数
- 設定rollback完了時間
ロールバック
telemetry.enabledを無効化する管理設定を同じchannelで配布し、collectorへの新規送信を止める。誤ってcontentを取得した場合はcollector側のindex、backup、export先を特定して削除手順を実行する。設定channelを切り替える場合は、優先順位の高いchannelに古い値が残っていないか確認する。
編集部分析
企業管理OTelの主目的は、開発者ごとに設定を揃えることではなく、監視データの境界を組織が決めることである。Agentの本文を集めれば調査は容易になるが、コードと業務情報を第二の保存基盤へ複製する。まずmetadataだけで運用指標を作り、本文収集は例外として扱うべきだ。
実務チェックリスト
- [ ] captureContentを既定で無効にした
- [ ] OTLP endpointとTLSを承認した
- [ ] header secretの配布方法を確認した
- [ ] VS CodeとCLIを別々に試験した
- [ ] Policy Diagnosticsで適用channelを確認した
- [ ] payloadのsecret scanを行った
- [ ] telemetry停止と削除手順を試した