GitHub CopilotでGemini 2.5 ProまたはGemini 3 Flashを使っている場合は、2026年7月31日までに代替モデルへ切り替える準備が必要です。GitHubは2026年7月2日、GitHub Copilotの各利用画面でGemini 2.5 ProとGemini 3 Flashを非推奨化し、同日以降は利用対象から外す予定だと案内しました。対象はCopilot Chatだけでなく、インライン編集、Ask、Agent mode、コード補完まで含まれます。(The GitHub Blog)
特にGitHub Copilot EnterpriseやCopilot Businessを管理している組織では、単に利用者へ「別のモデルを使ってください」と伝えるだけでは不十分です。代替モデルがポリシーで許可されているか、VS Codeやgithub.comのモデル選択画面に表示されるか、既存のワークフローや社内手順書に古いモデル名が残っていないかを確認する必要があります。
GitHubの「Upcoming deprecation of Gemini 2.5 Pro and Gemini 3 Flash」とは
今回の更新は、GitHub Copilotで利用できるAIモデルの入れ替えに関する告知です。GitHubの公式Changelogでは、Gemini 2.5 ProとGemini 3 Flashを2026年7月31日に非推奨化すると説明されています。代替候補として、Gemini 2.5 ProにはGemini 3.1 Pro、Gemini 3 FlashにはGemini 3.5 Flashが提示されています。(The GitHub Blog)
| 非推奨になるモデル | 非推奨化予定日 | GitHubが示す代替モデル | 主に確認すべき人 |
|---|---|---|---|
| Gemini 2.5 Pro | 2026年7月31日 | Gemini 3.1 Pro | 高精度な回答や設計相談でGemini 2.5 Proを選んでいた開発者、管理者 |
| Gemini 3 Flash | 2026年7月31日 | Gemini 3.5 Flash | 応答速度重視のチャット、補完、軽量な相談に使っていた利用者 |
ここで重要なのは、「GitHub Copilot自体が使えなくなる」という話ではない点です。影響を受けるのは、Copilotの中で選択していた特定モデルです。GitHub Copilotの利用を継続するには、サポートされる別モデルへ切り替えればよい、という整理になります。
影響範囲はCopilot Chatだけではない
今回の変更は、GitHub Copilotのモデル選択を日常的に使っている人ほど影響を受けます。公式情報では、対象範囲としてCopilot Chat、inline edits、ask、agent modes、code completionsが挙げられています。(The GitHub Blog)
つまり、次のような使い方をしている場合は確認が必要です。
| 利用シーン | 影響の見方 | 確認ポイント |
|---|---|---|
| VS CodeのCopilot ChatでGeminiを選んでいる | モデル選択肢から対象モデルが消える可能性がある | Gemini 3.1 ProまたはGemini 3.5 Flashが選べるか |
| GitHub.com上でCopilot Chatを使っている | ブラウザ上のモデルセレクターに影響する | github.com側でも代替モデルが表示されるか |
| Agent modeでタスクを任せている | 既定モデルや手順書の指定が古くなる可能性がある | エージェント実行時のモデル指定を見直す |
| コード補完やインライン編集で利用している | 利用者が明示的に意識していなくてもモデル変更の影響を受ける場合がある | 補完品質や応答傾向の変化を確認する |
| 社内ドキュメントでモデル名を指定している | 手順書どおりに操作できなくなる | README、開発標準、オンボーディング資料を更新する |
特に注意したいのは、Copilot Chatの画面だけ確認して安心してしまうケースです。チームでAgent modeやインライン編集を使っている場合、チャット以外の利用面でもモデル名が参照されていないか確認しましょう。
管理者がまず確認すべき変更点
GitHub Copilot Enterpriseの管理者は、代替モデルが組織で利用可能になっているかを優先して確認する必要があります。GitHubは、代替モデルを使うにはCopilot settingsのモデルポリシーでアクセスを有効化する必要がある場合があると案内しています。(The GitHub Blog)
GitHub Docsでも、利用できるAIモデルはCopilotプラン、利用クライアント、組織またはEnterpriseの制限に左右されると説明されています。組織やEnterpriseの所有者は、Copilot BusinessまたはCopilot Enterpriseのシートを持つメンバーに対して、モデルへのアクセスを有効化または無効化できます。(GitHub Docs)
管理者向けチェックリスト
| 確認項目 | やること | 放置した場合のリスク |
|---|---|---|
| 代替モデルの許可状況 | CopilotのAI controlsまたはモデルポリシーでGemini 3.1 Pro、Gemini 3.5 Flashを確認する | 利用者の画面に代替モデルが表示されない |
| 対象モデルの利用状況 | 開発チーム、AI推進担当、主要リポジトリの運用担当に確認する | 非推奨化後に問い合わせが集中する |
| VS Codeとgithub.comでの表示 | 管理者自身またはテストユーザーでモデルセレクターを確認する | ポリシー上は許可したが実際には使えない状態を見逃す |
| 社内ドキュメント | 「Gemini 2.5 Proを選択」などの記述を検索して更新する | 新メンバーが古い手順で操作して混乱する |
| 利用ルール | 用途別に推奨モデルを明記する | 各自が場当たり的にモデルを選び、品質やコスト管理が難しくなる |
Enterpriseでは、既定モデルの可用性を組織単位で制御できます。GitHub Docsでは、Enterprise ownerが各モデルについて「全組織で有効にする」または「各組織が有効化を選べるようにする」設定を選べると説明されています。なお、この既定モデル可用性の管理機能はPublic Previewであり、変更される可能性があります。(GitHub Docs)
開発者・一般ユーザーが確認すべきこと
個人利用やチームメンバーの立場では、まず自分がGemini 2.5 ProまたはGemini 3 Flashを明示的に選んでいないか確認しましょう。GitHubの案内では、代替モデルが有効化されると、VS Codeやgithub.comのCopilot Chatモデルセレクターに表示されるとされています。(The GitHub Blog)
確認の流れは次のとおりです。
| 手順 | 確認内容 |
| -: | ——————————————— |
| 1 | VS Codeまたはgithub.comでCopilot Chatを開く |
| 2 | モデル選択メニューを開く |
| 3 | 現在Gemini 2.5 ProまたはGemini 3 Flashを使っていないか確認する |
| 4 | Gemini 3.1 ProまたはGemini 3.5 Flashが表示されるか確認する |
| 5 | 普段の作業で数回試し、回答品質・速度・コード補完の傾向を確認する |
| 6 | 表示されない場合は、組織管理者にモデルポリシーの確認を依頼する |
個人向けCopilotプランでは、通常はモデルアクセスのポリシー管理を利用者自身が細かく設定する必要はありません。ただし、利用できるモデルはプランによって変わります。GitHub Docsでは、Copilot FreeとCopilot StudentはAuto model selection経由でのみモデルにアクセスできると説明されています。(GitHub Docs)
Gemini 3.1 ProとGemini 3.5 Flashの使い分け
GitHubは、Gemini 2.5 Proの代替としてGemini 3.1 Pro、Gemini 3 Flashの代替としてGemini 3.5 Flashを提示しています。GitHub Docs上では、Gemini 3.1 ProはPublic preview、Gemini 3.5 FlashはGAとして掲載されています。モデルの提供状況は変わる可能性があるため、導入時は公式Docs上の最新表示も確認してください。(GitHub Docs)
実務上は、単純に「新しいモデルだから常に良い」と考えるより、用途ごとに使い分ける方が安全です。
| 用途 | 向いている代替モデルの考え方 | 例 |
|---|---|---|
| 設計相談、複雑なリファクタリング、仕様理解 | Gemini 3.1 Proを優先して検証 | 複数ファイルをまたぐ変更方針の相談、設計レビュー |
| 軽い質問、短いコード補完、素早い説明 | Gemini 3.5 Flashを優先して検証 | エラー文の意味確認、関数の書き換え案、簡単なテスト生成 |
| チーム標準のモデル選定 | 品質、速度、利用可能プラン、ポリシーを合わせて判断 | 「設計レビューはPro系、日常チャットはFlash系」など |
| 本番コードへの反映前 | モデルに関係なく人間のレビューとテストを必須にする | セキュリティ修正、マイグレーション、認可処理の変更 |
GitHub Docsでも、Copilotは複数のAIモデルをサポートしており、モデルによって速度、コスト効率、精度、推論、マルチモーダル入力などの強みが異なると説明されています。どのモデルが適切かはタスクによって変わります。(GitHub Docs)
移行時に起きやすい失敗
モデルポリシーを確認せず、利用者任せにする
管理者が代替モデルを許可していない場合、利用者はモデルセレクターで代替モデルを選べません。GitHubのChangelogでも、Copilot Enterprise管理者はCopilot settingsのモデルポリシーで代替モデルへのアクセスを有効化する必要がある場合があると説明されています。(The GitHub Blog)
「各自で切り替えてください」と案内する前に、管理者側で最低1アカウントを使って実際の表示確認を行うべきです。
既存のプロンプトや手順書をそのまま使う
社内の開発手順に「Gemini 2.5 Proを選択してから実行する」といった文言が残っていると、非推奨化後に手順どおり操作できなくなります。特に、オンボーディング資料、AI活用ガイド、開発チームのWiki、研修資料、READMEに古いモデル名が残りやすいです。
検索するキーワードは、最低でも次の4つです。
- Gemini 2.5 Pro
- Gemini 3 Flash
- gemini-2.5
- gemini-3-flash
モデル名を直接指定している箇所は、単に名称を置き換えるだけでなく、「なぜそのモデルを使うのか」も見直しましょう。用途が速度重視なのか、精度重視なのかが分かれば、次回のモデル入れ替えにも対応しやすくなります。
切り替え後の回答品質を確認しない
代替モデルは同じGemini系であっても、回答の傾向、コード生成の癖、説明の粒度が変わる可能性があります。とくに社内標準としてCopilotを活用している場合は、代表的なタスクを数パターン用意して、切り替え前後の結果を比較すると実務への影響を把握しやすくなります。
検証に使うタスクは、現場でよく使うものに寄せるのがポイントです。
| 検証タスク | 見るべき観点 |
|---|---|
| 既存コードの説明 | 説明が正確か、不要な推測が混ざらないか |
| ユニットテスト生成 | 境界値、異常系、モックの扱いが適切か |
| リファクタリング提案 | 既存仕様を壊さないか、過剰な変更を提案しないか |
| エラー調査 | ログやスタックトレースから原因を絞り込めるか |
| セキュリティ関連コード | 認可、入力検証、秘密情報の扱いに問題がないか |
企業利用では「非推奨モデルの削除」より「代替モデルの展開」が重要
GitHubは、古いモデルが非推奨化された後に、それらを削除するための操作は不要だと案内しています。(The GitHub Blog)
そのため、管理者が注力すべきなのは「古いモデルをどう消すか」ではありません。重要なのは、利用者が業務を止めずに代替モデルへ移れる状態を作ることです。
おすすめの進め方は、次の順序です。
| フェーズ | 実施内容 | 目安 |
|---|---|---|
| 現状確認 | 対象モデルを使っているチーム、用途、手順書を洗い出す | すぐ実施 |
| ポリシー確認 | Gemini 3.1 Pro、Gemini 3.5 Flashの許可状態を確認する | 2026年7月中旬まで |
| 小規模検証 | 代表ユーザーでVS Code、github.com、Agent modeの挙動を確認する | 2026年7月中旬まで |
| 周知 | 代替モデル、切り替え手順、問い合わせ先を案内する | 非推奨化前 |
| 定着確認 | 非推奨化後に問い合わせ、補完品質、開発フローへの影響を確認する | 2026年8月以降 |
GitHub Enterpriseの顧客で不明点や懸念がある場合は、GitHubの案内に従い、アカウントマネージャーへ相談するのが安全です。(The GitHub Blog)
よくある疑問
GitHub Copilotが使えなくなるのですか？
いいえ。今回の対象はGitHub Copilot全体ではなく、Gemini 2.5 ProとGemini 3 Flashという特定モデルです。サポートされる代替モデルを使える状態にしておけば、Copilotの利用自体を継続できます。
何もしなくても自動で切り替わりますか？
個人利用では画面上の選択肢に従って使える場合がありますが、組織やEnterpriseではモデルポリシーが関係します。代替モデルが表示されない場合は、利用者側の操作では解決できないことがあります。管理者は、モデルポリシーと実際のモデルセレクター表示をセットで確認しましょう。
古いモデルを手動で削除する必要はありますか？
GitHubは、非推奨化後に古いモデルを削除するための操作は不要と案内しています。(The GitHub Blog)
ただし、社内ドキュメントや研修資料に残った古いモデル名は手動で更新する必要があります。
Gemini 3.1 ProとGemini 3.5 Flashのどちらを標準にすべきですか？
用途で分けるのが現実的です。複雑な設計相談や大きめのコード理解にはGemini 3.1 Pro、軽量な質問や素早い補助にはGemini 3.5 Flashを候補にすると判断しやすくなります。ただし、最終的には自社のコードベース、利用プラン、管理ポリシー、応答品質の検証結果をもとに決めるべきです。
まとめ：7月31日までにモデルポリシーと利用手順を見直す
今回のGitHubの更新で押さえるべき点は明確です。Gemini 2.5 ProとGemini 3 Flashは、2026年7月31日にGitHub Copilotの各利用体験で非推奨化される予定です。代替候補は、Gemini 2.5 ProがGemini 3.1 Pro、Gemini 3 FlashがGemini 3.5 Flashです。(The GitHub Blog)
管理者は、代替モデルがポリシーで許可され、VS Codeやgithub.comのモデルセレクターに表示されることを確認してください。開発者や一般ユーザーは、自分の普段の作業で対象モデルを選んでいないか確認し、代替モデルで回答品質や補完の傾向を試しておくと安心です。
次に取るべき行動は、対象モデルの利用有無を確認し、代替モデルの表示確認を行い、社内手順書に残った古いモデル名を更新することです。モデルの入れ替えは今後も起こり得るため、「モデル名を固定する運用」ではなく、「用途別に推奨モデルを見直せる運用」にしておくと、次回の変更にも対応しやすくなります。
コメント