GitHub Copilotのチャット保存が28日からアカウント存続中へ　統合前に見直す安全運用

この記事で分かるのは、GitHub Copilotのチャットとクラウドエージェントが統合される前に、企業や開発チームが何を決め、何を確認すべきかです。結論から言えば、今回の変更は単なる画面統合ではありません。Web上のCopilot Chatへ入力した内容が従来の28日ではなく、アカウントが存続する期間にわたって保持される予定であるため、チャットを「一時的な相談欄」ではなく「長期保存され得る業務記録」として扱う必要があります。

特に重要なのは、管理者が機能を有効にするかどうかだけを決めて終わらせないことです。入力可能な情報、利用可能なリポジトリ、セッションを見られる人、退職・異動時の扱い、削除できない記録への対応までを一つの運用として設計しなければなりません。

何が変わるのか

GitHubは2026年8月28日、Copilot Chat on GitHub.com、GitHub MobileのCopilot Chat、Copilot cloud agentを、2026年9月28日より前ではない時期に、単一のCopilot体験とポリシーへ統合すると発表しました。GitHubの変更予告で確認できる主な変更は次の通りです。

確認項目	発表された変更	安全運用への影響
機能とポリシー	Web、モバイル、クラウドエージェントの個別ポリシーを単一ポリシーへ統合	従来チャットだけを許可していた組織でも、統合後の権限範囲を再確認する必要がある
既定値	統合されたCopilot体験は公開後に既定で有効	何も操作しないことが現状維持になるとは限らない
実行方式	クラウドエージェントはSandboxを利用する予定	会話だけでなく、リポジトリを扱う実行型の機能として評価する必要がある
チャット保持	GitHub.com上のチャットデータは28日ではなくアカウント存続期間に保持	プロンプトや回答に含める情報の基準を見直す必要がある
無効化した場合	統合機能をオプトアウトすると、公開後はGitHub.comとモバイルのCopilotも利用できなくなる	チャットだけ残してクラウド実行だけ止めるという従来の想定が通用しない可能性がある

ここで注意したいのは、「9月28日に必ず全利用者へ一斉適用される」と発表されたわけではない点です。公式表現は「9月28日より前ではない」です。実際の提供日、段階展開の有無、管理画面の最終的な名称は、適用時点の案内で再確認する必要があります。

一方、管理者には9月28日までにポリシーを確認するよう明示的に案内されています。予定日が確定してから検討を始めるのではなく、現在の設定と利用実態を先に棚卸ししておくべき変更です。

なぜ「長く保存される」だけでリスクが変わるのか

保持期間が長くなっても、Copilotの回答精度が下がるわけではありません。変わるのは、入力ミスが後から消えるという期待を持てる範囲です。

開発者はチャットへ、エラー全文、設定ファイル、顧客から受け取った再現データ、障害調査中のログ、未公開機能の仕様などを貼り付けがちです。短時間の問題解決では便利でも、その会話がアカウント存続中の記録になるなら、次の問いを先に考えなければなりません。

その情報をGitHub上へ保存する権限が利用者にあるか
リポジトリの共同作業者に見られても問題ないか
顧客との契約や社内規程で保存先が制限されていないか
秘密情報をマスクせず入力していないか
数年後に残っていても説明できる内容か
アカウント停止や契約終了を削除手段として当てにしてよいか

保持期間は「データを学習に使うか」とは別の論点です。学習利用の有無だけを確認して安全と判断してはいけません。学習に使われなくても、サービス上に長く残り、検索、監査、共有、サポート対応などの対象になるなら、情報管理上の判断は必要です。

確認済みの事実と、まだ推測してはいけないこと

今回のような提供前の変更では、公式発表、現行ドキュメント、編集部の判断を混ぜないことが大切です。

公式情報で確認できたこと

統合は2026年9月28日より前には実施されない予定である
統合されたCopilot体験は公開後に既定で有効になる予定である
GitHub.com上のチャットデータは、28日ではなくアカウント存続期間に保持される予定である
BusinessおよびEnterpriseの管理者には、9月28日までのポリシー確認が求められている
現行のクラウドエージェントでは、停止したセッションをアーカイブできるが削除はできない
現行のクラウドエージェントのセッションは、リポジトリのAgents画面において、そのリポジトリへアクセスできる人に表示される
組織では、クラウドエージェントを許可するリポジトリを選択できる

現行セッションの停止、アーカイブ、共有、履歴検索についてはセッション管理の公式ドキュメントで確認できます。

現時点で断定しないこと

統合後の通常チャットに、現行クラウドエージェントの「アーカイブは可能だが削除不可」という制約が、どの範囲まで同じ形で適用されるかは、今回確認した変更予告だけでは確定できません。GitHub.com上のチャットがエージェントセッション体験へ移行することは発表されていますが、セッションの種類ごとの削除操作や管理者向け消去手続きの最終仕様は、展開後のドキュメントで確認する必要があります。

また、「アカウント存続期間」という表現から、退職者のアカウントを無効化すれば即座に全チャットが消える、と推測してはいけません。アカウント無効化、ライセンス解除、組織からの削除、アカウント削除は同じ操作ではありません。法令対応やバックアップを含む消去時期についても、この変更予告だけでは判断できません。

管理者が9月28日までに行う7つの確認

1. 現在のポリシーを記録する

まず、現在のCopilotポリシー画面を確認し、Webチャット、モバイル、クラウドエージェントがそれぞれ許可、禁止、委任のどの状態かを記録します。画面のスクリーンショットだけでなく、確認日、確認者、対象となるEnterpriseとOrganizationも残します。

組織管理者向けの操作経路はCopilotポリシー管理の公式手順で確認できます。ただし、Enterprise側で設定が固定されている場合、Organization側では上書きできません。「自分の組織画面では無効だった」という確認だけでは不十分です。

2. 統合後の希望状態を言葉で決める

管理画面を触る前に、希望する状態を文章にします。例えば次のように定義します。

GitHub.com上のCopilotは検証用Organizationだけで許可する
本番コードを持つリポジトリではクラウドエージェントを許可しない
長期保存できない顧客データはプロンプトへ入力しない
利用者はダミーデータ、公開情報、リポジトリ内で利用を許可された情報だけを使う
セッションから生成された変更はPull Requestで人が承認する

「便利そうなら有効」のような方針では、設定変更後に正否を判定できません。誰が、どこで、何を入力し、何を実行できる状態を許すのかまで書く必要があります。

3. リポジトリを情報区分で分ける

クラウドエージェントを許可すると、アクセス可能な全リポジトリへ一律に安全になるわけではありません。現行の公式手順では、クラウドエージェントを利用できるリポジトリを限定できます。クラウドエージェントの組織設定によれば、機能を許可された利用者が対象リポジトリへの書き込み権限を持つと、エージェントへ作業を委任できます。

最初の許可対象には、次の条件を満たす検証用リポジトリが向いています。

顧客データ、個人情報、認証情報を含まない
本番環境へ直接デプロイされない
ブランチ保護とPull Requestレビューが有効
テストを自動実行できる
外部システムへ接続する秘密情報が登録されていない
問題が起きても削除や作り直しができる

逆に、秘密管理、決済、医療、採用、法務案件などを扱うリポジトリを、最初から一括許可するべきではありません。

4. 入力禁止情報を具体例で示す

「機密情報を入力しない」だけでは、人によって判断が変わります。少なくとも以下を例示します。

APIキー、アクセストークン、秘密鍵、Cookie、接続文字列
本番ログに含まれるメールアドレス、IPアドレス、顧客ID
公開前の脆弱性情報や侵入調査の証拠
顧客から秘密保持契約の下で受領したコードや文書
人事評価、健康情報、本人確認書類
契約上、指定環境外への保存が禁止されたデータ

エラーの相談では、秘密値を伏せ、個人識別子を架空値へ置き換え、問題を再現する最小限のコードだけを入力します。伏せ字にしても文脈から本人や顧客を特定できる場合があるため、単純な名前削除だけで匿名化できたとは判断しません。

5. 「アーカイブ」と「削除」を分ける

アーカイブは一覧から見えにくくする整理操作であり、データの消去とは限りません。現行ドキュメントは、クラウドエージェントのセッションについて、アーカイブできても削除できないと説明しています。

したがって、誤って秘密情報を入力した後の対応を「後でセッションを消す」に依存させてはいけません。事故時は、秘密情報の失効、認証情報のローテーション、関係部署への報告、アクセス状況の確認を優先します。APIキーを貼り付けた場合、画面から見えなくするだけでは対策になりません。

6. 閲覧範囲をテストする

現行のクラウドエージェントセッションは既定で共有され、対象リポジトリへアクセスできる人がAgents画面から確認できると説明されています。一方、ローカルセッションは既定で非共有です。この違いを知らずに、個人的な下書きのつもりでクラウドセッションを使うと、想定外の共同作業者へプロンプトや回答、変更内容が見える可能性があります。

検証用リポジトリと架空データを使い、少なくとも次のアカウントで見え方を確認します。

セッションを開始した利用者
同じリポジトリの書き込み権限者
読み取り権限だけを持つ利用者
リポジトリへアクセスできない組織メンバー
Organization管理者

この確認は、統合前と統合後の両方で実施します。画面に表示されないことと、データが保存されていないことも区別してください。

7. 変更後に監査する

CopilotのポリシーはEnterpriseとOrganizationで階層的に適用され、複数のライセンスや設定が関係すると、利用者が想定より緩い設定を受ける場合があります。EnterpriseとOrganizationのポリシー解説では、同じEnterprise内の複数Organizationから異なる設定を受けた利用者には、通常、より制限の少ない設定が適用されると説明されています。ただし例外もあるため、設定表だけでなく実際の利用者単位で確認します。

Enterpriseの監査ログでは、Copilotの設定・ポリシー・ライセンス変更や、GitHub Web上でのエージェント活動を確認できます。監査ログの公式手順によれば、通常の監査ログ保持は180日です。長期監査が必要な組織は、必要性と契約条件を確認したうえで外部の監視基盤へストリーミングする設計を検討します。

ただし、この監査ログにはローカルでCopilotへ送ったプロンプトなど、クライアントのセッションデータは含まれません。「監査ログを保存しているから全Copilot利用を再現できる」という理解は誤りです。

統合後に実施する安全確認テスト

公開後すぐに全社有効化せず、検証用Organizationまたは限定チームで次のテストを行います。入力には架空情報だけを使います。

現在の公式変更履歴とドキュメントを再確認し、実際の提供日を記録する
EnterpriseとOrganizationの統合ポリシー状態を確認する
許可した検証用リポジトリでだけセッションを開始できることを確かめる
禁止したリポジトリでは開始できないことを確かめる
Webチャット、モバイル、クラウドエージェントの利用可否を別々に試す
プロンプト、回答、ファイル変更、セッションログを誰が見られるか確認する
停止、アーカイブ、共有解除、削除に相当する操作の有無を確認する
ライセンス解除後にも誰が履歴へアクセスできるか、ダミーアカウントで確認する
ポリシー変更とエージェント活動が監査ログへどのように記録されるか確認する
テスト結果を管理者、セキュリティ担当、開発責任者が承認してから対象を拡大する

ライセンス解除やアカウント削除を試す場合は、本番利用者ではなく、削除してよい検証専用アカウントを使います。アカウント操作が契約、請求、監査記録へ与える影響もあるため、安易に本番環境で再現テストを行わないでください。

よくある失敗

何もしなければ現在の状態が維持されると思う

今回は統合機能が既定で有効になる予定です。「設定を変えない」は中立な選択ではありません。変更前の個別ポリシーが、統合後にどの値へ移行するかを確認する必要があります。

保持期間だけを社内通知する

「履歴が長く残ります」と伝えるだけでは、利用者は何を変えればよいか分かりません。禁止データ、許可された用途、相談窓口、誤入力時の連絡手順までセットで周知します。

アーカイブを消去だと思う

一覧から消えたように見えても、保存データが削除されたとは限りません。誤入力への対策は、事後削除よりも入力前のマスキングと秘密情報の即時失効を中心に設計します。

Organization設定だけを見る

Enterpriseで固定されたポリシーはOrganizationで上書きできない場合があります。また、複数Organizationからライセンスを受ける利用者ではポリシー競合が起こり得ます。設定の所有者と適用対象を一緒に確認してください。

Sandboxという名称だけで安全と判断する

Sandboxは実行環境の隔離に関する仕組みであり、チャットへ入力した情報の保存期間、リポジトリの閲覧権限、外部接続、生成された変更の正しさを自動的に保証する言葉ではありません。許可リポジトリ、ネットワーク、秘密情報、人によるレビューは別々に管理する必要があります。

この運用が適さない条件

次の状況では、統合Copilotを有効にする前に、法務、情報セキュリティ、顧客担当者を含む個別審査を行うべきです。

契約で生成AIや外部クラウドへの入力が禁止されている
データの保存地域や消去期限について法的・業界上の要件がある
セッションを案件終了時に確実に消去する必要がある
開発者の書き込み権限が広く、リポジトリを安全区分で分けられていない
エージェントが作った変更を人がレビューできない
秘密情報がログや設定ファイルへ平文で混入している
監査ログの担当者と事故時の連絡経路が決まっていない

この場合は、機能を一時的に無効とし、入力データを限定した別環境で検証する方が安全です。利便性を失うことと、管理できない状態で長期保存を始めることを比較して判断します。

導入判断チェックリスト

安全運用の要点

今回の変更で最も重要なのは、Copilot Chatを「消えていく短期会話」と見なさないことです。保存期間がアカウント存続期間へ延びるなら、プロンプトはコードレビューのコメントやIssueと同じように、後から残っても説明できる業務記録として扱う必要があります。

管理者は、機能のオン・オフだけでなく、データ区分、リポジトリ範囲、共有、削除、監査をつないで判断してください。利用者側は、秘密情報や顧客データを貼り付けてから消すのではなく、入力前に最小化し、架空値へ置き換えることが基本です。

本記事の確認日は2026年9月9日です。主要な一次情報は、2026年8月28日のGitHub変更予告、Copilotのポリシー管理、クラウドエージェント設定、セッション管理、監査ログに関するGitHub公式ドキュメントです。統合は確認日時点で将来の予定であるため、実際の展開後には、提供日、既定値、セッション削除の可否、共有範囲を公式情報と検証用環境で再確認してください。

PRIMARY SOURCES