Copilotのモデル廃止にどう備える？ポリシーAPIで移行を管理

公開日2026.10.21

約9分で読めます

※本ページのリンクにはプロモーションが含まれています。

廃止されたAIモデルを外しポリシーAPIで代替モデルを段階的に許可して開発環境へ展開するフラットな概念イラスト

GitHubは2026年10月19日、GitHub Copilotの多くの画面で6つのモデルを廃止しました。同じ日に、企業・組織・チーム・エージェントアプリごとのモデル利用可否をREST APIで取得・変更できる機能も一般提供しています。これは単なるモデル一覧の入れ替えではありません。コードレビュー、補完、エージェント実行、社内手順書などにモデル名や前提を固定している場合、移行と統制を同時に見直す機会です。

この記事では、GitHub Changelogのモデル廃止告知とCopilotモデルポリシーAPIの一般提供告知、GitHub Docsを一次資料として確認し、Web開発チームが何を棚卸しし、どの順番で切り替えるべきかを整理します。性能比較の実測記事ではなく、移行設計と運用判断の解説です。

何が変わったのか

GitHubが2026年10月19日に廃止したのは、Gemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5です。対象は「ほとんどのGitHub Copilot体験」とされ、Copilot Chat、インライン編集、Ask、Agentモード、コード補完が例示されています。廃止自体は9月18日に予告されていました。GitHubは、それぞれGemini 3.8 Flash、GPT-6.1 Sol、GPT-6 Luna、Grok 4.7などの代替候補を示しています。

ここで重要なのは、廃止済みモデルを削除する作業は不要でも、代替モデルを使える状態にする作業は別に残る点です。Copilot Enterpriseの管理者は、候補モデルがポリシーで許可されているかを確認する必要があります。モデルを許可すると、VS Codeやgithub.comのCopilot Chatのモデル選択に現れるとGitHubは説明しています。つまり、利用者側の選択肢と管理者側の許可は別々に確かめる必要があります。

モデル名を変えるだけでは不十分な理由

提供元が代替候補を示していても、旧モデルと新モデルが同じ出力になるとは限りません。生成コードの粒度、説明の長さ、ツールを使う回数、指示への追従、応答時間、課金上の扱いは変わり得ます。GitHubの告知は移行先を案内していますが、個々のリポジトリに対する同等性を保証するものではありません。したがって、変更前後で同じ課題を解かせ、受け入れ条件を満たすかを見る必要があります。

もう一つの落とし穴は、画面で選ぶモデルだけを確認して終わることです。IDEの個人設定、組織ポリシー、社内テンプレート、手順書、教育資料、チャットの保存済み指示、エージェントアプリの設定など、モデル名が登場する場所は複数あります。APIや自動化が直接モデル名を保持しているとは限りませんが、運用上の期待値として「このモデルを選ぶ」と固定していれば、選択不能になった時点で手順が破綻します。

同日に一般提供されたポリシーAPI

GitHubは同日、CopilotのモデルポリシーをGETとPATCHで扱うREST APIを一般提供しました。対象は企業全体、Enterprise Teams、エージェントアプリ、組織の4階層です。公開された主な経路は次のとおりです。

GET/PATCH /enterprises/{enterprise}/copilot/model-policies
GET/PATCH /enterprises/{enterprise}/teams/{team_id}/copilot/model-policies
GET/PATCH /enterprises/{enterprise}/copilot/apps/model-policies
GET/PATCH /orgs/{org}/copilot/model-policies

変更告知ではEnterprise Teamsの例にteam_slugが記載されていますが、現行のGitHub REST APIのAI controlsリファレンスではteam_idを使う経路が示されています。実装時はブログの短い概要だけでパスを固定せず、利用時点のAPIリファレンスを正としてください。APIバージョンヘッダーや権限も含めて確認する必要があります。

読み取りにはEnterprise AI controlsのread権限、更新にはwrite権限が必要です。クラシックPATの場合、読み取りはread:enterprise、更新はadmin:enterpriseが必要とされています。更新権限は広いため、棚卸し用の読み取りと変更用の実行主体を分ける設計が妥当です。本サイトの提案としては、日常監視は読み取り専用、変更はレビュー済みのワークフローに限定し、トークンを共用しない運用を勧めます。

ポリシーは単純なオンとオフではない

GitHub Docsのモデル利用可否管理によると、企業では全員に有効、全員に無効、組織やEnterprise Teams・アプリへの委任という段階があります。組織単位で管理する既定方式と、Enterprise Teamsで細かく制御するプレビュー方式では、設定の意味が異なります。

Enterprise Teams方式では設定は加算的です。企業で無効にしたモデルをチーム側で有効にはできず、企業で有効にしたモデルはチームでも有効になります。チームは企業の基準に追加のモデルを与えられ、複数チームに所属する利用者は、それぞれで許可されたモデルの和集合を受け取ります。このため「あるチームで許可を外したから利用不能」とは限りません。所属関係を含めて判定しないと、想定外のモデルが残ります。

さらにAPIの応答は、個々の利用者が最終的にモデルを使えるかどうかを直接保証するものではありません。ドキュメントも、ポリシー状態は最終的なアクセス判定ではないと明記しています。企業ポリシー、チームやアプリの設定、個人の契約や利用画面などが重なるためです。API監視だけで完了とせず、代表利用者の画面でも確認する必要があります。

まず作るべき棚卸し表

切り替え前に、モデル名ではなく「用途」を軸に棚卸しします。モデル廃止のたびに手順を作り直さないためです。最低限、次の項目を1行にまとめると判断しやすくなります。

利用場面：コード補完、Chat、Ask、Agent、レビュー支援など
対象リポジトリと技術スタック：PHP、JavaScript、IaC、CMSなど
現在の推奨モデルと代替候補
品質条件：テスト成功、静的解析、変更行数、説明の十分さ
速度と費用の上限
モデルを許可する範囲：全社、組織、チーム、エージェントアプリ
責任者、検証日、ロールバック条件

たとえば「WordPressの小規模修正」と「複数サービスにまたがる移行」では、必要な推論量や確認工程が違います。すべてを高性能モデルへ寄せると費用と待ち時間が増え、軽量モデルだけに寄せると複雑な変更の手戻りが増える可能性があります。用途ごとに基準モデルと例外を決める方が、廃止後の移行を小さくできます。

移行を4段階に分ける

1 影響範囲を読む

まず管理画面とGET APIで現在の許可状態を保存し、廃止モデルを前提にした手順やテンプレートを検索します。IDEのモデル選択だけでなく、オンボーディング資料や社内Wikiも対象です。GitHubが廃止対象として挙げた画面を起点に、誰がどの用途で使っていたかを確認します。

2 代替モデルを小さく試す

代表的なリポジトリで、過去に完了した課題を再現用の入力にします。新規実装、バグ修正、テスト追加、リファクタリングなどを混ぜ、生成結果そのものではなく、テスト・静的解析・レビュー指摘・作業時間で比較します。提供元の推奨代替は出発点であり、採用決定ではありません。

3 ポリシーを段階的に変更する

企業全体で一気に許可するより、組織またはチーム単位で対象を限定し、利用者とエージェントアプリを分けて試します。PATCHの前後にGET結果を保存し、変更対象のモデル名、以前の状態、新しい状態、実行者、承認記録を残します。422や403を成功として扱わず、応答と再取得結果の両方を確認します。

4 実利用を確認してから標準化する

ポリシー反映後は、代表利用者のVS Codeとgithub.comでモデルが選べるかを確認します。さらに、補完・Chat・Agentなど実際に使う面で期待したモデルが利用できるかを見ます。問題がなければ社内標準を更新し、旧モデル名を資料から削除します。問題があれば、旧モデルへ戻すのではなく、別の対応モデルか用途別の設定を検討します。すでに廃止されたモデルは恒久的な退避先になりません。

自動化するときの安全策

ポリシーAPIを設定管理に組み込む場合、目標状態をコードに置くだけでは不十分です。GitHub側で新モデルが追加されたときの既定可否、委任方式の切り替え、複数チーム所属による和集合を考慮します。未構成の一般提供モデルはDefault availabilityの影響を受けるため、新モデルを自動的に全員へ許可したくない組織は、この既定値も監視対象にします。

GET結果を定期保存し、意図した設定との差分だけを通知する
PATCHは承認後に実行し、変更後に再度GETして一致を検証する
モデル表示名ではなくAPIのmodel_nameを記録する
新しい未知のモデルを自動許可しない
チームとエージェントアプリを別々に監査する
権限の広い更新トークンをCIの通常ジョブへ置かない

これはGitHubが示す機能を前提にした本サイトの運用提案です。実際の権限設計は、契約プラン、Enterpriseの構成、組織とチームの管理方式に合わせて調整してください。特にEnterprise Teamsによるモデル管理はプレビューとされているため、本番の基準にする前に仕様変更とロールバック時の状態を確認します。

費用と性能をどう評価するか

モデルの世代が上がっても、すべての作業で費用対効果が上がるとは限りません。短い補完では応答速度、広い変更では完遂率、レビューでは誤検出と見逃しが重要です。Copilot上の具体的な利用条件や課金はプランや時点で変わり得るため、この記事では単価を固定して比較しません。管理画面と契約資料を確認し、実際の利用量で評価してください。

評価用の課題は、成功した例だけでなく失敗しやすい例も残します。存在しないAPIを作る、必要以上に広い変更を行う、テストを弱めて通す、依存関係を不用意に増やすといった失敗を検出できるかが重要です。モデル移行はベンチマークの順位を追う作業ではなく、自社の受け入れ条件に適合するかを確認する作業です。

今回の変更から得られる教訓

今回の発表では、モデル廃止と管理APIの一般提供が同日に重なりました。利用者には代替モデルへの移行が必要になり、管理者にはそのモデルを誰へ許可するかを機械的に確認する手段が増えています。両方を別々の作業として扱うと、モデルは許可したが品質確認がない、品質確認は済んだが利用者に見えない、といったずれが起きます。

まず用途別の棚卸しを作り、代表課題で代替候補を検証し、ポリシーを限定範囲へ適用し、画面とAPIの両方で確認する。この順番なら、次のモデル廃止でも同じ枠組みを再利用できます。特定モデルへの依存をゼロにはできませんが、依存箇所と判断基準を見える形にしておけば、突然の選択肢変更を運用停止へ直結させずに済みます。