VB.NETのOverflowExceptionを防ぐCheckedとUncheckedコンテキスト：数値演算の限界を超える安全な計算処理
業務システムの開発現場において、数値演算のオーバーフロー（桁あふれ）ほど厄介なバグはない。
「テスト環境では正常に動いていたのに、本番稼働から数ヶ月後、データの累積によって突如としてシステムがクラッシュした」
「DBから取得した巨大な集計値と画面側の計算ロジックが一致せず、数円単位のズレが隠蔽されたまま経理処理されてしまった」
こうしたトラブルの原因の多くは、コンピュータが扱う数値型（IntegerやLongなど）の「物理的な限界」を軽視した設計にある。
VB.NETには、この数値演算の限界をコンパイラレベル、あるいはブロックレベルで厳密に制御するための強力なメカニズムが存在する。それが `Checked` と `Unchecked` コンテキストだ。
今回は、業務自動化ツールや基幹系連携プログラムを支える「堅牢な数値演算の設計思想」について、チーフアーキテクトの視点からロジカルに解説する。
—
1. なぜVB.NETのデフォルト演算は「危険」なのか？
VB.NET（およびC#）において、デフォルトの整数型演算はパフォーマンスを最優先するため、オーバーフローが発生しても例外を発生させずに silently（静かに）上位ビットを切り捨てる仕様になっている。
例えば、`Integer`型（32符号付き整数）の最大値は `2,147,483,647` である。この変数に対して単純に加算を行うとどうなるか。
Dim maxInt As Integer = Integer.MaxValue ‘ 2147483647
Dim result As Integer = maxInt + 1
Console.WriteLine(result)
このコードを実行すると、エラーで停止するどころか、結果は `-2147483648`（最小値）へとラップアラウンド（一回転）してしれっと処理が継続される。
自動化スクリプトやバッチ処理において、この「サイレント・オーバーフロー」が発生すると、データ破損の検知が極めて困難になる。数値を扱う処理において、エラーを隠蔽する挙動は百害あって一利なしだ。
—
2. Checked と Unchecked の基本構文とライフサイクル
この挙動を明示的にコントロールするのが `Checked` と `Unchecked` である。
- `Checked` コンテキスト: オーバーフローを検知した場合、即座に `OverflowException` をスローする。
- `Unchecked` コンテキスト: オーバーフローを無視し、ラップアラウンドさせる（デフォルトの挙動を明示する）。
これらは、プロジェクト全体のコンパイルオプション（プロジェクトのプロパティ ＞ コンパイル ＞ 高度なコンパイラ設定 ＞ 「整数オーバーフローのチェック」）で一括制御することも可能だが、実務においてはコードブロック単位で意図的に制御すべきである。すべてをグローバルにチェックすると、意図したビット演算などのパフォーマンスやロジックに悪影響を及ぼすためだ。
ブロック単位での制御構文
‘ Checkedブロック：安全第一。限界を超えたら即座に例外を飛ばす
Checked
Dim value1 As Integer = 2000000000
Dim value2 As Integer = 2000000000
Dim sum As Integer = value1 + value2 ‘ ここでOverflowExceptionが発生する
End Checked
‘ Uncheckedブロック：パフォーマンス優先、または意図的なラップアラウンド
Unchecked
Dim value1 As Integer = 2000000000
Dim value2 As Integer = 2000000000
Dim sum As Integer = value1 + value2 ‘ 例外は起きず、負の値になる
End Unchecked
—
3. 【実務・現場で使える】堅牢なプロダクションコード例
ファイル（CSV/Excel）からのデータインポートや、外部API、データベースからの数値集計を行う業務ツールを想定する。
「入力値が不正、あるいは想定以上に巨大であっても、システムがクラッシュせず、安全にハンドリングできる」設計を実装したサンプルコードを提示する。
Imports System
Namespace Enterprise.Automation.Calculations
Public Class FinancialCalculator
”’
”’
”’ 基幹システムからの既存金額
”’ ファイルから読み込んだ追加金額（文字列）
”’
Public Function SafeCalculateRevenue(baseAmount As Integer, additionalInput As String) As Long
‘ 1. まずパースの安全性担保
Dim parsedValue As Integer
If Not Integer.TryParse(additionalInput, parsedValue) Then
Throw New ArgumentException(“入力された数値の形式が不正です: ” & additionalInput)
End If
Try
‘ 2. Checkedコンテキストによるオーバーフローの強制検知
‘ 業務上、金額の計算ミスは許されないため、Checkedで厳密にガードする
Dim calculatedTotal As Integer
Checked
‘ ここで Integer の限界を超える可能性を検知する
calculatedTotal = baseAmount + parsedValue
End EndChecked ‘ VB.NETの構文仕様に合わせたブロック終了
Return calculatedTotal
Catch ex As OverflowException
‘ 3. 例外発生時のロジック（ログ出力、管理他へのアラート、上位型へのエスカレーション等）
System.Diagnostics.Debug.WriteLine($”[CRITICAL] 金額計算でオーバーフローを検知: Base={baseAmount}, Add={parsedValue}”)
‘ 対策：Integerの限界を超えたため、より安全な Long 型での再計算を試みる
Return SafeCalculateWithLong(baseAmount, parsedValue)
End Try
End Function
”’
”’
Private Function SafeCalculateWithLong(baseAmount As Integer, additionalInput As Integer) As Long
Checked
‘ 領域をLongに拡張して再計算
Dim longBase As Long = baseAmount
Dim longAdd As Long = additionalInput
Return longBase + longAdd
End EndChecked
End Function
End Class
End Namespace
—
4. ファイル・データベース連携における設計の急所
データベース（SQL Server, Oracleなど）やExcelファイルと連携する際、型とオーバーフローの関係で見落としがちな罠がある。
1. DBの型とVB.NETの型のミスマッチ
- データベース側のカラムが `INT`（SQL Serverでは最大約21億）であるにもかかわらず、VB.NET側で `Integer` を使ってガンガン加算処理を行い、それをそのままDBに突っ込もうとすると、DB側で `SqlException (Overflow)` が発生してバッチが異常終了する。
- 対策: 累積・集計を行う変数は、最初から `Long` (`BIGINT`) を採用するか、入力値のバリデーション段階でDBの限界値を事前にチェックする設計にすること。
2. Excel（COM Interop）自動化における数値処理
- COMオブジェクト経由でExcelセルから数値を取得する場合、`Double` 型として返されることが多い。これを `Integer` にキャスト（`CInt()`）する際、値が大きすぎると `InvalidCastException` または `OverflowException` が発生する。
- 対策: `CInt()` ではなく `Convert.ToInt32()` や `Int64.TryParse()` を用い、型変換とオーバーフローのチェックをワンセットで行うラッパー関数を共通モジュール化すべきである。
—
5. チーフアーキテクトからの提言：例外を恐れるな、隠蔽を恐れよ
「例外（Exception）が発生すると処理が重くなるから、Checkedは使わないほうがいい」という古いアンチパターンを耳にすることがある。だが、それは大間違いだ。
業務システムにおいて最も恐れるべきは、例外による処理の停止ではなく、「データが破壊されたまま静かに処理が回り続けること」である。不正なデータがDBに書き込まれ、数日後に発覚したときの修復コストは、例外ハンドリングのコードを書く手間に比べて何百倍も高い。
- 厳密性が求められる業務計算（金額、在庫数、カウンター等）には必ず `Checked` を適用する。
- グラフィック処理やビット演算など、パフォーマンスが極限まで求められ、かつオーバーフローが数学的に許容される領域でのみ `Unchecked` を選択する。
この使い分けをチーム全体で徹底し、堅牢で信頼性の高いプロダクトを構築してほしい。
