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

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

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

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

この記事で使う用語

VB6世代を直接は知らない読者もいるはずなので、先に用語を整理しておきます。

1. まず結論

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

この記事の知識マップ

VB6アプリの実行基盤であるVB6ランタイムはWindowsのサポート期間中は動作対象である一方、開発環境のVB6 IDEは2008年に終了しており、直せる体制が失われることこそが本当のリスクになります。VB6ランタイムは32bit専用でWOW64環境でのみ動作するため、64bit前提の.NETコンポーネントとは同一プロセス内で単純には両立しません。移行は全面リライト・自動変換ツール・段階移行(ストラングラーパターン)の3方式に整理され、どの方式でも.vbpファイルからのOCX・COM参照の棚卸しと、COM相互運用によるVB6と.NETの共存が土台になります。移行後に新規で書く言語はC#が推奨され、VB.NETは既存シナリオの維持に向く安定路線と位置づけられます。

flowchart LR
    accTitle: VB6から.NETへの移行の知識マップ
    accDescr: VB6のIDEとランタイムのサポート状況の違い、WOW64による32bit制約、全面リライト・自動変換・段階移行(ストラングラーパターン)という移行方式の選択肢、COM相互運用による新旧共存、移行後の言語としてC#とVB.NETのどちらを選ぶかの関係を示す図
    vb6["Visual Basic 6.0(VB6)"]
    dotnet[".NET(Core以降)"]
    vb6_runtime["VB6ランタイム"]
    vb6_ide["VB6 IDE(Visual Studio 6.0)"]
    wow64["WOW64"]
    ocx["OCX"]
    activex["ActiveX"]
    vb6_conversion_tool["VB6自動変換ツール"]
    vb_net["Visual Basic .NET(VB.NET)"]
    strangler_fig_pattern["ストラングラーパターン(Strangler Fig)"]
    com_interop["COM(Component Object Model)"]
    bitness_match_requirement["bitness一致要件"]
    regsvr32["regsvr32"]
    com["COM(コンポーネントオブジェクトモデル)"]
    csharp["C#"]
    vbp_file[".vbpファイル(VB6プロジェクトファイル)"]
    windows_forms["Windows Forms"]
    dotnet_framework[".NET Framework"]
    vb6 -->|"前提とする"| vb6_runtime
    vb6 -.->|"前提とする"| vb6_ide
    vb6_runtime -.->|"前提とする"| wow64
    vb6 -.->|"両立しない"| dotnet
    dotnet -->|"の後継"| vb6
    vb6 -.->|"利用する"| ocx
    ocx -->|"実装を担う"| activex
    vb6_conversion_tool -->|"利用する"| vb6
    vb6_conversion_tool -->|"利用する"| vb_net
    strangler_fig_pattern -.->|"推奨される対応"| vb6
    com_interop -->|"前提とする"| bitness_match_requirement
    com_interop -.->|"で構成できる"| regsvr32
    com_interop -->|"前提とする"| com
    csharp -->|"前提とする"| dotnet
    vb_net -->|"前提とする"| dotnet
    csharp -->|"推奨される対応"| vb6
    vb_net -.->|"推奨される対応"| vb6
    vb6 -->|"で確認できる"| vbp_file
    vb6 -.->|"利用する"| regsvr32
    vb6 -.->|"利用する"| com_interop
    windows_forms -.->|"の後継"| vb6
    dotnet -->|"の後継"| dotnet_framework

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全22件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

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

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

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

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

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

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

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

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

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

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

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

4. 移行方式の判断表

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

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

4.1 「変換ツール」とは具体的に何か

「自動変換ツール」と一括りに書きましたが、マイクロソフトはVB6のパートナー製品を実名で案内するページを公開しています。「Visual Basic 6.0からVisual Basic .NETへのより完全な移行を支援する、パートナーによる無償・有償のツールとソリューション」という位置付けで、次の3つが挙げられています。⁶

上記はマイクロソフトのページに載っている説明の要約であり、当社が推奨・保証するものではありません。選定は必ず自社のコードで試してから行ってください。見るべき観点は次のとおりです。

最後の「反復できるか」は見落とされやすい観点です。移行期間中もVB6側には障害対応が入ります。一度きりの変換しかできないツールだと、その修正を新旧の両方に手で入れ続けることになります。

なお「現状維持+文書化」を選ぶ場合の実務(実行環境の固定、バックアップ、リスクの引き受け方)は、前回の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の壁は越えられる」といった段階移行の切り口が見つかるのが普通です。

5.1 「機械的に抽出できます」の中身 ── .vbp から参照部品を洗い出す

3番目の項目に「.vbpの参照から機械的に抽出できます」と書きました。その方法を具体的に示します。

プロジェクトファイル(.vbp)はASCIIのテキストファイルです。マイクロソフトの公式ドキュメントにも中身の例が載っており、参照設定は次の形の1行として記録されます。⁷

Type=Exe
Form=B_Form.frm
Reference=*\G{00020430-0000-0000-C000-000000000046}#2.0#0#..\..\..\WINDOWS\SYSTEM\STDOLE2.TLB#OLE Automation
Form=A_Form.frm
Module=CModule; C_Module.bas
Class=DClass; D_Class.cls
Startup="BForm"
Name="Project1"

Reference= の値は # 区切りで、GUID(タイプライブラリのID)→ バージョン → ロケール → ファイルパス → 説明(ライブラリ名) の順に並びます。上の例では OLE Automation が説明にあたります。画面に貼り付けたActiveXコントロール(OCX)は Object= の行として記録されるので、この2種類の行を集めれば「このプロジェクトが依存している外部部品の一覧」になります。

プロジェクトが数十個あるシステムでは、次のようなスクリプトで一括して吸い出します。

# フォルダー配下の全 .vbp から、参照している部品の行を抜き出してCSVにする
# 動作環境: Windows PowerShell 5.1
Get-ChildItem -Path . -Filter *.vbp -Recurse | ForEach-Object {
    $project = $_.FullName
    Get-Content -LiteralPath $project | Where-Object {
        $_ -like 'Reference=*' -or $_ -like 'Object=*'
    } | ForEach-Object {
        $kind, $value = $_ -split '=', 2
        [pscustomobject]@{
            Project = $project
            # Reference = 参照設定したタイプライブラリ / Object = 画面に貼ったActiveXコントロール
            Kind    = $kind
            Entry   = $value
        }
    }
} | Sort-Object Kind, Entry | Export-Csv .\vb6-components.csv -NoTypeInformation -Encoding UTF8

出てきたCSVを重複排除して並べれば、「このシステムは結局どのCOM部品に依存しているか」が半日で一覧になります。あとは1件ずつ、入手可能か・ベンダーサポートがあるか・.NET側の代替があるかを埋めていくだけです。この表がそのまま、第4章の方式選定と見積もりの土台になります。

同じ発想で、Declare 文の一覧も .bas / .frm / .cls を横断して Declare を含む行を拾えば作れます。棚卸しで手作業に頼るべきなのは「コードにしかない業務ルール」だけで、それ以外はほぼ機械化できます。

5.2 工数と期間の見積もり方

「画面1枚あたり何日」という数字は、画面の複雑さ、OCXの有無、業務ロジックの密度、求められるテストの厳しさで簡単に一桁変わります。他社の事例値をそのまま持ち込んでも当たりません。代わりに、自社の数値を作る手順を置きます。

1. 数える。棚卸しで、画面数・帳票数・外部連携数・OCXの種類数・Declare 文の数・テーブル数を確定させます。
2. 難易度で仕分ける。画面を3段階程度に分けます(単純な一覧・参照画面/入力と検証がある画面/グリッドや帳票プレビューを含む画面)。
3. 各段階から1枚ずつ、実際に移行してみる(パイロット)。設計・実装・単体テスト・旧システムとの出力突合までを含めた実時間を計測します。ここが見積もりの単価になります。
4. 掛けて積む。3で得た単価を、2の枚数に掛けて積み上げます。
5. 別枠を足す。共通部分(認証、ログ、印刷基盤、配布、環境構築)と、「コードにしかない業務ルール」の解読時間は画面数に比例しません。この別枠が抜けている見積もりは必ず不足します。
6. 合わなければ方式に戻る。パイロットの実測が想定より大きく悪ければ、それは見積もりの誤差ではなく方式選定の誤りのサインです。第4章に戻って、全面リライト・自動変換・段階移行を選び直します。

要点は、見積もりの根拠を他社の事例値ではなく自社のパイロット実測に置くことです。パイロットは費用ではなく、見積もり精度を買う投資だと考えてください。

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

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

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

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

業務を止めずに移行する場合、新旧の共存構成が要になります。代表的なパターンを3つ挙げます。違いは一言でいえば「新旧の境界をどこに置くか」です。

flowchart TB
    subgraph P1["7.1 データ層を先に移す ── 境界はデータベース"]
      A1["VB6アプリ ── 接続先だけ切り替える"] --> DB["移行後のデータベース ── SQL Server など"]
      A2[".NET の新画面 ── 順に増やしていく"] --> DB
    end
    subgraph P2["7.2 COM相互運用でつなぐ ── 境界はCOMインターフェイス、同一プロセス"]
      B1["VB6アプリ ── 32bitプロセス"] --- B2["COMインターフェイス"]
      B2 --- B3[".NET の部品 ── 32bitでビルドする必要がある"]
    end
    subgraph P3["7.3 プロセスを分ける ── 境界はIPC、別プロセス"]
      C1["VB6アプリ ── 32bitプロセス"] --- C2["名前付きパイプ / ファイル / localhost通信"]
      C2 --- C3[".NET アプリ ── 64bitでもよい"]
    end

図1: 段階移行の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から型付きで使う方法 - COM公開とdscom TLB」で解説しており、呼び出し側がVB6でも考え方は同じです。
• VB6側の資産を.NETから呼ぶ: VB6で作られたActiveX DLLは、.NETからCOM相互運用で参照できます。ロジックを塊のまま生かし、画面だけ先に.NET化する場合に使います。ただし32bitの制約は残るため、恒久策ではなく移行期間中の橋と割り切ります。

橋渡しの実装は、最小構成なら数行です。まず.NET側の部品をVB6から呼ぶ方向。公開したいインターフェイスとクラスに属性を付けます。⁸

// .NET側(C# / .NET 8)── VB6から呼べるようにCOM公開する
using System.Runtime.InteropServices;

[ComVisible(true)]
[Guid("fe103d6e-e71b-414c-80bf-982f18f6c1c7")]   // インターフェイスのIID。必ず自分で新規生成する
[InterfaceType(ComInterfaceType.InterfaceIsIDispatch)]
public interface ITaxCalculator
{
    decimal CalcTax(decimal amount);
}

[ComVisible(true)]
[Guid("9f35b6f5-2c05-4e7f-93aa-ee087f6e7ab6")]   // クラスのCLSID。これも新規生成する
[ClassInterface(ClassInterfaceType.None)]
[ProgId("Komura.TaxCalculator")]
public class TaxCalculator : ITaxCalculator
{
    public decimal CalcTax(decimal amount) => Math.Floor(amount * 0.1m);
}

csprojにCOMホストの生成を指示してビルドし、生成された .comhost.dll を管理者権限のコマンドプロンプトから登録します。⁸

<PropertyGroup>
  <EnableComHosting>true</EnableComHosting>
</PropertyGroup>

regsvr32 TaxLib.comhost.dll

呼ぶ側のVB6は、いつものCOMオブジェクトと同じです。

' VB6側 ── ProgIdを使った遅延バインド呼び出し
Dim calc As Object
Set calc = CreateObject("Komura.TaxCalculator")
MsgBox calc.CalcTax(12345)
Set calc = Nothing

ここで必ずつまずく落とし穴が2つあります。どちらも公式ドキュメントに書かれています。⁸

• 既定では64bitクライアントからしか使えません。.NET Framework時代と違い、.NET Core / .NET 5以降では「Any CPU」でビルドしても、付随する *.comhost.dll は既定で64bitになります。VB6は32bitプロセスなので、このままでは読み込めません(WOW64の制約そのものです¹)。32bit版の comhost.dll が出るようにビルド構成を合わせてください。
• 自己完結型(self-contained)配布のCOMコンポーネントはサポートされません。フレームワーク依存の配布だけがサポート対象です。配布方式を先に決めてから設計してください。

もう一つ、VB6の資産を.NETから呼ぶ方向は、VB6製ActiveX DLLをCOM参照として追加するだけです。

// .NET側 ── VB6製ActiveX DLLをCOM参照して呼ぶ
// 事前準備: プロジェクトに「COM参照」を追加し、32bit(x86)ビルドにしておく
var legacy = new LegacyBiz.OrderCalc();      // VB6で書かれたクラス
decimal total = legacy.CalcTotal(orderId);   // 業務ロジックはVB6側のまま
Marshal.ReleaseComObject(legacy);            // COMオブジェクトは明示的に解放する

こちらも呼び出す.NET側を32bit(x86)でビルドする必要があります。VB6のActiveX DLLは32bitのDLLであり、64bitプロセスは32bit DLLを実行のために読み込めないためです。¹ 「64bitの新機能を入れたいのにVB6のロジックも呼びたい」という要求は、この時点で同一プロセスでは成立しません。次の7.3の出番になります。

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上の開発体験の改善は継続するとされています。⁵

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

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

9.1 次の一歩 ── 最初の1週間でやること

「移行を検討する」で止まらないための、着手できる粒度のチェックリストです。コードは1行も書きません。

• ソースコード一式の所在を確認する。最新の本番実行ファイルと突き合わせて、そのソースが本当に現行版かを確かめる(第3章のとおり、ここが食い違っていると以降が全部無駄になります)
• VB6 IDEが動く端末を確認する。何台あるか、そのOSは何か、壊れたら再構築できるか
• .vbp から参照部品を一覧化する。第5章のスクリプトをそのまま流し、CSVにする
• 一覧の各部品に「入手可否/ベンダーサポート/.NET側の代替」の3列を足して埋める。埋まらないセルが、移行の難所です
• 画面と帳票を数える。そのうえで現場に「実際に使っている画面」を確認する。使われていない画面を移行しないだけで工数は大きく変わります
• Declare 文を横断で抽出する。用途別に分類し、.NETの標準機能で置き換えられるかを仕分ける
• 検証の当てを決める。移行後の正しさを何と比べて確認するか(帳票、CSV、DBの内容)を1つ決めておく
• 32bitで困っている要件があるかを確認する。あるなら、その1点が方式選定の最優先条件になります

ここまでで、第4章の方式選定と、第5章のパイロットに進むための材料は揃います。

関連記事

• VB6 / Access業務アプリの延命と移行 - 残す・包む・置き換えるの判断表
• ActiveX / OCX を今どう扱うか - 残す・包む・置き換える判断表
• 32bitアプリから64bit DLLを呼ぶCOMブリッジ実例
• .NET 8 DLLをVBAから型付きで使う方法 - COM公開とdscom TLB
• .NET Framework→.NET移行前チェックリスト
• WinForms・WPF・WinUIの判断表
• VBA とは何か - 制約、将来性、置き換えるべき場面と現実的な移行パターン

関連する相談領域

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

• 既存資産活用・移行支援
• 既存Windowsソフトの改修・保守
• Windowsアプリ開発
• 技術相談・設計レビュー
• お問い合わせ

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

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

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