GitHub Copilot appがOpenTelemetryに対応し、AIエージェントの実行を既存の監視基盤で追えるようになりました。2026年9月22日のGitHub公式発表では、enterprise-managed settingsからOTel設定を配布し、モデル呼び出しやツール利用を含むエージェントセッションの流れを分析できると説明されています。対象はGitHub Copilot appを中心に、管理者がAI codingの品質・コスト・事故調査を同じ運用画面へ寄せたい企業です。
概要：AIエージェント監視が必要になる理由
これまでのCopilot導入では、利用量や席数は追えても、1つのエージェントセッションで何が起きたかを後から説明しにくい場面がありました。OpenTelemetry対応により、管理者はエージェントがどのモデルを呼び、どのツールを使い、どのステップで時間やトークンを消費したかをトレースとして扱えます。障害調査、利用定着、セキュリティレビューを分けずに見られる点が実務上の変化です。
ただし、これは会話内容をすべて収集する機能ではありません。GitHub Docsでは、既定ではプロンプト、応答、ツール引数は含まれないと説明されています。内容キャプチャを有効にする場合は、コードやファイル内容、ユーザープロンプトなどの機微情報が含まれる可能性があるため、先にデータ分類と保存期間を決めるべきです。
仕様表：確認すべき3種類のデータ
GitHub Docsで示されているデータは、traces、metrics、eventsの3種類です。導入判断では、それぞれを「事故調査」「継続改善」「利用定着」のどれに使うかを分けると設計しやすくなります。
- Traces：エージェントセッションの流れを追うデータ。モデル呼び出し、readFileのようなツール利用、次のモデル呼び出しまでのつながりを確認する用途。
- Metrics：入力・出力トークン数など、時間軸で傾向を見る数値。部門別の利用量、急増検知、PoC後の費用説明に使いやすい。
- Events：編集提案を受け入れたか拒否したかなど、個別アクションを記録するデータ。定着率や教育ポイントの把握に向く。
この3種類を最初から全部ダッシュボード化する必要はありません。まずは30日間、tracesで失敗セッションを追い、metricsでトークン利用の週次推移を確認し、eventsで受け入れ率を見る程度から始めるのが現実的です。
設定方法：managed-settings.jsonで配布する
GitHubの発表では、enterprise-managed settingsのtelemetryプロパティでOTelエクスポートを有効化し、送信先エンドポイントを指定すると説明されています。GitHub Docsのmanaged settingsガイドでは、.github-privateリポジトリにcopilot/managed-settings.jsonを置き、企業全体へ設定を配布する流れが紹介されています。
- 1. OTLP対応の監視基盤を決める。直接受けられない場合はOpenTelemetry Collectorを間に置く。
- 2. .github-privateリポジトリにcopilot/managed-settings.jsonを用意し、telemetry設定を管理者レビュー付きで変更する。
- 3. 重要チームだけ先行適用し、1時間程度の反映時間やクライアント再起動後の挙動を確認する。
- 4. prompt/response/content captureを有効にするかは別審査にし、既定では本文を取らない設計から始める。
中盤チェックリスト：PoCで見る8項目
AIエージェント監視のPoCは、接続確認だけで終わらせると効果が見えません。30日間で以下の8項目を確認すると、導入可否を説明しやすくなります。
- セッション単位でモデル呼び出しとツール利用の順序を追えるか。
- トークン利用量を部門、チーム、期間で集計できるか。
- 失敗・中断・長時間化したセッションを抽出できるか。
- 既存のSplunk、Grafana、Datadogなどの監視運用に乗せられるか。
- プロンプトやコード本文を取らなくても、最低限の調査に足りるか。
- 内容キャプチャを有効にする場合の承認者、保存期間、削除手順が明確か。
- 開発者に過度な手作業設定を求めず、managed settingsで統制できるか。
- PoC後に、利用拡大・制限・追加教育のどれを判断するかが決まっているか。
リスク：取らないデータを先に決める
OpenTelemetry対応は、AIエージェントをブラックボックスのまま運用しないための強い選択肢です。一方で、監視を強めるほどプライバシー、ソースコード、顧客データの取り扱いが論点になります。特に内容キャプチャは便利ですが、機微情報が入る可能性があるため、初期設定では無効のまま始め、例外的に有効化する条件を明文化するのが安全です。
おすすめは、データを3段階に分けることです。第1段階はメタデータのみ、第2段階は障害調査時だけ詳細化、第3段階は責任者承認がある場合だけ内容キャプチャを検討します。
FAQ
Q. OpenTelemetryを入れるとプロンプトやコードが必ず送信されますか？ A. いいえ。GitHub Docsでは、既定ではプロンプト、応答、ツール引数は含まれないと説明されています。ただし、内容キャプチャを選ぶ場合は機微情報が含まれる可能性があるため、事前審査が必要です。
Q. どの企業に向いていますか？ A. Copilot appやエージェント利用が複数チームに広がり、失敗調査、トークン利用、導入効果を説明する必要が出てきた企業に向いています。小規模チームなら、まず1チームPoCで十分です。
Q. 既存の監視ツールは使えますか？ A. OTLPに対応するバックエンド、またはOpenTelemetry Collector経由で接続できる監視基盤を使う設計になります。GitHub Docsでも、対応バックエンドやCollectorを使う流れが示されています。
まとめ：監視は「利用制限」ではなく改善ループに使う
Copilot appのOpenTelemetry対応で重要なのは、AIエージェントを止めるための監視ではなく、失敗を説明し、良い使い方を増やす改善ループを作れる点です。traces、metrics、eventsの3種類を分けて見れば、管理者は事故調査、費用説明、教育施策を同じデータ基盤で扱えます。
まずは30日間、1チーム・1監視基盤・8項目チェックリストで始めるのが現実的です。内容キャプチャは急がず、既定のメタデータ中心で価値を確認してから、必要な範囲だけ広げる設計にしてください。
GitHub Copilotの管理設定、AIエージェント監視、社内展開ルールをまとめて設計したい場合は、HelloCraftAIにご相談ください。
