「Not all model upgrades are upgrades」は、2026年7月6日にMicrosoft for Developersが公開した、GitHub CopilotにおけるAIモデル評価の記事です。日本語にすれば「すべてのモデル更新が改善になるとは限らない」という意味です。
結論は明確です。新しいモデルの単価が安く、一般的なベンチマークが優秀でも、自社の作業ではトークン消費量が増え、品質が下がり、総コストまで高くなる可能性があります。 今回の情報は新機能の強制展開を知らせるものではなく、モデル更新を本番環境へ反映する前に、実際の業務で評価すべきだと示す検証レポートです。(Microsoft for Developers)
GitHub Copilotを組織で利用している場合は、新モデルを一律に許可・標準化するのではなく、タスク別の評価、利用モデルの制御、AI利用予算、データの処理場所、参照ドキュメントの品質をセットで見直す必要があります。
Microsoftの「Not all model upgrades are upgrades」とは
Microsoftの公式記事では、GitHub Copilot Chatを使い、旧モデルのClaude Sonnet 4.6と新モデルのClaude Sonnet 5を比較しています。
検証環境は次のとおりです。
| 項目 | 検証内容 |
|---|---|
| 公開日 | 2026年7月6日 |
| 利用サービス | GitHub Copilot Chat |
| クライアント | Visual Studio Code |
| OS | Windows |
| 比較モデル | Claude Sonnet 4.6、Claude Sonnet 5 |
| タスク | Azureアーキテクチャ関連12シナリオ、SharePoint Framework更新3シナリオ |
| 実行回数 | 各モデル・各シナリオ5回、合計150回 |
| 評価方法 | タスク選択、品質、構成の正確性、トークン消費量、推定コスト |
| 推論レベル | 各モデルのデフォルト設定 |
150回の内訳は、Azureアーキテクチャ関連が120回、SharePoint Frameworkの更新が30回です。出力は二値基準を使って評価され、LLMによる判定も利用されています。記事公開後の著者コメントでは、推論レベルは各モデルのデフォルト設定だったことも明らかにされています。(Microsoft for Developers)
このため、今回の数値をすべての開発環境や業務にそのまま当てはめることはできません。ただし、「モデルの新旧や単価ではなく、自社の代表的なタスクで判断する」という考え方は、GitHub Copilot以外の生成AI導入にも応用できます。
検証結果から分かる主な変更点
今回の公式記事は製品仕様の変更ではなく、モデルの評価方法に関する実務上の方針転換を促す内容です。
主な結果は次のとおりです。
| 評価項目 | Claude Sonnet 4.6 | Claude Sonnet 5 | 読み取れること |
|---|---|---|---|
| アーキテクチャタスクの完了率 | 75% | 75% | 新モデルでも完了率は上がらなかった |
| アーキテクチャ出力の品質評価 | 90% | 78% | 旧モデルの方が既存の設計パターンに沿っていた |
| アーキテクチャ1回当たり平均コスト | 0.54ドル | 0.47ドル | この用途では新モデルが約12%安かった |
| コード更新タスクの完了率 | 60% | 100% | 指示への追従性は新モデルが優れていた |
| 構成の正確性 | 0% | 0% | どちらも構造的な移行を完了できなかった |
| コード更新1回当たり平均コスト | 0.55ドル | 2.01ドル | 新モデルが約3.7倍高かった |
アーキテクチャ出力の品質は、両モデルが利用可能な出力を生成したシナリオについて、一般的な設計パターンや慣例に沿っているかを評価したものです。旧モデルは9シナリオ中8シナリオで、新モデルと同等以上の結果を出しました。(Microsoft for Developers)
1トークンの安さと総コストは別問題
ブログ公開時点の価格表では、Claude Sonnet 5はClaude Sonnet 4.6よりも、入力・キャッシュ済み入力・出力の各単価が約33%安く設定されていました。
しかし、総コストはおおむね次の要素で決まります。
総コスト ＝ 入力トークン数 × 入力単価 ＋ 出力トークン数 × 出力単価 ＋ キャッシュ関連コスト
単価が3分の2になっても、消費トークンが10倍になれば、最終的な費用は大幅に増えます。
Microsoftの検証では、アーキテクチャタスクにおけるClaude Sonnet 5の中央値は、Claude Sonnet 4.6の約12倍のトークンを消費しました。コード更新タスクでも最大約10倍の差が確認されています。(Microsoft for Developers)
さらに、同じIoT分析アーキテクチャのシナリオと同じプロンプトでも、Claude Sonnet 5の実行結果は約1万6,000トークンから約660万トークンまで変動しました。モデルの平均コストだけを確認していると、このような外れ値による予算超過を見落とします。(Microsoft for Developers)
なお、GitHubの公式価格情報では、Claude Sonnet 5の低価格は2026年8月31日までのプロモーション価格とされています。運用開始時には、最新のモデル単価で再計算する必要があります。(GitHub Docs)
新モデルが優れていたのは指示への厳密な追従
新モデルがすべての点で劣っていたわけではありません。
SharePoint Frameworkをバージョン1.21.1から1.22.0へ更新する検証では、Claude Sonnet 4.6は5回すべてで失敗しました。Microsoft Learnに掲載されていた1.22.1を優先し、利用者が明示した1.22.0という条件を守れなかったためです。
一方、Claude Sonnet 5は5回すべてで指定バージョンに従いました。外部ドキュメントの情報よりも、利用者が明示した条件を優先する能力については、新モデルが明確に優れていました。(Microsoft for Developers)
次のような作業では、新モデルの恩恵を受けられる可能性があります。
- 特定バージョンを厳守するアップグレード
- 禁止事項や変更範囲が明確なコード修正
- 複数条件を満たす必要がある移行作業
- 利用者の指示と参照資料が食い違うタスク
- バージョン固定されたライブラリの導入支援
ただし、指示に従ったことと、最終成果物が技術的に正しいことは別です。今回の検証では、構成の正確性は両モデルとも0%でした。
最大の問題はモデルではなく参照情報だった
SharePoint Frameworkの更新では、どちらのモデルもビルドシステムや設定形式の構造的な移行を完了できませんでした。
Microsoftは、両モデルが発見できなかった変更点として、ビルドツールのフラグ、パッケージマニフェストの再構成、不要ファイルの削除、設定形式の移行など、7項目を特定しています。これらは作業に必要であるにもかかわらず、参照ドキュメント内にまとまって記載されていませんでした。(Microsoft for Developers)
この結果が示すのは、不足している情報をモデル更新だけで補うことはできないという点です。
AIが正しく作業できない場合は、モデルを変更する前に次を確認する必要があります。
- 社内手順書に例外処理まで書かれているか
- バージョンごとの差分が整理されているか
- 移行時に削除するファイルが明示されているか
- 設定ファイルの完成例が用意されているか
- 失敗時の復旧方法が記載されているか
- リポジトリ固有のルールがAIに提供されているか
- 参照元の情報が古くなっていないか
モデル更新よりも、ドキュメント、リポジトリ指示、エージェント拡張、検索対象の整備を優先した方が、費用対効果が高くなる場合があります。Microsoftの公式記事でも、情報不足を解消するエージェント拡張は、モデル更新以上の効果を生むことがあると説明されています。(Microsoft for Developers)
利用条件と影響を受ける範囲
「Not all model upgrades are upgrades」は、Microsoft 365 Copilot全体のモデル変更を告知する記事ではありません。直接の検証対象はGitHub Copilot Chatです。
| 確認項目 | 条件・対象範囲 |
|---|---|
| 直接の対象 | GitHub Copilot Chatを使ったエージェント型タスク |
| 検証クライアント | Visual Studio Code |
| 検証OS | Windows |
| 対象モデル | Claude Sonnet 4.6、Claude Sonnet 5 |
| モデル利用条件 | GitHub Copilotのプラン、利用クライアント、管理者ポリシーによって異なる |
| 個人プラン | 利用できるモデルは契約プランに依存する |
| Copilot Free・Student | Autoモデル選択のみ |
| Business・Enterprise | 組織またはエンタープライズ管理者がモデルの利用可否を制御できる |
| 直接検証されていないもの | Microsoft 365 Copilot、Copilot Studio、Azure上で独自構築したAIアプリ |
GitHub Copilotで利用できるモデルは、契約プランだけでなく、GitHub.com、Visual Studio Code、Visual Studio、JetBrains IDEなど、利用するクライアントによっても異なります。Copilot BusinessとCopilot Enterpriseでは、管理者が特定モデルへのアクセスを有効または無効にできます。(GitHub Docs)
日常的な低リスクの質問では、信頼性や可用性に応じてモデルを選択するAutoを利用できます。一方、バージョン更新、設計判断、大量のエージェント実行など、結果やコストの再現性が重要な作業では、特定モデルを指定して評価した方が安全です。Microsoft Learnでも、通常のプロンプトにはAutoを利用し、複雑な作業ではモデルを切り替える運用が案内されています。(Microsoft Learn)
GitHub Copilotのデータ境界で確認すべきこと
Microsoft公式ブログで紹介されたモデルだからといって、入力データが常にMicrosoftの設備内だけで処理されるとは限りません。
Claudeモデルは外部プロバイダーの基盤でも処理される
GitHubのモデルホスティング情報によると、GitHub Copilotで提供されるClaudeモデルは、Amazon Web Services、Anthropic、Google Cloud Platformの基盤でホストされます。
GitHubは各プロバイダーとの契約により、プロンプトや応答をモデル学習に使用しないことを説明しています。また、一般提供されているAnthropic機能については、Anthropicとのゼロデータ保持契約があるとしています。
ただし、一部のベータ機能やパブリックプレビュー機能はゼロデータ保持契約の対象外となり、Anthropic側でデータが保持される可能性があります。モデル名だけでなく、利用する機能が一般提供かプレビューかも確認しなければなりません。(GitHub Docs)
個人プランと法人プランでは学習利用の扱いが異なる
GitHubの公式ドキュメントでは、Copilot BusinessとCopilot Enterpriseの顧客データはAIモデルの学習に使用しないとされています。
一方、Copilot Free、Pro、Pro+、Maxなどの個人契約では、設定に応じてプロンプト、提案、生成されたコード断片などがモデル改善に使われる場合があります。個人契約者には、学習利用からオプトアウトする設定が用意されています。(GitHub Docs)
会社のソースコードを扱う場合、従業員が個人契約のCopilotを利用する運用は避け、組織が管理するBusinessまたはEnterpriseのライセンスへ統一するのが基本です。
データレジデンシーは標準で有効になるわけではない
GitHub Copilotのデータレジデンシー機能は、GitHub Enterprise Cloud with data residency向けです。
対応リージョンは、2026年7月時点で米国と欧州連合です。ポリシーを有効にすると、コード、プロンプト、応答、推論処理、ログ、テレメトリが指定リージョン内に制限され、リージョン外でホストされるモデルは利用者のモデル選択画面に表示されなくなります。(GitHub Docs)
このポリシーは初期状態では無効です。また、データレジデンシー対応モデルを利用したリクエストは、AIクレジットの消費量が10%増加します。(GitHub Docs)
公式ドキュメントには日本リージョンが記載されていません。そのため、「日本国内で推論処理を完結させること」が社内規程や契約条件になっている組織は、GitHub Copilotを標準設定のまま導入可能と判断せず、情報セキュリティ部門や法務部門による確認が必要です。
管理者が利用できる制御
GitHub Copilot BusinessまたはEnterpriseでは、単にライセンスを配布するだけでなく、モデル、エージェント、予算、データ、監視をまとめて管理する必要があります。
| 管理項目 | 主な制御内容 | 実務上のポイント |
|---|---|---|
| モデルアクセス | 特定AIモデルの有効化・無効化 | 未評価の新モデルを全社公開しない |
| Copilot機能 | Chat、CLI、エージェントなどの利用可否 | 自律実行機能は通常のチャットと分けて判断する |
| AI利用予算 | 利用者、組織、コストセンター、エンタープライズ単位で上限設定 | 外れ値によるクレジット消費を抑える |
| データレジデンシー | 対応リージョン内のモデルへ制限 | コンプライアンス要件とコストを両方確認する |
| コンテンツ除外 | 特定ファイルやパスをCopilotの参照対象から除外 | Agent Modeなどでは適用されない点に注意する |
| 利用状況 | モデル別・機能別の利用傾向を確認 | 新モデル導入前後を比較する |
| 監査ログ | ポリシー変更、ライセンス変更、Web上のエージェント活動を記録 | ローカルで送信したプロンプト本文は記録されない |
Copilotのポリシーは、エンタープライズの「AI controls」または組織設定から管理できます。ポリシーはIDE、GitHub Web、Copilot CLIなど、利用者がCopilotへ認証する複数の場所に適用されますが、すべてのポリシーがすべてのクライアントで同じように機能するわけではありません。(GitHub Docs)
モデルを一律に有効化しない
新モデルが公開された直後は、次のような段階的な許可が安全です。
- AI推進担当者と一部の開発者だけに許可する
- 代表的なタスクで旧モデルと比較する
- コスト、品質、失敗率、トークン変動を確認する
- 適合するチームや作業だけに対象を広げる
- 問題があれば旧モデルへ戻せる状態を維持する
GitHub Copilot BusinessとEnterpriseでは、管理者が利用可能なモデルを制御できます。GitHubには、一定期間利用できるLTSモデルの考え方も用意されているため、再現性を重視する開発では、最新モデルだけでなく安定利用できるモデルを運用の基準にできます。(GitHub Docs)
予算は通知だけでなく停止条件まで設定する
GitHub Copilotの使用量ベース課金では、利用者、組織、コストセンター、エンタープライズ単位の予算制御を利用できます。
特に利用者単位の予算は、共有クレジットと追加課金の両方を対象とする強制停止です。1人の開発者や1回のエージェント実行が共有クレジットを大量に消費するリスクを抑えられます。(GitHub Docs)
一方、組織、コストセンター、エンタープライズ単位の予算では、「上限到達時に利用を停止する」設定が初期状態で無効です。この設定を有効にしなければ、表示上の予算を超えても追加料金が発生し続ける可能性があります。(GitHub Docs)
モデル評価期間は、次のような設定が現実的です。
- 全利用者に共通の利用者単位上限を設定する
- 評価担当者だけ個別に上限を引き上げる
- 部門別にコストセンターを分ける
- 追加課金の上限到達時には利用を停止する
- 新モデルの評価用クレジットを通常運用と分離する
コンテンツ除外を完全な情報漏えい対策と考えない
コンテンツ除外を設定すると、対象ファイルはインライン提案、Copilot Chatの回答、Copilotコードレビューなどの参照対象から外せます。
ただし、GitHub Copilot CLI、Copilot cloud agent、IDEのCopilot ChatにあるAgent Modeでは、コンテンツ除外がサポートされていません。また、IDEが型情報やビルド設定などを間接的に提供した場合、除外ファイルに由来する意味情報が使われる可能性もあります。(GitHub Docs)
そのため、認証情報、秘密鍵、個人情報、顧客データなどは、コンテンツ除外だけに頼らず、そもそもリポジトリへ保存しない運用が必要です。
利用状況と監査ログは役割が異なる
Copilot利用状況ダッシュボードでは、導入率、機能別利用、モデル別利用、プログラミング言語別の傾向などを確認できます。新モデル導入後に利用量だけが増え、コード採用や成果につながっていないケースを見つけるために利用できます。(GitHub Docs)
監査ログでは、ライセンス付与、ポリシー変更、設定変更、GitHub Web上のエージェント活動などを確認できます。ただし、利用者がローカルのIDEから送信したプロンプト本文は監査ログに含まれません。詳細なプロンプト監査が必要な場合は、別のログ収集方法を検討する必要があります。(GitHub Docs)
自社で対応が必要かを判断する基準
| 現在の利用状況 | 対応要否 | 推奨する対応 |
|---|---|---|
| GitHub Copilotを利用していない | 低い | 今回の情報だけを理由に対応する必要はない |
| コード補完だけを利用している | 低い | 将来ChatやAgent Modeを導入する際に再評価する |
| 個人契約で業務コードを扱っている | 高い | 法人管理ライセンスへの統一と学習利用設定を確認する |
| Business・Enterpriseで複数モデルを許可している | 高い | モデルポリシー、利用状況、予算を確認する |
| Agent Modeで大規模な更新を行っている | 非常に高い | 利用者単位の上限、テスト、承認手順を導入する |
| 新モデルを全社の標準にする予定がある | 非常に高い | 代表タスクによる比較評価を先に行う |
| 国内データ処理が必須である | 非常に高い | データレジデンシーの対応地域と契約条件を確認する |
| 機密ファイルをコンテンツ除外している | 高い | Agent ModeやCLIで除外が効かない点を再確認する |
今回の情報によって、すべての組織が直ちにClaude Sonnet 5を無効化する必要はありません。必要なのは、新モデルを「改善版」として無条件に扱わず、利用目的に応じて許可範囲を決めることです。
業務や開発での使いどころ
モデル選定では、「どのモデルが最も高性能か」ではなく、「どの作業で、どのモデルが安定して成果を出すか」を判断します。
| 作業 | 選び方の目安 | 確認すべきこと |
|---|---|---|
| Azureアーキテクチャ案の作成 | 旧モデルやAutoを含めて比較する | 既存パターン、セキュリティ、可用性に沿っているか |
| 設計書のたたき台 | 出力の一貫性が高いモデルを優先する | 同じ条件で結果が大きく変動しないか |
| バージョン指定の更新 | 指示追従性が高い新モデルを試す | 指定バージョンを勝手に変更していないか |
| 大規模なフレームワーク移行 | モデルより先に移行資料を整備する | 削除ファイル、構成変更、復旧手順が文書化されているか |
| テストコード作成 | コストと採用率を比較する | 生成量ではなく有効なテスト数を測る |
| 反復的なリファクタリング | トークン変動の小さいモデルを優先する | 外れ値実行が発生していないか |
| 未知の問題の調査 | 新モデルを予算上限付きで利用する | 深い調査が再現できるか |
| 本番コードの自動変更 | モデルを固定し、人による承認を必須にする | テスト、静的解析、セキュリティ検査を通過したか |
Microsoftの検証では、Claude Sonnet 5が約6,900万トークンを使って通常より深く調査し、30項目中21項目を満たした実行もありました。しかし、同じ深さは他の実行で再現されませんでした。1回の優れた結果だけでモデルを標準化してはいけない理由です。(Microsoft for Developers)
モデル更新を評価する実務手順
代表的なタスクを分類する
まず、実際にCopilotへ任せている作業を分類します。
- 設計や調査
- コード生成
- バージョン更新
- バグ修正
- テスト作成
- リファクタリング
- ドキュメント作成
- コードレビュー
評価用タスクは、簡単なデモではなく、実務で頻繁に発生する作業から選びます。
比較条件を固定する
モデル以外の条件が変わると、正しい比較ができません。
次の項目を揃えます。
- プロンプト
- 添付ファイル
- 開いているファイル
- リポジトリの状態
- 参照ドキュメント
- IDEと拡張機能のバージョン
- Agent Modeなどの動作モード
- 推論レベル
- 利用可能なツール
- ネットワークアクセスの有無
モデルごとに異なるプロンプト最適化を行う場合は、「共通プロンプトによる比較」と「モデル別に調整した比較」を分けて記録します。
同じタスクを複数回実行する
生成AIには出力の揺らぎがあります。1回だけの比較では外れ値を標準性能と誤認します。
Microsoftの検証と同様に、最低でも各モデル・各シナリオを5回程度実行し、重要な業務では10回以上の結果を確認すると判断しやすくなります。
品質とコストを同時に測る
評価項目は次のように設定します。
| 評価項目 | 判定例 |
|---|---|
| タスク選択 | 指示された作業に取り組んだか |
| 指示追従 | バージョン、対象範囲、禁止事項を守ったか |
| 技術的正確性 | ビルド、テスト、静的解析を通過したか |
| 慣例への適合 | チームの設計・実装パターンに沿っているか |
| セキュリティ | 秘密情報の露出や危険な処理がないか |
| 平均トークン数 | 通常時の消費量は許容範囲か |
| 最大・上位トークン数 | 外れ値実行による予算リスクがないか |
| 平均コスト | 1回の実行費用はいくらか |
| 採用結果当たりコスト | 実際に採用できた成果1件の費用はいくらか |
| 再試行率 | 人がやり直しを指示した割合はどの程度か |
| 所要時間 | 人の確認を含めて本当に短縮できたか |
単純な「1回当たり平均コスト」だけでなく、採用できた成果物1件当たりのコストを確認することが重要です。安価なモデルでも失敗や再試行が多ければ、最終的な費用と作業時間は増えます。
情報不足とモデル能力を分けて評価する
失敗した項目については、次のどちらかを切り分けます。
- 必要な情報は提供されていたが、モデルが理解・実行できなかった
- そもそも必要な情報がドキュメントやリポジトリに存在しなかった
後者であれば、モデル変更ではなく、ドキュメントやコンテキストの改善が先です。
小規模に展開してから標準化する
評価を通過したモデルでも、最初から全社標準にはしません。
一部のチームに限定して利用を開始し、次を継続的に確認します。
- 利用者数
- モデル別の使用量
- AIクレジット消費量
- 外れ値となる実行
- コード採用率
- 不具合の発生率
- レビュー工数
- セキュリティ上の問題
- 利用者からの再試行報告
問題が発生した場合に旧モデルへ戻せるよう、モデルポリシーと評価結果を記録しておきます。
失敗しやすい運用
最新モデルを自動的に標準モデルにする
モデル名の新しさは、自社タスクでの改善を保証しません。まず一部の利用者へ限定し、結果を比較します。
1トークン当たりの価格だけで判断する
総コストはトークン消費量と再試行回数で決まります。平均だけでなく、最大値や上位5%の実行も確認します。
1回の成功例をモデルの標準性能と考える
深く調査できた実行があっても、再現しなければ業務では使いにくいモデルです。複数回の成功率を評価します。
ドキュメント不足をモデルの性能問題と考える
必要な情報が存在しなければ、上位モデルでも正しい処理はできません。モデル更新前に、参照情報の完全性を確認します。(Microsoft for Developers)
コンテンツ除外がAgent Modeにも適用されると思い込む
Agent Mode、Copilot CLI、Copilot cloud agentはコンテンツ除外の対象外です。機密情報はアクセス権、リポジトリ分離、シークレット管理など、別の対策で保護します。(GitHub Docs)
予算を設定しただけで利用が止まると思い込む
組織やエンタープライズの予算は、停止設定を有効にしなければ上限を超えて課金が続く場合があります。予算額と停止動作をセットで確認します。(GitHub Docs)
モデル更新で最初に行うべきこと
「Not all model upgrades are upgrades」が示しているのは、古いモデルを使い続けるべきという結論ではありません。モデル更新を製品アップデートとして受け入れるのではなく、自社の作業に対する仮説として検証するべきという考え方です。
GitHub Copilotを業務利用している組織は、次の順番で対応します。
- Copilotに任せている代表的なタスクを洗い出す
- 旧モデルと新モデルを同じ条件で複数回比較する
- 品質、指示追従、トークン消費、外れ値を記録する
- 不足している手順書やリポジトリ情報を補う
- 管理者がモデルアクセスとAI利用予算を設定する
- データ処理場所とモデルプロバイダーを確認する
- 限定展開後に、用途別の標準モデルを決める
新しいモデルへ切り替えるか迷った場合は、「新しいか」「単価が安いか」ではなく、同じ業務を、必要な品質で、安定して、総コストを抑えて完了できるかを判断基準にしてください。
コメント