1. イントロダクション：COMからCLRへの「遷都」という現実
Visual Basic 6.0（以下VB6）からVB.NETへの移行は、単なる「プログラミング言語のバージョンアップ」ではありません。それは、COM（Component Object Model）という1990年代を支配した技術体系から、.NETのCLR（Common Language Runtime）というマネージド実行環境への「遷都」に他なりません。
多くの開発プロジェクトが、かつてMicrosoftが提供していた「アップグレードウィザード」や、サードパーティ製の自動コンバートツールに頼り、そして沈没していきました。自動変換が生成するのは、旧時代の遺物である `Microsoft.VisualBasic` 名前空間（互換ライブラリ）のラッパーでカモフラージュされた、「.NETの皮を被ったVB6のゾンビコード」です。
本極限解説では、単に「動く」だけのコードを拒絶します。エンタープライズ環境で今後10年、20年と耐えうる保守性と極限のパフォーマンスを確保するために、手動リファクタリングにおいてアーキテクトが下すべき決断と、その具体的な実装技術を徹底的に解剖します。
—
2. アップグレードウィザードの限界：自動変換がもたらす「技術負債」の正体
自動変換ツールがなぜ破綻するのか。その理由は、両者の言語仕様の根本的なミスマッチにあります。
2.1 型システムの地殻変動
VB6とVB.NETでは、基本データ型のメモリ割り当てが異なります。
| 型 (VB6) | サイズ (VB6) | 移行先 (VB.NET) | サイズ (VB.NET) | 変換ツールの罠 |
| :— | :— | :— | :— | :— |
| `Integer` | 16-bit | `Short` | 16-bit | 変換ツールは `Short` にマップするが、現代のCPUでは `Integer` (32-bit) の方が高速。 |
| `Long` | 32-bit | `Integer` | 32-bit | 変換ツールは `Integer` にマップする。 |
| `Currency` | 64-bit (固定小数) | `Decimal` | 128-bit | スケールや精度の仕様が異なり、金融計算で微小な誤差を生む原因に。 |
| `Variant` | 16-byte (可変) | `Object` | 4/8-byte (参照) | ボックス化（Boxing/Unboxing）が多発し、GC（Garbage Collector）に極大の負荷をかける。 |
2.2 `On Error GoTo` のゾンビ化
自動変換ツールは、VB6の `On Error GoTo` をそのままVB.NETの `Try…Catch` に変換できません。結果として、VB.NET内に `GoTo` タグと `Resume` が入り乱れた、スパゲッティコードが温存されます。これはスレッドセーフティを著しく損ない、モダンな非同期処理（`Async/Await`）の導入を完全に阻害します。
2.3 `Microsoft.VisualBasic` 互換ライブラリへの依存
自動変換されたコードには、`Microsoft.VisualBasic.Compatibility` や `Left$`、`Mid$`、`DoEvents` などの関数が溢れかえります。これらは内部的に余分なオーバーヘッドを抱えており、.NET Framework/.NET Coreのネイティブなクラス（`System.String`、`System.Threading` など）に書き直さなければ、真のパフォーマンスは引き出せません。
—
3. メモリ管理のパラダイムシフト：COMの参照カウント vs CLRのガベージコレクション
VB6プログラマが.NET移行期に最も頻繁に引き起こす致命的なバグが、「メモリリーク」と「オブジェクトの解放遅延」です。
3.1 決定論的デストラクションの喪失
- VB6（COM）: `Set obj = Nothing` を実行するか、変数がスコープを抜けた瞬間に、参照カウントが `0` になり、その場で即座にメモリとリソースが解放されます（決定論的クリーンアップ）。
- VB.NET（CLR）: `obj = Nothing` を実行しても、参照ポインタが切れるだけで、メモリ上の実体はGC（Garbage Collector）が起動するまで解放されません（非決定論的クリーンアップ）。
特に、ExcelやWordなどのCOMコンポーネント（Officeオートメーション）や、レガシーなActiveX DLLをVB.NETから呼び出す場合、この違いは致命傷となります。バックグラウンドに大量の `EXCEL.EXE` プロセスが残留する現象は、これが原因です。
3.2 COMオブジェクトを完全に昇天させる極限の解放手法
.NETからCOMオブジェクトを操作する場合、ガベージコレクタに任せてはいけません。`Marshal.ReleaseComObject` を用いて、明示的かつ厳格に参照カウントをデクリメントする必要があります。
以下に、Officeオートメーション等で発生するCOMリークを完全に防ぐための、プロフェッショナルな実装パターンを示します。
Imports System.Runtime.InteropServices
Public Class ComResourceManager
Public Sub ExecuteExcelProcess()
‘ Excelアプリケーションの起動（COMオブジェクトの生成）
Dim xlApp As New Microsoft.Office.Interop.Excel.Application()
Dim xlBooks As Microsoft.Office.Interop.Excel.Workbooks = xlApp.Workbooks
Dim xlBook As Microsoft.Office.Interop.Excel.Workbook = xlBooks.Add()
Dim xlSheets As Microsoft.Office.Interop.Excel.Sheets = xlBook.Worksheets
Dim xlSheet As Microsoft.Office.Interop.Excel.Worksheet = CType(xlSheets(1), Microsoft.Office.Interop.Excel.Worksheet)
Try
‘ —————————————————-
‘ ここで主要な業務ロジックを実行する
‘ —————————————————-
xlSheet.Cells(1, 1).Value = “伝説のアーキテクト”
xlBook.SaveAs(“C:\Temp\Output.xlsx”)
Catch ex As Exception
‘ 業務例外のハンドリング
Throw New InvalidOperationException(“Excel処理中に致命的なエラーが発生しました。”, ex)
Finally
‘ —————————————————-
‘ COMオブジェクトを「生成の逆順」で確実に解放する
‘ —————————————————-
xlBook.Close(SaveChanges:=False)
xlApp.Quit()
‘ 参照カウントを0にするための明示的クリーンアップ
‘ （2回以上の参照を考慮し、ループで完全に解放する設計）
ReleaseComObjectSafe(xlSheet)
ReleaseComObjectSafe(xlSheets)
ReleaseComObjectSafe(xlBook)
ReleaseComObjectSafe(xlBooks)
ReleaseComObjectSafe(xlApp)
End Try
End Sub
”’
”’
Private Sub ReleaseComObjectSafe(ByRef obj As Object)
If obj IsNot Nothing AndAlso Marshal.IsComObject(obj) Then
Try
Dim refCount As Integer = 0
Do
refCount = Marshal.ReleaseComObject(obj)
Loop While refCount > 0
Catch ex As System.Exception
‘ 解放失敗時のトレース（通常は発生しない）
Debug.WriteLine($”COM解放エラー: {ex.Message}”)
Finally
obj = Nothing
End If
End If
End Sub
End Class
—
4. Win32 API呼び出し（P/Invoke）の再定義と極限の最適化
VB6コードの多くは、OSの機能にアクセスするために大量のWin32 APIを直接呼び出しています（`Declare` 文）。これをそのままVB.NETに移行すると、多くの場合、アプリケーションはクラッシュ（`AccessViolationException`）するか、x64環境に移行した瞬間に沈黙します。
4.1 64-bit（x64）への対応：`Long` から `IntPtr` へのパラダイムシフト
VB6におけるポインタやウィンドウハンドル（`hWnd`）は、すべて32-bitの `Long` 型で表現されていました。しかし、VB.NET（x64またはAnyCPUで動作時）では、ポインタは64-bit（8バイト）になります。これを `Integer` (32-bit) で受けると、上位4バイトの情報が脱落し、メモリ保護違反で即死します。
- 鉄則: ポインタ、ハンドル（`HWND`、`HDC`、`HANDLE` など）は、VB.NETでは絶対に `Integer` や `Long` で受けてはならない。必ず `System.IntPtr` を使用する。
4.2 文字列マーシャリング：`String` と `StringBuilder` の峻別
Win32 APIに対して、値を受け取るバッファとして文字列を渡す場合、VB6では空文字で埋めた `String` を渡していました。VB.NETにおける `System.String` は不変（Immutable）オブジェクトです。API側がメモリを書き換えるようなバッファの受け渡しには、必ず可変（Mutable）バッファである `System.Text.StringBuilder` を使用しなければなりません。
実践：Win32 API `GetWindowText` の移行比較
【VB6のレガシーコード】
‘ VB6での宣言
Declare Function GetWindowText Lib “user32” Alias “GetWindowTextA” (ByVal hwnd As Long, ByVal lpString As String, ByVal cch As Long) As Long
‘ VB6での呼び出し
Dim sBuf As String
Dim lRet As Long
sBuf = String$(255, 0)
lRet = GetWindowText(Me.hwnd, sBuf, 255)
MsgBox Left$(sBuf, lRet)
【VB.NETでの極限最適化コード（手動リファクタリング）】
Imports System.Runtime.InteropServices
Imports System.Text
Public Class NativeMethods
‘ 1. Unicode（W）版を明示的に呼び出し、マーシャリングを最適化。
‘ SetLastErrorをTrueにし、Win32エラーコードを.NET側でキャッチ可能にする。
Public Shared Function GetWindowText(
ByVal hWnd As IntPtr, ‘ hWndは厳密にIntPtrとして定義
ByVal lpString As StringBuilder, ‘ 書き換え可能なバッファとしてStringBuilderを指定
ByVal nMaxCount As Integer ‘ 32-bit整数
) As Integer
End Function
End Class
Public Class WindowManager
Public Function GetActiveWindowTitle(ByVal hWnd As IntPtr) As String
If hWnd = IntPtr.Zero Then Return String.Empty
‘ 余裕を持ったバッファサイズ（256文字）のStringBuilderを初期化
Dim titleBuffer As New StringBuilder(256)
‘ API呼び出し
Dim charactersCopied As Integer = NativeMethods.GetWindowText(hWnd, titleBuffer, titleBuffer.Capacity)
If charactersCopied > 0 Then
‘ 終端Null文字などを意識することなく、StringBuilderから直接文字列を切り出す
Return titleBuffer.ToString()
Else
‘ エラーハンドリング（必要に応じてMarshal.GetLastWin32Errorを取得）
Dim errorCode As Integer = Marshal.GetLastWin32Error()
If errorCode <> 0 Then
Debug.WriteLine($”Win32 Error occurred: {errorCode}”)
End If
Return String.Empty
End If
End Function
End Class
—
5. エラーハンドリングの近代化：`On Error GoTo` から構造化例外処理（SEH）へ
VB6の `On Error GoTo` は、呼び出しスタックの巻き戻しや、リソースのクリーンアップタイミングを隠蔽する、極めて危険な制御構造です。これを.NETの `Try…Catch…Finally` へ移行する際、単に「エラーを無視する」ようなコード（`On Error Resume Next`）をそのまま残すことは絶対に許されません。
5.1 構造化例外処理（SEH）へのリファクタリング規律
1. `On Error Resume Next` の全廃:
これは例外を「隠蔽」しているだけであり、システムの不整合状態を引き起こす主犯です。本当に例外を無視して処理を継続すべき箇所のみ、局所的に `Try…Catch` で囲み、何が発生したかをログに記録します。
2. `Finally` ブロックによる決定論的クリーンアップ:
DB接続（`SqlConnection`）やファイルIO（`StreamWriter`）など、アンマネージドリソースや限定資源は、必ず `Finally` ブロック、または `Using` ステートメントで確実にクローズします。
—
6. 実践コード：新旧対比で見る極限のリファクタリング
ここでは、「ファイルからデータを読み込み、レガシーなデータベース（ADO）に接続してレコードを挿入し、Win32 APIで処理完了ログを出力する」という、実務で頻出するシナリオを題材に、新旧のコードを対比します。
6.1 【BEFORE】VB6のレガシーな実装（スパゲッティコード）
‘ VB6：データベースへのインサートとログ出力
Public Sub ImportDataAndLog(ByVal filePath As String)
On Error GoTo ErrorHandler
Dim conn As ADODB.Connection
Dim rs As ADODB.Recordset
Dim fileNum As Integer
Dim lineData As String
Set conn = New ADODB.Connection
conn.Open “Provider=SQLOLEDB;Data Source=Server;Initial Catalog=DB;User Id=sa;Password=pwd;”
fileNum = FreeFile
Open filePath For Input As #fileNum
Do While Not EOF(fileNum)
Line Input #fileNum, lineData
‘ データベース挿入
conn.Execute “INSERT INTO LogTable (LogMessage) VALUES (‘” & Replace(lineData, “‘”, “””) & “‘)”
Loop
Close #fileNum
conn.Close
Set conn = Nothing
‘ Win32 APIでログ出力
Call OutputDebugStringA(“Process Completed Successfully.”)
Exit Sub
ErrorHandler:
MsgBox “Error: ” & Err.Description
If fileNum > 0 Then Close #fileNum
If Not conn Is Nothing Then
If conn.State = adStateOpen Then conn.Close
Set conn = Nothing
End If
End Sub
6.2 【AFTER】VB.NETの現代的かつ最適化された実装
Imports System.IO
Imports System.Data.SqlClient
Imports System.Runtime.InteropServices
Imports System.Text
Public Class DataImporter
‘ Win32 APIのモダンな宣言
Private Shared Sub OutputDebugString(ByVal lpOutputString As String)
End Sub
Private Const ConnectionString As String = “Server=Server;Database=DB;Integrated Security=True;Encrypt=True;”
”’
”’
Public Sub ImportDataAndLog(ByVal filePath As String)
‘ 1. 引数検証（ガード節）
If String.IsNullOrWhiteSpace(filePath) Then
Throw New ArgumentException(“ファイルパスが不正です。”, NameOf(filePath))
End If
If Not File.Exists(filePath) Then
Throw New FileNotFoundException(“対象ファイルが存在しません。”, filePath)
End If
‘ 2. 接続オブジェクトを Using で囲み、エラー発生時も確実にプールへ返却（メモリ解放）
Using conn As New SqlConnection(ConnectionString)
conn.Open()
‘ 3. StreamReader を用いた高速かつ安全なファイル読み込み
Using reader As New StreamReader(filePath, Encoding.UTF8)
‘ SQLインジェクションを防ぐため、パラメータ化クエリを使用
Dim query As String = “INSERT INTO LogTable (LogMessage) VALUES (@LogMessage)”
Using cmd As New SqlCommand(query, conn)
‘ パラメータの事前コンパイル（ループ内の高速化）
Dim param As SqlParameter = cmd.Parameters.Add(“@LogMessage”, SqlDbType.VarChar, 255)
While Not reader.EndOfStream
Dim lineData As String = reader.ReadLine()
‘ 空行のスキップ処理
If String.IsNullOrEmpty(lineData) Then Continue While
‘ パラメータに値をセットして実行
param.Value = lineData
cmd.ExecuteNonQuery()
End While
End Using
End Using
End Using ‘ ここで conn.Dispose() が自動実行され、接続が即座に解放される
‘ 4. Win32 APIによる進捗ログ出力
OutputDebugString(“Process Completed Successfully in .NET Environment.”)
End Sub
End Class
—
7. アーキテクトが語る、真の移行戦略（保守とシステム間連携の極意）
レガシー移行において、最も愚かなアプローチは「すべてを一度にビッグバンで書き換える」ことです。巨大なシステムであればあるほど、そのアプローチは破綻します。
7.1 「段階的移行（Strangler Applicationパターン）」の採用
移行期において、VB6のコアロジックをそのまま残しつつ、インターフェースやフロントエンドをVB.NETに徐々に置き換えていくアプローチが有効です。
- .NETからVB6（ActiveX DLL）を呼び出す: .NETの「COM相互運用（COM Interop）」機能を使用します。ただし、ラッパーオブジェクト（RCW: Runtime Callable Wrapper）の生存期間に極めて厳格である必要があります。
- VB6から.NET DLLを呼び出す: .NET側で「COM参照の登録（Register for COM Interop）」を有効にし、CCW（COM Callable Wrapper）を生成します。インターフェース（`Interface`）を明示的に定義し、UUID（`Guid`）を固定することが、レガシー環境を壊さずに機能追加を行う唯一の道です。
7.2 アーキテクトとしての冷徹な眼差し
VB6コードをVB.NETに「移行する」というタスクは、過去の技術的負債を清算する最大のチャンスです。
自動変換ツールは、その負債を「延命」するだけであり、将来的な開発効率を著しく低下させます。私たちは、プラットフォームの根底にある「メモリ管理、型安全、非同期処理、セキュアなリソース解放」というCLRの本質を理解し、手動でコードを再設計（リファクタリング）しなければなりません。
マシンパワーに任せた力任せの移行ではなく、言語とランタイムの思想に寄り添った、極限まで無駄のない洗練されたコードを記述すること。それこそが、技術至上主義を掲げる我々チーフアーキテクトに課せられた真の使命です。
