Git のブランチを切り替えた直後、ビルドは通るのに Visual Studio の「エラー一覧」だけが大量の“偽エラー”で真っ赤になる――そんなストレスフルな状況に悩んでいませんか。本記事では、この現象がなぜ起こるのかを仕組みから解説しつつ、現場で使える対処手順と再発防止策、そして最終的に Microsoft へ報告する際のポイントまでを網羅的に整理します。
現象の整理：ビルド成功なのにエラー一覧だけ真っ赤になる
まずは問題の症状を整理します。よくあるパターンを表にまとめると次のようになります。
| 項目 | 状態 |
|---|---|
| Git ブランチ切り替え後 | Visual Studio の「エラー一覧」に大量のエラーが表示される |
| ビルド／デバッグ | 正常に成功（ビルドログにエラーなし） |
| エラーからソースへジャンプ | 一部のエラーは消えるが、多数が残り続ける |
| クリーン／リビルド | 状況はほとんど変わらないことが多い |
| キャッシュ削除／再インストール | 改善しないケースがある |
| Visual Studio の再起動 | 一旦すべての偽エラーが消えるが、ブランチ切り替えのたびに再発する |
つまり、
- コンパイラが実際にビルドしている結果は正常
- しかしエディタや「エラー一覧」が参照している“設計時の解析結果”だけが壊れている
という二重構造の破綻が起きているのがポイントです。
なぜビルド成功なのに「エラー一覧」だけ壊れるのか
この現象を理解するには、Visual Studio 内部で動いている「設計時ビルド（DesignTime Build）」と「実ビルド」の違いを押さえる必要があります。
実ビルドと設計時ビルドは別物
ざっくりいうと、Visual Studio では次の二つの“ビルド系処理”が動いています。
| 種類 | 主な用途 | いつ動くか |
|---|---|---|
| 実ビルド（通常のビルド） | 実行ファイル・DLL を作る、本番用のビルド結果 | F5 / Ctrl + Shift + B / CI など |
| 設計時ビルド（DesignTime Build） | IntelliSense・「エラー一覧」・コード解析のための情報生成 | ファイル保存、プロジェクト変更、ブランチ切り替え検知など |
「エラー一覧」が参照しているのは後者の DesignTime Build の結果に基づくインデックス情報 です。この情報が Git ブランチ切り替えを契機に壊れてしまい、
- 実際のビルド結果：正常
- 設計時インデックス：古い状態のまま
というズレが生まれて、“存在しないエラー”が大量表示されていると考えられます。
なぜ Git ブランチ切り替えがトリガーになるのか
ブランチ間で次のような差分があると、設計時インデックスが壊れやすくなります。
| 変更パターン | 具体例 | よく出る偽エラー例 |
|---|---|---|
| API 形状の大きな変更 | メソッド削除・シグネチャ変更、クラスの移動など | 型または名前空間が見つからない |
| partial / generated の差替え | 部分クラスの片方だけが別ブランチで変更されている | メンバー定義が存在しない、partial クラスの競合 |
| ソースジェネレータの出力差分 | Source Generator のバージョンや設定がブランチごとに違う | 自動生成プロパティ・メソッドが見つからない |
| アナライザのバージョン差 | .editorconfig や NuGet のアナライザバージョンがブランチで異なる | 無効化済みのはずの警告が復活／逆に出るべき警告が出ない |
| 生成物フォルダの不整合 | bin/obj に古い出力が残ったまま別ブランチのコードを解析 | 参照アセンブリのバージョン不整合によるエラー |
特に、次のようなケースは偽エラーが出やすい“危険ゾーン”です。
- 大規模ソリューションで、プロジェクト間参照が複雑
- コード生成（T4、Source Generator、gRPC など）を多用している
- 独自アナライザや StyleCop、Roslyn Analyzer を多数導入している
- 同じソリューションを複数人で開き、ブランチを横断しまくっている
こうした環境では、DesignTime Build のインデックス更新が Git の変更をうまく追いかけられず、結果として“古い世界線のメタデータ”を参照し続けることがあります。
すぐ効くワークアラウンドまとめ
ここからは、実務で「とりあえず今日の作業を進める」ためのワークアラウンドを具体的な手順で整理します。頻度が高いものから順に掲載します。
Visual Studio 内蔵の Git 機能でブランチを切り替える
外部の Git クライアント（GitKraken、SourceTree、コマンドラインなど）だけでブランチを切り替えると、Visual Studio が変更通知を取りそこねることがあります。可能であれば、次の手順で VS 内蔵 Git から切り替えてみてください。
- Visual Studio を起動し、対象ソリューションを開く
- メニューバーから [Git] → 対象リポジトリを選択
- ステータスバーのブランチ名、または Git チェンジウィンドウから目的のブランチを選択
- 切り替え後、しばらく待ってインデックス更新が完了するのを待つ
これにより、Visual Studio 内部の DesignTime Build が「ブランチ切り替えイベント」を確実に受け取れます。
ソリューションのキャッシュを明示的にリセットする
VS 再起動よりも一段階軽い「キャッシュ掃除」として、ソリューションごとのキャッシュを消す方法があります。必ず Visual Studio を完全に終了してから 実行してください。
削除するフォルダ一覧
| フォルダ | 場所 | 役割 |
|---|---|---|
| .vs | ソリューションフォルダ直下 | ソリューションごとの設定・キャッシュ・インデックス |
| bin | 各プロジェクトフォルダ直下 | ビルドされた実行ファイル／DLL |
| obj | 各プロジェクトフォルダ直下 | 中間生成物、設計時ビルドが参照する情報の一部 |
さらに、より徹底的にやる場合はユーザキャッシュも削除対象になります（VS は終了済みであることが前提）。
C:\Users\<ユーザー名>\AppData\Local\Microsoft\VisualStudio\17.0_*\ComponentModelCache
C:\Users\<ユーザー名>\AppData\Local\Microsoft\VisualStudio\17.0_*\Cache
上記フォルダを削除後、ソリューションを開き直すとインデックスが一から再構築され、多くの場合、偽エラーは解消します。
ソリューションの再評価（NuGet 復元／プロジェクト再読み込み）
DesignTime Build に「今の依存関係をもう一度ちゃんと見直してくれ」とお願いするイメージで、次の操作を行います。
- ソリューションを右クリック → [NuGet パッケージの復元]
- または、ソリューションフォルダで
dotnet restoreを実行 - 必要に応じて、プロジェクトを右クリック → [プロジェクトの再読み込み]
NuGet の依存関係がブランチごとに変わるプロジェクトでは、復元だけで偽エラーが消えるケースもあります。
クリーン／リビルドより「ソリューションの閉じ直し」
軽度の不整合であれば、次のような簡易操作でも直ることがあります。
- ソリューションを閉じる（[ファイル] → [ソリューションを閉じる]）
- Visual Studio はそのまま起動しておく
- 最近使った項目から同じソリューションを再度開く
この操作により、DesignTime Build のインデックスがソリューション単位で再生成されます。クリーン／リビルドより高速に試せるので、まずはこの方法から行うのもおすすめです。
最終手段：Visual Studio を再起動する
既に経験されている通り、VS の再起動は多くの場合「全部リセットしてやり直す」強力な手段です。ただし、
- 起動に時間がかかる
- デバッグセッションが途切れる
- 未保存ファイルがあると危険
といった欠点もあります。そこで、前述した
- ソリューションの閉じ直し
- .vs / bin / obj の削除
- NuGet 復元・プロジェクト再読み込み
といったワークアラウンドを段階的に試し、どうしてもダメなときだけ再起動に頼る、という運用が現実的です。
再発防止のための運用ヒント
完全に防ぐのが難しい問題ではありますが、「発生頻度をかなり下げる」運用テクニックはいくつか存在します。
ブランチ切り替え前に未保存／未コミットを減らす
DesignTime Build は「今開いているファイルの状態」も解析対象にします。そこで、ブランチ切り替え前に次の習慣をつけると、不整合の発生確率を下げられます。
- すべてのファイルを保存する（Ctrl + Shift + S）
- コミット可能な変更はコミット／プッシュしてから切り替える
- 一時的な変更は
git stashで退避する
中途半端な状態のファイルを抱えたままブランチをまたぐと、「設計時の解析結果だけ旧バージョンが残る」といった混線が発生しやすくなります。
外部 Git クライアントを使うなら「ソリューションの開き直し」をセットで
どうしても外部ツールでブランチを切り替えたい場合は、次の運用にするのがおすすめです。
- 外部クライアントでブランチを切り替える
- Visual Studio に戻る
- ソリューションを一度閉じて、開き直す
面倒に見えますが、偽エラーに悩まされて数十分消費するよりは遥かにコストが安いです。
ソースジェネレータ／アナライザのバージョンを揃える
生成コードやアナライザは、DesignTime Build に大きく依存するコンポーネントです。次のような状況は偽エラーの温床になりがちです。
- ブランチ A と B で、同じパッケージのバージョンが微妙に違う
- あるブランチではアナライザを導入しており、別のブランチでは削除している
- 一部メンバーだけが新しいジェネレータ API に依存している
可能であれば、
- アナライザ／ジェネレータはプロジェクト全体でバージョンを統一する
- バージョンアップは専用ブランチでまとめて行う
- バージョン差をまたぐブランチ切り替えはなるべく避ける
といったルールをチーム内で決めておくと安定します。
大規模ソリューションの場合は「プロジェクト単位のロード／アンロード」を活用
数十〜数百プロジェクトあるようなソリューションでは、すべてを DesignTime Build で最新に保つのは VS にとっても負荷が高くなります。そこで、実際に今触っているプロジェクト以外は [プロジェクト] → [プロジェクトのアンロード] で一時的にアンロードする運用も有効です。
アンロードされたプロジェクトは DesignTime Build の対象外になるため、
- インデックスの更新量が減り、速度が向上する
- 偽エラーの発生範囲も限定的になる
というメリットがあります。
キャッシュ掃除を自動化する PowerShell 例
.vs や bin/obj を手で消すのが面倒であれば、定期的に実行するスクリプトにまとめてしまうのも一つの手です。例えば、次のような PowerShell スクリプトをソリューションルートに置いておくと便利です。
# Cleanup-VSCache.ps1
param(
[string]$SolutionDir = "."
)
Write-Host "Cleaning Visual Studio caches in $SolutionDir"
$paths = @(
".vs",
"bin",
"obj"
)
foreach ($path in $paths) {
Get-ChildItem -Path $SolutionDir -Recurse -Directory -Filter $path -ErrorAction SilentlyContinue |
ForEach-Object {
Write-Host "Removing $($_.FullName)"
Remove-Item $_.FullName -Recurse -Force -ErrorAction SilentlyContinue
}
}
Write-Host "Done."
ソリューションフォルダで PowerShell を開き、
pwsh ./Cleanup-VSCache.ps1
のように実行するだけで、配下の .vs / bin / obj を一括削除できます（実行前にコミット済みかどうかだけは必ず確認してください）。
恒久対応：Developer Community へ不具合として報告する
ここまで紹介したワークアラウンドを実施しても、最新の Visual Studio 2022 で同じ現象が継続して再現する場合は、製品側の改善に期待するしかありません。そのための公式窓口が Developer Community です。
Developer Community に報告する手順
- Visual Studio を起動
- メニューバーから [ヘルプ] → [フィードバックの送信] → [問題を報告] を選択
- 出てきたフォームに、現象と再現手順を詳細に記載
- 可能であれば、再現用の最小サンプルリポジトリ（または ZIP）を添付
- 送信後、発行されたチケット URL をチームで共有
開発チームが状況を把握しやすいように、次の情報を一緒に載せておくと非常に効果的です。
- Visual Studio の正確なバージョン（例：17.13.5）
- .NET SDK / MSBuild のバージョン
- 利用中の拡張機能一覧（特に Roslyn 関連）
- 再現に必要な最小限のステップ
- 試した回避策（キャッシュ削除、内蔵 Git 利用など）と、その効果
報告テンプレートの例
実際に書くときのイメージとして、簡易テンプレートを載せておきます。必要に応じてコピペしてご利用ください。
【概要】
Git ブランチ切り替え後に、Visual Studio の「エラー一覧」に存在しないエラーが大量表示される。
ビルドおよびデバッグは成功し、VS の再起動で一時的に解消する。
【環境】
- Visual Studio 2022 Version: 17.13.5
- .NET SDK: 8.0.x
- OS: Windows 11
- プロジェクト種類: ASP.NET Core / WPF / Console など
- 拡張機能: Roslyn Analyzer 関連があれば列挙
【再現手順】
1. ブランチ A をチェックアウトし、クリーンビルドを実行（成功）
2. ブランチ B（互換性のない API 変更を含む）に切り替え
3. Visual Studio 上で「エラー一覧」を確認
4. ビルドおよびデバッグを実行（成功）
5. エラーをダブルクリックして対象ファイルにジャンプすると、一部のエラーは消えるが多くが残る
6. Visual Studio を再起動すると、すべてのエラーが消える
【期待される結果】
ブランチ切り替え後も、実ビルドと同様に「エラー一覧」に偽エラーが表示されないこと。
【実際の結果】
- 実ビルドは成功する一方、「エラー一覧」に存在しないエラーが多数残る
- VS 再起動後にのみ正常な状態に戻る
【試した回避策】
- .vs / bin / obj の削除 → 一時的には改善するが再発
- ComponentModelCache / Cache の削除 → 同上
- VS 内蔵 Git でのブランチ切り替え → 発生頻度は減るがゼロにはならない
- ソリューション閉じ直し → 軽度のケースでは有効
ここまで書いておくと、Developer Community 側でも「既にユーザー側でできる対処は一通り試している」ことが伝わり、再現調査が進みやすくなります。
トラブルシューティングのチェックリスト
最後に、実際にトラブルが起きたときに上から順に確認できるチェックリストをまとめます。日々の開発で迷ったときの早見表として活用してください。
| 優先度 | 確認内容 | 具体的な操作 | 効果の目安 |
|---|---|---|---|
| 高 | ビルド／デバッグ結果は正常か | Ctrl + Shift + B でビルド、F5 でデバッグ | 実ビルドが正常なら偽エラーの可能性が高い |
| 高 | ソリューションを開き直したか | ソリューションを閉じて再オープン | 軽度の不整合ならこれだけで直ることも多い |
| 中 | .vs / bin / obj を削除したか | VS を閉じてからフォルダを削除 | インデックスを再構築でき、かなりの確率で改善 |
| 中 | NuGet / 依存関係を再評価したか | NuGet 復元・プロジェクト再読み込み | 参照アセンブリの不整合系エラーに有効 |
| 中 | VS 内蔵 Git で切り替えたか | [Git] メニューからブランチ切り替え | 発生頻度そのものを下げる効果が期待できる |
| 低 | VS を再起動したか | VS を完全終了→再起動 | 高確率で一時的に解決するが、根本対策にはならない |
| 低 | Developer Community に報告済みか | [ヘルプ] → [フィードバックの送信] → [問題を報告] | 長期的な改善のために重要 |
まとめ：これは「設計時解析が古い世界線のまま」になる問題
Git ブランチ切り替え後に Visual Studio の「エラー一覧」に偽エラーが大量発生し、VS 再起動でしか消えない問題は、
- 実ビルドと設計時ビルドが別系統で動いている
- ブランチ間の差分が大きいほど、設計時インデックスが古い情報を持ち続けやすい
という構造上の事情から起きていると考えられます。
実務上は、
- なるべく Visual Studio 内蔵の Git でブランチ切り替えを行う
- 外部 Git を使う場合は「切り替えたらソリューションを開き直す」をセットにする
- .vs / bin / obj の削除や NuGet 復元で、設計時インデックスを明示的にリセットする
- どうしても解消しなければ VS 再起動を使うが、恒久的な改善のために Developer Community へ報告しておく
といった方針をチームで共有しておくと、日々の“謎エラー”に振り回される時間を大きく減らせます。偽エラーに悩んでいるチームメンバーがいたら、本記事の内容を共有しつつ、少しずつ運用ルールを整えていくとよいでしょう。
コメント