分数 ↔ 小数 コンバーター

数値の文脈こそが機微情報になる

分数・小数の変換それ自体は公共の計算です。しかし「なぜその数値を変換しているか」というコンテキストは、場合によってきわめて機微になります。医療現場では 1/4 mg → 0.25 mg のような投薬量計算、調剤棚卸でのグラム換算、工場の歩留まり計算で不良率の小数分数変換 — 数値の前後の作業文脈が漏れると、医療上のエラーや製造上の機密情報になりうる数値が外部に出ることになります。

エンジニアが Stern-Brocot 近似のような高度な機能を必要とするシーンでは、π の近似値を求めている研究メモや、暗号プロトコルのパラメータ候補値を確認していることが推測されることもあります。「計算の中間値をオンラインツールに貼り付ける」習慣は、業務上の数値が気づかないうちに外部運営者の手に渡るリスクを内包しています。

「シンプルな計算ツール」に仕込まれるトラッカーのリスク

分数・小数変換のような単純なユーティリティほど、広告 SDK や行動分析ツールを無造作に組み込まれていることがあります。利用者は「危ないツールとは思わない」から警戒せず、業務上の数値をそのまま貼り付けてしまいます。フォーム送信時にサーバー側でログを取る実装や、Google Analytics の form submit イベント計測で入力値が payload に含まれるパターンは珍しくありません。

入力した分数・小数は「どんな計算をしているか」の記録を運営者に渡しています。単発の数値は無害でも、IP アドレスや Cookie で紐づいたセッション履歴が蓄積されると、業務上の計算パターンが外部に残ります。

十進文字列パースと Stern-Brocot 木をブラウザ内で実行する仕組み

このツールは小数→分数の「厳密モード」では、入力文字列を十進文字列として直接パースします。Number.parseFloat を経由しないため IEEE 754 の浮動小数点誤差が入らず、0.1 が正確に 1/10 になります。「近似モード」では Stern-Brocot 木 / 連分数展開アルゴリズムを JavaScript で実装しており、最大分母以下で最良近似の分数を探索します。循環小数 0.(3) → 1/3 のような変換も正規表現で循環節を抽出してから正確な分数を逆算します。

これらの計算はすべてブラウザのページメモリ内で実行されます。外部ライブラリへの呼び出しも API へのリクエストも発生しません。DevTools の Network タブを開きながら変換を実行しても、ページ初期ロード後のリクエストはゼロです。

業務・学習での使いどころと注意点

医療や工学での換算、レシピの分量スケール計算、数学の宿題での確認 — 用途はさまざまですが、いずれも「手元で完結させる」ことが安全です。特に医療投薬量の計算は、桁違いのエラーが重大な結果を招くため、このツールの結果を参考にしつつ、最終確認は薬剤師や医師との確認プロセスを別途経ることをお勧めします。循環小数の () 表記は JIS 標準表記に準拠しているため、日本の教育・業務文脈での共有にも使えます。

Stern-Brocot 木と連分数 — π → 355/113 が出る理由

任意の小数を「分母が小さく誤差も小さい分数」で近似する最良の方法は、連分数展開 (Continued Fraction) です。π = 3.14159265... を連分数で書くと π = 3 + 1/(7 + 1/(15 + 1/(1 + 1/(292 + ...)))) となり、途中で打ち切った値が 3, 22/7, 333/106, 355/113, 103993/33102, ... という最良有理近似列を生成します。355/113 (Milü, 祖沖之 5 世紀) が驚くほど精度が高い (誤差 < 0.0000003) のは、次の係数が 292 と非常に大きいためで、これは π という無理数の「数論的に偶発的」な性質です。

本ツールの近似モードは内部で Stern-Brocot 木 と等価な再帰アルゴリズムを使い、[low, high] の有理数区間を探索しながら、mediant = (a+c)/(b+d) を取って次の候補を絞り込みます。連分数展開と Stern-Brocot 木は同じ最良近似列を生成することが数論的に証明されており、JavaScript 上では BigInt を使わずに Number 精度の範囲 (分母上限 100 万程度) で安全に動きます。「分母上限」を設定するのは、近似精度と分数の見やすさのトレードオフをユーザーが選べるようにするためで、1000 までで止めれば日常用途、100 万 まで広げれば数学的に最良の近似が得られます。

IEEE 754 と循環小数 — 0.1 + 0.2 ≠ 0.3 を厳密モードが回避する仕組み

0.1 を IEEE 754 double 形式 で表すと、実際には 0.1000000000000000055511151231257827021181583404541015625 という 2 進無限循環の打ち切り値になります。これが 0.1 + 0.2 = 0.30000000000000004 という有名なバグの原因で、Number.parseFloat("0.1") を一度でも経由すると、もとの 1/10 という有理数情報は永久に失われます。本ツールの厳密モードは入力文字列 "0.1" を直接十進パースし、分子 1, 分母 10 を作ってから gcd で約分するため、IEEE 754 の落とし穴を完全に回避します。

循環小数の処理は別のロジックです。0.(3) = 1/3 のような循環節を持つ十進表記は、x = 0.333..., 10x = 3.333..., 10x − x = 3, x = 3/9 = 1/3 という代数操作で厳密分数に戻せます。本ツールは正規表現で循環節 (N) を抽出し、分母 = (10^循環桁数 − 1) × 10^非循環桁数、分子 = 非循環部 と循環部 を組み合わせた整数 で逆算します。たとえば 0.16(6) = 1/6 は 非循環 = 16, 循環 = 6, 分母 = (10^1 − 1) × 10^2 = 900, 分子 = (16 × 10 + 6) − 16 = 150 で 150/900 = 1/6 と既約化されます。JIS の循環小数表記 0.1̇6̇ や上点付き .6̇ を (6) 表記で代替しているのは、入力欄でアクセス可能な ASCII 文字だけで完結させるためです。レシピでの分量スケーリングなら recipe-unit-convert と組み合わせると ml と分数表記が一気通貫で扱え、確率や歩留まりを百分率に直したいときは percent-calc を使うと入力値をブラウザの外に出さずに処理できます。