この記事の要点
VB6からC#への移行では、構文を変換するだけでは足りません。ActiveX・OCXなどのコントロール、Variant型やOn Errorなど言語仕様の非互換、DAO・ADOによるデータアクセス、Win32 APIや帳票、文字コードの扱いまで、移行前の評価が成否を分けます。本記事では、評価すべき8つのポイント、移行方式の選び方、5ステップの移行手順とAI活用を解説します。
VB6からC#への移行とは、Visual Basic 6.0で作られたアプリケーションを、.NET上で動くC#のアプリケーションへ置き換えることです。成功のポイントは、変換作業に入る前に「何が、どれだけ、そのままでは動かないか」を評価しておくことにあります。
VB6のアプリケーションは、ActiveXコントロールやCOM部品、Windows APIに強く依存していることが多く、変換ツールで構文を置き換えても、それだけでは動きません。移行前の評価を省くと、移行途中で想定外の作業が次々に見つかり、費用と期間が膨らみます。
本記事は、VB6・VBA移行サービスを解説した記事のクラスター記事です。ここでは、VB6からC#への移行で「移行前に何を評価すべきか」に焦点を当てます。
1. VB6からC#への移行とは？なぜ今C#なのか
まずは、VB6のサポート状況と、移行先としてC#が選ばれる理由を整理しましょう。
1-1. VB6のサポート状況と放置するリスク
VB6の開発環境（IDE）は、すでにMicrosoftのサポートが終了しています。VB6ランタイムについては、Microsoftがサポート方針を公開していますが（Microsoft「Visual Basic 6.0 のサポートに関する声明」）、アプリケーションが使っている追加のコントロールやサードパーティ製部品まで動作が保証されるわけではありません。
さらに、VB6の開発者は年々減っており、改修や不具合対応を担える人材の確保が難しくなっています。Windowsの更新や64bit環境への対応のたびに、動作確認の負担も増えていきます。
1-2. 移行先にC#（.NET）が選ばれる理由
VB6の移行先には、VB.NETとC#の2つの選択肢があります。VB.NETは文法がVB6に近いため移行しやすい一方、長期的な保守性や技術者の確保を重視して、C#を選ぶ企業が増えています。
| 比較項目 | VB.NET | C# |
|---|---|---|
| VB6との文法の近さ | 近い（移行時の心理的ハードルが低い） | 異なる（書き換えの範囲が広い） |
| 技術者の確保 | 少なくなりつつある | 多く、採用・育成がしやすい |
| 新しい機能・情報量 | C#に比べて限定的 | 新機能・ライブラリ・情報が豊富 |
| 向いているケース | 短期間で移行し、当面の延命を優先 | 長期的な保守性・拡張性を重視 |
2. VB6からC#への移行前に評価すべき8つのポイント
では、移行前に何を評価すればよいのでしょうか。HBLABでは、VB6からC#への移行前に、次の8つのポイントを必ず確認しています。
① 資産の規模：フォーム・モジュール・帳票の数
フォーム（画面）、標準モジュール、クラスモジュール、帳票の数と行数を把握します。あわせて、本番で使われているexeとソースが一致しているかも確認します。VB6の資産は、担当者の端末にしかソースが残っていないこともあります。
② ActiveX・OCX・サードパーティ製コントロール
グリッド、カレンダー、帳票などのActiveXコントロール（OCX）は、VB6からC#への移行で最も工数がかかりやすい部分です。開発元がすでに存在しない製品や、.NET版がない製品は、代替のコントロールを選び直す必要があります。
③ 言語仕様の非互換
VB6とC#は、言語仕様が大きく異なります。代表的な非互換は次のとおりです。
| VB6の仕様 | C#での注意点 |
|---|---|
| Variant型 | 型が明確でないため、適切な型への置き換えと検証が必要 |
| On Error GoTo / Resume Next | try-catchへの書き換え。エラーを無視していた処理の扱いを決める |
| 配列の下限（Option Base 1・任意の下限） | C#は0始まり。添字のずれが不具合の原因になる |
| 固定長文字列（String * n） | 固定長の扱いを明示的に実装する |
| 既定のプロパティ・ByRefの既定 | 省略されていた記述を補う。引数の渡し方が変わる |
| コントロール配列 | 配列やイベントハンドラーで置き換える |
④ データアクセス：DAO・RDO・ADO
VB6では、DAO・RDO・ADOでデータベースにアクセスしているケースが多くあります。C#では、ADO.NETやEntity Framework Coreへの置き換えが必要です。Recordsetを前提にした処理の流れは、そのままでは移せないため、設計の見直しが必要になります。
⑤ Win32 API・COM連携・外部DLL
Declare文で呼び出しているWindows API、COM部品、独自のDLLは、C#側で呼び出し方を書き直す必要があります。64bit環境で動かす場合は、32bit専用の部品が使えなくなる点にも注意が必要です。
⑥ 帳票・印刷
Printerオブジェクトでの直接印刷や、帳票ツールに依存した出力は、移行先で別の仕組みに置き換える必要があります。帳票のレイアウトずれは利用者が最も気づきやすい違いのため、帳票は早い段階で現新比較の対象に含めます。
⑦ 文字コード・日付・数値の扱い
VB6では、Shift_JISを前提にしたバイト数の計算（LenB・MidB・StrConvなど）や、Format関数による日付・数値の書式設定がよく使われます。.NETは内部的にUnicodeで文字列を扱うため、バイト数や全角・半角を前提にした処理は特に注意が必要です。Currency型の端数処理も確認しておきましょう。
⑧ 実行環境：32bit/64bit・配布・権限
VB6アプリケーションは32bitで動作します。移行後に64bitで動かすのか、配布方法（インストーラー、ネットワーク配置など）や実行時の権限はどうするのかを、移行前に決めておきます。
| 評価ポイント | 確認内容 | 移行への影響 |
|---|---|---|
| ① 資産の規模 | フォーム・モジュール・帳票の数、ソースの有無 | 見積もりの基礎 |
| ② ActiveX・OCX | 使用コントロール、代替製品の有無 | 画面の作り直しの範囲 |
| ③ 言語仕様 | Variant、On Error、配列、固定長文字列 | 変換後の修正量 |
| ④ データアクセス | DAO・RDO・ADO、Recordsetの使い方 | データ層の再設計 |
| ⑤ API・COM・DLL | Declare文、COM部品、独自DLL | 64bit対応、呼び出しの書き換え |
| ⑥ 帳票・印刷 | Printerオブジェクト、帳票ツール | 帳票の作り直し |
| ⑦ 文字コード・書式 | LenB・StrConv・Format・Currency | 文字化け・桁ずれのリスク |
| ⑧ 実行環境 | 32bit/64bit、配布、権限 | 基盤設計・運用 |
3. 移行方式の選び方：自動変換・リライト・再構築
8つのポイントの評価結果をもとに、移行方式を選びます。代表的な方式は次の3つです。
| 方式 | 概要 | 向いているケース | 注意点 |
|---|---|---|---|
| 自動変換＋修正 | ツールやAIで変換し、動かない箇所を修正する | 資産が多く、仕様を変えずに早く移したい | VB6的な書き方が残り、保守性は高くなりにくい |
| リライト | 仕様は変えず、C#らしい設計で書き直す | 長期的な保守性を重視したい | 自動変換より工数がかかる |
| 再構築 | 業務を見直し、Webアプリなどで作り直す | 業務の変化が大きく、UIも刷新したい | 要件定義からやり直すため期間が長い |
実際には、難易度の低い機能は自動変換、業務上重要で複雑な機能はリライトというように、機能ごとに方式を使い分けるのが現実的です。
4. VB6からC#への移行手順：5ステップ
HBLABでは、次の5ステップでVB6からC#への移行を進めています。
Step1. アセスメント：8つのポイントで資産を評価する
ソースを収集し、8つのポイントで資産を評価します。機能ごとの難易度を整理し、移行方式と見積もりの根拠をつくります。評価の観点は、マイグレーション前のソースコード解析も参考になります。
Step2. 仕様を可視化する
設計書が残っていない場合は、画面・帳票・処理の流れ・業務ルールをコードから読み解き、仕様として整理します。ブラックボックス化したシステムの仕様を取り戻す方法は、AIリバースエンジニアリングとレガシー設計書の復元手順で解説しています。
Step3. 移行後のアーキテクチャを設計する
Windowsフォーム（WinForms）・WPF・Webアプリのどれにするか、データアクセスの方式、ActiveXの代替製品、32bit/64bitを決めます。画面の作りを大きく変えるほど、利用者の操作確認の負担も増えるため、業務部門と合意しておきます。
Step4. AI支援でコードを変換し、人がレビューする
AIを活用してVB6のコードをC#に変換し、エンジニアがレビューと修正を行います。言語仕様の非互換は、変換ルールとして先に標準化しておくことで、品質のばらつきを抑えられます。
Step5. 現新比較テストで動作を確かめる
同じ操作・同じデータで旧システムと新システムを動かし、画面表示・帳票・データベースの結果が一致するかを確認します。テストの進め方は、移行のリグレッションテストをご覧ください。
VB6資産の「そのままでは動かない箇所」、把握できていますか？
HBLABの無償AI診断では、VB6のソースコードを解析し、ActiveX・言語仕様の非互換・外部依存などの移行リスクを可視化します。移行方式と見積もりを決める前の判断材料としてご活用ください。
5. AIはVB6からC#への移行をどこまで支援できるか
生成AIは、VB6のコードの読解とC#への変換で大きな効果を発揮します。ただし、AIにすべてを任せることはできません。
| 工程 | AIが得意なこと | 人が判断すべきこと |
|---|---|---|
| 資産の理解 | フォーム・モジュールの処理概要の要約 | 要約内容の正しさの確認 |
| 非互換の洗い出し | Variant・On Error・配列などの候補の検出 | 修正方針の決定 |
| コード変換 | VB6からC#への変換、テストコードの生成 | 設計方針、ActiveXの代替の選定 |
| テスト | テストケース・テストデータの作成 | 業務上の重要度、合否の判断 |
AIの誤りへの対策は、生成AIマイグレーションのハルシネーション対策で解説しています。AI活用の全体像はマイグレーションのAI活用をご覧ください。
6. VB6からC#への移行前チェックリスト
移行を始める前に、次の12項目を確認しましょう。
- 本番のexeとソースが一致していることを確認した
- フォーム・モジュール・帳票の一覧と行数を把握した
- 使用しているActiveX・OCXの一覧と、代替製品の有無を確認した
- Variant型・On Errorの使用箇所を洗い出した
- 配列の下限・固定長文字列の使用箇所を確認した
- DAO・RDO・ADOの使用箇所と、Recordsetの使い方を把握した
- Declare文・COM部品・独自DLLの一覧がある
- 帳票・印刷の仕組みと移行方法が決まっている
- LenB・StrConvなどバイト数前提の処理を洗い出した
- 32bit/64bit・配布方法・権限の方針が決まっている
- 機能ごとの移行方式（自動変換・リライト・再構築）が決まっている
- 現新比較テストの範囲と合否基準が合意されている
7. HBLABのVB6・VBA移行支援
HBLABは、VB6・VBAのモダナイゼーションを、アセスメントから移行・テストまで一貫して支援しています。
HBLABのAI Assessment Toolは、技術調査、評価、移行戦略、業務仕様の整理、コード変換、単体テスト、結合テストの7工程を支援します。AIで解析と変換を高速化し、移行方式の判断や代替製品の選定はSA・BAの専門家が担う体制です。
移行先の選び方やサービスの全体像は、VB6・VBA移行サービスとHBLABのマイグレーションサービスをご覧ください。
VB6からC#への移行、まずは評価から始めませんか？
「どこまで自動変換できるか分からない」「ActiveXの代替が決められない」といったお悩みに、HBLABがアセスメントと移行計画づくりからお応えします。
8. VB6からC#への移行に関するよくある質問
VB.NETではなくC#に移行すべきですか？
短期間での移行と当面の延命を優先するならVB.NETも選択肢です。一方、技術者の確保や長期的な保守性を重視するなら、C#が有力です。システムの寿命と社内の体制をふまえて判断しましょう。
変換ツールだけで移行は完了しますか？
完了しません。構文の変換はツールやAIで効率化できますが、ActiveXの置き換え、データアクセスの見直し、帳票の作り直し、現新比較テストは別途必要です。
VB6からC#への移行にはどのくらいの期間がかかりますか？
フォーム数、ActiveXの種類、帳票の数、選ぶ移行方式によって大きく変わります。まずはアセスメントで難易度を把握し、機能単位で段階的に移行する計画を立てるのが現実的です。
まとめ
VB6からC#への移行では、資産の規模、ActiveX・OCX、言語仕様の非互換、データアクセス、API・COM、帳票、文字コード、実行環境の8つのポイントを移行前に評価することが重要です。評価結果をもとに移行方式を使い分け、5ステップの手順で進めましょう。HBLABは、AIと専門家の組み合わせで、確実なVB6からC#への移行を支援します。
