何が変わるのか
GitHub は 2026 年 8 月 28 日、Copilot Business / Enterprise の課金とポリシーに関する変更を発表しました。対象は座席課金だけではありません。Copilot Chat と cloud agent の統合、チャットデータの保持期間、コードレビューの既定値も、9 月から 10 月にかけて変わります。
同じ時期には GitHub Copilot の 6 モデル廃止 も予定されていますが、モデル移行と今回の課金・ポリシー変更は別件です。本記事では、情シス・法務・開発管理者が「いつまでに、何を確認するか」に絞ります。
最初に日付順で全体を見ておきましょう。
| 日付 | 変更内容 | 必要なアクション |
|---|---|---|
| 2026 年 9 月 1 日から | 新規の Copilot Business / Enterprise の座席割り当てで、アクセス前の支払いが必要になる | 新規導入・増員の承認フローと支払い準備を確認する |
| 2026 年 9 月 28 日から | コードレビューの既定の労力レベルが Lite から Balanced へ変わる | Lite を維持する場合のみ、期限前に Default から Lite へ明示設定する |
| 2026 年 9 月 28 日以降 | 3 つの Copilot 体験と個別ポリシーが統合され、チャットデータの保持が延長される | 情シス・法務が保持方針を確認し、統合後のポリシーをレビューする |
| 2026 年 10 月 1 日から | 既存のクレジットカード / PayPal 払いで、次の請求サイクル開始時に座席の前払いが発生する | 支払い方法、割り当て済み座席、予算承認の担当を確認する |
この表で、製品上「期限より前に設定を変えなければ現状を維持できない」のは Lite の項目だけです。課金とデータ保持は、契約・規程・運用を確認して備える項目です。製品仕様として必要な操作と、社内での運用提案を混同しないように進めてください。
注意
Copilot 体験の統合は「9 月 28 日以降」です。コードレビューの既定変更は「9 月 28 日から」です。同じ日付を含みますが、原文の表現が異なります。
座席課金が前払いになる
座席課金の変更は、新規顧客と既存顧客で開始日と説明が異なります。新規の Copilot Business / Enterprise では、2026 年 9 月 1 日から、利用者へ Copilot のアクセスを与える前に各座席の支払いが必要です。
既存顧客は、2026 年 10 月 1 日からの扱いです。ただし、発表が明記している対象は、クレジットカードまたは PayPal で支払う Copilot Business / Enterprise 顧客です。次の請求サイクルが始まる時点で、割り当て済みの全座席に前払いの請求が発生します。
| 区分 | 開始時期 | 発表で示された扱い | 対象の限定 |
|---|---|---|---|
| 新規の座席割り当て | 2026 年 9 月 1 日から | 利用者がアクセスを得る前に、座席ごとの支払いが必要 | Copilot Business / Enterprise |
| 既存顧客の割り当て済み座席 | 2026 年 10 月 1 日から | 次の請求サイクル開始時に、割り当て済み座席へ前払い請求 | クレジットカード / PayPal 払いの Copilot Business / Enterprise 顧客 |
請求書払いの既存契約について、同じ変更が同じ日から適用されるかは、今回の発表本文に記載がありません。「すべての既存契約が対象」と広げて解釈せず、契約条件や個別の案内を確認してください。
座席の棚卸しは請求前に行う
前払いになると、座席を割り当てる判断と支払いのタイミングが近づきます。情シスや購買部門では、申請、承認、割り当て、退職・異動時の解除が同じ台帳で追えるかを確認しておくと、不要な座席を抱えにくくなります。
これは GitHub が指定した製品操作ではなく、発表を受けた運用上の提案です。公式発表には、解約、返金、日割り計算、座席の再割り当てに関する具体的な条件は記載されていません。社内手順を決めるときは、記載のない条件を推測で補わないでください。
また、含まれる利用量を超えた場合は、本人や利用者が Copilot を使い続けるために追加の支払いが必要になる可能性があります。一方で、座席単価、含まれる利用量の内訳、具体的な超過レートは、今回の発表本文にはありません。予算を組む際は金額を仮定せず、契約画面や個別の請求案内を基に判断します。
FIXIT10 月から、既存の契約は全部前払いになるの？
Dodaiそこは断定できません。発表が明記したのはカードと PayPal 払いです。
FIXIT請求書払いなら、どう確認する？
Dodai契約条件と個別案内を見ます。記載のない条件を推測すると事故ります。
Copilot Chat と cloud agent が単一の体験に統合される
GitHub は、早くても 2026 年 9 月 28 日に、次の 3 つを単一の Copilot 体験として再提供するとしています。
- GitHub Web の Copilot Chat
- GitHub Mobile の Copilot Chat
- GitHub Copilot cloud agent
原文は No earlier than September 28th, 2026 です。したがって「9 月 28 日に統合される」とは断定できません。9 月 28 日は最も早い開始日の目安であり、管理者は同日以降の案内を確認してください。
統合に伴い、3 つの体験ごとに分かれていたポリシーは、単一のポリシーへ置き換わります。利用者から見ると入口がまとまり、管理側から見ると判断基準が一本化される変更です。ただし、発表の抜粋には新しいポリシーの全文や、旧ポリシーとの条項別の差分は含まれていません。
そのため、現時点で「何が許可され、何が禁止される」と細部まで書くことはできません。実務では、統合後のポリシーが提示された時点で、現在の利用ルール、セキュリティ審査資料、従業員向けガイドの根拠を差し替える担当者を決めておくのが現実的です。
GitHub Copilot の Slack / Teams 連携 を含め、cloud agent はエディタ外の接点にも広がっています。接点が増えるほど、利用者がどの入口から何を入力したかを、単一のルールで説明できる状態が重要になります。
一本化前に確認する資料
確認対象は、Copilot の設定画面だけではありません。社内に次の資料がある場合は、旧ポリシーや 28 日保持を前提にしていないかを探します。
- AI ツールの利用規程と申請書
- 情報セキュリティ部門の審査記録
- 開発者向けの入力禁止情報ガイド
- モバイル端末からの利用ルール
- cloud agent の利用範囲を定めた手順書
- 退職・異動時のアカウント停止手順
この棚卸しは製品仕様として要求された操作ではありません。しかし、ポリシーが一本化されてから古い説明が残ると、利用者はどのルールを優先すべきか判断できません。文書の所在と更新担当だけでも先に決めておくと、正式な差分が出たあとに動きやすくなります。
チャットデータの保持期間が 28 日からアカウント存続期間へ
統合に伴う最大のガバナンス変更は、チャットデータの保持期間です。従来の 28 日間から、アカウントが存続する限りへ延長されます。既存の Copilot cloud agent の体験に合わせる変更です。
| 観点 | 変更前 | 変更後 |
|---|---|---|
| チャットデータの保持 | 28 日間 | アカウントが存続する限り |
| 対象となる説明 | 統合前の個別体験 | 単一の Copilot 体験 |
| 管理上の焦点 | 短期間で消える前提の運用 | アカウント管理と長期保持を結び付けた運用 |
28 日がアカウント存続期間へ変わるため、単なる画面変更として扱うべきではありません。入力内容が残る期間の前提が変わります。情シス・情報セキュリティ・法務が把握し、社内のデータ保持方針との整合を確認します。
生成 AI の情報漏えい対策 では、入力前のルール設計と権限管理を整理しています。保持期間が延びるからといって、直ちに情報漏えいが起きるわけではありません。一方で、短期間で消えることを前提に入力ルールを緩めていた場合は、前提から見直す必要があります。
情シス・法務が確認する 4 つの論点
第一に、社内規程の保存期間と矛盾しないかを確認します。規程に「AI チャットは一定期間で削除される」と書いてある場合、28 日という前提が残っていないかを検索してください。
第二に、入力してよい情報の範囲を確認します。保持期間が延びても、入力禁止情報の定義が明確なら運用の軸は崩れません。定義が曖昧なまま「機密情報は禁止」とだけ書いている場合は、コード、顧客情報、認証情報、未公開の事業情報など、利用者が判断できる単位へ落とします。
第三に、アカウントのライフサイクルを確認します。保持期間がアカウント存続期間に結び付くなら、入社、異動、休職、退職、委託終了に伴うアカウント処理の担当と証跡が重要です。ただし、アカウント削除時の個別データ処理や復旧可否は、今回の発表本文に記載されていません。削除手続きの詳細は別途確認が必要です。
第四に、利用者への周知です。保持期間の変更を利用者が知らなければ、以前と同じ感覚で入力を続けます。統合の実施案内が出た時点で、変更前後と入力ルールを一緒に伝えると理解しやすくなります。
要点
28 日からアカウント存続期間への変更は、情シス・法務が把握すべきガバナンス変更です。新しい単一ポリシーの公開を待つ間にも、現行規程で 28 日保持を前提にした記述がないか確認できます。
コードレビューの既定が Lite から Balanced に変わる
2026 年 9 月 28 日から、Copilot コードレビューの既定の労力レベルが Lite から Balanced へ変わります。設定が Default のままなら、既定値の変更に伴って Balanced が使われるようになります。
Lite を維持したい場合は、9 月 28 日より前に、リポジトリまたは組織の設定でレビューの労力レベルを Default 以外へ変更し、Lite を明示的に選択してください。今回の発表で、期限前に手を動かす必要がある唯一の製品設定です。
| 現在の設定と意向 | 9 月 28 日までの対応 | 9 月 28 日からの扱い |
|---|---|---|
| Default のまま、Balanced を受け入れる | 設定変更は不要 | Balanced が既定になる |
| Default だが、Lite を維持したい | 期限前に Lite を明示選択する | Lite を維持する |
| Lite をすでに明示選択している | 設定値を確認する | 明示設定した Lite を維持する想定で確認する |
最後の行は、期限前に現在値を確認する運用提案です。発表の引用が明示している操作は、Default から離れて Lite を明示選択することです。Balanced と Lite の処理内容、消費量、料金差、レビュー品質の定量比較は、今回の発表本文に記載されていません。
したがって、名称から負荷や料金を推測して決めるのは避けます。組織として Lite を維持する明確な理由があるなら期限前に設定し、理由がなければ Default のまま新しい既定を受け入れる、という分け方ができます。
リポジトリ設定と組織設定の担当を決める
設定場所はリポジトリまたは組織です。複数のリポジトリを運用している企業では、どちらを正とするか、例外リポジトリを誰が管理するかを先に決めてください。これは GitHub が指定した必須手順ではなく、設定漏れを防ぐための運用提案です。
設定後は、対象範囲と選択値を記録します。画面の項目名や階層は今後変わる可能性があるため、本記事では発表にないクリック手順を補いません。重要なのは、9 月 28 日より前に Default を離れ、Lite を明示的に選ぶことです。
FIXIT何もしなければ、9 月 28 日から Balanced になるんだね？
Dodaiはい。Lite を残す組織だけ、期限前の明示設定が必要です。
FIXIT課金やポリシーにも、先に変える設定がある？
Dodai発表上はありません。確認と準備を、製品の必須操作と分けて進めます。
期限までにやることの整理
期限順に並べると、担当者の引き継ぎがしやすくなります。次の表で「製品仕様上の必須」としたのは Lite 維持の操作だけです。それ以外は、変更を受けて組織が判断するための運用提案です。
| 期限・時期 | やること | 担当の例 | 区分 |
|---|---|---|---|
| 9 月 1 日より前 | 新規座席の申請・承認・支払いフローを確認する | 情シス・購買 | 運用提案 |
| 9 月 28 日より前 | Lite 維持の要否を決め、必要なら Default から Lite へ変える | GitHub 組織・リポジトリ管理者 | 製品仕様上の必須操作 |
| 9 月 28 日より前 | 28 日保持を前提にした社内規程・審査資料を探す | 情シス・法務 | 運用提案 |
| 9 月 28 日以降 | 統合の実施案内と単一ポリシーを確認し、差分をレビューする | 情シス・法務 | 運用提案 |
| 10 月 1 日より前 | 既存契約の支払い方法と割り当て済み座席を確認する | 契約管理・購買 | 運用提案 |
| 次の請求サイクル開始前 | クレジットカード / PayPal 払いの前払いに備えて承認を完了する | 契約管理・経理 | 運用提案 |
1. まず契約と設定の現状を分けて記録する
課金の担当と GitHub の設定担当が同じとは限りません。契約情報にはプラン、支払い方法、請求サイクル、割り当て済み座席を記録します。設定情報には、コードレビューの設定単位と現在の労力レベルを記録します。
請求書払いの扱い、単価、超過レートは発表に記載がないため、未確認の欄として残してください。空欄を推測で埋めるより、問い合わせ先と確認期限を添えるほうが実務で使えます。
2. Lite を維持するかを最初に決める
明確な締切があり、操作しないと現状を維持できないためです。Lite を維持するなら、9 月 28 日当日ではなく、その前に設定を終えます。複数リポジトリがある場合は、組織設定と個別設定の対象を一覧にして漏れを防ぎます。
Balanced を採用する場合も、関係者へ既定値が変わることは伝えておくと、変更後の問い合わせを減らせます。ただし、告知にない品質差やコスト差を断定して説明しないでください。
3. データ保持のレビューを情シス・法務へ渡す
レビュー依頼には「保持期間が 28 日からアカウント存続期間へ延びる」「統合は 9 月 28 日以降」「個別ポリシーは単一ポリシーへ置き換わる」の 3 点を添えます。判断に必要な一次情報を短く揃えると、機能紹介だけを渡すより論点が伝わります。
法人向け AI プランの選び方 でも、契約条件とガバナンスを担当横断で確認する考え方を整理しています。製品が違っても、契約担当だけで決めず、情シス・法務・利用部門の役割を分ける点は共通します。
4. 10 月の請求前に座席を確認する
既存のクレジットカード / PayPal 払いでは、10 月 1 日から次の請求サイクル開始時に、割り当て済み座席へ前払いが発生します。利用していない座席がないか、退職・異動の処理が止まっていないかを確認します。
座席の解除や再割り当てに関する具体的な請求ルールは、今回の発表本文にありません。座席を変更する場合は、操作の結果を推測せず、契約画面や個別案内を確認してください。日々の開発運用を含む Copilot の基本的な検討事項は GitHub Copilot の実践ポイント も参考になります。
5. 変更後の確認日を予定に入れる
9 月 28 日は、コードレビューの既定変更が始まる日です。一方、Copilot 体験の統合は早くても同日であり、実施日が後ろへずれる可能性があります。1 回の確認で両方が終わったと判断せず、コードレビュー設定の確認と、統合案内の確認を別の項目にします。
10 月 1 日も、すべての既存顧客へその日に一律請求されるという説明ではありません。クレジットカード / PayPal 払いの既存顧客について、同日から次の請求サイクル開始時に前払いが発生します。自社の請求サイクルと結び付けて予定を立ててください。
まとめ
2026 年 9〜10 月の GitHub Copilot 変更は、課金、ポリシー、データ保持、コードレビューにまたがります。日付が近接しているため、ひとまとめに見えますが、対象者と必要な対応は異なります。
新規の Copilot Business / Enterprise は 9 月 1 日から座席のアクセス前に支払いが必要です。コードレビューは 9 月 28 日から既定が Lite から Balanced へ変わり、Lite を維持する場合だけ期限前の明示設定が必要です。Copilot Chat と cloud agent の統合は 9 月 28 日以降で、チャットデータは 28 日間ではなくアカウント存続期間にわたり保持されます。既存のクレジットカード / PayPal 払いは、10 月 1 日から次の請求サイクル開始時に前払いへ変わります。
最初の一歩は、GitHub 管理者がコードレビューの現在値を確認し、Lite を維持するかを決めることです。同時に、情シス・法務へデータ保持期間の変更を共有してください。AI 開発ツールの契約・設定・社内ルールをまとめて見直したい場合は、AI 開発ツール定着支援 で運用設計をご相談いただけます。