この記事のポイント
- Copilotの動作記録を入力・応答・ツールなど5種類に分けて設定でき、監査に必要な内容だけを選べます。
- 利用者名や端末名の記録は別設定で、初期状態ではすべてオフ。内容の一括取得設定でも識別情報は有効になりません。
- 企業の管理設定は利用者側の設定より優先。コードやファイルの内容も送信対象になり得るため、記録先との照合が必要です。
GitHubの2026年10月12日の変更を、Copilotの監査設計という観点から紹介します。対象はCopilot CLI、Copilotアプリ、Agent Hostを使うVS Codeセッション。利用者の識別と処理内容の記録を分けて整理します。
取得する情報を5つの単位で個別に選べる
ひとことで言うと、「何を記録するか」を5つのカテゴリーに分けて、それぞれオン・オフできるようになったということです。具体的には次の5種類です。
- prompts: ユーザー・システム・開発者からのプロンプトと、やり取りの前提になる入力内容
- responses: AIが返した応答と、対応している推論内容
- toolArguments: ツールへ渡す指定値や実行命令、使ったツール・MCPサーバー・フックの識別情報
- toolOutput: ツールを実行した結果やエラーの詳細
- policyDetail: サンドボックス(AIが操作できる範囲を区切る仕組み)のファイルパスなど、制御ルールの加工前の詳細
これらはすべて初期設定ではオフです。従来からある「captureContent」という一括設定を使うと、上記5つをまとめて有効にできますが、個別に選ぶほうが取得範囲を絞りやすくなっています。加えて、Copilotのアカウント名やOSのアカウント名、マシン名といった「誰が使ったか」を示す識別情報も、別の設定で追加できるようになりました(こちらも初期設定ではオフで、captureContentでは有効になりません)。
監査の必要な範囲だけ記録する、という考え方
この機能が効いてくるのは、情報システムやセキュリティを担当している方が、社内でのCopilot利用状況を把握したい場面です。従来の内容を一括取得する設定に加え、今回の変更で、監査に必要な項目だけを選んで取得し、それ以外は収集しないという運用がしやすくなりました。管理者側の設定は、利用者の端末ごとの設定よりも優先されるため、対象クライアントで会社として決めた取得範囲を優先できます。
ただし、prompts・toolArguments・toolOutput・policyDetailを有効にすると、ソースコードやファイルの内容、コマンド、作業フォルダーの場所なども記録対象に含まれ得ます。公式ドキュメントも、監査目的に必要な範囲だけを有効にし、送信先も承認済みの収集基盤に限ることを勧めています。
まとめ:監査の目的と、送信してよい情報を合わせる
Copilotの監査設計を担当する方にとって、利用者を特定する記録と、入力・応答の内容を分けて選べることが今回の要点です。監査に必要な項目と、収集先へ送ってよい情報を照らし合わせると、自社に合う取得範囲を検討しやすくなります。
※2026年10月時点の情報です。公式changelogを参照しています。
セキュリティ運用の省力化という観点では、コードスキャンの脆弱性をAIが自律修正する「Agentic autofix」の記事も参考になります。
Copilotの運用ルールという観点では、モデル利用ポリシーをAPIで一括管理できるようになった変更も紹介しています。利用ルールと監査記録を合わせて設計すると、何を許可し、何を後から確認するかを整理しやすくなるでしょう。
