2026年7月8日、Microsoftはコーディングエージェント評価を歪める「隠れた変数」に関する公式ガイダンスを公開しました。結論から言えば、今回の情報は新しいAPIやSDKの提供、既存機能の廃止を告知するものではありません。対応が必要なのは、AIコーディングエージェントのモデル、拡張機能、プロンプト、MCPツールなどをスコアで比較している開発チームです。
同じモデルとシナリオを使っていても、OS、シェル、作業ディレクトリ名、ユーザー名、LSP、IDE拡張機能、実行時点のバージョン状態によって結果が変わる可能性があります。そのため、既存の評価コードを直すこと以上に、評価環境を固定し、実行条件を記録し、実際の利用環境に合わせて結果を解釈することが重要です。(Microsoft Developer)
Microsoftのコーディングエージェント評価ガイダンスで何が変わるのか
Microsoftが示したのは、コーディングエージェント評価における再現性の考え方の見直しです。
従来は、次の項目を固定すれば公平に比較できると考えがちでした。
- 使用するAIモデル
- 評価ハーネス
- ユーザープロンプト
- ワークスペースのファイル
- インストール済みの拡張機能
- 合否判定の基準
しかし、実際のエージェントはこれら以外の情報も参照しています。システムプロンプトに含まれるOSや作業ディレクトリ、コマンドの実行結果、ビルドエラー、言語サーバーから返される診断情報なども、次の判断に影響します。
| 評価項目 | 従来見落とされやすかった点 | 今後の管理方針 |
|---|---|---|
| OS | 単なる実行基盤として扱う | シェルや技術選択に影響する変数として記録する |
| シェル | コマンド構文だけの違いと考える | エラー回復や複数コマンドの実行能力も含めて評価する |
| ユーザー名 | 評価結果と無関係と考える | クラウド名や製品名を含まない中立的な名前にする |
| 作業パス | ファイルの保存場所にすぎない | testやpocなど意味を持つ単語を避ける |
| LSP | IDEの補助機能として扱う | エージェントの自己修正能力を左右する構成要素として扱う |
| IDE拡張機能 | 開発者側だけの利便機能と考える | 診断やコンテキスト供給の有無を記録する |
| 実行時点 | 同じモデル名なら同条件と考える | モデル、ハーネス、拡張機能の更新状態を記録する |
| 依存関係 | ロックファイルの有無を深く区別しない | 何の能力を測るかに応じて意図的に選択する |
重要なのは、評価対象の範囲がモデル単体から、モデルを取り巻く実行環境全体へ広がったことです。モデル、プロンプト、ハーネスだけが同じでも、すべての入力条件が同じとは限りません。(Microsoft Developer)
APIやSDKの仕様変更ではなく、評価運用の更新
今回の公式記事では、新しいAPIバージョン、SDK、評価ファイル形式、ライセンス、段階的ロールアウトなどは発表されていません。Developer AI and agent evaluationという新製品が導入されるのではなく、AIコーディングエージェントを適切に評価するための設計・運用ガイダンスです。(Microsoft Developer)
したがって、既存実装への影響は次のように整理できます。
| 対象 | 互換性への影響 |
|---|---|
| 既存の評価スクリプト | 原則としてそのまま実行できる |
| モデル呼び出しコード | 当該記事を理由とする変更は不要 |
| エージェント用プロンプト | 直ちに変更する必要はない |
| 過去の評価結果 | 実行環境が不明な場合、現在の結果と単純比較しにくい |
| CI上の評価 | 動作はするが、実際のIDE利用体験を再現しているとは限らない |
| 評価レポート | OS、ツール、モデル、ハーネス、LSP情報の追加が望ましい |
| モデル選定プロセス | 単一スコアではなく、環境別の結果を確認する必要がある |
つまり、実行互換性は維持される一方、評価結果の比較可能性を見直す必要があるという更新です。
過去のスコアが直ちに無効になるわけではありません。ただし、OSやハーネス、LSPなどの条件が記録されていなければ、そのスコアがモデル性能を示しているのか、環境差を示しているのかを後から切り分けられません。
評価結果を歪める主な隠れた変数
OSとシェルがエージェントの行動経路を変える
WindowsではPowerShell、macOSやLinuxではbashやzshが使われやすくなります。これは単なるコマンド表記の違いではありません。
シェルが変わると、次の動作も変化します。
- コマンドの連結方法
- 標準出力やエラー出力の解析
- ビルド失敗後の再試行
- ファイル検索や置換の方法
- スクリプト生成の正確性
- 複数ターンにわたる修正経路
Microsoftが複数モデルで同一プロンプトを試した例では、Windows上では.NET、Linux上ではPythonやNode.jsが選ばれるなど、OSによって技術スタックの選択まで変わるケースが確認されています。
特に「REST APIを作成して」のように言語やランタイムを指定しないプロンプトでは、OSが技術選定の決め手になる可能性があります。一方、「ASP.NET Coreで本番用REST APIを作成して」のように条件を明示すれば、OSによる影響は小さくなります。(Microsoft Developer)
これは、プロンプトを詳しくすれば常に正しいという意味ではありません。
「エージェントが標準でどの技術を選ぶか」を測りたい場合、言語を指定しすぎると測定対象そのものが変わります。評価前に、デフォルト選択を測るのか、特定技術での実装品質を測るのかを決める必要があります。
作業パスやユーザー名にも意味がある
絶対パスは、エラーメッセージ、ビルドログ、検索結果、LSPの診断情報などに繰り返し登場します。パスに含まれる単語は、意図せずエージェントへの追加指示として働く可能性があります。
Microsoftの例では、ユーザー名がazureuserになっている環境で、クラウドを指定しない評価を実行したところ、エージェントがAzureを選択しました。この結果だけでは、モデル本来の選好なのか、パス内のazureに誘導されたのか判断できません。(Microsoft Developer)
次のようなディレクトリ名にも注意が必要です。
testdemopocprototypesample- 特定クラウドや製品の名称
- 顧客名やプロジェクト名
productionやenterpriseのような品質水準を示す単語
たとえば、/home/evaluser/test/poc-apiというパスは、「使い捨ての試作コードを作る」という文脈を暗黙に与える可能性があります。その結果、認証、構成管理、詳細なエラー処理、監視などが省略されても、モデル能力の不足とは断定できません。
評価用パスには、次のような意味的に中立な名前を使うのが安全です。
/workspace/projectWindowsの場合も、次のように用途や製品を示さない構成にします。
C:\workspace\project結果が出た後にパス文字列を削除するのではなく、実行前から意味を持たないパスを使うことが重要です。(Microsoft Developer)
LSPとIDE拡張機能が自己修正能力を変える
LSPはLanguage Server Protocolの略で、入力中のコードに対して型エラーや構文上の問題などを通知する仕組みです。
コーディングエージェントがLSPの診断を取得できる環境では、コードを生成している途中で問題を認識し、同じターンの中で修正できる場合があります。利用者から見ると、最初から正しいコードが生成されたように見えます。
一方、LSPがないCIコンテナでは、同じ問題がビルド時まで残ります。修正には追加ターンが必要となり、状況によっては修正されないまま評価が終了します。
結果に影響するのは、LSPの有無だけではありません。
- 言語サーバーのバージョン
- 型定義ファイル
tsconfig.jsonなどのコンパイラ設定- strictモードの有無
- ESLintなどの静的解析
- IDEにインストールされた拡張機能
- プロジェクト固有の診断設定
- クイックフィックスの内容
初期段階で1つの型エラーを修正できるかどうかが、その後の複数ターンの実装経路を変えることがあります。そのため、LSP構成は単なる補助設定ではなく、エージェント評価環境の一部です。(Microsoft Developer)
自動更新によって同じ評価が別条件になる
IDE、エージェント拡張機能、CLI型エージェント、評価ハーネスは自動更新されることがあります。
更新によって変わり得るのは、画面やコマンドだけではありません。
- システムプロンプト
- コンテキストの組み立て方
- ツール説明の優先順位
- コンテキストから省略される情報
- ツール選択ロジック
- エラー処理
- ターン管理
- ファイルの探索方法
同じモデル名を指定していても、火曜日と木曜日で拡張機能やハーネスが変わっていれば、厳密には同一条件の比較ではありません。Microsoftは、スコアが動いたときにモデルや自社拡張機能の効果だと判断する前に、ハーネスや周辺環境のバージョン変更を確認するよう促しています。(Microsoft Developer)
ロックファイルの有無は優劣ではなく評価目的で決める
依存パッケージのロックファイルを置けば、同じバージョンを解決しやすくなり、再現性が高まります。
ただし、ロックファイルを置かない評価にも意味があります。エージェント自身にライブラリやバージョンを選ばせることで、依存関係の選定能力を測れるからです。
| 評価したい内容 | ロックファイル |
|---|---|
| コード生成品質を安定した条件で比べたい | あり |
| モデル変更による差だけを確認したい | あり |
| 特定SDKの正しい利用方法を評価したい | あり |
| 適切な依存パッケージを選べるか確認したい | なし |
| 新規プロジェクトを一から構成する能力を測りたい | なしも検討 |
| 開発者の既存リポジトリでの体験を再現したい | 実際のリポジトリ構成に合わせる |
ロックファイルの有無に絶対的な正解はありません。問題なのは、異なる能力を測っていることに気付かず、同じ指標として比較することです。(Microsoft Developer)
対応が必要な組織と不要な組織
優先的に見直すべきケース
次のいずれかに該当する場合は、評価環境の見直しを優先すべきです。
- モデルAとモデルBをスコアで比較している
- モデルのアップグレード可否を自社評価で決めている
- MCPサーバーやエージェント拡張機能の効果を測っている
AGENTS.mdなどの指示ファイルをA/Bテストしている- 開発者はWindowsを使うが、評価はLinux CIだけで実施している
- IDE型エージェントとCLI型エージェントを同じ指標で比較している
- 複数の開発者PCで評価を分担している
- モデル名、OS、ハーネス、LSPのバージョンを記録していない
- 数ポイントのスコア差を採用判断の根拠にしている
- 自動更新を有効にしたまま継続評価している
公開ベンチマークはモデル候補を絞る材料にはなりますが、自社のSDK、拡張機能、独自コード、実際のハーネスでの性能までは保証しません。Microsoftは、自社の代表的なシナリオを使った比較をモデル選定の最終判断に利用する考え方を示しています。(Microsoft Developer)
直ちに対応する必要がないケース
次のケースでは、緊急の対応は不要です。
- コーディングエージェントの定量評価を実施していない
- 個人が補助的に利用しており、スコアで採用判断をしていない
- 評価結果を外部や経営判断に利用していない
- 同じPC上で簡易的な動作確認だけをしている
- モデル比較ではなく、明確な受け入れテストだけを行っている
ただし、将来的にモデルやエージェント製品の選定に評価結果を使う予定があるなら、最初から環境情報を保存しておく方が低コストです。
導入条件はライセンスではなく評価環境の管理能力
今回のガイダンスを取り入れるために、新しいMicrosoft製品の契約や特別なライセンスは必要ありません。
必要なのは、次の条件です。
- 評価対象となる利用者像を定義できる
- OSやツールのバージョンを確認できる
- コンテナまたは仮想マシンを用意できる
- 中立的なユーザー名と作業パスを利用できる
- LSPやIDE拡張機能の構成を記録できる
- モデルやハーネスの識別情報を取得できる
- 同じシナリオを繰り返し実行できる
- 実行結果と環境情報をひも付けて保存できる
モデルプロバイダー側の更新など、固定できない変数もあります。その場合は、無理に完全固定しようとするのではなく、取得可能なモデル識別子、実行日時、クライアントバージョン、レスポンスメタデータを保存します。
再現性と実利用環境を両立する2系統の評価
実務では、「完全に固定された環境」と「開発者が実際に使う環境」が一致しないことがあります。
たとえば、コンテナ内にすべてを固定すれば再現性は高まります。しかし、開発者がWindows上のIDEでLSPや多数の拡張機能を使っている場合、簡素なLinuxコンテナだけでは実際の体験を測れません。
この問題は、評価を2系統に分けると整理しやすくなります。
再現性ベースライン
モデルやプロンプトの変更による差を検出するための環境です。
- コンテナまたは仮想マシンを使用
- OSイメージを固定
- 中立的なユーザー名とパスを使用
- ツールとLSPのバージョンを固定
- ロックファイルを使用
- 自動更新を無効化
- 評価条件を毎回保存
利用者代表環境
実際の開発者体験を測るための環境です。
- 利用者が多いOSを使用
- 実運用と同じIDEまたはCLIを使用
- 実際に利用するLSPと拡張機能を導入
- 社内の指示ファイルやMCP構成を反映
- Windows、macOS、Linuxなど主要構成を別々に集計
- 実際の更新周期も考慮して定期的に再評価
Microsoftは、まず評価環境を対象利用者に合わせ、そのうえで制御可能な変数を固定することを重視しています。OSとハーネスの違いは特に大きな分散要因になり得るため、LinuxのCLI環境で得た改善率を、そのままWindowsのIDE利用者へ一般化しないことが重要です。(Microsoft Developer)
既存の評価環境を見直す手順
評価で測りたい能力を一文で定義する
最初に、評価目的を具体化します。
悪い例は、「どのモデルが優秀かを調べる」です。測定範囲が広すぎるため、結果を行動につなげられません。
次のように定義します。
- 特定の社内SDKを正しく利用できるか
- エージェントが適切なクラウドを自律的に選べるか
- Windows上でPowerShellを使って問題を解決できるか
- IDEのLSP診断を利用して型エラーを自己修正できるか
- MCPツール追加によって必要ターン数が減るか
- 新モデルで認証実装の成功率が向上するか
曖昧なプロンプトは、エージェントが自力で技術やツールを発見する傾向を測るのに向いています。特定のSDKやライブラリを明示したプロンプトは、その技術を使った実装品質の測定に向いています。両者を混ぜて1つのスコアにしないことが重要です。(Microsoft Developer)
既存評価の隠れた変数を棚卸しする
最低限、次の項目を確認します。
| 分類 | 確認項目 |
|---|---|
| OS | 製品名、エディション、ビルド、アーキテクチャ |
| シェル | PowerShell、bash、zshなどの種類とバージョン |
| ユーザー | ユーザー名に意味のある単語が含まれていないか |
| パス | test、poc、製品名、クラウド名が含まれていないか |
| モデル | プロバイダー、モデル名、バージョンまたはスナップショット |
| ハーネス | 製品名、クライアント、バージョン |
| IDE・CLI | 実行クライアントとバージョン |
| LSP | 言語サーバーとバージョン |
| 拡張機能 | 名前、バージョン、有効・無効 |
| ランタイム | Node.js、.NET、Python、Javaなど |
| 依存関係 | ロックファイルの有無とハッシュ |
| 入力 | プロンプト、ワークスペース、指示ファイルのリビジョン |
| 時刻 | 実行日時とタイムゾーン |
| 出力 | 成否、ターン数、コスト、生成ファイル、ログ |
中立的な評価環境を作る
まず1つの再現可能なベースラインを作成します。
- ユーザー名を
evaluserなどに統一する - 作業パスを
/workspace/projectなどに統一する - OSイメージを固定する
- ランタイムとパッケージマネージャーを固定する
- LSPと拡張機能のバージョンを固定する
- プロンプトとワークスペースをGitで管理する
- 自動更新を停止するか、更新状態を記録する
- 依存関係の固定方針をシナリオごとに定義する
環境マニフェストを評価結果に添付する
Microsoftは、各評価結果にOS、ツール、モデル、ハーネス、LSP構成を含む環境マニフェストを付けることを推奨しています。(Microsoft Developer)
次は独自に管理する場合の記録例です。Microsoftが定めた公式スキーマではありません。
eval_run:
scenario_id: "rest-api-001"
started_at: "<ISO-8601-date-time>"
audience_profile: "windows-ide"
run_number: 1
environment:
os: "<os-name-edition-build>"
architecture: "<architecture>"
shell: "<shell-name-and-version>"
user: "evaluser"
workspace_path: "C:\\workspace\\project"
agent:
model_provider: "<provider>"
model: "<model-name>"
model_version: "<version-or-snapshot>"
harness: "<harness-name-and-version>"
client: "<ide-or-cli-name-and-version>"
tooling:
lsp: "<language-server-and-version>"
runtime: "<runtime-and-version>"
extensions:
- "<extension-name-and-version>"
dependencies:
mode: "locked"
lockfile_hash: "<sha256>"
inputs:
prompt_hash: "<sha256>"
workspace_revision: "<git-commit>"
instruction_file_hash: "<sha256>"
result:
status: "<pass-fail-error>"
turns: "<number>"
token_usage: "<number>"
cost: "<amount>"モデルバージョンを取得できない場合は、モデルのエイリアス、実行日時、プロバイダーから返された識別情報を保存します。空欄のままにするより、「取得不能」と明示した方が後の分析に役立ちます。
過去の結果と新しいベースラインを分ける
環境情報を記録していなかった過去の評価は、削除する必要はありません。ただし、次のように区別します。
legacy-unmanifested
baseline-v1
baseline-v2
windows-ide-v1
linux-cli-v1過去データは傾向を見る参考値として残し、新しいベースラインとの直接比較には使わない運用が安全です。
同一シナリオを複数回実行する
生成AIには実行ごとのばらつきがあります。1回だけの成功や失敗をモデル能力として扱わないことが重要です。
Microsoftが2026年7月15日に公開した続編では、各シナリオを少なくとも5回実行し、差が信号なのかノイズなのかを確認するよう案内しています。(Microsoft Developer)
比較時には、成功率だけでなく次の指標も記録します。
- 合格回数
- 実行エラー回数
- 中央値
- スコアの最小値と最大値
- ターン数
- トークン使用量
- 実行コスト
- ビルド成功率
- テスト成功率
- 人手修正が必要だった回数
平均値だけでは、安定して70点を取るモデルと、40点から100点まで大きく変動するモデルを区別しにくくなります。
比較時は原則として1変数だけ変更する
モデル変更の効果を測るなら、モデル以外を固定します。
MCPサーバーの効果を測るなら、MCPサーバーの有無だけを変更します。
プロンプト改善を測るなら、OS、モデル、ハーネス、ワークスペース、LSPを同じにします。
複数の変数を同時に変えた場合は、「新構成全体の比較」として扱い、モデル単体や拡張機能単体の改善率とは表現しないようにします。
目的別のテスト構成例
| 評価目的 | プロンプト | 実行環境 | ロックファイル | 結果の使い方 |
|---|---|---|---|---|
| デフォルト技術選択 | 言語やクラウドを指定しない | 中立パスでOS別に実行 | 課題に応じる | OSごとの選択傾向を見る |
| 特定SDKの利用品質 | SDK、言語、要件を明示 | 固定したベースライン | あり | モデルや指示ファイルを比較 |
| 実際のIDE体験 | 開発者が使う自然な指示 | 実運用と同じIDE、LSP、拡張機能 | 実リポジトリに合わせる | 利用者体験を評価 |
| CLI操作能力 | 完了条件だけを指定 | シェル別に実行 | あり | コマンド実行とエラー回復を比較 |
| 依存関係の選定能力 | 必要機能だけを指定 | ランタイムのみ固定 | なし | 選定理由、保守性、安全性を確認 |
| 拡張機能の効果 | 同一プロンプト | 拡張機能の有無だけ変更 | あり | 成功率、ターン数、コストを比較 |
すべての結果を1つの総合点にまとめるより、「Windows IDE」「macOS IDE」「Linux CLI」などのプロファイル別に報告した方が、利用者への影響を判断しやすくなります。
テスト時に失敗しやすいポイント
| 失敗例 | 問題点 | 改善方法 |
|---|---|---|
| 開発者はWindowsなのにLinux CIだけで評価する | PowerShellやIDE固有の体験を測れない | Windows IDE環境の評価を追加する |
poc-apiなどのパスを使う | 試作品として振る舞うよう誘導する可能性がある | 中立的なパスへ変更する |
| LSPなしのコンテナだけで比較する | 実環境の自己修正能力を過小評価する | LSPあり・なしを別プロファイルにする |
| 自動更新後も同じベースラインとして扱う | ハーネスや拡張機能の差を見落とす | バージョン変更時にベースラインを更新する |
| 毎回1回だけ実行する | 偶然の成功や失敗を拾う | 同じ条件で複数回実行する |
| 複数項目を同時に変更する | 改善要因を特定できない | 原則1変数ずつ比較する |
| 常にロックファイルを使う | 依存関係選択能力を測れない | 評価目的に応じて別シナリオを作る |
| 常にロックファイルを外す | 依存関係の変動がモデル差を覆う | 実装品質比較では依存関係を固定する |
| プロンプトを過度に詳細化する | 自律的な技術選択を測れない | 発見能力と実装品質を別評価にする |
| 結果だけ保存する | スコア変動の原因を調査できない | 環境マニフェストとログを保存する |
特に危険なのは、数ポイントの改善を確認しただけでモデルや拡張機能の効果だと結論付けることです。複数の小さな環境差が重なると、測定したい改善幅を上回る可能性があります。(Microsoft Developer)
よくある疑問
GitHub Copilotの仕様が変わるのか
今回の公式記事は、特定のGitHub Copilot機能に対する変更通知ではありません。IDE型、CLI型を含むAIコーディングエージェント全般の評価方法を対象としています。
したがって、この情報を理由にGitHub Copilotの設定変更や再インストールを行う必要はありません。
既存の評価スクリプトは使えなくなるのか
使えなくなるわけではありません。
ただし、実行結果だけを保存している場合は、環境マニフェストを追加すべきです。また、複数PCや複数OSで実行した結果を同一条件として集計している場合は、環境別に分ける必要があります。
WindowsとLinuxの両方で評価する必要があるのか
すべての組織に両OSの評価が必要なわけではありません。
開発者がほぼWindowsだけなら、まずWindows環境を代表プロファイルにします。WindowsとmacOSに利用者が分かれている場合は、少なくとも両方を別集計にします。
評価環境は、技術的に用意しやすいOSではなく、対象利用者が実際に使う環境を基準に選ぶことが重要です。(Microsoft Developer)
コンテナを使えば問題はすべて解決するのか
コンテナは再現性を高めますが、実利用環境の再現を自動的に保証するものではありません。
IDE、LSP、拡張機能、OS固有シェルの影響を測りたい場合は、コンテナとは別に実利用者を代表する評価環境が必要です。
過去の評価結果は無効なのか
無効とは限りません。記録された環境における結果としては利用できます。
ただし、環境情報が残っていない場合は、別マシンや現在の結果と直接比較せず、参考値として扱うのが安全です。
固定できないモデルやハーネスはどう扱うのか
取得可能な情報を記録し、固定できない変数として明示します。
スコアが変化した場合は、評価対象の変更だけでなく、モデルプロバイダー、ハーネス、IDE拡張機能の更新も原因候補に含めます。完全に固定できないから記録しないのではなく、固定不能であること自体をマニフェストに残します。(Microsoft Developer)
まず実施すべき対応
今回のMicrosoft公式ガイダンスは、既存のコーディングエージェントや評価コードを破壊する仕様変更ではありません。しかし、AIモデルやエージェント機能をスコアで比較している組織にとっては、評価結果の信頼性に直結する重要な更新です。
最初に実施すべきことは、すべての評価環境を一度に作り直すことではありません。現在もっとも重要な評価シナリオを1つ選び、次の対応を行います。
- 作業パスとユーザー名を中立化する
- OS、シェル、モデル、ハーネス、LSPの情報を保存する
- 固定した再現性ベースラインを作る
- 実際の利用者を代表する環境でも実行する
- 同一シナリオを複数回実行する
- 過去結果と新しいベースラインを分ける
- 変更する変数を1つに絞って比較する
評価スコアの目的は、数字を高く見せることではありません。スコアが動いたときに、それが本当の能力向上なのか、実行環境が変わっただけなのかを説明できる状態を作ることが、今後のコーディングエージェント評価に必要な管理策です。
コメント