「新しいAIモデルは、ベンチマーク性能が高く、1トークン当たりの料金も安い。ならば、すぐに切り替えるべきではないか」と考えるのは自然です。しかし、Microsoftが2026年7月6日に公開したDeveloper AI model evaluationの検証結果は、新モデルへの更新が、総コストの増加やエージェント品質の低下につながる場合があることを示しました。
GitHub Copilot ChatでClaude Sonnet 4.6とClaude Sonnet 5を比較したところ、Sonnet 5は特定のコード更新で指示への追従性を高めた一方、アーキテクチャ設計では品質が低下し、同じプロンプトでもトークン消費量が大きく変動しました。したがって、AIモデル更新は単価表や公開ベンチマークだけで判断せず、自社のタスクを使って品質、総コスト、ばらつきを測定してから段階導入することが重要です。(Microsoft Developer)
なお、本件はMicrosoft製品の強制的な仕様変更や、新しい評価サービスの提供開始を告知するものではありません。ここでいうDeveloper AI model evaluationは、開発者向けAIエージェントを実際の開発タスクで比較評価する取り組みとして捉える必要があります。
MicrosoftのDeveloper AI model evaluationで何が分かったのか
Microsoftの検証では、Windows上のVisual Studio CodeとGitHub Copilot Chatを使用し、Claude Sonnet 4.6とClaude Sonnet 5を比較しています。
評価対象は、Microsoft Learnの情報を参照して行うAzureアーキテクチャ設計と、SharePoint Frameworkプロジェクトのアップグレードです。15シナリオについてモデルごとに5回実行し、合計150回のエージェントタスクが評価されました。(Microsoft Developer)
| 評価項目 | Claude Sonnet 4.6 | Claude Sonnet 5 |
|---|---|---|
| アーキテクチャのSelectゲート通過率 | 75% | 75% |
| アーキテクチャの出力品質 | 90% | 78% |
| アーキテクチャの平均コスト | 0.54ドル | 0.47ドル |
| コード更新のSelectゲート通過率 | 60% | 100% |
| コード更新の構成正確性 | 0% | 0% |
| コード更新の平均コスト | 0.55ドル | 2.01ドル |
ここで注意したいのは、Selectゲートの通過率が「完全に正しい成果物を生成した割合」ではない点です。MicrosoftはSelectゲートを、エージェントが要求されたタスクを適切に選択し、実行しようとしたかを確認する入口の評価として使用しています。
そのため、Sonnet 5のコード更新における100%という結果は、すべての移行作業が正しく完了したことを意味しません。実際には、構成ファイルやビルドツールを含む移行の正確性は、両モデルとも0%でした。(Microsoft Developer)
1トークン当たりの料金が安くても総コストは下がらない
検証時点でMicrosoftが比較に使った料金は、次のとおりです。
| トークン種別 | Claude Sonnet 4.6 | Claude Sonnet 5 |
|---|---|---|
| 入力100万トークン | 3ドル | 2ドル |
| キャッシュ済み入力100万トークン | 0.30ドル | 0.20ドル |
| 出力100万トークン | 15ドル | 10ドル |
Sonnet 5は各項目で約33%安く見えます。しかし、実際の支払額を決めるのは、単価だけではなく、エージェントがタスク完了までに消費するトークン数です。
Microsoftの検証では、Sonnet 5のトークン消費量は、アーキテクチャタスクで中央値がSonnet 4.6の12倍、コード更新では最大10倍の差になりました。その結果、コード更新の平均コストは0.55ドルから2.01ドルへ増え、単価の安いSonnet 5のほうが約3.7倍高くなっています。(Microsoft Developer)
Sonnet 5の低価格は期間限定である
Microsoftの記事で使われたSonnet 5の入力2ドル、出力10ドルという価格は、2026年8月31日までの導入価格です。Anthropicの公式情報では、その後、入力3ドル、出力15ドルの標準価格へ移行するとされています。
したがって、「Sonnet 5はSonnet 4.6より常に33%安い」という前提で長期コストを試算してはいけません。検証時点の価格、契約経路、キャッシュ利用率、入力と出力の比率を分けて計算する必要があります。(Claude Platform)
新しいトークナイザーも消費量に影響する
Claude Sonnet 5は新しいトークナイザーを使用します。Anthropicによると、同じテキストでもSonnet 4.6より約30%多くのトークンとして数えられます。増加率は、文章の内容やワークロードによって変わります。(Claude Platform)
ただし、トークナイザーの変更だけでは、Microsoftが確認した12倍という差を説明できません。これは推測を含みますが、新モデルが推論、ツール呼び出し、Web参照、再試行などをより長く続けるエージェント挙動も、トークン増加に関与した可能性があります。
AIモデル更新を評価するときは、単純なプロンプト文字数だけでなく、次の項目を分けて記録する必要があります。
- 入力トークン
- キャッシュ済み入力トークン
- 出力トークン
- 推論トークン
- エージェントのターン数
- ツール呼び出し回数
- Webやドキュメントの取得回数
- タスク全体の実行時間
- 1実行当たりの実コスト
同じプロンプトでもコストが大きく変動する
Sonnet 5で問題になったのは、平均的なトークン消費量だけではありません。実行ごとの差が大きく、コストを予測しにくいことも確認されました。
同じIoT分析アーキテクチャのシナリオでも、Sonnet 5は、ある実行で約1万6,000トークン、別の実行では約660万トークンを消費しています。また、SPFx更新では、1回の実行で6,900万トークンを使い、通常より深く未文書化の情報を探索した例もありました。
ただし、この深い探索は同じ条件のほかの実行では再現されていません。1回だけ高品質な結果が出ても、安定して再現できなければ、本番システムの標準モデルとしては扱いにくいということです。(Microsoft Developer)
小規模な検証では中央値、最小値、最大値、実行範囲を確認し、実行件数が増えた本番パイロットでは95パーセンタイルなども確認するとよいでしょう。平均値だけを見ると、少数の極端な実行や、不安定なエージェント挙動を見落とします。
新しいモデルが明確に優れていたタスクもある
Microsoftの検証は、Sonnet 5が全面的に劣ることを示したものではありません。特定のバージョンや条件を厳密に守らせるタスクでは、Sonnet 5が優れた結果を出しています。
SPFx 1.21.1から1.22.0への更新を指示したシナリオでは、Sonnet 4.6は5回すべてで、Microsoft Learnに記載されていた1.22.1を選択しました。一方、Sonnet 5は5回すべてで、ユーザーが明示した1.22.0を選択しています。
つまり、参照文書の記述よりユーザーの明示的な指示を優先する必要がある場面では、Sonnet 5の指示追従性が有効に働きました。(Microsoft Developer)
一方、アーキテクチャや設計パターンの評価では、Sonnet 4.6がSonnet 5と同等以上だったシナリオが9件中8件ありました。AIモデルの能力は一方向に向上するとは限らず、タスクの種類によって優劣が入れ替わります。
| タスクの特徴 | Microsoftの検証から読み取れる傾向 |
|---|---|
| 特定バージョンや条件への厳密な追従 | Sonnet 5が有利になる可能性 |
| 一般的なアーキテクチャ設計 | Sonnet 4.6が同等以上だった |
| 長時間の自律探索 | Sonnet 5が深く探索する場合がある |
| 予算を重視する大量処理 | トークン変動の大きさに注意 |
| 文書化されていない構造変更 | モデル更新だけでは解決しない |
モデルを更新しても情報不足は解消できない
SPFx更新シナリオでは、Sonnet 4.6とSonnet 5のどちらも、gulpからHeftへの移行や、従来形式からflat configへのESLint移行を完全には実行できませんでした。
Microsoftは、ビルドツールのフラグ、パッケージ構造、不要ファイルの削除、構成形式の変更など、必要な7つの具体的な変更が文書内にまとまっていなかったと説明しています。モデルが参照できる情報に不足があれば、より新しいモデルへ切り替えても正答率は上がりません。(Microsoft Developer)
この場合、モデル更新より先に、次の対策を検討するべきです。
- 移行手順を一つの文書に整理する
- 正しい完成形のサンプルリポジトリを用意する
- AGENTS.mdや指示ファイルに必須手順を記載する
- MCPサーバーやスキルから最新情報を提供する
- 構成ファイルを機械的に検証するツールを追加する
- ビルド、テスト、Lintをエージェントの完了条件にする
Microsoftは、モデル自体を変更するより、エージェントが利用できる文書や拡張機能を改善したほうが、費用対効果が高い場合があると指摘しています。(Microsoft Developer)
既存実装との互換性は3つの層で判断する
AIモデルの互換性は、APIが呼び出せるかどうかだけでは判断できません。少なくとも、API互換性、エージェント互換性、成果物の互換性を分けて確認する必要があります。
| 互換性の層 | 確認する内容 |
|---|---|
| API互換性 | リクエスト形式、パラメーター、モデルID、エラー処理 |
| エージェント互換性 | ツール選択、推論量、ターン数、指示追従性 |
| 成果物の互換性 | コード、構成ファイル、依存関係、設計規約、セキュリティ |
Claude APIでは一部のパラメーター変更が必要
AnthropicはSonnet 5をSonnet 4.6からのドロップインアップグレードと位置付けていますが、無条件にモデルIDだけを変更できるわけではありません。
主な動作差分は次のとおりです。
- 適応的思考がデフォルトで有効になる
- 非デフォルト値の
temperature、top_p、top_kを指定すると400エラーになる budget_tokensを使った従来の手動拡張思考は400エラーになる- 同じテキストでもトークン数が約30%増える
max_tokensの設定によっては出力が途中で切れる- 高リスクなサイバーセキュリティ要求は、HTTP 200と
stop_reason: "refusal"で拒否される場合がある
リクエスト、レスポンス、ストリーミングイベントの基本形式は維持されますが、既存コードが非デフォルトのサンプリング値や手動思考予算を指定している場合は、移行前の修正が必要です。(Claude Platform)
APIが動いても成果物の互換性は保証されない
APIリクエストが成功し、同じJSON形式のレスポンスを受け取れても、生成コードの内容やツールの使い方は変わります。
モデル更新後には、次のような回帰が起こり得ます。
- 指定していないファイルまで変更する
- 既存の設計パターンを別方式へ置き換える
- ツール呼び出しやWeb検索が増える
- タスク終了までのターン数が増える
- セキュリティ処理や例外処理を省略する
- 依存パッケージのバージョンを変更する
- 同じ指示でも毎回異なる方法を選ぶ
そのため、APIの疎通テストだけでなく、既存の開発タスクを使った成果物レベルの回帰テストが必要です。
GitHub Copilot Chatで試すための利用条件
GitHub Copilot Chatで利用できるモデルは、Copilotプラン、使用するクライアント、組織や企業のポリシーによって変わります。Copilot BusinessやCopilot Enterpriseでは、組織管理者がモデル切り替えを許可する必要があります。(GitHub Docs)
また、次の点にも注意してください。
- Chatで変更したモデルは、インライン補完のモデルには反映されない
Autoでは利用状況やレート制限に応じてモデルが選ばれる- Copilot Extensionsが選択したモデルを上書きする場合がある
- クライアントによって選択可能なモデルが異なる
モデル比較を行うときにAutoを選ぶと、どのモデルを評価したのか分からなくなる可能性があります。検証ではモデルを明示的に固定し、新しいチャットセッションから開始するのが安全です。(GitHub Docs)
Microsoft Foundry経由で利用する場合
Microsoft Foundryの現行ドキュメントでは、Claude Sonnet 5は一般提供として掲載され、100万トークンのコンテキストウィンドウと最大12万8,000出力トークンをサポートしています。
Claudeモデルはパートナー提供モデルとして扱われるため、利用にはAzure Marketplaceのサブスクリプションと、モデルオファーを契約・展開できる権限が必要です。(Microsoft Learn)
ただし、Microsoftの今回の結果はGitHub Copilot Chat、Visual Studio Code、Windowsを組み合わせた評価です。Microsoft FoundryからAPIを直接呼び出した結果と同一になるとは限りません。モデルが同じでも、システムプロンプト、ツール、コンテキスト構築、実行環境を管理するハーネスが違えば、エージェントの動作は変わります。(Microsoft Developer)
AIモデル更新を評価する実践手順
実際に使う3～5個のシナリオを選ぶ
最初から大量のテストケースを作る必要はありません。まずは、開発者が日常的に行う3～5個のタスクを選びます。
例えば、次のようなシナリオです。
- 既存APIへ認証機能を追加する
- 指定バージョンへ依存関係を更新する
- 社内SDKを使った機能を実装する
- 既存コードをチームの設計規約に合わせる
- 複数ファイルにまたがる不具合を修正する
簡単すぎてすべてのモデルが成功するタスクや、すべてのモデルが失敗するほど難しいタスクは、モデル差を判断しにくくなります。実務で頻度が高く、モデルの違いが結果に表れやすいタスクを選びます。(Microsoft Developer)
モデル以外の条件を固定する
比較時には、モデル以外の変更をできるだけ排除します。
記録しておきたい条件は次のとおりです。
- OSとバージョン
- Visual Studio Codeなどのクライアントバージョン
- GitHub Copilot拡張機能のバージョン
- 使用モデルとモデルバージョン
- reasoningまたはeffortの設定
- システムプロンプト
- AGENTS.mdや指示ファイル
- MCPサーバーと利用可能なツール
- LSP、Lint、ビルドツールのバージョン
- 依存関係とロックファイル
- 参照ドキュメントのスナップショット
- ワークスペースの初期状態
OSが違えばシェルが変わり、LSPや拡張機能が違えば、エージェントが受け取る診断情報も変わります。Microsoftは、評価環境を実際の利用者に合わせ、環境情報をマニフェストとして保存することを推奨しています。(Microsoft Developer)
プロンプトと採点基準を分離する
エージェントへ渡すプロンプトに、評価基準や正解条件をそのまま書いてはいけません。採点表をプロンプトに含めると、実務能力ではなく、モデルが採点表に合わせられるかを測るテストになってしまいます。
プロンプトには、実際の開発者が入力する依頼だけを書きます。評価基準は、エージェントから見えない別の設定として管理します。(Microsoft Developer)
合格条件を具体的にする
「適切に実装されている」「良い設計になっている」といった基準は、評価者によって判定が変わります。
例えば、認証処理なら次のように具体化します。
- APIキーがソースコードに直接記述されていない
- 秘密情報をログへ出力していない
- 認証失敗時に所定のステータスコードを返す
- トークンの有効期限を検証している
- 認証処理を回避できる経路が存在しない
各項目に「合格」「不合格」「評価対象外」の条件を定義します。LLMを採点者として使う場合も、曖昧な総合評価ではなく、個別項目を一つずつ判定させるほうが安定します。(Microsoft Developer)
1シナリオにつき最低5回実行する
生成AIは、同じモデル、同じプロンプト、同じ環境でも結果が変わります。1回の成功や失敗だけでモデルを判断してはいけません。
Microsoftは、1条件につき最低5回実行すると、安定して成功するのか、安定して失敗するのか、不安定なのかを判断しやすくなると説明しています。5回の結果が割れた場合は、追加実行して傾向を確認します。(Microsoft Developer)
品質、コスト、安定性を別々に評価する
最終的な比較表には、少なくとも次の項目を含めます。
| 評価軸 | 確認内容 |
|---|---|
| タスク選択 | 要求された作業を正しく理解したか |
| 機能正確性 | 必要な機能が動作するか |
| 構成正確性 | 設定ファイルやビルド構成が正しいか |
| 指示追従性 | バージョンや制約を守ったか |
| 設計品質 | 既存パターンや規約に従っているか |
| セキュリティ | 秘密情報や権限処理に問題がないか |
| 総コスト | タスク完了までに実際にかかった費用 |
| トークン変動 | 実行間の中央値、範囲、最大値 |
| 所要時間 | タスク完了までの時間 |
| 再現性 | 複数回で同等の結果を出せるか |
品質を一つの平均点にまとめると、重大な失敗が隠れます。ビルド成功、指定バージョンの遵守、秘密情報の非露出など、必須項目は個別の合格条件として扱うべきです。
テストで失敗しやすいポイント
| 失敗例 | 問題点 | 対策 |
|---|---|---|
| 1回だけ実行する | 偶然の成功や失敗を評価してしまう | 各条件を最低5回実行する |
Autoで比較する | 実際に使われたモデルを固定できない | モデル名を明示して新規セッションを使う |
| 平均コストだけを見る | 極端に高い実行を見落とす | 中央値、範囲、最大値も確認する |
| 単価だけで判断する | トークン増加やターン数を考慮できない | タスク全体の実コストを測る |
| 古いトークン見積もりを使う | 新トークナイザーとの差を反映できない | Sonnet 5で再カウントする |
| OSや拡張機能を変えて比較する | モデル以外の差が結果へ混入する | 環境を固定して記録する |
| 採点基準をプロンプトへ書く | 採点表への適応を測るテストになる | プロンプトと評価ルーブリックを分離する |
| LLMに計算まで任せる | 集計やバージョン比較を誤る場合がある | 数値計算やSemVer比較はコードで行う |
| 文書不足をモデルの問題にする | どのモデルも正しい情報を取得できない | 先に文書、サンプル、ツールを整備する |
| モデルとプロンプトを同時に変更する | 改善原因を特定できない | 1回の比較では1変数だけ変える |
Microsoftの検証では、各モデルのデフォルトのreasoningレベルが使用されました。したがって、今回の結果は「各モデルを標準設定で使った場合」の比較であり、reasoningやeffortを同じ方針に調整した比較ではありません。設定可能な環境では、デフォルト同士の比較に加え、reasoning方針を固定した比較も行うと、原因を切り分けやすくなります。(Microsoft Developer)
また、Microsoftの記事では、アーキテクチャタスクのトークン中央値が12倍だった一方、平均コストはSonnet 5のほうが低いという集計結果が示されています。中央値と平均値は異なる統計であり、入力、キャッシュ入力、出力の構成も異なります。公開記事には各実行の詳細データが掲載されていないため、この集計値をそのまま自社の料金予測へ当てはめるべきではありません。
対応が必要かを判断する基準
| 利用状況 | 対応要否 | 推奨対応 |
|---|---|---|
| Sonnet 4.6を継続し、切り替え予定がない | 緊急対応は不要 | 現行品質とコストを基準値として保存 |
| Sonnet 5をCopilotの標準モデルにしたい | 対応が必要 | 自社シナリオで比較し、小規模パイロットを実施 |
| Claude APIのモデルIDを切り替える | 対応が必要 | thinking、サンプリング値、トークン上限を確認 |
| 大量の自律エージェントを運用する | 優先度が高い | 最大消費量、実行上限、予算停止を設定 |
| 厳密なバージョン指定が多い | 試す価値がある | 指示追従性を重点評価 |
| 設計提案やアーキテクチャ生成が中心 | 慎重な比較が必要 | 既存モデルを残したまま品質を比較 |
| 移行手順が文書化されていない | モデル変更より文書整備を優先 | 手順、完成例、構成差分を提供 |
| 手作業のチャット利用が中心 | 影響は限定的 | 用途別にモデルを使い分ける |
企業全体へ一度に展開するのではなく、少人数または一つの組織へ限定してモデルを有効化し、ポリシーと予算を先に設定する方法が安全です。GitHubの公式ガイドでも、パイロット組織だけにモデルを許可し、費用上限と利用停止設定を組み合わせ、実績を確認してから展開範囲を広げる方法が案内されています。(GitHub Docs)
モデル更新は「製品のバージョンアップ」ではなく「システム変更」として扱う
今回のDeveloper AI model evaluationが示した重要な点は、AIモデルの性能を一つの数字で表せないことです。
Sonnet 5は、厳密な指示追従では改善を示しました。一方で、アーキテクチャ品質が下がり、コード更新の総コストが増え、同一プロンプトでもトークン消費が大きく変動しました。さらに、参照文書に必要情報がなければ、新旧どちらのモデルも正しい移行を完了できませんでした。
まず現在のモデルで、実務を代表する3～5個のシナリオを実行し、品質、トークン、コスト、所要時間を基準値として保存します。その後、同じ環境、同じプロンプト、同じ評価基準で新モデルを各5回以上実行してください。
品質の必須条件を満たし、総コストと最大消費量が許容範囲に収まり、複数回で結果を再現できた場合にだけ、小規模なパイロットへ進めます。モデル更新は「新しいから採用する」のではなく、「自社の重要タスクで改善を確認できたから採用する」ことが基本です。
コメント