VB6モダナイズが待ったなしになっている背景
Visual Basic 6.0（VB6）は、いまもなお業務システムの内部で動き続けている言語のひとつです。開発元のサポートは2008年に終了しており、VB6そのものを新規開発で採用する企業は実務上ほぼ見当たりません。それでもなお、現場では「動いているから止められない」「仕様を知る人がいない」「再実装の見積もりが膨らみすぎる」といった理由で、リプレース判断が先送りされてきました。
状況を難しくしているのは、VB6ランタイムがWindowsのライフタイムに沿って提供され続けるとされている点です。具体的な打ち切り年次は本記事執筆時点で公式に明示されていませんが、それでも実態としてはセキュリティ対応・周辺ライブラリの陳腐化・VB6を扱える人材の枯渇という三方向からの圧力が強まり続けています。レガシーを抱え続けるコストは、年を追うごとに静かに膨らんでいくと考えるのが自然です。
こうした課題に正面から向き合うために登場したのが、AWS Transformファミリーの一翼を担う AWS Transform Custom です。AWS Transform は「for Windows」「for mainframe」「for VMware」「custom」の4区分で構成されており、Custom は組織固有の変換パターンを自動化する位置づけにあります。Windows 向けの標準フローでカバーしきれない VB6 のような言語に対しても、ユーザー自身が変換ルールを定義してポートフォリオ全体へ一貫適用できるのが特長です。本記事では、AWS のマイグレーション＆モダナイゼーションブログで2026年4月17日に公開された解説をベースに、VB6 から C# / Blazor Server への変換を実例とともに整理していきます。
AWS Transform Customの全体像と4フェーズ
AWS Transform Custom は「複雑な変換パターンの学習と適用」をエージェンティック AI で支援するツールとして紹介されています。組織固有のルールやアーキテクチャ標準を踏まえた変換定義をユーザー側で組み立て、レジストリに発行することで、同じルールをチーム全員が再利用できる構造になっています。操作の入口となるのは atx という CLI（ATX CLI）で、対話形式で変換定義の作成と実行を進められます。
元記事のソリューション概要では、変換プロセスを次の4フェーズに分けて整理しています。
フェーズ | 役割 |
|---|---|
Assess | VB6 アプリケーションポートフォリオのスコープと複雑さを評価する |
Define | VB6 から C# への変換パターン、ビジネスルール、コーディング標準を含むカスタム変換を定義する |
Execute | 定義した変換をポートフォリオ全体へスケールさせて適用する |
Review | 変換結果をレビューし、フィードバックループで定義を改善し続ける |
Assess フェーズでは、2026年3月31日に一般提供が開始された自動コードベース分析機能が大きな役割を果たします。アーキテクチャ、技術的負債、コードメトリクス、参照ドキュメント、移行計画、図表といった成果物を自動生成できるため、ポートフォリオ全体のスコーピングを短期間で進めやすくなります。なお、この自動コードベース分析の対応言語は Python、Java（Maven および Gradle）、Node.js、.NET の4種類で、利用リージョンは米国東部（バージニア北部）と欧州（フランクフルト）です。VB6 そのものは自動コードベース分析の対象には含まれていないため、VB6 ポートフォリオの評価では既存のドキュメントやサンプルアセスメントを補助的に使う形になります。
もう一点、誤読を避けるために整理しておきたいのが GA 区分です。自動コードベース分析機能の GA 時期は公式に確認できますが、AWS Transform Custom 本体や、VB6 から C# への変換機能そのものの GA 区分は本記事執筆時点で公式に明示されていません。したがって「サービス全体が GA 済み」と一括りに語るのは避け、機能単位で確認するのが安全です。
サンプルアプリSalmon King Seafood(SKS)で見る変換の中身
元記事では、実演用のサンプルとして Salmon King Seafood（SKS）という VB6 アプリが使われています。SKS は VB6 の Multiple Document Interface（MDI）形式で構築された業務アプリで、受注処理、顧客管理、商品カタログ、在庫管理、承認ワークフローといった機能を、いかにも基幹系らしい構成で備えています。
変換前と変換後の構造を整理すると、次のような対応関係になります。
VB6 側の要素 | 変換後（C# / .NET 10 / Blazor Server） |
|---|---|
frmMain.frm（MDI コンテナ） | ナビゲーションメニューを備えた Blazor MainLayout.razor |
15 以上の子フォーム | 個別の Blazor ページコンポーネント |
modConnection.bas | Entity Framework Core と SQLite プロバイダーを使う SksDbContext.cs |
MSFlexGrid / ListView などの標準コントロール | データバインディング付きの Blazor テーブルコンポーネント |
Orders.db（SQLite） | SQLite を継続利用しつつ EF Core 経由でアクセス |
元記事には、atx CLI の起動からビジネスルール追加、変換プラン一覧、ビルドコマンド登録、生成後の請求書ページや注文作成ページのスクリーンショットまで、合計9枚の図が含まれています。VB6 の MDI 画面が Blazor のページ単位 UI に置き換わっていく過程を視覚的に追えるため、自社アプリと重ね合わせて読みやすい構成になっています。
処理時間について元記事では、サンプルアプリの実行例として「最大60分」という記述があります。これは記事中の実演における結果であり、公式に保証された処理時間ではない点に注意してください。実際のアプリ規模、フォーム数、参照ドキュメントの密度、ビルド検証の回数によって所要時間は変動するため、自社のポートフォリオに当てはめる際は別途計測する前提で考えるのが安全です。
組織固有ルールを保つカスタム変換定義の作り方
AWS Transform Custom で品質を左右するのは、変換定義に渡す参照ドキュメントの中身です。元記事では、対話モード atx -t を起動して新規の定義を作成し、3種類のマークダウンを参照させる流れが示されています。
参照ファイル | 主な役割 |
|---|---|
example-transformations.md | ビジネスルールや before / after の変換例を提供し、組織のロジックを伝える |
coding-standards.md | 命名規則やコーディング規約を渡し、生成コードのスタイルを揃える |
target-architecture.md | ターゲットアーキテクチャ（.NET 10 / Blazor Server など）を明文化する |
これらを取り込んだうえでビルドコマンドを登録しておくと、変換結果が実際にビルド可能かどうかを自動で検証できます。変換プランをレビューしたあとは、atx custom def exec -p <path-to-repository> -n 'VB6-to-CSharp-Blazor-Migration' -t のように発行済み定義名を指定して実行します。発行された定義は atx custom def list で一覧化でき、チーム共有のレジストリとしてポートフォリオ全体に同じルールを適用できるのが特長です。
注意したいのは、生成コードの品質が「参照ドキュメントの解像度」に強く依存することです。example-transformations.md に記述されているサンプルが少なかったり、coding-standards.md が抽象的すぎたりすると、エージェントが意図と異なる実装を選んでしまう余地が残ります。Review フェーズで実コードを点検し、定義と参照ドキュメントを反復的に書き直していく前提で計画を組むことを強くおすすめします。
PoCを始める前に押さえておきたい現実的な注意点
AWS Transform Custom は強力な仕組みですが、PoC を始める前に押さえておきたい現実的な前提もあります。公式に明示されていない項目を断定で語らないことが、計画段階の事故を防ぐうえで重要です。
論点 | 現時点で確認できる情報 |
|---|---|
料金体系 | 具体的な単価や課金単位は公式ページに明示されていないため、AWS Transform pricing ページと営業窓口で都度確認する想定が安全 |
VB6 変換機能の GA 区分 | VB6 から C# への変換機能そのものの GA 区分は本記事執筆時点で公式に明示されておらず、断定しない |
対応言語の広がり | 本記事の実演は VB6 から C# / Blazor のパターンに限定され、他のレガシー言語にそのまま使えるかは公式に未明示 |
利用リージョン | 自動コードベース分析機能は米国東部と欧州フランクフルトで確認できるが、VB6 変換の利用可能リージョンは別途確認が必要 |
開発環境 | MacOS / Linux / WSL2、IDE は Visual Studio 2022 以降または Visual Studio Code が前提として記載されている |
もうひとつ強調しておきたいのは、AWS Transform Custom が「完全自律で変換を終わらせるツール」ではないという点です。4フェーズの最後に Review が置かれているとおり、生成結果を人間がレビューし、定義と参照ドキュメントを改善しながら反復することが前提に組み込まれています。サンプルアプリ SKS で動く話と、自社の VB6 ポートフォリオで安定して動く話は別物であり、本番適用前には実機での検証フェーズを必ず確保してください。
レガシー刷新は時間との戦いです。AWS Transform Custom を起点にしてカスタム変換定義のひな型を整え、小さなアプリで Assess → Define → Execute → Review の一巡を回せると、組織標準を保ったまま大規模なモダナイズへ踏み出す手応えが得られます。
