Windows Server 2022でVB6/VC++6.0/COM+は動く？互換性・移行手順・DCOM対策まで完全ガイド

Windows Server 2016 上で稼働している VB6／VC++6.0 製の COM／COM+ システムを、Windows Server 2022 にそのまま持ち上げられるのか——この一点で悩む現場は少なくありません。本記事は「動く・動かない」を明快に整理しつつ、移行時にハマりやすいポイント、検証・運用の実践手順、トラブル対策までを網羅的にまとめた実務者向けガイドです。

対象と前提

既存：Windows Server 2016 で稼働
構成：Visual C++ 6.0 でビルドした COM DLL、および VB6 製 EXE
移行先：Windows Server 2022（64bit）
運用：COM/COM+（MTS/COM+ Services）を利用

結論サマリー（可否と対応策）

項目	結論・対応策	補足・注意点
VB6 ランタイム	サポート継続・動作可	ランタイム（`msvbvm60.dll` 等）は引き続き搭載。VB6 IDE は非サポートのため、開発・ビルドは旧 OS/VM で継続。
VC++6.0 生成バイナリ	概ね動作可	ツール自体（VC++6.0 IDE/コンパイラ）はサポート外。依存 DLL（`msvcrt.dll`、`mfc42(u).dll`、`msvcp60.dll` 等）は配布/同梱を前提に確認。
COM / COM+	継続利用可	COM 基盤は維持。COM+ も廃止されていない。DCOM の既定セキュリティ強化により、認証/暗号化レベルの調整が必要になりやすい。
登録（Registration）	`regsvr32` で登録	32bit DLL は `C:\Windows\SysWOW64\regsvr32.exe` を使用。64bit DLL は `C:\Windows\System32\regsvr32.exe`。
GUI（VB6 EXE）	Desktop Experience 版で安定	Server 2022 はインストール時に「Desktop Experience」有無を選択。後付けで GUI 化は不可。RDP 環境では DPI 差に留意。
ActiveX/OCX	個別検証が必須	古いコントロールは不安定な場合あり。署名なし OCX はブロックされやすい。必要に応じて再署名や代替コントロールを検討。
運用前検証	ステージングで全機能テスト	Server 2016 → 2022 で DCOM・ACL・UAC が厳格化。ファイル/レジストリ権限、サービスアカウント権限を重点確認。
将来計画	段階的モダナイズ推奨	C++17/20、.NET 8、WinAppSDK 等へ段階移行で保守性・セキュリティを改善。COM インターフェイス互換を活かした置換が現実的。

なぜ動くのか：互換性の根拠を仕組みから理解する

Windows は長年にわたり COM の互換性を重視しており、VB6 ランタイム／OLE 自動化／COM サービスは OS の中核機能として維持されています。VC++6.0 で生成したネイティブ DLL/EXE は Win32 API を利用しているため、64bit OS 上では WoW64（Windows-on-Windows 64）で 32bit プロセスとしてそのまま実行できます。COM+（旧 MTS）のアプリケーションも、dllhost.exe（COM サロゲート）によるホスティングが継続提供されているため、基本的な実行環境は変わりません。

Server 2016 → 2022 移行で追加される注意点

DCOM セキュリティ既定の強化：認証レベルが「None/Connect」だと拒否されるケースが増加。Packet Integrity/Privacy まで引き上げると安定します。
UAC と権限の厳格化：Program Files 配下への書き込み、レジストリの HKLM への書き込みはより制限的。データは ProgramData やユーザープロファイルへ。
暗号化/署名ポリシーの強化：SHA-1 署名のみのバイナリは信頼されにくい。SHA-256 で再署名する。
IE/Trident 依存：WebBrowser コントロールや HTML レンダリングを組み込む VB6 アプリは、描画エンジン周辺の互換性に差異が出る可能性あり。個別検証を必須化。

32bit/64bit の登録・管理パスを正しく使い分ける

64bit OS では 32bit と 64bit の COM 登録領域が分離されています。誤ったツールで登録すると「成功したように見えるが見つからない」という事象になります。次を厳守してください。

目的	使用するコマンド/パス	備考
32bit COM DLL の登録	`C:\Windows\SysWOW64\regsvr32.exe <dll>`	登録情報は `HKLM\Software\Classes\Wow6432Node\CLSID` 配下
64bit COM DLL の登録	`C:\Windows\System32\regsvr32.exe <dll>`	登録情報は `HKLM\Software\Classes\CLSID` 配下
32bit COM+ コンソール	`C:\Windows\SysWOW64\mmc.exe comexp.msc /32`	32bit コンポーネントの表示・操作は 32bit コンソールで

依存ランタイムのチェックと配布

VC++6.0 時代の DLL/EXE は OS に標準で存在しないライブラリに依存している場合があります。以下は典型例です。

mfc42.dll / mfc42u.dll
msvcp60.dll
msvcrt.dll（OS 提供。ただしバージョン差を前提にテスト）
古い ADO/MDAC、MSXML（MSXML6 を推奨。MSXML4 は非推奨）
データアクセス（Jet OLE DB は 32bit 限定。必要なら Access Database Engine など 64bit 代替と接続先を見直し）

配布形態は「アプリケーションと同一フォルダに同梱（Side-by-Side）」が衝突リスク低減に有効です。最終的には Dependency Walker / Dependencies 等で不足 DLL を洗い出し、ステージング OSで欠落がないか検証しましょう。

COM+（Component Services）の移行手順

現行サーバでエクスポート：Component Services → 対象アプリ右クリック → Export。MSI かアプリケーションファイルとして出力。
新サーバでインポート：同ツールから Import。Application Identity（実行アカウント）の再設定を忘れずに。
ロール/アクセス権：COM+ のロールベースアクセスや DCOM 設定（Launch/Activation/Access Permissions） を移行・再確認。
32bit/64bit：登録したコンポーネントのビット数に応じ、32bit Console での確認も行う。
動作確認：テストクライアントから CoCreateInstance、トランザクション、キューイング（必要な場合）を検証。

DCOM セキュリティを最初に整える（重要）

Server 2022 では DCOM のセキュリティが強化され、旧来の低い認証レベルや匿名呼び出しは失敗しやすくなりました。次の方針で設定します。

認証レベル：既定は Connect 以上。トラブル時は Packet Integrity または Packet Privacy に引き上げる。
偽装レベル：Impersonate（多くの業務アプリで無難）。委任が必要なら Delegate を検討。
AppID 単位での上書き：dcomcnfg → Component Services > Computers > My Computer > DCOM Config で対象 AppID を開き、セキュリティタブから起動/アクティブ化/アクセス許可を明示設定。
ファイアウォール：DCOM は TCP/135 と 動的 RPC ポートを用いる。サーバ側で dllhost.exe を許可、または動的ポート範囲を制限して許可ルールを定義。

ストレージと書き込み先の最適化

VB6/VC++6.0 時代のアプリは Program Files 配下や HKLM への書き込みを前提にしている場合があります。Server 2022 では UAC 仮想化や権限がより厳格化しており、次を推奨します。

アプリ設定／ログ：C:\ProgramData\<Vendor>\<App> やユーザープロファイル配下へ移動。
一時ファイル：%TEMP%／%ProgramData% を利用。
サービスアカウント：COM+ Identity（ドメインアカウント）に SeBatchLogonRight（バッチログオン）等の必要権限を付与。

GUI（VB6 EXE）運用のコツ

インストールエディション：Server 2022 は Desktop Experience をインストール時に選択。Server Core に後から GUI を追加することはできません。
DPI とフォント：RDP 接続の DPI 差でフォーム崩れが起きる場合は、アプリの DPI 認識を無効化（アプリケーションマニフェスト）して OS 側の DPI 仮想化に委ねると安定。
GDI オブジェクト枯渇：一覧画面や帳票プレビューが多い場合、GDI オブジェクト数の上限に注意。リークチェックを実施。

よくあるトラブルと対処

症状	原因	対処
「Class not registered」	32/64bit の `regsvr32` を誤使用、または依存 DLL 不足	正しい `regsvr32` を使用し、Dependency Walker で不足 DLL を特定して同梱
COM+ 起動失敗（イベント ID 10010/10016）	DCOM 権限不足、認証レベル不一致	dcomcnfg で AppID の起動/アクティブ化/アクセス許可を付与し、認証/偽装レベルを引き上げ
OCX ロード不可	未署名・古い ActiveX がブロック	コード署名（SHA-256）や代替コントロール化、信頼された配置ディレクトリでの運用
OLE DB プロバイダが見つからない	Jet 4.0（32bit）への依存	Access Database Engine の導入、または 64bit 対応のプロバイダへ移行
印刷/プレビューの乱れ	DPI 変更・プリンタドライバ差異	共通ドライバへ統一、固定解像度での出力、DPI 仮想化の利用

移行の実践手順（ゴールまでのチェックリスト）

準備（インベントリと凍結）

すべての COM DLL/OCX、実行 EXE、設定ファイル、レジストリ設定を列挙。
依存する フォント、プリンタドライバ、VC++ ランタイム、OLE DB/ODBC を洗い出し。
現行環境を スナップショット 取得（Hyper-V/VMware）。

ステージング構築

Windows Server 2022（Desktop Experience 版）をインストールし、最新更新を適用。
アプリと DLL/OCX を配置。regsvr32 で登録（32bit/64bit を厳密に）。
COM+ アプリをインポートし、Identity と ロールを設定。
DCOM の認証/偽装レベル、ファイアウォール許可を設定。

機能テストと負荷テスト

シナリオテスト：起動、帳票、トランザクション、並列実行、異常系（タイムアウト/障害復旧）。
長時間連続運転：GDI/ハンドルリーク、メモリ断片化、ログローテーションの検証。
セキュリティテスト：最小権限化（サービスアカウント、フォルダ ACL、共有 ACL）。

切替手順

新旧サーバで時刻同期とサービスアカウント権限を整備。
アプリ停止 → データ移行 → DNS/ロードバランサ切替。
監視：イベントログ（COM/COM+、アプリケーション）、リソース監視、失敗時のロールバック手順を準備。

自動化の雛形（配布・登録・検証）

登録スクリプト（例：32bit DLL 群の一括登録）

@echo off
setlocal
set SRC=%~dp0bin32
for %%F in ("%SRC%\*.dll") do (
  echo Registering %%~nxF
  "C:\Windows\SysWOW64\regsvr32.exe" /s "%%~fF" || echo ERROR: %%~nxF
)
echo Done.
endlocal

PowerShell で CLSID の存在確認

param([string]$CLSID)
$paths = @(
  "HKLM:\Software\Classes\CLSID\{$CLSID}",
  "HKLM:\Software\Classes\Wow6432Node\CLSID\{$CLSID}"
)
foreach ($p in $paths) {
  if (Test-Path $p) { Write-Output "Found: $p" } else { Write-Output "Not found: $p" }
}

セキュアに運用するための設計見直しポイント

コード署名の徹底：発行元ベースで AppLocker/WDAC を設定しやすくなる。署名アルゴリズムは SHA-256。
データ分離：実行ファイルとデータ/ログを別ドライブに分離。バックアップと復旧が容易。
監視：イベントログ（Applications and Services Logs > Microsoft > Windows > COM）とアプリケーションログを収集。
最小権限：COM+ の Identity は専用ドメインアカウント。必要な権限のみ付与。

VB6/VC++6.0 からの段階的モダナイズ戦略

「今すぐ全面刷新」は現実的でないことが多いため、COM の二重化（旧 COM の I/F を保ったまま内部実装を新言語に）でリスクを抑えます。

段階	施策	効果
短期	クリティカル DLL/OCX の依存解消（MFC/ADO/古い OLE DB）、ログ/設定の外だし、署名整備	安定性と運用性の底上げ
中期	.NET 8 / C++17 で COM サーバを新実装（互換 I/F）。既存クライアントは据え置き	段階移行でダウンタイム/開発負荷を分散
長期	COM 依存の撤廃、REST/GRPC 化、WinAppSDK やモダン UI への置換	保守性・セキュリティ・スケーラビリティの最大化

検証観点の具体リスト（抜け漏れ防止）

API 呼び出し：CoInitialize/CoUninitialize、スレッドモデル（STA/MTA）の整合性。
トランザクション：COM+ の Required/Requires New 設定と DB 側の分離レベル。
並列性：スレッドセーフでないコンポーネントの再入、クリティカルセクションのデッドロック。
例外/エラー：ISupportErrorInfo を通したエラー伝播、タイムアウト時の再試行。
ログ：操作ログ、障害ログ、監査ログの分離と容量制御。
バックアップ：COM+ カタログ（%SystemRoot%\Registration など）とアプリ/設定の取得。

サンプル：インストーラに依存しない「Reg-Free COM」化

可能なら Registration-Free COM（アプリケーションマニフェストで CLSID/TypeLibrary のバインディングを記述）を検討してください。インプレース配布で regsvr32 を回避でき、ローリングアップデートが容易になります。長年の運用で COM 競合 を繰り返してきた環境ほど効果が出ます。

移行判断の目安

即移行可：VB6 ランタイム依存のみ／独立した 32bit COM DLL／外部接続が限定的。
要計画：DCOM を越境して利用／古い ADO/OLE DB・ActiveX に強依存／IE 埋め込み UI。
再設計推奨：サービス化（非対話）前提なのに EXE をユーザセッションで常駐／署名なし OCX を多用。

最後に（まとめ）

Windows Server 2022 でも VB6 ランタイムと COM(+) は引き続き利用でき、VC++6.0 でビルドした COM DLL／VB6 EXE は基本的に動作します。要点は「32bit/64bit 登録の正確な使い分け」「DCOM セキュリティ設定の見直し」「依存 DLL の明確化」です。運用上の落とし穴は、認証レベルの不一致・権限不足・古い ActiveX に集中します。移行はステージングでの 全機能テストをベースに、コード署名・最小権限・ログ/設定の外だしを同時進行させると、2022 世代の OS セキュリティモデルに沿った堅牢な運用に着地できます。将来は COM I/F を残した置換戦略でモダナイズを進めるのが実務的です。

付録：チェックシート（コピーして使える）

区分	観点	状況
ランタイム	VB6 ランタイム（`msvbvm60.dll`）の有無	未/済
依存 DLL	`mfc42(u).dll`、`msvcp60.dll` の同梱	未/済
登録	32bit DLL を `SysWOW64\regsvr32.exe` で登録	未/済
COM+	Import 済／Identity 設定／ロール設定	未/済
DCOM	認証＝Packet Integrity 以上、偽装＝Impersonate 以上	未/済
権限	サービスアカウントに `SeBatchLogonRight` 等付与	未/済
GUI	Desktop Experience 版での描画・DPI テスト	未/済
署名	バイナリの SHA-256 署名	未/済
DB 接続	OLE DB/ODBC の 64bit/32bit 整合	未/済
監視	イベントログ収集（COM/アプリ）としきい値設定	未/済

FAQ

Q. VB6 EXE をサービスとして常駐させたい。
A. VB6 EXE は本来サービス化に非対応です。SrvAny/NSSM 等での疑似サービス化は可能ですが、対話 UI を前提とする場合は不安定になりやすく、権限やデスクトップセッションの制約で問題が出ます。COM+ Server Application でのホストや、実装のサービス化を検討してください。

Q. 2016 で動いていたのに 2022 でのみ失敗する。
A. まず DCOM の認証/偽装レベルを上げ、イベントログの DCOM/COM エラーを確認。加えて、依存 DLL と権限（フォルダ ACL/レジストリ ACL）を点検。多くはこの 3 点で解決します。

Q. VB6 の Common Controls（ListView 等）が崩れる。
A. comctl32.dll v6 を使うマニフェストが原因となるケースがあります。v5 を使う（マニフェスト調整）か、DPI 非対応として OS の仮想化に任せると改善することがあります。

Q. 64bit 化は必須？
A. 既存の VB6/VC++6.0 資産は 32bit で完結させるのが最短・低リスクです。将来的にモダナイズする際に 64bit ネイティブ化を検討するのが現実的です。

実務の要点（チェックポイント抜粋）

Server 2022 でも VB6 ランタイムは継続搭載、COM/COM+ は 廃止されていない。
登録は 32bit/64bit のパスを厳守。見え方も CLSID のツリーが分かれる。
DCOM セキュリティの既定強化に伴い、認証/偽装レベルと権限設定の見直しが必須。
依存 DLL と ActiveX は個別テスト。署名・配布・配置のルールを整備。
将来を見据え、COM I/F を保った置換で段階モダナイズを図る。

この記事を書いた人

佐藤健司

実務の現場で詰まりがちなポイントを地図にするITブログ「IT trip」を運営。Windows／Office（Teams・Excel）からSQL、サーバ運用、ガジェットまで、再現性のある手順と“なぜそうなるか”を丁寧に解説します。読んだらすぐ試せること、そして迷った人の次の一歩が見えることを大切にしています。