色彩設計の基本と実践　Web UI配色からデザインシステムまで

色を変えているのに、なぜか良くならない。そんな違和感から別の色を試し、さらに周囲まで調整しているうちに、最初に何を直したかったのか分からなくなることがあります。

配色で迷い続けると、自分には色彩感覚が足りないのではないかと不安になるかもしれません。しかし、WebやUIにおける色彩設計では、直感だけに頼らず、色相、彩度、明度、トーン、面積、役割といった条件へ分けて考えられます。

つまり「センスがないから決められない」と結論づける前に、違和感を構成している要因を一つずつ確認できるのです。

本記事ではWebやUIの配色設計を中心に、印刷で起こる色の違い、アクセシビリティ、デザインシステムまで扱います。単に美しい色を選ぶ方法を覚えるのではなく、なぜその色を使うのかを説明でき、問題が起きたときに修正理由まで追える状態を目指します。

配色が垢抜けない原因と視覚的違和感

制作を進めていると、大きな破綻は見当たらないのに「あと少し何かが違う」と感じる瞬間があります。文字も画像も配置できているため、足りないものを埋めようとして新しい色を加えたくなるでしょう。

ところが、寂しさを補うために色を足すほど、華やかになるどころか画面が騒がしくなる場合があります。背景も見出しもボタンも強くなれば、それぞれが視線を求め始め、ユーザーは何を最初に見ればよいのか判断しにくくなります。

反対に、落ち着かせようとしてすべての色を弱めると、今度は重要な情報まで埋もれてしまいます。ここで起きているのは、単純な色選びの失敗というより、画面の中で各色が担う仕事を整理できていない状態だと考えられます。

配色は色の美しさを競わせる作業ではありません。背景には背景の役割があり、ブランドを示す色には別の役割があり、重要な操作へ視線を導く色にも異なる役目があります。

そのため違和感を覚えたときは、すぐ別の色へ交換するのではなく、色相が合っていないのか、鮮やかすぎるのか、明るさに問題があるのか、それとも面積が広すぎるのかを切り分けます。

「何となく変」という感覚に理由を見つけられれば、修正の範囲は急に小さくなります。これが感覚的な配色から、検証できる色彩設計へ移る最初の一歩です。

色彩設計を支える色相 彩度 明度

色彩設計の基本となるのが、色相、彩度、明度です。普段は三つをまとめて一つの色として認識していますが、制作では独立した要素として捉えると判断しやすくなります。

たとえば青がしっくりこないと感じても、青そのものを捨てる必要があるとは限りません。鮮やかすぎる青なのか、暗すぎる青なのか、周囲との明るさの差が足りないのかによって修正方法は変わるからです。

一つの色を複数の条件へ分解して見ることで、画面全体を作り直すような大きな修正を避けやすくなります。

色相で色同士の距離を考える

色相とは、赤、黄、緑、青、紫などの色味の違いです。色相を環状に並べることで、それぞれの色が近い関係にあるのか、反対側に近い関係にあるのかを把握できます。

日本色研配色体系では24色相を基本に色相関係が整理されており、色相とトーンを組み合わせながら色を体系的に捉えられます。

近い色相を組み合わせると共通性を作りやすいため、穏やかでまとまりのある配色につながります。一方、色相環の反対側付近に位置する補色関係を使えば、強い色相差が生まれ、視線を集めやすくなるでしょう。

ただし、補色を組み合わせれば自動的におしゃれになるわけではありません。鮮やかな補色同士を大きな面積で隣接させれば境界が強く感じられ、落ち着かなさやちらつきのような印象につながる可能性があります。

補色は完成された正解ではなく、強い差を生む関係です。何を目立たせたいのかを考えたうえで使うことが重要になります。

彩度で視覚的な強さを調整する

彩度は、色の鮮やかさを表す尺度です。彩度が高いほど色味が強く感じられ、低くすると灰色を含んだような穏やかな印象へ近づきます。

鮮やかな色には人の目を引きつける力があります。そのため重要な操作や通知へ限定して使用すれば効果的ですが、広い背景や多数の要素へ使うと、画面全体が常に強く主張しているように感じられるでしょう。

「この色自体は好きなのに、デザインへ置くと派手すぎる」と感じることがあります。そんなときは別の色を探す前に、彩度だけを少し下げて確認してみます。

それまで浮いていた色が、鮮やかさをわずかに調整しただけで周囲になじむ場合があります。色を捨てずに済むと分かると、制作中の焦りも少し軽くなるでしょう。

反対に、重要な部分が埋もれているなら、周囲より彩度を上げる方法があります。彩度は華やかさを決めるだけではなく、画面のどこへ視覚的な力を与えるのかを調整する要素でもあります。

明度で重さと情報階層を作る

明度は色の明るさを示します。明るい色は軽快さや柔らかさを感じさせることがあり、暗い色は落ち着きや重厚さにつながる場合があります。

同じ青でも、明るく彩度を抑えた青と、暗く濃い青では印象が大きく異なります。そのため「青は信頼感」という色相だけの説明では、実際の見え方を十分に表せません。

さらに明度は、雰囲気だけではなく情報の優先順位にも関係します。背景、本文、見出し、主要な操作領域に適切な明るさの差があれば、色相を取り除いた状態でも構造を把握しやすくなります。

明るさの違いを見ることは、情報階層を診断するための有力な方法です。しかし、WCAGの適合判定では色の相対輝度から算出されるコントラスト比を別途確認します。

感覚的に「十分違って見える」と判断することと、規格上必要な値を満たしていることには違いがあります。この二つを分けて理解しておけば、見た目の確認と基準への適合を混同しにくくなるでしょう。

トーンを揃えて配色の世界観を整える

色相を見直しても、まだ画面がばらついて見える場合があります。そのとき確認したいのが、明度と彩度を複合して捉えるトーンです。

PCCSでは、色相だけでなくトーンという考え方によって色彩を整理します。同じ赤や青でも、明るく柔らかな状態なのか、彩度を抑えた落ち着いた状態なのか、低明度で濃い状態なのかによって受ける印象は変化します。

たとえば青、緑、紫という異なる色相を組み合わせても、それぞれの彩度を抑え、近い明度の範囲へ整えれば共通した穏やかさを感じやすくなります。そこから全体を明るい方向へ寄せれば軽やかな印象を作りやすくなり、暗い方向へ寄せれば深みや重厚感のある世界観へ近づくでしょう。

反対に、低彩度で整えた画面へ一色だけ極端に鮮やかな色を入れると、その色は大きく浮かび上がります。それを意図的なアクセントとして使うなら効果的ですが、目立たせるつもりのない要素まで強く見えるなら違和感の原因になります。

色がまとまらないとき、色相を次々に交換する必要はありません。「この一色だけ鮮やかすぎないか」「この部分だけ暗すぎないか」とトーンを見直せば、元の配色を保ったまま改善できる可能性があります。

色を選び直すのではなく、同じ色を整えるという選択肢を持てるようになると、配色の迷いはかなり減っていきます。

配色比率で色の役割を分ける

配色では何色を使うかだけでなく、それぞれをどの程度の面積へ使うかも重要です。同じ赤でも、画面全体を覆う場合と小さな操作部分だけに使う場合では、存在感が大きく変化します。

実務では、ベースカラーを約70%、メインカラーを約25%、アクセントカラーを約5%とする考え方が、配色を整理するための目安として紹介されることがあります。

ただし、70対25対5はUIカラー体系そのものを定義する規格でも、守るべき絶対的な黄金比でもありません。写真の量、画面構造、ブランド表現、コンテンツの種類によって適切な割合は変化します。

この比率は、あくまで面積と視覚的優先順位を理解するための入門的なモデルとして考えると扱いやすくなります。

重要なのは数字をぴったり合わせることではありません。広い範囲を静かに支える色、デザインの印象を形成する色、限定された場所へ視線を集める色という役割へ分け、それぞれの存在感に差をつけることです。

実際のWebやUIでは、この三色だけですべての意味を表現する必要はありません。三色モデルは画面全体の色量や視覚的な強弱を理解するための出発点であり、実務では別の役割を持つ色が追加されることがあります。

ベースカラーで画面の空気を作る

ベースカラーは、背景や広い余白など、デザインの土台となる領域に使う色です。画面の大部分を占めるため、主役として目立つことより、その他の情報を自然に支えることが求められます。

小さな色見本を見て「この鮮やかな色を使いたい」と感じることはあります。しかし、同じ色を画面いっぱいに広げると、想像以上に圧迫感が出る場合があります。

これは色選びが間違っていたというより、面積によって色の存在感が変化した結果です。小さな見本を見ていたときには気にならなかった強さが、広い領域では一気に前へ出てきます。

ベースカラーには、高明度の無彩色や彩度を抑えた有彩色がよく使われます。暗い背景を中心に設計することもできますが、その場合には文字や操作要素との十分なコントラストを確保する必要があります。

ベースカラーを選ぶときは「最も好きな色」よりも「この空間で他の情報を自然に見せられる色」という視点を持つと判断しやすくなるでしょう。

メインカラーでデザインの個性を作る

メインカラーは、ブランドやコンテンツの印象を形成する中心的な色です。見出しや主要な図形、ナビゲーションなど、ユーザーの記憶に残りやすい領域へ使います。

色見本では魅力的なのに、実際のデザインへ置くと合わないことがあります。そんなとき「選んだ色が悪かった」と思い、別の候補を探したくなるかもしれません。

しかし、配色では一色だけの美しさより周囲との関係が重要です。ベースカラーとの明度差が小さければ埋もれ、彩度差が大きすぎれば意図以上に浮く可能性があります。

また、ブランドが伝えたい印象と色の質感が離れていれば、内容と見た目の間にも違和感が生まれます。落ち着きを伝えたい画面なのに、主要な色だけが極端に刺激的であれば、色とメッセージが互いに別の方向を向いてしまうでしょう。

メインカラーはベースと同じ色相から明度や彩度を展開して作ることもできますし、近接する色相を使いながらトーンを合わせる方法もあります。

いずれの場合も「きれいだから選んだ」で終わらせず、なぜその色を主要な場所へ使うのかを説明できる状態にすることが大切です。

アクセントカラーで視線を必要な場所へ導く

アクセントカラーは、画面の中で特に注目してほしい部分へ使う色です。主要な行動ボタンや重要な数値など、優先順位の高い情報へ限定して配置すると効果を発揮します。

ここで迷いやすいのが「目立たせたいものが多いから、アクセントも増やそう」と考えてしまうことです。見出しもボタンもアイコンも数字も同じ強さで目立たせれば、一つひとつの重要性はかえって伝わりにくくなります。

全員が同じ大きさの声で「こちらを見て」と主張している画面では、ユーザーはどこから見ればよいのか迷ってしまうでしょう。

アクセントには、補色関係、高めの彩度、大きな明度差などを利用できます。ただし、色そのものを極端に強くするより、周囲との差を作ると考えるほうが扱いやすくなります。

静かな配色の中なら、少し鮮やかな色を置くだけでも十分に視線は集まります。アクセントは絶対的な強さではなく、周囲との相対的な違いによって成立するからです。

なお、WebやUIでは、視線を集めるアクセントとは別に、成功、警告、エラーなどの意味や状態を伝える色が必要になることがあります。アクセントが主に視覚的な優先順位を作る色であるのに対し、こうしたセマンティックカラーは意味を一貫して伝えるために使われます。

この二つを分けて考えておけば、目立つ色をすべてアクセントとして扱う混乱を避けやすくなるでしょう。

純色と完全な黒を使うときの考え方

高彩度の色や完全な黒は、使ってはいけない色ではありません。問題になるのは、その強さが本当に必要なのかを考えずに採用することです。

鮮やかな色は短時間で目を引くため、重要な通知や行動を促す部分では有効な場合があります。一方、広い領域へ使用すると視覚的な刺激が増え、その他の情報より色そのものが目立ってしまう可能性があります。

色自体は気に入っているのに画面へ置くと騒がしい場合には、別の色相へ変更する前に彩度を少し下げて確認します。個性を残したまま周囲との関係だけを整えられることがあるためです。

完全な黒についても同様で、白い背景との間に非常に大きな差を作れるため、明確さが必要な場面では有効です。一方、柔らかな世界観を重視するデザインでは、少し明度を上げた濃いグレーや、わずかに色味を含む暗色のほうが調和する場合があります。

ただし、見た目を柔らかくすることと文字を読みにくくすることは別です。黒を弱める場合にも、可読性に必要なコントラストは確認しなければなりません。

「完全な黒を使ってはいけない」という規則を覚えるのではなく、その強さを採用する理由があるかを考えることが重要です。

RGBとCMYKの違いを制作前に考える

画面では鮮やかだった色が、印刷すると想像より落ち着いて見えることがあります。時間をかけて決めたブランドカラーほど、その変化には戸惑いを感じるでしょう。

しかし、画面と印刷では色を作る仕組みが異なります。

デジタル画面では主にRGBによって光を組み合わせて色を表現します。一方、一般的なカラー印刷ではCMYKによってインクを組み合わせます。

両者が表現できる色の範囲は完全には一致しません。そのためディスプレイ上で表現できる非常に鮮やかな色を印刷へ移すと、同じ発色を再現できない場合があります。

デジタルと紙の双方へ展開するブランドでは、完成直前になってから色を合わせようとすると調整が難しくなります。最終的な媒体を早い段階で把握し、必要であれば印刷時の再現性まで含めて色を設計することが重要です。

配色は画面の中だけで完結するものではありません。どこで表示され、どのように再現されるのかも色彩設計を決める条件になります。

アクセシビリティを配色設計の基準にする

見た目が美しくても、必要な文字を読めず、操作すべき場所を識別できなければ、機能するデザインとはいえません。

WCAG 2.2では、レベルAAにおける通常サイズのテキストについて少なくとも4.5対1、大きなテキストについて少なくとも3対1のコントラスト比が求められています。

また、達成基準1.4.11では、ユーザーインターフェースコンポーネントを識別するために必要な視覚情報や状態、コンテンツ理解に必要なグラフィックの部分など、対象となる非テキスト要素について隣接色との3対1以上のコントラストが求められます。

そのため数値だけを暗記するより「この部分が認識できなかった場合、ユーザーは操作や意味を理解できなくなるだろうか」と考えたほうが、基準の目的を捉えやすくなります。

色だけに意味を持たせない

入力エラーを赤い枠線だけで伝えていると、色の違いを認識しにくい利用者には状態変化が十分伝わらない可能性があります。

そこで色だけに頼らず、エラー内容を文章で示したり、識別できる記号や形状の違いを組み合わせたりします。色は重要な手掛かりですが、それだけで状態や意味を成立させないことが大切です。

この考え方は、特定の利用者だけを対象とした配慮ではありません。強い日差しの中で画面を見ている場合や、表示品質の低い環境でも情報を認識しやすくなります。

「色を付けたから伝わるはず」と思っていた部分が、別の環境では十分に機能しないこともあります。だからこそ、色以外の手掛かりを持たせることが、結果として多くの人に分かりやすい画面につながります。

WCAGとJISの現在地を理解する

日本国内でウェブアクセシビリティを調べると、JIS X 8341-3という規格を目にします。ここでは規格の版を混同しないことが重要です。

JIS X 8341-3:2016はISO/IEC 40500:2012との一致規格であり、その技術的内容はWCAG 2.0に対応しています。そのため、JIS X 8341-3:2016とWCAG 2.2を同じ規格として扱うことはできません。

一方、ISO/IEC 40500は2025年に改正され、WCAG 2.2と同内容のISO/IEC 40500:2025となっています。2026年8月現在、日本でもこの動きを受けたJIS X 8341-3の改正が検討されています。

現在は、既存のJIS X 8341-3:2016がWCAG 2.0相当である一方、国際規格ではWCAG 2.2相当への更新が済み、日本のJISについても次の版への移行が検討されている時期です。

デザインシステムでは色を役割として管理する

一枚のデザインだけであれば「青」「薄い青」「濃い青」といった名前でも管理できるかもしれません。しかし、画面や機能が増えると、色を直接指定するだけでは整合性を保ちにくくなります。

リンク用の青、主要な操作に使う青、見出しの青、成功を示す色、警告を示す色、エラー表示の色というように個別指定を続けていると、「なぜこの色なのか」が次第に分からなくなります。

そこでデザインシステムでは、具体的な色値と、その色が持つ役割や意味を分けて管理します。

三色構成からセマンティックカラーへ役割を広げる

ベース、メイン、アクセントという三色構成は、面積と視覚的優先順位を理解するためには有効です。しかし、実際のUIには視線誘導だけでは説明できない色があります。

成功した状態を示す色、注意を促す色、入力エラーを知らせる色などは、単に目立たせるためではなく、特定の意味を繰り返し伝えるために使われます。

そのため、デザインシステムではアクセントカラーとセマンティックカラーを分けて管理する場合があります。アクセントが「どこを見てほしいか」を支えるのに対し、セマンティックカラーは「何が起きているか」を伝える役割を持つと考えると理解しやすくなります。

三色モデルで学んだ内容が後から否定されるわけではありません。最初は面積と視覚的な強弱を理解し、その後、実際のプロダクトで必要になる意味や状態へ役割を細分化していくのです。

この流れを理解すると、配色の基本とデザインシステムが別々の知識ではなく、一つの設計思想の延長線上にあることが見えてきます。

デザイントークンで色の意味を引き継ぐ

カラーデザイントークンでは、具体的な色値を定義する層と、その値へ「主要操作」「背景」「境界」「成功」「警告」「エラー」といった意味を与える層を分けて考えます。さらに必要に応じて、個別のコンポーネントへ役割を割り当てます。

この仕組みを使うと「このボタンは青だから青を使う」のではなく、「このボタンは主要操作だから主要操作に割り当てられた色を使う」と判断できます。

同じように、エラー表示についても「赤だから使う」のではなく、「エラーという意味を持つ役割に設定された色を使う」と考えられます。

色そのものと役割を切り離しておけば、ブランドカラーを変更した場合やライトテーマとダークテーマを切り替える場合でも、個々の画面を一つずつ修正するより体系的に変更しやすくなります。

Design Tokens Community Groupは2025年10月28日にDesign Tokens Format Module 2025.10をFinal Community Group Reportとして公開しています。この仕様では、ツール間でデザイントークンを交換するための技術的な形式が示されています。

一方、この仕様はW3C Recommendationではなく、W3C Standards Track上の標準でもありません。そのため「W3C標準になった」と表現するのではなく、Community Groupによる交換形式の安定した仕様が公開されていると理解する必要があります。

配色をデザインシステムまで広げると、色は単なる見た目の値ではなくなります。どのような意味を持ち、どこで使われるのかまで管理することで、色彩設計を継続的に運用できるようになります。

色彩設計を実践する基本フロー

ここまでの理論を実際の制作へ落とし込むとき、すべてを同時に考えようとすると再び迷いやすくなります。

知識は増えたのに、画面を前にすると「結局どこから決めればよいのだろう」と手が止まることもあるでしょう。これは理解が足りないからではなく、判断する順番がまだ定まっていない可能性があります。

そこで、目的設定から検証までを一つの流れとして進めます。配色に迷ったときに戻れる順序を持っておけば、思いつくまま色を動かし続ける状態を避けやすくなります。

目的と感情を最初に言葉にする

最初に決めるのは色ではありません。誰に何を伝え、どのような状態になってほしいのかを言葉にします。

信頼して情報を読んでほしいのか、親しみを持ってサービスへ触れてほしいのか、重要な操作へ迷わず進んでほしいのかによって、必要な色彩の強さは変わります。

目的が曖昧なまま色を見ると、青にも緑にも赤にもそれぞれ魅力を感じ、決め手を失いやすくなります。選択肢が多いことより、判断基準がないことのほうが迷いを深くするのです。

そこで「安心して長く読める」「活発で前向きに感じる」など、最初に求める印象を言葉へ落とします。判断軸があれば、採用した色だけでなく、使わなかった色にも理由を持てるようになります。

ベースからアクセントまで順番に組み立てる

目的が定まったら、まず全体を支えるベースカラーを決めます。その上でブランドや情報の印象を担うメインカラーを選び、最後に最優先の操作や情報へ使うアクセントカラーを加えます。

この順序で進めれば、最初からすべての色を同時に決める必要がありません。

次に、色相だけではなくトーンを確認します。一色だけ必要以上に鮮やかになっていないか、明度差が不足していないか、アクセントの面積が広がりすぎていないかを見ます。

実際のUIでは必要な役割が増える場合もありますが、最初からすべての色を決めようとせず、画面に必要な機能が見えてから追加していくほうが整理しやすくなります。

配色を「三色を当てる問題」と考えるより、画面に必要な役割を順番に定義する工程として捉えたほうが修正もしやすくなるでしょう。

グレースケールで情報階層を診断する

配色を組んだら、グレースケールでも画面を確認します。

ここで見たいのはWCAGへの適合そのものではなく、色相がなくなった状態でも見出し、本文、主要操作、補助情報といった階層を把握できるかという点です。

色をなくした瞬間に、どこが重要なのか分からなくなるのであれば、情報の優先順位を色だけに任せすぎている可能性があります。

文字サイズ、太さ、余白、配置、形状などでも構造を伝えられていれば、そこへ色を加えることで情報階層をさらに補強できます。

なお、グレースケール確認で問題がなくても、それだけでWCAGのコントラスト基準を満たしたことにはなりません。WCAGへの適合確認では、相対輝度から算出したコントラスト比を別途確認します。

視覚階層を診断する方法と、規格への適合を判定する方法を明確に分けておくことが重要です。

一度に一つの変数だけ修正する

配色に違和感が残っていても、色相、彩度、明度、面積を一度に変更すると原因を追えなくなります。

複数の条件を同時に動かせば、良くなったとしても何が効果を生んだのか分かりません。逆に悪化した場合にも、どの変更を戻せばよいのか判断しにくくなります。

画面が騒がしい場合には、まず色数が多すぎないかを確認します。それでも落ち着かなければ、目立ちすぎている色の彩度だけを少し下げて結果を見ます。

色同士がばらついているなら、色相を変更する前にトーンを近づけます。アクセントが強すぎる場合には、色そのものではなく面積を小さくして比較する方法もあります。

「色が悪いと思っていたけれど、実際には使う量が多すぎただけだった」と気づくこともあるでしょう。

こうした発見ができるのは、一度に一つだけ条件を動かしたときです。

修正前後で目的が達成されたか確認する

変更後は「きれいになったか」だけで評価しません。

最初に見てほしい情報へ視線が向くか、文章を無理なく読めるか、主要な操作を見つけやすいか、色の違いが分からなくても意味を理解できるかを確認します。

制作中は同じ画面を何度も見るため、自分の目が強い色や弱いコントラストに慣れてしまうことがあります。そのため、可能であれば少し時間を空けて見直すことにも意味があります。

時間を置いたあと、一か所だけ異常に強く感じるのであればアクセントを見直す余地があります。反対に、最初にどこを見ればよいのか分からなければ、視覚的な優先順位が不足している可能性があります。

完成とは、色がきれいに並んだ状態ではありません。最初に定めた目的が、配色によって以前より伝わりやすくなった状態です。

判断した理由を次の制作へ残す

一つのデザインが完成したら、そこで得た判断を次回へ残します。

どの色を使ったかだけを記録しても、別の制作では条件が変わるため、そのまま再現できません。残したいのは「なぜその判断をしたのか」という関係です。

たとえば、アクセントの面積を減らしたら主要な操作が見つけやすくなった、低彩度の画面へ高彩度の色を限定的に加えたら優先順位が明確になった、といった理由を残します。

こうした経験が積み重なると、最初は「なんとなく良い」としか言えなかった感覚に説明が付くようになります。自分が何を見て判断したのかが分かれば、別のデザインでも条件に応じて考え直せるでしょう。

それが色彩設計を感覚から再現可能な判断へ変えていく過程です。

色彩設計で目指すのは美しさと機能の両立

色彩設計の目的は、きれいな色を集めることではありません。

色相によって色同士の関係を整理し、彩度によって視覚的な強さを調整し、明度によって印象と情報階層を支えます。さらに面積によってベース、メイン、アクセントの優先順位を作り、トーンによって画面全体の質感を整えます。

WebやUIでは、視線を導く色だけではなく、状態や意味を一貫して伝える色も必要になります。そこで色を見た目だけで管理せず、役割へ分解して考えることで、基本的な配色設計からデザインシステムへ自然に発展させられます。

また、アクセシビリティの観点では色だけに意味を依存させず、必要なコントラストを確認し、さまざまな利用者が情報へ到達できる状態を作らなければなりません。

さらにプロダクトが大きくなれば、色を一つずつ管理するだけでは足りなくなります。デザイントークンを通じて色の役割を管理し、画面やテーマが変わっても意味を維持できる仕組みが必要になります。

最初は「少し垢抜けない」という小さな違和感だったかもしれません。しかし、その違和感を色相、彩度、明度、トーン、面積、役割へ分けて考えられるようになると、配色は得体の知れないセンスの問題ではなくなります。

一つの条件を確認し、小さく直し、その結果を見る。さらに判断した理由を次へ残していけば、自分なりの設計基準が少しずつ育っていくでしょう。

まとめ

色彩設計を安定させる基本は、色を感覚だけで選ばず、色相、彩度、明度、トーン、面積、役割へ分けて考えることです。

ベースカラーで空間を支え、メインカラーで印象を形成し、アクセントカラーで必要な場所へ視線を導きます。WebやUIでは、さらに必要な意味や状態を役割として整理し、規模が大きくなればデザインシステムへつなげていきます。

また、グレースケールによる情報階層の診断とWCAGのコントラスト判定を混同せず、それぞれの目的に応じて確認することも重要です。

違和感が生まれたときには一度にすべてを変更せず、目的へ戻り、一つの変数だけを調整して結果を見ます。

なぜその色を使ったのかを説明でき、その判断を次の制作でも使えるようになることが、感覚に依存しない色彩設計への確かな一歩です。

参考資料

PCCS 日本色研配色体系 一般財団法人日本色彩研究所

Web Content Accessibility Guidelines WCAG 2.2 W3C

WCAG 2.2 日本語訳 ウェブアクセシビリティ基盤委員会

JIS X 8341-3:2016 解説 ウェブアクセシビリティ基盤委員会

WCAG 2.2 日本語訳更新とJIS改正情報 ウェブアクセシビリティ基盤委員会

カラー デジタル庁デザインシステム

Design Tokens Format Module 2025.10 Design Tokens Community Group