COBOLは注目されるが、VB6とPowerBuilderという「もうひとつのレガシー危機」は見過ごされている

レガシー資産は、COBOLだけで完結していることの方が珍しい

「レガシーモダナイゼーション」という話題になると、議論はほぼ必ずメインフレームCOBOLに向かう——バッチジョブ、JCLスケジューラ、CICSトランザクションモニター、数十年前から動き続ける銀行の基幹システム。この捉え方は間違ってはいないが、全体像ではない。COBOL資産を抱えるほど歴史のある組織に足を踏み入れれば、たいていもう一つの、より静かなレガシー問題がその一段上のレイヤーに存在する。1990年代後半から2000年代半ばにかけてVB6やPowerBuilderで書かれ、いまも誰も触りたがらない社内ツールとして稼働し続けているWindows時代のクライアント・サーバーアプリケーションだ。

この二つのレガシーコードのカテゴリーは、ほとんどのツール群によって別々の問題として扱われている——一方にはメインフレーム用のパーサー、もう一方には.NET移行コンサルタント、という具合に。しかし、それを運用している企業の組織図の中では、この二つは同じ原因を持つ同じ問題であることが多い。誰も十分に文書化しなかったビジネスロジックが、すでに退職した人々によって書かれ、現在のエンジニアリングチームが流暢には読めない言語で存在している、という状態だ。Legacy Dragonが両方を、同じASTグラフ、同じシングルバイナリで意図的に解析するのは、コードが書かれた年代でツールを分けるやり方が、実際のITアセットの中でリスクが現れる形と一致しないからだ。

2026年のVB6：稼働し続けながら、追い詰められつつある

VB6は1998年に登場したソフトウェアであり、常識的に考えれば何年も前に引退していておかしくない。しかし、そうはなっていない。2026年に入ってからの報道も同じ結論に繰り返し行き着いている——何千もの企業がいまなおVB6アプリケーションを本番環境で稼働させており、Microsoftのスタンスは、既存アプリケーションについてはVB6ランタイムを最新のWindows上でも動作させ続ける一方、新規開発・セキュリティパッチ・64ビット対応にはその方針を広げない、というものだ。

この状況を維持するのは年々難しくなっている。Windows 11上でのVB6稼働に関する最近の分析では、Windows 10バージョン21H2以降のメジャーOSリリースのたびに互換性が悪化してきたことが指摘されている。その一因は、64ビット版Windowsが、多くのVB6アプリがUIコントロールや外部連携のために依存している32ビットCOMコンポーネントのサポートを打ち切っていることにある——しかも、そうしたコンポーネントの元々のインストーラーは、もはや存在しない、あるいは動作しないケースも少なくない。ほかのほぼすべてのアプリケーションにとっては何でもないはずのハードウェア更新が、20年間静かに動き続けてきたVB6ツールをついに壊してしまう引き金になり得る。

ここには互換性だけでなく、コンプライアンス上の論点もある。PCI DSS v4.0は2025年3月31日から義務化され、対象範囲内のすべてのシステムコンポーネントに対する脆弱性管理を要求している——これは、10年以上セキュリティパッチを受けていないランタイム上に構築されたソフトウェアにとって満たすのが厄介な要件だ。あるアプリケーションがコンプライアンス上の負債になるのに、特別な事情は要らない。ただ「まだ稼働している」というだけで十分なのだ。

PowerBuilder：ベンダー自身が導入基盤の大きさを物語っている

PowerBuilderの状況は見た目こそ違うが、根底にある事実は同じところを指している。Sybase(現Appeon傘下)は2025年5月にPowerBuilder 2025をリリースし、ゼロから書き直すのではなく現状のまま近代化しようとする組織を明確に狙った機能を投入した。コードを書き直さずにレガシー画面を視覚的に刷新できるノーコードUIテーマ機能、そして既存のPowerBuilderビジネスロジックを作り直すことなくモバイル・Webクライアントに公開できる自動REST API生成機能だ。ベンダーが「書き直さずに近代化する」ためのツールに投資するのは、旧アプリをいまだに使い続けている導入基盤が、放置せず直接サービスを提供する価値があるほど大きく、かつ重要である場合に限られる。

そのPowerBuilderコードを読み、安全に変更できる人材が見つかりにくくなっているのも、COBOL人材が枯渇しているのと構造的に同じ理由による。現在のコンピューターサイエンスのカリキュラムでは教えられておらず、1990年代・2000年代に現場でそれを身につけたエンジニアたちが、いままさに退職していく世代なのだ。

日本のレガシー問題は、メインフレームだけの話ではない

ここでLegacy Dragonが最初からUTF-8を前提とせず、Shift-JIS・EBCDIC・DBCSをネイティブに扱う理由につながってくる。日本の経済産業省(METI)は、2024年7月から2025年3月にかけて開催されたレガシーシステム刷新に関する検討会を組織し、2024年12月から2025年2月にかけて実施した市場動向調査を踏まえて、2025年5月に包括的な報告書を公表した。この報告書や、より広く語られる「2025年の崖」への懸念に関する報道では、日本企業の約80%がいまなおレガシーシステムに依存しているという数字が繰り返し引用されている。この数字は性質上、メインフレームのCOBOL資産とWindows時代のクライアント・サーバーツールの両方にまたがるものであって、どちらか一方だけの話ではない。COBOLしか読めないパーサーは、その資産棚卸しの半分にしか対応できていないことになる。

なぜ「二つのツール」ではなく「一つのツール」なのか

だからといって、VB6やPowerBuilderがCOBOLやJCLとまったく同じモダナイゼーション手法を必要とするわけではない——ランタイムのリスクも、移行経路も、ビジネス上の文脈も本質的に異なる。両者が共有しているのは、リスクの実際の形だ。文書化されていないロジック、高齢化していく作成者たち、そして誰も「自分が壊した人」にはなりたくないシステム。Legacy DragonがCOBOL、JCL、PL/I、Assembly、SQL/DB2、CICS、REXXに加えてVB6、VB.NET、PowerBuilderまでを解析し——合計10言語を、一つのシングルバイナリで、コードがどの年代に書かれたものであっても同じインタラクティブなASTグラフとして出力するのは、ほとんどの組織にとって本当に必要なのはメインフレーム用ツールとWindowsレガシー用ツールを別々に持つことではなく、事業が今も依存している「古いものすべて」を映し出す一枚の正直な地図である、という賭けなのだ。

---

メインフレーム資産とWindows時代のクライアント・サーバー資産の両方を抱えていますか?Legacy Dragonが10言語すべてをどう解析するかはdragon.aitytech.comで、Legacy Dragonが解決しようとしている解析のボトルネックについてはこちらの記事で、ロックダウンされた環境向けにシングルバイナリとして提供している理由はこちらの記事でご覧いただけます。お問い合わせはhello@aitytech.comまで。