カラーコンバーター — HEX, RGB, HSL & OKLCH

カラーコンバーターとは？

// sRGB → linear → XYZ D65 → OKLAB → OKLCH
// References: W3C CSS Color 4 §11-15, Ottosson 2020 (https://bottosson.github.io/posts/oklab/)
// Worked example: #3b82f6 (Tailwind blue-500)

const srgb = [0x3b, 0x82, 0xf6].map(v => v / 255); // [0.231, 0.510, 0.965]

const toLinear = (v) => v <= 0.04045 ? v / 12.92 : Math.pow((v + 0.055) / 1.055, 2.4);
const lin = srgb.map(toLinear); // gamma-decoded linear-sRGB

// linear-sRGB → XYZ D65 (CSS Color 4 §15.1 matrix)
const [lr, lg, lb] = lin;
const x = 0.4124564 * lr + 0.3575761 * lg + 0.1804375 * lb;
const y = 0.2126729 * lr + 0.7151522 * lg + 0.0721750 * lb;
const z = 0.0193339 * lr + 0.1191920 * lg + 0.9503041 * lb;

// XYZ D65 → LMS (Ottosson 2020 matrix), cube-root, → OKLAB
const l_ = Math.cbrt(0.8189330101 * x + 0.3618667424 * y - 0.1288597137 * z);
const m_ = Math.cbrt(0.0329845436 * x + 0.9293118715 * y + 0.0361456387 * z);
const s_ = Math.cbrt(0.0482003018 * x + 0.2643662691 * y + 0.6338517070 * z);
const L = 0.2104542553 * l_ + 0.7936177850 * m_ - 0.0040720468 * s_;
const a = 1.9779984951 * l_ - 2.4285922050 * m_ + 0.4505937099 * s_;
const b = 0.0259040371 * l_ + 0.7827717662 * m_ - 0.8086757660 * s_;

// OKLAB → OKLCH (Cartesian to polar)
const C = Math.sqrt(a * a + b * b);
const H = (Math.atan2(b, a) * 180 / Math.PI + 360) % 360;
console.log(`oklch(${L.toFixed(3)} ${C.toFixed(3)} ${H.toFixed(1)})`);
// → oklch(0.629 0.193 263.4)

主な機能

カラーコンバーター代替の比較

カラー変換の例

#3b82f6

#FF5733

#FF6347

oklch(0.7 0.25 30)

#767676

#FF6347

hsl(220 70% 50%)

#3b82f6

カラーコンバーターの使い方

1. 1

   任意の形式で色を貼り付けるか入力する

   9 つの形式フィールド（HEX、RGB、HSL、HSV、HWB、CMYK、OKLCH、OKLAB、Named）はすべて直接編集可能です — クリックする「Convert」ボタンはありません。Figma から hex を貼り付ける、Tailwind 設定から `oklch()` 値を入力する、古いスタイルシートから `hsl()` を投入する、あるいは `tomato` のような CSS 名前付きカラーを入力することもできます。入力中にインクリメンタルに解析されるので、書きかけの値が有効な形式としてコミットされるまで他のフィールドは吹き飛びません。無効な入力には静かなインラインエラーが付き、有効な入力はグリッド全体を更新します。

2. 2

   9 つの形式が即座に更新される

   内部の真実の源は OKLCH（知覚的に均一、色域非拘束）で、他のすべての形式はキー入力ごとにそこから導出されます。今入力中のフィールドはカーソル位置を保ったまま — 他の 8 つのフィールドだけが再レンダリングされます。これにより、OKLCH の L チャネルを直接編集しながら、hex、RGB、HSL、CMYK のすべてがリアルタイムで動く様子を、カーソルを失わずに見られます。変換の数学はすべて JavaScript で、モダンブラウザに搭載されているのと同じ OKLAB プリミティブを使います。

3. 3

   ビジュアル探索にピッカーを使う

   形式グリッドの下には saturation-lightness の四角（現在の色相に対する S+L を設定するために任意の場所をドラッグ）、色相スライダー（カラーホイールを回転）、アルファスライダー（透明度を設定）があります。Chromium 系ブラウザ（Chrome、Edge、Brave）では **Eyedropper** ボタンがネイティブの `EyeDropper` API を起動します — 画面上どこでも（ブラウザウィンドウの外も含めて）クリックして、そのピクセルの色をサンプルできます。Safari と Firefox はまだ API を出荷していないため、これらのブラウザではボタンは非表示になり、SL 四角 + 色相スライダーが主要なピッカーとして残ります。

4. 4

   色域とコントラストを一目で確認する

   3 つの色域バッジ（**sRGB**、**Display P3**、**Rec.2020**）は、現在の色がそれぞれの空間の再現可能範囲に収まっているかを示します — OKLCH で作業していて、どのディスプレイがその値を正確に描画するかを知りたいときに有用です。コントラスト行は、白と黒の両方に対する WCAG 2.1 比に加えて、APCA Lc スコア（将来を見据えた WCAG 3 指標）を表示します。Pass / fail のバッジ（AA、AAA）もインラインで出ます。色が sRGB 色域外なら、**Snap to sRGB** ボタンが収まるまで chroma を縮小します。

5. 5

   プラットフォームのネイティブ構文でコピーする

   9 つの形式フィールドそれぞれに **Copy** ボタンがあります — 1 クリックでクリップボードに値が乗り、ラベルが一瞬「Copied!」に切り替わるのでコピー成功がわかります。ピッカーの下の **Copy as code** セクションは、5 つのプラットフォーム向けにすぐ貼り付けられるスニペットを生成します: CSS カスタムプロパティ、Tailwind v4 `@theme` トークン、SwiftUI `Color(red:green:blue:)` リテラル、Jetpack Compose `Color(0xFF...)` 定数、Flutter `Color(0xFF...)`。URL ハッシュ（`#hex=...` または `#oklch=...`）も更新されるので、正確な色へのライブリンクを共有できます。

よくあるカラー変換の間違い

HSL のパレットが知覚的に均一だと仮定する:
hsl(220 50% 30%) → hsl(220 50% 60%) → hsl(220 50% 90%)
画面上で間隔が不均一に見えます。

知覚的に均一なランプには OKLCH を使う:
oklch(0.30 0.10 220) → oklch(0.60 0.10 220) → oklch(0.90 0.10 220)
画面上で間隔が均等に見えます。

本ツールの CMYK 出力を直接印刷に出す:
hex #FF6347 → cmyk(0%, 61%, 72%, 0%)
印刷結果が濁ったり過飽和に見えることがあります。

元の hex を印刷業者に送る:
hex #FF6347 → 業者の刷版で ICC 変換させる
画面の色により近い印刷結果になります。

Lc 60 = WCAG 4.5:1 のふりをする:
APCA Lc 60 → 「これは AA を通る」
同じペアの WCAG 2 比は 3.8:1（AA 失敗）かもしれません。

両指標を独立してチェックする:
AA 本文テキスト準拠のために WCAG 2 比 ≥ 4.5:1、かつ
現実の読みやすさのために APCA |Lc| ≥ 75。
両方が通る必要があり、片方が他方の代用にはなりません。

シェードに HSL の L をステップ:
hsl(220 50% 30%) / hsl(220 50% 60%) / hsl(220 50% 90%)
90% は白っぽく見え、30% は 60% との差より遥かに暗く見えます。

シェードに OKLCH の L をステップ:
oklch(0.30 0.10 220) / oklch(0.60 0.10 220) / oklch(0.90 0.10 220)
各ステップが同じ視覚ギャップに見えます。

8 桁の hex をレガシーパーサーにコピー:
#FF573380 → パーサーが切り捨て → #FF5733（アルファなし）
50% の透明度が静かに失われます。

ターゲットが 8 桁の hex をサポートするか確認するか、rgba() を使う:
モダンな CSS には: #FF573380（8 桁 hex）
レガシーサポートには: rgba(255, 87, 51, 0.5)（常にサポートされる）
明示的なアルファ構文が静かな切り捨てを避けます。

すべての OKLCH カラーをデフォルトで sRGB にスナップ:
oklch(0.7 0.25 30) → スナップ → oklch(0.7 0.18 30)
P3 ディスプレイは理由もなく 30%+ の彩度を失います。

まず Display P3 バッジを確認する:
P3 に収まる: 広色域の値を維持し、@supports で sRGB フォールバックを追加
P3 を超える: そのとき sRGB にスナップ
広色域ハードウェアにその仕事をさせましょう。

このツールを使う人

Tailwind v4 の OKLCH トークンに移行するフロントエンド開発者

Tailwind v4 は 2024 年にデフォルトパレットを OKLCH に標準化しました。古い HSL や hex ベースのデザインシステムを移行するということは、数百のブランドカラーを OKLCH に変換することを意味します。各 hex を貼り付け、OKLCH 出力をコピーし、`@theme` ブロックに投入します。ライブの色域バッジが sRGB を超える色をフラグするので、Display P3 ディスプレイ向けに広色域の値を残すかどうかを判断できます。

Figma カラーを iOS / Android に翻訳するデザイナー

Figma はデフォルトで hex をエクスポートしますが、iOS は SwiftUI の `Color(red:green:blue:)` リテラルを、Android は Jetpack Compose の `Color(0xFF...)` 定数を欲しがります。Figma の hex を一度貼り付ければ、iOS エンジニアには SwiftUI スニペット、Android エンジニアには Compose スニペットをコピーできます — どちらも各プラットフォームが期待する厳密な構文ですでに整っており、トレーサビリティのために元の hex がコメントに保持されます。

印刷校正を準備するデザイナー（CMYK 近似）

ブランドカラーを名刺に印刷する必要があるとき、CMYK 近似は適切な ICC 変換の前に印刷所と共有するクイック見積もりを与えてくれます。ブランドの hex を貼り付け、CMYK パーセントをコピーして、簡易見積もりのためプリンターに送ります — 最終的な色合わせは、特定の刷版に対するプリンターの ICC プロファイル対応変換に委ねてください。

WCAG と APCA を検証するアクセシビリティエンジニア

WCAG 2.1 は今日の規制標準（ADA、EAA、Section 508）、APCA Lc は提案中の WCAG 3 の後継です。両指標を並列表示することで、デザイナーは本文テキストの色が白に対して WCAG 4.5:1 を満たすか、続いて APCA Lc 75 もクリアするかを、1 画面で検証できます — 2 つの別々の計算機を行き来する必要はありません。

色空間の概念を教える教育者

9 フィールド同時表示は色空間の関係を見える化します。OKLCH 値を入力して、L の意味が空間ごとに違うため HSL がどう漂うかを見る。色相スライダーをドラッグして hex、RGB、CMYK がすべて更新されるのを見る。chroma を sRGB の外に押し出して色域バッジが赤くなる様子を示す。本ツールは大学レベルのグラフィックスや HCI コースのための、それ自身が教室デモになります。

最も近い CSS 名前付きカラーを見つけるブランドマネージャー

マーケティングコピーが「トマト色のアクセント」と言っているのに、実際のブランド hex が `#FF6347` の場合、Named フィールドは `tomato (exact)` を返します — CSS 仕様で `tomato` がまさにそれに解決されるためです。近似 hex の場合、フィールドは最も近い名前付きカラーと OKLAB での ΔE 距離を返します — ドキュメント、本文、カジュアルな色命名に有用です。

レガシー HEX パレットを OKLCH に変換する Web 開発者

古いサイトでは、50 色のブランドパレットが hex として CSS カスタムプロパティに定義されていることがあります。OKLCH に移行すれば、ブランドチームが同じランプを知覚的に均一な空間で表現できます。各 hex を貼り付け、OKLCH 出力をコピーして変数定義に差し替えます。下のティント/シェードパネルは、出荷前に得られたランプが視覚的に均等であることを検証できます。

デザイントークンを文書化する OSS メンテナー

デザイントークンのドキュメントでは、同じ色を複数の構文で表示する必要があるのが普通です — CSS コードブロック用の hex、仕様表用の OKLCH、本文の言及用の名前付きカラー。同時フィールド表示なら、メンテナーは 3 つの別々の変換を再実行することなく、1 回ですべてをコピーできます。共有可能な URL ハッシュもあるので、貢献者は GitHub Issue で議論中の正確な色にリンクできます。

カラー変換の数式とアルゴリズム

内部の真実の源としての OKLCH

本ツールは正規の色の値を内部で OKLCH の 3 つ組として保持します。すべての編集可能フィールドはキー入力ごとにその 3 つ組から表示値を導出し、ユーザーの編集はまず 3 つ組を更新してから他の 8 フィールドの再レンダリングをトリガーします。これは HSL や sRGB をピボットとして経由するコンバーターを悩ませるステップごとの浮動小数点ドリフトを解消します。OKLAB ではなく OKLCH を選んだのは意図的です — 極形式は Hue を安定軸として保持するため、色相スライダーをドラッグしても誤ってグレーをクロスフェードすることがありません。Björn Ottosson の 2020 年の論文に従えば、OKLAB の知覚的均一性こそが、これをモダンな色数学のリンガフランカとして扱う最大の論拠です。

行列の出典（W3C CSS Color 4 + Ottosson 2020）

コードベースのすべての変換行列は一次資料に明示的に紐づけられています。sRGB ↔ 線形 sRGB の区分的ガンマ関数は W3C CSS Color 4 §11.2（`v <= 0.04045 ? v/12.92 : ((v+0.055)/1.055)^2.4`）。線形 sRGB ↔ CIE XYZ D65 の 3×3 行列は CSS Color 4 §15.1。XYZ D65 ↔ LMS 行列と OKLAB の立方根ステップは、Ottosson のリファレンス実装 `https://bottosson.github.io/posts/oklab/` から、公開されたままの形で取り入れています。行列は再計算も再導出もしません — 仕様のリファレンスベクトルと同じ出力を保つために逐語的にコピーしています。

単純な CMYK 公式と ICC の但し書き

本ツールの CMYK 出力は、標準的な教科書公式 `K = 1 - max(R, G, B); C = (1-R-K)/(1-K); M = (1-G-K)/(1-K); Y = (1-B-K)/(1-K)` を正規化済みの sRGB 値に適用します。これは意図的な近似です。本当の印刷精度には、特定の刷版・インク（例: US Web Coated SWOP v2、Fogra39、Japan Color 2011）・用紙に対する ICC プロファイル変換が必要で、それはチャネルを 5〜15% シフトさせ得ます。CMYK フィールドは目に見える但し書きとともに表示しており、ユーザーが本ツールの値を直接刷版に出すことを防ぎます。出力は見積もりの健全性チェックとして扱い、納品物としては扱わないでください。

チャネル範囲チェックによる色域検出

ターゲット空間（sRGB、Display P3、Rec.2020）に対して、その空間のプライマリへ変換後、すべてのチャネルが `[-ε, 1 + ε]` に入っていれば色域内と判定します。ここで `ε = 1e-7` は境界付近の浮動小数点ノイズを吸収する値です。あるチャネルが範囲を超えると、その空間の色域バッジは赤になります。これにより、`oklch(0.7 0.4 30)` のような広色域 OKLCH 色が sRGB 外で P3 内と報告される一般的なケースを捕捉でき、どのディスプレイが色を正確にレンダリングするかが分かります。チェックはキー入力ごとに実行されます。

Chroma 減縮スナップアルゴリズム

Snap to sRGB は Chroma 軸で二分探索を行います: 現在の L と H を固定し、`C ∈ [0, 現在の C]` の範囲で sRGB 変換が色域内に収まる最大の C を探します。探索は最大 30 回反復（精度 ~10⁻⁹）で、視覚的な精度には十分以上です。これは CSS Color 4 §13 で説明されている情報提供的な色域マッピングアルゴリズムに一致します — 明度と色相を保ったまま chroma だけを下げるので、スナップ後の色は同じ色相ファミリーとして識別できます。RGB チャネルを直接クリップしないのは、それが色相を目に見えて歪めるためです（特に青）。

Brettel + Machado の CVD 行列

色覚特性シミュレーションは 2 つの公開行列ファミリーを使います。3 種の 2 色覚 — protanopia、deuteranopia、tritanopia — は Brettel-Viénot-Mollon 1997 行列を線形 RGB 上で適用します（ガンマ復号 → 行列適用 → ガンマ符号化）。3 種の異常 3 色覚 — protanomaly、deuteranomaly、tritanomaly — は重症度 0.66 の Machado-Oliveira-Fernandes 2009 行列を使います。これは典型的な異常 3 色覚患者に対応します。全色盲と部分全色盲は rec601 輝度重み（`0.299R + 0.587G + 0.114B`）でグレースケール投影します。8 種すべてのシミュレーションが色の変更ごとにレンダリングされます。

WCAG 2 vs APCA: いつどちらを使うか

WCAG 2.x（現行標準）は相対輝度から対称的なコントラスト比 `(L1 + 0.05) / (L2 + 0.05)` を計算します。通常本文テキストの目標は 4.5:1、AAA は 7:1。2026 年時点でアクセシビリティ監査の法的コンプライアンスの下限です。APCA（Accessible Perceptual Contrast Algorithm）は提案中の WCAG 3 後継 — 極性に敏感（明地に暗文字は暗地に明文字とは違うスコア）で、人間の知覚的可読性とより相関し、本文テキストの目標は `|Lc| ≥ 75`。両指標を 1 つの行に出すことで、デザイナーはコンプライアンスのために WCAG 2 を、現実の読みやすさのために APCA を、2 つの別々の計算機を行き来せずに達成できます。

カラー変換のベストプラクティス

デザインシステムトークンには OKLCH を、レガシーには HEX を優先する

2025 年以降に出荷するあらゆる新規デザインシステムでは、ブランドカラーとパレットランプを OKLCH で定義してください。L 軸が知覚的に均等なランプを自動で与え、Chroma 軸は hex では符号化できない広色域の色をアドレッシングできます。古いブラウザ向けには `@supports not (color: oklch(0 0 0))` やビルド時 PostCSS で hex フォールバックを残してください。ただし OKLCH をトークンストアの正規の値にしてください。数千もの既存 hex 変数を持つレガシーシステムは、計画的な移行までは hex のままで構いません — 何の理由もない変更は避けましょう。

CMYK 出力は近似として扱い、印刷業者と確認する

本ツールが提示する CMYK 数値は、ICC プロファイル変換ではなく、単純な sRGB ベースの公式です。概算見積もりや社内比較には使ってください。本番の印刷ランの前には、CMYK 近似ではなく元の hex を印刷業者に送り、特定の刷版・インク・用紙に対する独自の ICC 変換をしてもらってください。適切な変換による 5〜15% のチャネルシフトが、近似をそのまま出荷すると鮮明な赤を濁ったオレンジに容易に変えてしまいます。

将来を見据えたアクセシビリティに APCA Lc を使う

WCAG 2.x は今後数年は規制の下限で在り続けるでしょうが、APCA が標準の進む方向です。新しいデザインでは、WCAG 2.1 の下限と並行して、本文テキストで `|Lc| ≥ 75`、大きいテキストで `|Lc| ≥ 60` を狙ってください。APCA は WCAG 2 の対称比が見逃す読みやすさの問題を捕捉します — 特に明るい背景上の細いストロークのテキストで、WCAG の比は問題なく見えるのに、通常の読み距離で文字が事実上消えるようなケースです。

広色域カラーを Display P3 色域チェックに通す

モダンな Apple ハードウェア（iPhone、iPad、2017 年以降の MacBook）を対象にしていたり、HDR を意識したコンテンツを出荷するなら、ブランドカラーを OKLCH で定義し、Display P3 バッジを使って sRGB を超えても P3 に収まるかを検証してください。広色域の色は P3 ディスプレイで目に見えてより飽和して見え、sRGB 専用画面ではブラウザの chroma 圧縮で滑らかに劣化します。観客全員がレガシーディスプレイにいると確信できない限り、事前に sRGB へスナップしないでください。

OKLCH のトーンで知覚的に均一なシェードを取得する

ブランドカラーに対して 50/100/200/.../900 のランプを生成するときは Tones パネルを使ってください。C と H を固定したまま L を等間隔でステップさせます。結果は知覚的に均等なランプで、400 と 500 の間の視覚ギャップが 500 と 600 の間のギャップと同じに見えます。同じ均等性を HSL ランプで手動チューニングするのは色ごとに数時間の作業ですが、OKLCH ではそれが無料で手に入ります。

タブを越えた色マッチには Eyedropper を控えめに使う

EyeDropper API（2026 年時点で Chromium 限定）は、ブラウザ外も含む画面のどこをクリックしてもそのピクセルの色をサンプルできます。スクリーンショット、動画フレーム、他アプリの UI からの色マッチに有用です。結果は最終値ではなく出発点として扱ってください — 画面レンダリングはソースファイルとは異なるカラーマネジメントを適用することがあります。正規のブランドカラーは、スクリーンショットからスポイトするのではなく、デザインのソース（Figma、Sketch、ブランドガイドラインの PDF）から hex を取得してください。

共有可能なパレット決定のために `#hex=...` URL をブックマークする

現在の色は自動的に `#hex=...` または `#oklch=...` として URL ハッシュに符号化されます。URL をコピーし、Slack スレッドや GitHub Issue に貼り付けると、開いた誰もが同じ色に着地します。「ブランドの青」が特定の OKLCH の 3 つ組を意味する必要があるデザインレビュースレッドに便利です。ハッシュは変更ごとに更新されるので、アドレスバーの URL は常にライブの現在の色 — それをブックマークすれば後で特定のパレットに戻れます。

よくある質問