【VB.NET極限最適化】Const・ReadOnly・Staticの完全使い分け：バグを根絶する変数設計の極意
開発現場でよく見かける光景がある。「とりあえず動くから」という理由で、すべての変数を適当なスコープで宣言し、メソッドのあちこちで値が書き換えられる。その結果、原因不明のバグに頭を悩ませ、デバッグに半日を費やす――。
特に業務自動化ツールやデスクトップアプリケーションをVB.NETで開発する際、「変数のライフサイクル（寿命）とスコープ（可視性）」の制御を誤ると、コードは一瞬でスパゲッティ化する。
今回は、VB.NETが持つ不変性と状態保持の要、`Const`、`ReadOnly`、`Static` の3つのキーワードに焦点を当て、実務で絶対に迷わない「堅牢な設計手法」をチーフアーキテクトの視点から伝授しよう。
—
1. なぜ「なんとなく宣言」が業務ツールを崩壊させるのか？
業務自動化ツール（Excel連携、CSV一括処理、DBバッチなど）では、大量のデータをループ処理することが多い。ここで変数の設計がいい加減だと、以下の問題が発生する。
- 意図しない値の書き換え（副作用）： 共通で使うべき設定値が、ループの途中で書き換わり、後半の処理が全滅する。
- メモリリークと不要なオブジェクト生成： 本来一度作ればいいものを、メソッドが呼ばれるたびに再生成する。
- 並行処理・マルチスレッドでの競合： 将来的に非同期処理（`Async/Await`）を導入した際、静的変数（Static）の誤用によりデータが破壊される。
これらを防ぐ盾となるのが、`Const`、`ReadOnly`、`Static` である。それぞれの本質を正しく理解し、適材適所で使い分けなければならない。
—
2. 3大キーワードの正体とライフサイクル
まずは、それぞれのキーワードが「メモリ上のどこに、いつ生まれ、いつ消えるのか」を整理する。
| キーワード | 対象 | 評価・決定タイミング | ライフサイクル (寿命) | 主な用途 |
| :— | :— | :— | :— | :— |
| `Const` | 定数 | コンパイル時 | アプリケーション起動中ずっと (埋め込み) | 数学的な定数、変更されないシステム上限値 |
| `ReadOnly` | フィールド | 実行時 (インスタンス生成時) | オブジェクトの生存期間に依存 | 依存性注入(DI)されるオブジェクト、設定値 |
| `Static` | ローカル変数 | 実行時 (初回通過時) | アプリケーション終了まで保持 | メソッド内での状態保持、キャッシュ、カウンター |
—
3. 各キーワードの深掘りと実践的アンチパターン
① `Const`（コンスト）：完全なる「ハードコードされた定数」
`Const` は、コンパイル時に値が確定する。そのため、数値や文字列などのプリミティブ型（Integer, String等）しか指定できない。
‘ 【良い例】絶対に変わらない物理法則やシステム制約
Private Const MaxRetryCount As Integer = 3
Private Const ConnectionTimeoutSeconds As Integer = 30
⚠️ 現場の罠（アンチパターン）：
「変更されないから」という理由で、外部ファイルパスや接続文字列に `Const` を使うのは悪手である。環境（開発・テスト・本番）によって変わる値を `Const` にすると、環境が変わるたびにリコンパイルが必要になる。環境依存値には `ReadOnly`（あるいは設定ファイル）を使うべきだ。
—
② `ReadOnly`（リードオンリー）：実行時不変の「信頼のフィールド」
`ReadOnly` は、クラスのフィールドに対して付与する。`Const` と異なり、コンストラクタ実行時（インスタンス生成時）に一度だけ値を代入できる。 これにより、「生成後は絶対に値を変更させない不変オブジェクト（Immutability）」を担保できる。
さらに、VB.NETではオブジェクトそのものだけでなく、`ReadOnly` を適切に使うことで外部からの意図せぬ改ざんを防げる。
—
③ `Static`（スタティック）：メソッドの記憶喪失を防ぐ「局所的永続変数」
`Static` は、メソッドのローカル変数に対して使用する。通常のローカル変数はメソッドを抜けると消滅するが、`Static` 変数はアプリケーションが終了するまでメモリ上に残り続け、次回のメソッド呼び出し時にも前の値を保持する。
Public Sub ProcessBatchRecord()
‘ この変数はメソッドを抜けても消えず、呼び出されるたびにインクリメントされる
Static executionCount As Integer = 0
executionCount += 1
Console.WriteLine($”現在の処理回数: {executionCount}”)
End Sub
⚠️ 現場の罠（アンチパターン）：
「グローバル変数を使うのはダサいから、隠蔽するために `Static` を使おう」という発想は非常に危険。`Static` 変数は実質的に「スコープがメソッド内に制限されたグローバル変数（静的変数）」であり、マルチスレッド環境や、クラスを複数インスタンス化して並行処理を行った際に、予期せぬデータの混入（スレッドセーフティの崩壊）を引き起こす。
—
4. 【実践】プロダクションコードで示す堅牢な設計
ここまでの知見を統合し、実務でそのまま使える「ファイル・DB連携を伴う堅牢なデータローダー」のクラス設計を示す。
このコードでは、`Const`（システム制限）、`ReadOnly`（依存性と設定）、そして必要最小限に抑えた設計を体現している。
Imports System.IO
Imports System.Data.SqlClient
Namespace Enterprise.DataProcessing
”’
”’
Public NotInheritable Class SecureCsvLoader
‘ ==========================================
‘ 1. Const: アプリケーション全体で絶対不変の定数
‘ ==========================================
Private Const MaxBatchSize As Integer = 1000
Private Const CsvDelimiter As Char = “,”c
‘ ==========================================
‘ 2. ReadOnly: インスタンス生成時に決定し、二度と書き換えないフィールド
‘ ==========================================
Private ReadOnly _connectionString As String
Private ReadOnly _logFilePath As String
”’
”’
Public Sub New(connectionString As String, logFilePath As String)
‘ 引数のガード節
If String.IsNullOrWhiteSpace(connectionString) Then
Throw New ArgumentException(“接続文字列が空です。”, NameOf(connectionString))
End If
If String.IsNullOrWhiteSpace(logFilePath) Then
Throw New ArgumentException(“ログファイルパスが空です。”, NameOf(logFilePath))
End If
‘ ReadOnlyフィールドへの代入は、コンストラクタ内でのみ許可される
Me._connectionString = connectionString
Me._logFilePath = logFilePath
End Sub
”’
”’
Public Sub LoadCsvToDatabase(targetCsvPath As String)
If Not File.Exists(targetCsvPath) Then
Throw New FileNotFoundException($”指定されたCSVファイルが見つかりません: {targetCsvPath}”)
End If
Dim lines = File.ReadAllLines(targetCsvPath)
Dim dataBatch As New List(Of String())(MaxBatchSize)
Dim processedCount As Integer = 0
For Each line As String In lines
Dim columns = line.Split(CsvDelimiter)
dataBatch.Add(columns)
‘ バッチサイズに達したらDBへバルクインサート（模擬）
If dataBatch.Count >= MaxBatchSize Then
ExecuteBulkInsert(dataBatch)
processedCount += dataBatch.Count
dataBatch.Clear()
End If
Next
‘ 最後の端数データを処理
If dataBatch.Count > 0 Then
ExecuteBulkInsert(dataBatch)
processedCount += dataBatch.Count
dataBatch.Clear()
End If
‘ 処理結果をログに記録
WriteLog(f”正常終了: 総処理件数 {processedCount} 件”)
End Sub
”’
”’
Private Sub ExecuteBulkInsert(batchData As List(Of String()))
‘ 実際のADO.NET処理がここに入ります
‘ _connectionString を使用して接続を確立
Using connection As New SqlConnection(_connectionString)
connection.Open()
‘ データベース処理のロジック…
End Using
End Sub
”’
”’
Private Sub WriteLog(message As String)
Dim logMessage As String = $”{DateTime.Now:yyyy-MM-dd HH:mm:ss} – {message}”
‘ _logFilePath を使用して追記
File.AppendAllText(_logFilePath, logMessage & Environment.NewLine)
End Sub
End Class
End Namespace
この設計が優れている理由
1. `Const` の適切な配置: バッチの最大サイズや区切り文字など、ロジックの根幹にかかわる変更されないマジックナンバーを排除している。
2. `ReadOnly` によるスレッド安全性と不変性: 接続文字列やログパスは一度コンストラクタで設定されたら、クラス内のどのメソッドからも書き換えられない。これにより、インスタンスの汚染を防ぎ、安全に並行処理（マルチスレッド）に耐えうる設計になっている。
3. 無駄な `Static` の排除: 処理件数やバッチデータはインスタンス変数やローカル変数として適切にスコープを閉じ込められており、予期せぬ状態の持ち越し（バグの温床）を完全にシャットアウトしている。
—
5. チーフアーキテクトからの提言
コードの品質は、変数の「寿命」と「可視性」をどれだけ厳格にコントロールできているかで決まる。
- 値が文字通り「完全に不変の定数」なら `Const`。
- クラスの状態として、外部から書き換えられたくない、インスタンス固有の値なら `ReadOnly`。
- メソッド内のロジックでどうしても状態を維持する必要があり、その影響範囲が完全に制御されている場合のみ `Static`（※基本的にはクラスのフィールド化を検討すべき）。
この3つの使い分けをマスターした瞬間から、あなたの書くVB.NETコードは「動くだけのスクリプト」から、「保守性が高く、バグを寄せ付けないエンタープライズ・プロダクションコード」へと劇的に進化する。
明日からのコーディングで、ぜひ「この変数のライフサイクルは本当に適切か？」と自問自答してみてほしい。
