【VB.NET極限知見】Option Explicit & Inferを制する者が、堅牢な業務システムを制す
開発現場でこんな恐怖を味わったことはないか？
「Excelから読み込んだ売上データをデータベースにINSERTするだけのプログラムなのに、なぜか月末だけデータが数円ズレる」
「前任者が適当に書いたコードのせいで、文字列の`”10″`と数値の`10`が暗黙に変換され、予期せぬ型変換例外（InvalidCastException）が本番環境で爆発した」
VB.NETは、その歴史的背景と「誰でも直感的に書ける」という美学の裏腹として、設定を怠るとコンパイラが勝手に気を利かせて（あるいは余計な世話を焼いて）コードをねじ曲げる言語だ。
特に業務自動化ツールや社内基幹システムのアドオンを開発する際、この「おせっかい」は致命傷になる。今回は、プロジェクトの寿命を縮める「暗黙の罠」を完全に駆逐し、保守性の極限へ到達するための`Option Explicit`と`Option Infer`の真実を伝授する。
—
1. 開発のプロが最初に確認すべき「3種の神器」
VB.NETのソースコードの最上部、あるいはプロジェクトのプロパティを見てほしい。以下の3行が揃っていないコードベースは、いわば「ブレーキの壊れたスポーツカー」だ。
Option Explicit On
Option Strict On
Option Infer Off
今回はこの中でも、変数の宣言と型推論の根幹を成す `Option Explicit` と `Option Infer` の挙動を、メモリとコンパイルの観点から丸裸にする。
—
2. Option Explicit：タイポが生む「幽霊変数」との決別
これは何をする設定か？
`Option Explicit On`（デフォルトで有効だが、コード先頭での明示が鉄則）は、「すべての変数は、使用する前に明示的に宣言しなければならない」という絶対の掟をコンパイラに強いる。
もしこれを `Off` にするとどうなるか？
‘ 【悪夢の Option Explicit Off の世界】
Sub TerribleCode()
‘ 宣言なしで突然使い出す
totalAmounnt = 1000 ‘ ← “ount” とタイポしている！
‘ 処理の途中でまたタイポ
Dim tax As Decimal = totalAmount 0.1 ‘ ← こっちは “ount” ではなく “ount” じゃない（正しくは totalAmounnt）
‘ 結果：税込み計算がおかしくなるが、コンパイルエラーは一切起きない
End Sub
`Option Explicit Off` の環境では、タイポした瞬間に対象の変数名で勝手に新しいグローバル（またはモジュールレベル）のバリアント型（Object型）の変数が生成される。これが「幽霊変数」の正体だ。
コンパイラはエラーを出さないため、デバッグの神様でも見つけ出すのが困難なバグが爆誕する。
業務システムにおける鉄則
- 常時 `On` に固定せよ。
- 開発者の「うっかりタイポ」を人間が目視で防ぐのは不可能。機械（コンパイラ）に強制させろ。
—
3. Option Infer：便利さの裏に隠された「型崩壊」の罠
これは何をする設定か？
`Option Infer` は、VB.NET 2008以降に導入された「型推論（Type Inference）」の挙動を制御する。
- `Option Infer On`（現代のデフォルト）：
代入される値から、コンパイル時に自動的に型を決定する。
Dim taxRate = 0.1 ‘ 右辺の “0.1”（Double型）を見て、自動的に Double 型と推論される
- `Option Infer Off`：
型を省略した場合、`Option Strict` の設定に応じてエラーになるか、レガシーな `Object` 型として扱われる。
なぜ「型推論」が業務システムで危険なのか？
一見、`Dim count = 10` のように書けるのはコードがすっきりして良さそうに見える。しかし、ファイル読み込みやデータベース連携が絡む瞬間、この「勝手な推論」が牙を剥く。
例えば、以下のようなCSVやExcelからのデータ読み込み処理を考えてほしい。
‘ Option Infer On の状態で、APIやCSVからデータを取得する場合
Sub DangerousProcess()
‘ CSVの1列目（本当は文字列の “00123” という顧客コード）を取得
Dim customerCode = GetCsvColumn(0)
‘ コンパイラは GetCsvColumn の戻り値（Object型または曖昧な型）を見て推論する…
‘ もし数値と判定されたら、先頭の “0” が消滅し、”123″ という数値に勝手に変換される！
ProcessDatabase(customerCode)
End Sub
業務データにおいて、「先頭のゼロ（郵便番号、社員番号、口座番号など）」が消える現象は、システムに対する信頼を一瞬で失墜させる致命的なバグだ。型推論に頼りきったコードは、「何型が入っているか分からない」という恐怖を常に内包する。
—
4. 【実践】バグをゼロにするプロダクションコード設計
ここからは、実務で使える「堅牢性を極限まで高めたデータ処理モジュール」のテンプレートを提示する。
`Option Explicit On`、`Option Strict On`、そして厳格な型定義を組み合わせた、プロのコードだ。
Option Explicit On
Option Strict On
Option Infer Off ‘ 型推論を禁止し、すべての変数を明示的に型定義する
Imports System.IO
Imports System.Text
Public Class DataImporter
”’
”’
”’ 読み込み対象のファイルパス Public Sub ImportCsvData(ByVal filePath As String)
‘ 存在チェック
If Not File.Exists(filePath) Then
Throw New FileNotFoundException($”指定されたファイルが見つかりません: {filePath}”)
End If
‘ エンLcodingを指定してStreamReaderを生成（文字化け防止）
‘ すべての変数は型を明示（As を省略しない）
Dim encoding As Encoding = Encoding.GetEncoding(“Shift_JIS”)
Using reader As New StreamReader(filePath, encoding)
Dim lineCount As Integer = 0
‘ 1行ずつ安全に処理
While Not reader.EndOfStream
Dim currentLine As String = reader.ReadLine()
lineCount += 1
‘ ヘッダー行のスキップなどの判定
If lineCount = 1 AndAlso IsHeaderLine(currentLine) Then
Continue While
End If
‘ 行データのパース（厳密な型変換）
Try
ProcessRowData(currentLine, lineCount)
Catch ex As Exception
‘ ログ出力と例外の伝播
Console.WriteLine($”[Error] 行 {lineCount} の処理中にエラーが発生しました: {ex.Message}”)
Throw
End Try
End While
End Using
End Sub
”’
”’
Private Sub ProcessRowData(ByVal line As String, ByVal rowNumber As Integer)
‘ カンマ区切りの分割
Dim columns As String() = line.Split(CChar(“,”))
If columns.Length < 3 Then
Throw New FormatException($"行 {rowNumber}: カラム数が不足しています。")
End If
' 型推論を使わず、意図した型へ明示的に変換・代入する
' 1. 顧客コード（文字列として厳格に扱う。先頭のゼロ落ちを防ぐ）
Dim customerCode As String = columns(0).Trim()
' 2. 数量（Integerへ明示的キャスト。数値以外なら例外を発生させる）
Dim quantity As Integer = 0
If Not Integer.TryParse(columns(1), quantity) Then
Throw New FormatException($"行 {rowNumber}: 数量が正しい数値ではありません -> ‘{columns(1)}'”)
End If
‘ 3. 単価（Decimal型を使用。通貨計算での浮動小数点誤差を排除する）
Dim unitPrice As Decimal = 0D
If Not Decimal.TryParse(columns(2), unitPrice) Then
Throw New FormatException($”行 {rowNumber}: 単価が正しい数値ではありません -> ‘{columns(2)}'”)
End If
‘ 堅牢な計算処理（Decimal同士の演算）
Dim totalAmount As Decimal = quantity unitPrice
‘ データベース登録処理へ引き渡し
SaveToDatabase(customerCode, quantity, unitPrice, totalAmount)
End Sub
Private Function IsHeaderLine(ByVal line As String) As Boolean
‘ 簡易的なヘッダー判定
Return line.Contains(“顧客コード”)
End Function
Private Sub SaveToDatabase(ByVal code As String, ByVal qty As Integer, ByVal price As Decimal, ByVal total As Decimal)
‘ TODO: 実際のADO.NETやORMを用いたDB保存処理
‘ ここでもSQLパラメータを使用し、型を一致させること
End Sub
End Class
このコードのアーキテクチャ的優位性
1. `Option Strict On` とのシナジー： 暗黙の型変換（例: `Integer` に `String` をそのまま代入するなど）がすべてコンパイルエラーになるため、型不一致によるバグが物理的に発生しない。
2. `Decimal` 型の徹底： 金額や単価の計算に `Double` や `Float` を使わず、高精度な `Decimal`（リテラルは `0D`）を採用。浮動小数点の丸め誤差による「1円のズレ」を完全に封じている。
3. `Integer.TryParse` / `Decimal.TryParse` の活用： 不正なデータが混入した際、プログラムがサイレントに壊れるのではなく、即座に意味のある `FormatException` をスローして安全に停止する（Fail-Fastの原則）。
—
5. チーフアーキテクトからの最終提言
「動けばいい」という甘いコードは、開発者自身の首を絞める。
業務自動化ツールや社内システムにおいて最も価値があるのは、派手な機能ではなく「絶対に止まらない信頼性」と「誰がメンテしてもバグを埋め込みにくい構造」だ。
今すぐ、あなたのプロジェクトのプロパティ、あるいはソースコードの先頭を確認してほしい。
`Option Explicit` を有効にし、`Option Infer` の無意味な便利さに頼るのをやめよう。
型を支配する者が、VB.NETを制する。今日のその小さな設定変更が、未来のあなた自身の徹夜を救うことになると確信している。
