合同会社小村ソフト
相談する
メニュー

VB6アプリはいつまで動くのか ── ランタイムのサポート状況と現実的な.NET移行の進め方

· · VB6, .NET, C#, レガシー技術, 既存資産活用, 移行, モダナイゼーション, 32bit, Windows開発, 判断表, 技術相談

「このVB6のシステム、いつまで動くんですか」──既存システムの相談で、最も多い質問の一つです。

答えは意外と明確で、マイクロソフトが公式にサポートポリシーを出しています。ただしその内容は、「ランタイムは当分動く。しかし開発の後ろ盾はもうない」という非対称なものです。この非対称さを正しく理解しないと、「まだ動くから大丈夫」と「今すぐ全部作り直すべき」という両極端な結論に振れてしまいます。

当ブログでは「VB6 / Access業務アプリの延命と移行 ── 残す・包む・置き換えるの判断表」で、VB6資産をどう扱うかを決めるための判断を整理しました。この記事はその続きとして、「置き換える(移行する)」と決めた後、あるいは決めるために、VB6から.NETへの移行を実際にどう進めるかに踏み込みます。

1. まず結論

  • VB6のIDE(開発環境)は2008年4月8日にサポートが終了しています。VB6アプリを作成・保守するサポートされた手段はもう存在せず、マイクロソフトはモダンな技術への置き換えを強く推奨しています。1
  • 一方、VB6ランタイムは「同梱されるWindowsのサポート期間中」はサポート対象です。対象OSの一覧にはWindows 11、Windows 10、Windows Server 2025などが含まれており、既存アプリは「そのまま動く(It Just Works)」ことが目標とされています。2 つまり「いつまで動くのか」への答えは、実行だけならWindowsのサポートが続く限りです。
  • ただしそのサポート範囲は、既存アプリに対する深刻なリグレッションと重大なセキュリティ問題への対応に限定されています。また、ランタイムは32bit専用で、64bit Windows上ではWOW64環境でのみサポートされます。2
  • 本当のリスクは「動かなくなること」より、直せなくなることです。IDEの入手・維持が年々難しくなり、参照しているOCXのベンダーサポートが切れ、書ける人が退職していく。この3つは、Windowsのサポート期間とは無関係に進行します。
  • 移行の進め方は、全面リライト・自動変換・段階移行の3系統があります。最初に決めるのは方式ではなく棚卸しで、画面数・外部連携・OCX・API宣言の量を把握してから方式を選びます。
  • 移行先の言語は、新規に書く部分はC#を推奨します。VB.NET(Visual Basic)は安定路線が公式に明言されており、新しい構文・新しいワークロードへの拡張は行われません。3

2. 「いつまで動くのか」の正確な答え ── サポートポリシーの読み方

マイクロソフトのVB6サポートポリシーは、VB6を3つの構成要素に分けて説明しています。2

構成要素 内容 サポート状況
VB6 IDE 開発環境(Visual Studio 6.0) 2008年4月8日で終了
VB6ランタイム msvbvm60.dll などOSに同梱される実行基盤 同梱されるWindowsのサポート期間中はサポート
ランタイム拡張ファイル 主要なOCXコントロール類(アプリと共に再配布) 同上(アプリ側で配布が必要)

対象OSの表では、Windows 11・Windows 10、Windows Server 2012〜2025で「ランタイム: サポート」「IDE: サポート外」と明記されています。2

読み方のポイントは3つあります。

第一に、ランタイムのサポートはWindowsのライフサイクルに完全に従属します。「VB6ランタイムのサポート期限」という独立した日付は存在せず、使っているWindowsのサポート終了がそのまま期限です。

第二に、サポートの中身は「動き続けること」の保証に近いものです。対応されるのは深刻なリグレッション(OS更新で既存アプリが壊れた場合)と重大なセキュリティ問題だけで、個別の調査や機能改善は含まれません。2

第三に、VB6アプリは今後も32bitプロセスとしてしか生きられません。ランタイムは32bit専用で、64bit OSではWOW64エミュレーション環境でのみサポートされます。2 64bit専用のDLLやSDKと連携する必要が出た時点で、単一プロセスでは完結しなくなります。この壁の越え方は「32bitアプリから64bit DLLを呼ぶCOMブリッジ実例」で扱っています。

3. 「動く」と「維持できる」は別問題

サポートポリシーだけを見ると「急ぐ必要はない」ように読めます。しかし実務では、実行環境より先に開発と保守の環境が崩れていきます。

  • IDEが用意できない。VB6 IDEは現行OSでのサポート対象外で、正式な入手手段・インストール手段の維持が年々難しくなっています。「直せる環境が社内に1台しかない」状態は珍しくありません。
  • サードパーティOCXのベンダーサポートが切れている。サポートポリシーもサードパーティ製コントロールはベンダー側の責任範囲と明記しています。2 グリッドや帳票のOCXがすでに入手不能というケースは多く、この判断は「ActiveX / OCX を今どう扱うか」で整理した内容がそのまま適用できます。
  • 書ける人がいなくなる。言語仕様の問題ではなく人の問題です。新規にVB6を学ぶ技術者はほぼ供給されないため、保守できる人数は単調に減ります。
  • 周辺要件が32bitの壁に当たる。新しい機器SDK、認証ライブラリ、クラウド連携などが64bit前提・.NET前提になり、VB6プロセスに取り込めない要求が増えていきます。

つまり「いつまで動くか」は問題の半分でしかありません。もう半分は「次に修正が必要になったとき、直せる体制が残っているか」です。移行の計画は、障害が起きてからではなく、直せる人と環境が残っているうちに立てる必要があります。

4. 移行方式の判断表

「置き換える」と決めた場合でも、進め方には幅があります。主な方式を整理します。

方式 概要 向いているケース 主なリスク
全面リライト 仕様を整理し直し、.NETで新規に作る 画面数が少ない/業務フロー自体を見直したい/仕様が説明できる 隠れた業務ルールの漏れ、並行開発期間の長期化
自動変換ツール 変換ツールでVB6コードを.NETコードへ機械変換し、人が仕上げる コード量が多く、ロジックをそのまま保ちたい/画面構成を変えない 変換後コードの品質・可読性、結局残る手作業、ツール費用
段階移行(ストラングラー) 機能単位に切り出し、新旧を共存させながら順に置き換える 業務を止められない/画面・機能が多い/リスクを分散したい 新旧共存期間の複雑さ、境界(連携部)の設計力が要る
現状維持+文書化 移行せず、環境固定・バックアップ・文書化で延命 変更要求がほぼない/端末とOSを固定できる 前章のリスクが解消されない(先送り)

どれを選ぶかはコード行数だけでは決まりません。マイクロソフト自身も、移行にあたって公式ガイドとともにアップグレード・移行パートナー(移行ツールベンダーを含む)の利用を案内しており1、機械変換という選択肢は現実に存在します。ただし、どの方式でも共通して必要になるのが次章の棚卸しです。

なお「現状維持+文書化」を選ぶ場合の実務(実行環境の固定、バックアップ、リスクの引き受け方)は、前回のVB6 / Access記事で扱っています。

5. 移行前の棚卸し ── コードより先に調べること

見積もりと方式選定の精度は、棚卸しの精度で決まります。最低限、次を一覧化します。

  1. 画面と帳票の一覧 ── フォーム数、実際に使われている画面(使われていない画面の移行は無駄になります)、帳票の種類と出力先(プリンター直接印字か、Excel経由か)
  2. 外部連携の一覧 ── データベース(ADO/DAO/RDOのどれで、接続先は何か)、ファイル入出力、シリアル・ソケット通信、他システム呼び出し
  3. OCX / ActiveX / COM参照の一覧 ── プロジェクトファイル(.vbp)の参照から機械的に抽出できます。各コンポーネントの入手可否・代替有無が、方式選定に直結します
  4. Win32 API宣言(Declare文)の一覧 ── APIの用途(印刷、INI読み書き、ウィンドウ操作など)ごとに、.NET側の標準機能で置き換えられるかを分類します
  5. コードにしかない業務ルール ── 端数処理、日付の締め、取引先ごとの例外など。「なぜこう書かれているか誰も知らない」箇所こそ、移行後の不具合の温床です
  6. テスト手段の有無 ── 移行の正しさを何と比較して確認するか。多くの場合、旧システムの出力(帳票、CSV、DB内容)との突合が最も実用的な検証手段になります

この棚卸しは、全面リライトを選ばない場合でも無駄になりません。むしろ棚卸しの結果、「全面リライトだと思っていたが、実は core のロジックはDB側に寄せられる」「この10画面だけ先に移せば64bitの壁は越えられる」といった段階移行の切り口が見つかるのが普通です。

6. VB6と.NETの主な非互換ポイント

VB6とVB.NET/C#は、名前の印象より遠い言語です。機械変換でも人手リライトでも、次の差異は必ず設計判断が要ります。

領域 VB6 .NET 実務上の注意
エラー処理 On Error GoTo / Resume 構造化例外(Try...Catch) 単純置換不可。「エラーを握りつぶして続行」していた箇所の仕様確認が必要
型 Variant、Integerは16bit 静的型付け中心、Integerは32bit 暗黙変換に依存したコードの洗い出し。数値型のサイズ差は互換バグの定番
既定プロパティ Text1 = "abc" のような省略記法 廃止(明示が必要) 変換ツールの誤解釈ポイント。オブジェクト代入と値代入の区別が曖昧なコードに注意
データアクセス ADO / DAO / RDO ADO.NET以降 接続・トランザクション・カーソルの考え方が別物。データ層は「変換」ではなく「再設計」が前提
画面 VB6フォーム+OCX WinForms / WPF コントロールは1対1対応しない。グリッド等のOCXは代替選定が必要
印刷・描画 Printerオブジェクト、フォーム直接描画 GDI+ / 印刷API 帳票は移行工数が読みにくい領域。Excel帳票への寄せ替えも選択肢
起動・配布 EXE+ランタイム+OCX登録 自己完結型配布も可能 レジストリ登録(regsvr32)前提の運用から脱却できるのは移行のメリット

ここで重要なのは、非互換の多さに圧倒されて全面リライト一択と考えないことです。逆に、この表の左側(VB6)の資産が今も正しく動いているという事実自体が、移行時の最良の仕様書になります。旧システムを「動く仕様書」として並行稼働させ、出力を突合しながら進めるのが、実務的には最も確実です。

7. 段階移行の実務パターン

業務を止めずに移行する場合、新旧の共存構成が要になります。代表的なパターンを3つ挙げます。

7.1 データ層を先に移す

VB6アプリのデータをAccessファイルや独自形式からSQL Serverなどへ先に移し、VB6側は接続先だけ切り替えて動かし続ける構成です。データが先に近代化されていれば、新画面(.NET側)は同じDBを見て段階的に増やせます。Access絡みの具体的な手順は前回記事のアップサイズの章を参照してください。

7.2 新機能・新画面を.NETで作り、COM相互運用でつなぐ

既存のVB6画面はそのままに、新しい機能を.NETで作って共存させる構成です。方向は2つあります。

  • .NET側の部品をVB6から呼ぶ: .NETのクラスをCOMとして公開すれば、VB6からは普通のCOMコンポーネントとして参照できます。.NET 8以降でも型付きで公開する方法を「.NET 8のDLLをVBAから型付きで呼ぶ ── dscomとTLB」で解説しており、呼び出し側がVB6でも考え方は同じです。
  • VB6側の資産を.NETから呼ぶ: VB6で作られたActiveX DLLは、.NETからCOM相互運用で参照できます。ロジックを塊のまま生かし、画面だけ先に.NET化する場合に使います。ただし32bitの制約は残るため、恒久策ではなく移行期間中の橋と割り切ります。

7.3 プロセスを分けて連携する

COM相互運用で同一プロセスに同居させると、ビット数(32bit/64bit)と障害の巻き込みが制約になります。64bitの新機能が必要な場合や、新旧の障害を分離したい場合は、別プロセスに分けてファイル・名前付きパイプ・localhost通信などで連携します。プロセス間連携の選択肢は「WindowsのIPC判断表」に、32bit→64bitブリッジの実例は「COMブリッジ実例」にまとめています。

どのパターンでも共通する原則は、「新旧の境界を1か所に集約し、境界を跨ぐデータの形式を固定する」ことです。境界が画面ごと・機能ごとにバラバラに増えると、共存期間のコストが移行の効果を食い潰します。

8. 移行先の言語 ── C#かVB.NETか

「VB6からならVB.NETが自然」と思われがちですが、現在のマイクロソフトの言語戦略を踏まえると単純ではありません。

公式の言語戦略では、Visual Basic(VB.NET)は「安定した設計を保つ、分かりやすく親しみやすい言語」と位置づけられ、新機能は原則として消費(consumption-only)のみで新しい構文は追加しない、新しいワークロードへの拡張は行わない方針が明示されています。一方で、Windows Formsやライブラリといった中核シナリオへの投資と、Visual Studio上の開発体験の改善は継続するとされています。3

これを移行の観点で読むと、次のようになります。

  • VB.NETを選んでも、既存シナリオ(WinFormsの業務アプリ)は当面問題なく成立します。VB6経験者が多く、文法の近さが学習コストを下げるチームでは合理的な選択です。
  • ただし、これから新規に書く資産の土台としてはC#を推奨します。言語とエコシステムの進化が続いており、サンプル・ライブラリ・人材の供給もC#に集中しています。「VB6の保守要員がいない」問題を、10年後に「VB.NETの保守要員がいない」問題として繰り返さないための選択です。
  • 折衷案として、変換ツールの出力はVB.NETで受け、新規開発はC#で書く構成も取れます。.NETでは両言語のアセンブリは相互に参照できるため、言語を混在させること自体は障害になりません。

画面フレームワークの選択(WinForms / WPF / WinUI)は「WinForms・WPF・WinUIの判断表」を、.NET Frameworkではなく現行.NETへ直接移行する際の確認事項は「.NET Framework→.NET移行前チェックリスト」を参照してください。VB6からの移行でわざわざ.NET Framework 4.8を新規採用する理由は、参照ライブラリの制約がない限りありません。

9. まとめ

  • 「VB6はいつまで動くのか」への答えは、ランタイムはWindowsのサポート期間中は動作対象(Windows 11も対象)です。ただしIDEは2008年にサポート終了しており、作り直す・直す手段の公式な後ろ盾はすでにない、という非対称な状態です。21
  • 本当の期限はOSではなく、直せる環境と人が残っているかで決まります。移行計画は障害発生後ではなく、旧システムが「動く仕様書」として使えるうちに立てます。
  • 進め方は全面リライト・自動変換・段階移行の3系統。方式選定の前に、画面・外部連携・OCX・API宣言・コードにしかない業務ルールの棚卸しを行います。
  • 業務を止めない移行では、データ層先行・COM相互運用・プロセス分離のいずれかで新旧を共存させ、境界を1か所に集約します。
  • 新規に書く部分の言語はC#を推奨します。VB.NETは安定路線が公式方針であり3、長期保守の土台としてはC#の方が有利です。

関連記事

関連する相談領域

合同会社小村ソフトでは、VB6を含む既存資産の棚卸しと移行方針の整理、COMブリッジ・プロセス分離による新旧共存構成の設計・実装、.NETへの段階的なリプレイスを扱っています。

参考リンク

  1. Microsoft Learn, Visual Basic 6.0 Support Announcement. VB6 IDE / Visual Studio 6.0 IDEが2008年4月8日でサポート終了したこと、VB6アプリを作成・保守するサポートされた手段が存在しないためモダンな技術への置き換えを強く推奨していること、移行にあたりアップグレードガイドと移行パートナーが案内されていることについて。 ↩ ↩2 ↩3

  2. Microsoft Learn, Support Statement for Visual Basic 6.0 on Windows. VB6ランタイムは同梱されるWindowsバージョンのサポート期間中はサポート対象であること、Windows 11・Windows 10・Windows Server 2025等が対象OSに含まれること、サポート範囲は深刻なリグレッションと重大なセキュリティ問題に限られること、ランタイムは32bit専用で64bit OSではWOW環境でのみサポートされること、サードパーティ製コントロールはベンダーの責任範囲であることについて。 ↩ ↩2 ↩3 ↩4 ↩5 ↩6 ↩7 ↩8

  3. Microsoft Learn, Annotated Visual Basic language strategy および Microsoft .NET language strategy. Visual Basicは安定した設計を保ち、新機能は消費(consumption-only)中心で新しい構文の追加を避けること、新しいワークロードへは拡張しないこと、Windows Formsやライブラリなど中核シナリオとVisual Studio体験への投資は継続することについて。 ↩ ↩2 ↩3

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

業務アプリの和暦・祝日・締め日処理 ── 改元に強い設計とJapaneseCalendar・営業日計算の実務

帳票の「令和8年」表示、祝日を除いた営業日計算、20日締め翌月末払い──日本の業務アプリ特有の日付処理は、改元・祝日の法改正・月末の丸めという「あとから変わる仕様」を抱えています。JapaneseCalendarによる和暦表示と改元に強い設計、祝日をハードコードしてはいけな...

記事を読む

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

VB6アプリはWindows 11でも動きますか？
動作対象です。マイクロソフトのサポートポリシーでは、VB6ランタイム(msvbvm60.dllなど)は同梱されるWindowsバージョンのサポート期間中はサポート対象とされており、対象OSの一覧にはWindows 11・Windows 10やWindows Server 2025などが含まれています。ただしサポートの範囲は、既存アプリに対する深刻なリグレッションと重大なセキュリティ問題への対応に限られます。またVB6ランタイムは32bit専用で、64bit Windows上ではWOW64という32bit互換環境の中でのみサポートされます。
VB6から.NETへの移行は自動変換ツールだけで完了できますか？
完了できないと考えるべきです。変換ツールは画面定義や単純なロジックの書き換えを省力化できますが、On Errorによるエラー処理、Variant型や既定プロパティに依存したコード、ActiveXコントロール、Win32 API宣言などは人手での設計判断と修正が必要です。ツールの出力をそのまま本番に使うのではなく、「変換後に人が仕上げる工数」を含めて全体を見積もり、変換結果の検証方法(並行稼働や出力比較)を先に決めておくことが重要です。
移行先はVB.NETとC#のどちらを選ぶべきですか？
新規に書く部分はC#を推奨します。マイクロソフトの言語戦略では、Visual Basic(VB.NET)は安定した設計を保つ言語と位置づけられ、新しい構文の追加や新しいワークロードへの拡張は行わない方針が明示されています。既存シナリオ(Windows Formsなど)への投資は続くためVB.NETが使えなくなるわけではありませんが、これから10年保守するコードの土台としては、言語・エコシステムともに進化が続くC#の方が人材確保の面でも有利です。VB6経験者が多いチームでは、文法が近いVB.NETを経由する判断もあり得ます。
全面リライトの前に、まず何をすべきですか？
コードを書き始める前に棚卸しをすべきです。具体的には、画面・帳票の一覧、外部連携(DB、ファイル、シリアル通信、他システム)の一覧、参照しているOCX/ActiveXコントロールとCOMコンポーネントの一覧、Win32 API宣言(Declare文)の一覧、そして「仕様書はコードしかない」業務ルールの洗い出しです。この棚卸しの結果によって、全面リライトではなく、一部だけを切り出す段階移行や、データ層を先に移す構成の方が現実的だと分かることが多くあります。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。

お問い合わせ
ブログ一覧に戻る