GitHub Copilotの9月28日変更は、単なるUI更新ではありません。Copilot Chat、GitHub Mobile、Copilot cloud agentの扱いが1つの体験とポリシーに寄り、code reviewの既定もLiteからBalancedへ変わります。管理者が当日確認すべき論点は、アクセス権限、データ保持、AI credits、GitHub Actions minutes、請求サイクルの5つです。
この記事では、GitHub公式ChangelogとGitHub Docsをもとに、2026年9月28日以降にCopilot Business/Enterprise管理者が確認すべきポイントを整理します。対象は、GitHub Copilotを開発組織で運用している情シス、Engineering Manager、AI coding導入担当者です。
9月28日変更の要点：5つだけ先に確認
今回の変更は3つに分けると理解しやすいです。1つ目は、Copilot Chat on github.com、GitHub Mobile、Copilot cloud agentが単一のCopilot体験とポリシーに寄ること。2つ目は、Copilot code reviewのDefaultがBalanced effortとして扱われること。3つ目は、クレジットカードまたはPayPal払いのBusiness/Enterpriseで、座席課金と追加利用の支払い体験が変わることです。
- 単一ポリシー化：GitHub.com、Mobile、cloud agentのアクセス判断を一箇所で確認する
- 既定有効：統合体験はローンチ後にデフォルト有効になる前提で影響範囲を棚卸しする
- データ保持：GitHub.com上のCopilot Chatもagent sessions体験へ寄り、保持期間の前提が28日からアカウント存続期間へ変わる点を確認する
- code review：DefaultのままならBalanced effortとして動くため、AI creditsとActions minutesの影響を見る
- 請求：10月1日以降、対象支払い方法では座席の前払い、超過利用時の追加支払い、月内按分の扱いを経理と確認する
自社のCopilot設定・利用状況・AI credits管理を短期間で棚卸ししたい場合は、HelloCraftAIのAI導入支援にご相談ください。
統合Copilot体験で変わるアクセス設計
GitHubの発表では、2026年9月28日以降、Copilot Chat on github.com、GitHub MobileのCopilot Chat、Copilot cloud agentが単一のCopilot体験とポリシーへ収束すると説明されています。従来は体験ごとに見ていた許可・禁止を、今後は統合されたポリシーとして扱う必要があります。
管理者が最初に見るべきなのは、誰がGitHub.com上でCopilotに質問できるか、誰がcloud agentに作業を割り当てられるか、モバイルから同じ権限で操作できるかです。とくにリポジトリ閲覧権限、Issue/PR作成権限、Secretsや社内コードへの接触範囲が広い組織では、ロール別に許可範囲を確認してから全社展開するのが安全です。
データ保持とSandboxをどう説明するか
公式発表では、統合体験によりCopilot on github.comがagent sessions体験へ移行し、チャットデータの保持が28日ではなくアカウント存続期間に揃うとされています。これは監査や社内説明で見落としやすい変更です。短期保存を前提に社内規程を書いている場合は、FAQ、利用ルール、ログ管理の表現を更新する必要があります。
一方で、cloud agentはSandboxを利用してより速いクラウド体験を提供する方向です。Sandboxは便利ですが、管理者は『何が隔離され、何がリポジトリ権限に従うのか』を説明できる状態にしておくべきです。社内向けには、許可リポジトリ、外部通信、生成PR、Actions実行、監査ログの5点で説明資料を作ると運用に乗せやすくなります。
Balanced既定でcode reviewコストはどう変わるか
Copilot code reviewでは、Defaultのreview effortが2026年9月28日からBalancedとして扱われます。GitHub Docsでは、LiteのAI credits消費は概算で0.05〜1ドル相当、Balancedは0.25〜5ドル相当と説明されています。さらにagentic capabilitiesではGitHub Actions runnersも利用されるため、AI creditsだけでなくActions minutesの観点も必要です。
ここで重要なのは、Balancedが悪いという話ではなく、既定値のまま自動レビューを全PRにかけると、レビュー品質とコストの両方が変わることです。大規模リポジトリ、巨大PR、custom instructionsが多い環境では消費が増えやすいため、まずは20〜50本のPRで平均コスト、レビュー時間、指摘採用率を測るのが現実的です。
Liteを維持すべき組織、Balancedを試すべき組織
Liteを明示選択すべきなのは、PR数が多く、既存の人間レビュー体制が強く、Copilotには軽い見落とし検知を期待している組織です。たとえば1日100本以上のPRが出るチームでは、全リポジトリをBalancedにするより、セキュリティ影響が大きいリポジトリだけBalancedにする方が管理しやすくなります。
Balancedを試す価値が高いのは、レビュー待ち時間が長い、レビュー品質のばらつきが大きい、生成AIコードの混入が増えている組織です。Balancedはより深い分析を期待できるため、認証、課金、権限、データ処理などの重要領域から段階導入するのが向いています。判断軸は、PR本数ではなく『見逃しコストが高い変更にCopilotを厚く使えているか』です。
10月1日の請求変更で経理が見るべき項目
クレジットカードまたはPayPal払いのCopilot Business/Enterpriseでは、2026年10月1日から既存顧客にも請求体験の変更が適用される予定です。公式発表では、座席割り当て時の支払い、次回請求サイクル開始時の割り当て済み座席への前払い、超過利用時の追加支払い、月内按分の可能性が説明されています。価格そのものは変更されない一方で、キャッシュフローと承認フローは変わります。
経理・管理者が確認すべき実務項目は、現在の支払い方法、座席追加の承認者、AI creditsの上限、追加購入の承認経路、座席解除時に日割り返金がない点の5つです。特に『一時的に席を付与して月末に外す』運用をしている場合は、前払いと返金なしの扱いを社内に説明しておく必要があります。
30日で実施する管理者チェックリスト
- Day 1: Copilot settingsで統合体験のポリシー状態を確認し、対象ユーザーと対象組織を一覧化する
- Day 3: GitHub.com、Mobile、cloud agentの利用可能範囲をロール別に整理する
- Day 7: code reviewのDefault設定を洗い出し、Lite固定が必要なリポジトリを明示する
- Day 10: Balanced対象のリポジトリを5〜10個に絞り、PR件数、平均レビュー時間、AI credits消費を記録する
- Day 14: chat data retentionの社内説明文、利用規程、FAQを更新する
- Day 21: 座席追加、AI credits追加購入、超過利用時の承認フローを経理と合意する
- Day 30: 利用状況、コスト、レビュー品質、問い合わせ数をまとめ、全社展開または限定運用を判断する
Copilotのポリシー変更、AI credits、code review運用をまとめて整理したい企業向けに、HelloCraftAIでは社内AI活用の設計・研修・運用チェックを支援しています。
よくある質問
Q. 9月28日に必ず設定変更が必要ですか？ A. 統合Copilot体験を使い続けるだけなら、公式発表上は追加作業なしでも利用可能です。ただし、管理者はポリシーが意図した状態か、デフォルト有効の範囲が社内ルールに合うかを確認すべきです。
Q. Balancedに変わると必ずコストが上がりますか？ A. Defaultのまま自動レビューが多い組織では上がる可能性があります。GitHub Docs上の概算でもBalancedはLiteより消費レンジが高いため、全社ではなく重要リポジトリから測定するのが安全です。
Q. 既存記事のCopilot code review設定と何が違いますか？ A. この記事は9月28日の統合体験、データ保持、Balanced既定、10月1日の請求変更をまとめた管理者向けチェックリストです。個人設定やEnterprise既定値だけでなく、経理・監査・モバイル利用まで含めて整理しています。
Q. まず何から始めるべきですか？ A. まずCopilot settingsで統合ポリシーとcode review Defaultを確認し、次に直近30日のPR本数とCopilot利用者数を出します。その2つが分かれば、Balanced対象のリポジトリとAI credits予算を現実的に決められます。
