センスよりも「ロジック」と法則
「〇〇さんが作った管理画面、なんか目が痛くなるんですよね。ずっと見てると疲れるというか…」
これは私がフリーランスのエンジニアとして独立したばかりの頃、自信満々で納品したシステムに対してクライアントから言われた衝撃の一言です。
当時の私は、機能要件を満たすことや、バックエンドの処理速度を上げることには命をかけていましたが、デザイン、特に「色」に関しては完全に無頓着でした。
「目立たせたいボタンは赤だろ？ リンクは青だろ？ エラーは黄色だろ？」
そんな短絡的な思考で、エディタのカラーピッカーの右上に表示される「彩度100パーセントの原色」を画面中にばら撒いていたのです。
結果、出来上がったのは、まるで警告ランプが点滅しているかのような、攻撃的で目に優しくないシステムでした。
あの時のクライアントの、言いにくそうに、でも我慢できないといった表情は今でも夢に見ることがあります。恥ずかしさと申し訳なさで、穴があったら入りたい気分でした。
「自分にはデザインのセンスがないから仕方ない」
「エンジニアは機能を作るのが仕事で、見た目を整えるのはデザイナーの仕事だ」
そうやって逃げようとしたこともありました。しかし、Web制作やアプリ開発の現場に長く身を置くうちに、ある重要な事実に気づいたのです。
優れたデザイナーほど、感覚やセンスだけで色を選んでいないということに。
彼らは、私たちエンジニアがコードを書くときにアルゴリズムを組み立てるのと同じように、明確な「ロジック」と「数値」、そして「物理法則」に基づいて色を設計しているのです。
もしあなたが、「デザインはセンスだ」「色選びは生まれ持った才能だ」と思って諦めているなら、それは大きな勘違いです。断言します。
配色は、数学です。
比率があり、計算式があり、守るべき変数のルールがあります。
論理的な思考を得意とするエンジニアである私たちにとって、実はこれほど相性の良い分野はありません。
今回は、あの日クライアントに呆れられた私が、その後15年かけて現場で血と汗を流しながら学んできた「エンジニアのための色彩戦略」を、泥臭い実体験と共にすべて共有します。
感覚的なふわっとした話は一切しません。すべて論理と数値で説明できる「技術」の話です。
これを読み終わる頃には、あなたはエディタのカラーパレットを開くのが怖くなくなり、むしろ変数のように色を操ることができるようになっているはずです。
なぜエンジニアのデザインは「ダサく」なるのか
まず、具体的な理論に入る前に、なぜ私たちエンジニアが選ぶ色はダサく、素人っぽくなってしまうのか。その根本的な原因を言語化しておきましょう。
バグを修正するには、まずエラーログを見て原因を特定する必要がありますよね。デザインの「ダサさ」というバグにも、明確な原因があります。
デフォルトのカラーパレットという罠
VS Codeやブラウザのデベロッパーツールで色を指定するとき、カラーピッカーが出てきます。
あなたは、そのピッカーの「どこ」をクリックしていますか？
多くの初心者は、無意識に「右上」の角をクリックしてしまいます。
そこにあるのは、彩度（鮮やかさ）が100パーセント、明度（明るさ）も100パーセントの、いわゆる「ビビッドカラー」です。
CSSの色名で言うなら red blue green yellow といった色、16進数なら #FF0000 #00FF00 #0000FF といった純粋な色です。
しかし、冷静に周りを見渡してみてください。
自然界や、洗練されたプロダクトの中に、こんなに純粋で強い色が存在するでしょうか？
ほとんどありません。
木々の緑も、空の青も、スタバのロゴの緑も、ユニクロの赤も、すべて何らかの「混じりけ」があります。
それなのに、画面上にこの純粋すぎる色を置くと、そこだけ異空間のように浮いてしまい、ユーザーの目に強い刺激を与えてしまうのです。
プロのデザイナーが使う「赤」は、少し黒が混じっていたり、少し彩度を落としていたりします。この「くすみ」や「濁り」こそが、画面全体に馴染ませるための接着剤の役割を果たします。
私たちは無意識に「純粋なコード」や「きれいな整数」を好む傾向がありますが、色に関しては「不純物が混じっている」ほうが正解であり、美しいのです。
色数が多すぎて制御不能になる（スパゲッティコード状態）
プログラミングにおいて、グローバルスコープに変数を乱立させたら、レビューでこっぴどく怒られますよね？
「変数のスコープは最小限にしろ」「マジックナンバーを使うな」と。
配色もまったく同じです。
「ここは目立たせたいから赤、ここは注意喚起だから黄色、ここは安心感を出したいから緑、ここはクールにしたいから青…」
こうやって意味もなく、ルールもなく色数を増やしていくと、画面はカオスになります。
これを私は「色のスパゲッティコード状態」と呼んでいます。
どこを見ていいかわからない、情報の優先順位がわからない、そして何より美しくない。
原則として、1つの画面で使う色は3色、多くても4色まで。それ以上使う場合は、相当な理由と高度な制御技術が必要です。
変数を減らすように、色数を減らす。これがエンジニアがデザインを攻略する第一歩です。
色を「数値」で管理する技術｜RGBを捨ててHSBを持て
エンジニアなら、色は16進数（Hex）の #RRGGBB か、rgb(255, 0, 0) で管理していることが多いと思います。
コンピュータにとっては、RGB（光の三原色）が正解です。モニターは光で色を表現しているからです。
しかし、今日からデザインをするときだけは、その思考を一旦捨ててください。
RGBは「機械のための言語」であって、「人間のための言語」ではありません。
「赤を200、緑を100、青を50混ぜたら、どんな色になるか想像できますか？」
この質問に即答できる人は、特殊な訓練を受けた人か、天才だけです。普通の人間には無理です。
直感的に色がわからないモデルを使ってデザインをするのは、目隠しをして絵を描くようなものです。
代わりに使うべきなのが、「HSB（またはHSL）」というモデルです。
これは、以下の3つのパラメータで色を表現します。
- Hue（色相）：色の種類。0度から360度の角度で表す。「赤」「青」「黄色」などの色味そのもの。
- Saturation（彩度）：色の鮮やかさ。0パーセントから100パーセント。数値が高いとビビッドに、低いとグレー（無彩色）に近づく。
- Brightness（明度）：色の明るさ。0パーセントから100パーセント。数値が高いと白に、低いと黒に近づく。
これなら、エンジニアの脳でも直感的に操作できます。
「この青（Hue）を、もう少し落ち着かせたいな」と思ったら、Saturation（彩度）の数値を下げればいい。
「この赤（Hue）を、もう少し暗く重厚にしたいな」と思ったら、Brightness（明度）の数値を下げればいい。
この「パラメータを調整して出力を変える」という感覚は、関数の引数をチューニングするのに似ていて、私たちエンジニアにはすごく馴染みやすいんです。
「トーン」を合わせるという魔法
配色の失敗の9割は、実は色の選び間違いではなく、「トーン（彩度と明度の組み合わせ）」がバラバラなことで起きます。
逆に言うと、色相（Hue）がバラバラでも、トーン（SaturationとBrightness）さえ揃っていれば、統一感が出ておしゃれに見えるのです。
例えば、パステルカラーと呼ばれる色たち。あれは「高明度・低彩度」で数値を揃えた色のグループです。
ビビッドカラーは「高彩度」で揃えたグループです。
伝統色やアースカラーは「中彩度・中明度」のグループです。
私たちがやるべきは、使いたい色のS（彩度）とB（明度）の数値を、ある程度近い範囲に収めること。
これだけで、画面に驚くほどの統一感が生まれます。
「なんかダサい」「バラバラな感じがする」と思ったら、エディタの表示をRGBからHSBモードに切り替えて、数値をチェックしてみてください。
きっと、どれかの色の彩度や明度が、他の色と比べて極端にズレているはずです。
それを修正するだけで、デザインのバグは解消されます。
配色の黄金比率「60:30:10」の法則
色を数値で管理する方法がわかったら、次は「どの色を、どれくらいの面積で使うか」という配分（レイアウト）の問題です。
ここで登場するのが、インテリア業界やWebデザイン業界で鉄則とされる「60:30:10の法則」です。
これは黄金比のようなもので、この比率を守っている限り、大きな事故は起きません。
おしゃれな部屋も、かっこいいWebサイトも、ほぼ例外なくこの比率で構成されています。
ベースカラー（70%）：背景となる舞台
画面全体の背景となる色です。理論上は60パーセントですが、Webデザインの実務では余白が多いため、70パーセントくらいを占めることが多いです。
基本的には「白」か「ごく薄いグレー（#F5F5F5など）」、あるいは「ごく薄いメインカラー」を選びます。
ここで重要なのは、「個性を出さない」ことです。
ベースカラーはあくまで、コンテンツを乗せるための「画用紙」であり「舞台」です。舞台装置が目立ちすぎて役者（コンテンツ）が見えなくなっては本末転倒です。
エンジニアがやりがちなのが、ここに変なテクスチャを入れたり、目に優しくない真っ黒を使ったりすることです。
可読性が死ぬので、初心者のうちは黙って「白に近い色」を選びましょう。それだけで清潔感が保証されます。
メインカラー（25%）：ブランドの顔
そのサイトやアプリの「ブランドイメージ」を決定づける色です。
ロゴに使われている色や、ターゲット層が好む色を選びます。
見出し、ヘッダー、フッター、イラストの一部、リンク文字などに使います。
ここでのポイントは、先ほどもお伝えした通り「彩度を少し下げる」ことです。
例えば、青をメインカラーにしたい場合、カラーピッカーの右上にある真っ青（S:100%）ではなく、少し左または下に移動させた、落ち着いたネイビーやスチールブルー（S:70%, B:80%くらい）にします。
これだけで、画面に「プロっぽさ」と「長時間見ていても疲れない安心感」が生まれます。
また、メインカラーは1色に絞るのが理想ですが、どうしても増やしたい場合は、同じ色相（Hue）で明度だけ変えた色を使うとまとまります。
アクセントカラー（5%）：最強のスパイス
画面の中で一番目立たせたい部分、つまり「コンバージョンボタン（購入、登録、お問い合わせ）」や「重要な通知バッジ」に使います。
たった5パーセントというわずかな面積ですが、役割としては主役級です。ユーザーのアクションを誘導するための色だからです。
ここで選ぶべきは、「メインカラーの補色（反対色）」や、メインカラーと対照的な色です。
メインが青なら、アクセントはオレンジや黄色。
メインが緑なら、アクセントは赤やピンク。
色相環（カラーホイール）を見て、メインカラーの正反対にある色を選ぶと、一番コントラストが効いて目立ちます。
この「5パーセント」を守るのが、実は一番難しいのです。
「ここも目立たせたい」「あそこも見てほしい」という欲が出て、気づけば画面中がアクセントカラーだらけになってしまう。
それはもうアクセント（強調）ではなく、ノイズ（雑音）です。
「強調したい場所以外には、絶対にこの色を使わない」という強い意志（制約）を持ってください。
デザインとは、足し算ではなく、引き算の技術です。
ツールに頼れ！自力で色を探すな
ここまで理屈を話してきましたが、ぶっちゃけゼロから良い色の組み合わせ（カラースキーム）を見つけるのは大変です。
プロのデザイナーだって、毎回自分の頭の中だけでゼロから色をひねり出しているわけじゃありません。
優秀なライブラリやツールを使って、効率よく「正解」を見つけているんです。
私たちエンジニアも、ゼロからソートアルゴリズムを書いたりしませんよね？ 標準ライブラリを使いますよね？ それと同じです。
車輪の再発明はやめて、巨人の肩に乗りましょう。現場で使える最強のツールを3つ紹介します。
Adobe Color
王道中の王道です。Adobeが提供している無料ツールです。
「探索」タブでキーワード（例：Business, Cafe, Summer, Tech）を入れると、世界中のデザイナーが作成した配色パレットがずらりと出てきます。
「トレンド」タブを見れば、今流行りの配色もわかります。
気に入ったパレットを見つけたら、CSSコードとしてコピーすることも可能です。
私は新規案件が来たら、まずここでキーワード検索して、良さげなパレットを3つくらいピックアップすることから始めます。これで配色の方向性が9割決まります。
Coolors
スペースキーを押すたびに、AIが良い感じの配色パターンをランダムに生成してくれるツールです。
「このメインカラーだけは固定（ロック）して、それに合うアクセントカラーを探して」という使い方ができるのが最強です。
自分の頭では絶対に思いつかないような、でも意外と合う組み合わせを提案してくれるので、アイデアに詰まった時によく使います。
生成されたパレットはURLで共有できるので、チームメンバーに「これどう？」と送るのも簡単です。
Happy Hues
「実際にWebサイトに当てはめたらどう見えるか」がリアルタイムで確認できるサイトです。
左側のメニューから配色のパレットを選ぶと、デモサイトの背景、ボタン、文字色がその色に切り替わります。
「パレット単体で見ると綺麗だけど、画面全体にすると文字が読みづらいな」とか「背景色が強すぎて目が痛いな」といった失敗を未然に防げます。
実務に入る前のシミュレーションとして非常に優秀です。
アクセシビリティは「優しさ」であり「品質」である
色がなんとなく決まったら、次に確認しなければならないのが「アクセシビリティ」です。
これは単なる「優しさ」ではありません。エンジニアにとっては、バグがないかどうかの「品質チェック」と同じレベルの話です。
特に重要なのが「コントラスト比」です。
背景色と文字色の明るさの差が十分にないと、視力が弱い人や、日光の下でスマホを見ている人、ディスプレイの輝度を下げている人にとって、文字が読めなくなってしまいます。
WCAGの基準を数値でクリアせよ
Webアクセシビリティ基盤委員会（WCAG）という国際的なガイドラインがあります。
ここでは、通常の文字で「4.5対1」以上のコントラスト比を求めています。
「なんとなく読めるからOK」ではダメなんです。エンジニアなら、数値でクリアしているかを厳密に確認しましょう。
これを確認するのにもツールがあります。
「Adobe Color」の「アクセシビリティツール」や、Chromeのデベロッパーツールでも確認できます。
デベロッパーツールで要素を検査して、カラーコードの横に「$D83D$DEAB」マークが出ていたら、コントラスト比不足です。
デザイナーさんが作ったカンプがこの基準を満たしていなくて、「これだと外でスマホを見た時に読みにくいので、文字色をもう少し濃く調整してもいいですか？」と提案することもしょっちゅうあります。
これはデザインへの文句ではなく、プロダクトの品質担保（QA）としての、エンジニアの義務です。
色だけで情報を伝えない（色覚多様性への配慮）
もう一つ大事なのが、「色覚多様性」への配慮です。
日本人男性の約20人に1人、欧米ではもっと高い割合で、特定の色（特に赤と緑）の区別がつきにくい人がいます。
「エラーの箇所を赤くしました」
これだけだと、赤が見えにくい人には、どこがエラーなのかわかりません。ただのグレーに見えているかもしれません。
必ず「アイコン」を添えるか、「エラー」という文字情報を併記する。
グラフなら、色だけでなく模様（ハッチング）を変える。
「色がなくても情報が伝わるデザイン」こそが、本当にユニバーサルで優れたデザインなんです。
「色に頼りすぎない」というのは、逆説的ですが、配色を極める上で非常に重要な視点です。
ダークモードという現代の必須要件と実装ロジック
最近のアプリやOSでは当たり前になったダークモード。
エンジニアとしては実装の手間が増えるので頭が痛いですが、ユーザーの需要が高い以上、避けては通れません。
ここでエンジニアがやりがちな最大の失敗が、「単純に白と黒を反転させる」ことです。
真っ黒（#000000）は使うな
ダークモードの背景に完全な黒（#000000）を使うと、文字の白とのコントラストが強すぎて、逆に目が疲れます（ハレーションと言います）。
スマホの有機ELディスプレイだと、黒の部分画素が消灯して省エネにはなりますが、スクロールしたときに文字が滲む「黒滲み」という現象も起きます。
Googleのマテリアルデザインでも推奨されていますが、背景には「濃いグレー（#121212など）」を使いましょう。
これだけで、目に優しく、かつ高級感のあるダークモードになります。
「重なり」は色ではなく「明るさ」で表現する
ライトモード（通常）では、カードやドロップダウンの重なりを「影（ドロップシャドウ）」で表現しますよね。
でもダークモードでは、背景が暗いので黒い影が見えません。
じゃあどうするか？
「手前にあるものほど、背景色を明るくする」んです。
一番奥の背景が #121212 なら、その上に乗るカードは #1E1E1E、さらにその上に乗るモーダルは #2C2C2C みたいに、明るさの段階（レベル）を上げます。
これを「エレベーション（高度）」と言います。
色を変えるのではなく、明度で階層を表現する。このロジックを知っているだけで、ダークモードの実装がグッと楽になりますし、デザインが破綻しません。
現場でのCSS設計｜色は「変数」で管理しろ
ここからは少しコード寄りの話です。
デザインが決まったら、それをどうCSSに落とし込むか。
絶対にやってはいけないのが、各場所にカラーコードを直接書くことです（ハードコーディング）。
/* NGな例：保守性の欠片もない */
.button {
background-color: #3498db;
}
.title {
color: #3498db;
}これをやると、「メインカラーを少し暗くしたい」となった時に、全ファイルを検索置換する地獄が待っています。
そして必ず置換漏れが起きて、色がちぐはぐになります。エンジニアとしてあるまじき行為です。
CSS Variables（カスタムプロパティ）の活用
現代のCSSでは、ネイティブで変数が使えます。これを使わない手はありません。
:root {
/* セマンティックな命名にする */
--color-primary: #3498db;
--color-background: #ffffff;
--color-text-main: #333333;
--color-text-sub: #666666;
--color-accent: #e74c3c;
}
.button {
background-color: var(--color-primary);
}ポイントは、変数名を「色の名前（blue, red）」ではなく「役割（primary, accent, danger）」にすること。
そうすれば、後でプライマリーカラーを青から緑に変えることになっても、変数の中身を変えるだけで済みます。変数名を変える必要がありません。
これを「セマンティック・ネーミング」と言います。
コードの可読性も上がるし、ダークモード対応も :root の変数をメディアクエリで上書きするだけで済むので、保守性が段違いです。
Tailwind CSSでの管理
最近流行りのTailwind CSSを使う場合も同じです。tailwind.config.js で、独自のカラーパレットを定義しましょう。
module.exports = {
theme: {
colors: {
primary: '#3498db',
secondary: '#2ecc71',
// ...
}
}
}こうしておけば、bg-primary text-primary といったクラスが自動生成されます。
チーム開発でも「とりあえず bg-primary を使ってください」と言えば色が統一されるので、コミュニケーションコストも下がります。
デザインシステムの構築において、この「色の変数化」は最初に行うべき最も重要な工程です。
色は「言語」である
長々と話してきましたが、結局のところ、色は「非言語のコミュニケーションツール」なんです。
私たちがコードでコンピュータに命令を伝えるのと同じように、色はユーザーに感情や優先順位を伝えます。
青いボタンは「進む」「決定」「信頼」を感じさせ、赤いボタンは「危険」「停止」「注目」を感じさせる。
薄いグレーの文字は「補足だから読み飛ばしてもいいよ」と囁き、太字の黒い文字は「ここだけは読んでくれ！」と叫んでいる。
そう考えると、配色ってプログラミングにすごく似ていませんか？
意図を持って配置し、ユーザーの行動を制御する。
そう、デザインもエンジニアリングの一部なんです。
私があの「目がチカチカするサイト」を作ってしまった時は、この視点が完全に抜け落ちていました。
ユーザーに何を伝えたいかではなく、「目立てばいい」「機能があればいい」というエゴで作っていたんです。
色を整えることは、単なるお化粧ではありません。ユーザーへの「おもてなし」であり、使いやすさへの配慮であり、プロダクトへの愛です。
これから画面を作るとき、少しだけ立ち止まって考えてみてください。
「この色は、ユーザーに何を伝えようとしているのか？」
「この配色は、長時間見ていても疲れないか？」
「60:30:10の比率になっているか？」
センスはいりません。
必要なのは、ユーザーを思いやる想像力と、それを実現するための少しのロジックだけです。
大丈夫、複雑なバックエンドのロジックを組めるあなたなら、色のロジックもきっと制御できます。
さあ、エディタを開いて、まずは :root にカラー変数を定義するところから始めましょう。
あなたの作る画面が、誰かにとって心地よい場所になることを願っています。
