浮動小数点演算の呪縛を断つ：金融系VBA開発におけるCurrency型とDecimal型の極限最適化
開発現場でよく見かける光景がある。Excel VBAで財務諸表、見積書、あるいは金利計算システムを作り、「よし、動いた」と担当者が胸をなでおろす。しかし、数百万行のデータを処理した瞬間、あるいは税率の掛け合わせを行った瞬間に、末尾の「1円のズレ」が頻発する。
「なぜだ？電卓と合わない」
「Excelの数式なら合致するのに、VBAを通すと狂う」
原因は明白だ。あなたが`Double`型を使って浮動小数点演算を行っているからにほかならない。
本稿では、IEEE 754規格の呪縛から脱却し、金融・会計領域において絶対にバグを出さないためのデータ型選定基準と、プロダクション環境に耐えうる堅牢な実装アーキテクチャを伝授する。
—
1. なぜ `Double` 型は金融計算で「使ってはならない」のか
プログラミング初学者は「小数点を含む数値＝`Double`」という悪しき習慣に囚われている。しかし、アーキテクトの視点から言えば、`Double`型の使用は、金融系ツールにおいては設計上の欠陥とみなされても仕方がない。
2進数浮動小数点の宿命
`Double`型（倍精度浮動小数点数）は、数値を2進数（$2のn乗$）の組み合わせで近似表現する。
人間の使う10進数の「0.1」は、2進数において無限小数（循環小数）となる。これを有限のビット数で表現しようとすると、どうしても丸め誤差（Precision Error）が生じる。
‘ 【危険なアンチパターン】
Dim a As Double
Dim b As Double
a = 0.1
b = 0.2
‘ 期待値は 0.3 だが、厳密な比較を行うと False になるか、予期せぬ誤差を含む
Debug.Print (a + b = 0.3) ‘ 結果: False または 微小な誤差を持つ数値
このわずか数ペニー、数円の誤差が、複利計算や大量の明細合算において雪達磨式に拡大し、最終的な監査で致命的な整合性エラーを引き起こす。このリスクを排除するために用意されているのが、`Currency`型と`Decimal`型である。
—
2. 武器の選定：`Currency`型 vs `Decimal`型
VBAで高精度計算を行うための選択肢は2つある。それぞれの特性を深く理解し、適材適所で使い分ける必要がある。
① `Currency` 型（推奨：圧倒的なパフォーマンスと安定性）
- 内部構造: 8バイトの整数として保持し、自動的に下4桁を小数点位置として扱う（スケーリングされた整数）。
- 有効範囲: $-922,337,203,685,477.5808$ ～ $922,337,203,685,477.5807$
- メリット:
- 処理速度が極めて高速（CPUの整数演算器を直結で利用可能）。
- 小数点以下4桁までの固定精度であれば、丸め誤差が100%発生しない。
- 実務上のほとんどの金額計算（日本円や米ドルなどの一般的な通貨）を完全にカバー。
② `Decimal` 型（高精度だが諸刃の剣）
- 内部構造: 14バイトのデータ構造＋2バイトのスケール情報を保持する128ビット10進浮動小数点数。
- 有効範囲: 小数点以下28桁までの有効数字。
- メリット:
- 非常に大きな桁数や、小数点以下5桁以上の厳密な計算（為替レートの細分化やマージン計算など）に対応。
- デメリット:
- VBAの標準の変数宣言（`Dim x As Decimal`）では直接宣言できない（Variant型のサブタイプとしてのみ存在）。
- 内部的な型変換コストが発生するため、`Currency`型に比べてパフォーマンスが劣る。
- `CDec()`関数を経由する必要があり、コードの可読性がやや下がる。
> アーキテクトの判断基準：
> 特段の理由がない限り、通常業務の金額計算はすべて `Currency` 型で実装せよ。 厳密な為替レートの掛け合わせ等で小数点第5位以下が必要な場合のみ、`CDec` による `Variant/Decimal` を限定的に採用する。
—
3. 【実践】バグを駆逐する堅牢な消費税・総額計算モジュール
それでは、実務の現場でそのまま稼働できる、`Currency`型を駆使した堅牢な消費税・金額計算ツールのコードを提示する。
このコードでは、単なる型の選定だけでなく、端数処理（切り捨て・四捨五入など）のビジネスロジックの揺らぎをも完全にコントロールしている。
Option Explicit
‘ ====================================================================
‘ モジュール名: CModFinancialCalculator
‘ 概要: 浮動小数点誤差を排除した厳密な金融・金額計算モジュール
‘ ====================================================================
‘ 端数処理モードの定義
Public Enum RoundingMode
RndTruncate = 1 ‘ 切り捨て
RndRoundUp = 2 ‘ 切り上げ
RndBankers = 3 ‘ 四捨五入（JIS丸め / 銀行家丸め）
End Enum
‘ —————————————————————-data
‘ 関数名: CalculateSubTotal
‘ 概要 : 単価と数量から小計をCurrency型で算出する
‘ ——————————————————————–
Public Function CalculateSubTotal(ByVal unitPrice As Currency, ByVal quantity As Long) As Currency
‘ Currency型同士、あるいは整数との掛け算は誤差を生じない
CalculateSubTotal = unitPrice CDec(quantity)
End Function
‘ ——————————————————————–
‘ 関数名: CalculateTaxAmount
‘ 概要 : 税抜金額と税率から消費税額を算出し、指定された方式で端数処理する
‘ ——————————————————————–
Public Function CalculateTaxAmount(ByVal subTotal As Currency, ByVal taxRate As Currency, ByVal mode As RoundingMode) As Currency
Dim rawTax As Currency
‘ 税額の生データ算出（例: 10000 0.10 = 1000.0）
rawTax = subTotal taxRate
Select Case mode
Case RoundingMode.RndTruncate
CalculateTaxAmount = Application.WorksheetFunction.RoundDown(rawTax, 0)
Case RoundingMode.RndRoundUp
CalculateTaxAmount = Application.WorksheetFunction.RoundUp(rawTax, 0)
Case RoundingMode.RndBankers
‘ VBAのRound関数は銀行家丸め（偶数丸め）を行う
CalculateTaxAmount = Round(rawTax, 0)
Case Else
Err.Raise 9999, “CalculateTaxAmount”, “無効な端数処理モードが指定されました。”
End Select
End Function
‘ ——————————————————————–
‘ プロシージャ名: ExecuteBatchBilling
‘ 概要 : 実際のシートからデータを読み込み、安全に計算して出力するメイン処理
‘ ——————————————————————–
Public Sub ExecuteBatchBilling()
Dim ws As Worksheet
Set ws = ActiveSheet
Dim lastRow As Long
lastRow = ws.Cells(ws.Rows.Count, “A”).End(xlUp).Row
If lastRow < 2 Then
MsgBox "処理対象データが存在しません。", vbExclamation, "システムエラー"
Exit Sub
End If
' 処理の高速化
With Application
.ScreenUpdating = False
.Calculation = xlCalculationManual
.EnableEvents = False
End Sub
On Error GoTo ErrorHandler
Dim i As Long
Dim unitPrice As Currency
Dim quantity As Long
Dim subTotal As Currency
Dim taxAmount As Currency
Dim grandTotal As Currency
const TAX_RATE As Currency = 0.1D ' 10% (Decimalリテラルとしての強制はできないためCurrencyで保持)
' 明細ループ
For i = 2 To lastRow
' 入力値の型安全な取得（VariantからCurrencyへの明示的キャスト）
unitPrice = CCur(ws.Cells(i, 2).Value)
quantity = CLng(ws.Cells(i, 3).Value)
' 1. 小計計算
subTotal = CalculateSubTotal(unitPrice, quantity)
' 2. 消費税計算（ここでは切り捨てを採用）
taxAmount = CalculateTaxAmount(subTotal, 0.1, RndTruncate)
' 3. 総合計
grandTotal = subTotal + taxAmount
' 結果の書き戻し
ws.Cells(i, 4).Value = subTotal
ws.Cells(i, 5).Value = taxAmount
ws.Cells(i, 6).Value = grandTotal
Next i
MsgBox "すべての計算処理が正常に完了しました。", vbInformation, "完了"
ErrorHandler:
If Err.Number <> 0 Then
MsgBox “予期せぬエラーが発生しました: ” & Err.Description, vbCritical, “致命的エラー”
End If
‘ 環境の復元
With Application
.ScreenUpdating = True
.Calculation = xlCalculationAutomatic
.EnableEvents = True
End Sub
End Sub
—
4. ファイル・データベース連携における「型安全」の罠
VBAで高精度な型（`Currency` や `Decimal`）を使用しても、外部（Excelシート、CSVファイル、SQL Serverなどのデータベース）とのデータの橋渡しで油断すると、一瞬でデータが破損する。
① Excelセルとの読み書きの落とし穴
Excelのセルは本質的に「型レス（Variant）」である。セルに数値を書き込む際、あるいはセルから読み込む際は、Excel側の自動型変換が働く。
- `Range.Value` から値を取得するとき、Excelは必要に応じて `Double` や `Long` として渡してくる。
- 対策として、必ず `CCur()` や `CLng()` 関数を用いて、VBA側の受け入れ変数の型を明示的に強制（キャスト）しなければならない。これを怠ると、暗黙の型変換により `Double` に格下げされ、精度の喪失を招く。
② データベース（ADO）連携時のスケール崩壊
SQL Serverの `DECIMAL` 型や `MONEY` 型のデータを ADO (`ADODB.Recordset`) 経由で取得する場合、VBA側で `Variant` 型として受け取ることになる。
このとき、VBA側で適切に `CDec()` や `CCur()` でラップしないまま演算を行うと、内部で自動的に `Double` に昇格（あるいは降格）させられ、データベース側の厳密な値とVBA側の計算結果に乖離が生じる。
DB連携を行うレイヤーでは、必ず型アサーションを挟む設計を徹底すること。
—
5. アーキテクトからの総括
「たかが1円のズレ」を許容するシステムは、やがて信頼を失い、組織の基盤を揺るがす。
プログラミング言語やプラットフォームの特性を理解せず、目の前の動くコードだけに終始するアプローチは、プロフェッショナルの仕事とは言えない。
- 金額を扱う変数は、惰性で `Double` にしない。
- 基本は `Currency` 型を選択し、パフォーマンスと精度のバランスを最適化する。
- 入出力の境界線（セル、外部DB、CSV）では必ず明示的なキャストを行う。
この鉄則をチーム全体で共有し、実務における計算ロジックの信頼性を極限まで高めてほしい。あなたの書くコードの背後には、常に正確なデータと、それを利用するユーザーの信頼があることを忘れてはならない。
