浮動小数点数の罠を断つ：VB.NETにおける数値丸め処理の極限と実務最適解
レガシーなVBAシステムからモダンな.NET環境への移行、あるいは基幹系システム間連携において、エンジニアが最も頻繁に踏み抜く地雷の一つが「数値の丸め処理」と「浮動小数点数のバイナリ表現に起因する誤差」だ。
「なぜ、12.375 を四捨五入して 12.38 にならないのか？」
「なぜ、金融計算で数円のズレが発生し、監査法人から指摘を受けるのか？」
本稿では、VB.NETの `Math` クラスの挙動の裏にあるIEEE 754規格の残酷な真実を暴き、現場のシステムアーキテクトが絶対に知っておくべき「誤差ゼロ」の丸め戦略を解説する。
—
1. 浮動小数点数（Double型）の宿命と `Math.Round` の罠
多くの初学者は、`Math.Round` メソッドを使えば意図した通りに四捨五入ができると錯覚している。しかし、VB.NETの標準的な `Math.Round` は、私たちが小学校で習った「四捨五入（MidpointRounding.AwayFromZero）」とは異なる動作をする場合がある。
さらに根深い問題は、引数として渡される `Double` 型そのもののメモリ上の表現にある。
‘ 【危険なコード例】浮動小数点数のバイナリ誤差
Dim val As Double = 12.375
‘ 期待値: 12.38 (小数点第2位で四捨五入)
Dim result As Double = Math.Round(val, 2, MidpointRounding.AwayFromZero)
Console.WriteLine(result) ‘ 結果はどうなるか？
コンピュータは数値を2進数で保持する。`12.375` は 2進数で正確に表せる（$12 + 1/4 + 1/8$）ため一見セーフティに見えるが、これが `12.38` のような10進数の小数になると、2進数では無限小数となり、正確に表現できなくなる。
メモリ上では `12.379999999999999…` のような値として保持されているため、丸め処理の瞬間に予期せぬ切り捨て・切り上げが発生するのだ。
銀行丸め（Banker’s Rounding）の仕様
VB.NETの `Math.Round` は、デフォルト（引数を省略した場合）では「偶数丸め（MidpointRounding.ToEven）」を採用する。これは統計的偏りを防ぐための国際規格（IEEE 754）であるが、日本の経理・財務システムではご法度であることが多い。
業務システムで「四捨五入」が求められた場合、必ず明示的に `MidpointRounding.AwayFromZero` を指定しなければならない。
—
2. 業務システムにおける鉄則：Decimal型の強制と精度の担保
金融、販売、給与計算などの基幹システムにおいて、`Double` や `Single` 型を使うこと自体がアーキテクチャ上の欠陥であると言わざるを得ない。
小数を扱う場合は、必ず `Decimal` 型 を使用すること。.NETの `Decimal` 型は128ビットの固定小数点数であり、10進数をそのままメモリ上に保持するため、バイナリ誤差を完全に排除できる。
以下に、現場でそのまま使える、誤差を完全に排除した丸め処理のラッパークラスを提示する。
実用コード：安全な丸め処理ユーティリティ
Imports System
Namespace System.Architecture.Utilities
”’
”’
Public NotInheritable Class StrictMath
‘ インスタンス化させない
Private Sub New()
End Sub
”’
”’
”’ 対象の数値（必ずDecimal型または暗黙変換可能な数値）
”’ 小数点以下の桁数
”’
Public Shared Function RoundAwayFromZero(value As Decimal, decimals As Integer) As Decimal
‘ Decimal型を維持したまま、常にJIS/一般的な四捨五入（端数五入切り上げ）を行う
Return Math.Round(value, decimals, MidpointRounding.AwayFromZero)
End Function
”’
”’
Public Shared Function Truncate(value As Decimal, decimals As Integer) As Decimal
Dim multiplier As Decimal = CDec(Math.Pow(10, decimals))
‘ 負数の切り捨て挙動（Math.Floorとの違い）に注意しつつ、確実に切り捨てる
If value >= 0 Then
Return Math.Floor(value multiplier) / multiplier
Else
Return Math.Ceiling(value multiplier) / multiplier
End If
End Function
”’
”’
Public Shared Function Ceiling(value As Decimal, decimals As Integer) As Decimal
Dim multiplier As Decimal = CDec(Math.Pow(10, decimals))
If value >= 0 Then
Return Math.Ceiling(value multiplier) / multiplier
Else
Return Math.Floor(value multiplier) / multiplier
End If
End Function
End Class
End Namespace
—
3. レガシー連携・外部API通信時のメモリと型の最適化
社内システムや外部ベンダーのAPI、あるいはレガシーなCOMコンポーネント（VBA製マクロや古いVB6製DLL）と連携する際、データ型（特に `DBNull` や `String` との暗黙的型変換）でクラッシュする事故が後を絶たない。
特にパフォーマンスやメモリ最適化が問われる極限環境では、不要なオブジェクトの生成（ボクシング/アンボクシング）を避ける必要がある。
データベース（SQL Server / Oracle）との型一致
SQL側で `DECIMAL(18, 4)` や `NUMBER(18, 4)` で定義されているカラムに対し、VB.NET側で `Double` や `Single` をバインドしてはならない。必ず `Decimal` 型として受け渡し、ADO.NETのレイヤーで型推論に頼らないコードを書くこと。
‘ 【推奨されるDB値の安全な取得と丸め】
Dim rawValue As Object = dataRow(“UnitPrice”)
If IsDBNull(rawValue) Then
‘ DBNullのハンドリング（例外コストを避けるためIsDBNullを使用）
ProcessNullValue()
Else
‘ 一度Decimalに確実にキャストしてから丸め処理を行う（ボクシング抑制）
Dim safeDecimal As Decimal = Convert.ToDecimal(rawValue)
Dim finalPrice As Decimal = StrictMath.RoundAwayFromZero(safeDecimal, 2)
‘ 処理続行…
End If
—
4. チーフアーキテクトからの提言
システムがどれほどモダンな.NET 8 / .NET 9に移行しようとも、数学的な数値の扱いの本質は変わらない。
「動けばいい」という安易なコードは、数年の運用を経て、決算期のバッチ処理で数百万単位の端数ズレという致命傷となって牙を剥く。
1. 小数を扱う変数は、原則としてすべて `Decimal` 型で統一する。
2. 四捨五入には必ず `MidpointRounding.AwayFromZero` を明示する。
3. 外部連携やUI層との境界で型変換のコストと誤差を意識する。
この3つをチームの開発規準として徹底せよ。それこそが、プロフェッショナルな業務システムエンジニアリングの極意である。
