※お役に立てたらストック、いいねをよろしくお願いします！！
＜📝本記事のターゲット層＞
- Web/UIデザイナー（初心者〜中級者）
- フロントエンド開発者（デザイン実装担当）
- プロダクトオーナー／PM（デザイン方針決定者）
🔷 導入 — なぜ現場で配色が難しいのか
配色は美しさだけでなく、可読性やアクセシビリティ、ブランドの一貫性、実装工数と密接に関係します。現場でよく起きる失敗をまとめると次の通りです。
• 選択肢が膨大：数百万色の中から選ぶため基準がないと迷走する。
• レベルの不一致：同じ"レベル"（例: UIの500）が色相によって見た目が揃わず統一感を欠く。
• テーマ差分の崩れ：ライト／ダークの単純反転で視認性が落ちる。
• アクセシビリティ不足：コントラストが取れておらず一部ユーザーが利用できない。
この記事では、これらの問題を防ぎ、短時間で実装可能なカラーパレットを作るための実務ワークフローを提示します。
🔹 色の基礎（実務で使える要点）
▸ 色の3要素
色は Hue（色相）、Chroma（彩度）、Lightness（明度）で表現されます。Webでは RGB/HEX が一般ですが、UI設計では OKLCH（人間の色知覚に近い色空間）を使うと、異なる色相間でも見た目のバランスを取りやすくなります。
▸ 実務ルール：70:25:5
画面の色比率を整理する簡易ルールとして 70:25:5 を推奨します。70% をベース（背景）、25% をメイン（カードや領域）、5% をアクセント（CTA）に使うことで画面がまとまります。
実務の短いチェックリスト：ベース色、メイン色、アクセント色をそれぞれ1色ずつ決め、後続でレベルを作る。
🔹 ステップバイステップのワークフロー（実践編）
以下は現場でそのまま使える手順です。各ステップに「必須アウトプット」「推奨ツール」「注意点」を記載します。
▸ Step 1 — ゴールと文脈を決める
• 必須アウトプット：目的（ブランド性／可読性重視／CV最適化など）、対象ユーザー、アクセシビリティ目標（例：WCAG AA）を短くまとめる。
• 推奨ツール：Notion、Google Docs、Miro、Linear
• 注意点：目的が曖昧だと配色の優先度が定まりません。チームで合意を取ってから進めましょう。
▸ Step 2 — ベースカラーを決める
• 必須アウトプット：背景（ベース）色、メイン候補 1〜2 色
• 推奨ツール：Figma（既存デザイン抽出）、Adobe Color
• 注意点：既存ブランド色がある場合はその色を優先し、OKLCH で微調整できるよう余白を残すと後が楽です。
▸ Step 3 — パレット自動生成（OKLCH 対応）
• 必須アウトプット：各色の複数レベル（例：50〜900）
• 推奨ツール：Harmonizer（OKLCH + APCA）、ColorMate、Colorbase
• 注意点：同一レベルで知覚的一貫性があるかを確認。Harmonizer はこの点を自動で揃えてくれます。
▸ Step 4 — レベルとコントラストを調整（APCA/WCAG）
• 必須アウトプット：見出し・本文・CTA など主要要素ごとの合否表
• 推奨ツール：APCAコントラスト日本語フォント検証、コントラストチェッカー、Adobe Color(WCAG)
• 注意点：WCAG だけで通っても APCA では視認性が不足する場合があります。両方確認しましょう。
▸ Step 5 — ライト/ダーク対応とテーママッピング
• 必須アウトプット：ライト→ダークの対応表（例：ライトの 500 → ダークの 300）
• 推奨ツール：Harmonizer、Figma
• 注意点：単純な反転は避け、各レベルで意味と視認性を保つようマッピングしてください。
▸ Step 6 — エクスポートと実装
• 必須アウトプット：Tailwind、CSS 変数、JSON 形式のパレット定義
• 推奨ツール：Harmonizer のエクスポート、Node スクリプト
• 注意点：開発側と事前に渡すフォーマットを合意しておくと実装がスムーズです。
実践例：Tailwind への落とし込み（サンプル）
以下は OKLCH で生成したカラーパレットを仮に HEX に変換して Tailwind に組み込むイメージです（実運用ではツール出力をそのまま利用してください）。
// tailwind.config.js の例
module.exports = {
theme: {
extend: {
colors: {
brand: {
50: '#f1f7f1',
100: '#e3f0e3',
200: '#c8e7c8',
300: '#9dd79d',
400: '#66c266',
500: '#2E7D32',
600: '#276b2b',
700: '#1f5a23',
800: '#154219',
900: '#0b2a0f'
}
}
}
}
}
この定義を共有することで、デザイナーと開発者の間での齟齬を減らせます。
🔹 ツール別ワークフローと使い分け
▸ Adobe Color / Colorbase
• 用途：配色案の探索、感性ベースの候補出し。
• 長所：直感的で早い。
• 短所：UI 用のレベル調整が自動化されない。
▸ Harmonizer（OKLCH + APCA）
• 用途：UI向けに一貫したパレットを生成／ライト・ダーク対応のマッピング
• 長所：レベル間の知覚的一貫性が取れるため、実装後の手戻りが少ない。Tailwind等へのエクスポートが便利。
• 短所：OKLCHやAPCAに不慣れだと学習コストがかかる。
▸ Contrast Checker（WCAG/APCA）
• 用途：最終チェック。アクセシビリティ要件の検証。
• 実務活用：結果を設計書に残し、品質保証フローに組み込みます。
🔹 アクセシビリティ（実務的観点）
• WCAG と APCA の使い分け：WCAG は規格としての有用性があり、APCA はスクリーン表示に近い評価をします。実務ではまず WCAG の基準を満たし、その上で APCA を用いて微調整するのが現実的です。
• 色だけで情報を伝えない：色弱者にも配慮して、色以外（アイコン／テキスト）でも情報を伝える設計にしてください。
✅ 実務チェックリスト（すぐ使える）
- ベース / メイン / アクセント を決め、70:25:5 を意識したか
- 各色にレベル（50〜900）を用意しているか
- 主要テキストと背景のコントラストを WCAG / APCA で確認済みか
- ライト / ダーク双方のマッピング表があるか
- Tailwind または CSS 変数 / JSON を用意しているか
- スマホ・タブレットで実機確認を行ったか
補足：よくあるトラブルと対処法
▸ 配色が全体的に“重たい”印象になる
→ 対処：ベース色を少し明るくする、アクセントに明度の高い色を混ぜる、OKLCH で彩度を下げて調整する。
▸ ダークテーマで文字が読みづらい
→ 対処：APCAで該当箇所を評価し、背景または文字の明度を微調整する。WCAG の判定だけで安心しない。
参考（リンク）
- Harmonizer（Web／GitHub）: https://harmonizer.evilmartians.com/
- Harmonizer GitHub: https://github.com/evilmartians/harmonizer
- Adobe Color: https://color.adobe.com/ja
- colorbase: https://colorbase.app/ja
- 色の基礎（新井 眞之介）: https://araishinnosuke.com/design/color20230423.html
- カラーパレット生成（coliss）: https://coliss.com/articles/build-websites/operation/work/generating-accessible-consistent-color-palettes-for-uidesign.html
※お役に立てたらストック、いいねをよろしくお願いします！！