【実務・中級編】VB.NETとC#の決定的な違い：言語仕様から読み解く相互運用性と実務での選び方 – Visual Basic (VB / VB.NET)解析バイブル

VB.NETとC#の決定的な違い：言語仕様から読み解く相互運用性と実務での選び方

業務システムの現場において、「なぜかVB.NETで書かれたレガシーコードと、新しくC#で書かれたコードが混在している」「VBの資産はあるが、モダンな非同期処理やAPI連携を入れたいのに知見がない」といった壁にぶぶったことはないだろうか。

世間では「C#が主流で、VB.NETは時代遅れ」という短絡的な神話がまことしやかに囁かれているが、それは言語の本質とCLR（共通言語ランタイム）の挙動を理解していない者の戯言にすぎない。VB.NETもC#も、コンパイルされれば同じIL（中間言語）を生成し、同じCLR上で実行される。

しかし、言語仕様の設計思想と、それに起因する開発者の「癖」には決定的な違いが存在する。
今回は、世界最高峰の業務自動化を担うアーキテクトの視点から、VB.NETとC#の決定的な違いを解き明かし、レガシー資産を活かしながら堅牢なモダンアプリケーションを構築するための実務的アプローチを伝授する。

—

1. 言語仕様の決定的な違い：甘えを許すVB vs 厳格なC#

まずは、両者の根本的な思想の違いを直視しよう。

オプション設定の罠（`Option Strict` と `Option Explicit`）

C#はデフォルトで型安全かつ厳格（Strict）だが、VB.NETは歴史的経緯（VB6等からの移行配慮）から、デフォルトでは型変換に「甘い」設定になっている。
実務において、`Option Strict Off` のままコードを書くことは「時限爆弾を抱えて業務アプリを作る」と同義である。

• `Option Strict On`: 暗黙の型変換（例: `Integer` から `Long` への拡大変換はOKだが、`String` から `Integer` への縮小・危険な変換をコンパイルエラーにする）を強制する。
• `Option Explicit On`: 変数の宣言を強制する。

【鉄則】
VB.NETでコードを書く際、ファイルの一番上に `Option Strict On` が書かれていないコードを見つけたら、即座に修正させろ。これがバグの温床の8割を占める。

構文の冗長性と可読性

C#が記号（`{ }`, `;`, `=>`）を多用し、数学的・構造的に記述するのに対し、VB.NETは英単語（`If…Then…End If`, `Sub`, `Function`）を多用する。
一見するとVB.NETは冗長に見えるが、「非プログラマーの業務担当者が仕様書代わりに読む」という観点においては、VB.NETの自然言語に近い可読性は強力な武器になり得る。ただし、メンテナンス性を考慮するならば、コードブロックのスコープを視覚的に捉える規律が必要だ。

—

2. 相互運用性（Interop）：C#とVB.NETの混在プロジェクトの極意

「VB.NETの古い資産（WindowsフォームやCOM連携ロジックなど）」と「C#で書いた新しいWebAPI連携クラス」を同じソリューションで動かすことは完全に可能である。
CLRのレベルでは両者は完全に等価だからだ。

しかし、安易な混在はビルド順序の依存関係を複雑にし、チームの認知負荷を上げる。
「アセンブリ（DLL）単位で言語を分離する」のがプロのアーキテクトの選択だ。

• データアクセス層やレガシーなUI層：VB.NET
• コアロジック、外部API連携、非同期処理：C#（または厳格なVB.NET）

このように役割を明確に分ければ、言語のイディオムの違いによるコンフリクトを防ぐことができる。

—

3. 【実践】ファイル・DB連携における堅牢なプロダクションコード

現場で最も多いトラブルが、「ファイル操作時のロック解放漏れ」や「データベース接続のリーク」だ。
VB.NETでもC#の `using` ステートメントに相当する `Using`ブロックが存在する。これを正しく使いこなすことが、リソース管理の基本中の基本である。

以下に、`Option Strict On` を前提とした、ファイル読み込みとデータベース接続（トランザクション制御含む）を安全に行う実用的なVB.NETコードを提示する。そのままコピペして現場のモジュールに組み込んでほしい。

Option Strict On
Option Explicit On

Imports System.IO
Imports System.Data.SqlClient
Imports System.Text

Public Class DataProcessor

”’

”’ 読み込むファイルのパス ”’ ファイルの内容（UTF-8）
Public Function ReadTextFileSafely(filePath As String) As String
If Not File.Exists(filePath) Then
Throw New FileNotFoundException(“指定されたファイルが見つかりません。”, filePath)
End If

‘ Usingブロックを使用することで、例外が発生しても確実にStreamReaderが破棄（Dispose）される
Using fs As New FileStream(filePath, FileMode.Open, FileAccess.Read, FileShare.Read),
sr As New StreamReader(fs, Encoding.UTF8)

Return sr.ReadToEnd()
End Using
End Function

”’

”’ 接続文字列 ”’ 更新対象ID ”’ 新しい値 Public Sub UpdateRecordWithTransaction(connectionString As String, targetId As Integer, newValue As String)
‘ データベース接続とコマンドもUsingで確実に管理する
Using connection As New SqlConnection(connectionString)
connection.Open()

‘ トランザクションの開始
Using transaction As SqlTransaction = connection.BeginTransaction()
Using command As SqlCommand = connection.CreateCommand()
command.Transaction = transaction
command.CommandText = “UPDATE M_Data SET Value = @Value WHERE Id = @Id”

‘ パラメータを明示的に追加（SQLインジェクション対策）
command.Parameters.Add(“@Value”, SqlDbType.VarChar, 100).Value = If(String.IsNullOrEmpty(newValue), CObj(DBNull.Value), CObj(newValue))
command.Parameters.Add(“@Id”, SqlDbType.Int).Value = targetId

Try
Dim rowsAffected As Integer = command.ExecuteNonQuery()

If rowsAffected = 0 Then
‘ 対象が存在しない場合はロールバック
transaction.Rollback()
Throw New InvalidOperationException(“更新対象のレコードが存在しませんでした。ID: ” & targetId.ToString())
End If

‘ 正常終了時はコミット
transaction.Commit()

Catch ex As Exception
‘ 予期せぬ例外時はロールバック
Try
transaction.Rollback()
Catch rollbackEx As Exception
‘ ロールバック失敗時のログ出力等の処理をここに記述
System.Diagnostics.Debug.WriteLine(rollbackEx.Message)
End Try

‘ 呼び出し元へ例外を伝播
Throw New ApplicationException(“データベース更新中にエラーが発生しました。”, ex)
End Try
End Using
End Using
End Using
End Sub

End Class

コードの解説ポイント

1. `Using` ステートメントの徹底: `FileStream`, `StreamReader`, `SqlConnection`, `SqlCommand` といった非管理リソース（メモリやファイルハンドル、ソケット）を保持するオブジェクトは、例外発生時であっても確実に `Dispose` されるよう `Using` で囲む。これがメモリリークや「ファイルが別のプロセスによって使用されています」エラーを防ぐ唯一の解である。
2. `Option Strict On` 対応の型キャスト: データベースのNull許容値を扱う際、`If(…, CObj(…), CObj(…))` を用いて明確に型を整合させている。曖昧な型推論に頼らないことで、実行時エラーを完全に排除している。
3. トランザクションの二重防壁: 業務システムで最も恐ろしい「中途半端なデータ更新」を防ぐため、`Try…Catch` の中で確実に `Rollback` を呼ぶ設計を強制している。

—

4. まとめ：実務におけるVB.NETの選び方と未来

「C#に書き換えるべきか？」という問いに対する私の答えはこうだ。
「動いている既存のVB.NET資産を、単に言語の好みだけでC#に書き換えるのはコストの無駄遣いである。しかし、新規開発やコアコンポーネントにはC#、あるいは厳格なルールを課したVB.NETを適用せよ」

VB.NETは死んだ言語ではない。.NETの進化（.NET 8 / .NET 9など）の恩恵をC#と全く同じように受けることができる。
重要なのは、言語の優劣ではなく、「書く人間がメモリ管理、例外処理、型安全性を正しく理解しているか」というエンジニアリングの基本原則に他ならない。

レガシーなVB資産をリスペクトしつつ、モダンな設計思想を注入することで、あなたの作る業務システムは、保守性が高く、かつ絶対に止まらない堅牢な要塞へと生まれ変わるはずだ。