GitHub CopilotのAutoモデル選択を使っている個人ユーザーは、今後「evaluation models（評価中モデル）」が自動的に使われる場合があります。結論から言うと、Copilot Free、Pro、Pro+などの個人向けプランでAutoを使っている人は、設定を確認し、安定性やセキュリティレビューを重視する開発では無効化も検討すべき変更です。
GitHub公式Changelogでは2026年6月1日付で「Evaluation models in auto for individual plans」が公開され、個人の非Enterpriseユーザー向けにevaluation modelsへのアクセスが提供され、CopilotのAutoモデル選択でそれらが使われる可能性があると案内されています。日本時間では2026年6月2日前後に確認した人も多い更新です。(The GitHub Blog)
GitHub CopilotのEvaluation models in auto for individual plansで何が変わるのか
今回の変更は、GitHub Copilotの個人向けプランでAutoモデル選択を使ったとき、評価中のAIモデルが候補に入る場合があるというものです。
Autoモデル選択とは、ユーザーが毎回モデルを選ばなくても、Copilotがタスク内容や利用状況に応じてモデルを選ぶ仕組みです。GitHub Docsでは、Autoモデル選択は利用可能なモデル、サブスクリプション、ポリシーに従ってモデルを選ぶと説明されています。(GitHub Docs)
今回新たに注意したいのは、Autoの候補に含まれる可能性がある「evaluation models」が、一般提供済みの安定モデルと同じ前提で扱えるとは限らない点です。GitHub Docsでは、evaluation modelsは追加・更新・削除される可能性があり、可用性やレート制限が一般提供モデルと異なる場合があると説明されています。(GitHub Docs)
つまり、開発者にとっては「Autoを選んでいるだけ」のつもりでも、裏側では評価中モデルが使われ、回答の傾向や速度、安定性が変わる可能性があります。
対象になるユーザーと対象外になりやすいケース
今回の変更でまず確認すべきなのは、自分やチームがどのCopilotプランで利用しているかです。
| 区分 | 影響の有無 | 確認ポイント |
|---|---|---|
| 個人の非Enterpriseユーザー | 影響あり | Autoモデル選択時にevaluation modelsが使われる可能性がある |
| Copilot Free / Student | 影響あり得る | GitHub DocsではFreeとStudentはAutoモデル選択のみ利用可能とされているため、設定確認の優先度が高い |
| Copilot Pro / Pro+などの個人プラン | 影響あり得る | Autoを使うか、明示的にモデルを選ぶかを用途で決める |
| Copilot Business / Enterpriseの組織利用 | 直接の主対象ではない | 組織・Enterpriseのモデルポリシー、データレジデンシー、FedRAMP関連ポリシーを確認 |
| 明示的に特定モデルを選んでいるユーザー | 影響は限定的 | Autoを選ばない限り、今回のAuto経由の影響は受けにくい |
GitHub Docsでは、個人向けCopilotプランではAIモデルを直接利用でき、組織やEnterpriseでは管理者がCopilot BusinessまたはCopilot Enterpriseシートを持つメンバー向けにモデルアクセスを有効化・無効化できると説明されています。(GitHub Docs)
組織利用の場合は、「個人ユーザー向けの新機能だから関係ない」と決めつけない方が安全です。社員が会社リポジトリとは別に個人アカウントのCopilotを使っている場合、個人設定側でevaluation modelsが有効になっている可能性があります。
evaluation modelsとは何か
evaluation modelsは、GitHub Copilotで評価目的に提供されるAIモデルです。GitHub Docsによると、製品画面では正式なモデル名やプロバイダー名ではなく、コードネームで表示される場合があります。また、Microsoft、OpenAI、Anthropic、Googleのいずれか、または複数のプロバイダー由来・ファインチューニング済みのモデルである可能性があります。(GitHub Docs)
実務上は、次のように捉えると分かりやすいです。
| 観点 | 一般提供モデル | evaluation models |
|---|---|---|
| 位置付け | 通常利用を前提に提供されるモデル | 評価・検証中のモデル |
| 表示名 | モデル名やプロバイダー名が分かりやすいことが多い | コードネーム表示の場合がある |
| 安定性 | 比較的予測しやすい | 更新・削除・挙動変更の可能性がある |
| セキュリティ関連タスク | 過信せずレビューが必要 | より慎重な検証が必要 |
| 向いている用途 | 日常開発、レビュー補助、設計相談 | 新モデルの試用、回答傾向の比較、非本番コードでの検証 |
特に重要なのは、GitHub Docsが「evaluation modelsはセキュリティ関連など一部カテゴリのプロンプトで他モデルより低い性能を示す可能性がある」と注意している点です。生成されたコードは、人間によるレビューや複数モデルでの確認を経て、本番へ取り込むべきだとされています。(GitHub Docs)
Autoモデル選択で何が起きるのか
Autoモデル選択は、Copilotが利用可能なモデル群から適したモデルを選ぶ機能です。GitHub Docsでは、Autoモデル選択はリアルタイムのシステム状態やモデルの可用性、タスクの複雑さなどを考慮し、より効率的にモデルを選ぶ仕組みとして説明されています。(GitHub Docs)
今回の変更により、個人向けCopilotプランのユーザーがAutoを選んでいる場合、Copilotがevaluation modelsを使う可能性があります。
たとえば、次のような場面です。
| 利用シーン | 起こり得る変化 | 実務での対応 |
|---|---|---|
| 小さな関数の実装補助 | いつもと違う書き方を提案する可能性 | lint、unit test、差分レビューを通す |
| エラーメッセージの調査 | 回答の深さや切り口が変わる可能性 | 公式ドキュメントやログと照合する |
| セキュリティ修正の相談 | 評価中モデルの性能差が影響する可能性 | 1つの回答で判断せず、SASTやレビューを併用 |
| 本番障害対応中の相談 | 回答の安定性が重要になる | Autoではなく信頼しているモデルを明示選択する |
| 新技術の調査 | 新しいモデルの強みを試せる可能性 | 出力を鵜呑みにせず検証環境で確認する |
Autoは便利ですが、「常に同じモデルが同じ品質で答える」機能ではありません。運用上は、速度や手軽さを優先する場面ではAuto、再現性や説明責任を重視する場面ではモデルを明示選択という使い分けが現実的です。
evaluation modelsを無効化すべきかの判断基準
すべてのユーザーが即座に無効化すべきとは限りません。新しいモデルを試したい個人開発者や、非本番コードでCopilotの出力を比較したい人にとっては、Auto経由で評価中モデルを試せることがメリットになる場合があります。
一方で、次の条件に当てはまる場合は無効化を検討した方がよいでしょう。
| 判断基準 | 推奨 |
|---|---|
| 本番コード、認証、暗号化、権限管理まわりの実装にCopilotを使う | 無効化を検討 |
| チームで回答品質のばらつきを減らしたい | 無効化または明示的なモデル選択を推奨 |
| 生成コードをレビューなしで取り込みがち | 無効化を強く検討 |
| 新モデルの挙動を比較したい | 有効のまま検証用に使うのも選択肢 |
| 個人の学習・プロトタイピングが中心 | 有効のままでもよいが、出力検証は必要 |
| 会社のコードを個人アカウントで扱うことがある | 社内ルール確認まで無効化が無難 |
独自の判断軸としておすすめしたいのは、「失敗したときのコスト」で決めることです。
生成コードの誤りがすぐ捨てられるプロトタイプなら、evaluation modelsを試す価値があります。しかし、権限チェック漏れ、SQLインジェクション、クラウド権限の過剰付与、CI/CD設定ミスのように失敗時の影響が大きい領域では、安定性とレビュー体制を優先すべきです。
evaluation modelsを無効化する設定手順
GitHub Docsでは、CopilotのAutoモデル選択におけるevaluation modelsの利用を無効化する手順として、GitHubのプロフィールメニューからSettingsを開き、AI controlsで「Evaluation models in Copilot auto model selection」をDisabledにする方法が案内されています。(GitHub Docs)
手順を整理すると、次の通りです。
| 手順 | 操作 |
| -: | ——————————————————– |
| 1 | GitHubにログインする |
| 2 | 画面右上のプロフィール画像をクリックする |
| 3 | Settingsを開く |
| 4 | ページ上部のAI controlsを選択する |
| 5 | Evaluation models in Copilot auto model selectionを探す |
| 6 | ドロップダウンからDisabledを選択する |
| 7 | Copilot ChatやIDE側でAuto利用時の挙動を確認する |
設定後は、VS CodeやJetBrains IDEなど、普段使っているクライアント側でもCopilot Chatを開き、Auto選択時に使われたモデル表示を確認しておくと安心です。GitHub Docsでは、Copilot Chatでは回答にホバーすることで使用モデルを確認でき、Copilot CLIやCopilot cloud agentでも回答ごとのモデルを確認できると説明されています。(GitHub Docs)
管理者が確認すべきポイント
今回の主対象は個人向けプランですが、企業や開発チームの管理者も無視しない方がよい変更です。理由は、開発者が業務コードを扱う環境で、組織管理下のCopilotとは別に個人向けCopilotを使っているケースがあるためです。
個人アカウント利用を棚卸しする
まず確認すべきなのは、会社のリポジトリやローカルの業務コードに対し、個人のCopilot契約を使っている開発者がいないかです。
確認項目は次の通りです。
| 確認項目 | 見るべき理由 |
|---|---|
| 業務端末で個人GitHubアカウントにログインしているか | 個人設定が業務利用に影響する可能性がある |
| IDEのCopilot認証先アカウント | GitHub.comのログインとIDEの認証が異なることがある |
| Autoモデル選択の利用有無 | evaluation modelsが使われる入口になる |
| 生成コードのレビュー運用 | モデル差による品質ばらつきを吸収できるか確認する |
| 社内AI利用ポリシー | 評価中モデルの利用を許容するか判断する |
「会社ではCopilot Businessを契約しているから問題ない」と考える前に、実際に各開発者がどのアカウントでIDEにサインインしているかを確認するのが重要です。
組織・Enterpriseのモデルポリシーを確認する
GitHub Docsでは、Autoモデル選択で利用可能なモデルは、管理者ポリシー、データレジデンシー、FedRAMP準拠モデルに制限するポリシー、evaluation modelsを制限するポリシーなどの影響を受けると説明されています。(GitHub Docs)
組織管理者は、次の順番で確認すると迷いにくいです。
| 優先度 | 確認内容 | 判断の目安 |
|---|---|---|
| 高 | Copilot Business / Enterpriseのモデルアクセス設定 | 許可していないモデルがAutoに入らないか確認 |
| 高 | データレジデンシーやコンプライアンス要件 | 制限が必要ならポリシーで明示 |
| 中 | 開発者が個人アカウントを併用していないか | 併用がある場合は社内ルールを明文化 |
| 中 | セキュリティレビュー対象のコード種別 | 認証・決済・権限まわりはレビューを厚くする |
| 低 | 新モデル評価の場 | 本番リポジトリとは別に検証用環境を用意する |
開発者が確認すべき設定と使い分け
個人開発者やフリーランスの場合は、管理者に頼らず自分で設定を決める必要があります。最初に見るべきポイントは、CopilotでAutoを使っているかです。
Autoを使う場合
Autoを使い続けるなら、次の運用をおすすめします。
| やること | 理由 |
|---|---|
| 回答ごとの使用モデルを確認する | いつもと違うモデルが使われた場合に気づける |
| 重要コードではテストを先に用意する | モデル差よりもテスト結果を判断基準にできる |
| セキュリティ関連は複数観点で確認する | GitHub自身も慎重な検証を求めている |
| 生成コードをそのまま貼らない | 依存関係、例外処理、境界条件の見落としを防ぐ |
| うまくいかないときはモデルを明示選択する | Autoの選択がタスクに合っていない可能性を切り分ける |
Autoを使わない方がよい場面
次の作業では、Autoよりも信頼しているモデルを明示選択する方が安全です。
- 認証・認可の実装
- 個人情報や機密データを扱う処理
- 決済、請求、金融関連のロジック
- インフラ権限、IAM、ネットワーク設定
- 本番障害の暫定対応
- 監査証跡やセキュリティレビューの対象になる変更
- 既存仕様への厳密な追従が必要なリファクタリング
特に、Copilotの提案を「作業速度を上げる補助」として使うのではなく、「判断の代替」として使っている場合は注意が必要です。evaluation modelsの有無にかかわらず、最終判断は開発者とレビュー体制に残ります。
移行・展開時の注意点
今回の変更は、大規模な移行作業が必要なタイプではありません。ただし、開発現場では「いつの間にかAutoの挙動が変わった」と感じる可能性があります。展開時は、次の3点を押さえると混乱を減らせます。
まず設定確認を標準作業に入れる
Copilotを新規導入する手順書やオンボーディング資料に、AI controlsの確認を追加しましょう。
例として、次のようなチェックリストを入れておくと実用的です。
| チェック | 内容 |
|---|---|
| Copilotの契約種別 | Free / Pro / Pro+ / Business / Enterpriseを確認 |
| IDEのサインインアカウント | 個人か組織管理かを確認 |
| Autoモデル選択の利用 | Autoを使う前提か、明示選択する前提かを決める |
| evaluation models設定 | 有効・無効の方針を決める |
| 重要コードのレビュー | セキュリティ、テスト、レビューの条件を確認 |
「新モデルを試す場所」と「本番コードを書く場所」を分ける
evaluation modelsを完全に避けるのではなく、検証用として使いたいチームもあるはずです。その場合は、対象リポジトリや用途を分けるのが安全です。
おすすめは次の分け方です。
| 環境 | evaluation modelsの扱い | 例 |
|---|---|---|
| 個人検証・学習 | 有効でもよい | サンプルコード、技術調査、メモ |
| プロトタイプ | 条件付きで利用 | 破棄前提のPoC、UI案、モック |
| 社内ツール | 慎重に利用 | テストとレビューを必須にする |
| 本番サービス | 原則無効または明示モデル利用 | 認証、決済、顧客データ処理 |
| セキュリティ修正 | 無効を推奨 | 脆弱性対応、権限管理、監査対応 |
生成物のレビュー基準を明文化する
モデルの種類に関係なく、AIが生成したコードにはレビュー基準が必要です。特にevaluation modelsを許可する場合は、次のようなルールを明文化しておくと実務で迷いません。
| レビュー観点 | 確認例 |
|---|---|
| 正しさ | 仕様、境界値、例外処理を満たしているか |
| セキュリティ | 入力検証、認可、秘密情報の扱いに問題がないか |
| 保守性 | プロジェクトの設計方針や命名規則に合っているか |
| 依存関係 | 不要なライブラリや古いAPIを追加していないか |
| テスト | 失敗ケース、異常系、回帰テストがあるか |
| ライセンス・引用 | 外部コードの混入や不適切な再利用がないか |
データ処理やプロバイダー面での注意
evaluation modelsは、正式なプロバイダー名ではなくコードネームで表示される場合があります。GitHub Docsでは、evaluation modelsのデータ処理は各プロバイダーとの既存契約に限定され、リリース前にGitHubとMicrosoftによるテスト・検証を受けると説明されています。(GitHub Docs)
また、GitHub Copilotでは複数のAIモデルが使われており、OpenAI、Anthropic、Google、Microsoftなどモデルごとにホスティングやデータコミットメントが異なります。GitHub Docsでは、入力と出力はCopilotのコンテンツフィルタを通り、必要に応じて公開コード一致や有害コンテンツのチェックが行われると説明されています。(GitHub Docs)
ここで注意したいのは、「データ処理の説明があること」と「自社の利用ルール上問題ないこと」は別問題だという点です。社内規程で、評価中モデル、外部AIサービス、特定リージョン外処理、プロンプトへの機密情報入力が制限されている場合は、GitHubの設定だけでなく社内ポリシーとの整合性を確認してください。
よくある疑問
evaluation modelsは勝手に本番コードを書き換えるのか
Copilotの提案を採用しない限り、モデルが直接本番コードを変更するわけではありません。ただし、Copilot ChatやIDE補完で出てきたコードを開発者が採用すれば、結果的に本番コードへ入る可能性があります。重要なのは、モデル名ではなく提案を採用する前のレビュー手順です。
Autoを使わなければ影響はないのか
今回の告知は、CopilotのAutoモデル選択でevaluation modelsが使われる可能性に関するものです。そのため、普段から特定モデルを明示選択している場合、影響は限定的です。ただし、クライアントや設定変更でAutoに戻ることがあるため、利用中のIDEやGitHub.com側の表示は確認しておきましょう。
Copilot FreeやStudentはどうすればよいか
GitHub Docsでは、Copilot FreeとCopilot StudentはAutoモデル選択のみ利用できると説明されています。(GitHub Docs) そのため、該当ユーザーはAI controlsでevaluation modelsの設定を確認し、業務コードや重要な個人プロジェクトで使う場合は無効化を検討するとよいでしょう。
管理者は全員に無効化を指示すべきか
一律に無効化するより、用途で分ける方が現実的です。セキュリティや本番品質に関わる開発では無効化または明示モデル選択を推奨し、検証・学習・プロトタイプでは許可する、というルールが扱いやすいでしょう。
evaluation modelsの方が高性能なのか
高性能な場合もあれば、タスクによっては不安定な場合もあります。GitHub Docsは、セキュリティ関連など一部カテゴリで他モデルより性能が低い可能性を明記しています。(GitHub Docs) 「新しいから良い」「評価中だから危険」と単純に判断せず、用途とレビュー体制で決めることが大切です。
まずやるべきこと
今回の「Evaluation models in auto for individual plans」は、GitHub Copilotの個人ユーザーにとって小さく見えて重要な変更です。Autoモデル選択を使っている場合、評価中モデルが使われる可能性があるため、品質、セキュリティ、再現性を重視する開発では設定確認が欠かせません。
まずは次の順で対応しましょう。
- GitHub Copilotの契約種別を確認する
- GitHubのSettingsからAI controlsを開く
- Evaluation models in Copilot auto model selectionの状態を確認する
- 本番コードや業務コードで使う場合はDisabledを検討する
- Autoを使う場合でも、使用モデル、テスト、レビューを確認する
- チーム利用では、個人アカウント併用と社内AI利用ルールを見直す
Autoモデル選択は便利な機能ですが、便利さと統制は分けて考える必要があります。新しいモデルを試す場面では活用し、重要なコードでは明示的なモデル選択とレビューを徹底する。それが、今回の変更を安全に取り込むための現実的な対応です。
コメント