多くのGitHub Copilot利用体験で6モデル廃止|後継モデルの管理

GitHubは2026年10月19日、GitHub Copilotの多くの利用体験で6つのAIモデルを廃止しました。対象はGemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5です。

今回の変更はCopilot Chatだけにとどまりません。インライン編集、ask mode、agent mode、コード補完も対象です。開発チームが使う機能を棚卸しします。

廃止モデルの削除操作は不要です。後継モデルの表示にはEnterpriseやOrganizationのモデルポリシーが関わります。固定モデル名のワークフローやインテグレーションは移行します。

※本記事は2026年10月28日時点の情報です。

廃止された6モデルと代替モデルの対応。Gemini 3.7 FlashはGemini 3.8 Flash、GPT-5.5とGPT-5.4はGPT-6.1 Sol、GPT-5.4 miniとGPT-5 miniはGPT-6 Luna、Grok 4.5はGrok 4.7
GitHubが示す代替モデルへの対応

多くのCopilot利用体験で6モデル廃止|代替モデルは4系統

GitHubが多くのCopilot利用体験で廃止したのは、世代の異なる6モデルです。廃止日はすべて2026年10月19日で、GitHubはそれぞれの代替モデルを示しています。

廃止モデル廃止日GitHubが示す代替モデル
Gemini 3.7 Flash2026-10-19Gemini 3.8 Flash。
GPT-5.52026-10-19GPT-6.1 Sol。
GPT-5.42026-10-19GPT-6.1 Sol。
GPT-5.4 mini2026-10-19GPT-6 Luna。
GPT-5 mini2026-10-19GPT-6 Luna。
Grok 4.52026-10-19Grok 4.7。

移行先は同じモデル提供元に限られません。GPT-5.5とGPT-5.4はGPT-6.1 Sol、GPT-5.4 miniとGPT-5 miniはGPT-6 Lunaへ案内されています。実際の開発タスクで出力を評価し、採用可否を判断する方針です。

GitHubのサポート対象モデル一覧では、利用可能なモデルはCopilotのプランとクライアントで異なると説明されています。後継モデルが一覧にあっても、全開発者やIDEで使えるとは限らない点に注意が必要です。

ポイント

多くのCopilot利用体験で廃止された6モデルは、すべて2026年10月19日が廃止日です。自社の利用モデルを表と照合し、後継モデルの契約・クライアント・ポリシーを確認します。

多くのCopilot利用体験に影響|開発工程ごとに点検する

Copilotのモデルは、質問に答えるチャットだけで使われているわけではありません。GitHubの発表では、今回の廃止対象にCopilot Chat、インライン編集、ask mode、agent mode、コード補完が含まれています。

モデル選択欄から古い名前が消えたかだけでは不十分です。補完、編集、エージェントへの作業依頼、チャットでの設計相談を分け、どの工程でモデルを選ぶか洗い出します。

  • 開発者の操作:Copilot Chatやインライン編集で選択しているモデル名を確認する。
  • エージェント利用:ask modeやagent modeでモデルを固定していないか確認が必要です。
  • 自動化・連携:ワークフローやインテグレーションで廃止モデルを指定していないか確認する。
  • 品質評価:代替モデルで代表的なコード作業を実行し、レビュー方法をそろえる。

AIモデルは同じ指示でも品質や処理時間が変わります。実際のタスクで評価する方法は、同一指示でAIモデル11種を比較した実験も参考資料です。

GitHubは、ワークフローとインテグレーションをサポート対象モデルへ更新するよう案内しています。リポジトリの開発手順や自動処理から優先して点検が必要です。

ポイント

影響範囲はモデル選択欄に限りません。補完、編集、ask/agent mode、コード作業の自動連携を工程別に分けて点検すると、見落としを減らせる内容です。

Enterpriseのモデルポリシー|後継モデルの表示可否を管理する

Copilot Enterpriseでは、管理者が提供モデルを制御できます。代替モデルへのアクセスを、モデルポリシーで有効にする必要がある場合があります。

既定のOrganizationモードでは、Enterprise全体のモデル設定からOrganizationへ判断を委ねる仕組みです。Enterprise teamsによる制御はopt-in previewで、Organizationレベルのモデル設定を使えません。

Enterprise teamsモードでは、チームとagent appsへのモデル委譲が対象です。既定のOrganizationモードと同時に使わず、先に管理方式を選ぶ設計です。

Enterpriseのモデルポリシーは、OrganizationモードかEnterprise teamsモードのどちらか一方で細かく制御し、有効にしたモデルがVS Codeとgithub.comのモデル選択欄に表示される
OrganizationモードとEnterprise teamsモードは、どちらか一方を使う
  • Enterprise全体:全ユーザーとagent appに有効化するか、無効化するかを決める。
  • 既定のOrganizationモード:Enterpriseから委譲されたモデルを組織単位で有効・無効にする。
  • Enterprise teamsモード(opt-in preview):チームとagent appsへのモデルアクセスを設定する。Organizationレベルのモデル設定は無効になる。

設定後は管理画面だけでなく、開発者のクライアントのモデル選択欄も確認します。GitHubは、ポリシーを有効にするとVS Codeとgithub.comのCopilot Chatに表示されると説明しています。

企業でCopilotを管理するときは、利用者、統合先、選定基準を定める設計です。全社導入の観点は、Microsoft Copilotの大規模導入を参考資料にできます。

ポイント

後継モデルが見えないときは、プラン、クライアント、Enterprise・Organization・チームのモデルポリシーを順に切り分ける運用です。廃止モデルの削除操作は必要ありません。

既定の可用性を確認|自動有効化と明示設定を分ける

後継モデルの表示を考えるとき、個別モデルの設定と「Default availability for released models」を混同しないことが重要です。このポリシーは、まだ明示的に設定していないGAモデルに対する既定の扱いを決めます。

ポリシーがEnabledなら、「Delegate to Default Policy」と表示されたモデルは、Copilotユーザーに自動で有効になります。Disabledなら自動で無効です。組織によっては、Enterpriseで組織に判断を委ねる設定も選べます。

自動有効化は、新しいモデルを素早く届けやすい運用です。一方で、モデルの挙動を評価してから開発工程へ広げたい企業には、明示設定や組織単位の委譲が向いています。どちらを選ぶかは、開発速度と変更管理のルールで決めます。

  • 自動で有効化:GAモデルを広く試し、新モデルの展開を速める。
  • 明示的に有効化:検証済みモデルだけを提供し、変更の影響範囲を管理する。
  • 組織へ委譲:事業や開発環境の違いに合わせ、組織ごとに判断する。

モデルを固定する理由が、品質なのかデータ管理なのか、開発者教育なのかも明文化します。Default availability for released modelsをEnabledにすると、明示設定していないGAモデルも自動で有効になります。

ポイント

Default availability for released modelsは、セッションで最初に選ばれるモデルを決める設定ではありません。明示設定していないGAモデルを有効・無効のどちらにするかを決めるポリシーです。

移行手順を運用化|固定モデル名とポリシーを棚卸しする

今回のような廃止は、モデルの世代交代が開発ツールの通常運用に入ったことを示します。1回の切り替えで終わらせず、モデル名を固定している箇所と、利用可否を管理する設定を分けて台帳化します。

まず3つの台帳を作る

最初に作るのは、モデルの利用箇所、モデルポリシーの設定者、代替モデルの評価結果を並べた台帳です。担当部署が違う情報を一つにまとめると、廃止告知を受けたときの確認漏れを減らせます。

  1. 利用箇所を列挙する:Chat、補完、編集、ask/agent mode、ワークフロー、インテグレーションを分ける。
  2. 代替を評価する:代表的なコード作業で出力を比べ、レビューと修正の手順を決める。
  3. 設定を更新する:モデルポリシーと固定モデル名を変更し、利用者の画面で動作を確認する。

複数のOrganizationやチームを管理するEnterpriseでは、2026年10月19日に一般提供されたモデルポリシーAPIも使えます。Enterprise、Enterprise teams、agent apps、Organizationの各ポリシーが対象です。

モデルの提供状況は今後も変化します。GitHubのモデル一覧とChangelogを定期確認し、変更時は「告知」「影響箇所」「代替評価」「ポリシー更新」の順に対応する流れです。AI生成コードの品質管理では、AI生成コード時代のコードレビューのように、人によるレビューも残す設計です。

告知、影響箇所、代替評価、ポリシー更新、の4つを繰り返す運用
廃止のたびに同じ手順を回す

ポイント

モデルの廃止を受けて毎回ゼロから調べるのではなく、利用箇所・管理設定・評価結果の3台帳を更新する運用にします。次のモデル変更にも同じ手順を適用できます。

よくある質問

Q. 多くのGitHub Copilot利用体験で廃止された6モデルは何ですか?

6モデルです。対象はGemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5です。廃止日はすべて2026年10月19日に設定されています。

Q. 廃止モデルを削除するために管理者の操作は必要ですか?

不要です。GitHubは、多くのCopilot利用体験で廃止されたモデルの削除操作は必要ないと案内しています。ワークフローやインテグレーションは、サポート対象モデルへの更新が必要です。

Q. 後継モデルがCopilotのモデル選択欄に表示されないときはどうしますか?

Copilotのプランとクライアントを確認し、選択中の管理モードで後継モデルが有効か確認が必要です。GitHubは、ポリシー有効後にVS Codeとgithub.comのCopilot Chatへ表示される仕様だと説明しています。

Q. GitHub Copilotのモデルは今後も入れ替わりますか?

入れ替わる前提です。GitHubはモデルの提供状況が変更される場合があると説明しているため、モデル一覧とChangelogの定期確認が必要です。

まとめ

GitHub Copilotでは、2026年10月19日に多くの利用体験で6モデルが廃止されました。対象はGemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5です。代替モデルは案内されていますが、プラン、クライアント、モデルポリシーによって利用できる範囲は変わります。

企業の管理者は、廃止モデルを消すのではなく、利用箇所の棚卸し、後継モデルの評価、ポリシー設定、開発者への周知を進めます。更新を定期運用に組み込めば、次の廃止時の備えです。

ポイント

まず6モデルと代替モデルを照合し、次にCopilot Enterpriseのモデルポリシーと固定モデル名を点検する段階です。最後に代表的な開発タスクで代替モデルを評価し、組織の標準を決定します。

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール
張田谷凌央
張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。