開発ツール
Copilotのモデル入れ替えは、開発AIをポートフォリオで使う時代を示す
GitHubはKimi K2.7 CodeをCopilotで一般提供し、Gemini 2.5 ProとGemini 3 Flashの廃止予定も示しました。さらにGitHub Modelsは7月30日に完全終了予定です。これらをまとめると、開発AIは単一モデルに固定するものではなく、モデルの追加、廃止、価格、ポリシーを運用するものになっています。
この記事で押さえること
- Copilotは複数モデルを選べる開発AIプラットフォームとして動いています。
- モデル廃止は、プロンプト、評価、社内手順の見直しを伴う運用イベントです。
- 管理者はモデル許可リストと代替モデルを定期的に確認する必要があります。
今回の核心: モデルは「採用して終わり」ではない
Kimi K2.7 Codeは、Copilotのモデルピッカーで選べるオープンウェイト系モデルとして紹介されています。一方で、Gemini 2.5 ProとGemini 3 Flashは7月末にCopilot上で廃止予定です。さらにGitHub Modelsのプレイグラウンドや推論APIも7月30日に終了します。
この動きは、開発AIの現場に重要な前提を突きつけます。モデルは永続的な部品ではなく、追加、値下げ、廃止、置き換えが起きるサービス構成要素です。社内標準モデルを決めたら終わりではなく、モデル更新に合わせて検証を回す必要があります。
図解: 開発AIモデル運用のサイクル
実務で見るべき点
まず、社内で使っているCopilotモデルを棚卸しします。ドキュメント、研修資料、プロンプト例、CIの自動処理に特定モデル名が書かれている場合、廃止予定に合わせた更新が必要です。
次に、モデルごとの料金と利用制限を確認します。安いモデルを標準にし、高難度タスクだけ高性能モデルへ切り替える運用は現実的ですが、品質差を測らずに一括変更すると開発体験が悪化します。
まとめ
Copilotのモデル入れ替えは、開発AIが「1つの賢い相棒」ではなく、複数モデルを束ねる業務基盤になったことを示しています。企業は、モデル選択を個人任せにせず、更新カレンダー、許可ポリシー、評価手順を持つべきです。