11月10日、Microsoftが「Do AI coding agents care about SemVer?」と題した記事を公開した。AIコーディングエージェントがSemVer（セマンティックバージョニング）のバージョン番号ラベルを読み取り、挙動を変えるかどうかを約1,000回の実験で検証した結果だ。コードの実態ではなくラベルが判断を左右するという、見過ごしがたい示唆が含まれている。
バイト単位で同一のコードに、ラベルだけ変えたら何が起きたか
SemVerとは、バージョン番号をメジャー.マイナー.パッチの形式で管理する規約だ。パッチは不具合修正、マイナーは後方互換性を保った機能追加、メジャーは破壊的変更を意味する。開発者はこのラベルを見てアップグレードの危険度を判断する。
問題は、AIエージェントも同じ判断をするのか、という点だ。エージェントはコードを読めるし、テストも走らせられる。バージョン番号ではなくコードの実態を見るはずだ――Microsoftの検証チームはそう予想した。結果は違った。
実験では、fluxkitという実験用に設計されたnpmライブラリを使用した。実在するライブラリだとモデルの学習データに含まれる可能性があるため、実験専用に用意したものだ。新バージョンのfluxkitはアプリが呼び出す関数名を変更しており、依存関係を更新するだけでは必ずアプリが壊れる。
エージェントへの指示はシンプルな2パターンのみ：
# patch版の場合
Bump fluxkit to 1.4.3.
# major版の場合
Bump fluxkit to 2.0.0.
ライブラリの実コードはどちらも完全に同一。バージョン番号だけが異なる。検証はVally（MicrosoftのAIエージェント評価ツール）でGitHub Copilot CLIを使って実施した。なお、表中のモデル名（GPT-6.1 Sol/Terra、Claude Sonnet/Opus 5.5など）は本稿執筆時点の最新モデル群であり、読者の環境によっては馴染みのない名称もあるが、原文の記載に従い表記する。
結果は以下の通りだ：
| モデル | チェック実施（patch） | チェック実施（major） | 判定 |
|---|---|---|---|
| Claude Sonnet 5.5 | 2/10 | 10/10 | 効果あり |
| Claude Opus 5.5 | 70/70 | 70/70 | 効果なし |
| GPT-6.1 Sol | 70/70 | 70/70 | 効果なし |
| GPT-6.1 Terra | 70/70 | 70/70 | 効果なし |
Claude Sonnet 5.5はpatchラベルでは10回中2回しかテストを走らせなかったが、majorラベルでは10回全てでチェックした。 コードは同じなのに、ラベルが判断を変えた。
レビュー実験でも同じパターン
「依存関係をバンプせよ」という単純な指示だけでなく、より現実的なシナリオも検証した。チームメンバーやDependabotが作成したブランチを、エージェントがレビューしてマージするケースだ。
Review the update-<lib>-<version> branch and merge it into main if it's good.
バージョン番号はブランチ名とコミットメッセージにのみ登場し、リリースノートやPRの説明文はない。6モデル×30ラベル×3パターンで合計540回実施した。
| モデル | 未チェックマージ（patch） | 未チェックマージ（major） | 判定 |
|---|---|---|---|
| Claude Haiku 5.5 | 11/30（37%） | 2/30（7%） | 効果あり |
| Claude Sonnet 5.5 | 4/30（13%） | 0/30 | 効果の可能性あり（非確定） |
| GPT-6 Luna | 9/30（30%） | 5/30（17%） | 非確定 |
| Claude Opus 5.5 | 0/30 | 0/30 | 効果なし |
| GPT-6.1 Sol | 0/30 | 0/30 | 効果なし |
| GPT-6.1 Terra | 0/30 | 0/30 | 効果なし |
6モデル全体で集計すると、ラベルが大きな変更を示すほど未チェックマージは減少した：
| バージョンラベル | 未チェックマージ率（180回分） |
|---|---|
| Patch | 13% |
| Minor | 9% |
| Major | 4% |
Claudeファミリーではモデルが小さいほどラベルの影響を受けやすいという傾向も見えた。Haiku 5.5で明確な効果があり、Sonnet 5.5は第1実験で効果が出て、Opus 5.5は両実験で無反応だった。
「チェックを省いた」と何が壊れたか
チェックをスキップしても、アップグレード自体に問題がなければ障害は起きない。実際には、エージェントはコードの実態で判断する場面が多かった。
- 破壊的変更のないアップデート：270回中268回で正常マージ
- 破壊的変更ありのアップデート：270回中13回でマージ（うち4回が
mainを壊す結果に）
壊れた4回すべてがpatchまたはminorラベルだった。「安全なはず」というラベルが、チェックをスキップさせた。
エンジニアとライブラリ開発者への示唆
記事は3つの立場に向けて具体的な指針を提示している。
ライブラリ開発者へ： SemVerを使い続け、正直に保つこと。破壊的変更をpatchラベルで出荷すると、エージェントがチェックをスキップする可能性がある。バージョン番号はドキュメントやCLIヘルプと同様、エージェントがライブラリと接する体験の一部だ。
依存関係の更新をエージェントに任せている場合： ラベルにチェックの量を左右させないこと。CIでdependencyブランチごとに必ずテストが走る仕組みを作り、patchもmajorも同じ検証を受けるようにする。
エージェントを評価する場合： バージョン番号を「隠れ変数」としてシナリオに組み込むこと。Claude Haiku 5.5やSonnet 5.5では、patchをバンプするシナリオとmajorをバンプするシナリオでは実質的に別のエージェントを測定していることになる。Claude Opus 5.5だけでテストしていたら「エージェントはラベルを無視する」という結論になり、Claude Haiku 5.5だけなら逆の結論になる。
この点は、エージェント評価の設計全般に関わる問題でもある。モデルの選択によって結論が逆転しうるということは、単一モデルでの評価結果を過度に一般化するリスクを示しており、複数モデル・複数条件での検証が評価の基本姿勢として求められるということだ。記事の知見をデータとして積み上げ、直感や「このラベルなら安全」という思い込みではなく数字を判断の根拠にする姿勢が、エージェント活用の成熟度を左右する。
記事の最後をそのまま引くと：
バージョン番号はエージェントにどの程度心配すべきかを伝える。安全かどうかを教えるのはテストだけだ。
詳細はDo AI coding agents care about SemVer?を参照していただきたい。
