OKLCH 色空間でデザイナーが実務で詰まる 3 点

結論 — OKLCH は便利だが、見え方の直感はチームで揃え直す必要があります

結論を先に書きます。OKLCH は L（明度）・C（彩度）・H（色相）が知覚距離（人の目で感じる差）と素直に対応する色空間で、Tailwind v4 のデフォルトパレットでも採用されました。一方で、これまで #3b82f6 のような sRGB の hex で色を決めてきたチームにとっては、見え方の予想が一度ズレます。私自身も AetherEchoes のカラートークンを OKLCH に寄せる時、最初の 3 日は「思った色にならない」を繰り返しました。

本記事では数学側ではなく実装側から、私が詰まった 3 点を整理します。元ネタは nekotrack 氏の OKLCH 色差改善記事 で、CIEDE2000 と比較した精度評価が丁寧です。私は精度の数字ではなく、Figma で色を組んだ後に CSS に落としたとき何が起きるか、の側を書きます。

Tailwind v4 で OKLCH が default になった文脈

まず文脈から押さえます。Tailwind CSS v4 は同梱パレット（bg-blue-500 などのプリセット色）を OKLCH 表記で再定義しました。@theme で独自トークンを書くときも、推奨表記は oklch(0.72 0.15 250) のような 3 値です。

以前の Tailwind v3 までは内部表現は HSL や hex でした。v4 でこれが OKLCH に切り替わった理由はシンプルで、HSL では H を回しても L の知覚が一定にならないからです。例えば HSL で hsl(0 80% 50%) の赤と hsl(240 80% 50%) の青を並べると、青の方が明らかに暗く見えます。OKLCH は L を一定にすると明度の見え方も揃うので、ダークモード反転やホバー色の生成が機械的に書けます。私が AetherEchoes で --surface-elevated のような派生トークンを oklch(from var(--surface) calc(l + 0.04) c h) 形式で書けているのは、この性質のおかげです。

ここまでは OKLCH の良い側面です。問題はこの先にあります。

ハマり 1: グラデーションの色かぶり — 中点で灰色になる

要点を先に書きます。OKLCH 補間（CSS の in oklch）で青から黄色のグラデーションを引くと、中点が灰色っぽく濁ります。これは OKLCH の H が円環なので、最短経路を計算すると経路上で C が一度落ちるためです。

私が最初にやって失敗したのは、Hero セクションの帯を linear-gradient(in oklch, oklch(0.72 0.15 250), oklch(0.85 0.18 90)) で書いたケースです。Figma で見た青→黄の鮮やかな帯が、CSS で書くと中央でうっすら灰色のベルトを挟む形になりました。当時の私は CSS の側を疑って 1 時間検証ツールを行き来した後、ようやく OKLCH 補間の挙動だと気付きました。原因が分かれば「そりゃそうだ」なのですが、最初の遭遇では脳が拒否します。

対策は 2 つあります。1 つ目は in oklch longer hue を指定して経路を反対回りに倒し、暖色側を通すこと。2 つ目は中間色を手で 1 つ挟むことです。私は後者を選びました。CSS は linear-gradient(in oklch, oklch(0.72 0.15 250), oklch(0.78 0.16 200), oklch(0.85 0.18 90)) のように 3 stop にして、中点に L と C を高めの緑をひと粒置く形です。これで Figma の見た目とほぼ揃いました。CSS Color Module Level 4 仕様の ok-lab セクション でも、補間モードの選択は意図的に行うことを推奨しています。

ハマり 2: 中間色のくすみ — L が高いほど C の上限が下がる

要点を先に書きます。OKLCH では L を 0.9 のような明るい値に上げると、表現できる C（彩度）の上限が物理的に下がります。これを知らずに L を上げると、思ったよりくすんだ色になります。

これは Display P3 や sRGB のガマット（表示可能な色の範囲）と OKLCH 球の交点の問題で、白に近づくほど鮮やかな色は存在しません。当たり前といえば当たり前で、現実の光でも真っ白でかつ純粋な原色は同時に存在しません。理屈は理解できますが、Figma の HSB スライダで「L=95、S=100」のような攻めた値に慣れていると、OKLCH に翻訳した瞬間に「あれ、思ったより灰色じゃないか」と感じます。私のコードは過去の私が書いたとは思えないほど Lightness を盛りがちなので、ここで何度もぶつかりました。

対策は oklch.com のカラーピッカー を Figma の隣に置いて、C の限界を見ながら詰めるのが結局速いです。ピッカーは L を上げると右側の Chroma スライダの実効レンジが縮むので、視覚的に「ここ以上は出せない」が分かります。私は明るい背景色を作るときは oklch(0.97 0.02 H) を上限値の目安にして、それ以上 C を要求しない運用にしました。これで「Figma では鮮やかなのに CSS で灰色」の事故は止まりました。

ハマり 3: ブランド色の引き算 — sRGB の青と OKLCH の青は同じ青ではない

要点を先に書きます。既存ブランドの hex を OKLCH に変換すると、見た目は同じでも派生色（hover / disabled / 反転）が hex 派生と違う方向に動きます。「同じブランド色をベースに OKLCH で書き直そう」とすると、ホバー色だけが妙に冷たくなる事故が起きます。

私は AetherEchoes のブランド色を hex で #3b82f6 相当からスタートし、OKLCH で oklch(0.65 0.19 254) に置きました。基準色は揃います。問題は「ホバー時に 4% 暗く」のルールで、hex の HSL 派生だと L 軸が知覚と一致しないため、青系では暗くした時に H が紫寄りに見えます。一方 OKLCH の L 派生は、青を暗くしても青のままです。これは技術的には OKLCH が正しいのですが、デザインレビューでは「これまでのホバー色と感じが違う」と指摘される側になります。

私の対応は単純で、ブランド色だけは 2 系統並べることにしました。--brand を OKLCH で持ち、--brand-legacy を旧 hex で残して、UI の細部（影 / ボーダー）は legacy 側を参照する暫定運用です。半年くらいで legacy を捨てる前提で、移行中の「違和感がない」を優先します。詳しくは私の以前の記事 Tailwind CSS v4 の @theme で色と余白を一本化する と 5 部門のカテゴリ色を決めた基準 も合わせて読むと、色トークンの考え方が補強されると思います。

私が今やっている運用 — 3 つのチェックリスト

最後に、これまでの 3 つのハマりを踏まえて、私が新しい色を追加する時に通しているチェックリストを置きます。

• グラデーションを引いたら、Chrome の DevTools で実物をスクリーンショットして Figma 側と並べて見る
• L > 0.9 を使う時は oklch.com で C の上限を確認してからトークン化する
• 既存ブランド色を OKLCH 化する時は、ホバー色だけ別 hex で確認パスを通す

どれも特別な道具は要りません。Figma と DevTools と oklch.com があれば回ります。OKLCH は数学的にきれいな色空間ですが、デザインの現場では「数式の上では同じだが、目には違う」を許容する運用が結局必要です。半年使ってみて、私はこの空間そのものより、運用ルールを言語化したことの方が効いた気がします。なお、ダークモード側の派生は トークン反転だけでダークモードを実装する で別に書いているので、興味があればそちらも。