会社から配られたGitHub Copilotを使っていると、自分が入力したプロンプトが記録されるのか気になる場面があります。2026年10月12日のGitHub Changelogで、企業の管理者がmanaged settings（会社側がまとめて配る設定）のtelemetryを使い、プロンプトや回答やツールの内容を集めずにGitHub Copilotの活動を利用者本人に結びつけられるようになったと公開されました。何が既定でオフなのか、どの設定名を確認すればよいのかを整理します。
要点
- 2026年10月12日のGitHub Changelogで、企業の管理者がmanaged settingsのtelemetryを使い、プロンプトや回答やツールの内容を集めずにGitHub Copilotの活動を利用者に結びつけられるようになったと公開された
- telemetry.capture.identityを有効にすると、OpenTelemetryのデータにuser.name・process.user.name・host.nameの3つの属性が追加される
- prompts・responses・toolArguments・toolOutput・policyDetailの5つの取得クラスは管理者が個別に制御でき、すべての取得クラスは既定でオフ
- identityの取得も既定でオフで、既存の仮名ユーザー識別子とは別に扱われる
- 細かい取得制御が使えるのはCopilot CLI・GitHub Copilot app・Agent Hostを使うVS Codeセッション
何が発表されたか
企業の管理者がmanaged settingsのtelemetryを使って、プロンプト・回答・ツールの内容を収集せずにGitHub Copilotの活動を利用者本人に結びつけられるようになりました。
前提として登場するOpenTelemetry（OTel）は、オープンソースの可観測性フレームワーク（動作の中身を観測して外部ツールに送る仕組み）です。GitHub Docsによると、Copilotが送るデータは3種類あります。エージェントのセッションの流れをモデル呼び出しやツール利用まで含めてつなぐtraces、時間の経過とともにパターンを見つけるための数値であるmetrics、ある時点の個々の操作を記録するeventsです。
誰が使ったかを記録するidentity
telemetry.capture.identityを有効にすると、OTelデータに3つの属性が加わります。user.nameは認証済みのCopilotアカウント名で、現時点ではGitHubのログイン名です。process.user.nameはローカルのOSアカウント、host.nameはローカルのマシン名です。identityの取得は既定でオフで、既存の仮名ユーザー識別子とは別に扱われます。
内容側は5つのクラスに分かれる
管理者が個別に制御できる取得クラスは、次の5つが追加されています。
- prompts: ユーザー・システム・開発者のプロンプトと、対応する入力コンテキスト
- responses: アシスタントの回答と、対応するreasoning（推論）の内容
- toolArguments: 生のツール引数・コマンド・ツールのスキーマと、ツールやMCPサーバーやプラグインやフックの識別子
- toolOutput: ツールの実行結果と実行エラーの詳細
- policyDetail: サンドボックスのファイルシステムのパスのような生のポリシー詳細
すべての取得クラスは既定でオフです。GitHub Docsでも、既定のデータには直接個人を特定する属性・プロンプト・回答・ツール引数・ツール結果・生のポリシー詳細は含まれないと書かれています。policyDetailを無効にしていても、範囲の定まったポリシーの状態と結果は引き続き利用できます。
設定の優先順位と対応するクライアント
明示的に指定されたmanagedの値は、ローカル設定・SDKの設定・環境変数よりも優先されます。細かい取得制御が使えるのはCopilot CLI・GitHub Copilot app・Agent Hostを使うVS Codeセッションです。VS Codeのローカルエージェントハーネスはidentityの取得と従来の一括型のcontent capture設定には対応しますが、5つのcontent captureクラスを個別には適用しません。
従来のcaptureContentは5つの内容クラスをまとめて切り替えるレガシーの短縮設定として残りますが、identityを有効にすることはありません。設定の多くはmanaged-settings.jsonに記述し、telemetryにはenabled・endpoint・protocol・capture・captureContent・lockCaptureContent・serviceName・resourceAttributes・headersが指定できます。captureの各サブプロパティの既定値はfalseです。lockCaptureContentをtrueにすると、管理側のtelemetryでそのクラスかcaptureContentを明示しない限り、ローカル設定からレガシーの内容クラスを有効にできなくなります。この設定はidentityには及びません。
GitHubはChangelogで、プロンプト・ツール・ポリシーの取得にはソースコード・ファイル内容・コマンド・ツール結果・ワークスペースやユーザープロファイルのパスが含まれうると注意しています。そのうえで、監査の用途に必要なクラスだけを有効にし、承認済みの収集先へ送るよう案内しています。
個人の仕事や学びにどう使えるか
記録される範囲を設定名で確認する
社内SEやWebエンジニアが情報システム部門に問い合わせるとき、「ログは残りますか」と漠然と聞く代わりに、telemetry.capture.promptsやresponsesが有効かどうかを尋ねられます。すべての取得クラスが既定でオフという前提があるので、会話の出発点がはっきりします。
機密を含む作業の線引きを決める
受託開発のフリーランスなら、顧客のコードを開いた状態でエージェントを動かす前に、toolArgumentsとtoolOutputの扱いを確かめておく価値があります。ここには生のコマンドやツールの実行結果、実行エラーの詳細が含まれます。
利用実績の見え方を区別して説明する
identityだけを有効にした環境では、GitHubのログイン名やマシン名は記録されますが、会話やツールの内容は集められません。人事・労務や営業の立場でCopilotの社内利用を説明する人も、見えているものと見えていないものを分けて話せます。
会社・チームで使うときのポイント
OTelのデータを集めるには、OTLP（OpenTelemetry Protocol）に対応した安全なバックエンドを選び、各利用者のクライアントでendpointとheadersと認証トークンを設定します。managedのtelemetryを複数のソースが定義している場合は、最も優先度の高いソースが完全なmanaged telemetryオブジェクトを提供し、下位のソースのオブジェクトは統合されません。記録の範囲は社員の納得感に直結するため、有効にするクラスと目的を先に決めて共有しておくと説明が楽になります。法人でAI活用の導入や研修を検討しているなら、導入社数No.1の法人向けAIリスキリングサービスを提供する株式会社デジライズに相談できます。
使う前の注意点
細かい取得制御に対応するクライアントはCopilot CLI・GitHub Copilot app・Agent Hostを使うVS Codeセッションで、VS Codeのローカルエージェントハーネスは5つの内容クラスを個別には適用しません。取得クラスは既定でオフですが、管理者が有効化できる設計であり、明示的なmanagedの値はローカル設定や環境変数より優先されます。つまり自分の手元の設定だけを見て判断するのは避けたいところです。勤務先で実際に何が有効になっているかは社内の管理者に確認し、あわせてGitHubの公式ヘルプで最新の仕様と対応範囲を確かめてから使い始めてください。
まとめ
今回の変更は、利用者を特定する情報と会話の内容を別々に扱えるようにしたものです。どちらも既定でオフという点と、設定名で会話できるという点を押さえておけば、会社のGitHub Copilotと落ち着いて付き合えます。プロンプトの扱いや業務での使い方を体系的に学びたい人は、デジライズAIスクールのコース一覧から「IT・デジタルのプロンプト活用」などを見てみてください。
出典
- Client telemetry user attribution and configurable capture - GitHub Changelog
- OpenTelemetry for agent monitoring - GitHub Docs
- Enterprise managed settings - GitHub Docs
この記事は、各社の公式の発表をもとに AI で下書きし、出典の本文との照合とGoogle 検索による事実確認（ファクトチェック）を通ったものだけを公開しています。
