Microsoftが2026年7月10日時点で公開したPure Virtual C++ 2026の事前情報は、MSVCの新機能が一斉に適用されるという告知ではありません。公式ページ上の日付は米国時間の2026年7月9日で、イベントに向けて「ビルドを速くする」2つのセッションを紹介する内容です。実務で確認すべきなのは、C++/WinRT 3.xのC++20名前付きモジュールと、GitHub Copilot build performance for Windowsの2点です。(Microsoft for Developers)
結論として、C++/WinRTを複数プロジェクトで利用し、PCHや中間生成物が肥大化しているチームはC++20 Modulesを検証する価値があります。また、Windows上のMSBuildまたはCMakeプロジェクトでビルド待ちが長い場合は、GitHub Copilotによるビルド分析を試す候補になります。
一方、セッションのテーマに「Run Faster」とあるものの、今回紹介された具体的な内容は、主にコンパイル時間、インクリメンタルビルド、PCH、IFC、中間生成物の削減です。アプリケーションの実行速度が自動的に向上する新しいランタイム機能が発表されたわけではありません。(Microsoft for Developers)
Microsoft C++ developer toolingの今回の発表で何が変わるのか
Pure Virtual C++ 2026で紹介される「Build Faster, Run Faster」関連セッションは、次の2つです。
| セッション | 主な対象 | 改善するもの | 提供状況 |
|---|---|---|---|
| C++/WinRT: Build Faster and Smaller with C++20 Modules | C++/WinRT、WinUI、Windows Runtimeを使うプロジェクト | コンパイル時間、PCH、中間生成物、ビルド時ディスク使用量 | C++/WinRT 3.xで利用可能 |
| Cut Your Build Times Without Becoming a Build Expert | Windows上のMSBuild・CMakeプロジェクト | 高コストなヘッダー、テンプレート実体化、関数生成時間 | GitHub Copilot機能として公開プレビュー |
前者はコンパイル方式そのものをヘッダーベースからモジュールベースへ切り替える施策です。後者はBuild Insightsの計測結果をGitHub Copilotが分析し、修正と再計測を繰り返す支援機能です。(Microsoft for Developers)
Pure Virtual C++ 2026は2026年7月21日16時UTC、日本時間では7月22日午前1時から配信予定です。YouTubeとTwitchでライブ配信され、終了後はVisual StudioのYouTubeチャンネルでオンデマンド視聴できると案内されています。(Microsoft for Developers)
C++/WinRT 3.xのC++20 Modulesは何を変えるのか
ヘッダーの読み込みから名前付きモジュールのインポートへ変わる
従来のC++/WinRTでは、利用するWindows Runtime名前空間に対応するヘッダーをインクルードします。
#include <winrt/Windows.Foundation.h>C++20 Modulesを利用すると、次のように名前付きモジュールをインポートできます。
import winrt.Windows.Foundation;C++/WinRT 3.xは、従来のプロジェクションヘッダーに加えて、名前空間ごとの.ixxモジュールインターフェースを生成できます。モジュールを有効にするCppWinRTBuildModuleの既定値はfalseであるため、C++/WinRT 3.xへ更新しただけで既存プロジェクトが自動的にモジュール方式へ切り替わることはありません。(GitHub)
つまり、既存のヘッダーベース実装はそのまま維持できます。モジュール化は明示的に選択し、プロジェクト単位で段階的に導入する機能です。
ビルド時間だけでなくPCHと中間生成物も削減できる
ヘッダー方式では、同じヘッダーが複数の翻訳単位で繰り返しプリプロセスされます。PCHを利用すればプロジェクト内の重複処理は減らせますが、複数の.vcxprojがある場合、それぞれのプロジェクトでPCHを生成する必要があります。
名前付きモジュールでは、コンパイル済みのインターフェース情報がIFCとして保存されます。専用のモジュールビルダープロジェクトでIFCを一度生成し、複数プロジェクトから共有する構成も可能です。モジュールはマクロをインポート先へ漏らさないため、ヘッダーの順序やマクロ定義による影響も抑えられます。(Microsoft Learn)
MicrosoftがWindows Terminalのコードベースを用いて行った検証では、ビルド時間が約22分から19分へ短縮され、ビルド時のディスク使用量が約30GBから18GBへ減少しました。PCHのサイズが最大約80％減り、PCH生成時間が約40秒から約5秒になったケースも示されています。ただし、これは特定の大規模プロジェクトにおける結果であり、すべてのプロジェクトで同じ改善率になるわけではありません。(GitHub)
従来方式との主な仕様差分
| 確認項目 | 従来のヘッダー方式 | C++20 Modules方式 |
|---|---|---|
| 読み込み方法 | #include | import |
| 主な生成物 | ヘッダー、PCH | 名前空間別.ixx、IFC |
| 複数プロジェクトでの再利用 | PCHは原則プロジェクトごと | 専用ビルダーでIFCを共有可能 |
| マクロ | インクルード先へ影響する | 原則としてインポート先へ公開されない |
| 導入方法 | C++/WinRTの標準的な既存方式 | CppWinRTBuildModuleによる明示的な有効化 |
| 言語標準 | C++17でも利用可能 | C++20以降が必要 |
| ツールセット間の互換性 | 通常のソース再ビルドで対応しやすい | IFCは異なるツールセット間で互換性がない |
| PCHとの関係 | WinRTヘッダーをPCHへ入れる構成が一般的 | importをPCHへ入れてはいけない |
モジュール化で変わるのは、主にコンパイル時のコード取り込み方法です。winrt::Windows::Foundationなど、アプリケーションコードから使用する基本的な名前空間や型が別のAPIへ置き換わるわけではありません。
ただし、マクロやヘッダーガードの副作用に依存したコードは、そのままでは動作しない場合があります。特にWILなど、C++/WinRTヘッダーのガード定義を確認して機能を切り替えるライブラリでは、ラッパーヘッダーやWINRT_IMPORT_MODULEの設定が必要になることがあります。(GitHub)
既存実装との互換性で注意するポイント
C++/WinRT 3.0にはモジュール以外の破壊的変更もある
C++/WinRT 3.0では、非標準のコルーチンを利用する/awaitオプションと<experimental/coroutine>のサポートが削除されました。
NuGetパッケージの標準設定を使用し、プロジェクトへ手動で/awaitを追加していない場合、C++17ビルドではターゲットファイルが/await:strictを設定するため、変更が不要な可能性があります。一方、/awaitや実験的コルーチンへ直接依存しているコードは、C++/WinRT 3.xへ更新する前に修正が必要です。(GitHub)
モジュール導入とパッケージのメジャーバージョン更新を同時に行うと、不具合の原因を切り分けにくくなります。最初にC++/WinRT 3.xへ更新してヘッダー方式のまま動作確認し、その後にモジュールを有効化する手順が安全です。
PCH内へimportを書かない
現在の公式ガイドでは、MSVCの制約により、PCH内のimportが内部コンパイラエラーを引き起こす可能性があると説明されています。
従来のpch.hに入れていた次のような記述は削除し、通常の.cppファイルから読み込むモジュール用のプリンブルヘッダーへ移します。
#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Foundation.Collections.h>移行後の構成例は次のとおりです。
// ModulePreamble.h
#pragma once
#define WINRT_IMPORT_MODULE
import winrt.Windows.Foundation;
import winrt.Windows.Foundation.Collections;各ソースファイルでは、PCHの後に読み込みます。
#include "pch.h"
#include "ModulePreamble.h"モジュールをPCHへ直接入れるのではなく、PCHとモジュール用プリンブルを分離することが重要です。(GitHub)
includeとimportを無計画に混在させない
同じ名前空間について、先にimportしてから同じ内容のC++/WinRTヘッダーを#includeすると、型や宣言の再定義エラーが発生する可能性があります。
外部ライブラリや自動生成コードがWinRTヘッダーをインクルードする場合は、WINRT_IMPORT_MODULEを定義したうえでヘッダーを読み込み、インクルードガードのみを有効にする方法が用意されています。単純な機械置換ではなく、各翻訳単位でヘッダーとモジュールの読み込み順を確認してください。(GitHub)
XAMLプロジェクトは追加設定が必要になる
WinUIやXAMLを含むC++/WinRTプロジェクトでは、XAMLコンパイラがXamlTypeInfo.g.cppなどのソースを生成します。これらの生成ファイルはモジュールの存在を認識しないため、/FIによる強制インクルードでモジュール用プリンブルを注入する必要があります。
XAMLのコンパイルは複数パスに分かれているため、通常のソースファイルだけがビルドできても、生成コードのコンパイルやリンクで失敗することがあります。XAMLプロジェクトを最初の移行対象にせず、依存関係の少ないユーティリティープロジェクトから始めるほうが原因を切り分けやすくなります。(GitHub)
IFCを異なるビルド条件で共有しない
モジュールのIFCには、コンパイル時の前提条件が含まれます。次の設定が異なるプロジェクト間でIFCを共有すると、コンパイラが明確なエラーを出さないまま、ABIや型レイアウトの不一致が発生する可能性があります。
- MSVCツールセットのバージョン
- DebugとRelease
- プリプロセッサ定義
- ランタイムライブラリ
- 構造体のアライメントと
/Zp /std:c++20、/std:c++23、/std:c++latest- 対象アーキテクチャ
公式ガイドでは、IFCは異なるツールセット間で互換性がないため、同じソリューション内の全プロジェクトでツールセットを統一するよう求めています。(GitHub)
コンポーネント用IFCを外部プロジェクトへそのまま渡さない
CppWinRTConsumeModuleは、Windows SDKなどのプラットフォームモジュールを生成する専用の静的ライブラリープロジェクトで使用することが想定されています。
WinRTコンポーネントの内部用モジュールを別のDLLやEXEから直接参照すると、アクティベーションファクトリを経由しない内部向けコードが使われ、リンクエラーや不正な動作につながる可能性があります。各利用側プロジェクトは、コンポーネントの.winmdから自身の参照プロジェクションを生成する必要があります。(GitHub)
C++20 Modulesの導入条件
C++/WinRTのモジュールを検証する場合は、少なくとも次の条件を満たす必要があります。
| 項目 | 条件 |
|---|---|
| C++/WinRT | 3.0以降 |
| MSVC Build Tools | 14.50以降 |
| 推奨ツールセット | Visual Studio 2026のv145以降 |
| C++言語標準 | C++20以降 |
| STLモジュール | import std;を使う場合はBuildStlModules=true |
| プロジェクト設定 | CppWinRTBuildModule=true |
| 複数プロジェクト | 専用の静的ライブラリーでプラットフォームIFCを共有する構成を推奨 |
| ビルド条件 | ビルダーと利用側でツールセットやコンパイル条件を統一 |
Pure Virtual C++ 2026の案内では、C++/WinRT 3.0以降とMSVC Build Tools 14.50以降が開始条件として示されています。最新のモジュールガイドでは、Visual Studio 2026のv145ツールセットとC++20以降が前提です。(Microsoft for Developers)
最小構成の設定例
既存の条件付きPropertyGroupやItemDefinitionGroupへ、次の設定を追加します。
<PropertyGroup>
<CppWinRTBuildModule>true</CppWinRTBuildModule>
<CppWinRTModuleInclude>
Windows.Foundation;Windows.Storage
</CppWinRTModuleInclude>
</PropertyGroup>
<ItemDefinitionGroup>
<ClCompile>
<BuildStlModules>true</BuildStlModules>
</ClCompile>
</ItemDefinitionGroup>CppWinRTModuleIncludeを指定しない場合、WinMDから到達できる多数の名前空間が生成対象になります。Windows SDK全体では数百の名前空間が対象となり、クリーンビルドへ1分以上の処理が追加されることがあります。
最初からすべての名前空間をモジュール化するのではなく、実際に利用する名前空間だけをCppWinRTModuleIncludeへ指定してください。依存する名前空間が除外されていると、could not find moduleエラーが発生するため、推移的な依存関係も確認する必要があります。(GitHub)
検証では最新のC++/WinRT 3.xを使う
2026年7月18日時点では、C++/WinRT 3.0.260715.1が最新リリースです。このバージョンにはモジュール導入ガイドの整備に加え、MSVCのモジュール関連問題に対する回避策が含まれています。(GitHub)
初期の3.0系では、モジュール内のwinrt::impl::get_marshaler()に関連し、仮想関数の呼び出し時にクラッシュする可能性があるMSVC側の問題が確認されました。修正版では不要なエクスポートを停止することで回避されています。検証環境を古い3.0初期版へ固定せず、現行の修正版以降を利用することが重要です。(GitHub)
GitHub Copilot build performance for Windowsは何をするのか
GitHub Copilot build performance for Windowsは、Visual StudioからC++ Build Insightsを実行し、ビルドトレースをGitHub Copilotが分析する機能です。
基本的な処理は次の流れです。
- 対象プロジェクトをビルドし、診断トレースを取得する
- 高コストなヘッダーを特定する
- 長時間かかっている関数生成やテンプレート実体化を特定する
- プロジェクト設定やコードの修正案を作成する
- 修正を適用して再ビルドする
- 変更前後のビルド時間を比較する
- 効果のなかった変更を戻し、次の改善候補を提示する
Copilotが分析と編集を担当しますが、最終的にどの変更を採用するかは利用者が決定します。公式のセッション案内では、クリーンビルドがわずかに遅くなってもインクリメンタルビルドが大幅に速くなる、といったトレードオフも数値で確認する構成が説明されています。(Microsoft for Developers)
導入条件
| 項目 | 必要条件 |
|---|---|
| Visual Studio | Visual Studio 2026 version 18.3 Insiders 4以降 |
| MSVC Build Tools | 14.50以降 |
| OS | Windows 10以降 |
| プロジェクト形式 | MSBuildまたはCMake |
| GitHub Copilot | Pro、Pro+、Business、Enterpriseのいずれか |
| Visual Studioコンポーネント | C++ Build Insights、C++プロファイリングツール、CMake Tools |
| アカウント | Visual StudioでGitHubアカウントへサインイン |
この機能は公開プレビューであり、一般提供版の安定機能として全環境へ展開されているわけではありません。Visual Studio 2026 Insidersを使用できない開発環境では、現時点の導入対象になりません。(Aka.ms)
テンプレート実体化の収集は手動で有効にする
テンプレート実体化時間の収集は、解析時のオーバーヘッドを抑えるため、初期状態では無効です。
テンプレートを多用するプロジェクトを分析する場合は、Visual Studioで次の設定を有効にします。
Tools
> Options
> Build Insights
> Collect Template Instantiationこの設定を有効にしないと、高コストなテンプレート実体化が主要な原因であっても、十分な分析結果を得られない可能性があります。(Aka.ms)
初回利用時は管理者権限が必要になる
Build InsightsがMSVCのコンパイラートレースを取得する際、初回のみ昇格要求とWindowsのユーザーアカウント制御が表示される場合があります。権限を拒否すると、ビルド分析は中止されます。
また、Copilotが調査や修正を進める過程で、PowerShellやターミナルコマンドの実行許可を求めることがあります。検証環境では無条件の常時許可を避け、まずはセッション単位で許可し、実行されるコマンドを確認する運用が安全です。(Aka.ms)
大規模ソリューションでは単一プロジェクトを指定できる
最新のVisual Studio Insidersでは、ソリューション全体ではなく、特定のMSBuildプロジェクトやCMakeターゲットだけを分析できます。
Solution Explorerからプロジェクトを右クリックし、次の項目を選択します。
Run Build Insights
> Improve Build PerformanceCopilot Chatで@BuildPerfCppを選択し、対象プロジェクト名を指定する方法もあります。
ただし、対象プロジェクトが深い依存関係を持つ場合、依存プロジェクトのビルド時間は残ります。CMakeでは選択するターゲットが共通のルートプロジェクトに属している必要があり、ファイル単位の分析は現時点でサポートされていません。(Microsoft for Developers)
テスト時に必ず確認するポイント
1回の計測結果だけで判断しない
ビルド時間は、ファイルキャッシュ、ウイルス対策ソフト、CPUの温度、バックグラウンド処理、ストレージキャッシュなどの影響を受けます。
変更前後を比較するときは、次の条件を統一してください。
- 同じPCと電源設定を使用する
- 同じツールセットとWindows SDKを使用する
- 同じDebug・Release設定を使用する
- バックグラウンドの更新処理を停止する
- コールドビルドとウォームビルドを分ける
- それぞれ複数回実行し、中央値を比較する
1回だけ数秒速くなった結果ではなく、複数回の計測で再現できる改善を採用基準にします。
クリーンビルドとインクリメンタルビルドを分ける
少なくとも次の4パターンを計測してください。
| テスト | 確認する内容 |
|---|---|
| 完全なクリーンビルド | 初回生成を含めた総時間 |
| 変更なしの再ビルド | 不要な再コンパイルが発生していないか |
.cppを1ファイル変更 | 通常の反復開発速度 |
| 共通ヘッダーやモジュールを変更 | 影響範囲が広い変更時の速度 |
モジュールの初回生成には時間がかかるため、クリーンビルドだけを見ると遅くなる場合があります。一方、複数プロジェクトでIFCを再利用できれば、通常の反復開発では大きな効果が出る可能性があります。
時間以外の指標も記録する
ビルド時間だけでなく、次の項目も記録します。
- 中間ディレクトリの合計サイズ
- PCHとIFCのサイズ
- ピークメモリ使用量
- クリーンビルドとインクリメンタルビルドの差
- 生成された実行ファイルやDLLのサイズ
- 警告件数
- CI環境での再現性
- キャッシュ無効時の挙動
開発PCでは速くても、CIエージェントでIFCの再利用ができず、全体では効果が出ない場合があります。ローカル環境とCI環境の両方で計測してください。
モジュール設定を変更したら中間ファイルを削除する
CppWinRTModuleIncludeやCppWinRTModuleExcludeを変更すると、古いIFCが中間ディレクトリに残り、同じモジュールが複数存在するように見える場合があります。
設定変更後はVisual Studioの「Rebuild」だけに頼らず、必要に応じてIntDirや生成済みIFCを削除してからクリーンビルドします。古いIFCが残ると、C7684の曖昧なモジュール解決エラーなど、現在の設定とは関係のないエラーが発生することがあります。(GitHub)
動作テストを省略しない
モジュール化はビルド方式の変更ですが、マクロ、ヘッダーガード、構造体アライメント、生成コードなどへ影響します。
該当する場合は、次のテストを実施してください。
- WinRTオブジェクトの生成と破棄
- COMインターフェースの取得
- 非同期処理とコルーチン
- XAML画面の起動と画面遷移
- WinUIコントロールのバインディング
- ファイルピッカーなどWindows APIの呼び出し
- x64とARM64の両方
- DebugとReleaseの両方
- 単体テストと統合テスト
コンパイルが通ることだけで、互換性が確認できたとは判断しないことが重要です。
Copilotの変更は必ず差分レビューする
GitHub Copilot build performanceは、設定やソースコードを実際に変更します。検証時は専用ブランチを作成し、1回の改善ごとに差分を確認してください。
特に次の変更は慎重に評価します。
- PCHの有効化や対象ヘッダーの変更
- ヘッダーからソースファイルへの実装移動
- インライン関数の変更
- テンプレートコードの分割
- include順序の変更
- CMakeLists.txtや
.vcxprojの変更 - ビルドオプションの追加や削除
ビルド時間が短くなっても、バイナリーサイズ、実行速度、デバッグ性、移植性が悪化する可能性があります。Copilotが示した数値だけでなく、変更内容とチームの開発方針を合わせて判断してください。
対応要否の判断基準
| 現在の状況 | 推奨する対応 |
|---|---|
C++/WinRTを複数の.vcxprojで利用している | C++20 Modulesを小規模に検証する |
| WinRTやXAMLのPCHが大きい | モジュールビルダープロジェクトを検討する |
| ビルド時の中間生成物が数十GBに達する | モジュール化の効果を計測する |
C++/WinRT 2.xで手動の/awaitを使用している | 先にコルーチン互換性を確認する |
| Visual Studio 2022やv143へ固定している | 現時点ではモジュール移行を急がない |
| C++17から変更できない | C++20 Modulesの導入は見送る |
| Windows上のMSBuild・CMakeビルドが長い | Copilot build performanceを検証する |
| Insiders版や公開プレビューを利用できない | Build Insightsによる手動分析を継続する |
| AIによるコマンド実行が組織ポリシーで禁止されている | Copilot機能は導入しない |
| ビルドは速いがアプリの処理速度が遅い | 今回の機能ではなく実行時プロファイラーを使う |
| LinuxやmacOSだけで開発している | Copilot build performance for Windowsの直接対象外 |
C++/WinRT Modulesは、すべてのプロジェクトに一律で適用するものではありません。WinRTヘッダーの処理が実際のボトルネックになっているかをBuild Insightsなどで確認してから導入します。
GitHub Copilot build performanceについても、公開プレビューを利用できる環境で、ビルド待ちが開発生産性の問題になっている場合に限定して検証するのが適切です。
よくある誤解と失敗しやすいポイント
「Run Faster」とあるので実行速度も上がる
今回紹介された2セッションで中心となるのはビルド性能です。モジュール化によってコンパイル時の処理や中間生成物は削減できますが、アプリケーションのホットパスやアルゴリズムが自動的に高速化されるわけではありません。
C++/WinRT 3.xへ更新すれば自動でモジュール化される
CppWinRTBuildModuleの既定値はfalseです。既存のヘッダー方式は維持されるため、モジュール化にはプロジェクト設定とソースコードの変更が必要です。
すべての名前空間を生成したほうが速い
利用しない名前空間までモジュール化すると、初回ビルド時間とIFCサイズが増えます。CppWinRTModuleIncludeで対象を絞り、必要な推移的依存関係だけを追加するほうが効率的です。
PCHへimportを書けばさらに速くなる
現在のMSVCでは、PCH内のimportが内部コンパイラエラーにつながる可能性があります。PCHとモジュールプリンブルを分離してください。
Copilotが提案した変更はすべて採用してよい
Copilotは計測結果に基づいて変更しますが、ビルド速度以外の設計要件まですべて把握しているとは限りません。差分レビュー、機能テスト、複数構成でのビルド確認が必要です。
対応は計測、小規模検証、段階展開の順で進める
Pure Virtual C++ 2026の今回の事前情報は、全C++開発者に即時対応を求めるものではありません。対応の優先順位は、現在のビルドボトルネックによって決まります。
C++/WinRTを利用している場合は、まずC++/WinRT 3.xへ更新し、従来のヘッダー方式で互換性を確認します。その後、依存関係の少ない1プロジェクトだけでC++20 Modulesを有効にし、クリーンビルド、インクリメンタルビルド、中間生成物、機能テストを比較してください。
一般的なWindows C++プロジェクトでは、Visual Studio 2026 Insidersと必要なGitHub Copilot契約を用意できる場合に限り、専用ブランチでBuild Performanceエージェントを試します。提案された変更は1件ずつ確認し、再現性のある改善だけを残します。
最も重要なのは、「新機能があるから導入する」のではなく、現在のビルド時間を計測し、改善幅が移行コストを上回るか判断することです。
コメント