GitHub Copilotのエージェントの動きを監視ツールで追えるように。既定でプロンプト除外

GitHub Copilot OpenTelemetry対応は、Copilotのエージェント活動を組織の監視基盤から追えるようにする管理者向けの更新です。

📖 この記事で分かること

• Copilotのエージェント活動をOpenTelemetryで外部送信できる
• 送られるのはトレース・メトリクス・イベントの3種類
• プロンプトと応答、ツール引数は既定で除外される
• 設定は管理者がmanaged-settings.jsonで一括指定する

💡 知っておきたい用語

• OpenTelemetry:アプリの内部動作を「いつ・何が・どの順で起きたか」の記録として外部の監視サービスへ送るための、業界共通の仕組み。特定ベンダーに縛られない共通規格として使われている。

最終更新日: 2026年9月23日

▶ 公式ページ

• OpenTelemetry in the GitHub Copilot app(GitHub Changelog)
• OpenTelemetry for agent monitoring(GitHub Docs)
• Get started with managed settings(GitHub Docs)

GitHub CopilotがOpenTelemetryに対応

この記事のポイント

• GitHubは2026年9月22日、GitHub Copilotアプリ(2026年9月時点)がOpenTelemetry設定に対応したと発表しました。
• 送信対象はトレース・メトリクス・イベントの3種類で、プロンプト・応答・ツール引数は既定で含まれません。
• 有効化はenterpriseのmanaged-settings.jsonのtelemetryプロパティで行い、送信先はOTLP対応のバックエンドが必要です。

GitHubは2026年9月22日、GitHub Copilotアプリがenterprise-managed settings経由でOpenTelemetry(OTel)の設定に対応したと公式Changelogで発表しました。OpenTelemetryはオープンソースの可観測性フレームワークで、管理者はCopilotのエージェント活動データを自社が使っている対応監視ツールへ送れるようになります。

これまでAIコーディングエージェントの実行内容は、基本的に開発者個人の手元で完結していました。今回の対応は、その実行過程を組織側の監視基盤から読めるようにするものです。

送られるのはトレース・メトリクス・イベントの3種類

エクスポートされるデータは3つの種別に分かれます。公式ドキュメントの定義は次のとおりです。

• トレース: エージェントセッションの流れを示し、モデル呼び出しやツール利用といった各ステップを連結したもの
• メトリクス: 時系列のパターンを把握するための数値計測
• イベント: 特定時点で起きた個別のアクションの記録

GitHubが用途として挙げているのは3点です。1つ目はエージェントセッションの追跡で、AIモデルへのリクエストとエージェントが使ったツールを流れとして追えます。2つ目は想定外の挙動の調査で、エージェント実行のステップごとのトレースを既存の監視ツール上で確認できます。3つ目はテレメトリ設定の一元管理で、開発者一人ひとりに設定させる代わりに、チーム横断で同じ設定を適用できます。

送信先はOpenTelemetry Protocol(OTLP)に対応したバックエンドである必要があります。ドキュメントではGrafanaが例として参照されています。OTLPのHTTP方式とgRPC方式のどちらに対応するかについては、ドキュメント上に明示がなく不明です。対応プランやエディションの明示も、現時点のドキュメントには見当たりません。

プロンプトと応答は既定で送られない

既定の設定では、送信データにプロンプト・応答・ツール引数は含まれません。この3つは任意で取得を有効化できますが、ドキュメントはコードやファイル内容、ユーザーのプロンプトといった機微な情報を含みうると明記しています。Changelogも、有効化の前にコンテンツ取得の設定を確認するよう促しています。

設定手順は管理者側で完結します。enterpriseのmanaged-settings.jsonにあるtelemetryプロパティでエクスポートを有効化し、データを受け取るエンドポイントを指定します。設定項目としてはエンドポイント、ヘッダー、認証トークンが必要です。

編集部の見方

編集部は、この更新で実務に効くのは監視機能そのものより、設定を管理者側で一括して固定できる点だと見ます。

• 根拠1: 有効化の入口がenterpriseのmanaged-settings.jsonに置かれているため、開発者ごとの設定漏れや設定差が原理的に起きにくくなります。AIエージェントの利用実態を把握したい組織にとって、取得の抜けが出ない構造は監視機能の有無より重要です。
• 根拠2: プロンプト・応答・ツール引数を既定で除外する設計は、エージェント監視の導入で最も反発が出やすい「コードや入力内容が外部に出るのではないか」という懸念を、既定値の側で下げています。取得するかどうかを組織が明示的に選ぶ形になっています。
• 根拠3: 送信先がOTLP対応バックエンドであるため、監視のために新しい製品を導入する必要がありません。すでに社内で動いている監視基盤にそのまま合流させられます。

この見方が変わる条件は、対応プランの扱いです。現時点のドキュメントには対応プラン・エディションの明示がなく、適用範囲が限定的だった場合、「組織全体の実態把握」という利点は一部の契約形態に閉じます。

よくある質問

Q: 開発者が書いたプロンプトの中身も監視ツールに送られますか?

A: 既定では送られません。プロンプト・応答・ツール引数は既定で除外対象です。任意で取得を有効化することはできますが、その場合はコードやファイル内容を含みうるとドキュメントが注意を促しています。

Q: 送信先にはどんな監視サービスを使えますか?

A: OpenTelemetry Protocol(OTLP)に対応したバックエンドが必要です。公式ドキュメントではGrafanaが例として参照されています。

Q: 個々の開発者が自分で設定する必要はありますか?

A: 今回の対応はenterprise-managed settings経由です。管理者がmanaged-settings.jsonのtelemetryプロパティで設定し、チーム横断で適用します。

まとめ

GitHubは2026年9月22日、GitHub CopilotアプリのOpenTelemetry対応を発表しました。トレース・メトリクス・イベントの3種類を管理者指定のOTLP対応バックエンドへ送信でき、プロンプト・応答・ツール引数は既定で除外されます。AIコーディングエージェントの実行過程が、組織の既存の監視基盤から読める対象になったことになります。対応プランの範囲は現時点のドキュメントでは不明です。

【用語解説】

• オブザーバビリティ: システムの外から取れる記録だけで、内部で何が起きているかを説明できる状態のこと。障害が起きてから調べるのではなく、常時記録を出しておく考え方。
• OTLP【オーティーエルピー】: OpenTelemetry Protocolの略。記録を送る側と受け取る側の間で使う共通の通信仕様で、これに対応したツールであれば送信先として選べる。
• managed-settings.json: 組織の管理者がCopilotの設定を一括で指定するための設定ファイル。個々の開発者の環境ではなく、enterprise側で管理される。

引用元:

• [1] OpenTelemetry in the GitHub Copilot app(GitHub Changelog)
• [2] OpenTelemetry for agent monitoring(GitHub Docs)
• [3] Get started with managed settings(GitHub Docs)

この記事について: AI 支援で執筆、編集部が事実確認・編集しています。誤りや追加情報があれば Contact よりお知らせください。