GitHub の「Copilot agent session streaming is now in public preview」は、GitHub Copilot のエージェント利用状況を企業が監査・分析しやすくするための更新です。開発者に新しい操作画面が増えるというより、Enterprise 管理者が Copilot のエージェントセッションに関するデータをストリーミングまたは REST API で取得できるようになる点が重要です。特に、プロンプト、応答、ツール呼び出しといったセッション情報を扱うため、導入時は「誰が見られるのか」「どこに保存するのか」「開発者へどう周知するのか」を先に決めておく必要があります。GitHub はこの機能を 2026年7月2日に Public Preview として発表しており、対象は主に Enterprise Managed Users を利用する GitHub Enterprise Cloud の企業です。(The GitHub Blog)
GitHub の新機能・変更点：「Copilot agent session streaming is now in public preview」で確認すべきポイント
今回の更新で押さえるべき結論は、GitHub Copilot のエージェント利用を、企業の監査ログや SIEM、データ管理基盤に接続しやすくなったという点です。
これまで GitHub Copilot の導入では、「何人が使っているか」「どの機能が使われているか」といった利用メトリクスに注目しがちでした。今回の Copilot agent session streaming は、さらに一歩踏み込み、エージェントセッションの活動内容を企業側で確認・保管・分析できるようにするものです。GitHub の公式発表では、対象データとして prompts、responses、tool calls が例示されています。(The GitHub Blog)
ただし、これはすべての GitHub ユーザーがすぐ使える個人向け機能ではありません。公式情報では、GitHub Enterprise Cloud の Enterprise Managed Users、または GitHub Enterprise Cloud with data residency を利用する企業向けの Public Preview とされています。REST API についても、アクセスできるのは EMU の Enterprise owner と説明されています。(GitHub Docs)
何が新しくなったのか
今回の更新では、GitHub Copilot のエージェントセッションデータを、次の2つの方法で取得できるようになりました。
| 取得方法 | 向いている用途 | 実務での使いどころ |
|---|---|---|
| Streaming endpoint | 継続的な監査、SIEM 連携、長期保管 | Splunk、Datadog、Azure Event Hubs、Microsoft Purview などに流して監査基盤に集約する |
| REST API | 必要なタイミングでの確認、調査、軽量な分析 | 直近のセッションデータを取得し、特定ユーザーや期間で調査する |
GitHub の公式 Changelog では、ストリーミングエンドポイントと REST API の両方が案内されています。REST API では GET /enterprises/{enterprise}/copilot/usage-records が用意され、Enterprise owner がオンデマンドでセッションデータを取得できます。公式発表では「last 48 hours of session data」と説明されています。(The GitHub Blog)
対象になる Copilot クライアント
対象は GitHub.com 上の cloud agents だけではありません。公式情報では、次のような Copilot クライアントが対象に含まれると説明されています。(The GitHub Blog)
| 対象クライアント | 確認ポイント |
|---|---|
| GitHub.com 上の Cloud agents | GitHub 上で開始されたエージェント作業を監査対象にできる |
| ghe.com の data resident deployments | データレジデンシー環境を使う企業でも対象になる |
| GitHub Copilot CLI | ターミナル経由のエージェント利用も見落としにくくなる |
| Visual Studio Code | 現場で利用頻度の高い IDE からの利用を把握できる |
| Visual Studio | .NET やエンタープライズ開発での利用状況を確認しやすい |
| JetBrains、Eclipse などのパートナー IDE | 複数 IDE を使う組織でも統一的に監査しやすい |
実務上のポイントは、「GitHub の画面で使った Copilot だけを見る機能ではない」ということです。企業内で Copilot を複数クライアントに展開している場合、利用経路ごとに監査の抜け漏れが起きないよう、取得対象と保存先を整理しておく必要があります。
Public Preview として理解すべきこと
Copilot agent session streaming は Public Preview です。つまり、正式提供前に広く試せる段階であり、仕様や画面、API の応答形式、サポート範囲が今後変わる可能性があります。GitHub Docs でも、このエンドポイントは Public Preview であり変更される可能性があると明記されています。(GitHub Docs)
本番運用に組み込む場合は、次の前提で設計するのが安全です。
| 判断項目 | 推奨される考え方 |
|---|---|
| API スキーマ | 固定前提にせず、フィールド追加・変更に耐える実装にする |
| SIEM 連携 | パーサーやダッシュボードを柔軟に更新できる構成にする |
| 監査証跡 | Public Preview 中は、法令・社内監査の唯一の証跡にしない |
| 運用手順 | GitHub Docs の変更に追随できるよう、設定手順を定期確認する |
「Public Preview だから使わない」と決める必要はありません。むしろ、Copilot エージェントを全社展開する前に、どの程度の監査データが取れるのか、既存のセキュリティ運用にどう組み込めるのかを検証するタイミングと考えるのが現実的です。
管理者が確認すべき設定
管理者が最初に確認すべき場所は、Enterprise の AI Controls と Audit log streaming です。
公式情報では、AI Controls の Copilot サブページで「Copilot Usage Records Streaming」と「Copilot Usage Records API」を Enable everywhere に設定する流れが示されています。ストリーミングを使う場合は、Enterprise の監査ログ設定から送信先を構成します。(The GitHub Blog)
設定前に確認するチェックリスト
| 確認項目 | 理由 |
|---|---|
| Enterprise Managed Users を利用しているか | 今回の Public Preview の対象条件に関わる |
| Enterprise owner 権限を持つ担当者がいるか | 設定変更や API 利用に必要 |
| Copilot の企業向けライセンス利用範囲 | どのユーザーのセッションが取得対象になるかを把握するため |
| 送信先の SIEM・ストレージ | データ保存先、保管期間、アクセス権限を決めるため |
| 開発者への周知文 | プロンプトや応答が監査対象になる可能性を明確に伝えるため |
| 個人情報・機密情報の扱い | セッションデータに業務情報が含まれる可能性があるため |
特に見落としやすいのは、開発者への周知です。管理者が監査機能を有効化しても、利用者がその意味を理解していないと、プロンプトに秘密情報や顧客データを貼り付けるリスクが残ります。
Streaming endpoint でできること
Streaming endpoint を使うと、GitHub の監査ログ設定から任意のイベントコレクターや SIEM ツールにセッションデータを送信できます。公式情報では、GitHub が Enterprise 全体のセッションデータを自動的にストリーミングすると説明されています。(The GitHub Blog)
GitHub Docs では、監査ログストリーミングの送信先として Amazon S3、Azure Blob Storage、Azure Event Hubs、Datadog、Google Cloud Storage、Splunk などが案内されています。また、Microsoft Purview は Copilot agent session events 専用の送信先として Public Preview で利用可能と説明されています。(GitHub Docs)
Microsoft Purview 連携の意味
Microsoft Purview 連携は、Microsoft 365 や Entra ID、コンプライアンス運用を Microsoft 製品中心に組んでいる企業にとって重要です。GitHub Docs では、Microsoft Purview へのストリーミングは Copilot agent session events のみをサポートし、GitHub 側でストリーミングを構成した後、Microsoft Entra で認可する流れが示されています。(GitHub Docs)
実務では、次のような組織に向いています。
| 組織の状況 | Purview 連携を検討する理由 |
|---|---|
| Microsoft 365 E5 や Purview を既に使っている | 監査・コンプライアンス基盤を分散させずに済む |
| AI 利用の監査証跡を一元化したい | Copilot for Microsoft 365 などと合わせて AI 利用の可視化を進めやすい |
| 情報保護ポリシーを統一したい | GitHub Copilot の利用データも既存のガバナンス設計に組み込みやすい |
ただし、Purview がすべての GitHub 監査ログを受けるという意味ではありません。Docs では、Microsoft Purview は Copilot agent session events のみをサポートすると説明されているため、通常の監査ログや Git イベントの保管先とは分けて考える必要があります。(GitHub Docs)
REST API で確認できること
REST API を使うと、Enterprise の Copilot agent session activity records を取得できます。GitHub Docs では、このエンドポイントが Enterprise 内の Copilot セッションデータに対する可観測性を提供し、Enterprise-paid Copilot licenses のもとで利用された各 Copilot クライアントの詳細な usage records を返すと説明されています。(GitHub Docs)
基本のエンドポイントは次の通りです。
curl -L \
-H "Accept: application/vnd.github+json" \
-H "Authorization: Bearer <YOUR-TOKEN>" \
-H "X-GitHub-Api-Version: 2026-03-10" \
"https://api.github.com/enterprises/ENTERPRISE/copilot/usage-records"GitHub Docs では、phrase による検索、type、user_id、created などの qualifier、per_page、after、before、order といったパラメータが案内されています。per_page は最大 25 とされているため、大量データを取得する場合はページング設計が必要です。(GitHub Docs)
REST API を使うべきケース
REST API は、継続的な監査というより、調査や検証に向いています。
| 利用シーン | API が向いている理由 |
|---|---|
| 特定ユーザーの利用状況を確認したい | user_id などで絞り込みやすい |
| インシデント調査で直近のやり取りを確認したい | 必要な期間だけ取得しやすい |
| SIEM 連携前にデータ構造を把握したい | サンプル取得してパーサー設計に使える |
| 利用ルール違反の有無を確認したい | プロンプトや応答の取り扱い方針を検証できる |
一方で、API だけで長期監査を回そうとすると、取得漏れ、ページング処理、保管、再試行、アクセス制御を自前で作り込む必要があります。長期保管やリアルタイム性を重視する場合は、Streaming endpoint を優先した方が運用しやすいでしょう。
取得されるデータの中身と注意点
GitHub Docs の agentic audit log events では、ストリーミングされる Copilot API usage record のフィールド例として、type、user_id、enterprise_id、endpoint、body、@timestamp、truncated、event_id、github_request_id が示されています。body はリクエストまたはレスポンス本文を JSON エンコードした文字列で、1MB のドキュメントサイズ制限に合わせて切り詰められた場合は truncated が true になります。(GitHub Docs)
この仕様から、実務上は次の点に注意が必要です。
| 注意点 | 対策 |
|---|---|
| セッション本文に機密情報が含まれる可能性 | 開発者向けに「入力してよい情報・禁止情報」を明文化する |
body が切り詰められる可能性 | 監査時に truncated を確認し、完全な本文が常に取れる前提にしない |
| JSON 文字列のパースが必要 | SIEM 側でネスト構造や文字列エスケープに対応する |
| ユーザー単位の追跡が可能 | 閲覧権限を最小化し、監査目的以外の利用を禁止する |
| Public Preview 中に仕様が変わる可能性 | スキーマ変更を前提にパーサーを保守する |
特に body の扱いは慎重に設計すべきです。プロンプトや応答には、ソースコード、設計情報、顧客名、障害内容、内部 URL などが含まれる可能性があります。取得できるようになったからといって、誰でも見られる場所に保存してよいわけではありません。
開発者・一般ユーザーへの影響
開発者や一般ユーザーにとって、今回の変更は「Copilot の使い方が大きく変わる」ものではありません。重要なのは、Enterprise 環境では Copilot エージェントの利用状況が管理者側で監査・分析される可能性が高まることです。
たとえば、次のような使い方は避けるべきです。
| 避けたい使い方 | 理由 |
|---|---|
| API キーやトークンをプロンプトに貼る | セッションデータとして記録・保存される可能性がある |
| 顧客情報をそのまま入力する | 個人情報・契約情報の取り扱いリスクがある |
| 未公開の障害情報を詳細に入力する | インシデント情報の共有範囲を超える可能性がある |
| 社外秘の設計資料を丸ごと貼る | 監査ログ側にも機密情報が残る可能性がある |
| 会社の許可なく個人アカウントで作業する | Enterprise 管理下の監査・ポリシーから外れる可能性がある |
管理者は、開発者に対して「監視されているから使わないでください」と伝えるのではなく、安全に使うためのルールを具体化することが大切です。たとえば、「秘密情報は貼らない」「再現コードは匿名化する」「顧客名はプロジェクト ID に置き換える」「ログを入力する前にトークンやメールアドレスをマスクする」といった実践的なルールが有効です。
管理者が作るべき運用ルール
Copilot agent session streaming を有効化する前に、少なくとも次の運用ルールを決めておくべきです。
| ルール | 決める内容 |
|---|---|
| データ保管期間 | SIEM やストレージに何日・何年保存するか |
| 閲覧権限 | Security、Compliance、Platform 管理者など、誰が見られるか |
| 調査フロー | どの条件でセッションデータを確認するか |
| 開発者通知 | 監査対象になる情報と禁止入力をどう伝えるか |
| 例外対応 | 誤って機密情報を入力した場合の削除・報告手順 |
| 監査証跡の二次利用 | 人事評価や個人監視に使わないなど、目的外利用を防ぐ方針 |
この機能は、セキュリティチームだけで完結させるより、開発組織、法務、情報システム、コンプライアンス部門を巻き込んで設計した方が失敗しにくくなります。特に日本企業では、従業員の利用ログや会話データの扱いについて、社内規程や労務面の説明が必要になることがあります。
実務で役立つ活用シーン
Copilot agent session streaming は、単なるログ収集ではなく、AI 開発支援を安全に拡大するための基盤として使えます。
インシデント調査
疑わしい Copilot エージェント利用があった場合、どのユーザーが、どのクライアントから、どのようなセッションを開始したのかを確認しやすくなります。GitHub の agentic audit log events では、actor:Copilot フィルターを使って Enterprise audit log 上の agentic activity を確認できると説明されています。(GitHub Docs)
たとえば、意図しない Pull Request 作成、外部ツール呼び出し、想定外のリポジトリ操作が発生した場合に、該当する agent_session_id や github_request_id を手がかりに調査できます。
AI ガバナンスの強化
全社で GitHub Copilot を導入すると、「便利だから使う」段階から「安全に使い続ける」段階へ移ります。Copilot agent session streaming を SIEM やデータ管理基盤に接続すれば、ポリシー違反の傾向、特定組織での利用集中、禁止情報の入力リスクなどを継続的に把握しやすくなります。
開発者教育の改善
監査データは、開発者を責めるためではなく、教育材料として使う方が効果的です。たとえば、プロンプトに秘密情報を含めがちなチームがあれば、ガイドラインを更新し、プロンプト例を改善できます。
「Copilot に聞いてはいけないこと」を抽象的に並べるより、「本番ログを貼る前にトークンを削除する」「顧客名を仮名にする」「社外秘の設計書は要約してから使う」といった具体例を提示する方が、現場に定着します。
よくある誤解
Copilot の回答速度が速くなる機能ではない
「session streaming」という名前から、Copilot の応答がストリーミング表示される機能だと誤解されるかもしれません。しかし、今回の更新はユーザー体験の表示改善ではなく、Enterprise 管理者向けのセッションデータ取得・監査機能です。
すべての GitHub ユーザーが使えるわけではない
公式情報で対象として示されているのは、Enterprise Managed Users を利用する GitHub Enterprise Cloud の顧客です。REST API も EMU の Enterprise owner が対象と説明されています。個人アカウントや小規模チームが同じように有効化できる機能として扱わない方が安全です。(GitHub Docs)
ログは必ず1回だけ届くとは限らない
GitHub Docs では、監査ログストリーミングについて at-least-once delivery method を使用すると説明されています。ネットワークやシステムの問題により、イベントが重複する可能性があります。(GitHub Docs)
そのため、SIEM やデータウェアハウス側では event_id や github_request_id などを使い、重複排除を前提に集計する必要があります。
設定後も監視が必要
監査ログストリームにはヘルスチェックがあります。GitHub Docs では、各ストリームに対して24時間ごとにヘルスチェックが実行され、設定ミスがある場合は Enterprise owner にメール通知されると説明されています。また、イベントの取りこぼしを避けるには、誤設定を6日以内に修正する必要があります。(GitHub Docs)
設定して終わりではなく、通知先、障害時の対応担当、復旧手順まで決めておくことが重要です。
導入時のおすすめ手順
Copilot agent session streaming を本番環境に入れる場合は、次の順序で進めると安全です。
| 手順 | 実施内容 | 目的 |
|---|---|---|
| 1 | 対象 Enterprise と EMU 利用状況を確認する | 機能の対象条件を満たしているか確認する |
| 2 | 取得するデータと利用目的を定義する | 監査、セキュリティ、コンプライアンスなど目的を明確にする |
| 3 | 保存先を決める | SIEM、ストレージ、Purview などを選定する |
| 4 | AI Controls で Streaming/API を有効化する | GitHub 側でデータ取得を許可する |
| 5 | 監査ログストリーミングを設定する | 外部基盤へデータを送る |
| 6 | サンプルデータを確認する | フィールド、文字化け、欠損、重複を確認する |
| 7 | アラートとダッシュボードを作る | 異常検知や利用状況把握に使う |
| 8 | 開発者向けルールを周知する | 機密情報入力や目的外利用を防ぐ |
| 9 | 定期レビューを行う | Public Preview の仕様変更や運用課題に対応する |
最初から全社の監査ダッシュボードを作り込むより、まずはサンプルデータを取得し、どの情報が含まれるかを確認するのがおすすめです。その上で、機密情報の扱い、保存期間、閲覧権限を固めると、後から大きな手戻りが起きにくくなります。
セキュリティ担当者が見るべき観点
セキュリティ担当者は、単に「ログが取れるか」ではなく、次の観点で評価すると実務に落とし込みやすくなります。
| 観点 | 確認内容 |
|---|---|
| データ分類 | セッション本文を機密データとして扱うか |
| アクセス制御 | ログ閲覧者を最小限にできているか |
| DLP | 秘密情報や個人情報の検知ルールを適用できるか |
| インシデント対応 | agent_session_id から関連イベントを追跡できるか |
| 保管・削除 | 社内規程や契約に沿った保持期間になっているか |
| 監査対応 | 監査証跡として使う場合の限界を明記しているか |
AI 利用ログは、従来のアクセスログよりも文脈情報を多く含みます。便利な一方で、保存先の権限設計を誤ると、ログ基盤そのものが機密情報の集積場所になります。
開発組織が今すぐ見直すべきこと
開発組織では、Copilot エージェントを使う前提で、プロンプト作成ルールを見直すべきです。
たとえば、次のようなルールをチームの README や開発者ポータルに明記します。
| ルール例 | 実践例 |
|---|---|
| 秘密情報を入力しない | API キー、SSH 鍵、トークン、Cookie は削除してから相談する |
| 顧客情報を匿名化する | 会社名や個人名を Customer A のように置き換える |
| 本番ログをマスクする | メールアドレス、IP アドレス、セッション ID を伏せる |
| 社外秘資料は要約する | 原文を貼らず、必要な制約条件だけを書く |
| Copilot の出力をレビューする | 自動生成されたコードや PR を人間が確認する |
Copilot agent session streaming は管理者向け機能ですが、実際のリスクを下げるのは現場の入力ルールです。ログで検知するだけではなく、入力段階で危険な情報を減らす運用が重要です。
まとめ：まずは監査目的と保存先を決める
GitHub の「Copilot agent session streaming is now in public preview」は、GitHub Copilot のエージェント利用を企業がより細かく把握するための重要な更新です。特に、プロンプト、応答、ツール呼び出しを含むセッションデータを Streaming endpoint または REST API で扱えるようになる点は、AI ガバナンスやセキュリティ監査に直結します。(The GitHub Blog)
管理者は、まず対象条件、Enterprise owner 権限、AI Controls の設定、送信先、保存期間、閲覧権限を確認してください。開発者には、Copilot の使い方そのものよりも、入力する情報の扱い方を具体的に周知することが大切です。
Public Preview の段階では、仕様変更を前提に小さく検証し、データ構造、SIEM 連携、重複排除、機密情報対策を確認するのが現実的です。GitHub Copilot を全社展開している、またはこれから本格導入する企業は、今回の更新を「AI 利用を監視する機能」ではなく、AI を安全に業務へ組み込むための管理基盤として捉えるとよいでしょう。
コメント