🔷 導入 — なぜ現場で配色が難しいのか

配色は美しさだけでなく、可読性やアクセシビリティ、ブランドの一貫性、実装工数と密接に関係します。現場でよく起きる失敗をまとめると次の通りです。

• 選択肢が膨大：数百万色の中から選ぶため基準がないと迷走する。
• レベルの不一致：同じ"レベル"（例: 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

※お役に立てたらストック、いいねをよろしくお願いします！！