金融システムにおけるVBAの死角：Double型を駆使した瞬間にシステムは崩壊する
レガシーシステムの最前線で幾多の修羅場をくぐり抜けてきたエンジニアなら、一度は目撃したことがあるはずだ。「`0.1 3 = 0.30000000000000004`」という、あの悪名高き浮動小数点演算の誤差である。
一般の事務用マクロであれば「誤差の範囲」で片付けられるかもしれない。だが、それが億単位の金銭を扱う金融系計算ツール、あるいは厳密な端数処理が法律で義務付けられている税務・会計システムであった場合、この数微小な誤差は致命傷となる。監査法人からの指摘、顧客からの信頼失墜、そして夜間バッチの残高不一致による全社的な阿鼻叫叫。
VBAにおいて、この悪夢を根絶するために用意されているのが `Currency`型 と、バリアント型（VarType）の裏でひっそりと息を潜める `Decimal`型 である。
本稿では、IEEE 754倍精度浮動小数点数（`Double`）の呪縛を断ち切り、実務で即座に使える堅牢な金融系計算エンジンを実装するための極限の知見を公開する。
—
1. なぜ `Double` 型は金融計算で使ってはいけないのか
コンピュータは内部で数値を2進数（Binary）として表現する。人間が日常的に使う10進数（Decimal）の小数（例: `0.1`）は、2進数では循環小数になる。これを有限のビット数（`Double`の場合は符号1ビット、指数11ビット、仮数52ビット）で表現しようとすると、必ず丸め誤差が発生する。
Sub CheckDoubleError()
Dim dblVal As Double
dblVal = 0.1 3
‘ 期待値は 0.3 だが、結果は…
Debug.Print dblVal ‘ 0.3
Debug.Print dblVal = 0.3 ‘ False (!)
Debug.Print dblVal – 0.3 ‘ 5.55111512312578E-17 (!?)
End Sub
このわずか `5.55E-17` の誤差が、累計計算や税率計算、複利計算のループの中で雪だるま式に膨れ上がる。IF文の比較条件（`= 0.3`）が突然偽（False）を返し、業務ロジックが意図しない分岐へ流れる原因はここにある。
—
2. 救世主 `Currency` 型：VBAが隠し持つ10進数固定小数点
VBAの `Currency` 型は、実は 8バイト（64ビット）の整数型 である。
内部的には、実際の金額の値を 10,000倍した整数 として保持している。つまり、小数点以下4桁までの精度をハードウェアレベルの整数演算で保証する、極めて優れた固定小数点型（Fixed-point）である。
- データサイズ: 8バイト
- 有効範囲: `-922,337,203,685,477.5808` から `922,337,203,685,477.5807`
- 最大のメリット: 小数点以下の計算において、浮動小数点演算特有の誤差が絶対に発生しない。
実務での活用上の注意点
`Currency` 型は高速で非常に扱いやすいが、唯一の弱点は「小数点以下が最大4桁まで」に固定されている点である。為替レートの細かい換算（例: `1USD = 148.23456 JPY` のような5桁以上の精度）や、厳密な利息計算の途中で5桁目以降の保持が必要な場合には精度不足に陥る。
—
3. 真の精度を求めるなら `Decimal` 型（Variant内包）
`Currency` 型の4桁制限を超える高精度な計算、あるいは端数処理の厳密なルール（四捨五入、切り捨て、JIS丸めなど）を完全に制御したい場合、VBAでは `Decimal` 型 を使用する。
しかし、VBAの変数宣言構文には `Dim x As Decimal` という直接的なキーワードが存在しない（VB.NETには存在する）。VBAで `Decimal` を使うには、`Variant` 型に `CDec` 関数でラップして格納する という特殊なイディオムを用いる。
- データサイズ: 14バイト（Variantのオーバーヘッドを含むとさらに消費）
- 有効範囲: 小数点以下28桁までの10進数精度
Sub CalculateWithDecimal()
Dim decVal As Variant
‘ CDecを使ってVariantをDecimal型として初期化
decVal = CDec(0.1)
decVal = decVal 3
Debug.Print decVal ‘ 0.3
Debug.Print decVal = 0.3 ‘ True
Debug.Print TypeName(decVal)’ Decimal
End Sub
パフォーマンスとメモリのトレードオフ
`Decimal` 型は、CPUのネイティブな整数・浮動小数点レジスタで直接処理できないため、VBAのランタイム（OLEAUT32.DLLのVariant演算ルーチン）ソフトウェア層で計算が行われる。そのため、数百万件のループ内で `Decimal` を多用すると、`Double` や `Currency` に比べて実行速度が著しく低下する。
【アーキテクチャ設計の黄金律】
- 通常の金額計算、税金計算（小数点2〜4桁以内）: `Currency` 型 を採用し、極限のパフォーマンスを死守する。
- 為替レート、金利の多段階乗算、巨大な数値を扱う財務諸表計算: `Decimal`（Variant）型 を採用し、精度を最優先する。
—
4. 【実践】厳密な端数処理を実装した金融系計算エンジンの全コード
実務の現場でそのままコピペして利用できる、通貨換算と税率計算、四捨五入（JIS丸め回避の算術四捨五入）を実装したクラスモジュール風の標準モジュールコードを提示する。
Option Explicit
‘ =========================================================================
‘ モジュール名: mFinancialCalculator
‘ 概要: 浮動小数点誤差を完全に排除した金融計算エンジン
‘ 著者: チーフアーキテクト
‘ =========================================================================
‘ 算術丸め（四捨五入）を行う汎用関数
‘ VBAのRound関数は「銀行丸め（偶数丸め）」を行うため、金融実務では不適切であることに注意せよ。
Public Function PreciseRound(ByVal Value As Variant, Optional ByVal DecimalPlaces As Long = 0) As Variant
Dim Factor As Variant
Dim Shifted As Variant
Factor = CDec(10 ^ DecimalPlaces)
‘ 正負を考慮した算術四捨五入ロジック
If Value >= 0 Then
Shifted = Int(Value Factor + CDec(0.5))
Else
Shifted = Fix(Value Factor – CDec(0.5))
End If
PreciseRound = Shifted / Factor
End Function
‘ 税抜金額から税込金額を算出し、指定桁数で切り捨て・四捨五入を行う関数
Public Function CalculateTaxIncluded(ByVal Amount As Currency, ByVal TaxRate As Currency, Optional ByVal Mode As String = “Floor”) As Currency
Dim RawTotal As Variant
‘ Currency型同士の掛け算は高速かつ安全
RawTotal = CDec(Amount) (CDec(1) + TaxRate)
Select Case UCase$(Mode)
Case “ROUND”
CalculateTaxIncluded = CCur(PreciseRound(RawTotal, 0))
Case “FLOOR”
CalculateTaxIncluded = CCur(Int(RawTotal))
Case “CEILING”
CalculateTaxIncluded = CCur(-Int(-RawTotal))
Case Else
Err.Raise 9999, “CalculateTaxIncluded”, “無効な丸めモードが指定されました。”
End Select
End Function
‘ 実行テスト用プロシージャ
Public Sub RunFinancialEngineTest()
Dim BaseAmount As Currency
Dim Rate As Currency
Dim Result As Currency
BaseAmount = 1234567.89 Currency型は小数点以下4桁まで保持可能
Rate = 0.1 ‘ 10%
Result = CalculateTaxIncluded(BaseAmount, Rate, “ROUND”)
Debug.Print “— 金融計算エンジン テスト結果 —”
Debug.Print “基準金額 (Currency): ” & Format$(BaseAmount, “#,
0.00″)
Debug.Print “税込金額 (四捨五入): ” & Format$(Result, “#,
0″)
‘ 型の整合性確認
Debug.Print “計算結果のデータ型: ” & TypeName(Result)
End Sub
—
5. レガシー環境・システム間連携におけるリスクマネジメント
Excel VBAで計算した正確な金額データを、外部のSQL Server、Oracle、あるいはCSVやJSONを介して基幹系システムへ連携する際、以下の罠が待ち受けている。
1. Variant(Decimal) のシリアライズ問題:
VBAの `Variant(Decimal)` は、ADOなどを通じてデータベースへ書き込む際、ドライバによっては正しく認識されず、精度の切り詰めや型不一致エラー（Type Mismatch）を引き起こすことがある。
対策: データベースへパラメーターとして渡す直前に、明示的に `CCur()` で `Currency` 型にキャストするか、文字列（String）へ変換して送信する設計にせよ。
2. Excelシート上での表示フォーマットの罠:
VBA内部でどれほど厳密に `Currency` や `Decimal` で計算していても、それを `Range.Value` を通してワークシートへ書き戻した際、セルの表示形式（NumberFormatLocal）が標準のままだと、Excelの自動型推論や浮動小数点の表示仕様に引っ張られ、ユーザーに誤解を与える見た目になることがある。
対策: 金額を書き込むセルレンジには、必ずコード側から `.NumberFormatLocal = “#,
0″` などの書式を明示的に適用すること。
—
チーフアーキテクトからの最終提言
「たかがマクロ、されどマクロ」。そう考えて適当な `Double` 型で金額計算を実装した瞬間から、そのシステムは技術的負債の塊となり、いつか必ず爆発する時限爆弾を抱えることになる。
プロフェッショナルなエンジニアたる者、扱うデータの性質（物理量なのか、金銭なのか、確率なのか）を見極め、適切なデータ型を選択する義務がある。
今すぐあなたのVBAコードベースを開き、`Double` で金額を計算している箇所がないか確認しなさい。そして、今日から `Currency` と `Decimal` を使いこなす真のエンジニアへと脱皮するのだ。
