VB6 からの移行ガイド — .NET化・Web化の判断基準

VB6（Visual Basic 6.0）で作られた業務システムは、いまも多くの企業の現場で動いています。受発注、在庫管理、生産管理、営業支援。20年以上前に作られたものが、日々の業務をいまだに支えているケースは珍しくありません。

そして、どの現場でもほぼ同じ悩みが聞こえてきます。作った人がもういない。改修できる技術者が採用できない。仕様書は残っているが現状と合っていない。それでも業務は止められない。

本記事では、VB6システムの移行先の選択肢と、それぞれが向くケースを率直に整理します。

「サポート終了」を正しく理解する

VB6の話をするとき、まず切り分けておきたいのが開発環境と実行環境です。ここを混同すると、判断を誤ります。

• 開発環境（VB6 IDE） — 2008年4月に延長サポートが終了しています。最新のWindowsで動かすこと自体に手間がかかり、新しく手に入れることもできません。
• 実行環境（VB6ランタイム） — MicrosoftはVB6ランタイムをWindowsに同梱し、OSのサポート期間中は動作を維持する方針を示してきました。つまり、既存のVB6アプリは今も動きます。

だからこそ厄介なのです。「動いている」ため、移行の議論は先送りされます。しかし実際に失われつつあるのは、そのシステムを直せる能力のほうです。動くけれど直せないシステムは、事業のリスクとして静かに積み上がっていきます。

VB6の移行が難しい理由

VB6の移行が単純な言語変換にならないのは、言語そのものより、その作り方に理由があります。

• フォームとロジックの密結合。 VB6は画面（フォーム）のイベントプロシージャに業務ロジックを直接書けます。長く使われたシステムほど、価格計算や在庫引当のルールが cmdSave_Click の中に埋まっています。業務ロジックが層として分離されていないため、画面だけを作り直すという分割ができません。
• ActiveX / OCX・COM依存。 サードパーティ製のグリッドやカレンダーのOCX、社内で作られたCOMコンポーネント。ベンダーが消滅して入手できないもの、ソースが失われたものが、必ずと言っていいほど混ざっています。ここは自動変換でも個別の判断が必要になる部分です。
• 暗黙の型変換とエラー処理。 Variant型、暗黙の型変換、On Error Resume Next。厳密な型を持つモダンな言語へ移すと、これまで表面化していなかった挙動が顕在化します。移行時に「元と同じ動き」を定義する作業が必要になります。
• 32ビット前提。 VB6アプリは32ビットです。64ビットのコンポーネントやドライバとの連携が必要になった時点で、回避策の積み重ねが始まります。

移行の選択肢

選択肢	概要	期間	リスク	向くケース
継続保守	VB6のまま使い続ける	（つなぎ）	年々上昇	短期のつなぎとしてのみ
VB.NETへアップグレード	.NET上のデスクトップアプリへ移す	中	中	.NET資産を持ち、当面デスクトップで良い
リライト（再構築）	モダンな技術で一から作り直す	長	大	規模が小さい、または業務を見直す
自動変換	ソースを解析しモダン技術へ機械変換	中	小〜中	残したい大規模システムを標準技術へ

継続保守

計画的なつなぎとしてのみ妥当です。VB6が動く限り選び続けられてしまうのが、この選択肢の危険なところです。買った時間は、移行を避けるためではなく、移行を準備するために使うものです。

VB.NETへのアップグレード

「VBからVBなら簡単だろう」と思われがちですが、VB.NETはVB6とは別の言語です。オブジェクトモデルも画面フレームワーク（Windows Forms）も異なり、かつてVisual Studioに同梱されていたアップグレードウィザードも、変換後に相当量の手作業を残すのが実情でした。

それでも意味があるのは、社内に.NETの開発体制があり、当面はデスクトップアプリのままで良いと明確に決まっている場合です。逆に、最終的にWebへ移すつもりなら、VB.NETは一度余分な移行を挟むことになります。VB.NETを経由するかどうかは、「最終的にどこへ行きたいか」を決めてから判断すべきです。

リライト（再構築）

要件から作り直せば、望みどおりのシステムが手に入ります。一方で、選択肢の中では最もリスクが高く、期間も長くなります。VB6システムの再構築で期間が膨らむ典型的な原因は、コーディングではなく仕様復元です。フォームのイベントに散らばった業務ルールを人手で読み解く工程は、見積もりに載りにくく、実際には最も時間を食います。

画面数が限られる小規模システムや、業務プロセスそのものを作り替えたい場合には、これが正解です。

自動変換

自動変換は、VB6の実ソース（フォーム、イベントプロシージャ、モジュール、埋め込みSQL）を解析し、モダンな等価物を生成します。当社の場合は、標準的な TypeScript / React などのクリーンなコードです。ツールが人手を介さず完璧なコードを書くという話ではなく、OCX依存やエラー処理の方針決めは必ず残ります。

要点は、業務ロジックを記憶からの再構成ではなく、実際のコードから引き継げることです。残して動かし続けたい大規模なVB6システムにとって、採用可能な技術スタックへ移る、最もリスクの低い道になることが多い手法です。

「.NETか、Webか」の判断

VB6の移行先を議論すると、しばしば「まずVB.NETに上げて、いずれWebに」という案が出ます。段階的で穏当に見えますが、多くの場合、移行を二回行うことになります。

判断はシンプルにできます。

• 10年後もデスクトップアプリで良いか。 良いなら.NETへのアップグレードは合理的です。良くないなら、Webを前提に一度で移すほうが総コストは下がります。
• 利用者はどこにいるか。 拠点や取引先、外出先から使う要件があるなら、配布とバージョン管理の課題は残り続けます。
• 人材はどちらで採れるか。 これは技術論ではなく、経営判断です。

自動変換が向くケース・向かないケース

公平を期すために、自動変換が万能でないことも明確にしておきます。

向くケース

• フォームやモジュールに未文書の業務ロジックが厚く、資産として保全したい
• 数十万行〜数百万行規模で、人手の再構築では期間が読めない
• 業務を止められず、サブシステム単位で段階的に移行したい

向かないケース

• 画面数が少なく小規模（→ 再構築やパッケージの方が速い）
• どのみち業務を抜本的に見直す（→ 再構築で業務改革とセットに）
• OCXやCOMへの依存が大半を占め、業務ロジックがほとんど自社コードにない

まず現状を把握する

VB6システムの移行で最初につまずくのは、手法の選択ではなく、自社のコードの現状が分からないことです。総行数、画面数、OCX依存の一覧、デッドコードの割合、モジュール間の依存関係。これらが分からないまま見積もりを取っても、比較になりません。

そのため実務では、コード分析で全体像を可視化し、移行方式を判断する材料を作ってから方式を決める順序を取ります。VB6の全量解析から移行計画の策定までを2ヵ月で完了した事例を含め、実績は導入事例で紹介しています。

自社のVB6システムがモダンなコードとしてどう見えるかを確かめたい場合は、実際のコードの代表的な一部を対象に、範囲を固定したPoC（概念実証）から始めるのが定番です。無料コード診断では、現行コードの規模と構造を把握するところからご相談を承っています。

モダナイゼーション手法の全体像はアプリケーションモダナイゼーションの主要アプローチ5選で、再構築と自動変換の比較は再構築か、自動変換かで解説しています。同じデスクトップ系レガシーの移行としては、PowerBuilder からの移行ガイドも参考になります。