JSONとAPI — ブラウザ以外の相手に返す

ただし JSON は型が薄く、文字列・数値・真偽値・null・配列・オブジェクトしかありません。「64bit の整数」という型はありません。DB の id が 64bit 整数だとして、JSON の数値のまま返すとどうなるか。実機で確かめました。

$ node -e 'console.log(JSON.stringify({id: 9007199254740993})); console.log(JSON.parse("9007199254740993")); console.log(Number.MAX_SAFE_INTEGER); console.log(9007199254740993 === 9007199254740992); console.log(BigInt("9007199254740993").toString())'
{"id":9007199254740992}
9007199254740992
9007199254740991
true
9007199254740993

1行目に注目してください。渡したのは …993 なのに、出てきたのは …992 です。大事なのは、JSON.stringify が丸めたのではないことです。リテラルが評価された時点で、すでに …992 になっています。4行目の true がその証拠で、異なる2つの整数リテラルが等しいと判定されています。

3行目が Number.MAX_SAFE_INTEGER です。ECMA-262(2026-09-16 時点のドラフト §21.1.2.6)の定義はこうです。

The value of Number.MAX_SAFE_INTEGER is 9007199254740991𝔽 (𝔽(2^53 − 1)).

同じ節の Note が今の現象を述べます。

Due to rounding behaviour necessitated by precision limitations of IEEE 754-2019, the Number value for every integer greater than Number.MAX_SAFE_INTEGER is shared with at least one other integer. Such large-magnitude integers are therefore not safe, and are not guaranteed to be exactly representable as Number values or even to be distinguishable from each other. For example, both 9007199254740992 and 9007199254740993 evaluate to the Number value 9007199254740992𝔽.

仕様自身が 9007199254740993 を例に挙げ、9007199254740992 になると書いています。実機と一致します。

5行目は同じ文字列を BigInt に渡した場合で、…993 が保たれます。失われるのは値そのものではなく Number という型を通ったせいだ、と切り分けられます。

実装の数値型の問題だと分かれば、別の実装なら結果が違うはずだと予測できます。同じ文字列を Python に読ませました。

$ python3 -c 'import json; print(json.loads("9007199254740993"))'
9007199254740993
$ python3 -c 'import json; print(json.dumps({"id": 9007199254740993})); print(type(json.loads("9007199254740993")))'
{"id": 9007199254740993}
<class 'int'>

…993 のままです。Python の int は任意精度で binary64 に縛られません。どちらも壊れていません。 RFC が精度を規定していない以上、両方とも準拠しています。「JSON で送れば同じ値が届く」という前提が、範囲の外では成り立たないだけです。

これは第2週『2進数 — オンとオフの並びで、なぜ数が表せるのか』で見た桁あふれの再演です。あのときの教訓は「エラーにならず、静かに間違った値が出る」でした。今回も例外は出ません。違うのは、原因がビット数の上限か浮動小数点形式の精度かだけです。