Visual StudioでC++プロジェクトをビルドすると「The Windows SDK version 10.0.20348.0 was not found.」で失敗し、Retarget solutionやプロパティでSDKを変更しても未選択のはずの10.0.20348.0を要求し続けることがあります。原因の切り分けと、再発しにくい直し方を手順化して解説します。
まず確認したい：エラーは「MSB8036」になっていないか
この症状は、ビルド出力に次のような行が出ることが多いです（文言は環境で多少変わります）。
error MSB8036: The Windows SDK version 10.0.20348.0 was not found.
Install the required version of Windows SDK or change the SDK version in the project property pages or by right-clicking the solution and selecting "Retarget solution".「Retarget solutionで直るはず」と書かれているのに直らないのが今回のポイントです。UI操作が効かないときは、SDKの実体とMSBuildの上書き元を疑うと解決が早くなります。
起きているエラーと、C++だけが落ちる理由
Windows SDKは、C++のコンパイル・リンクで必要になるヘッダー（include）やライブラリ（lib）を提供します。C++プロジェクトはビルド時に「どのSDKのヘッダー/ライブラリを使うか」を参照するため、指定されたSDKが見つからないと止まります。一方、.NETのプロジェクトは同じSDKを必須としないケースが多く、C++だけビルドできないという分かれ方になりやすいです。
ここで多いのが次のパターンです。
- ソリューションのリターゲットや、プロジェクトの「Windows SDKバージョン」を別の値に変更した
- にもかかわらず、ビルドログでは相変わらず10.0.20348.0が要求され続ける
この「変更しているのに反映されない」現象は、ほとんどが次のどちらか（または両方）で説明できます。
- SDK自体が入っていない／破損している（フォルダーがない、ヘッダーやライブラリが欠けている）
- 設定のどこかに10.0.20348.0が固定されている（Retargetで変えたつもりでも、別ファイルやプロパティシートが上書きしている）
- Visual StudioがSDKを検出できていない（インストール済みなのに一覧に出ない、選べない、または参照できない）
最短で直すためのチェックリスト
まずは原因を「不足・破損」なのか「検出不良」なのか「設定固定」なのかに切り分けます。下の表に沿って確認してください。
| 確認ポイント | 見る場所 | OKの目安 | NGなら次にやること |
|---|---|---|---|
| 10.0.20348.0のSDKフォルダーが存在するか | C:\Program Files (x86)\Windows Kits\10\Include\10.0.20348.0 | フォルダーがあり、umやshared等が入っている | Windows SDKを修復／再インストール |
| 他のSDKバージョンは入っているか | ...\Windows Kits\10\Include\配下の一覧 | 10.0.19041.0や10.0.22621.0等、複数のバージョンが見える | Visual Studio InstallerでSDKコンポーネント追加 |
| UIで指定したSDKがビルドにも反映されているか | プロジェクトプロパティ > 全般 | 「Windows SDK バージョン」が意図した値（または最新） | 固定値の上書き元を探す |
| プロジェクト側に「20348」が固定されていないか | ソリューションフォルダー全体の検索 | 「20348」の記述が見つからない、または意図した箇所のみ | .vcxproj / Directory.Build.props / .propsを修正 |
| Retarget後もログで20348が出続けるか | 出力ウィンドウ／ビルドログ | 要求SDKが変更後の値になっている | キャッシュ削除、MSBuildの評価結果を確認 |
UIでの確認ポイント（Retargetとプロジェクトプロパティ）
「本当に変更できているか」を確認するため、UIの場所も整理しておきます。
- Retarget solution：ソリューションを右クリック →「Retarget solution（ソリューションのリターゲット）」
- Windows SDKバージョン：プロジェクトを右クリック →「プロパティ」→「構成プロパティ」→「全般」→「Windows SDK バージョン」
ここで「10.0 (最新のインストール済みバージョン)」のような選択肢がある場合は、いったん最新追従にしてビルドが通るか確認すると切り分けに便利です。固定が必要な理由がなければ、最初は最新追従に寄せると環境差の事故が減ります。
Windows SDKフォルダーの存在を確認する
まずは「そもそもSDKが入っているか」を確認します。エクスプローラーで次の場所を開いてください。
C:\Program Files (x86)\Windows Kits\10\Include\10.0.20348.0
このフォルダーが存在しない場合は、10.0.20348.0のSDKが未インストールか、インストールが不完全です。フォルダーはあるのに中身がスカスカ、あるいはヘッダーが欠けている場合も「破損」扱いで、次の修復・再インストールが近道です。
なお、10.0.20348.0はWindows Server 2022のビルド番号（20348）と一致するため、Server系の環境で作成されたC++プロジェクトやテンプレートが、このSDKを明示指定していることがあります。別のPCへ移植したり、クリーン環境で開くと「そのSDKがない」状態になりやすい点も覚えておくと切り分けが楽になります。
Windows SDKを修復（Repair）または入れ直す
SDKの不足・破損が疑わしい場合は、Windows SDKの修復を優先します。Windowsの「アプリと機能」または「プログラムと機能」から、該当のWindows SDKを探してください。
- 例：Windows Software Development Kit – Windows 10.0.20348.x のような名前
見つかったら、まずは変更（Change）→ 修復（Repair）を実行します。修復で直らない場合は、アンインストールしてから再インストールします。
ここでのポイントは、「Visual Studio側の設定」より先に「SDKの実体」を正常化することです。プロジェクトの設定だけ直しても、参照先のSDKが欠けていればビルドは通りません。
Visual Studio InstallerからSDKコンポーネントを追加する
Windows SDKは単体インストーラーの他に、Visual Studio Installerの「ワークロード／個別コンポーネント」から追加できることがあります。特にC++がビルドできないときは、次も同時に確認してください。
| 項目 | 場所（Visual Studio Installer） | 狙い |
|---|---|---|
| デスクトップ開発（C++） | ワークロード | MSVC、MSBuild、基本ツール一式を揃える |
| Windows 10 SDK（10.0.20348.0 など） | 個別コンポーネント | 不足しているSDKバージョンを追加 |
| C++ CMake tools（使っている場合） | 個別コンポーネント | CMakeプロジェクトでSDK検出が絡むケースを潰す |
「10.0.20348.0を入れたいのに候補に出ない」場合は、次の「検出不良の回避策」も試してください。
Visual StudioがSDKを検出できていない場合の対処
SDKフォルダーは存在するのに、Visual Studioのプロジェクトプロパティで選べない／ビルドで見つからないと言われる場合は、Visual Studio側がSDKの情報を正しく掴めていない可能性があります。ここは「設定を変える」よりも「検出ルートを正す」方向で攻めるのがコツです。
まず試したい簡単なリセット
- Visual Studioを終了し、再起動する
- ソリューションの「クリーン」→「リビルド」を実行する
- ソリューションフォルダー内の
.vsフォルダーを削除して開き直す（ユーザーごとのキャッシュが壊れているケースに効く） - 可能ならPCを再起動する（インストーラー実行直後に検出が不安定なときがある）
SDK検出の要となる場所を確認する
Windows SDKは通常、次のルート配下にインストールされます。
C:\Program Files (x86)\Windows Kits\10\
もしWindows Kitsフォルダー自体が特殊な場所にある、権限が極端に制限されている、セキュリティ製品でアクセスがブロックされている、といった条件があると検出が失敗することがあります。企業PCや厳格な環境では特に注意してください。
レジストリが壊れている可能性をざっくり確認する
「Windows Kitsを通常パスに入れたのにVSが見つけない」場合、KitsRootの情報が崩れていることがあります。管理者権限のコマンドプロンプトで次を実行し、エラーが出ないか確認します。
reg query "HKLM\SOFTWARE\Microsoft\Windows Kits\Installed Roots" /v KitsRoot10値が空、あるいは明らかに存在しないパスを指している場合は、SDKの再インストールで直ることが多いです（手動でのレジストリ修正は環境依存が強いため、まずは修復・再導入を優先します）。
回避策：Visual Studio 2019を併用してSDKコンポーネントを追加する
環境によっては、Visual Studio 2022でSDKの選択肢が出ないのに、Visual Studio 2019のインストーラー経由だと該当SDKを追加でき、その結果としてVS 2022でも認識されるケースがあります。手順としては次の流れです。
- Visual Studio 2019を追加インストールする
- Visual Studio Installerの「個別コンポーネント」からWindows 10 SDK（10.0.20348.0）を追加する
- その後、Visual Studio 2022を起動してC++プロジェクトがビルドできるか確認する
「なぜ2019経由で？」と思うかもしれませんが、社内ミラー環境やインストーラーのキャッシュ状態などが絡むと、結果的にこのルートが一番早いことがあります。まずビルドを通して作業を前に進めたい場合の実践的な手として覚えておくと便利です。
Retargetしても20348を要求し続ける場合（設定固定の犯人を探す）
もっとも厄介なのが、リターゲットやプロパティのUIで別バージョンを選んだのに、ビルド時は20348を要求し続けるケースです。これは多くの場合、MSBuildの評価順序の中で別の設定ファイルが最後に上書きしている、またはUIが触っている場所とは別の場所に値が書かれていることが原因です。
鍵になるプロパティは主に次の2つです。
WindowsTargetPlatformVersion（どのWindows SDKバージョンを使うか）WindowsTargetPlatformMinVersion（最小ターゲット。UWP等で登場することがある）
上書きされやすい場所を把握する（優先順位のイメージ）
MSBuildは複数のファイルをインポートして最終的な値を決めます。「どこで上書きされているか」を知っていると、闇雲にUIを触る時間が減ります。
| よくある上書き元 | ファイル例 | 特徴 | 対処の考え方 |
|---|---|---|---|
| ディレクトリ共通設定 | Directory.Build.props | 配下のプロジェクト全部に効く。意図せず固定していると事故が大きい | 固定するなら導入手順を明記。不要なら値を削除 |
| プロジェクト本体 | *.vcxproj | プロジェクト単体に効く。構成/プラットフォームごとにCondition付きで分岐していることがある | x64/Win32やDebug/Releaseで別々に指定していないか確認 |
| 共有プロパティシート | *.props | チーム運用で共通化しているとここに固定が入る | プロパティシートの参照元も含めて修正 |
| ビルド手順側の後勝ち上書き | Directory.Build.targets / *.targets | 最後に値を塗り替えられるので、UI変更が効かない原因になりやすい | diagログで「どこで確定したか」を追う |
まず「20348」を全文検索する
最も早いのは、ソリューションフォルダー全体で「20348」を検索することです。Visual Studioの「検索（Ctrl+Shift+F）」でも、エクスプローラー＋PowerShellでも構いません。
PowerShellなら、次のワンライナーで「20348を含む行」を拾えます（大規模リポジトリでも便利です）。
Select-String -Path .\* -Pattern "20348" -Recurse -ErrorAction SilentlyContinue特に見落としやすいのが次のファイルです。
*.vcxproj（プロジェクト本体）Directory.Build.props/Directory.Build.targets（ディレクトリ配下のプロジェクトをまとめて上書きできる）*.props（共有のプロパティシート。チーム内で共通化しているとここに固定値が入りがち）*.targets（ビルド手順側で上書きしていることもある）
例えば、次のような記述があると、UIで変更しても結局ここに引っ張られて20348が要求されます。
<PropertyGroup>
<WindowsTargetPlatformVersion>10.0.20348.0</WindowsTargetPlatformVersion>
</PropertyGroup>この場合は、インストール済みのSDKバージョンに合わせて値を変更するか、チーム運用として「固定しない（空にして最新に追従する）」方向に寄せるのが一般的です。固定するメリットは再現性ですが、環境移行に弱いので、CIやビルドサーバーを含めて統一できるときにだけ固定するのがおすすめです。
「20348がどこから来たのか」をMSBuildで可視化する
検索しても見つからない、あるいは複数箇所にあり判断できない場合は、MSBuildの評価結果（最終的にどう解釈されたか）を出すと原因が一気に絞れます。開発者コマンドプロンプト（Developer Command Prompt）で次を試してください。
msbuild YourProject.vcxproj /t:Build /v:diag > build.log出力されたbuild.logを開き、「WindowsTargetPlatformVersion」や「20348」を検索します。どのファイル（どの.props/.targets）がその値を設定したのかがログに出るため、上書き元を突き止められます。
もう少し手軽に全展開（プリプロセス）したい場合は、次も有効です。
msbuild YourProject.vcxproj /pp:preprocessed.xmlpreprocessed.xmlには、インポートを展開した結果がまとまって出ます。どこでSDKバージョンが確定したかを確認しやすくなります。
キャッシュや中間生成物が古い設定を握っている場合
設定を直したのに挙動が変わらないとき、実は「中間生成物（Intermediate）」やキャッシュに古い情報が残っていて、結果として同じエラーが繰り返されることがあります。特にC++は中間生成物が多く、残骸が影響しやすいので、以下を一度整理すると改善することがあります。
- Visual Studioを終了
- ソリューションフォルダー内の
.vsを削除 - 各プロジェクトの
bin/obj、C++ならx64\Debugやx64\Releaseなど出力フォルダーを削除 - 再度Visual Studioで開いてリビルド
「とにかく一回、環境をまっさらにして評価し直す」ことで、UIで変更した値が正しく適用されることがあります。特に、SDKを修復・再インストールした直後はこの掃除が効きやすいです。
実践：インストール済みのWindows SDKバージョンを一覧で確認する
「どのSDKが入っているのか分からない」「インストールはしたはずだがバージョンが見えない」というときは、フォルダー一覧で確認するのが確実です。PowerShellで次を実行すると、インストール済みのSDKバージョンが概ね分かります。
Get-ChildItem "C:\Program Files (x86)\Windows Kits\10\Include" -Directory |
Select-Object -ExpandProperty Name表示されたバージョンのいずれか（例：10.0.19041.0や10.0.22621.0など）を、プロジェクトのWindows SDKバージョンとして指定すれば、少なくとも「存在しないSDKを要求して落ちる」状態は解消できます。
最終手段：20348を削除して、より古い（または別の）SDKに寄せる
質問者の実例として、次の対応で解決したケースがあります。
- Visual Studio 2019を導入（SDKコンポーネント追加の足場として）
- コントロールパネル（アプリと機能）から10.0.20348.0をアンインストール
- より古いWindows SDKをインストール（環境に合うバージョンへ）
ここで大事なのは、単に古くすることではなく、「プロジェクトが要求するSDK」と「PCに確実に入っているSDK」を一致させることです。もしチーム開発で、他メンバーやCIが20348固定なら、プロジェクト側の固定値を見直して「より汎用的なSDKへ変更」するか、「必要なSDKを全員の環境に入れる」かのどちらかに寄せて、ブレをなくすと再発が減ります。
よくある質問と、ハマりどころ
Retarget solutionとプロジェクトプロパティ、どちらを優先すべき？
基本はどちらでも構いませんが、Retarget solutionは「ソリューション配下の複数プロジェクトをまとめて変更」できる反面、Directory.Build.propsや共有.propsで固定されていると上書きされることがあります。変更しても直らないときは、UI操作を繰り返すより「固定値の出どころ」を探す方が早いです。
「SDKを入れたのに見つからない」と言われる
SDKの修復に加えて、Visual Studio Installer側の修復（Visual Studio自体のRepair）も検討してください。C++のビルドはVisual Studio側のMSBuild／VCツールセットの整合性にも依存するため、SDKだけ直しても解決しないことがあります。
特定の構成（x64だけ、Releaseだけ）が落ちる
この場合、*.vcxproj内でCondition付きのPropertyGroupにSDKが書かれている可能性があります。例えばx64だけ別SDKを指定していると、Win32は通るのにx64だけ落ちる、のような症状になります。「構成マネージャー」で実際にビルドしている構成（Debug/Release、Win32/x64）がどれかを確認し、その構成の設定が固定されていないかを追ってください。
CIやビルドサーバーでは通るのに、手元PCだけ落ちる
手元だけ落ちる場合は、手元にだけ「存在しないSDK固定」が入り込んでいる、またはSDKの一部が欠けている可能性が高いです。特に、プロジェクトが参照している.propsがユーザーごとに違う（ローカルパス参照、環境変数依存など）と再現性が崩れます。チーム開発では、共有.propsにSDKバージョン固定を置く場合、導入手順をREADME等に明記しておくと事故が減ります。
再発防止のためにやっておくと効くこと
- ソリューション内でWindows SDKバージョンを統一し、混在させない（プロジェクトごとにバラバラだと移行時に壊れやすい）
- SDKを固定するなら、チーム全員・CI・ビルドマシンで同一バージョンを必ず入れる
- 固定しない運用にするなら、WindowsTargetPlatformVersionを空にする（最新インストールSDKに追従）か、最低限「社内標準のSDK」だけに寄せる
- 環境移行時は、まずWindows KitsのInclude/Libフォルダーが揃っているかを確認する（一番速い）
- 謎挙動が出たら、msbuild /v:diagで「どこで値が確定したか」をログで追う
「Retargetしても直らない」「選んでいないSDKを要求される」という症状は、原因さえ分かれば対処は難しくありません。SDKの実体（フォルダー）→ VSの検出 → 設定固定の出どころ、の順で潰していくと、短時間で正常なC++ビルド環境に戻せます。
コメント