VB6・Delphi製システムはいつまで動くか。移行タイミングの見極め

経理システム、受発注管理、生産管理、在庫管理――中小企業の基幹業務を、10年、20年と前に作られたVB6(Visual Basic 6.0)やDelphi製のアプリケーションが今も支えている光景は、決して珍しくありません。画面はいかにも「昔のWindowsソフト」という見た目で、ボタンは立体的に浮き出ており、フォントはくっきりとしたゴシック体。しかし中身は今日も正しく動き、伝票を発行し、在庫数を更新し続けています。

担当者に「このシステムはいつまで使えますか」と尋ねても、明確な答えが返ってくることは稀です。「昔からあるので大丈夫でしょう」「動いているので特に問題ないと思います」という感覚的な回答か、あるいは「実は分からない」という正直な沈黙のどちらかになりがちです。無理もありません。VB6もDelphiも、Windows 95〜XP時代を代表する開発ツールであり、開発した会社がすでに存在しない、担当者が退職している、そもそも保守契約自体が存在しないというケースが多いためです。

この記事は、VB6やDelphiで作られた業務システムがまだ現役で動いている会社の、情シス・総務兼任の担当者に向けて書きました。「いつまで使えるのか」「何を根拠に移行のタイミングを判断すればよいのか」という問いに対して、Microsoftの公式サポート情報という一次情報をもとにしながら、感覚ではなく手順で答えを出せるように整理します。専門用語は初出のタイミングで言い換え、判断に迷ったときに立ち返れる基準を提示することを目指します。

この記事で分かること

VB6・Delphiという2つの古い開発言語について、「サポートが切れている」という言葉の実際の意味、現時点で何がどこまで動くのか、そして「まだ大丈夫」から「そろそろ危ない」への切り替わりを見極めるための具体的なチェックポイントを解説します。結論を先に言うと、押さえるべきポイントは次の3つです。

• VB6のランタイム(実行に必要な部品)自体は、Windows OSのサポート期間中は動作する。ただし開発環境(IDE)は2008年にすでにサポート終了しており、新規開発や大きな改修は事実上できない
• Delphiは会社によってバージョンごとの状況が大きく異なる。古いバージョンほどOS互換の保証がなく、サブスクリプション切れの場合は開発元(Embarcadero社)からのサポートも受けられない
• 「動くかどうか」と「安全に使い続けられるかどうか」は別の話。移行タイミングの見極めは、OSのEOL(サポート終了)・周辺環境の互換性・属人化の進行度という複数の軸を組み合わせて判断する必要がある

「動いているから今すぐ作り直すべき」という単純な話でも、「動いているから永遠に安心」という話でもありません。事実を積み上げたうえで、自社にとって現実的な着地点を探すのがこの記事のゴールです。

そもそもVB6・Delphiとはどんな技術なのか

結論から言うと、VB6とDelphiはどちらも1990年代に登場した、Windows向けの業務アプリケーションを効率よく作るための開発ツールです。今も現役のシステムが多く残っているのは、当時「フォームに部品を貼り付けるだけで業務画面が作れる」という生産性の高さから、多くの中小企業の基幹システムに採用されたためです。

VB6(Visual Basic 6.0)は、Microsoftが1998年に発売した開発環境です。ドラッグ&ドロップでボタンや入力欄を配置し、比較的平易な文法でプログラムを書けたことから、情報システム部門を持たない中小企業でも、社内の詳しい社員や小規模な開発会社が独自に業務システムを組み上げるケースが多く見られました。

Delphiは、当時Borland社(現在は開発元がEmbarcadero社に移行)が販売していた開発ツールで、Pascal系の言語(Object Pascal)をベースにしています。VB6よりもやや専門的な位置づけでしたが、動作の軽さやデータベース連携のしやすさから、生産管理・在庫管理・販売管理といった基幹系のシステムで採用された例が数多くあります。

どちらも共通しているのは、「Windows専用の、ゼロから作り込む開発ツールで作られた」という点と、「開発環境自体がすでに新規販売・積極開発されていない、あるいは限定的にしか提供されていない」という点です。つまりこれらの言語で作られたシステムは、広い意味でのレガシーシステムに分類されます。

補足: 「VB6」と「VBA(Visual Basic for Applications)」は名前が似ていますが別物です。VBAはExcelなどのOffice製品に組み込まれたマクロ用の言語で、Officeのサポートポリシーに従います。本記事で扱うのは、独立した実行ファイル(.exe)として動く業務システムを作るためのVB6です。

VB6のサポート状況を一次情報で確認する

結論から言うと、VB6には「開発環境(IDE)」と「ランタイム(実行に必要な部品)」という2つの異なるサポート区分があり、この2つを混同すると判断を誤ります。Microsoft公式のサポートステートメントには、次のように明記されています。

Visual Basic 6.0 IDE and Visual Studio 6.0 IDE are no longer supported as of April 8, 2008.(Visual Basic 6.0 IDEおよびVisual Studio 6.0 IDEは、2008年4月8日をもってサポートが終了しました)

——Microsoft Learn「Support Statement for Visual Basic 6.0」より

つまり、VB6を使って新しくプログラムを書いたり、大幅に改修したりするための開発環境は、すでに17年以上前にサポートが打ち切られています。新しいWindowsのバージョンに合わせてIDE自体が更新されることは今後もありません。

一方で、すでに完成しているVB6アプリケーションを「動かす」ために必要なランタイムについては、事情が異なります。同じ公式ステートメントには次のようにも書かれています。

The Visual Basic 6.0 runtime will be supported for the support lifetime of Windows versions. The support bar is limited to serious regressions and critical security issues for existing applications.(VB6ランタイムは、それが含まれるWindowsバージョンのサポート期間中はサポートされる。ただしそのサポート基準は、既存アプリケーションにおける重大な後退および重大なセキュリティ問題に限定される)

——Microsoft Learn「Support Statement for Visual Basic 6.0」より

分かりやすく言い換えると、「VB6で作られた既存のアプリケーションは、そのランタイムを含んでいるWindowsのバージョンがサポートされている限りは、基本的に動き続ける」という方針です。2024年12月時点で更新されているMicrosoft公式ドキュメントによれば、Windows 11・Windows 10・Windows Server 2012 R2以降の各バージョンにおいて、VB6ランタイムのファイル自体はOSに同梱される形でサポート対象に含まれています。

ただしここには重要な但し書きが2つあります。

• サポートの範囲が限定的: 「重大な後退」と「重大なセキュリティ問題」への対応に限られ、通常のバグ修正や機能追加は行われません
• 32bit専用: VB6ランタイムのファイルは32bit版のみで提供されており、64bit版のWindows上では「WOW(Windows on Windows)」と呼ばれる互換動作環境の中でのみサポートされます。将来的にこの互換レイヤー自体が縮小・廃止される可能性はゼロではありません

つまり「VB6ランタイムはサポートされている」という言葉を額面通りに受け取ると誤解を招きます。正確には「今のところ動くように配慮されているが、その配慮は各Windowsバージョン自体のサポート期間という有限の枠の中でのみ有効」という状態です。Windows自体がEOLを迎えれば、VB6ランタイムのサポートもそこで終わります。EOL（サポート終了）の考え方については、Windows Serverを例に別記事で詳しく解説しています。

Delphiのサポート状況を一次情報で確認する

結論から言うと、Delphiのサポート状況はVB6よりも複雑で、「開発元(Embarcadero社)のサポート方針」と「実際に使っているDelphiのバージョン」の組み合わせによって答えが変わります。VB6のように「〇年〇月にIDEのサポートが終了」という一律の区切りが存在しない点が、VB6との大きな違いです。

現在のDelphiの開発元であるEmbarcadero社は、製品を購入すると1年間のアップデートサブスクリプション(更新・サポートプログラム)が付属し、それ以降も継続してサポートを受けるには、サブスクリプションの更新または最新版の購入が必要という方針を取っています。つまりDelphiは、Windows自体のライフサイクルとは独立した「ベンダー自身の商用サポート契約」という枠組みでサポートの有無が決まります。

さらに厄介なのは、旧バージョン製品の扱いです。Embarcadero社の公式サポート情報には、旧バージョン製品について次のような趣旨の説明があります。

旧バージョン製品は、発売当時に対応していたOS環境へのインストールのみが対象で、それ以降の新しいWindows環境への対応やインストールのサポートは保証されない

——Embarcadero社公式サポート情報「旧バージョンを取得したい」より(要旨)

これは、VB6ランタイムが「新しいWindowsでも同梱・動作するよう配慮されている」のとは対照的な方針です。Delphiで作られたシステムの場合、「今使っているWindowsで今は動いている」という状態と、「開発元がそのバージョンの互換性を保証している」という状態は、必ずしもイコールではありません。

自社のDelphi製システムが今どのバージョンで作られていて、そのバージョンが現在どういう扱いになっているかを確認するには、次の情報を集める必要があります。

なお、Delphi自体は現在も新バージョンが継続的に販売・開発されている製品です。「VB6のように言語自体が終わっている」わけではなく、あくまで「古いバージョンのまま長年更新していない」ことがリスクの源になっている点は、VB6とは性質が異なります。この違いは移行タイミングの判断にも影響するため、後述の判断基準の項目で改めて触れます。

「動いている」と「安全に使い続けられる」は別の話

結論から言うと、VB6・Delphiともに「今日、目の前で動いている」という事実は、「今後も安全に使い続けられる」ことをまったく保証しません。この2つを混同したまま経営層に説明すると、「動いているなら問題ないだろう」という反応が返ってきて、話が前に進まなくなります。

「動いている」という状態を支えているのは、次のような複数の前提条件が、たまたま今のところ崩れずに揃っているという状況にすぎません。

• 今のWindowsのバージョンが、VB6ランタイムやDelphiの実行に必要なファイルをまだサポートしている
• サーバーやパソコンのハードウェアが、まだ物理的に故障せずに動いている
• システムを操作できる担当者が、まだ会社に在籍している
• OSやセキュリティソフトの更新が、たまたまシステムの動作に悪影響を与えていない

このうちどれか1つでも崩れると、「動いている」という前提そのものが揺らぎます。たとえばパソコンが故障して買い替えた瞬間、新しいOSでは古いアプリケーションが正常に動かなくなる、というのは実際によくある事故です。特にDelphiの古いバージョンは、前述の通り新しいOSでの動作をEmbarcadero社が保証していないため、この種のトラブルが起きやすい傾向にあります。

経営層への説明で使いやすい例え: 「古い建物が今日も倒れずに建っているからといって、耐震基準を満たしているとは限りません。次の地震(=パソコンの故障やOSの大型更新)で崩れないという保証はどこにもなく、"今のところ崩れていないだけ"という状態です」

VB6やDelphiで作られたシステムに属人化が重なっていると、状況はさらに深刻になります。「動いているが、なぜ動いているのか、どう直せばいいのか誰も分からない」システムは、小さなきっかけ一つで長期間の業務停止につながるリスクを抱えています。

移行タイミングを見極める4つのチェックポイント

結論から言うと、「いつ移行すべきか」を1つの絶対的な期日で答えることはできません。VB6・DelphiにはWindows Serverのような明確な「延長サポート終了日」の一覧が存在しないためです。その代わりに、次の4つの軸で自社の状況を点検し、複数の軸で「危険信号」が重なってきたタイミングを移行検討の目安とすることをおすすめします。

チェックポイント1: OS・ハードウェアの残り寿命

自社のVB6・Delphi製システムが動いているサーバーやパソコンのOSが、あとどれくらいでEOLを迎えるかを確認します。Windows 10は2025年10月14日に多くのエディションでサポートが終了しており、それ以降の延命には有償のESU(拡張セキュリティ更新プログラム)への加入が必要です。まだWindows 10のパソコンで稼働させている場合は、OS自体のサポート状況とセットで確認してください。

さらに、動かしているパソコン・サーバーのハードウェア自体の経年劣化も見逃せません。一般的にパソコンの物理的な寿命は5年前後と言われることが多いものの、実際の耐用年数は使用環境によって幅があります。目安として、次のような状態が1つでも当てはまる場合は要注意です。

• 同じ機種の予備機・代替機がすでに製造終了している
• ハードディスクや電源ユニットから異音・異常な発熱がある
• 起動やシャットダウンにかかる時間が以前より明らかに長くなっている

チェックポイント2: 開発・改修ができる体制の有無

「動いているシステムに、どうしても直したい不具合や追加したい機能が出てきたときに、誰が対応できるか」を確認します。次のいずれにも当てはまらない場合は、事実上「改修不能」の状態にあると考えたほうが安全です。

• 社内にVB6またはDelphiでの開発経験がある担当者がいる
• 開発を委託できる外部の開発会社と、現在も連絡が取れる関係にある
• ソースコードが手元にあり、開発環境(古いバージョンのVisual StudioやDelphi IDE)を用意すれば改修に着手できる

VB6のIDEは2008年にサポートが終了しているため、新規に開発環境を用意すること自体が年々難しくなっています。Delphiについても、古いバージョンのIDEを、現在の主流であるWindows 11環境にそのままインストールできるとは限りません。「ソースコードはあるが、開発環境が用意できない」という状態は、実質的にブラックボックス化が進行している段階です。

チェックポイント3: 周辺システムとの連携の変化

VB6・Delphi製システムが単独で完結していれば、周辺の変化による影響は比較的小さく済みます。しかし多くの基幹システムは、会計ソフト、ECサイト、給与計算システムなど、他のシステムとデータをやり取りしています。周辺システム側がクラウド化・バージョンアップを重ねる中で、連携方式(ファイル出力形式や通信プロトコルなど)が変わり、古いシステム側が対応できなくなるケースが増えています。

次のような予兆が出てきたら、移行検討を早める必要があります。

• 連携先のシステムから「〇〇形式でのデータ受け渡しは今後廃止します」という案内が来ている
• 手作業での回避(一度Excelに書き出してから手で変換するなど)が常態化している
• 連携先の担当者から「そちらのシステム、まだそんな古い形式なんですね」と言われる機会が増えている

チェックポイント4: 障害発生時の許容できる停止時間

最後のチェックポイントは技術的な話ではなく、業務側の許容度です。「このシステムが1日止まったら、会社にどれくらいの影響が出るか」を具体的に想像してみてください。

• 受発注や出荷が止まり、当日中の対応ができなくなる
• 経理処理が滞り、月次決算や支払い業務に遅れが出る
• 顧客への対応品質が下がり、クレームや信用低下につながる

もし「半日止まっても大きな問題はない」システムであれば、多少のリスクを許容しながら延命する選択肢も現実的です。逆に「数時間の停止でも会社の資金繰りや取引先との関係に直結する」システムであれば、たとえ今は問題なく動いていても、移行の優先順位を引き上げるべきサインです。

4つのチェックポイントをどう組み合わせるか

結論から言うと、4つのチェックポイントのうち2つ以上で「危険信号」が出ている場合は、本格的な移行検討に着手すべきタイミングです。1つの軸だけで判断するのではなく、組み合わせで見ることが重要です。

このとき注意したいのは、「移行=すべてを作り直す」だけが選択肢ではないという点です。老朽化したシステムへの向き合い方には、大きく分けて延命と作り直しという2つの方向性があり、どちらを選ぶべきかはTCO(総所有コスト)や技術的負債の大きさによって変わります。この判断軸については、『老朽化した社内システムの「延命 vs 作り直し」判断基準』で詳しく解説しているので、あわせて確認してください。

移行までの「つなぎ」としてできる延命策

結論から言うと、移行を決めたとしても、実際にシステムが切り替わるまでには一定の期間がかかります。その間にリスクをゼロにすることはできませんが、いくつかの延命策で被害の大きさを抑えることは可能です。

• ネットワークからの分離・限定: VB6・Delphi製システムが動く端末を、インターネットに直接つながらない環境に置く、あるいは必要最小限の通信のみ許可する設定にする
• バックアップの強化: システムが停止・破損しても業務を再開できるよう、データのバックアップ体制を見直す。バックアップの基本原則については別記事で扱っています
• アクセス権限の最小化: システムを操作できるアカウントを必要最小限に絞り、退職者のアカウントが放置されていないか確認する
• 代替手段の準備: システムが完全に止まった場合に、一時的に手作業(紙・Excel)で業務を継続できる手順を用意しておく

これらはいずれも「移行しなくていい理由」ではなく、あくまで移行が完了するまでの時間を安全に稼ぐための応急処置です。延命策を講じたことで安心してしまい、移行の検討自体が止まってしまうことのないよう注意してください。

移行を検討する際に社内で整理しておくべきこと

結論から言うと、移行プロジェクトを始める前に、現在のシステムに関する情報を可能な限り洗い出しておくことで、その後の見積もり依頼や意思決定がスムーズになります。次の情報を一覧化しておくことをおすすめします。

1. 現在のシステムでできること: 画面の一覧、主要な機能、月次・年次で行っている特殊な処理(決算処理など)
2. データの量と種類: 取り扱っているデータベースの規模、過去データの保存年数、他システムとの連携有無
3. 業務フロー: システムを使う部署・人数、1日あたりの利用頻度、繁忙期の有無
4. 既知の不具合・不満点: 現状で困っていること、動作が遅い処理、手作業でカバーしている部分

こうした情報がまとまっていると、開発会社に相談する際のRFP（提案依頼書）作成がスムーズになり、見積もり精度も上がります。ゼロから作り直す場合、フルスクラッチ開発で自社の業務に合わせて開発する方法と、既製のパッケージソフト・ノーコード・ローコードツールを活用する方法のどちらを選ぶかによって、費用や期間の目安も大きく変わってきます。

なお、移行先のシステムを外部の開発会社に依頼する場合、旧システムのベンダーロックインの状態(ソースコードの権利が自社にあるか、データを自由に取り出せるかなど)によって、移行の難易度が大きく変わります。ソースコードの著作権や利用許諾の扱いは、契約時点で明確にしておかないと後々のトラブルの種になります。

まとめ: 「動いている」を判断材料にしない

VB6・Delphi製のシステムが今日も動いているという事実は、移行を先送りする理由にはなっても、安全である証明にはなりません。VB6は開発環境(IDE)がすでに2008年にサポート終了しており、ランタイムもWindowsのサポート期間という有限の枠の中でのみ動作が配慮されている状態です。Delphiは開発元の商用サポート契約とバージョンごとの互換性次第で状況が変わり、古いバージョンほど新しいOS環境での動作が保証されません。

大切なのは、「動いているかどうか」ではなく、「OS・ハードウェアの残り寿命」「改修できる体制の有無」「周辺システムとの連携の変化」「停止時に許容できる時間」という4つの軸で、危険信号がどれだけ重なっているかを定期的に点検することです。危険信号が少ないうちは計画的な準備期間として、複数重なってきたら本格的な移行検討の段階として、感覚ではなく根拠を持って次の一手を判断してください。

移行するかどうかの判断そのものについては、次の記事で「延命」と「作り直し」を比較する具体的な評価軸を解説しています。あわせて確認しておくと、社内での説明や稟議の際にも役立つはずです。