【テクニカル・上級編】実務中級者向け：VB.NETでのReadOnlyとConst、Staticの使い分け：変数のスコープとライフサイクルを制御して堅牢なロジックを作る – Visual Basic (VB / VB.NET)解析バイブル

変数の生存期間と不変性を掌握せよ：なぜ修飾子の選択ミスが深刻なバグを生むのか

業務システムの現場において、意図しない変数の書き換えや、予期せぬタイミングでの値の消失によって引き起こされるバグは後を絶ちません。特にレガシーなVBAやVB6のメンタリティを引きずったまま.NET Framework / .NET環境へ移行したプロジェクトでは、変数のライフサイクル（生存期間）とスコープ（可視範囲）、そして不変性（Immutability）に対する理解不足が、メモリリークやマルチスレッド環境でのデータ破壊といった深刻な障害を引き起こします。

本稿では、VB.NETにおける3つの重要修飾子——`Const`、`ReadOnly`、そして`Static`——について、CLR（共通言語ランタイム）の内部挙動、IL（Intermediate Language）レベルでの処理の違い、さらにはメモリ空間における変数の挙動までを踏まえて徹底解説します。

単なる構文規則の暗記ではなく、「メモリ効率と保守性の極限のバランス」を叩き込むための知見を提示します。

—

`Const` vs `ReadOnly`：コンパイル時定数と実行時定数の深淵

「変更されない値」を定義する際、`Const` と `ReadOnly` のどちらを選択すべきか。この判断を誤ると、大規模システムにおいて「DLLを差し替えたのに値が更新されない」という致命的な静的結合の罠（バージョン不整合問題）に直面します。

1. `Const`（コンパイル時定数）の物理構造

`Const` は、コンパイル時点で値が評価され、確定する定数です。

• メモリ挙動: メモリ上に変数領域が割り当てられるわけではありません。コンパイラは、`Const` を参照しているすべての箇所に対し、その「値そのもの」をILコード内に直接インライン展開（ハードコーディング）します。
• 使用可能型: 数値型、ボクシングを伴わない基本型、文字列（`String`）、および `Nothing` に限定されます。オブジェクトのインスタンスを `Const` にすることは不可能です。

【危険】アセンブリ境界を越える `Const` の罠

ライブラリ（DLL）側で `Public Const MaxRetryCount As Integer = 3` と定義し、メイン実行ファイル（EXE）からそれを参照しているとします。後からライブラリ側の値を `5` に変更してライブラリのみをビルド・デプロイしても、EXE側を再コンパイルしない限り、EXE内部には旧値 `3` がILコードとして直接埋め込まれたままとなります。

2. `ReadOnly`（実行時定数）の物理構造

`ReadOnly` は、実行時（インスタンス生成時、またはクラスロード時）に値が決定される修飾子です。

• メモリ挙動: 実際のメモリ領域（ヒープまたはスタック）に変数が確保されます。値の代入は宣言時またはコンストラクタ内部でのみ許容されます。ILレベルでは `initonly` フラグが付与され、コンストラクタ終了後の書き換えをCLRがハードウェア/OSレベルでブロックします。
• 参照型の不変性に関する勘違い: `ReadOnly` が保証するのは「参照（アドレス）の変更不可」であり、「参照先オブジェクトの状態の変更不可」ではありません。例えば `ReadOnly` な配列や `List(Of T)` を定義しても、要素の追加や書き換え（`list(0) = “X”`）は防げません。

`Const` と `ReadOnly` の比較マトリクス

| 項目 | `Const` | `ReadOnly` |
| :— | :— | :— |
| 決定タイミング | コンパイル時（Compile-Time） | 実行時（Run-Time） |
| 評価回数 | コンパイル時に1回 | コンストラクタ呼び出しごとに評価 |
| 展開方式 | ILコードへのインライン埋め込み | メモリ（フィールド）へのアクセス |
| 適用可能型 | プリミティブ型・`String` のみ | 参照型・構造体を含むすべての型 |
| DLL参照時の挙動 | 呼び出し元の再コンパイルが必要 | DLLの更新のみで動的に新値を反映 |
| 推奨用途 | 数学定数、言語仕様レベルの不変値 | 設定値、接続文字列、ドメインオブジェクト |

【実装例】安全な定数設計と参照型 `ReadOnly` のカプセル化

Imports System.Collections.Generic
Imports System.Collections.ObjectModel

”’

Public Class SystemConfiguration

‘ 【Constの適切な使用例】
‘ システムの寿命尽きるまで絶対に変わらない純粋な値。ILに埋め込まれても問題ない。
Public Const AbsoluteMaxThreshold As Integer = 9999
Public Const StandardDateFormat As String = “yyyy-MM-dd HH:mm:ss”

‘ 【Shared ReadOnlyの適切な使用例】
‘ 実行時に設定ファイルや環境変数から取得し、以降は不変とするグローバル値。
‘ アセンブリ境界を越えても再コンパイルなしで値の変更が反映される。
Private Shared ReadOnly _dbConnectionString As String

‘ 【参照型ReadOnlyの誤用を防ぐ設計】
‘ 単に ReadOnly List(Of String) にすると外部から要素を操作されてしまう。
‘ ReadOnlyCollection または ReadOnlyReadOnlySpan などで完全な不変性を確保する。
Private ReadOnly _allowedIPAddresses As List(Of String)
Public ReadOnly Property AllowedIPAddresses As ReadOnlyCollection(Of String)

”’

Shared Sub New()
‘ 実行時に環境から取得して初期化
_dbConnectionString = Environment.GetEnvironmentVariable(“APP_DB_CONN”) _
?? “Server=localhost;Database=ProdDB;Integrated Security=SSPI;”
End Sub

”’

Public Sub New(ByVal initialIPs As IEnumerable(Of String))
‘ ReadOnlyフィールドはコンストラクタ内部でのみ書き換え可能
Me._allowedIPAddresses = New List(Of String)(initialIPs)
Me.AllowedIPAddresses = Me._allowedIPAddresses.AsReadOnly()
End Sub

”’

Public Sub IllegalMutationExample()
‘ Me.AbsoluteMaxThreshold = 10000
‘ -> コンパイルエラー: 定数に値を代入することはできません。

‘ Me._dbConnectionString = “New Connection”
‘ -> コンパイルエラー: ReadOnly フィールドに代入することはできません。

‘ 【注意】以下の操作はコンパイルを通ってしまう！参照型ReadOnlyの罠。
‘ Me._allowedIPAddresses.Add(“192.168.1.1”) ‘ 参照先が変更可能クラス（List）だと内部状態が変わる！

‘ だからこそ、外部へは ReadOnlyCollection (Me.AllowedIPAddresses) として公開するのがプロの設計。
End Sub

End Class

—

`Static` 変数：ローカルスコープに隠蔽されたグローバル状態の罠と真価

`Static` キーワードをプロシージャ（メソッド）内部のローカル変数に使用すると、その変数は「メソッドの処理が終了してもメモリ上に値が保持され続ける」という挙動を示します。

VBAやVB6のプログラミング体験から、カウンタや一時キャッシュとして安易に `Static` 変数を使う開発者が多いですが、.NET環境における `Static` 変数の正体は「特定メソッドに限定された可視性を持つ、隠蔽された `Shared`（静的）フィールド」です。

1. CLRにおける `Static` 変数の正体

VB.NETコンパイラは、ローカルの `Static` 変数を発見すると、バックグラウンドで以下のような処理を行います。

1. クラスの非公開フィールド（`Shared`）として変数を昇格させる。
2. 名前衝突を防ぐため、`$STATIC$MethodName$001$VariableName` のような特殊な難読化名を変数に与える。
3. 初回呼び出し時のみ初期化を実行するための「スレッド同期ロック機能付きブールフラグ」を自動生成する。

この仕様により、`Static` 変数はクラスのすべてのインスタンスで単一のメモリ領域を共有することになります。

2. マルチスレッド環境における致命的なリスク（Data Race）

現代の.NETアプリケーション（WebAPI、マルチスレッドデスクトップアプリ、Task並列処理）において、プロシージャ内の `Static` 変数はスレッドセーフではありません。

複数のスレッドが同時にそのプロシージャを実行した場合、内部の `Static` 変数に対する読み書きは競合状態（Race Condition）を引き起こし、値の破損や整合性の欠如をもたらします。また、暗黙的な同期処理の負荷によりパフォーマンスが著しく低下する要因にもなります。

—

アンマネージドリソース・Windows API連携におけるライフサイクル制御

業務開発の現場では、Windows API（Win32 API）の呼び出しやアンマネージドリソースのハンドリングを要求されるケースが存在します。

ここでは、`Static` 変数のメモリ保持特性を利用しつつ、スレッドセーフティの確保とメモリ leak の防止（明示的解放）を完璧に制御するアーキテクチャパターンを示します。

【実用コード】高精度タイマーAPIとリソースのライフサイクル完全制御

以下のコードは、Win32 API (`QueryPerformanceCounter`) を利用して超高精度なパフォーマンス計測を行うクラスの実装例です。`Static` 変数を安易に使わず、スレッドローカルストレージ（`ThreadStatic`）および `Lazy(Of T)` を駆使してマルチスレッド安全に最適化しています。

Imports System.Runtime.InteropServices
Imports System.ComponentModel
Imports System.Threading

”’

Public Sealed Class HighResolutionNativeTimer
Implements IDisposable

#Region “Win32 API Native Signatures”
‘ NativeMethodsクラスパターンに則り、P/Invoke定義を集約
Private Shared Class NativeMethods

Public Shared Function QueryPerformanceCounter(ByRef lpPerformanceCount As Long) As Boolean
End Function

Public Shared Function QueryPerformanceFrequency(ByRef lpFrequency As Long) As Boolean
End Function
End Class
#End Region

‘ 【Shared ReadOnly】システム起動時に確定するCPUクロック周波数。コンパイル時定数にできないためReadOnly。
Private Shared ReadOnly ClockFrequency As Long

‘ 【ThreadStatic】スレッドごとに独立したメモリ空間を確保するStaticフィールド。
‘ ローカルの Static 変数と異なり、スレッド間の競合破壊を100%防止する。

Private Shared t_lastMeasuredTicks As Long

‘ ガベージコレクション（GC）の圧迫を防ぐためのフラグ管理
Private _isDisposed As Boolean = False

”’

Shared Sub New()
Dim freq As Long
If Not NativeMethods.QueryPerformanceFrequency(freq) Then
Throw New Win32Exception(Marshal.GetLastWin32Error(), “High-resolution timer is not supported by the hardware.”)
End If
ClockFrequency = freq
End Sub

”’

”’ 前回呼び出し時からの経過ミリ秒数
Public Function GetElapsedMillisecondsAndReset() As Double
If Me._isDisposed Then
Throw New ObjectDisposedException(NameOf(HighResolutionNativeTimer))
End If

Dim currentTicks As Long
If Not NativeMethods.QueryPerformanceCounter(currentTicks) Then
Throw New Win32Exception(Marshal.GetLastWin32Error(), “Failed to query performance counter.”)
End If

‘ 初回呼び出し時のスレッドローカル初期化
If t_lastMeasuredTicks = 0 Then
t_lastMeasuredTicks = currentTicks
Return 0.0
End If

Dim deltaTicks As Long = currentTicks – t_lastMeasuredTicks
t_lastMeasuredTicks = currentTicks

‘ ミリ秒換算して返却（浮動小数点演算の精度を保持）
Return (CDbl(deltaTicks) 1000.0) / CDbl(ClockFrequency)
End Function

#Region “IDisposable Implementation (Standard Dispose Pattern)”
”’

Private Sub Dispose(ByVal disposing As Boolean)
If Not Me._isDisposed Then
If disposing Then
‘ マネージドリソースの解放（必要に応じて）
End If

‘ アンマネージドリソースの解放や、Static/ThreadStaticに関連する破棄処理をここで行う
‘ ThreadStatic変数のクリア
t_lastMeasuredTicks = 0

Me._isDisposed = True
End If
End Sub

Public Sub Dispose() Implements IDisposable.Dispose
Me.Dispose(True)
GC.SuppressFinalize(Me)
End Sub

Protected Overrides Sub Finalize()
Me.Dispose(False)
MyBase.Finalize()
End Sub
#End Region
End Class

—

極限の設計プラクティス：修飾子選定の意思決定フロー

堅牢な業務ロジックを設計するため、変数定義に直面した際は以下のフローチャートに従って修飾子を厳格に選定してください。

[ 変数を定義する ]
│
▼
【 Q1: 値はコンパイル時に確定し、絶対に変わらないか？ 】
├─ YES ──> [DLL境界を越えて参照されるか？]
│ ├─ YES ──> `Shared ReadOnly` を使用（バージョン不整合を回避）
│ └─ NO ──> `Const` を使用（IL埋め込みによる超高速度化）
│
└─ NO ──> 【 Q2: 初期化後に値を再代入（変更）する必要があるか？ 】
├─ NO ──> `ReadOnly`（または `Shared ReadOnly`）を使用
│
└─ YES ──> 【 Q3: メソッド終了後も状態を保持したいか？ 】
├─ NO ──> 通常のローカル変数（`Dim`）
│
└─ YES ──> [注意！プロシージャ内 `Static` は原則禁止]
│
├─ スレッドごとに孤立 ──> `` フィールド
└─ 全体で安全に共有 ──> `ConcurrentDictionary` ＋ `Shared` フィールド

堅牢なロジックを構築する3つの鉄則

1. プロシージャ内 `Static` は原則封印せよ
VBAのパラダイムを捨て、状態保持が必要な場合は「適切にカプセル化されたクラスのインスタンスフィールド」または「スレッドセーフに排他制御された `Shared` フィールド」へ設計を変更すること。

2. 参照型の `ReadOnly` にはカプセル化を徹底せよ
`ReadOnly arr As List(Of String)` は、配列の要素追加・変更を防げない。必ず `ReadOnlyCollection(Of T)` や `ImmutableArray(Of T)` を介して外部へ曝露すること。

3. アセンブリを跨ぐ定数は `Shared ReadOnly` 一択とせよ
設定値、接続文字列、業務ルール上の閾値など、将来的に変更の可能性が1%でもあるものは `Const` を使用してはならない。再コンパイル漏れによる静的結合の障害は、往々にして本番環境のデータ破壊として発現する。

—

結び：修飾子一つに思想を宿せ

アーキテクチャの美しさは、細部の記述に宿ります。
`Const`、`ReadOnly`、`Static` というわずか数文字の修飾子。その一つひとつが、CLRメモリ空間のスタック/ヒープのどちらにどのように配置され、CPUキャッシュにどう影響し、マルチスレッド下でどう振る舞うのか。

これらを完全に予見してコードを書くことこそが、中級者を抜け出し、システムを十全に掌握するトップエンジニアへの唯一の道です。本稿の知見を明日のリファクタリングから直ちに適用し、ビクともしない圧倒的に堅牢な業務システムを構築してください。