9 月 1 日に 6 モデルが使えなくなる
GitHub Copilot で、2026 年 9 月 1 日に 6 つのモデルが廃止されます。2026 年 7 月 31 日に公式の changelog で予告されました。
整理すると、影響を受けるのは次の 2 者です。管理者は期日までに設定を 1 つ変える必要があり、開発者はモデル名を固定している箇所だけ直す必要があります。 何もしないまま当日を迎えると、選べるモデルが減った状態で朝を迎えることになります。
作業自体は数分で終わります。問題は、期日が過ぎてから気づく形になりやすいことです。
対象と代替の対応表
公式に示されている対応は次のとおりです。
| 廃止されるモデル | 推奨される代替 |
|---|---|
| Gemini 3.1 Pro | Gemini 3.6 Flash |
| Claude Opus 4.5 | Claude Opus 4.7 / 4.8 / 5 |
| Claude Opus 4.6 | Claude Opus 4.7 / 4.8 / 5 |
| Claude Sonnet 4.5 | Claude Sonnet 5 |
| Claude Sonnet 4.6 (※) | Claude Sonnet 5 |
| Raptor Mini | MAI-Code-1-Flash |
いずれも同系列の後継への移行なので、使い方や指示の書き方を変える必要はありません。 世代が 1 つ上がるだけです。
Claude Opus 系だけ代替が 3 つ並んでいますが、迷ったら新しいほうを選んで構いません。世代間の違いは Claude Opus 4.6・4.7・4.8 の違いと使い分け に整理しています。
例外は Claude Sonnet 4.6 だけ
表の ※ 印には例外があります。公式には次のように書かれています。
Claude Sonnet 4.6 will remain available to individual GitHub Copilot subscribers on annual plans so they retain a Sonnet offering.
個人の年間プラン契約者に限り、Claude Sonnet 4.6 は引き続き使えます。 Sonnet の選択肢を残すための措置です。
注意が要るのは、この例外が「個人」かつ「年間プラン」の両方を満たす場合に限られることです。組織のライセンスで配られている場合や、月額で契約している場合は対象外になります。自分がどちらなのかを先に確認してください。 例外があると聞いて安心していたら対象外だった、というのがいちばん避けたい形です。
管理者がやること
やることは 1 つです。廃止日より前に、Copilot 設定のモデルポリシーで代替モデルへのアクセスを有効化する ことです。
ポリシーで許可されていないモデルは、開発者の選択肢に出ません。旧モデルだけを許可した状態で 9 月 1 日を迎えると、廃止されたモデルは消え、代替は許可されていない、という状態になります。使えるモデルが実質的に減ります。
注意
「代替モデルは自動で使えるようになる」わけではありません。ポリシーは明示的に許可した分だけが有効なので、追加の操作が要ります。
逆に、廃止されたモデルをポリシーから削除する作業は不要です。 公式にもその旨が書かれています。掃除のつもりで触って別の設定を壊すほうが損なので、そこは放っておいて構いません。
作業の順番としては、次のようになります。
- 現在のモデルポリシーで、どのモデルを許可しているかを確認する
- 表の右列にあたるモデルが許可されていなければ、追加で有効化する
- 開発者側で選択肢に出るかを 1 人試して確認する
- 期日後に、旧モデルが消えたことを確認する
3 番を飛ばさないでください。ポリシーを変えたつもりでも、反映されているかは使う側で見ないと分かりません。
自分の契約形態をどう確かめるか
例外の対象かどうかは契約形態で決まるので、そこを先に確定させてください。判断はこの表で足ります。
| 状況 | Claude Sonnet 4.6 の扱い |
|---|---|
| 個人で契約・年間プラン | 継続して使える |
| 個人で契約・月額プラン | 廃止される |
| 会社から配られたライセンスで使っている | 廃止される |
会社から配られている場合は、本人が年払いかどうかを知らないことが多い部分です。 支払っているのは会社であり、個人の契約ではありません。ここを取り違えると、「例外があるから大丈夫」と判断したまま期日を迎えます。
分からないときは、管理者に契約形態を確認してください。管理者側から見れば一目で分かる情報です。
開発者側で確認すること
現場での影響は限定的です。モデル選択の一覧から対象モデルが消えるだけで、ほとんどの人は既定のまま使っているはずです。
ただし、次のいずれかに当てはまる場合は確認が要ります。
- 設定ファイルにモデル名を固定で書いている
- 社内の手順書や導入ガイドにモデル名を書いている
- スクリプトや自動化からモデルを指定して呼んでいる
いずれも、廃止されたモデル名が残っていると指定が無効になります。 静かにエラーになるか、既定のモデルに落ちるかは環境によりますが、どちらにしても意図した状態ではありません。
確認は検索で足ります。リポジトリと手順書に対して、廃止対象のモデル名で全文検索をかけてください。ヒットが 0 なら、あなたの環境では何もしなくて構いません。
FIXIT使ってるモデルが消えるって、けっこう困らない？
ShioriFIXITShiori影響はほぼありません。優先順位で言うと、管理者側の設定が先です。
移行後に「前より悪い」と感じたら
代替モデルへ移ったあと、体感が変わったという声が出ることがあります。そのほとんどは、モデルの優劣ではなく前提の違いです。 切り分けの順番を決めておくと、無用な議論が減ります。
まず疑うのは次の 3 つです。
- 依頼の書き方を変えていないか。移行を機に指示を書き直していると、変わったのはモデルではなく指示です
- 比べている作業が同じか。前は小さな修正、今は大きな実装、では比較になりません
- 既定に戻っていないか。ポリシー設定によっては、指定が無効になって別のモデルで動いていることがあります
3 番が地味に多い部分です。指定したつもりのモデルで動いていない状態は、画面を見ないと分かりません。 実際に何で動いているかを、まず表示で確認してください。
そのうえで差が残るなら、同系列の別の世代を試します。Opus 系は代替が 3 つ示されているので、そこで調整できます。
コツ
「前のほうが良かった」という感想は、原因の特定より先に共有されがちです。切り分けの 3 点だけ先に配っておくと、感想が報告に変わります。
この種の廃止は今後も定期的に起きる
今回に限った話ではありません。モデルは世代交代が速く、古い世代は順次提供が終わります。 GitHub Copilot に限らず、Cursor でも Claude Code でも、他のツールでも同じ形の告知が繰り返されます。
そのたびに慌てないための構えは、2 つで足ります。
1 つは、モデル名を固定で書く箇所を減らしておく ことです。設定ファイルや手順書に直接書き込むほど、廃止のたびに書き換えが発生します。既定を使えるところは既定に任せ、指定するのは理由がある箇所だけにしておくと、影響範囲が小さくなります。
もう 1 つは、告知を見る係を決めておく ことです。changelog を全員が追う必要はありません。1 人が見て、影響がありそうなものだけを流す形で足ります。今回のような 1 か月の猶予は、見ていれば十分に間に合う長さです。
| 構え | 効果 |
|---|---|
| モデル名の固定を減らす | 廃止のたびの書き換えが減る |
| 告知を見る係を決める | 期日を過ぎてから気づく事故がなくなる |
| 移行の手順を残しておく | 次回は同じ手順をなぞるだけで済む |
3 行目が効いてきます。今回の移行でやったことを数行で残しておけば、次の廃止のときはそれをなぞるだけです。 毎回ゼロから調べ直している状態が、いちばん時間を使います。
期限のある変更をどう扱うか
この種の告知は、毎回同じ形で流れてきます。発表があり、1 か月ほどの猶予があり、期日に切り替わる。 今回は 7 月 31 日発表・9 月 1 日廃止なので、猶予はちょうど 1 か月です。
うまく回っているチームは、告知を見た時点で次の 3 つを決めています。
| 決めること | 内容 |
|---|---|
| 誰がやるか | 管理者側の設定変更の担当 |
| いつまでに | 期日の 1 週間前など、当日より前の日付 |
| 誰に伝えるか | 影響を受ける開発者と、手順書の管理者 |
3 番が抜けやすい部分です。設定だけ変えて周知しないと、モデルの選択肢が変わったことに気づかず「壊れた」と報告が上がってきます。 一言流しておくだけで、その問い合わせが消えます。
期日を決めるときは、当日ではなく前倒しにしてください。当日に作業する前提だと、その日に別の障害が起きた時点で押し出されます。
旧モデルを使い続けたい場合
「今のモデルで安定しているので変えたくない」という相談も受けます。結論から言うと、Copilot 上で使い続ける方法はありません。 廃止は提供側の決定なので、契約や設定で回避できる性質のものではありません。
どうしても特定の世代を使い続けたい事情があるなら、選択肢は次の 2 つです。
- Copilot 以外の経路で同じモデルを使う。API 経由や別のツールでは、提供状況が異なる場合があります
- その事情そのものを見直す。特定の世代でないと動かない仕組みを作っていること自体が、次の廃止でも同じ問題を起こします
実務では 2 番を勧めます。モデルの世代に依存した作りは、半年から 1 年でまた同じ話になります。 移行のたびにコストを払い続けるより、依存を薄くしておくほうが安く済みます。
期日までのチェックリスト
やることを並べておきます。上から順に消していけば終わります。
| # | 作業 | 担当 |
|---|---|---|
| 1 | 契約形態を確認する (個人 / 組織、年額 / 月額) | 管理者 |
| 2 | モデルポリシーで代替モデルを有効化する | 管理者 |
| 3 | 開発者 1 人に、選択肢へ出るか確認してもらう | 管理者 |
| 4 | リポジトリと手順書をモデル名で全文検索する | 開発者 |
| 5 | ヒットした箇所を代替モデル名に置き換える | 開発者 |
| 6 | 変更したことをチームへ一言流す | 管理者 |
| 7 | 9 月 1 日以降に、旧モデルが消えたことを確認する | 管理者 |
所要はどれも数分です。 唯一時間がかかるとすれば 4 番と 5 番ですが、モデル名を書いていないチームなら検索して終わりです。
7 番まで入れているのは、設定が効いていなかったことに後から気づく形を避けるため です。当日に確認しておけば、その場で直せます。
費用への影響
モデルが変わると請求が変わるのでは、という質問も受けます。GitHub Copilot は契約プランに紐づく提供なので、モデルが入れ替わっただけで契約の料金が変わるわけではありません。
ただし、プランによってはモデルごとに消費量の重みが異なる形が採られています。世代が上がることで、同じ作業でも消費のされ方が変わる可能性はあります。気にするなら、切り替えの前後 2 週間で利用量を見比べておくのが確実です。 事前に予測するより、実測のほうが早く答えが出ます。
社内で AI ツールの契約全体を見直したい場合は 法人向け生成 AI 契約プラン比較 2026 を参照してください。
移行のついでに見直すなら
モデルが変わるタイミングは、選定そのものを見直す機会 でもあります。惰性で同じモデルを指定し続けている状態は、意外と多く見ます。
見直しの観点は 2 つで足ります。
1 つは、そのモデルである理由を言えるか。速さで選んだのか、精度で選んだのか、単に最初に選んだままなのか。理由が言えないなら、既定に戻して構いません。
もう 1 つは、用途で分けているか。短い修正と、設計を伴う実装で、同じモデルを使う必要はありません。この観点は Claude Opus 5 と Sonnet 5 の使い分け に整理しています。Copilot でも考え方は同じです。
ツールそのものの選定に戻って考えたい場合は Claude Code・Cursor・GitHub Copilot を実務比較 を、Copilot を使い込む側の話は GitHub Copilot を実プロジェクトで使い倒す 6 つのポイント を参照してください。
まとめ
- 2026 年 9 月 1 日に 6 モデルが廃止される。予告は 7 月 31 日
- 代替は同系列の後継。使い方を変える必要はない
- Claude Sonnet 4.6 は、個人の年間プラン契約者に限り継続利用できる
- 管理者はモデルポリシーで代替モデルを有効化する。旧モデルの削除は不要
- 開発者はモデル名を固定している箇所だけ確認する。既定のままなら影響はほぼ無い
- 担当・期日・周知先の 3 つを、告知を見た時点で決めておく