AIモデルの切替で仕事を止めないCopilot変更前の確認手順

GitHubが示した代替候補は次の通りです。1

これは同じ出力を保証する対応表ではありません。モデルを変えれば、コードの差分、説明量、ツールの使い方、待ち時間が変わる可能性があります。代表タスクを切替前後で残す理由は、代替候補が使えることと、仕事の結果が同じことを分けるためです。

対応表は一度で終わらない場合もあります。Raptor Miniの代替候補とされたMAI-Code-1-Flash自体が、2026年9月10日にすべてのCopilot利用面で廃止され、MAI-Code-1.1-Flashへの移行が案内されました。5 2026年7月末の案内どおりに置き換えたチームは、9日後にもう一度同じ移行作業をすることになります。移行先を決めるときは、そのモデルの廃止予定も合わせて確認します。

Enterpriseの管理者は、代替モデルへのアクセスをモデルポリシーで有効にする必要がある場合があります。GitHubは、個人のCopilot設定で利用可否を確認し、VS CodeやGitHub.comのモデル選択肢に現れることを確認する手順を案内しています。1

2026年8月26日から9月1日にかけて、GitHubはBusinessとEnterpriseへGlobal model policyを展開中です。これまで設定していなかったモデルはDelegate to default policyへ移り、既定ポリシーが有効なら利用者に提供されます。2

明示的に有効または無効へ設定した選択は維持されます。一方、委任は動的な状態です。管理者が既定値を変えると、委任しているモデルもその変更に従います。オープンウェイトモデルやデータ保持契約の対象外モデルには例外があります。2

設定を監査するときは、単に「有効か無効か」ではなく、次の四状態を区別します。

GitHubの日本語ドキュメントでも、未構成モデルの既定可用性はポリシーが制御するとされています。3

Copilotの自動モデル選択は、タスクの複雑さ、システムの正常性と可用性、プラン、管理者ポリシーに応じてモデルを選ぶ仕組みです。利用可能なモデルは時間とともに変わり得ます。4

つまり、依頼文にモデル名がなければ影響がないとは言えません。昨日と同じAutoでも、今日の実行では別のモデルへ送られる場合があります。

使われたモデルは、応答ごとに確認できます。確認する場所は利用面ごとに異なります。4

自動選択を使う代表タスクでは、入力と出力だけでなく、この方法で確認したモデル名も一緒に残します。

実験では、架空のCopilot利用記録8件を作りました。実際のCopilot、IDE、コードリポジトリには接続していません。

内訳は、モデル名の明示指定5件、自動選択2件、既定ポリシーへの委任1件です。明示指定のうち4件は廃止予定、1件は継続するモデル。自動と委任には、直近に観測したモデル名を付けました。

二つの監査を比べます。

1. 名前だけの監査。設定名または直近モデルが廃止予定リストに一致するか調べる。
2. 選択経路の監査。明示指定、自動選択、既定へ委任を分け、必要な作業を変える。

選択経路の監査では、明示された廃止モデルは代替候補へ変更します。自動選択は実行時モデルを記録して代表タスクを再実行。委任は管理者の既定ポリシーを確認してから再実行します。

名前だけの監査は8件中6件を検出しました。廃止予定モデルが文字列として残っていたからです。

選択経路まで見ると、作業が必要な記録は7件でした。

名前検索が見落とした1件は、直近に継続モデルを使っていた自動選択でした。廃止予定名はなくても、自動選択で利用できるモデル集合は変わり得るため、代表タスクの基準記録が要ります。

反対に、名前検索が拾った自動選択や委任を、すべて「モデル名を置き換える」と扱うべきではありません。選ぶ主体がCopilotや管理者ポリシーなら、利用者の作業は設定変更ではなく、実行時モデルの記録と再検証です。

この比較で扱ったのは模擬設定の分類だけです。廃止前後のモデル品質、速度、コード正解率は測っていません。

チームで使う表は、次の四列から始めます。

利用面には、Chat、インライン編集、agent mode、CLI、コード補完など、実際に仕事で使う入口を書きます。モデル名が空欄なら終わりではなく、自動か委任かの確定が必要です。

代表タスクは三つほどで十分です。短いコード補完、複数ファイルの変更、失敗したテストの説明など、チームの普段の仕事から選びます。公開前の機密コードを外部へ持ち出さず、普段のCopilot利用範囲と組織ポリシー内に限定します。

モデルの比較を一つの点数だけで表すと、違いの場所が分かりません。代表タスクごとに次を残します。

コードが動いても、不要なファイルを変えた案は採用外です。説明が長くなっても、原因特定が速ければ仕事には役立ちます。チームごとの採用条件は、切替前に言葉へ直しておきます。

変更後に悪化が見つかったら、すぐ別モデルへ移すか、タスクごとにモデルを分けるか、依頼文を直すかの判断が必要です。一度に全部変えず、まずモデルだけを変えた結果を残せば原因を追いやすくなります。

ここからは筆者の見立てです。モデルが短い周期で追加・廃止され、自動選択も広がると、開発者の役割は「一番良いモデルを選ぶ人」だけではなくなります。

新しく増えるのは、どの仕事がどの選択経路を通り、実行時に何が使われ、切替後に何が変わったかを追う仕事です。管理者もモデルを許可するだけでなく、明示設定と委任を区別し、代替候補を代表タスクで確かめる必要があります。

GitHubが示した代替候補は移行の出発点です。チームの完了条件は、利用可能になったことではなく、代表タスクが止まらず、テストと人の確認を通ったことに置きます。

次の廃止日はすでに決まっています。2026年9月10日のMAI-Code-1-Flashです。2026年9月1日の廃止当日に最初にすることは、リポジトリ全体のモデル名を置換することではありません。利用面、選択方法、現在のモデルまたは委任先、代表タスクの四列を一行埋めることです。その一行を作っておけば、次の廃止案内が来たときも、直接置換する設定、自動選択で記録する実行、管理者へ確認する委任を同じ手順で分けられます。