【テクニカル・上級編】VB.NETのCInt、CLng、Val関数の挙動差異とオーバーフロー対策：レガシーな数値変換からモダンなTryParseへの移行 – Visual Basic (VB / VB.NET)解析バイブル

Visual Basic (VB / VB.NET)

2026.08.25

数値変換の罠を断つ：`Val`・`CInt`の呪縛から解放されるモダン.NETアーキテクチャ

レガシーなVB6、そしてVB.NETへの移行期から連綿と受け継がれてきた「暗黙の型変換」と「数値パース処理」。
夜間バッチで突如発生する `InvalidCastException` や `OverflowException`、あるいはログにも残らずにサイレントで値を丸め込むレガシー関数の挙動に、頭を悩ませたエンジニアは数知れない。

本稿では、VB.NETにおける `Val`、`CInt`（および `CLng` 等の型変換関数）、そして現代の .NET が提供する `TryParse` パターンの本質的な挙動差異を解剖する。
単なる「使い方の違い」ではない。.NETのランタイム構造、例外送出コスト、そしてメモリ効率の観点から、プロダクション環境に耐えうる堅牢な数値変換アーキテクチャを定義する。

—

1. レガシー数値変換の深部：`Val` と `CInt` の暗黒面

まずは、VB6時代から持ち込まれた「負の遺産」が、現代の CLR（Common Language Runtime）上でいかに危険な挙動を引き起こすかを理解しなければならない。

`Val` 関数の非決定論的な挙動

`Microsoft.VisualBasic.Val` 関数は、文字列の先頭から数値とみなせる部分を抽出し、`Double` 型として返す。この関数には、堅牢なシステム開発において致命的な仕様がいくつか存在する。

1. ロケール依存（小数点文字）: OSのカルチャー設定に依存するため、小数点にカンマを使用する環境では予期せぬパース結果を生む。
2. 例外を投げない（サイレント失敗）: `”123ABC”` を渡すと `123` を返し、`”ABC”` を渡すと `0` を返す。「不正な入力」を検知できないという致命的な設計上の欠陥がある。
3. 精度の損失: 戻り値が `Double` であるため、厳密な通貨計算や巨大な整数（64bit整数など）を扱う際に丸め誤差が発生する。

`CInt` / `CLng` によるオーバーフローの脅威

一方、`CInt` や `CLng` は言語組込の型変換関数である。これらは内部で .NET の `Convert.ToInt32` や `Convert.ToInt64` にコンパイルされる。

入力が `String` の場合、文字列を数値に変換しようとするが、パースできない文字列や空文字に対しては容赦なく `InvalidCastException`（または `FormatException`）を投げる。
さらに、型が許容する範囲を超えた数値（例：`CInt(“9999999999”)`）が入力された場合、実行時エラー `OverflowException` が発生する。

> アーキテクトの視点:
> 例外（Exception）は、文字通り「例外的な状況」のためにある。ユーザー入力の不正や外部CSVのフォーマット不備といった「起こり得ることが確実なエラー」を、例外のキャッチで制御するのは、ランタイムのコールスタック走査コストを考慮しても最悪のアンチパターンである。

—

2. 3大数値変換関数の挙動比較マトリクス

実務で遭遇する入力値に対し、それぞれの関数がどのように振る舞うかを整理する。

—

3. モダナイゼーション：`Int32.TryParse` と `Try` パターンの極意

堅牢なシステムを構築するための唯一無二の解法が、`.NET Framework 2.0` 以降（当然 .NET Core / .NET 6/7/8 でも基本）で提供されている `TryParse` パターンである。

VB.NET においても、`Integer.TryParse` を用いることで、例外を一切発生させずに安全かつ高速に数値変換を行える。

実装パターン：高速で安全な入力検証ロジック

以下は、レガシーな `Val` や `CInt` を排除し、業務システムで即座に使える堅牢な拡張メソッドを内包したクラスのサンプルである。

Imports System.Runtime.CompilerServices

Public Module NumberConverterExtensions

”’

”’ 安全にIntegerへ変換する。失敗時はデフォルト値を返す。
”’

Public Function ToInt32Safe(value As String, Optional defaultValue As Integer = 0) As Integer
Dim result As Integer

‘ TryParseは例外をスローせず、Booleanの結果を返すためパフォーマンスが極めて高い
If Integer.TryParse(value, result) Then
Return result
End If

‘ ログ出力基盤へのフックをここに置くことも可能
Return defaultValue
End Function

”’

”’ 厳密な数値検証を行いながらInt64へ変換する
”’

Public Function ToInt64Safe(value As String, ByRef outValue As Long) As Boolean
‘ 64bit整数（Long）のパース
Return Long.TryParse(value, outValue)
End Function

End Module

呼び出し側のコード

Public Sub ProcessUserIput(rawInput As String)
‘ 従来: Dim val = CInt(rawInput) ‘ ここで落ちるリスクがある

‘ モダン: 拡張メソッドによる安全な取得
Dim safeValue As Integer = rawInput.ToInt32Safe(-1)

If safeValue = -1 Then
Console.WriteLine(“警告: 不正な入力値が検出されました。処理をスキップします。”)
Exit Sub
End If

Console.WriteLine($”正常な数値処理: {safeValue}”)
End Sub

—

4. パフォーマンスとメモリ最適化の深層

シニアエンジニアとして語るべきは、単なる「安全性の向上」だけではない。CPUサイクルとメモリ割り当て（Allocation）の最適化についても言及しよう。

1. 例外のスローコスト:
.NETにおいて `Exception` がインスタンス化され、スタックトレースが生成されるコストは、通常のメソッド呼び出しの数千倍から数万倍に達する。バッチ処理で数百万件のCSVを処理する際、不正なフォーマットのたびに `CInt` が例外を吐いていたとすれば、それだけで処理時間が何十倍にも膨れ上がる。`TryParse` はマネージドヒープへの例外オブジェクトの割り当てを行わないため、ゼロアロケーションに近い高速性を維持する。

2. メモリ空間と型サイズ:
`Val` 関数が返す `Double` は 8バイト（64ビット）であり、これを `Integer`（4バイト）に代失うことは、レジスタの無駄遣いだけでなく、FPU（浮動小数点演算ユニット）とALU（算術論理演算ユニット）の無駄なコンテキストスイッチを誘発する。最初から目的の型（`Integer`, `Long`）の `TryParse` を使うべきである。

—

5. レガシーシステム改修のための移行戦略（まとめ）

既存の巨大なVB.NET（あるいはVBAからの移行組）システムにおいて、すべての `Val` や `CInt` を一斉に置き換えることはリスクが高い。以下のステップで段階的なモダナイゼーションを断行せよ。

1. 静的解析ツールの導入: Roslynアナライザー等を活用し、コードベース内の `Microsoft.VisualBasic.Val` の使用箇所を全て洗い出す。
2. 境界値（インターフェース）の保護: Web APIのコントローラー、UI層からの入力を受け取るエントリポイント、CSV/DBインポーターなど、外部世界からデータが流入する「境界」において、必ず `TryParse` （または上述の拡張メソッド）に置き換える。
3. ドメイン層の純化: 内部のビジネスロジック層においては、すでに検証済みのプリミティブ型、あるいは型安全なValue Object（値オブジェクト）のみを流通させ、二度と `CInt` や `Val` を登場させない設計を徹底する。

技術の本質を見極め、脆弱なレガシーコードを駆逐すること。それこそが、我々アーキテクトが担うべき責務である。