古いAIに任せたままでは、品質も統一も守れません。GitHubは、Copilot Enterpriseで利用されてきたClaude Opus 4.1とGPT-5などの旧モデルを廃止し、後継のClaude Opus 4.6とGPT-5.2系へ切り替える方針を示しました。自動では移行されず、管理者が有効化手続きを行う必要があります。AnthropicとOpenAIのモデルが併存する構成は維持されます。設定が遅れると、チーム内で提案結果が分断される恐れがあります。対応の優先度を明確にする局面です。
廃止と後継、手続きと影響範囲。管理画面での有効化、VS CodeとGitHub.comの両面対応が鍵
GitHubは、三つの旧モデルを終了対象としました。対象はClaude Opus 4.1、GPT-5、GPT-5-Codexです。推奨標準として提示されたのはClaude Opus 4.6、GPT-5.2、GPT-5.2-Codexです。Copilot Enterpriseでは、管理者が新モデルを手動で有効化しない限り、自動切り替えは行われません。切り替えは、管理ダッシュボードに加え、VS CodeとGitHub.comの両方での設定が必要になります。移行期は複数モデルが並存し、プロジェクトや個人ごとに出力が揺れる可能性があります。
GitHubはAnthropicとOpenAIの両系統を運用しており、単一事業者への依存は回避されています。一方で、モデル選択はプラットフォーム側の方針に従う形となり、ベンダー制御の影響を受けます。廃止対象モデルは即時削除されない旨が示されており、アクセスが残る環境では監査や統制が煩雑化する懸念があります。サポート終了時期は明確化されていません。互換性やパフォーマンスが変動する可能性も指摘され、品質や速度、扱える情報量の差分を把握する取り組みが必要です。
移行にあたっては、モデル選択の標準化とテストの厳格化が求められます。まず、現在どのモデルが使われているかを管理者が確認します。続いて、小規模なテストグループで新旧モデルを比較し、コード提案のパターン、応答速度、誤り傾向を記録します。MCPやClaude Codeを利用する場合は、API互換性とモデルバージョンの統一をチェックします。ベースラインを作成し、全体展開の前にルールを更新します。最後に、社内で旧モデル利用の期限を定め、設定のドリフトを防止します。
今回の変更は、企業にとって「自動アップグレード」ではありません。管理者の明示的な判断と設定が要件となります。モデルの廃止により、意思決定はGitHubのロードマップに引き寄せられますが、複数ベンダーのモデルを併用する構造が残るため、完全なロックインは回避されています。とはいえ、切り替えの設計と監査の負荷は増大します。運用側は、対象機能、利用者、環境ごとの設定と挙動を紐づけて管理し、監査証跡の整備に努める必要があります。
Copilot Enterpriseのチームにとって重要なのは、設定の統一と運用モニタリングです。新モデルの有効化が進まないと、同じ質問に対して異なる回答が生まれ、レビューや品質保証が混乱します。ダッシュボードでの可視化とルール化により、ばらつきを抑えられます。新設計のClaude Opus 4.6では、提案品質や応答速度が変わる可能性があります。重要なコードやセキュリティ関連では、生成結果の再検証が欠かせません。展開後の測定も併走させ、改善の起点を明確にします。
見解として、モデル移行をインフラ変更と同等に扱い、段階展開と計測を前提とした運用設計が有効です。アクセスが残る旧モデルは統制対象として扱い、期限と監査でリスクを最小化すべきです。
詳しくは「GitHub」の公式ページまで。 レポート／DXマガジン編集部
