Visual C++ ランタイムの互換性は、名前が似ていて複雑そうに見えますが、判断軸は実はシンプルです。Visual Studio 2015 以降で作られたアプリは v14 系としてまとめて考え、Visual Studio 2013 以前は別世代として個別に扱う。この2つを押さえるだけで、ほとんどの導入判断は外しません。しかも 2013 以前のランタイムは v14 系で置き換わらないため、古い Visual C++ Redistributable を整理目的で消すのは危険です。 (Microsoft Learn)
この記事では、DLL 名から必要世代を見分ける方法、x86/x64/ARM64 の判断、Visual Studio の設定場所、中央配置・ローカル配置・静的リンクの違い、失敗しやすいポイント、戻し方と代替策まで、実務でそのまま使える形で整理します。一般に「Visual C++ ランタイム」と呼ばれますが、実際に導入・配布する単位は Visual C++ Redistributable（再頒布可能パッケージ）です。これが必要なランタイム ライブラリをまとめてインストールします。 (Microsoft Learn)
Visual C++ ランタイムの互換性はこの表でほぼ判断できる
まずは、世代ごとの整理を頭に入れておくと迷いません。代表的な DLL 名と導入判断を並べると、次のようになります。 (Microsoft Learn)
| 世代の目安 | 代表的な DLL 名 | 互換性の考え方 | 導入判断 |
|---|---|---|---|
| Visual Studio 2015 以降の v14 系 | msvcp140.dll, vcruntime140.dll, concrt140.dll, mfc140u.dll | v14 系は同じメジャー系として扱う。新しい再頒布可能パッケージは古い v14 系アプリとバイナリ互換 | 最新の v14 系 Redistributable を入れる |
| Visual Studio 2013 | msvcp120.dll, mfc120u.dll | v14 系とは別世代 | VC++ 2013 を別途入れる |
| Visual Studio 2012 | msvcp110.dll | v14 系とは別世代 | VC++ 2012 を別途入れる |
| Visual Studio 2010 | msvcr100.dll, msvcp100.dll | v14 系とは別世代 | VC++ 2010 を別途入れる |
| Visual Studio 2008 / 2005 | msvcr90.dll, msvcr80.dll | 完全に別世代 | 対応する旧版 を個別に入れる |
ポイントは、2015 以降の v14 系だけが「新しいものが古いものを包含する」と考えればよいことです。一方で 2013 以前は横に並んで共存する世界なので、「新しい版を入れたから古い版は不要」とは言えません。 (Microsoft Learn)
導入判断の前に確認する3つのポイント
DLL 名から世代を見分ける
一番手っ取り早いのは、エラーに出ている DLL 名を見る方法です。msvcp140.dll や vcruntime140.dll なら v14 系、msvcp120.dll なら 2013、msvcp110.dll なら 2012、msvcr100.dll なら 2010 という具合に、数字がそのまま世代判定の手掛かりになります。MFC を使うアプリなら mfc120u.dll や mfc140u.dll のような名前もよく出ます。 (Microsoft Learn)
実務では、「アプリ名」で探すより「不足している DLL 名」で探したほうが早いケースが多いです。特に古い業務アプリや配布元が曖昧なツールは、製品名では必要ランタイムが分からなくても、DLL 名から世代だけはほぼ特定できます。 (Microsoft Learn)
x86 / x64 / ARM64 を切り分ける
次に見るのがアーキテクチャです。ここを外すと、正しい世代を選んでも起動しません。Microsoft の説明でも、再頒布可能パッケージのアーキテクチャはアプリのターゲット アーキテクチャに合わせる必要があります。64bit Windows 上でも 32bit アプリは x86 のランタイムを使うため、x64 端末だから x64 版だけ入れればよいとは限りません。 (Microsoft Learn)
ARM64 端末は少しだけ特殊です。現行の公式 x64 再頒布可能パッケージには、ARM64 と x64 の両方のバイナリが含まれます。そのため、ARM64 デバイスで x64 アプリも扱う構成では、この仕様を理解しておくと無駄な入れ直しを減らせます。 (Microsoft Learn)
自社開発なら /MD と /MT も確認する
配布先で困らないようにするには、アプリをどうビルドしているかも重要です。Visual Studio では [構成プロパティ] > [C/C++] > [コード生成] > [ランタイム ライブラリ] で /MD と /MT を切り替えられます。/MD は DLL 版ランタイムを使う動的リンク、/MT は静的リンクです。さらに、同じリンク単位に入るモジュールは、同じランタイム ライブラリ オプションでコンパイルされている必要があります。 (Microsoft Learn)
ここを揃えずにライブラリを混在させると、単に「ランタイムを入れたかどうか」の問題ではなくなります。加えて /GL や /LTCG を使ったビルドは、v14 系同士でもマイナー更新をまたいだ完全互換ではありません。バイナリ互換性があるから何でも混ぜてよい、とは考えないほうが安全です。 (Microsoft Learn)
設定場所と確認場所はここだけ押さえれば足りる
運用と開発の両方でよく使う場所は、次の4つです。 (Microsoft Learn)
| 確認・変更したいこと | 見る場所 / 設定場所 | 使いどころ | ||
|---|---|---|---|---|
| v14 系ランタイムの現在バージョン | HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\14.0\VC\Runtimes{x86 | x64 | arm64} | 配布スクリプトや導入判定 | ||
| /MD と /MT の切り替え | Visual Studio の [構成プロパティ] > [C/C++] > [コード生成] > [ランタイム ライブラリ] | 自社アプリのビルド設定確認 | ||
| 中央配置された DLL の配置先 | %windir%\System32、x64 環境の 32bit 用は %windir%\SysWOW64 | 実ファイル確認やトラブル切り分け | ||
| 古いランタイムを使うプロセスの監査 | NTFS 監査を有効化したうえで Event Viewer の Security ログ（Event ID 4663） | 旧版削除前の依存調査 |
特に v14 系は、インストーラーに組み込む前にレジストリの Version を見ておくと、あとで「新しい版が入っているのに古い版を流して失敗した」という事故を減らせます。 (Microsoft Learn)
迷ったら中央配置。導入方式の選び方
Visual C++ ランタイムの入れ方は、大きく分けると 3 つあります。Microsoft が基本線として勧めているのは中央配置です。 (Microsoft Learn)
| 方式 | 向いているケース | 利点 | 注意点 |
|---|---|---|---|
| 中央配置（Redistributable パッケージ） | 一般的な Windows アプリ配布、社内標準端末、インストーラー同梱 | Windows Update でライブラリを個別更新できる。最も無難 | アプリのアーキテクチャに合わせて x86 / x64 / ARM64 を選ぶ |
| ローカル配置（アプリ フォルダーに DLL 同梱） | 管理者権限が取りにくい、ポータブル配布、閉域網 | 端末全体に触らずに済む | 更新は自前で管理。放置すると脆弱性・不具合対応が遅れる |
| 静的リンク（/MT） | 単一バイナリ配布、完全に自社管理のアプリ | 外部ランタイム依存を減らせる | ランタイム更新のたびにアプリ再ビルド・再配布が必要 |
新規導入で merge module を選ぶ理由は、今ではほとんどありません。merge module は非推奨で、Microsoft も Redistributable パッケージによる中央配置を勧めています。 (Microsoft Learn)
なお、UCRT（Universal C Runtime）は Visual Studio 2015 以降で重要な前提です。Windows 10/11 では OS コンポーネントとして扱われ、ローカル配置した新しい UCRT よりシステム側が優先されます。古い OS では Windows Update や別途配布が前提になることがあります。古い OS で「Visual C++ ランタイムを入れたのに動かない」場合は、この前提を見落としていることがあります。 (Microsoft Learn)
古い版を消していいかは、互換性ではなく依存先で決める
「サポート外の古いランタイムが入っているから消したい」と考える人は多いですが、削除判断は互換性の話ではなく、その端末上のどのアプリが使っているかで決めるべきです。Microsoft のライフサイクル FAQ でも、一部の Microsoft 製品が旧版 VC++ ランタイムに依存する例が示されていますし、ネットワーク内にはサポート外ランタイムを使うアプリが残っている前提で、NTFS 監査で使用実態を確認する方法が案内されています。 (Microsoft Learn)
共有サーバー、VDI、RDS、長く使っている業務端末ほど、この考え方が重要です。見た目が古いからといって消すのではなく、誰が使っているかを監査してから置き換える。この順番にすると事故が起きにくくなります。 (Microsoft Learn)
失敗しやすいポイント
- 64bit Windows だから x64 だけ入れればよいと思い込むこと。 32bit アプリは x86 のランタイムを使うため、x64 端末でも x86 が必要になるケースは普通にあります。 (Microsoft Learn)
- v14 系を入れたから 2013 以前も動くと思うこと。 v14 系の互換性は 2015 以降の範囲です。2013 以前は別世代です。 (Microsoft Learn)
- 新しい v14 が入っているのに、古い v14 を重ねて流すこと。 v14 系はインプレースの累積更新なので、古いインストーラーは
0x80070666で止まるのが仕様です。 (Microsoft Learn) - DLL 配布サイトから
msvcp140.dllだけ拾って置くこと。 Microsoft は、Microsoft サイト以外から落とした Redistributable や、Microsoft が署名していないものを使わないよう明記しています。 (Microsoft Learn) - ローカル配置した DLL を放置すること。 ローカル配置は Microsoft が自動更新してくれないため、自前で更新管理しないと脆弱性や不具合修正が止まります。 (Microsoft Learn)
- Debug ビルドをそのまま配ること。 デバッグ版の実行ファイルやデバッグ DLL は再配布できません。配布物は Release 前提で考えるべきです。 (Microsoft Learn)
- /MD と /MT を混在させたり、/GL・/LTCG の条件を無視したりすること。 「ランタイムを入れれば解決」では済まない典型例です。 (Microsoft Learn)
実務向けの導入手順
迷ったときは、次の順で進めるとぶれません。
- まず、配布元の前提条件、インストーラーの必須要件、または不足している DLL 名を確認します。アプリ名より DLL 名のほうが世代判定に直結します。自社アプリなら依存 DLL の一覧も確認します。 (Microsoft Learn)
- DLL 名から世代を決めます。2015 以降で作ったアプリなら v14 系、2013 以前なら対応世代を個別に選びます。v14 系は、アプリをビルドした MSVC Build Tools と同じか、それより新しいバージョンの再頒布可能パッケージを使うのが原則です。 (Microsoft Learn)
- x86 / x64 / ARM64 を切り分けます。64bit Windows 上で 32bit アプリが動く環境なら、x86 と x64 の両方を管理対象に入れておくほうが実務的です。 (Microsoft Learn)
- ダウンロード元は Microsoft 公式に限定します。自社配布で同梱するなら、再配布ライセンス条件も確認します。 (Microsoft Learn)
- 通常は Redistributable パッケージによる中央配置で入れます。無人導入なら、次のようなコマンドで組み込めます。 (Microsoft Learn)
vc_redist.x64.exe /install /passive /norestart
vc_redist.x86.exe /install /passive /norestart- インストーラーに組み込む場合は、先に v14 のレジストリ バージョンを見て、すでに新しい版があればスキップします。確認せずに古い版を流すと、導入失敗扱いになることがあります。導入後にアプリが動かなければ、
%TEMP%/vscollect.zipからdd_vcredist_<arch>_yyyyMMddHHmmss系のログを確認します。 (Microsoft Learn)
うまくいかないときの戻し方と代替策
まず覚えておきたいのは、いきなりアンインストールしないことです。v14 系は累積更新なので、単純な「古い版に戻す」運用とは相性がよくありません。先に同じ再頒布可能パッケージの /repair を試し、それでもだめならログを見て原因を絞るほうが安全です。Visual Studio Installer 経由で失敗しているなら、最新の VC Redist を先に手動導入してから再試行する流れも有効です。 (Microsoft Learn)
トラブル時は、次の見方をしておくと復旧が早くなります。 (Microsoft Learn)
| エラー / 症状 | 意味の見立て | まず試すこと |
|---|---|---|
1603 | 汎用的なインストール失敗 | まずログ確認。最新版で再実行 |
5 | 権限不足 | 管理者で実行、保護ソフトやポリシー影響を切り分け |
32 | ファイル使用中 | アプリを閉じる、再起動して再試行 |
1620 | MSI / パッケージ破損 | 再ダウンロード。Visual Studio Installer 経由ならキャッシュ確認 |
1714 | 旧版が削除できない | ログから問題の旧版を特定し、Windows Installer か同じ旧版インストーラーで除去 |
特に 1714 は、壊れた旧版が残っていて更新できないときの定番です。この場合は、ログで引っかかっている旧版番号を確認し、その旧版の公式インストーラーを Microsoft から取り直してアンインストールに使う、という順で戻すのが定石です。逆に、ベンダー要件がないのに v14 を意図的にダウングレードする運用はおすすめしません。新しい v14 が入っている環境では、古い v14 のインストールが仕様上ブロックされるためです。 (Microsoft Learn)
代替策が必要なら、選び方はこうです。端末全体に入れたくないならローカル配置、外部ランタイム依存そのものを減らしたいなら /MT の静的リンクです。ただしローカル配置は更新責任を自分で持つ必要があり、静的リンクはランタイム更新のたびにアプリ全体を作り直して再配布する必要があります。どちらも例外策であって、標準策ではありません。 (Microsoft Learn)
迷ったら、最後はこの順で決めればよい
Visual C++ ランタイムの互換性で迷ったら、DLL 名で世代を見て、アーキテクチャを合わせ、導入方式は中央配置を優先する。これが最短ルートです。140 系なら最新の v14、120 110 100 90 80 なら対応する旧世代を個別に入れる。古い版は見た目だけで消さず、依存先を監査してから整理する。自社開発なら、あわせて /MD と /MT、そして /GL /LTCG の条件まで確認する。この順番で進めれば、Visual C++ ランタイムの導入判断で大きく外すことはありません。 (Microsoft Learn)
次にやることはシンプルです。手元のアプリで不足している DLL 名、アプリの x86 / x64、配布元が指定している前提条件の3つを確認し、それに対応する Microsoft 公式の再頒布可能パッケージを選んでください。ここまでできれば、導入作業はかなり安定します。 (Microsoft Learn)
コメント