はじめに

iPhoneを筆頭にスマートフォンがコモディティ化して、ウェブではユーザーも"デザインっぽい"ことを簡単にできるようになりました。一方で、デザインのプロは、長年ウェブで色を扱うことに制約を感じていた人も多いと思います。

詳しくは、座談会に参加してもらったみなさんにお話してもらう算段なのですが、人間の色覚に対して、HTMLもしくはCSSで指定する色の関数、それを映すモニターが再現できる色を考慮する必要があります。これまで、ウェブにおける色の表現でどんなことが大変だったかを伺いつつ、技術の進化によって実現可能になった、最近の色指定事情を話してもらいました。

今回は、ピクセルグリッドのスタッフの他に、KODANSHAtechでデザイナー業務を担当されている勝谷さんにも参加してもらい、座談会を行いました。

勝谷 元気さん（KODANSHAtech合同会社：デザイナー）
制作会社で広告など印刷物のデザインを経験後、ウェブ制作会社に転職。デザインだけでなく、WordPressやActionScriptでのゲームの実装など、フロントエンド周りのさまざまな経験を経て、KODANSHAtechに入社した。現在はUIデザインおよびフロントエンドの実装を主に行う。

小原 司（株式会社ピクセルグリッド：UIデザイナー）
制作会社やフリーランスで商品パッケージや広告商材など、紙媒体のデザインに携わる。その後、ウェブにも興味を持ち、エンジニアの勉強会などに参加して知識を深める。ピクセルグリッドに入社後は、UIデザインを主に行う。

矢倉 眞隆（株式会社ピクセルグリッド：フロントエンド・エンジニア）
HTML/CSSなどの仕様やブラウザについて詳しく、今回の色指定に関しても以前より興味を持つ。

進行は、編集の大塚 亜周です。

なぜ新しい色空間が必要なのか

――今回はRelative color syntax（相対的な色の構文）とCSSのoklch()関数を中心に、新しいウェブの色指定について話していきたいと思います。これは、2024-2025年の年末年始座談会「2024年のHTML/CSSの動向とこれから」でも上がった話題ですね。

まず、oklch()関数が生まれた経緯について話していきたいと思います。

矢倉：oklch()関数は、CSSに最近追加された色を指定する関数のことで、名前の通りOkLChという色空間で色を指定するものですね。

OkLCh色空間は、ストックホルム在住のゲームエンジニアのBjörn Ottossonという人が2020年にOklabという色空間の一つの形態で、最近話題となっています。

――なるほど。これまでの色空間とどう違っているのでしょうか。ちなみに、OkLChの「OK」って、「オーケー」そのままの意味で合ってますか？

矢倉：はい。OklabはCIELABという色空間を「OK」、つまり「いい感じにしたもの」ということです。

もともと、LABもLCHも、CIEが定めた国際規格*で、人間の視覚をモデル化したものです。LCH色空間では、「L」は知覚的に線形な明るさ（Lightness）、「C」は彩度（Chroma）、「H」は色相（Hue）です。

ただ、人の知覚に基づいて作られてはいたんですが、青のChroma（彩度）を上げると紫色っぽくなるとか、ちょっと問題もあったんですね。そういう問題点を解決し、さらにPCやスマホのディスプレイで使っても「OKなもの」にしたのが、OkLCh色空間で、それをCSSで使えるようにしたのが、oklch()関数です。

――これまでの色指定での課題は、どのようなものがあったのでしょうか？

矢倉：これまで、主にウェブ制作において色の指定では、コンピューターが扱える色空間としてはsRGBを使っていました。それをコードに落とし込む時は#（ハッシュ）の後16進数で0から255の8ビットの数字を3つで指定してきました。たとえば#ff0000だったら赤になるとかですね。これはウェブの初期からある色指定なので、サポート状況も良い。当然、デザインツールをはじめとするソフトウェアのカラーパレットで採用されています。

ただ、sRGBとハッシュの表記、それぞれに課題があります。

sRGBの”s”って「スタンダード」という意味でつけられたのですが、あくまで当時のモニターのスタンダード。CRTとかそれぐらいのものでも色が再現できるってことなんですよね。技術が進歩してきて、sRGBでは表示できない範囲の色も撮影できるデバイスが増えました。また、iPhoneなどではDisplay P3という、より広い色空間……発色のいいディスプレイが搭載されるようになって久しいです。こうなってくると、ウェブもsRGBに縛られる必要がないというか、逆にそれが制約になってきました。

なので、最近のCSSの色は、主に2つのアプローチから色の拡張をしています。まず一つは、新しい、より広範囲な色空間への対応。sRGB以外への色空間に対応しています。OklabやOkLChの対応が、これにあたります。

次に、#（ハッシュ）の表記の課題。RGBはRed、Green、Blueの組み合わせですが、色を考えるときに、色を少し勉強した人でなければ色を作れなかったんですよね。今ではあらゆるツールにカラーピッカーがあるので、普通の人は不便を感じることは少ないと思いますが。

一方、デザイナーが色を設計するときには、まず色相から決めていきます。しかし、RGBだと考えづらかったので、sRGB色を色相、彩度、明度で表現するhsl()関数などがCSSで採用されるようになりました。

ただ、hsl()にも課題がありました。色相、彩度、明度で色を扱えるのはいいんですが、それぞれの数値を変えたとき人の目にはしっくりこない変化をするんです。色相だけを変えたはずなのに、元の色よりも暗く見える。明度が0%から10％の変化と、80％から90％への変化が、同じ10％なのに違うとか。

これはRGBやHSLの色空間の問題で、Oklab、OkLChだとそれが起こらないように作られています。

oklch()が注目されているのは、ブラウザの実装が揃ってきたのが最近のことだからです。

• types: <color>: oklch() (OKLCH color model) | Can I use... Support tables for HTML5, CSS3, etc

OkLCh色空間だと、色を計算して決めやすいはずなので、急速に期待が高まっています。年末年始の座談会のときにも話しましたが、Relative color syntaxを使えば、その計算もとても楽にできます。

――Relative color syntaxについておさらいしておくと、矢倉さんは以前の座談会で次のように説明してくれていますね。

これはデザインシステムでいうカラースウォッチって言えばいいのかな、色を1つ決めてそれに基づいて色を作るのに便利な機能です。たとえば彩度変えたりすることもできるし、RGBだったらRの色だけ取り出してそれに数式を当てはめたりとかもできたりします。

そして、次のようなコード例を挙げてくれました。

.red-100 {
  background-color: hsl(from red h s 90%);
}
.red-500 {
  background-color: red;
}
.red-700 {
  background-color: hsl(from red h s 30%);
}

小原さんは、Relative color syntaxは「デザインするときに、思ってた近い色ができる！」って言っていましたよね。

小原：歓喜ですよ（笑）。こんなに違うんだ！ というか、こんなに安定的に出せるんだ！ っていう。

より正確に表現すると、「人間の目の仕組みと近しいもの」って感じですね。コンピューターにとっては、RGBのほうが圧倒的に扱いやすい数値です。とても規則性が高いものになってるので。色空間は立方体で、どこかを選んだら必ず色が返ってくる。計算しやすいのでコンピューター的にとても都合がいい。でも、人間の目にとっては都合が良くないんです。それを、人間が見るものなので、人間の目に都合が良いものにしていきましょうよ、ということなんじゃないかなと。

――Hueplotのような、色空間を可視化したものを見ていると、RGBとOkLChの違いがわかっておもしろいですよね。

色のトーンを保ったまま変化させる

――デザイナーの視点でいくと、ウェブにおける色指定の課題は、どのようなものがあるのでしょうか？

小原：sRGBの色空間ではトーンが揃えづらいっていうのは、さっき矢倉さんも説明してくれてたんですが、人間の視覚に沿った表記というhsl()にしても、RGBなんです。だから色相を変えても、視覚的に期待する色相の変化にならないんですよね。コンピューター的に、線形で変化しちゃうって言うんですかね……。

そもそも、色ってきれいに四角い箱の中にびっちり入ってるものじゃないので。きれいに横にずらしちゃうとトーンがずれちゃう。……っていうニュアンスをどう伝えればいいんだろう。デザイナーの人たちはわかるんですけど。

勝谷：めちゃめちゃわかります。以前、動的に色がふわっと変わるような演出を作った時に、hsl()関数で数値上は赤とか青とか色相（Hue）だけ変えて書いているのに、実際にブラウザで見ると、色味によって明るさが変わってしまうんです。デザイナーの感覚だと、色相だけ変えたなら、それが赤になろうが緑になろうが、明るさの印象は変わらないという期待値でコードを書いているのに、そうはならなくて。

小原：そうなんです、そうなんです。

矢倉：そうですね。これまでのウェブの色指定に関する課題でいうと、デザイナーのワークフローにも優しいですよね。色を1色決めて、その濃淡を変化させたり、色のトーンというか濁った感じを保ったまま別の色相に変えたいっていう思考プロセスに寄り添った拡張をしようという動きから生まれたのが、Relative color syntaxだったり、OkLCh色空間ですね。

小原：そう。そういう意味では、もう究極に求めていたもののアルゴリズムがそこにある感じですね。

勝谷：エンジニアが選ぶものだと、Tailwind CSSなどは、初期のバージョンからいくつかの色味（色相）を知覚的に均等な明暗をつけた色のパレットがあらかじめ用意してあって、たとえば「Redの100」とか「Greenの300」みたいな名前で呼び出すことができます。

この「知覚的に均等なカラーパレット」は、従来のhsl()関数などで単純に彩度や明度だけを変化するだけでは得られないものでした。

でも、oklch()がメジャーなブラウザ環境で使えるようになってきたことで、今後はそのTailwindのカラーパレットを使わなくてもよいケースがでてくるかもしれません。

ぼくがいま制作中のサイトではテーマカラーが変わる演出を実装中なんですが、それもoklch()関数が知覚的な明度・彩度を一定に保ったまま、色（色相）をコントロールできるからこそ実現できることだったりします。

――これまでの色の指定とは、どのあたりが変わるのでしょうか？

勝谷：これまでって、たとえばテーマカラーが青だったら何段階かの青を決めて、アクセントカラーも色を作って……って、パレットを用意する必要がありました。でも、oklch()関数と、Relative color syntaxを使えば、「青をこれぐらいの暗さで使う」とか、「この部分ではこの青をこういう明るさで使う」っていうことを、CSSに書けるんですよね。色相と、まあ彩度ぐらいを最初に決めておけば、その明暗のバリエーションみたいなものはカラーパレットとして用意しなくても良くなる。

小原：oklch()関数はその辺りをとても上手にやってくれそうですよね。たとえば、hoverしたときに濃くしたいみたいなときとか。いろんな色を使ってるんだけど、だいたい10%目安で安定して濃くしたいんだよねっていうときに、oklch()はすごくパワフルに使える感じがする。

昔、Sassが流行ったときに、lighten($color, $amount)、darken($color, $amount)っていう関数をSass自体が持ってたけれど、colorはRGBだから、デザイナーが期待する結果は安定的に得られなかったんですね。ある色だと汚くなっちゃったり、ある色だとあまり暗くなりきらないみたいな。デザイナーとしては、結果をコントロールできないので、安心して使えませんでした。OkLCh色空間の中でRelative color syntaxを使えるようになったことで、デザイナーが色を設計するときの考え方に沿った色指定がしやすいんじゃないかと期待しています。

デザイナーとエンジニアの無駄なやり取りを減らす

勝谷：デザインって「ちょっと明るく」とか相対的に考えることって、結構多いんですよね。

小原：多いですね。多いですね。

勝谷：oklch()関数とRelative color syntaxを使えば、「この色からこの部分だけちょっと明るさを、彩度をこれくらい変えたい」という感覚的な意図を記述できるようになる。

今、ウェブ制作の現場ではコンポーネント化してデザイナーから渡しましょうという流れがあるので、色でも同様にやりたいということが顕在化してくるだろうなと思ってます。その課題を解決できそう。

矢倉：そうですね。hoverしたときのボタンの色をカンプで指定されてたとしても、テキストの色と馴染みすぎて読みづらくなってしまったなんてことは、コード書いてる側が気づけることなんです。エンジニアからデザイナーにフィードバックをする際に「こういう風にしたらどうだろう」って、コードを書く側が埋め合わせをするようなこともたまにあります。その埋め合わせをする時に、気の利いた色を提案したくても結構難しいので、時間がかかってしまうことがあるんですよね。

今はデザインシステムを運用して、デザイントークンとして色もあらかじめ指定しておくというケースも増えていると思いますが、CSSでoklch()関数とRelative color syntaxで書けば、便利になるんじゃないかという期待がありますね。

勝谷：おそらく、コミュニケーションが少なくて済むようになるんですよね。パレットを作って渡さなくても良くなるというか。

小原：たとえば、「明度の違う青を10色作ります」ってなったときに、HEXで指定すると10色分の別々の色の値になる。それが、OkLCh色空間とRelative color syntaxを使うんだとしたら、基準の青と、そこから10%明るく、20%明るく、30%明るく、40%明るくっていう指定ができるので、エンジニアにとってわかりやすい設計になる。

色同士の相対関係が把握できるから、色味の変更や追加があっても、同じように基準色を1つ決めさえすれば、バリエーションのためのカラーパレットは必要なくなる。デザイナーが設計した色の全体像を想像しやすくなるので、たとえばテーマカラーの変更があってもエンジニアも「じゃあ基準色、1色教えてください」って、それで済んじゃうような感じ。

勝谷：基準色っていう話ができるということ自体が結構すごい。

小原：そうですね。HEXで指定した色ってそれぞれ無関係の別の色になっちゃう。”基準”という考え方が生まれないというか、デザイナーの中にしか存在しなくなってしまう。デザイナーは、パレットを作るときには基準色を置いて、そこから相対的に色を決めているんです。それをHEXで表して値にした途端に、絶対的な色指定になってしまう。デザイナーが表現したかった意図がそこで途切れちゃうんですよね。

勝谷：色のベースとそのバリエーションがどう設計されているかをエンジニアと共有できるようになると、実装時にエンジニアが色について気がついたことがあっても、うまいこと調整できるようになりそうですね。

小原：今の状態って、エンジニアからしても、デザイナーから色指定の意図を連想することができないので、気を利かせづらいと思うんですね。デザイナーが苦労してたくさん色を作ったっていうことにしかならなくて。「ここ間違ってるみたいだから、直しときました」っていうのはできない。

でも、Relative color syntaxで「なんかここだけちょっとパーセンテージおかしいぞ」というものを見つけたら、意図を聞くとか「間違ってませんか？」っていうコミュニケーションに発展できるけれど、HEXで指定されたものは「そういうものだろう」って受け入れるだけで、最終的に仕上がりのクオリティが下がってしまう。

――なるほど、デザイナーとエンジニアのコミュニケーションにも一役買いそうなんですね。では、もう少し具体的に、こういった新しい色指定方法を使っていくことについて、お話していきたいと思います。

（後編に続く）