MSVCのC++ Modulesビルドでfatal error C1001やC1116が発生している場合、更新先はMSVC v14.52 Previewのcl.exe 19.52.36520以上、link.exe 14.52.36520以上です。
Microsoftは2026年7月のMSVC Build Tools Preview更新で、サードパーティ製ヘッダーをインクルードした後に、import std;を使用して構築したパーティション付きC++23モジュールをインポートするとC1001やC1116が発生する回帰問題を修正しました。Visual Studio InstallerでPreviewコンポーネントを追加しただけでは不十分で、プロジェクト側でもPreviewを有効化し、実際に使われているcl.exeとlink.exeのバージョンを確認してからクリーンビルドする必要があります。(Microsoft for Developers)
一方、LNK4321は同じ更新で追加された新しいリンカー警告です。更新によって消える不具合ではなく、重複したC++モジュールのエクスポートを検出するための診断です。LNK4321が出た場合は、古い中間生成物を削除したうえで、モジュールやライブラリが重複してリンクされていないかを調べます。
結論：必要なMSVCバージョンは19.52.36520／14.52.36520以上
今回の修正が含まれる最低バージョンは次のとおりです。単に「v14.52」と表示されているだけで判断せず、実行ファイルが出力する完全なバージョン番号を確認してください。(Microsoft for Developers)
| 確認項目 | 必要なバージョン | 判定基準 |
|---|---|---|
| MSVC Build Tools | v14.52 Preview | Preview版であること |
cl.exe | 19.52.36520以上 | C1001／C1116の修正を含む |
link.exe | 14.52.36520以上 | July 2026 Previewのリンカーを使用 |
| Visual Studio | Visual Studio 2026 | StableまたはInsidersからPreviewを導入 |
| ビルド方式 | MSBuild、CMake、コマンドライン | 実際にPreviewツールを選択する必要あり |
MSVCでは、製品名、コンパイラ、リンカーで番号の先頭が異なります。
- MSVC Build Toolsの系列：
v14.52 - C/C++コンパイラ：
19.52.36520 - リンカー：
14.52.36520
この違いは正常です。cl.exeが19.52、link.exeが14.52であること自体は、ツールの混在を意味しません。
ただし、次のように末尾のビルド番号が一致しない場合は注意が必要です。
| 実際のバージョン | 判定 |
|---|---|
| cl 19.52.36520／link 14.52.36520 | 修正版の最低条件を満たす |
| cl 19.52.36521／link 14.52.36521 | より新しいビルドなので対象 |
| cl 19.51.x／link 14.51.x | 修正版ではない |
| cl 19.52.36519／link 14.52.36519 | 最低ビルド未満のため対象外 |
| cl 19.52.36520／link 14.51.x | PATHやプロジェクト設定が混在している可能性が高い |
MSVC v14.52 Previewで修正されたC1001・C1116の原因
Microsoftが修正済みとしたのは、すべてのC1001やC1116ではありません。対象となるのは、C++23 Modulesの特定条件で発生していた回帰問題です。
主な条件は次の組み合わせです。
- パーティション付きのC++23モジュールを使用している
- そのモジュールが
import std;を使用している - インポート側で先にサードパーティ製ヘッダーを
#includeしている - その後に対象モジュールを
importするとC1001またはC1116が発生する
概念的には、次のような構成です。
// mymodule-part.ixx
export module mymodule:core;
import std;
export int calculate();// app.cpp
#include <third_party/header.hpp>
import mymodule;
int main()
{
return calculate();
}2026年7月のPreview更新では、この条件で発生するfatal error C1001とC1116の回帰が修正されています。(Microsoft for Developers)
C1001が残る場合は別の内部コンパイラエラーも疑う
C1001は、特定のモジュール問題だけに使われるエラー番号ではありません。Microsoft Learnでは、C1001を内部コンパイラエラーとして説明しており、構文解析、最適化、特定の式とコンパイルオプションの組み合わせなど、複数の原因で発生する可能性があります。(Microsoft Learn)
そのため、19.52.36520以上へ更新して完全なクリーンビルドを行ってもC1001が残る場合は、次の順序で切り分けます。
- エラーがC++ Modulesのインポート処理で発生しているか確認する
- ビルドログに表示された
cl.exeの絶対パスを確認する - DebugとReleaseの両方で発生するか確認する
/O2などの最適化を一時的に外して変化を見る- 最小構成の再現コードを作成する
- 修正版でも再現する場合はVisual Studio Developer Communityへ報告する
ソースコードの書き換えや最適化の無効化は、更新できない環境での一時回避策です。今回の既知のモジュール回帰に該当する場合は、先にMSVC v14.52 Previewへ更新する方が適切です。
LNK4321は「修正されたエラー」ではなく新しい重複検出警告
LNK4321は、2026年7月のMSVC v14.52 Previewで新たに追加されたリンカー警告です。1つのインポートライブラリ内に、重複したC++モジュールのエクスポートが含まれている状態を診断します。(Microsoft for Developers)
つまり、C1001やC1116とは対処が異なります。
| 識別子 | July 2026更新での扱い | 基本的な対処 |
|---|---|---|
| C1001 | 特定のC++ Modules回帰を修正 | 19.52.36520以上へ更新 |
| C1116 | 同じモジュール回帰を修正 | 19.52.36520以上へ更新 |
| LNK4321 | 新しい警告を追加 | 重複したモジュールエクスポートを除去 |
MSVCを更新した直後にLNK4321が初めて表示された場合、更新によって重複が作られたとは限りません。以前から存在していた重複構成が、新しいリンカーによって検出されるようになった可能性があります。
LNK4321が出たときに確認する項目
最初に古い中間生成物をすべて削除します。クリーンビルド後もLNK4321が残る場合は、次の構成を確認してください。
- 同じ
.ixxファイルを複数のプロジェクトでコンパイルしていないか - 同じモジュールインターフェイスを複数のオブジェクトファイルに含めていないか
- 同一の
.objや.libをリンク入力へ重複登録していないか - プロジェクト参照と「追加の依存ファイル」の両方から同じライブラリを渡していないか
- 古いツールセットで生成したモジュール成果物が残っていないか
- Debug用とRelease用の中間ディレクトリを共有していないか
- x64、x86、ARM64の中間生成物が同じ出力先へ混在していないか
DLLやインポートライブラリを生成しているプロジェクトでは、リンクコマンドの入力一覧も確認します。Visual Studioのビルド出力を「詳細」または「診断」に変更すると、実際に渡されたライブラリやオブジェクトファイルを追いやすくなります。
リンカーには特定の警告を抑制する/IGNOREオプションがありますが、警告を非表示にしても重複したモジュール構成は修正されません。LNK4321は、原因を確認せずに抑制するのではなく、重複入力を解消することが基本です。(Microsoft Learn)
Visual Studio InstallerでMSVC v14.52 Previewへ更新する手順
Visual StudioまたはBuild Toolsのインスタンスを更新する
- Visual Studioと実行中のビルドプロセスを終了します。
- Visual Studio Installerを起動します。
- 使用しているVisual Studio 2026またはBuild Tools for Visual Studio 2026のインスタンスを確認します。
- 更新が表示されている場合は、先にインスタンスを最新版へ更新します。
- 対象インスタンスの「変更」を開きます。
- 「C++によるデスクトップ開発」ワークロードを選択します。
- 必要なPreviewコンポーネントを選択します。
- 変更を適用してインストールを完了します。
選択するコンポーネントは、ビルド対象のアーキテクチャによって異なります。
| ビルド対象 | 選択するコンポーネント |
|---|---|
| x64／x86 | MSVC Build Tools for x64/x86 (Preview) |
| ARM64／ARM64EC | MSVC Build Tools for ARM64/ARM64EC (Preview) |
| 複数アーキテクチャ | 両方を選択 |
これらのコンポーネントは、ワークロード画面の右側だけでなく、「個別のコンポーネント」でpreviewを検索して選択することもできます。MFC、ATL、C++/CLI、Spectre軽減ライブラリを使用しているプロジェクトでは、Previewに対応した関連コンポーネントも必要です。コマンドライン専用環境では、Visual Studio IDEではなくBuild Tools 2026へ同じコンポーネントを追加できます。(Aka.ms)
Stableで必要なビルドが見つからない場合
MSVC Build Tools Previewは、Visual Studio 2026のStable ChannelとInsiders Channelの両方から利用できます。ただし、Insidersの方がPreview更新を早く受け取り、Microsoftはおおむね週単位で更新されると説明しています。(Microsoft for Developers)
Stable ChannelへPreviewを追加してもcl.exeが19.52.36520未満の場合は、次のどちらかを選びます。
- Stable Channelで新しいPreviewが提供されるまで待つ
- 検証用にInsiders Channelまたは対応する最新Build Toolsを導入する
重要なのはチャネル名ではなく、最終的にcl.exeとlink.exeが最低バージョンを満たしていることです。
プロジェクトをMSVC Previewへ切り替える
Previewコンポーネントをインストールしても、既存プロジェクトが自動的にPreviewへ切り替わるとは限りません。Visual Studioには複数世代のMSVCをサイドバイサイドで導入できるため、プロジェクト設定やコマンドプロンプトが旧バージョンを選んでいる場合があります。
MSBuildプロジェクトの場合
Visual Studioのソリューションエクスプローラーから、対象プロジェクトのプロパティを開きます。
- 「構成」をRelease、Debug、または「すべての構成」に設定します。
- 「プラットフォーム」をx64、x86、ARM64、または「すべてのプラットフォーム」に設定します。
- 「構成プロパティ」から「全般」を開きます。
- 「Use MSVC Build Tools Preview」を
Yesにします。 - 「MSVC Build Tools Version」を
Latest supportedにします。 - すべてのC++プロジェクトで同じ設定を確認します。
MSVC Build Tools Versionに特定のバージョンを固定していると、Previewを有効化しても固定されたMSVCが優先されます。Microsoftも、Previewを利用する場合はLatest supportedへ設定するよう案内しています。(Aka.ms)
コマンドラインからMSBuildを実行する場合は、次のプロパティを指定できます。
msbuild MySolution.sln /m /p:Configuration=Release /p:Platform=x64 /p:MSVCPreviewEnabled=trueCIでは、プロジェクトファイル側の設定だけに依存せず、パイプラインからMSVCPreviewEnabled=trueを明示すると設定漏れを発見しやすくなります。
Developer Command PromptやBuild Toolsの場合
Preview用の環境を初期化してからビルドします。
call "<VS-install-dir>\VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=Previewx86やARM64向けの場合は、対象アーキテクチャに合ったvcvarsスクリプトを使用します。
インストール先やPreviewのフォルダ名は更新によって変わる可能性があります。現在のPreviewツールセットのフォルダ名は、次のファイルで確認できます。(Aka.ms)
<VS-install-dir>\VC\Auxiliary\Build\Microsoft.VCToolsVersion.Preview.txtCMakeプロジェクトの場合
CMakeでは、Previewをインストールしただけで既存のビルドディレクトリが新しいコンパイラへ切り替わるとは限りません。CMakeCache.txtに以前のコンパイラパスが保存されているためです。
Visual Studioジェネレーターを使用する場合は、CMakePresets.jsonのtoolsetでMSVCバージョンを明示します。Visual Studio 2026のプラットフォームツールセットはv145ですが、v145という表示だけでは19.52.36520以上を使用しているか判断できません。最終的にはビルドログと実行ファイルのバージョンを確認します。(Aka.ms)
Ninjaなど、環境変数からコンパイラを取得するジェネレーターでは、Preview用のvcvarsを実行した新しいコマンドプロンプトから構成し直します。
call "<VS-install-dir>\VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=Preview
cmake -S . -B build -G Ninja
cmake --build build既存のbuildディレクトリをそのまま再利用せず、後述するクリーン手順を実施してください。
cl.exeとlink.exeのバージョンを確認する
更新後は、新しいDeveloper Command Promptまたはターミナルを開きます。更新前から開いていたターミナルには古いPATHが残っている可能性があります。
最初に、実行されるファイルの場所を確認します。
where cl
where link複数のパスが表示された場合、通常は先頭の実行ファイルが使われます。Visual Studio 2022、Visual Studio 2026 Stable、Insiders、Build Toolsが同居している環境では、想定外のパスが先頭になっていないか確認してください。
続いてバージョンを確認します。
cl /Bv
link /?判定基準は次のとおりです。
cl.exe : 19.52.36520 以上
link.exe : 14.52.36520 以上cl.exeだけが条件を満たし、link.exeが古い場合は、コンパイラとリンカーが別のインストール先から読み込まれています。vcvarsを実行し直し、where clとwhere linkの先頭パスをそろえてください。
Visual Studio上のビルドでは、出力ウィンドウを「詳細」に変更し、実際に呼び出されたcl.exeとlink.exeの絶対パスも確認します。IDE内のターミナルで確認したバージョンと、プロジェクトビルドが使用するバージョンが同じとは限りません。
更新後はC++ Modulesの成果物を含めてクリーンビルドする
MSVCを更新した後に通常の差分ビルドだけを実行すると、旧コンパイラで生成されたモジュール成果物やオブジェクトファイルが再利用される可能性があります。
特に削除対象となるのは次のファイルです。
.ifc.obj.pch.lib.exp.pdb- CMakeの
CMakeCache.txt - モジュールやヘッダーユニットのキャッシュ
- プロジェクトで設定した中間ディレクトリの内容
Visual Studio／MSBuildでの手順
- 「ビルド」から「ソリューションのクリーン」を実行します。
- Visual Studioを終了します。
- 各プロジェクトの中間ディレクトリと出力ディレクトリを削除します。
.ifcの出力先を独自指定している場合は、そのディレクトリも削除します。- Visual Studioを再起動します。
- Previewが有効になっていることを確認します。
- ソリューション全体をリビルドします。
「ソリューションのクリーン」だけでは、独自に配置したモジュールキャッシュや外部ビルドシステムの成果物が残る場合があります。C1001やC1116の再検証では、モジュール依存グラフ全体を作り直すことが重要です。
CMakeでの手順
CMakeでは、ツールチェーンを変更するときにビルドディレクトリを作り直す方が確実です。
rmdir /s /q build
call "<VS-install-dir>\VC\Auxiliary\Build\vcvars64.bat" -vcvars_ver=Preview
cmake -S . -B build -G Ninja
cmake --build buildビルドディレクトリに手動作成したファイルがある場合は、削除前に退避してください。ソースディレクトリやパッケージ管理用キャッシュまで一括削除する必要はありません。
CIでもキャッシュを無効化する
開発者PCだけを更新しても、CIエージェントが旧MSVCを使っていれば同じエラーが続きます。
CIでは次の対応が必要です。
- すべてのWindowsビルドエージェントへPreviewを導入する
- パイプラインの先頭で
cl /Bvとlink /?を記録する - コンパイラバージョンをビルドキャッシュのキーへ含める
- 旧バージョンで作成したIFCやオブジェクトキャッシュを破棄する
- Release、Debug、x64、ARM64ごとに中間ディレクトリを分離する
- ローカルとCIで同じプロジェクトプロパティを使用する
たとえば、キャッシュキーにmsvc-19.52.36520-x64-releaseのような識別子を含めると、旧コンパイラの成果物が再利用されにくくなります。
更新しても直らない場合のチェックリスト
| 症状 | 主な原因 | 対処 |
|---|---|---|
cl.exeが19.51以前 | Previewが選択されていない | プロジェクトのPreview設定とPATHを確認 |
| Installerでは導入済みなのに旧版が動く | バージョン固定または古いターミナル | Latest supportedへ変更し、ターミナルを開き直す |
| Debugでは直るがReleaseで再発 | 構成ごとの設定漏れ、最適化依存 | Release側のPreview設定とビルドログを確認 |
| 一部プロジェクトだけC1116になる | プロジェクト単位の設定差 | すべてのC++プロジェクトを確認 |
| クリーン後も同じC1001が出る | 今回とは別の内部コンパイラエラー | 最小再現、最適化切り分け、問題報告 |
| LNK4321が残る | 実際にモジュールエクスポートが重複 | .ixx、.obj、.libの重複入力を除去 |
| ローカルでは成功しCIで失敗 | CIのBuild Toolsが古い | エージェント更新とバージョンログ追加 |
| 毎回結果が変わる | 異なるMSVCやキャッシュが混在 | ツールパスと中間ディレクトリを固定 |
特に見落としやすいのは、ソリューション内の一部プロジェクトだけが古いMSVCへ固定されているケースです。モジュールを生成するプロジェクトと、モジュールを利用するプロジェクトの両方で同じツールセットを使用してください。
Previewを本番ビルドへ採用するときの注意点
MSVC Build Tools Previewは、不具合修正を早期に検証できる一方、正式な安定版とは運用条件が異なります。
Microsoftは、Previewビルドにはサービス更新が提供されず、本番環境での利用を想定していないと説明しています。また、PreviewはVisual Studioの更新に合わせて新しいビルドへ切り替わり、特定ビルドの固定を前提としていません。(Aka.ms)
実務では、次の運用が安全です。
- まず専用ブランチや検証用CIで導入する
- コンパイラとリンカーの完全なバージョンをログへ残す
- 既存の単体テスト、結合テスト、性能テストを実行する
- 生成物を正式リリースへ使うかは組織のサポート方針に基づいて判断する
- 修正がGA版へ入った後は、サポート対象の安定版へ移行する
- Previewの自動更新によるビルド差分を監視する
C1001やC1116で開発が停止している場合、v14.52 Previewは有効な検証・回避手段です。ただし、Previewでビルドが通ったことだけで本番採用を決めず、実行時の回帰テストまで行う必要があります。
最終的に行うべき対応
C++ Modules環境で今回のC1001またはC1116が発生している場合は、次の順序で対応します。
- Visual Studio InstallerでMSVC v14.52 Previewを導入する
- x64/x86またはARM64/ARM64EC用のPreviewコンポーネントを選択する
- プロジェクトで「Use MSVC Build Tools Preview」を有効にする
cl.exeが19.52.36520以上か確認するlink.exeが14.52.36520以上か確認する- IFC、OBJ、PCH、CMakeキャッシュを含めてクリーンビルドする
- C1001／C1116が解消したか確認する
- LNK4321が出た場合は、重複したモジュールエクスポートを調査する
- CIでも同じMSVCバージョンを使用する
- 正式リリース用途ではPreviewのサポート条件を考慮する
最低条件である19.52.36520／14.52.36520を満たしていても、古いモジュール成果物や別プロジェクトのツールセットが混在していると、修正効果を正しく確認できません。更新、ツール選択、バージョン確認、完全な再ビルドを一連の作業として実施することが、最も確実な解決方法です。
コメント