GitHub Copilot Chatをgithub.com上で使っている場合、今回の「Updates to available models in Copilot on web」で最初に確認すべき点は、Web版Copilot Chatで選べるAIモデルが絞り込まれたことです。特に、Gemini系モデルや一部のOpenAI系モデルを前提にプロンプト運用、検証、社内手順を作っていたチームは、モデル選択・利用ポリシー・コスト管理の見直しが必要です。
GitHubの公式Changelogでは、Copilot Chat on the webでより一貫した高品質な応答を提供するため、github.com上で利用できるモデル一覧を制限すると説明されています。Geminiモデル全般と、GPT-5.2 Codex、GPT-5.4 nanoなど一部モデルがWeb版Copilot Chatから削除され、OpenAIおよびClaudeのモデルは各Copilotプランで引き続き利用可能とされています。(The GitHub Blog)
GitHub Copilot on webのモデル選択で何が変わったのか
今回の更新は、GitHub Copilot全体からAIモデルがなくなるという話ではありません。ポイントは、github.com上のCopilot Chatで選択できるモデルが限定されたことです。
GitHubは、モデル選択の価値を認めつつも、信頼性の高い応答を安定して提供するために、Web版で利用できるモデルのリストを制限するとしています。今後もWebチャットでは、新しいモデルのロールアウト対象がより限定される方針です。(The GitHub Blog)
| 確認項目 | 今回の変更内容 | 実務上の意味 |
|---|---|---|
| 対象 | Copilot Chat on the web、つまりgithub.com上のCopilot Chat | IDE、CLI、他クライアントの挙動まで同じとは限らない |
| 削除されたモデル | Geminiモデル全般、一部のOpenAI系モデルなど | Web版で特定モデルを指定した手順や検証結果は見直しが必要 |
| 残るモデル | OpenAIおよびClaudeのモデルは各プランで引き続き利用可能 | 代替モデルの候補はOpenAI系またはClaude系を中心に考える |
| 目的 | 応答品質と一貫性の向上 | モデル数より、安定した回答品質を優先する運用に寄る |
| 最新確認方法 | github.com/copilotのモデルピッカー、または公式ドキュメント | 記事や社内資料の古いモデル一覧を信用しすぎない |
開発者にとっては「使いたいモデルが消えた」という見え方になりますが、管理者目線では「Web版Copilot Chatの標準化が進んだ」と捉えると整理しやすくなります。
影響を受けやすい利用者
今回のUpdates to available models in Copilot on webで影響を受けやすいのは、次のような利用者です。
github.com上でCopilot Chatを頻繁に使う開発者
Issue、Pull Request、README、コード差分の確認などをGitHub上で直接行い、その場でCopilot Chatに質問している開発者は、モデルピッカーの選択肢が変わっている可能性があります。
たとえば、これまでGemini系モデルを選んで長文の設計相談やドキュメント要約をしていた場合、同じモデルをWeb版で選べなくなることがあります。その場合は、まずOpenAI系またはClaude系の利用可能モデルで同じタスクを試し、回答の粒度や速度、コード生成の傾向を確認するのが現実的です。
Copilot BusinessやCopilot Enterpriseの管理者
組織やEnterpriseでCopilotを管理している場合、モデル選択は単なる個人設定ではありません。GitHub Docsでは、利用できるCopilotモデルはプラン、利用クライアント、組織またはEnterpriseによるモデル制限に依存すると説明されています。(GitHub Docs)
つまり、管理者は「GitHub側のWeb版モデル一覧の変更」と「自社のモデル利用ポリシー」の両方を確認する必要があります。ユーザーから「モデルが見つからない」と問い合わせが来た場合、原因はGitHub側の変更か、組織ポリシーか、利用プランかを切り分ける必要があります。
社内ドキュメントや研修資料を作成しているチーム
Copilotの使い方を社内展開している企業では、スクリーンショットや手順書に古いモデル名が残りやすくなります。
特に注意したいのは、以下のような記述です。
- 「Web版ではGeminiを選択する」
- 「コードレビュー前の確認はGPT-5.2 Codexを使う」
- 「軽量タスクはGPT-5.4 nanoを選ぶ」
- 「このモデルを選べば同じ結果が得られる」
今回の更新後、これらの記述はWeb版Copilot Chatでは通用しない可能性があります。モデル名を固定するよりも、「利用可能なモデルの中から、速度重視なら軽量系、複雑な設計相談なら高性能系を選ぶ」といった表現に変えるほうが、今後の変更にも強くなります。
削除されたモデルを前提にしていた場合の移行方針
今回の変更で重要なのは、単に「別のモデルを選ぶ」だけではなく、作業ごとに代替モデルを検証することです。AIモデルは同じプロンプトでも、回答の長さ、コードの書き方、推論の深さ、エラー時の説明が変わります。
| これまでの使い方 | 移行時の考え方 | 確認ポイント |
|---|---|---|
| Gemini系で設計相談をしていた | 利用可能なClaude系またはOpenAI系で再検証 | 長文理解、前提条件の保持、設計理由の説明力 |
| Codex系でコード生成をしていた | OpenAI系の利用可能モデルを中心に比較 | 生成コードの正確性、既存コードとの整合性、テスト生成 |
| nano系など軽量モデルで短い質問を処理していた | 速度とコストのバランスを見て代替 | 応答速度、利用量、十分な回答品質 |
| 社内手順でモデル名を指定していた | モデル名固定から用途別の選び方へ変更 | 手順書、研修資料、FAQ、スクリーンショット |
移行時にやるべきことは、以下の順番で進めると失敗しにくくなります。
- Web版Copilot Chatのモデルピッカーで現在選べるモデルを確認する
- 既存の社内手順書で特定モデル名を指定している箇所を洗い出す
- 代表的なタスクを3〜5個選び、代替モデルで出力を比較する
- 回答品質だけでなく、利用量やコストへの影響も確認する
- 開発者向けに「選べないモデルが出た場合の対処」を短く周知する
ここで避けたいのは、「以前のモデルと似た名前だから同じ用途で問題ない」と決め打ちすることです。モデル名が近くても、応答傾向や得意分野が変わる場合があります。最低限、実際のリポジトリ、Issue、Pull Requestの文脈で試すべきです。
管理者が確認すべき設定
Copilot BusinessやCopilot Enterpriseを利用している組織では、管理者がモデルアクセス設定を確認する必要があります。GitHub Docsでは、Organization ownerまたはEnterprise ownerが、Copilot EnterpriseまたはCopilot Businessのシートを持つメンバーに対してAIモデルへのアクセスを有効化・無効化できると説明されています。(GitHub Docs)
モデルアクセスの確認
まず確認すべきなのは、組織またはEnterpriseで許可しているAIモデルです。GitHub側でWeb版の選択肢が絞られていても、組織ポリシーでさらに制限している場合、ユーザーに表示されるモデルはより少なくなります。
管理者は、次の観点で見直すとよいでしょう。
| 管理項目 | 確認内容 | 見落としやすい点 |
|---|---|---|
| Copilotプラン | Business、Enterprise、個人プランのどれか | プランによって利用できるモデルが異なる場合がある |
| クライアント | github.com、VS Code、JetBrains、CLIなど | Web版だけ変更されている情報を全クライアントに広げて解釈しない |
| モデルポリシー | 組織・Enterpriseで許可または禁止しているモデル | GitHub側の削除と自社ポリシーの制限を混同しやすい |
| Auto model selection | 自動モデル選択がポリシーに従うか | 許可していないモデルが自動選択されると誤解されやすい |
| BYOK・カスタムモデル | 独自APIキーや外部モデルを使っているか | Web版標準モデルの変更とは別管理になることがある |
GitHub Docsでは、Auto model selectionで利用されるモデルもOrganizationまたはEnterpriseのポリシーに従うと説明されています。(GitHub Docs) そのため、自動選択を使っている場合でも、管理者側のモデルポリシー確認は不要になりません。
モデル切り替え権限の確認
Copilot Chatでは、ユーザーがチャット中にモデルを切り替えられます。ただし、Copilot Business経由で利用している場合、組織がメンバーに別モデルへの切り替え権限を付与している必要があります。(GitHub Docs)
開発者から「モデル選択欄がない」「別モデルを選べない」と問い合わせが来た場合は、次の順で確認すると切り分けが早くなります。
| 症状 | 主な確認先 | 対応 |
|---|---|---|
| モデルピッカーに以前のモデルがない | GitHub公式Changelog、モデル一覧 | Web版から削除されたモデルか確認する |
| モデルピッカー自体が使えない | 組織ポリシー | モデル切り替え権限が許可されているか確認する |
| 他のメンバーと表示モデルが違う | プラン、所属Organization、Enterprise設定 | ライセンス割り当てとポリシー差分を確認する |
| VS Codeでは選べるがWebでは選べない | クライアント別モデル対応 | Web版とIDE版を分けて説明する |
開発者が今すぐ確認すべきこと
開発者側で必要なのは、難しい管理作業ではありません。まずは、普段の作業で使っているCopilot Chatの入口がWeb版なのか、IDE版なのかを分けて考えることです。
GitHub Docsでは、Copilotで利用できるモデルはGitHub.comやVisual Studio Code、JetBrains IDEsなど利用クライアントによって異なると説明されています。(GitHub Docs) そのため、「Webで選べない＝Copilot全体で使えない」と判断するのは早計です。
Web版Copilot Chatで確認する手順
GitHub公式ドキュメントでは、GitHub Webサイト上のCopilot Chatで、チャット下部の現在のモデル名のドロップダウンからAIモデルを選択できると説明されています。また、プロンプト送信後に別モデルで再生成することも可能です。(GitHub Docs)
実務では、次のように確認するとよいでしょう。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | github.comでCopilot Chatを開く | 普段使うリポジトリやIssueの文脈で確認する |
| 2 | チャット下部のモデル選択を開く | 以前使っていたモデルが表示されるか確認する |
| 3 | 代表的な質問を1つ投げる | 回答の正確性、長さ、コードの質を見る |
| 4 | 可能であれば別モデルで再生成する | 同じ文脈で比較し、チーム標準候補を決める |
| 5 | 選べないモデルがあれば管理者に共有する | スクリーンショットと利用プランを添える |
特にチーム開発では、「自分の画面では選べる」「別の人の画面では選べない」という状況が起きやすくなります。問い合わせ時は、利用場所がgithub.comなのかIDEなのか、Organization配下のリポジトリなのか、個人アカウントなのかを添えると解決が早くなります。
コストと利用量への影響も確認する
モデル変更は、回答品質だけでなく利用量やコストにも関係します。GitHub Docsでは、2026年6月1日からCopilotがリクエストベースの課金から使用量ベースの課金へ移行し、モデルと消費トークン数によってコストが決まると説明されています。(GitHub Docs)
また、モデルによってプレミアムリクエストの消費倍率が異なる場合があり、モデル選択は月間利用枠の消費に影響する可能性があります。(GitHub Docs)
そのため、管理者はモデル変更を「UI上の選択肢変更」とだけ捉えないほうがよいです。特に、以下のような使い方をしているチームでは注意が必要です。
- Pull RequestごとにCopilot Chatで長文レビューをしている
- Issueの要約や調査を大量に行っている
- 設計相談で長いコンテキストを頻繁に渡している
- 複数モデルで回答を比較する運用をしている
- 開発者全員に同じ高性能モデルの利用を推奨している
コスト管理の観点では、まず「全員が高性能モデルを常用する」運用を避けるのが現実的です。複雑な設計、セキュリティ観点のレビュー、重要なリファクタリングでは高性能モデルを使い、短い質問や定型的な説明では軽量・標準的なモデルを使う、といった使い分けを社内ガイドに落とし込むとよいでしょう。
失敗しやすいポイント
今回のUpdates to available models in Copilot on webでは、次のような誤解が起きやすくなります。
「GeminiがCopilot全体から消えた」と判断する
公式Changelogで説明されているのは、Copilot Chat on the web、つまりgithub.com上のWebチャットに関する変更です。IDEやその他のクライアント、今後のモデル一覧は別途確認が必要です。
最新の利用可能モデルは、GitHubが案内しているとおり、github.com/copilotのモデルピッカーまたは公式ドキュメントで確認するのが安全です。(The GitHub Blog)
社内手順に特定モデル名を固定し続ける
モデル名を固定した手順は、変更に弱くなります。特にAIモデルは追加、削除、リタイア、プレビュー終了が起きやすいため、社内ドキュメントでは「モデル名」よりも「用途」と「判断基準」を中心に書くべきです。
悪い例は「必ずGeminiを選ぶ」です。よい例は「長文の設計相談では、利用可能な高性能モデルを選び、回答理由と前提条件を確認する」です。
回答品質の変化を検証しない
モデルが変わると、同じプロンプトでも回答が変わります。特に、以下のタスクは検証しておくべきです。
| タスク | 検証すべき理由 |
|---|---|
| コード生成 | APIの使い方や型定義の扱いが変わることがある |
| リファクタリング提案 | 設計思想や分割粒度が変わることがある |
| PRレビュー | 指摘の厳しさ、網羅性、優先順位が変わることがある |
| ドキュメント要約 | 省略の仕方や表現の硬さが変わることがある |
| 障害調査 | 原因仮説の出し方や確認手順の順序が変わることがある |
モデル変更後は、いきなり本番運用に組み込むのではなく、実際のリポジトリを使って代表ケースを比較してください。特に、セキュリティ、課金、データ削除、認証認可に関わるコードは、Copilotの出力をそのまま採用せず、人間のレビューを前提にするべきです。
管理者向けの展開チェックリスト
今回の変更を受けて、組織でCopilotを展開している管理者は、以下を確認しておくと問い合わせ対応がスムーズになります。
| チェック項目 | 対応内容 |
|---|---|
| Web版の表示モデル | github.com上のCopilot Chatで現在選べるモデルを確認する |
| 公式ドキュメント | サポートモデル一覧とモデルアクセス設定を確認する |
| 組織ポリシー | モデル切り替え権限、許可モデル、Auto model selectionの扱いを確認する |
| 社内資料 | 古いモデル名、スクリーンショット、研修資料を更新する |
| 代替モデル | 主要タスクごとに推奨モデル候補を決める |
| コスト管理 | 使用量ベース課金やAI Creditsへの移行に備えて利用状況を確認する |
| 周知 | 開発者に「Web版のモデル選択肢が変わった」ことを短く案内する |
社内告知では、長い説明よりも次の3点を明確にすると伝わりやすくなります。
- Web版Copilot Chatで選べるモデルが変更された
- 以前使っていたモデルが表示されない場合は、利用可能なOpenAI系またはClaude系で代替する
- モデルが選べない、表示が人によって違う場合は、利用場所、アカウント、Organization名を添えて管理者へ連絡する
開発チームでの実用的な使い分け
モデル選択肢が減ったからといって、Copilot Chatの価値が下がるとは限りません。むしろ、チームとしては「どのモデルを使うか」よりも「どの作業で、どの品質基準を満たすか」を決めるほうが重要です。
| 作業内容 | 推奨する使い方 |
|---|---|
| 軽い構文確認 | 速度重視のモデルで短く質問する |
| 複雑な設計相談 | 高性能モデルを選び、前提条件を明示する |
| PRレビュー補助 | 指摘の優先度、影響範囲、修正案を分けて依頼する |
| テスト作成 | 対象関数、期待値、異常系を具体的に指定する |
| 障害調査 | ログ、再現条件、直近変更をまとめて渡す |
| ドキュメント作成 | 読者、目的、禁止表現、見出し構成を指定する |
たとえば、PRレビューで使う場合は「このPRをレビューして」だけではなく、次のように依頼するとモデル差によるブレを抑えやすくなります。
このPull Requestをレビューしてください。
観点は、認証認可、例外処理、既存仕様との互換性、テスト不足の4点です。
指摘は重要度順に並べ、修正例がある場合は差分形式ではなく説明文で示してください。モデル選択肢が変わっても、プロンプト側で期待する出力形式を明確にすれば、実務で使える回答に近づけられます。
今回の更新で取るべき次の行動
今回の「Updates to available models in Copilot on web」は、GitHub Copilot ChatのWeb版におけるモデル選択を整理し、より一貫した応答品質を目指す変更です。影響が大きいのは、Gemini系モデルや一部OpenAI系モデルをWeb版で指定していた開発者、そして組織単位でCopilotのモデル利用を管理している管理者です。
まずは、github.com上のCopilot Chatで現在のモデルピッカーを確認してください。次に、社内資料やチーム手順に古いモデル名が残っていないかを見直します。管理者は、OrganizationまたはEnterpriseのモデルアクセス設定、モデル切り替え権限、Auto model selection、コスト管理の方針をあわせて確認しましょう。
モデル名に依存した運用から、用途・品質基準・コストを基準にした運用へ切り替えることが、今後のCopilot更新に強いチーム運用につながります。
コメント