VB6.0は早めにVB.NETに移行しよう！サポート期限切れを放置するリスクや具体的な対処法

「VBマイグレーション」と呼ばれる、旧世代のVBで作成された業務アプリケーションをVB.NETやweb（ASP.NET）あるいはJavaといった現役の環境に移行するソリューションは、VB6.0がサポート終了して15年以上たった今でも、多くの企業が悩まされている事例です。

現在でもVB5.0やVB6.0といった環境で作成されたビジネス用アプリケーションを利用しつつ、法対応した仕様の追加や機能改善を行っている企業があります。

トラブル防止や業務改善の観点からも、できるだけ早く、後継となるVB.NETをはじめとした他の環境への移行を検討することをおすすめします。この記事では、VB6を使い続けることのリスクや移行の際の課題についてまとめ、スムーズな移行について考えます。

できるだけ早く、後継となるVB.NETをはじめとした他の環境への移行を検討したほうがよさそうです。この記事では、VB6を使い続けることのリスクや移行の際の課題についてまとめ、スムーズな移行について考えます。

VB6.0の現状

VB（Visual Basic）は、Microsoftが開発し、提供しているプログラミング言語です。最初のバージョンであるVBが発表されたのは1991年で、VB6.0は1998年に登場しています。

VB6.0はVB1.0から続く「初心者向け」という特徴をもちながら、企業独自のWindowsアプリケーションの開発において、ActiveXに完全対応し、SQL ServerやOracle DBといったRDB（リレーションデータべース）を制御できるため、ビジネスの現場で広く使われてきました。現在でも、VB6.0で開発されたシステムは、特に工場内や支店などの部門システムを中心に多く残っています。

VB6.0はWindows11でも動作するのか？

VB6で開発されたアプリケーションは、Windows11でも動作します。2025年10月にWindows10の延長サポートが終了した際、PCの入れ替え（主にWindows10クライアント端末の撤廃）を行う過程で、「Windows11環境でVB6アプリケーションを動作させる」ことで暫定対応した結果、VB6からの脱却を、いったんは後回しにしたケースも少なくないようです。

ただし、Windows11でVB6を動作させるためには、OSに標準では入っていないランタイムライブラリをインストールする必要があります。

これはあくまでも実行環境（クライアントアプリケーションを利用する側の環境）の話であり、VB6アプリそのものの改修や機能追加といった開発側の話とは異なります。Windows11環境下においてVB6の「開発環境」を構築することは非公式には可能ですがサポート外であることもあり、ここでは割愛します。

VB6の開発環境のサポートは終了している

VB6とその統合開発環境（IDE）のサポートは、はるか以前の2008年に終了しました。VB6のIDEをインストールできるOSは公式にはWindows Vistaまでですが、そのWindows Vista自身も2017年にサポートが終了しています。

また、OSやVB6開発環境本体のサポートが切れているだけでなく、サードパーティ製のVB6に関する開発支援ツールもほとんどがサポート期限切れとなっています。

しかし、すでにサポートが切れている開発環境で開発されたアプリケーションが、まだまだ多くの企業で動作しているのが現状です。一切の機能追加・改修など、アプリに手を加えずに実行するだけであればまだよいですが、機能改修や追加にはさらにリスクが伴います。

VB6の後継となるプログラミング言語は「VB.NET」

VBの最終版はVB6.0で、それ以後の新しいバージョンは開発されていません。VBの後継となるプログラミング言語はVB.NETで、現在の最新バージョンはVisual Basic 2019（VB16）です。このVB.NETも、一般的には「VB」と呼ばれることが多くありますが、その言語の中身は旧来のVisual BasicではなくVB.NETです。VB.NETは、VB6までの系統とは言語仕様に多くの変更点があり、VB6以下との直接的な互換性はありません。

VB.NETは、「.NET Framework」を使ってコンパイルされ、動作します。Windows用のアプリケーション開発、Web用のアプリケーション開発、およびモバイル向けのアプリケーション開発などに使われています。開発にはMicrosoftの統合開発環境Microsoft Visual Studioを利用するのが一般的です。

VB6を使用し続けるリスク

VB6はリリースされてから長い時間が経っており、開発環境のサポート期限も切れています。そのようなプログラミング言語を使い続けることは当然ながら、さまざまなリスクを伴います。

VB6環境で作成されたアプリケーションを使い続けるリスクには、大きく分けてIT部門・開発側（主に経営部門・情報システム部門）と、利用者側（利用部門・ユーザー・一般社員）の2つに分類されます。

開発側に関するリスク

まずはVBアプリケーションを提供するIT部門・開発側に関するリスクを解説します。具体的には、次の4つがあると考えられます。

・開発（アプリ改修）を継続することに関するセキュリティリスク
VB6の統合開発環境は2008年に延長サポートが終了しています。開発環境にもセキュリティリスクがあり、安全とは言い切れません。また仮想化で延命させるなどの策をとっているとはいえ、統合開発環境をインストールできるOSも公式にはサポートが切れています。
VB6の全盛期にはいくつものサードパーティ製開発支援ツールがありましたが、こちらも現在はほとんどサポートが切れています。

・仕様に関するリスク
VB6 は 1998 年にリリースされたこともあり、古い仕様も多く残っています。たとえば VB6 の特徴の 1 つである ActiveX 対応です。ActiveX は Microsoft が開発した Internet Explorer 用のソフトウェアコンポーネントですが、2015 年には Microsoft のブラウザである Microsoft Edge では非対応になっています。さらに、サードパーティ製の ActiveX コントロールの多くは、すでにサポート期限切れの状態です。
VB6 を使い続けると、このような 「すでに使われていない技術」や「現在ではメジャーではない技術」（例：ActiveX やサポート切れの ActiveX コントロール） を前提とした開発を継続するというリスクがあります。

具体的には、次のような実務上の困りごとが発生しやすくなります。

• 新しい OS やブラウザに対応したいのに、古い ActiveX コントロールが動作せず、代替手段の検討や大規模な作り直しが必要になる
• 不具合が発生しても、サードパーティ製 ActiveX コントロールがサポート終了のため、ベンダーに問い合わせても修正パッチが提供されない
• セキュリティ要件の強化（例：最新ブラウザへの統一、ActiveX の禁止）に追随できず、社内ポリシーや取引先の要件と矛盾する
• VB6 や ActiveX に詳しい技術者が減少しており、改修や障害対応ができる人材の確保・育成に時間とコストがかかる
• 開発ツールや周辺ライブラリが更新されないため、自動テストや CI/CD など、現在主流の開発プロセスに組み込みにくい

このようなレガシー技術への依存が続くと、日々の機能追加や修正のたびに制約が多くなり、開発・保守の効率が低下します。

・実行に関するリスク
VB6を動作させるためには、独自に開発したアプリケーション以外に、Windows10では標準でインストールされていないVB6.0の実行環境（ランタイムライブラリ）が必要です。
MicrosoftはWindows10のサポート期間内はVB6のランタイムをサポートすると表明していますが、それ以降のサポートは明言していないのが現状です。今後のランタイムのサポートがいつまで続くかも不明です。また、Windows11も同様です。現在は動作していても、将来的にOSのアップデート等で動作しなくなるリスクは排除できません。

・システムの維持運用に関するリスク
VB6は古いプログラミング言語ということもあり、今や新規に習得するプログラマは少ないです。結果、現在では扱える技術者は少なくなりました。企業によっては自社開発したアプリケーションの保守運用が自社要員や当時委託した外部のベンダーのSEでまかないきれなくなり、外部から新たに調達することになります。外部から人材を呼ぶことになれば、採用や招集にかかる時間やコストのアップにつながります。

以上のことから、VB6で開発したアプリケーションを今後も安定して運用し利用部門に提供するのは、年々難しくなってきています。

ユーザーに関するリスク

利用部門側に関するリスクには、次の2つがあるといえるでしょう。

・セキュリティに関するリスク
VB6開発環境のサポートが切れていることもあり、今後新たな脆弱性が発見されたとしても、Microsoftからセキュリティ更新プログラムが提供されることはありません。そのため、VB6を利用したアプリケーションを使い続けたり、開発環境を使ってアプリケーションを修正したりすること自体がセキュリティリスクを増やすことにつながります。たとえば、情報漏えいや不正アクセス、それらをきっかけとしたサービス停止などです。これは、サードパーティ製の開発支援ツールについても同じことが言えるでしょう。

・業務内容に関するリスク
VB6のアプリケーションには古いものが多く、仕様や要件も開発当時の業務に合わせて開発されています。そのため、想定されている業務内容や機能が現在の業務にそぐわないものも多い可能性が高いです。現在の業務に合わない仕様を使い続けることを、結果的に業務効率を落としているおそれもあります。

VB6からVB.NETへのマイグレーションにおける課題

VBマイグレーションとは、おもにVB6からVB.NETへの移行を指しています。マイグレーションとは、既存のシステムを全面あるいは部分的に再利用したうえで最新環境へ移行することで、ITモダナイゼーションとも呼ばれています。

VBマイグレーションは、過去にWindowsXPやWindows7などのOSのサポート終了前後に盛んに実施されました。当社もOSのサポート終了に合わせる形で、多くの企業様のVBマイグレーションを手掛けてきました。現在は多少下火になってきていますが、いまだにVB6アプリケーションが現役で使われています。これはマイグレーションがIT課題としての対応優先度が低く、後回しにされているのが現状だからです。
この記事を読まれている読者の方々にも、手を付けたいけど塩漬けになっているVBアプリケーションがあるのではないでしょうか？

VB6からVB.NETへそのまま変換することができない

VB6とVB.NETは設計思想が異なっており、その結果言語仕様が大きく異なる部分が多いため、上位互換性が十分でなくそのまま変換することはできません。さらにMicrosoftが提供している公式の変換ツールの「アップグレードウィザード」は、もっとも新しいもので2008年版という、いまから10年以上も前のものです。

そのため、VB6からVB.NETの最新版に移行するには、次のような段階を踏んだ変換を行う必要があります。

VB6.0→VB.NET 2008→VB.NET最新版

※VB6から直接最新バージョン（記事執筆時点はVisual Studio 2019）への直接アップグレードをすることはできません。

アップグレードウィザードを使うだけでは大量のエラーが発生

MicrosoftではVB6からVB.NETへの移行のための公式な移行ツールを提供しており、VBマイグレーションには、このツールを利用するのが一般的です。しかし、移行ツールそのものも発表されてから年月が経っており、VB.NETも、その間に何度もバージョンアップを繰り返しているため、一筋縄では移行できない、さまざまな課題があります。

公式のアップグレードウィザードを使用したとしても、多くの場合、プログラムの生成時や実行時には数万件以上の大量のエラーが発生します。基本的には、これらのエラーはすべて手作業で修正しなくてはなりません。VB6とVB.NETの両方に経験豊富な技術者は限られているため、修正作業にはかなりの工数と時間がかかります。

サードパーティ製品の互換性問題

VB6で開発されたアプリケーションの多くは、その開発生産性を上げたり、独自アプリケーションとしての使用時の利便性を高めたりするために、サードパーティ製のハードウェアやソフトウェアを組み合わせて利用されてきました。サードパーティ製品も古いものが多く、最新のVB.NET環境に対応しているか、あるいは上位互換性が保たれているか（たとえば最新バージョンを導入して入れ替えるだけで動作するのか）どうかは、個別に確認する必要があります。

また、Microsoft公式のアップグレードウィザードは、サードパーティ製品には対応していません。VB6で開発したアプリケーションはサードパーティ製品を利用していることが多く、そのままアップグレードしても、システム全体ではこれまでと同じようには利用できないことが多々あります。

サードパーティ製品のアップグレードには上位互換性が保たれてないことも多く、エラー修正と同じように手作業でプログラムを修正する必要があるため、多くの工数が必要になります。

VB6でVBマイグレーションを成功させるためのアプローチ

VB6からVB.NETへの移行が不可欠な一方で、多くの企業が長年「塩漬け」にしてきた背景には、前述したような数々の技術的ハードルがあります。しかし、企業の独自ノウハウが詰まった大切なIT資産をそのまま捨てるのは大きな損失です。
VBマイグレーションを成功させるためには、大きく分けて4つのアプローチがあり、それぞれ企業の予算や社内リソースの状況に合わせて使い分けます。

公式ツールを用いて難易度を把握する

開発環境を現在も保有している場合は、外部のITベンダーに頼らなくても、今のVB6製の自社アプリがどれだけ最新版のVB.NETに対応しているか、逆に言えば、どれだけ手修正で移行しなければならないか、をアップグレードウィザードで確認することができます。

おそらく大半のケースは大量のエラーが表示され、エラー修正や変換後のテストには多くの手間や時間がかかることが多くなるでしょう。サードパーティ製品を利用している画面や機能が多ければ、その分移行ボリュームを解析するのが大変になるかもしれません。

その場合はVBマイグレーションの専門家のサポートを受けると良いでしょう。

webアプリに移行する

VBをそのままVB.NETに移行するのではなく、ブラウザをクライアントとするwebアプリ化、という手段もあります。詳しくはこちらの記事をご確認下さい。
VB6をweb化するという既存IT資産活用の選択肢。ASP.NET移行によるVBアプリ資産の再生

マイグレーションの専門会社に全て委託する

「社内に移行作業に割ける人員がいない」「公式ツールでのエラー件数が多すぎてお手上げ」という場合は、マイグレーションの専門会社へ委託することも検証しましょう。

企業システムのマイグレーションを手がけてきた当社では、VBに限らず長年マイグレーションで培ってきたノウハウがあります。これらの技術やノウハウをVBマイグレーションに生かし、VBマイグレーションに関しても独自の分析ツール、変換ツールにより、８０％から９０％以上の自動変換が可能です。一部の機能だけをマイグレーションすることもできるため、積み重ねてきたノウハウを今後の業務にも活用することができます。

また自動変換できないエラーに関しても、同種エラーを網羅的に解析する「パターン分析」を活用することで、より効率的で不具合の少ない修正が可能です。

マイグレーションの第一人者でもあり、当社でVBマイグレーションを専門とする板倉が2019年に寄稿した日経XTECHの記事も合わせてご覧ください。
脱Visual Basicは茨の道、VB.NETへのマイグレーションに待つ「落とし穴」

マイグレーションの専門会社に一部を委託する

「すべてのプログラムを移行すると予算が合わない」という企業にとっては、専門会社に丸投げせず、作業を分担する体制を構築するのも選択肢の一つです。

たとえば、先行プロジェクトとして一部のサブシステムのマイグレーションを専門会社に依頼し、残りのシステムは自社で内製化して対応することで予算を抑える方法もあります。

VB6からVB.NETへのマイグレーションには十分な準備が必要

今回はVB6が抱えるリスクと、マイグレーションについて解説しました。
このように、VB6からVB.NETへの移行が不可欠な一方で、VBマイグレーションにはいくつもの大きな課題があります。公式のアップグレードウィザードがあっても、簡単に済ませることはできません。大きな課題があるからこそ、企業によってはサポート終了から何年もの間、塩漬けになってきたという側面もあるといえるでしょう。

VBアプリからの脱却を検討する際には、ぜひ当社に一度お問い合わせください。資産の規模や利用サードパーティー製品などのヒアリングをさせていただいたうえで概算見積を出させていただきます。もちろん見積費用は無料です。

VBマイグレーションのご紹介（VBモダナイゼーション）｜システムズ