GitHub Copilot で Gemini 2.5 Pro と Gemini 3 Flash が廃止、Copilot の全体験に影響
GitHub Copilot で提供していた Gemini 2.5 Pro と Gemini 3 Flash が廃止された。移行先は Gemini 2.5 Pro → Gemini 3.1 Pro(Preview)、Gemini 3 Flash → Gemini 3.6 Flash。影響は Copilot Chat、インライン編集、ask / agent モード、コード補完を含む Copilot のすべての体験に及ぶ。エンタープライズ管理者はワークフローと連携を対応モデルへ更新し、Copilot 設定のポリシーで代替モデルへのアクセスを有効化し、モデルセレクタで提供状況を確認する必要がある。一般ユーザーは即時対応不要だが、旧モデルを使っているカスタム構成は更新が要る。
ニュース原文を読む ↗要約
GitHub Copilot で提供していた Google の Gemini 2.5 Pro と Gemini 3 Flash が廃止されました。移行先として案内されているのは次の2つです。
- Gemini 2.5 Pro → Gemini 3.1 Pro(Preview)
- Gemini 3 Flash → Gemini 3.6 Flash
影響範囲は Copilot のすべての体験に及びます。Copilot Chat、インライン編集、ask / agent モード、コード補完が対象です。特定の機能だけの話ではないため、旧モデルを指定していた箇所はすべて確認が必要になります。
対応は立場によって異なります。エンタープライズ管理者は、ワークフローと連携を対応モデルへ更新し、Copilot 設定のポリシーで代替モデルへのアクセスを有効化し、モデルセレクタ(VS Code および github.com)で提供状況を確認する必要があります。一般ユーザーについては、廃止されたモデルを取り除くための即時対応は不要とされていますが、旧モデルを使っているカスタム構成は更新が必要です。エンタープライズ顧客は、疑問があればアカウントマネージャーへ問い合わせるよう案内されています。
注意しておきたいのは、移行先の Gemini 3.1 Pro が Preview である点です。廃止されたモデルの代替が Preview 版というのは、本番運用の観点では扱いに悩む状況です。安定性を重視するなら、Gemini 3.1 Pro に移るのではなく、他ベンダーの GA モデルへ移すという判断もあり得ます。
何が変わったか
- Gemini 2.5 Pro と Gemini 3 Flash が GitHub Copilot で廃止された(即時適用)
- 移行先: Gemini 2.5 Pro → Gemini 3.1 Pro(Preview)、Gemini 3 Flash → Gemini 3.6 Flash
- 影響範囲は Copilot の全体験(Copilot Chat、インライン編集、ask / agent モード、コード補完)
- エンタープライズ管理者の対応: ワークフロー・連携の更新、Copilot 設定のポリシーで代替モデルを有効化、モデルセレクタでの提供状況確認
- 一般ユーザーの対応: 即時対応は不要だが、旧モデルを使うカスタム構成は更新が必要
- エンタープライズ顧客はアカウントマネージャーへ問い合わせ可能
業務インパクト(一般企業向け)
管理者にとっては、また1つポリシー設定の作業が増えたかたちです。ここ最近の Copilot は、Gemini 3.6 Flash(07-21)、Claude Opus 5(07-24)、Grok 4.5(07-28)とモデルを追加し続け、今回は廃止です。追加も廃止も同じ頻度で起きているというのが実態です。
この状況を踏まえると、個別のモデルごとに判断を積み上げる運用は成立しません。2026-07-29 に発表されたデフォルトモデル有効化ポリシー(2026-08-26 発効)と、2026-07-31 のエンタープライズチーム単位のモデルポリシー割り当ては、まさにこの負荷への回答です。今回の廃止対応をきっかけに、「どのベンダーのモデルを許容するか」というレベルで方針を決め、個別のモデルは自動で追随させる構成へ寄せるのが現実的です。
実務上の作業としては、まず旧モデルを明示指定している箇所の洗い出しです。ワークフローと連携が対象に挙がっているのは、CI やスクリプトの中でモデル名を指定しているケースを想定してのことでしょう。開発者の個人設定より、こうした自動化された箇所の方が発見が遅れます。
移行先が Preview である点は、社内でどう扱うかを決める必要があります。Gemini 2.5 Pro を使っていたチームに対して「Gemini 3.1 Pro(Preview)へ移ってください」と案内するのは、Preview を本番で使うことを組織として容認するかどうかの判断を含みます。容認しないなら、Claude や GPT 系の GA モデルへ移す案内にする方が筋が通ります。ベンダーを揃えることに強いこだわりがなければ、後者の方が安定します。
一般ユーザー向けの案内としては、「基本的に何もしなくてよいが、カスタム構成を持っている人だけ確認」という切り分けを明示するのが親切です。全員に一律で対応を求めると、対応不要な大多数の工数を無駄にします。
副業・個人活用視点
個人プランでも影響は同じです。モデルセレクタから Gemini 2.5 Pro と Gemini 3 Flash が消えます。普段使っていたなら、Gemini 3.1 Pro(Preview)または Gemini 3.6 Flash へ切り替えることになります。
カスタム構成を持っているかどうかが分かれ目です。プロンプトファイルや設定でモデル名を明示している場合、そこを直さないと期待どおり動きません。特に、複数のクライアント案件で環境を分けているなら、それぞれ確認が必要です。
実務的な教訓としては、モデル名を固定で書かない習慣です。Copilot に限らず、ここ数週間だけでも追加3件・廃止2件という頻度でモデルが入れ替わっています。特定のモデル名に依存した設定やドキュメントを作ると、月単位で陳腐化します。「用途に対してどの帯のモデルを使うか」という抽象度で書いておき、具体名は最小限にする方が保守が楽です。
移行先が Preview であることは、個人利用ではさほど問題になりません。むしろ Preview のモデルを早く試せる機会と捉える方が実利があります。ただしクライアント案件で使うなら話は別で、Preview のモデルを本番の納品物の生成に使うことを先方が許容するかは確認しておくべきです。安定性を求められる案件では、GA のモデルを選ぶ方が説明しやすくなります。