GitHubの「GPT-5.2 and GPT-5.2-Codex deprecated」は、GitHub CopilotでGPT-5.2系モデルを使っている管理者・開発者が、代替モデルへ切り替えるべき変更です。結論から言うと、GPT-5.2はGPT-5.5へ、GPT-5.2-CodexはGPT-5.3-Codexへ移行するのが基本方針です。GitHubは2026年6月5日付のChangelogで、Copilot Chat、inline edits、ask mode、agent mode、code completionsなど、多くのCopilot体験で両モデルを非推奨にしたと案内しています。なお、GPT-5.2はCopilot code reviewの一部としては引き続き利用可能とされています。(The GitHub Blog)
特に注意したいのは、「非推奨だから何もしなくてよい」ではない点です。GitHubは deprecated models を削除するための作業は不要としていますが、ワークフローや連携でモデル名を固定している場合は、サポート対象モデルへ更新する必要があります。Copilot Enterpriseの管理者は、代替モデルがモデルポリシーで有効になっているかも確認しましょう。(The GitHub Blog)
何が変わったのか
今回の変更は、GitHub Copilotで利用できるAIモデルの入れ替えです。公式Changelogでは、以下の2モデルが2026年6月5日に非推奨化されたと案内されています。(The GitHub Blog)
| 対象モデル | 変更内容 | 推奨される代替モデル | 主な確認ポイント |
|---|---|---|---|
| GPT-5.2 | 多くのCopilot体験で非推奨 | GPT-5.5 | Chat、inline edits、ask mode、agent mode、code completionsで固定利用していないか |
| GPT-5.2-Codex | 多くのCopilot体験で非推奨 | GPT-5.3-Codex | コーディング支援、エージェント、開発ワークフローで固定利用していないか |
GitHub Docsのサポートモデル一覧では、GPT-5.5とGPT-5.3-CodexはいずれもGAとして掲載されています。一方で、モデルの利用可否はCopilotプラン、利用クライアント、組織・Enterpriseのモデル制限によって変わるため、単に「新しいモデルが存在する」だけでは利用できるとは限りません。(GitHub Docs)
「deprecated」は実務上どう受け止めるべきか
deprecatedは、日本語では「非推奨」と訳されることが多いですが、実務では「今後使い続ける前提にしない」という意味で受け止めるのが安全です。
今回のGitHub Copilotの変更では、旧モデルを利用者側で削除する作業は不要です。ただし、以下のようなケースでは影響が出る可能性があります。
| 利用状況 | 起こり得る影響 | 対応の考え方 |
|---|---|---|
| 開発者がCopilot ChatでGPT-5.2を選んでいた | モデル選択肢に表示されない、または別モデルへの切り替えが必要になる | GPT-5.5など利用可能な代替モデルに切り替える |
| inline suggestionsやcode completionsで旧モデルを指定していた | 補完モデルの設定が意図どおり動かない可能性がある | 補完モデル設定を確認し、サポート対象モデルへ変更する |
| 社内ドキュメントやオンボーディング資料に旧モデル名が残っている | 新規メンバーが選べないモデルを設定しようとする | 手順書・FAQ・研修資料を更新する |
| 自動化スクリプトや連携でモデル名を固定している | 実行エラー、フォールバック、出力品質の変化が起きる可能性がある | 固定値を検索し、推奨代替モデルへ置換する |
| Copilot Enterpriseでモデルポリシーを使っている | 代替モデルが許可されておらず、利用者の画面に表示されない | 管理画面でGPT-5.5やGPT-5.3-Codexの可用性を確認する |
ポイントは、Copilotの画面でモデルを選ぶ利用者だけでなく、組織のポリシー、IDE拡張、社内標準、CI/CDや開発支援ツールの設定まで確認することです。
影響範囲：Copilot Chatだけではない
公式Changelogでは、対象範囲としてCopilot Chat、inline edits、ask mode、agent mode、code completionsが挙げられています。つまり、チャットだけを確認して終わりにすると見落としが出ます。(The GitHub Blog)
確認すべきCopilot体験
| 領域 | 確認すること | 見落としやすい点 |
|---|---|---|
| Copilot Chat | モデルセレクターに旧モデルが残っていないか、代替モデルを選べるか | Chatのモデル変更はinline suggestionsには反映されない |
| inline edits | 編集支援で旧モデル前提の説明や手順がないか | チーム内の使い方案内に旧モデル名が残りやすい |
| ask mode | 質問・調査用プロンプトでモデル名を固定していないか | 「このモデルで聞く」といった社内Tipsが古くなる |
| agent mode | エージェント実行時のモデル指定や期待結果を確認する | 大きなリファクタリングや複数ファイル変更で挙動差が出やすい |
| code completions | 補完モデルの設定を確認する | Chat側だけ変更して補完側を忘れやすい |
| Copilot code review | GPT-5.2が一部で利用可能とされている点を理解する | 「完全に使えない」と誤解しない |
Copilot Chatのモデル変更は、inline suggestionsで使われるモデルには影響しないとGitHub Docsに明記されています。Chatと補完は別々に確認する必要があります。(GitHub Docs)
管理者が最初に確認すべき設定
GitHub Copilotを組織やEnterpriseで管理している場合、最初に見るべきなのはモデルポリシーです。GitHub Docsでは、CopilotモデルへのアクセスはCopilotプラン、利用クライアント、組織またはEnterpriseによるモデル制限に依存すると説明されています。(GitHub Docs)
Enterprise管理者の確認ポイント
Enterprise ownerは、Enterprise内の各Organizationで利用できるデフォルトCopilotモデルを管理できます。管理画面では、モデルを全Organizationで有効にするか、Organization側で選択可能にするかを設定できます。(GitHub Docs)
| 確認項目 | 判断基準 |
|---|---|
| GPT-5.5が利用可能か | GPT-5.2の代替として、対象Organizationで有効または選択可能になっているか |
| GPT-5.3-Codexが利用可能か | GPT-5.2-Codexの代替として、開発チームが使える状態か |
| Targeted model rulesを使っているか | 特定Organizationだけモデルが許可・制限されていないか |
| Copilot Chatのモデルセレクターに表示されるか | GitHub.comやVS Codeで利用者視点の確認ができているか |
| 古いモデルが社内標準に残っていないか | 手順書、テンプレート、開発ガイドラインを更新したか |
GitHubは、代替モデルへのアクセスを有効にしたあと、個人のCopilot設定やVS Code・github.com上のCopilot Chatモデルセレクターで表示を確認するよう案内しています。(The GitHub Blog)
Organization管理者の確認ポイント
Organization ownerは、Enterprise側でモデルがOptionalに設定されている場合、自Organizationでモデルを有効または無効にできます。GitHub Docsでは、OrganizationのSettingsからCopilot、Modelsへ進み、モデルごとにEnabledまたはDisabledを選択する流れが案内されています。(GitHub Docs)
Enterprise配下のOrganizationでは、Enterprise ownerが強制した設定はOrganization側で変更できません。モデル一覧にロックされた状態でEnabledまたはDisabledが表示される場合は、Organization管理者ではなくEnterprise管理者に確認が必要です。(GitHub Docs)
開発者が確認すべき移行作業
開発者側では、まず「旧モデル名をどこかで固定していないか」を探すのが現実的です。IDEの画面でモデルを選んでいるだけなら切り替えで済むことが多いですが、リポジトリ内の設定ファイル、社内ツール、ドキュメント、プロンプト集に旧モデル名が残っていることがあります。
リポジトリ内を検索する
以下のように、モデル名の表記ゆれを含めて検索します。
rg -n "GPT-5\.2|GPT-5\.2-Codex|gpt-5\.2|gpt-5\.2-codex" .検索対象には、コードだけでなく次のファイルも含めます。
| 対象 | 例 |
|---|---|
| 設定ファイル | JSON、YAML、TOML、環境変数テンプレート |
| 開発ドキュメント | README、CONTRIBUTING、オンボーディング資料 |
| プロンプト集 | .md、社内Wiki、Issueテンプレート |
| 自動化スクリプト | GitHub Actions、CLI実行スクリプト、社内Bot |
| IDE設定 | VS Code workspace settings、JetBrains設定手順 |
旧モデル名が見つかったら、GPT-5.2はGPT-5.5へ、GPT-5.2-CodexはGPT-5.3-Codexへ置き換えるのが基本です。ただし、すべてを機械的に置換するのではなく、用途別に動作確認を行いましょう。
代替モデルへの置き換え基準
| 旧モデル | 推奨代替 | 向いている移行先の考え方 | 重点的に検証すること |
|---|---|---|---|
| GPT-5.2 | GPT-5.5 | 汎用的なChat、設計相談、レビュー補助、説明生成 | 回答の粒度、既存プロンプトとの相性、コスト感 |
| GPT-5.2-Codex | GPT-5.3-Codex | コード生成、修正、エージェント的な開発作業 | 差分の正確性、テスト通過率、不要な変更の有無 |
Copilotのモデルは、それぞれ速度、推論、精度、コーディング適性などの強みが異なります。GitHub Docsでも、モデルには異なる強みがあり、プランや利用場所によってアクセスできるモデルが変わると説明されています。(GitHub Docs)
実務では、モデルを切り替えた直後に「以前と同じ回答をするか」だけを見るのでは不十分です。以下のように、開発フローに近い観点で検証すると失敗を防げます。
| 検証観点 | 確認例 |
|---|---|
| コード生成 | 既存のコーディング規約に沿った関数・クラスを生成できるか |
| 修正提案 | 不具合修正時に不要なリファクタリングを混ぜないか |
| テスト | 生成したテストが実行可能で、過剰なモックに依存していないか |
| セキュリティ | 認証、権限、入力検証まわりで危険な提案がないか |
| 日本語の説明 | チームのドキュメント品質に合う説明が出るか |
| 長いコンテキスト | 大きな差分や複数ファイルの作業で破綻しないか |
Copilot Chatと補完モデルは別々に確認する
開発者が特に間違えやすいのが、Copilot Chatでモデルを切り替えたあとに「補完も同じモデルになった」と思い込むことです。GitHub Docsでは、Copilot Chatで使うモデルの変更は、Copilot inline suggestionsで使うモデルには影響しないと説明されています。(GitHub Docs)
VS Codeでinline suggestionsのモデルを変更する場合は、コマンドパレットからGitHub Copilot: Change Completions Modelを選び、利用するモデルを選択します。現在の補完モデルはSettingsでcopilot completionを検索し、GitHub > Copilot: Selected Completion Modelから確認できます。(GitHub Docs)
VS Code利用者に伝えるべきこと
- Chatのモデル変更と補完モデルの変更は別物
- モデルが表示されない場合は、組織ポリシーと拡張機能のバージョンを確認する
- Auto model selectionを使っている場合、モデルポリシーで許可された範囲から選ばれる
- 既存チャットセッションでは切り替えが反映されにくい場合があるため、新しいセッションで確認する
IDEや拡張機能の更新も忘れない
モデル移行で地味に多い失敗が、管理画面では許可されているのに、開発者のIDE上にモデルが出てこないケースです。GitHub Docsでは、最近のモデルにはIDEやCopilot拡張・プラグインの最小バージョンが必要な場合があり、最新版に更新することが推奨されています。(GitHub Docs)
公式ドキュメント上では、GPT-5.3-CodexやGPT-5.5にもクライアントごとの最小バージョンが掲載されています。たとえばGPT-5.5は、VS Code、Visual Studio、JetBrains IDEs、Xcode、Eclipseなどで最小バージョンの記載があります。これらは今後変わる可能性があるため、社内手順書に固定値を書く場合は「公式ドキュメント確認日」を併記しておくと安全です。(GitHub Docs)
費用・利用量の確認も移行作業に含める
モデルの切り替えは、出力品質だけでなく利用コストにも影響する場合があります。GitHub Docsでは、Copilotの利用は入力トークン、出力トークン、キャッシュされたトークンを消費し、モデルと消費トークン数によってAI creditsに換算されると説明されています。(GitHub Docs)
一方、code completionsとnext edit suggestionsはAI creditsでは課金されず、有料Copilotプランでは従来のカウント方式のまま無制限とされています。(GitHub Docs)
そのため、移行時は以下を分けて見ます。
| 項目 | 確認すること |
|---|---|
| Copilot Chat | 代替モデルの利用でAI credits消費が大きく変わらないか |
| agent mode | 長いコンテキストや複数ファイル変更で利用量が増えないか |
| code review | AI creditsとGitHub Actions minutesの両方に注意する |
| code completions | AI credits対象外だが、補完モデル設定は別途確認する |
| チーム単位の利用 | 特定チームだけ新モデル利用が集中していないか |
移行直後は、いきなり全員に新しい運用を広げるより、代表的な数チームで1〜2週間程度の利用傾向を見てから展開するほうが安全です。
移行の進め方
現状を棚卸しする
まず、どこでGPT-5.2やGPT-5.2-Codexを使っているかを洗い出します。対象はGitHub.com、VS Code、Visual Studio、JetBrains IDEs、Xcode、Eclipse、Copilot CLI、社内の開発支援ツールです。
管理者はモデルポリシー、開発者はリポジトリとIDE設定を確認します。社内ドキュメントやプロンプト集にモデル名が残っている場合も、利用者の混乱につながるため更新対象です。
代替モデルを有効化する
EnterpriseまたはOrganizationの管理者は、GPT-5.5とGPT-5.3-Codexが対象チームで利用可能か確認します。モデルがOptional扱いになっている場合は、Organization側でEnabledにする必要があります。(GitHub Docs)
小さく検証する
いきなり全社展開せず、次のような代表ケースで確認します。
| 検証ケース | 合格基準 |
|---|---|
| 小さなバグ修正 | 既存テストが通り、余計な変更が少ない |
| 新規テスト生成 | テストが実行可能で、保守しやすい |
| 既存コードの説明 | ドメイン用語を大きく誤解しない |
| PRレビュー補助 | セキュリティや設計上の懸念を過不足なく指摘する |
| 大きめのリファクタリング | 変更範囲を説明でき、レビューしやすい差分になる |
利用者へ短く周知する
周知文は長くしすぎないほうが読まれます。以下の内容を入れれば十分です。
| 周知項目 | 伝える内容 |
|---|---|
| 変更内容 | GPT-5.2とGPT-5.2-Codexが多くのCopilot体験で非推奨になった |
| 移行先 | GPT-5.2はGPT-5.5、GPT-5.2-CodexはGPT-5.3-Codexを使う |
| 利用者の操作 | Chatと補完モデルをそれぞれ確認する |
| 困った時 | モデルが出ない場合は、IDE更新と管理者ポリシーを確認する |
| 注意点 | Copilot code reviewではGPT-5.2が一部利用可能とされているため、混同しない |
よくある失敗と対策
旧モデルを削除しようとして時間を使う
GitHubは、非推奨モデルを削除するための対応は不要としています。管理者がやるべきことは削除作業ではなく、代替モデルの利用可否を確認し、利用者が移行できる状態を作ることです。(The GitHub Blog)
管理画面だけ確認して、開発者の画面を見ない
モデルポリシー上は有効でも、IDEや拡張機能が古い、対象プランが違う、Organizationで無効になっている、といった理由で利用者の画面に出ないことがあります。最後は実際の利用者アカウントで、GitHub.comとVS Codeなど主要クライアントのモデルセレクターを確認しましょう。
Chatだけ切り替えて補完を放置する
Copilot Chatとinline suggestionsは別設定です。ChatでGPT-5.5を選んでも、補完モデルが自動で同じになるわけではありません。補完品質に関する問い合わせが増えた場合は、まず補完モデルの設定と拡張機能のバージョンを確認します。(GitHub Docs)
Copilot Extensionsの影響を見落とす
GitHub Docsでは、Copilot Extensionsを使っている場合、選択したモデルが上書きされる可能性があると案内されています。拡張機能や社内プラグインを使っているチームでは、「モデルセレクターで選んだモデル」と「実際の応答に使われるモデル」が一致するかを確認してください。(GitHub Docs)
出力の違いを「劣化」と即断する
モデル移行後は、回答の文体、コードの分割粒度、テストの書き方が変わることがあります。すぐに劣化と判断せず、チームの基準に照らして評価しましょう。たとえば、生成コードの行数が増えても、可読性やレビューしやすさが上がっているなら許容できる場合があります。
管理者・開発者別チェックリスト
| 立場 | すぐ確認すること | 完了の目安 |
|---|---|---|
| Enterprise管理者 | GPT-5.5とGPT-5.3-Codexを対象Organizationで利用できるか | モデルセレクターに表示され、対象チームで選択できる |
| Organization管理者 | Enterprise側でOptionalになっているモデルをEnabledにする | Organizationメンバーが代替モデルを利用できる |
| 開発リーダー | リポジトリ、プロンプト、ドキュメントの旧モデル名を検索する | 旧モデル名が残る箇所を修正または注記できている |
| 開発者 | Chatとinline suggestionsのモデル設定を別々に確認する | 日常作業で推奨代替モデルを使える |
| セキュリティ担当 | 生成コードやレビュー補助の品質を確認する | 認証・権限・入力検証まわりで危険な提案がない |
| FinOps・管理部門 | AI creditsやActions minutesの変化を見る | 移行後の利用量に異常な増加がない |
まとめ：次にやるべきこと
今回の「GPT-5.2 and GPT-5.2-Codex deprecated」は、GitHub Copilotの利用モデルを新しいサポート対象モデルへ移すための変更です。最優先でやることは、GPT-5.2をGPT-5.5へ、GPT-5.2-CodexをGPT-5.3-Codexへ移行できる状態にすることです。
管理者は、Copilotのモデルポリシーで代替モデルが有効か確認してください。開発者は、Chat、補完、エージェント、社内スクリプト、ドキュメントに旧モデル名が残っていないかを確認しましょう。
最後に、移行後の検証では「モデルが選べるか」だけでなく、生成コードの品質、テスト通過率、レビューしやすさ、AI creditsの消費まで見るのが実務的です。単なるモデル名の置き換えで終わらせず、チームの開発フローに合わせて小さく検証してから展開することが、今回の変更を安全に乗り切る近道です。
コメント