温度変換完全ガイド：摂氏・華氏・ケルビン・ランキンの公式とコード

月曜日、天気ダッシュボードをリリースした。水曜日、トロントのユーザーからバグ報告が届く。外気温が 284 と表示されている、と。OpenWeatherMap のエンドポイントはデフォルトでケルビンを返していた。UI は摂氏を期待していた。その間のどの層も確認する責任を負っていなかった。一度の引き算漏れと、Twitter に流れる一枚の壊れたスクリーンショット。

公式だけ知って先に進みたいなら、以下の 3 つで足りる。

• 摂氏から華氏への変換公式： °F = °C × 9/5 + 32
• 華氏から摂氏への変換公式： °C = (°F − 32) × 5/9
• 摂氏からケルビンへの変換： K = °C + 273.15

この 3 つで、開発者が実際に必要とする場面のおよそ 9 割はカバーできる。残りの 1 割、つまり本稿の中身は、9/5 がどこから来るのか、なぜケルビンは決して負にならないのか、どうやって型システムに celsiusToFahrenheit(kelvinValue) をコンパイル時点で拒否させるか、そしてトロントのバグを二度と出荷しないためにはどうすべきか、という話である。数値がすぐに欲しいだけなら、読まずに 温度コンバーター を使えばよい。温度以外の単位については、より広範囲を扱う 単位変換完全ガイド を参照してほしい。

温度変換が他の単位変換と異なる理由

ほとんどの単位変換はゼロを通る線形関係で片付く。1 メートルは 3.28084 フィート、それだけの話だ。メートルを 2 倍にすればフィートも 2 倍。0 メートルは 0 フィート。ペアごとに乗算定数を 1 つ持たせれば、もう何も考えなくていい変換ライブラリが書ける。

温度はこのモデルを 1 つの重要な点で壊す。尺度同士がゼロ点を共有していないのだ。摂氏は水の凝固点にゼロを置く。華氏は 1724 年当時の食塩水の混合物にゼロを置く。ケルビンは熱力学の理論的な下限にゼロを置く。任意の 2 尺度を行き来するには、スケーリング係数とオフセットの両方が必要になる。温度は線形変換ではなく、アフィン変換なのだ。

帰結は具体的で、かつ危険だ。温度の値は長さや質量のように加算できない。20°C + 20°C は物理的にどう解釈しても 40°C にはならない。「部屋を 2 つ足して」暖かい部屋を作ることはできない。ただし、温度差を温度に加えることはできる。差は線形だからだ。この区別が原因で、2006 年に英国で起きた Medeva ワクチン事件が発生した。医薬品コールドチェーンのロガーが絶対値と差分を取り違え、数千回分のワクチンが基準外と判定された。温度のような示強性量には常にこの心的ガードレールが必要だ。単位を共有する数値が、代数まで共有しているとは限らない。

4 つの温度尺度

日常のコードで重要なのは 2 尺度（摂氏・華氏）だけだ。科学的な用途では 3 つ目のケルビンが加わる。4 つ目は米国の熱力学教科書と、それを今も参照する HVAC コードベースという、ほぼ一箇所にしか登場しない。

摂氏（°C）

アンダース・セルシウスが 1742 年に尺度を発表したときは、沸点を 0°、凝固点を 100° としていた。現在とは逆である。水の凝固点を 0°C、沸点を 1 標準気圧下で 100°C とする現代の向きは、彼の死後まもなく定着した。今日では日常温度における SI 由来単位であり、米国・バハマ・ベリーズ・ケイマン諸島・リベリアを除くすべての国で既定の尺度となっている。

2019 年の SI 再定義により、摂氏はケルビンに厳密に紐付けられた。0°C はいまや正確に 273.15 K と定義される。かつて定義だった水の凝固点は、今や測定によって得られる帰結である（百万分率で 0°C に一致するが、もはや基準ではない）。

華氏（°F）

ダニエル・ガブリエル・ファーレンハイトは 1724 年にこの尺度を提案した。0°F には特定の食塩水混合物の凝固点、すなわちダンツィヒの冬に彼が再現可能な最低温度を選び、96°F を体温とした。のちに純水の凝固点と沸点に対して再校正され、体温は 98.6°F に、凝固点は 32°F、沸点は 212°F、すなわち 180 度幅となった。

華氏は米国で気象・調理・医療用途として残っている。凝固点から沸点までの 180 度幅（摂氏では 100 度）は「日常温度における分解能が細かい」と擁護されることがある。限定的な主張ではあるが、米国のサーモスタットが 1°F 刻み、欧州のそれが 0.5°C 刻みで表示されがちな理由の説明にはなる。

ケルビン（K）

ウィリアム・トムソン、ケルビン卿は 1848 年に絶対温度尺度を提案した。現代のケルビンは SI 基本単位の温度である。2019 年の SI 再定義により、ケルビンはボルツマン定数 k_B = 1.380649 × 10⁻²³ J/K と厳密に結び付けられ、測定量ではなく定義量となった。

ケルビンには、開発者が知っておくべき癖が 3 つある。

1. 度記号を付けない。 300 K と書き、300°K とは書かない。これは 1967 年以来の SI の慣例である。
2. 絶対零度から始まる。 0 K = −273.15°C。有効なデータで負のケルビン値が現れることはない。見つかったら入力エラーとして扱う。
3. 度の幅は摂氏と同じ。 1 K の変化は 1°C の変化に等しい。温度差は両者で互換だが、絶対値は 273.15 のオフセットの分だけずれる。

温度を乗算・除算するときは常にケルビンが正解だ。熱放射（T⁴）、理想気体の状態方程式、黒体輻射の物理。負あるいはゼロ付近の摂氏値で割ると、有限値に保っておきたい物理量が吹き飛ぶ。

ランキン（°R）

ウィリアム・ランキンは 1859 年、華氏版のケルビンとしてこの尺度を提案した。絶対零度をゼロとする絶対尺度で、度幅は華氏と同じ。0°R = −459.67°F。491.67°R = 0°C。

米国の熱力学工学（HVAC の計算、石油精製、ロケットエンジンの燃焼解析）以外でランキンに遭遇することは、まずない。絶対尺度が必要だが入力データが華氏で届く、という領域である。変換は機械的だ。°R = °F + 459.67、あるいは °R = K × 9/5。現代の工学ソフトウェアの多くは内部ではケルビンのまま保持し、表示時にだけ変換する。選択できる立場なら、それが推奨だ。

温度変換の公式（6 方向すべて）

6 方向、4 尺度、6 公式。実務では摂氏中心のものを暗記し、残りは合成する。

摂氏 ↔ 華氏

°F = °C × 9/5 + 32
°C = (°F − 32) × 5/9

9/5 は、同じ 2 つの物理基準点の間で 2 尺度が張る幅の比である。凝固点から沸点までで華氏は 180 度（32 から 212）、摂氏は 100 度（0 から 100）を進む。180 / 100 = 9/5 = 1.8。+ 32 は、華氏のゼロが摂氏のゼロより 32°F 下にあるため、凝固点のゼロを揃えるためのオフセットだ。

計算例：°F = 25 × 9/5 + 32 = 45 + 32 = 77°F。

摂氏 ↔ ケルビン

K = °C + 273.15
°C = K − 273.15

スケーリングはなく、オフセットだけ。273.15 は、摂氏のゼロ（水の凝固点）から絶対零度までの数値的距離を、摂氏度で測ったものである。ケルビンと摂氏は度幅が同じなので、倍率は要らない。

華氏 ↔ ケルビン

K = (°F − 32) × 5/9 + 273.15
°F = (K − 273.15) × 9/5 + 32

これ以上短い形式はない。スケール変更もオフセット変更も必要だ。コード上はほぼ常に、摂氏経由で通すほうが綺麗になる。k = cToK(fToC(f))。書く量は減り、信頼性は上がる。コンパイラが合成を最適化してくれるので実行コストも変わらない。

ランキンの変換

°R = °F + 459.67
°F = °R − 459.67
°R = K × 9/5
K  = °R × 5/9
°R = °C × 9/5 + 491.67

491.67 は 32 × 9/5 + 459.67、つまり 0°C に対応するランキン値である。実務でこれらを合成する機会はまれだ。ランキンが必要なときは「華氏の絶対零度版の双子」として扱い、華氏かケルビンを経由すればよい。

9/5 はどこから来るのか：短い導出

2 尺度はアフィン関数 °F = a × °C + b で関係付けられる。a と b を解くには既知の校正点が 2 つ要る。慣例的なペアは凝固点と沸点だ。

• 凝固点：0°C ↔ 32°F
• 沸点：100°C ↔ 212°F

どちらも °F = a × °C + b に代入する。

32  = a × 0   + b   →  b = 32
212 = a × 100 + 32  →  a = (212 − 32) / 100 = 180 / 100 = 9/5

それだけだ。1 次方程式 2 本、未知数 2 つ、それで変換全体が決まる。幾何学的な直感としてはこうだ。摂氏とファーレンハイトの温度計を縦に 2 本並べると、華氏の温度計は摂氏に対して縦方向に伸ばされ（傾き 9/5）、上にずらされている（切片 32）。他のどの変換値も、この伸張・平行移動された直線上に乗る。

同じ導出を (0°C, 273.15 K) と (100°C, 373.15 K) で行えば、摂氏 → ケルビンが出る。傾き 1、切片 273.15。曖昧さのない校正点が 2 つあれば、どんなアフィン変換でも導出できる。数学的には温度に特別な点はない。複雑さは、他の単位では不要な「基準点 2 点の設定」にすべて押し込まれている。

−40° の交点：便利な暗記法

摂氏と華氏で同じ数値になる温度はあるだろうか。変換式で °C = °F と置く。

°C = °C × 9/5 + 32
°C − °C × 9/5 = 32
°C × (1 − 9/5) = 32
°C × (−4/5) = 32
°C = −40

つまり −40°C = −40°F。交点はちょうど 1 つ、しかもイエローナイフ、ヤクーツク、フェアバンクスの 1 月に実際に体験しうる温度である。安価なメンタルチェックにも使える。C ↔ F の変換を目検で見ていて結果が −40 付近に落ちるなら、両方の数値は互いに近いはずだ。片方が −40°C でもう片方が −72°F なら、方向を取り違えている。

モニターの横には暗記リストを貼ってある。凝固点（0 / 32）、体温（37 / 98.6）、室温（20 / 68）、沸点（100 / 212）、−40（−40 / −40）。この 5 点で、必要な妥当性チェックのほぼ全てをカバーできる。

コードでの温度変換

公式そのものは自明だ。実際のコードベースで正しく動かすために重要なのは、主に 2 点。呼び出し側が摂氏を期待する場所に華氏を渡せないようにすること、そして境界（凝固点、絶対零度、オーブン温度）での浮動小数点挙動を予測可能にすること。以下の例はすべて、完全な実行可能プログラムである。

JavaScript / TypeScript

素の JavaScript なら、関数的な変換はすぐに書ける。

const cToF = (c) => c * 9 / 5 + 32;
const fToC = (f) => (f - 32) * 5 / 9;
const cToK = (c) => c + 273.15;
const kToC = (k) => k - 273.15;
const fToK = (f) => cToK(fToC(f));
const kToF = (k) => cToF(kToC(k));
const cToR = (c) => (c + 273.15) * 9 / 5;
const rToC = (r) => r * 5 / 9 - 273.15;

console.log(cToF(100));   // 212
console.log(fToC(98.6));  // 37
console.log(kToC(300));   // 26.85

TypeScript では数値型をブランド化することで、単位の取り違えをコンパイルエラーにできる。

type Scale = 'C' | 'F' | 'K' | 'R';
type Temp<S extends Scale> = number & { readonly __scale: S };

const t = <S extends Scale>(value: number, _scale: S): Temp<S> =>
  value as Temp<S>;

const cToF = (c: Temp<'C'>): Temp<'F'> => t(c * 9 / 5 + 32, 'F');
const fToC = (f: Temp<'F'>): Temp<'C'> => t((f - 32) * 5 / 9, 'C');

const indoor = t(22, 'C');
const outdoor = cToF(indoor);   // OK: Temp<'F'>
// const broken = cToF(outdoor); // コンパイルエラー: Temp<'F'> は Temp<'C'> ではない

ブランド型のランタイムコストはゼロで、追加の決まり文句も 10 行ほど。その代わり、冒頭のトロントのバグはエディタ上の赤い波線に変わる。

Python

素の関数でも十分だが、温度を初めてログ出力した瞬間に Enum と dataclass の組み合わせは元を取る。

from dataclasses import dataclass
from enum import Enum

class Scale(Enum):
    C = "°C"
    F = "°F"
    K = "K"
    R = "°R"

@dataclass(frozen=True)
class Temperature:
    value: float
    scale: Scale

    def to(self, target: Scale) -> "Temperature":
        c = _to_celsius(self)
        return _from_celsius(c, target)

    def __str__(self) -> str:
        return f"{self.value:.2f}{self.scale.value}"

def _to_celsius(t: Temperature) -> float:
    if t.scale is Scale.C: return t.value
    if t.scale is Scale.F: return (t.value - 32) * 5 / 9
    if t.scale is Scale.K: return t.value - 273.15
    if t.scale is Scale.R: return (t.value - 491.67) * 5 / 9
    raise ValueError(f"Unknown scale: {t.scale}")

def _from_celsius(c: float, scale: Scale) -> Temperature:
    if scale is Scale.C: return Temperature(c, scale)
    if scale is Scale.F: return Temperature(c * 9 / 5 + 32, scale)
    if scale is Scale.K: return Temperature(c + 273.15, scale)
    if scale is Scale.R: return Temperature(c * 9 / 5 + 491.67, scale)
    raise ValueError(f"Unknown scale: {scale}")

body = Temperature(37, Scale.C)
print(body.to(Scale.F))   # 98.60°F
print(body.to(Scale.K))   # 310.15K

科学計算で 0.1 + 0.2 != 0.3 が監査上の問題になる場合は float を decimal.Decimal に置き換えればよい。トレードオフは速度（Decimal はおよそ 50 倍遅い）と、5/9 もまた正確な小数表現を持たないので、コンテキストを制御した Decimal(5) / Decimal(9) が必要になる点だ。ほとんどのセンサーパイプラインでは、float と表示境界での round(value, 2) で十分すぎる。

Go

Go の型システムでは、TypeScript より一歩踏み込める。名前付きの float64 型は、ランタイム表現が同じでも、別の名前付き float64 型と暗黙に混在できない。

package main

import "fmt"

type Celsius float64
type Fahrenheit float64
type Kelvin float64
type Rankine float64

func (c Celsius) ToFahrenheit() Fahrenheit { return Fahrenheit(c*9/5 + 32) }
func (c Celsius) ToKelvin() Kelvin         { return Kelvin(c + 273.15) }
func (f Fahrenheit) ToCelsius() Celsius    { return Celsius((f - 32) * 5 / 9) }
func (k Kelvin) ToCelsius() Celsius        { return Celsius(k - 273.15) }
func (f Fahrenheit) ToKelvin() Kelvin      { return f.ToCelsius().ToKelvin() }

func main() {
    room := Celsius(22)
    fmt.Printf("%.2f °F\n", room.ToFahrenheit()) // 71.60 °F
    fmt.Printf("%.2f K\n", room.ToKelvin())      // 295.15 K

    // var bug Fahrenheit = room          // コンパイルエラー
    // fmt.Println(room.ToKelvin() + 1)   // コンパイルエラー: Kelvin + 型なし int には Kelvin(1) が必要
}

コストは尺度あたりおよそ 1 行。見返りとして、ToFahrenheit は誤ってケルビン値を受け取れず、Celsius を受ける関数は呼び出し側で素の float64 を拒む。

Rust

Rust の newtype パターンは、Go と同じ保証に加えて、From/Into による安価な変換を与えてくれる。

#[derive(Clone, Copy, Debug, PartialEq)]
struct Celsius(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Fahrenheit(f64);

#[derive(Clone, Copy, Debug, PartialEq)]
struct Kelvin(f64);

impl From<Celsius> for Fahrenheit {
    fn from(c: Celsius) -> Self { Fahrenheit(c.0 * 9.0 / 5.0 + 32.0) }
}

impl From<Fahrenheit> for Celsius {
    fn from(f: Fahrenheit) -> Self { Celsius((f.0 - 32.0) * 5.0 / 9.0) }
}

impl From<Celsius> for Kelvin {
    fn from(c: Celsius) -> Self { Kelvin(c.0 + 273.15) }
}

impl From<Kelvin> for Celsius {
    fn from(k: Kelvin) -> Self { Celsius(k.0 - 273.15) }
}

fn main() {
    let body = Celsius(37.0);
    let body_f: Fahrenheit = body.into();
    let body_k: Kelvin = body.into();
    println!("{:.2} {:?} {:?}", body.0, body_f, body_k);
    // 37.00 Fahrenheit(98.6) Kelvin(310.15)
}

上に検証層を重ねることもできる。負値を拒む TryFrom<f64> for Kelvin は Result<Kelvin, TemperatureError> を返し、チェックを構築時点に押し出す。不正な状態がビジネスロジックまで到達することはない。

SQL（PostgreSQL）

温度は CHECK 制約付きで保存し、他尺度は生成カラムで導出する。そうすれば負のケルビン値は挿入時に制約違反で弾かれ、3 クエリ下流で気付くような静かなデータバグにはならない。

CREATE OR REPLACE FUNCTION c_to_f(c numeric) RETURNS numeric AS $$
    SELECT c * 9.0 / 5.0 + 32.0;
$$ LANGUAGE SQL IMMUTABLE;

CREATE OR REPLACE FUNCTION c_to_k(c numeric) RETURNS numeric AS $$
    SELECT c + 273.15;
$$ LANGUAGE SQL IMMUTABLE;

CREATE TABLE sensor_readings (
    id          bigserial PRIMARY KEY,
    recorded_at timestamptz NOT NULL DEFAULT now(),
    celsius     numeric(6, 2) NOT NULL,
    fahrenheit  numeric(6, 2) GENERATED ALWAYS AS (c_to_f(celsius)) STORED,
    kelvin      numeric(6, 2) GENERATED ALWAYS AS (c_to_k(celsius)) STORED,
    CONSTRAINT  kelvin_non_negative CHECK (celsius >= -273.15)
);

INSERT INTO sensor_readings (celsius) VALUES (22.5), (0), (100);
SELECT celsius, fahrenheit, kelvin FROM sensor_readings;
-- 22.50 | 72.50  | 295.65
--  0.00 | 32.00  | 273.15
-- 100.00| 212.00 | 373.15

-- 挿入時に拒否される:
-- INSERT INTO sensor_readings (celsius) VALUES (-300);
-- ERROR: new row for relation "sensor_readings" violates check constraint

GENERATED ALWAYS AS ... STORED は、ディスクをわずかに消費する代わりにクエリ時の速度を得る。値は読むだけで、再計算しない。大量の IoT テーブルでディスク圧が読み取り遅延より深刻なら、STORED をビューに置き換えればよい。

天気・IoT API の扱い方

温度まわりで本番に最もよく出るバグは、公式ミスではない。API の戻り値と UI 表示との単位不一致だ。実務でよくあたるプロバイダを手短に見ていく。

OpenWeatherMap は既定でケルビンを返す。摂氏が欲しければ units=metric、華氏なら units=imperial を渡す。肝心なのは、クエリパラメータを忘れるとケルビンが返ってくる点だ。temp というフィールド名に 284.15 のような数値が届くのに騙された技術者は十分多く、統合テストを書く価値がある。

Open-Meteo は既定で摂氏を返し、temperature_unit=fahrenheit を受け付ける。ケルビンのオプションはない。科学用 API ではないからだ。

Tomorrow.io と WeatherAPI は既定でメトリックだが、同じレスポンス内に異なるキーで両尺度を返す。自分のコードが参照する実際のキーを読むこと。隣のキーを読まないこと。

天気やセンサーの取り込みで私が使っているパターンはこれだ。

type Reading = {
  value: number;
  scale: 'C' | 'F' | 'K';
  source: string;
};

function normalise(raw: Reading): number /* celsius */ {
  switch (raw.scale) {
    case 'C': return raw.value;
    case 'F': return (raw.value - 32) * 5 / 9;
    case 'K': return raw.value - 273.15;
  }
}

// 取り込み時、各計測値は自分の尺度を明示的に持ち歩く。
// UI レイヤーは決して推測しない。摂氏を受け取り、ユーザー設定に応じて整形するだけ。

ここから 2 つのルールが導かれる。

1. すべての取り込み境界で、元の尺度を記録する。裸の数値がモジュール境界をまたぐことを許さない。
2. 表示レイヤーだけが、ユーザーの好みの単位に変換する唯一の場所である。

二重変換、つまり 2 つのレイヤーが別々に「正規化」してしまうケースも、頻発バグの定番だ。バックエンドが書き込み時にケルビンを摂氏へ変換する。それを知らないフロントエンドが読み取り時に同じ - 273.15 を適用する。ユーザーの画面には −251°C 付近の温度が出る。直し方はテストを増やすことではない。正規化の責任者を 1 人に絞ることだ。

IoT では、生のセンサーデータが ADC カウントとして届き、校正曲線（10kΩ の NTC サーミスターなら Steinhart–Hart 式）で温度に変換される必要があることが多い。温度尺度の変換は、校正後の値に対してその後で行う。この 2 つのフェーズを混ぜると、温度らしい形をしていながら 30% ほどずれた数値ができあがる。

よくある落とし穴と回避法

以下の 6 つは、実際の本番コードベースで繰り返し見てきた。自分のコードと見比べてみてほしい。

公式の方向を間違える

最もよくある症状は、37°C の乳児の発熱を表示しておきながら、それを重篤アラートとして扱うアプリだ。実際に起きたのは、API が 37°F を返し、カラム名がそう呼んでいたので誰かが celsius とラベル付けし、医療閾値のロジックが摂氏スケールで比較した、というストーリー。防ぎ方は、変数名ではなく型に単位を担わせることだ。

温度を示量的に扱う

averageTemperature は意味がある。sumTemperatures には意味がない。集計 SQL に SUM(temperature_c) があれば、どこかが間違っている。おそらく欲しいのは AVG か、稀に積分系の度日指標だろう。温度は示強性量である。2 つ足して意味のある結果が返ってくると期待してはいけない。

浮動小数点の丸め

JavaScript で (37 * 9 / 5) + 32 を計算すると 98.60000000000001 になり、98.6 にはならない。IEEE 754 の倍精度を使う言語はすべて同じ挙動だ。選択肢はこうだ。

• .toFixed(2)（または各言語の相当物）で表示して、それ以上は追わない。
• 監査に耐える精度が必要なら、十進ライブラリ（decimal.js、Python の Decimal、BigDecimal）を使う。
• 整数のデシ度（37.0 の代わりに 370）として保存し、表示時にだけ 10 で割る。

UI 表示なら toFixed(2) でほぼ常に正解。丸め誤差が累積する請求系や規制系では十進数を使う。

負のケルビンを入力検証で弾く

ケルビンは物理法則上、非負である。{ "tempK": -10 } を含むリクエストボディは常に不正だ。境界（JSON Schema、Pydantic、Zod、CHECK 制約）で弾き、ビジネスロジックの奥深くで処理しないこと。唯一の例外である「負の絶対温度」を扱う量子系は、統合するような API には出てこない。出てくる案件に携わっているなら、自分で承知しているはずだ。

UI とログに単位ラベルがない

sensor 42: 37 と書かれたログ行は、半年後には無価値だ。それは摂氏？ 華氏？ 生の ADC カウント？ 常に sensor 42: 37°C と書くか、{ "sensor": 42, "value": 37, "unit": "celsius" } のように構造化する。ディスクは安く、午前 3 時の本番トリアージは高くつく。

タイムゾーンと温度の混同

旅行アプリにまれに出荷されるバグがある。ユーザーがタイムゾーンをまたぐと、コードがタイムスタンプ付きフィールドをすべて親切にずらしてしまうのだ。温度計測値まで含めて。温度はタイムゾーンを気にしない。計測値に付くタイムスタンプにはタイムゾーンのロジックが必要だが、計測値本体には不要だ。別フィールドに保ち、別の変換パイプラインを通すこと。

暗算のショートカット

コンバーターを開けない場面のために。

摂氏から華氏（概算）： 2 倍して 30 を足す。20°C → 70°F（実際 68）。30°C → 90°F（実際 86）。0〜40°C の範囲で誤差 2〜3°F 以内、つまり窯の中以外で体験するほぼすべての温度で実用的だ。

華氏から摂氏（概算）： 30 を引いて 2 で割る。80°F → 25°C（実際 26.7）。60°F → 15°C（実際 15.6）。精度帯は同じ。

摂氏からケルビン： 273 を足して丸める。0.15 K を失うが、物理実験室以外の温度計の精度を下回る。

覚えておく価値のある基準点 2 つ： 20°C = 68°F ≒ 293 K、そして 100°C = 212°F = 373.15 K。この 2 つからの線形補間で、どんな見積もりも十分な精度になる。

この手早いルールは、旅行、料理の下ごしらえ、天気予報には使える。コードや規制申請に入れる数値には、厳密な公式を使うか、無料の温度変換ツール を開いて正確な値をコピーすること。

参照表

日常の温度

場面	摂氏	華氏	ケルビン
家庭用冷凍庫	−18°C	0°F	255.15 K
凝固点	0°C	32°F	273.15 K
冷蔵庫	4°C	39°F	277.15 K
室温	20°C	68°F	293.15 K
体温	37°C	98.6°F	310.15 K
発熱判定	38°C	100.4°F	311.15 K
真夏日	35°C	95°F	308.15 K
水の沸点	100°C	212°F	373.15 K

調理・オーブンの変換

オーブン設定	摂氏	華氏
低温・長時間	125°C	257°F
保温	150°C	302°F
中火焼き	175°C	347°F
標準焼き（ケーキ）	180°C	356°F
ロースト	190°C	374°F
高温ロースト	200°C	392°F
強火ロースト	220°C	428°F
ピザ・パン皮	250°C	482°F

米国のレシピでは 350°F をレシピ本によって 175°C もしくは 180°C に丸める。正確な値は 176.67°C だ。どちらでも問題ない。家庭用オーブンは ±5°C より良い精度で温度を保てないからだ。

科学的な極値

現象	ケルビン	摂氏
絶対零度（理論的下限）	0 K	−273.15°C
宇宙マイクロ波背景放射	2.725 K	−270.425°C
液体ヘリウム（沸点、1 気圧）	4.2 K	−268.95°C
超伝導転移（YBCO）	93 K	−180.15°C
液体窒素（沸点）	77 K	−196.15°C
深宇宙の陰影部	~40 K	~−233°C
ドライアイス（昇華）	194.65 K	−78.5°C
太陽の表面	5,778 K	5,504.85°C
太陽の中心	1.57×10⁷ K	1.57×10⁷ °C*
トカマクプラズマ（ITER 目標）	1.5×10⁸ K	~1.5×10⁸ °C*

*この規模では、273.15 K のオフセットは丸め誤差でしかなく、摂氏とケルビンは事実上同じ値を示す。

FAQ

摂氏から華氏への変換式は？

摂氏に 9/5（または 1.8）を掛け、32 を足します：°F = °C × 9/5 + 32。例えば 25°C × 1.8 + 32 = 77°F。乗数は凝固点から沸点までの 2 尺度の幅の比 180:100 を反映し、32 は異なるゼロ点を揃えるためのものです。

華氏から摂氏への変換式は？

華氏の値から 32 を引き、5/9 を掛けます：°C = (°F − 32) × 5/9。72°F なら (72 − 32) × 5/9 = 40 × 5/9 ≈ 22.22°C。先に引き算、次に掛け算。順序を逆にすると間違った答えが出ます。

摂氏と華氏が等しくなる温度は？

ちょうど −40 度です。変換式で °C = °F と置くと °C = °C × 9/5 + 32 となり、これを解くと °C = −40 が得られます。2 尺度が同じ数値を示す唯一の温度で、実在する寒波の目安にも、変換方向のバグに対する妥当性チェックの基準にも使えます。

焼き菓子用に 350°F を摂氏に変換するには？

350°F はおよそ 176.67°C に当たります。ヨーロッパのレシピではこれを 180°C に、米 → メトリックの換算表の多くは 175°C に丸めます。家庭用オーブンではどちらでも機能します。その温度帯の安定度は丸め誤差より悪いからです。精度が必要な場面では 温度コンバーター で正確な値を取得してください。

100°F は摂氏で何度？

100°F ≈ 37.78°C です。平熱（37°C / 98.6°F）をわずかに超える値で、軽度発熱の目安としてしばしば挙げられます。医療ガイドラインが発熱の閾値とするのは通常 38°C / 100.4°F なので、100°F は境界線ですが、臨床的に有意とまでは言えません。

なぜ絶対零度は −273 ではなく −273.15°C なのか？

2019 年の SI 再定義でボルツマン定数が厳密に固定され、−273.15°C が絶対零度の丸め近似ではなく厳密に計算された値になったからです。2019 年以前は摂氏のゼロが水の三重点に結び付けられており、0.15 は測定から得られていました。現在は定義により厳密です。

コードでケルビンを使うべき場面は？

温度を乗除したり冪乗したりするとき、つまり黒体放射（T⁴）、理想気体の計算、反応速度など。ケルビンは負にならないため除算が安定します。温度差については摂氏とケルビンは互換です（5 度の変化は両者で同じ）。

2026 年でもランキンは使われているか？

はい、ただし限定的です。米国の機械・HVAC・航空宇宙工学では、他のすべての入力が華氏である熱力学サイクル解析で今もランキンを使います。これらの領域と米国を除けば事実上使われていません。汎用ソフトウェアを書くなら、ランキンのサポートは安価な保険ですが、主役になることはめったにありません。

SQL クエリで温度を変換するには？

公式をインラインに書くか、GENERATED ALWAYS AS カラムを使います。例：SELECT celsius * 9.0 / 5.0 + 32.0 AS fahrenheit FROM readings。9 と 5 ではなく 9.0 と 5.0 と書くことで、ほとんどの方言で浮動小数点演算を強制できます。整数除算は黙って切り捨てます。CHECK (celsius >= -273.15) を加えて、挿入時に不正な値を拒否しましょう。

摂氏から華氏への暗算で一番簡単な方法は？

摂氏の値を 2 倍して 30 を足します。22°C × 2 + 30 = 74°F（実際 71.6°F）。0〜30°C の範囲で誤差およそ 2°F 以内で、気象と屋内温度のほぼすべてをカバーします。逆方向は、華氏から 30 を引いて 2 で割ります。

温度コンバーターが 37°C に対して 98.599999 を返すのはなぜ？

9/5 = 1.8 は 2 進浮動小数点で厳密に表現できないため、37 × 9 / 5 + 32 は 98.6 ではなく 98.60000000000001 となるからです。これは IEEE 754 の挙動であり、バグではありません。表示には toFixed(2) を使うか、末尾桁の精度が業務に効くなら十進数ライブラリに切り替えてください。

浮動小数点の問題を避けるために温度を整数で保存できる？

はい。デシ摂氏（温度の 10 倍）として保存します。37.0°C は 370、22.5°C は 225。整数演算は厳密で、表示境界でだけ 10 で割ります。このパターンは組み込みシステムや、ディスクと CPU が効いてくる大量時系列データベースで一般的です。

API レスポンスに単位のない数値があるときは？

そうしないでください。すべての温度フィールドは、フィールド名（temp_celsius、temp_k）または兄弟の unit フィールドで単位を明示するべきです。自分が利用者で API がそれを提供しないなら、前提をコード中に大きく明記し、API の既定が変わったら壊れる契約テストを書いてください。

4 尺度すべてでの水の沸点は？

標準大気圧（1 気圧、101.325 kPa）下で 100°C = 212°F = 373.15 K = 671.67°R です。圧力が影響します。デンバーの標高では水はおよそ 95°C で沸騰し、エベレスト山頂ではおよそ 71°C に近づきます。沸点は圧力依存の量であり、普遍定数ではありません。

温度は他の数値と異なる浮動小数点の挙動をする？

いいえ。温度値は他の浮動小数点値と同じように振る舞います。実務上の落とし穴は、変換式に含まれる 5/9 と 9/5 の係数が変換ステップごとに丸め誤差を導入する点です。200〜400 付近のケルビン値なら精度は十分。表現可能な倍精度の縁に近いマイナス摂氏値でも精度は保たれます。本当の落とし穴は、連続する変換が小さな誤差を積み上げることです。1 回だけ変換し、正規形で保存してください。