浮動小数点数の罠：なぜ 6.35.toFixed(1) は 6.3 になるのか
プログラミングにおいて、数値の丸め処理は避けて通れないタスクです。特にECサイトの価格計算や金融系のアプリケーションでは、精度が極めて重要になります。しかし、JavaScriptで 6.35 を小数点第1位まで丸めようと 6.35.toFixed(1) を実行すると、期待される 6.4 ではなく 6.3 という結果が返ってきます。
一見すると、JavaScriptのバグのように感じられるかもしれませんが、これは言語仕様の問題ではなく、コンピュータが数値を扱う際の根本的な仕組みである「IEEE 754」浮動小数点規格に起因する仕様です。本記事では、なぜこのような現象が発生するのか、そのメカニズムと正しい対処法について、フロントエンドエンジニアとして知っておくべき知識を詳細に解説します。
浮動小数点数の内部表現と精度問題
コンピュータは数値を2進数で扱います。私たちが普段使う10進数（0.1, 0.2など）は、2進数に変換すると無限小数になるものが多く存在します。例えば、10進数の 0.1 は、2進数では 0.0001100110011…（1100の繰り返し）となり、有限のメモリ空間には収まりません。
JavaScriptの数値型は「倍精度浮動小数点数（IEEE 754）」を採用しています。これは64ビットを使用して数値を保持しますが、仮数部に割り当てられるビット数は52ビットと決まっています。そのため、無限小数となる数値は、最も近い値に丸められた状態でメモリに格納されます。
6.35という数値を例にとると、この数値もまた、2進数に変換した瞬間に正確な値ではなく、ごくわずかに小さい（あるいは大きい）近似値として保持されます。この「正確ではない値」に対して丸め処理を行うため、期待値と異なる結果が出力されるのです。
6.35.toFixed(1) が 6.3 になる理由
toFixedメソッドが内部で行っている処理を掘り下げてみましょう。
1. 6.35 を IEEE 754 形式で格納しようとすると、実際には 6.3500000000000005332… のような値として保持されます。
2. しかし、別の環境や計算過程によっては、逆に 6.3499999999999996447… のように、6.35よりわずかに小さい値として保持されるケースがあります。
3. JavaScriptの丸め処理（toFixedなど）は、この「正確ではない6.35」に対して行われます。6.3499999999999996… という値は、小数点第1位まで丸めようとすると、当然ながら 6.3 に引き寄せられます。
つまり、問題の本質は「6.35」という表記が人間にとっての正確な数値であっても、コンピュータ上では「6.35ではない何か」として管理されていることにあります。toFixedは「四捨五入」のような単純なルールで動くわけではなく、内部的なバイナリ値の近似値に基づいて計算されるため、このような直感に反する挙動が発生します。
サンプルコード：事象の再現と回避策
以下のコードでは、なぜこの現象が起きるのかを可視化し、どのように対処すべきかを示します。
// 現象の再現
console.log(6.35.toFixed(1)); // "6.3"
console.log((6.35 * 10).toFixed(0)); // "64"（計算順序による違い）
// なぜ正確ではないのかを確認する
console.log(6.35.toPrecision(20));
// 出力: 6.3500000000000005329
// 正確な丸めを実現するためのアプローチ
// 1. 小数点を整数に直してから計算する（安全な範囲で）
function roundFixed(value, precision) {
const multiplier = Math.pow(10, precision);
return (Math.round(value * multiplier) / multiplier).toFixed(precision);
}
console.log(roundFixed(6.35, 1)); // "6.4"
// 2. より厳密な計算が必要な場合はライブラリを使用する
// npm install decimal.js
import { Decimal } from 'decimal.js';
console.log(new Decimal(6.35).toFixed(1)); // "6.4"
実務における回避策とベストプラクティス
実務でこのような問題に直面した際、安易な解決策（例えば「少しだけ足してから丸める」といったハック）は推奨されません。以下の指針に従うのがプロフェッショナルなエンジニアの作法です。
1. 金額計算には浮動小数点数を使用しない
ECサイトや決済システムにおいて、金額を浮動小数点数（Number型）で扱うことは厳禁です。代わりに、最小単位（日本円なら「円」、ドルなら「セント」）に換算して整数（Integer）として計算するか、BigInt型を使用してください。例えば、100.50円を扱うなら、10050銭として計算し、表示の際のみ変換します。
2. 専用のライブラリを活用する
JavaScriptの標準機能だけで精度を保証するのは非常に困難です。decimal.js や big.js といったライブラリは、浮動小数点数の問題を回避し、10進数計算を正確に行うために設計されています。これらは、金融計算が必要なフロントエンドアプリケーションでは必須のツールといえます。
3. 表示用と計算用を分ける
「表示のための丸め」と「ロジックのための計算」を混同してはいけません。計算ロジックは可能な限り高精度な型を保持し、toFixedのような「文字列化を伴う丸め」は、UIに表示する直前の最終ステップでのみ実行するように設計しましょう。
4. 許容範囲を定義する
もし科学技術計算などで精度が問題になる場合は、あらかじめ「どの程度の誤差を許容するか」を定義し、イプシロン（極小値）を用いた比較を行うようにします。
まとめ
6.35.toFixed(1) が 6.3 になる現象は、プログラミング言語の欠陥ではなく、コンピュータが数値をバイナリとして扱うという物理的な制約が生み出す必然です。この事象を「バグ」として片付けるのではなく、浮動小数点数の仕組みを正しく理解し、適切なツールと手法を選択することが、フロントエンドエンジニアとしての信頼性に直結します。
特にWebフロントエンドは、複雑な計算をクライアントサイドで完結させるケースが増えています。数値を扱う際は、「Number型は常に近似値である」という前提に立ち、常に安全な計算方法を模索してください。整数での計算、あるいは専用ライブラリの利用といった定石を使い分けることで、このような罠を回避し、堅牢なアプリケーションを構築しましょう。
コメント