UIのステータスカラー設計｜成功・警告・エラー・情報の色と使い分け

Webサイトやアプリケーションでは、操作結果や現在の状態を利用者へ伝えるために、成功、警告、エラー、情報という四つのステータスがよく使われます。保存が完了したときは成功、入力内容に問題があるときはエラー、注意が必要な操作には警告、補足説明には情報というように、状態ごとに役割が異なります。

ステータスカラーは、成功なら緑、警告なら黄、エラーなら赤、情報なら青を選べば完成するものではありません。背景色、文字色、枠線、アイコン、操作要素、ライトモード、ダークモードまで含めて設計しなければ、文字が読めない、状態を区別できない、ブランドカラーと混同するといった問題が発生します。

さらに、色だけで状態を伝える設計は避ける必要があります。WCAG 2.2では、色の違いだけに依存せず、文字、形状、アイコンなど別の視覚的な手掛かりも提供することが求められています。また、通常サイズの文字には背景とのコントラスト比4.5対1以上、状態の識別に必要な非テキスト要素には隣接色とのコントラスト比3対1以上が基準になります。

本記事では、四つのステータスの意味から、カラーパレット、コンポーネント、アクセシビリティ、デザイントークン、Figma、CSSへの実装まで、実務で使える設計手順を解説します。

1. UIのステータスカラーとは

ステータスカラーとは、UI上の状態や操作結果に意味を与える色です。ブランドを表現するための色とは異なり、利用者へ「何が起きたか」「何に注意すべきか」「次に何をすべきか」を伝える目的で使用します。

1.1 ステータスカラーとは

ステータスカラーは、成功、警告、エラー、情報など、特定の意味と結び付いた色です。一般的には、成功に緑、警告に黄またはオレンジ、エラーに赤、情報に青が使われます。IBMのCarbon Design Systemでも、緑を正常または成功、黄やオレンジを警告、赤を危険またはエラー、青を補足情報や進行状況として扱っています。

ただし、色相だけを決めてもステータスカラーシステムにはなりません。各状態について、濃い文字色、アイコン色、枠線色、薄い背景色、ホバー色、ダークモード用の色などを用意する必要があります。

1.2 ブランドカラーとの違い

ブランドカラーは、製品や企業の個性を表現するために使います。主要ボタン、ロゴ、選択状態、リンクなどへ使用されることが多く、必ずしも状態の意味を持ちません。

一方、ステータスカラーには明確な意味があります。ブランドカラーが緑の場合でも、すべての主要ボタンを成功状態として扱うわけではありません。通常操作の緑と成功の緑を同じ値にすると、利用者が操作と状態を区別しにくくなる可能性があります。

1.3 装飾色との違い

装飾色は、イラスト、背景、グラフ、カードの分類など、視覚的な変化を作るために使います。装飾色には、必ずしも成功や失敗といった意味はありません。

ステータスカラーを装飾目的で多用すると、色の意味が弱くなります。例えば、通常のカードを赤い枠線で装飾すると、利用者はエラーや危険を示していると誤解する可能性があります。

1.4 状態を伝える要素

ステータスは、色だけでなく、アイコン、見出し、本文、枠線、背景、配置を組み合わせて伝えます。成功ならチェック、警告なら三角形、エラーなら感嘆符や×、情報なら情報記号を使う方法があります。

WCAGの「色の使用」では、色を識別できない利用者にも情報が伝わるよう、文字やアイコンなど別の手掛かりを提供することが重要です。

1.5 ステータスカラーを使う場所

ステータスカラーは、通知、フォーム検証、タグ、バッジ、進行状態、表の状態列、空状態、インラインメッセージなどへ使用できます。

同じ状態でも、コンポーネントによって必要な強さは異なります。画面全体を停止させるエラーと、一つの入力欄だけのエラーで、同じ面積と強度の赤を使う必要はありません。

2. 成功・警告・エラー・情報の違い

四つの状態は、色ではなく意味によって選びます。黄色にしたいから警告を選ぶのではなく、利用者が取るべき行動と問題の深刻度から決定します。

2.1 成功と情報の違い

成功は、利用者の操作やシステム処理が期待どおり完了したことを示します。情報は、処理の成功・失敗に直接関係しない補足や案内を示します。

例えば「プロフィールを保存しました」は成功ですが、「反映には数分かかる場合があります」は情報です。Carbon Design Systemでも、成功はタスクが期待どおり完了したことの確認、情報は現在の操作と直接結び付かない追加情報として区別されています。

2.2 警告とエラーの違い

警告は、現在は操作を続行できるものの、注意や確認が必要な状態です。エラーは、処理が失敗した、入力が無効である、または問題を解決するまで先へ進めない状態です。

「この操作を行うと共有リンクが無効になります」は警告です。「共有リンクを削除できませんでした」はエラーです。Carbon Design Systemでも、警告は望ましくない結果の可能性を知らせ、エラーは処理の失敗や解決まで進行を妨げる問題として区別しています。

2.3 情報と警告の違い

情報は、利用者の判断を支援する中立的な案内です。警告は、無視すると望ましくない結果が起こる可能性があることを示します。

「パスワードは8文字以上です」は情報として表示できますが、「このパスワードは漏えいした可能性があります」は警告です。文章だけでなく、利用者が対応しなかった場合の影響を基準に選びます。

2.4 成功と通常状態の違い

成功は、変化や完了を利用者へ通知する必要がある場合に使用します。単に問題がない通常状態すべてを緑で表示すると、画面が緑だらけになり、重要な成功通知が目立たなくなります。

例えば、常に利用可能なボタンを緑にする必要はありません。一方、設定変更直後の「設定を保存しました」は、操作結果として成功色を使う価値があります。

2.5 深刻度を追加する場合

複雑な業務システムでは、四つの状態だけでは不足する場合があります。重大障害、危険、停止、保留、未開始、進行中などを追加できます。

状態を増やす場合も、似た意味を色だけで分けないことが重要です。例えば警告と重大警告を黄色とオレンジだけで区別せず、「警告」「重大」という文字や異なるアイコンを組み合わせます。

3. 成功カラーを設計する

成功カラーは、操作や処理が期待どおり完了したことを伝えます。利用者へ安心感を与える一方、すべての正常状態へ使うと意味が弱くなるため、使用範囲を定義します。

3.1 成功カラーの役割

成功カラーは、保存、送信、登録、承認、接続、完了など、期待した結果が得られた状態へ使用します。

成功通知は、利用者の不安を解消する役割があります。操作後に画面変化が小さい場合は、「保存しました」という成功メッセージを表示することで、処理が完了したことを明確にできます。

3.2 成功色の色相を選ぶ

成功には、一般に緑が使われます。黄緑に近すぎる色は警告と混同しやすく、青緑に近すぎる色は情報色やブランド色と区別しにくくなる場合があります。

まず中程度の緑を選び、そこから濃い文字色、標準アイコン色、薄い背景色を作ります。ブランドの緑をそのまま使う場合も、成功として十分に識別できるか確認します。

成功パレット例

この値は設計例であり、実際には文字と背景のコントラストを計測して決定します。

3.3 成功メッセージを書く

成功メッセージでは、何が完了したかを短く明示します。「成功しました」だけでは、複数の処理がある画面で対象が分かりません。

「プロフィールを保存しました」「招待メールを送信しました」のように、対象と結果を含めます。次の操作が必要な場合は、短い説明やリンクを追加します。

3.4 成功通知の表示時間

自動的に消える成功通知は、利用者が内容を読める時間を確保します。短すぎると見逃され、長すぎると作業を妨げます。

重要な結果や、後から確認できない情報は自動消去せず、閉じる操作を用意します。軽い保存完了通知は数秒後に消す設計もできますが、画面内の状態変化でも結果を確認できるようにします。

3.5 成功を過剰に表示しない

文字入力のたびに緑のチェックを表示するなど、成功表示が多すぎると画面が落ち着かなくなります。利用者が結果を確認する必要がある場面だけに限定します。

正常状態が標準である場合、何も表示しないことも有効です。異常から正常へ戻った場合や、重要な操作が完了した場合に成功色を使うと、意味を保ちやすくなります。

4. 警告カラーを設計する

警告カラーは、直ちに失敗しているわけではないものの、利用者が内容を確認すべき状態に使います。警告を多用すると、重要な注意が埋もれるため、使用基準を明確にします。

4.1 警告カラーの役割

警告は、現在の操作を続行できるが、望ましくない結果が起こる可能性を伝えます。削除前の確認、容量不足、期限接近、互換性の問題などが代表例です。

警告の目的は利用者を怖がらせることではなく、判断に必要な情報を与えることです。起こり得る結果と、回避方法を具体的に説明します。

4.2 黄色とオレンジを使い分ける

黄色は一般的な注意、オレンジはより強い警告に使用できます。Carbon Design Systemでも、黄色を通常の警告、オレンジを重大な警告として扱う例があります。

ただし、二つの警告段階を色だけで区別してはいけません。「注意」「重大な警告」という文字や、異なるアイコンを追加します。

4.3 黄色背景の文字色を選ぶ

明るい黄色の上に白文字を置くと、十分なコントラストを確保しにくくなります。黄色背景には、濃い茶色、濃いグレー、黒に近い文字色を使う方法が安全です。

通常サイズの文字は背景とのコントラスト比4.5対1以上がWCAG 2.2のレベルAA基準です。アイコンや状態を識別する枠線などの非テキスト要素には、隣接色との3対1以上が基準になります。

警告パレット例

4.4 警告メッセージを書く

警告文では、何が起こる可能性があるか、利用者が何を選べるかを説明します。「注意してください」だけでは判断材料が不足します。

削除確認なら、削除対象、復元可能性、影響範囲を明示します。ボタンも「はい」「いいえ」ではなく、「ファイルを削除」「キャンセル」のように結果が分かる文にします。

4.5 警告と確認画面を区別する

すべての確認ダイアログを警告色にする必要はありません。通常の選択確認と、損失の可能性がある警告を区別します。

例えば「言語を日本語へ変更しますか」は通常確認ですが、「未保存の内容を破棄しますか」は警告です。操作の重大性に合わない強い色を使うと、利用者が警告を無視するようになります。

5. エラーカラーを設計する

エラーカラーは、入力、処理、接続、権限などに問題があり、修正または再試行が必要な状態へ使用します。赤くするだけでなく、原因と解決方法を明示することが重要です。

5.1 エラーカラーの役割

エラーは、利用者の目的を達成できなかったことを示します。入力値が無効、サーバーへ接続できない、権限がない、保存に失敗したといった状態が該当します。

エラー表示は問題の存在だけでなく、次に取るべき行動を伝えます。「エラーが発生しました」だけでは、利用者が自力で解決できません。

5.2 赤色の強度を設計する

強い赤を大面積で使うと、利用者へ過度な緊張を与えることがあります。通常のフォームエラーでは、薄い赤背景、濃い赤文字、赤い枠線を組み合わせます。

システム停止や回復不能な操作など、重大性が高い場合だけ、濃い赤背景や強い視覚表現を使用します。

エラーパレット例

5.3 フォームエラーを表示する

入力欄のエラーでは、枠線だけを赤くする設計を避けます。項目の近くにエラーアイコンと説明文を表示し、どの条件を満たせば修正できるかを示します。

Material Designのテキストフィールドでも、エラーメッセージには修正方法を示し、対象フィールドの下に補助文として表示する設計が案内されています。

HTML例

<label for="email">  メールアドレス </label> <input  id="email"  type="email"  aria-invalid="true"  aria-describedby="email-error" > <p  id="email-error"  class="field-error" >  有効なメールアドレスを入力してください </p>

5.4 動的エラーを読み上げる

利用者の操作後に動的に表示される重要なエラーは、支援技術へ通知する必要があります。role="alert"は、即時の注意が必要な動的メッセージに使用され、暗黙的に強いライブリージョンとして扱われます。頻繁に使うと操作を妨げるため、重要なエラーへ限定します。

すでにページ読み込み時から存在する説明文へ、無条件にrole="alert"を付けるのではありません。動的に発生した入力エラー、セッション期限、接続喪失などに利用します。

<div  id="form-error"  role="alert" >  保存できませんでした。  入力内容を確認してください。 </div>

5.5 利用者を責めない文章にする

エラーメッセージでは、「入力が間違っています」「不正な操作です」のように利用者を責める表現を避けます。

問題の場所、現在の状態、修正方法を簡潔に示します。技術的なエラーコードは必要に応じて補足し、主要メッセージには利用者が理解できる言葉を使います。

6. 情報カラーを設計する

情報カラーは、中立的な補足、説明、案内、進行状況を伝えるために使います。緊急性が低く、利用者の現在の作業を妨げないことが特徴です。

6.1 情報カラーの役割

情報は、利用者の判断を支援する補足内容へ使います。新機能の案内、処理時間の説明、設定の推奨、データの更新日時などが該当します。

現在の操作に対する即時の成功や失敗ではなく、理解を助けるための情報であることが重要です。Carbon Design Systemでは、情報通知を現在の操作に直接結び付かない追加情報として説明しています。

6.2 青色を選ぶ

情報カラーには青が一般的です。ただし、青はリンク、主要ボタン、ブランドカラーにもよく使われます。情報アイコンや薄い背景を組み合わせ、クリック可能な要素と区別します。

情報通知全体を青文字にするとリンクに見える場合があります。本文は通常の文字色を使い、アイコン、枠線、見出しへ青を使用する設計も有効です。

情報パレット例

6.3 リンクとの違いを作る

情報色とリンク色が同じ場合、通知内の通常テキストがクリックできるように見える可能性があります。リンクには下線、異なる太さ、ホバー状態などを追加します。

色だけでリンクを識別させないことも、色に依存しない設計の一部です。W3Cの資料では、色覚差にかかわらず認識できる追加の手掛かりが重要とされています。

6.4 情報通知の優先度

情報通知は緊急性が低いため、画面の主要操作より強く目立たせないようにします。全面の濃い青背景ではなく、薄い背景や左側の枠線で表現できます。

利用者が後で参照する必要がある情報は、トーストではなくインラインまたは固定表示にします。自動で消えると、内容を再確認できません。

6.5 statusロールを使う

動的に更新されるが、利用者の現在の操作を中断するほど緊急ではない情報には、role="status"を使用できます。statusは暗黙的にaria-live="polite"を持ち、支援技術は適切なタイミングで内容を通知します。更新時にフォーカスを移動させる必要はありません。

保存完了、検索結果件数、処理進行の更新などに利用できます。

<div  id="save-status"  role="status" >  下書きを保存しました </div>

7. ステータスパレットを構築する

四つの代表色だけを決めるのではなく、各状態について複数の明度段階を用意します。用途別の色を作ることで、背景、文字、アイコン、枠線を一貫して実装できます。

7.1 基準色を決める

最初に、成功、警告、エラー、情報それぞれの基準色を決めます。基準色は、主にアイコン、枠線、強調部分へ使用する中程度の色です。

ブランドカラーと近い場合は、色相、明度、彩度のいずれかを調整します。青いブランドカラーと青い情報カラーが完全に同じ場合でも、コンポーネントの形や意味トークンで区別できる設計が必要です。

7.2 薄い背景色を作る

通知やインラインメッセージでは、基準色より非常に薄い背景色を使います。背景へ強い原色を使うと、広い面積が過度に目立ちます。

薄い背景では、基準色のアイコンが十分に見えるか、文字色とのコントラストが確保できるかを確認します。

7.3 濃い文字色を作る

薄い背景に基準色をそのまま文字として使うと、通常サイズの文字に必要なコントラストへ届かない場合があります。本文には、各色相の濃い段階を使用します。

色付き背景の上に通常文字色を使う方法もあります。ステータスの意味はアイコンと枠線で伝え、本文の可読性を優先します。

7.4 枠線とアイコン色を作る

枠線とアイコンは、背景より濃く、文字色より明るい中間色を使うことができます。ただし、状態の識別に必要なアイコンや枠線には、隣接背景とのコントラスト比3対1以上を確保する必要があります。

細い枠線は色の差があっても認識しにくいことがあります。必要に応じて2pxへ太くする、左側だけ太いアクセント線にするなど、形状でも差を作ります。

7.5 パレット全体を比較する

各状態を別々に設計した後は、四つを同じ画面へ並べて比較します。成功と情報、警告とエラーが似すぎていないかを確認します。

これらは開始点となる配色例です。実際の製品では、使用フォント、背景、ブランド色、ダークモードを含めてコントラストを検証します。

8. 文字・背景・枠線・アイコンを設計する

ステータスコンポーネントには、複数の視覚要素があります。一つの色をすべてへ使うのではなく、各要素の役割に適した明度を割り当てます。

8.1 本文色を設計する

本文は、状態色の濃い段階または通常の高コントラスト文字色を使用します。長い説明文を鮮やかな赤や青で表示すると、読み疲れしやすくなる場合があります。

見出しとアイコンだけを状態色にし、本文は通常文字色にする方法もあります。状態を認識しながら、文章を読みやすくできます。

8.2 背景色を設計する

背景色は、通知の範囲を示し、周囲のコンテンツと区別します。薄い色を使うと、本文の可読性を維持しながら状態を表現できます。

背景面積が大きいほど、色は薄くするのが一般的です。小さなバッジでは比較的濃い色を使えますが、その上の文字とのコントラストを確認します。

8.3 枠線を設計する

枠線は、通知や入力欄の境界を明確にします。背景色だけでは周囲と区別しにくい場合に有効です。

フォームエラーでは、入力欄の全周を赤くするだけでなく、エラーメッセージやアイコンを追加します。枠線だけでは色覚差のある利用者が状態を判断できない可能性があります。

8.4 アイコンを設計する

アイコンは、色を認識できない場合にも状態を区別する手掛かりになります。成功、警告、エラー、情報で異なる形状を使用します。

アイコンだけで意味を伝えず、テキストも併記します。アイコンが装飾目的で、隣に同じ意味の文字がある場合は、支援技術から重複して読み上げられないようにします。

<div class="notice notice--success">  <svg    class="notice__icon"    aria-hidden="true"    viewBox="0 0 24 24"  >    <!-- チェックアイコン -->  </svg>  <p>    ファイルを保存しました  </p> </div>

8.5 アクション要素を設計する

通知内に「再試行」「詳細を見る」「元に戻す」などのボタンを置く場合、状態色と操作色の関係を確認します。

エラー通知内のすべてのリンクやボタンを赤にすると、破壊的操作と誤解される可能性があります。再試行などの通常操作はブランドカラー、削除や停止などの危険操作だけを赤にする方法があります。

9. アクセシビリティへ対応する

ステータスカラーは、色覚、弱視、画面環境、支援技術にかかわらず理解できる必要があります。色の選択だけでなく、文言、形状、HTML構造まで含めて確認します。

9.1 色だけに依存しない

成功を緑、エラーを赤だけで区別すると、色覚特性やモノクロ表示によって判断できない場合があります。状態名、アイコン、枠線パターンなどを追加します。

W3Cは、色で伝えられる情報を、テキストや別の視覚的手掛かりでも利用できるようにすることの利点を示しています。

9.2 文字のコントラストを確認する

WCAG 2.2のレベルAAでは、通常サイズの文字と背景に4.5対1以上、大きな文字には3対1以上のコントラスト比が求められます。

薄い成功背景に明るい緑文字、黄色背景に白文字などは、基準を満たしにくい組み合わせです。色を選んだ後ではなく、パレット作成中に計測します。

9.3 非テキスト要素を確認する

入力枠、状態アイコン、グラフの線など、状態理解に必要な非テキスト要素は、隣接する色とのコントラスト比3対1以上を確保します。

アイコンが装飾ではなく、状態を理解するために必要なら、背景へ十分に見える必要があります。薄い黄色の警告アイコンを白背景へ置く場合は特に注意します。

9.4 動的な状態を通知する

動的な成功や情報にはrole="status"、即時対応が必要な重大エラーにはrole="alert"を検討します。statusは穏やかに通知し、alertは現在の読み上げを中断する可能性があるため、使い分けが必要です。

9.5 色覚シミュレーションを行う

デザインツールの色覚シミュレーションを使い、赤と緑、青と紫、黄と薄い背景などが区別できるか確認します。

シミュレーションだけで合否を決めず、コントラスト計測、モノクロ表示、実機確認も組み合わせます。色が同じ灰色に見えても、アイコンと文字によって区別できる状態を目指します。

10. コンポーネント別に使い分ける

同じステータスでも、通知、フォーム、タグ、表、トーストでは適切な表現が異なります。コンポーネントの目的に合わせて強度と表示時間を設計します。

10.1 インライン通知

インライン通知は、関連するコンテンツの近くへ常設または長時間表示します。フォーム全体のエラー、設定に関する案内、機能制限などに適しています。

タイトル、説明、アイコン、必要なアクションを一つの領域へまとめます。背景色は薄くし、本文を読みやすくします。

<section  class="notice notice--warning"  aria-labelledby="warning-title" >  <h3 id="warning-title">    未保存の変更があります  </h3>  <p>    ページを移動すると変更内容が失われます。  </p> </section>

10.2 トースト通知

トーストは、操作結果を短時間知らせるために使います。保存成功、コピー完了、軽い失敗などが適しています。

重大なエラー、長い説明、複数の操作が必要な内容を、自動で消えるトーストだけに表示しないでください。利用者が再確認できる場所にも状態を残します。

10.3 フォーム検証

フォームでは、項目単位のエラーと、フォーム全体のエラーを分けます。問題のある入力欄の近くに説明を置き、送信時には最初のエラーへ移動しやすくします。

入力中に早すぎるエラーを表示すると、まだ入力を終えていない利用者を急かします。入力欄を離れたとき、または送信時に表示するなど、適切なタイミングを決めます。

10.4 タグとバッジ

タグやバッジは、表や一覧で状態を短く示します。「承認済み」「審査中」「却下」など、文字ラベルを必ず含めます。

背景を薄くして濃い文字を使う形式は、小さい面積でも読みやすくなります。色付きの小さな点だけで状態を表す場合は、近くに状態名を表示します。

<span class="status-tag status-tag--success">  承認済み </span> <span class="status-tag status-tag--warning">  審査中 </span> <span class="status-tag status-tag--error">  却下 </span>

10.5 表とダッシュボード

表では、多数の状態色が同時に表示されるため、背景面積を抑えます。文字と小さなアイコン、タグを組み合わせると、行全体を着色するより読みやすくなります。

ダッシュボードの数値では、色だけで良し悪しを判断させず、増減記号、ラベル、基準値を表示します。

11. ライトモードとダークモードを設計する

ライトモードの色を反転するだけでは、ダークモード用のステータスカラーになりません。暗い背景上での明度、彩度、面積、発光感を個別に調整します。

11.1 ダークモードの背景を作る

ダークモードでは、明るい色を広い背景へ使うと強く発光して見えます。状態色を混ぜた非常に暗い背景を用意し、その上へ明るい文字とアイコンを配置します。

例えば、エラー背景を鮮やかな赤にするのではなく、黒に近い暗赤色を使います。

11.2 ダークモードの文字色を作る

暗い背景では、ライトモードの濃い文字色は見えません。各色相の明るい段階を文字やアイコンへ使用します。

白に近すぎる色だけを使うと状態差が弱くなるため、コントラストを満たしながら色相も認識できる値を選びます。

11.3 彩度を調整する

ライトモードで使った鮮やかな基準色は、暗い背景上で強く見えることがあります。明度だけでなく彩度を下げ、長時間見ても疲れにくい色へ調整します。

一方、彩度を下げすぎると四つの状態が灰色に近付きます。実際の画面で、隣接した通知を比較します。

11.4 モードごとに個別検証する

ライトモードでコントラストを満たしていても、ダークモードで同じとは限りません。各モードで文字、背景、枠線、アイコンを個別に計測します。

半透明色を使う場合は、その背後にある色によって最終表示が変わります。代表的な背景上で確認してください。

11.5 モード対応トークンを作る

基礎色の名前を直接コンポーネントへ使わず、status-success-backgroundのような意味トークンを参照します。ライトとダークでトークンの値だけを切り替えます。

:root {  --status-success-text: #166534;  --status-success-border: #16a34a;  --status-success-background: #f0fdf4; } [data-theme="dark"] {  --status-success-text: #bbf7d0;  --status-success-border: #4ade80;  --status-success-background: #052e16; }

12. デザイントークンとして管理する

ステータスカラーは、色名ではなく意味を表すトークンとして管理します。コンポーネントが特定の緑や赤へ直接依存しない構造を作ります。

12.1 基礎カラートークンを作る

基礎トークンは、色相と明度段階を表します。例えばgreen-50、green-600、red-50、red-600という形式です。

基礎トークンは色そのものを管理し、状態の意味を持たせません。パレット変更時の土台になります。

:root {  --green-50: #f0fdf4;  --green-600: #16a34a;  --green-800: #166534;  --red-50: #fef2f2;  --red-600: #dc2626;  --red-800: #991b1b; }

12.2 意味トークンを作る

意味トークンは、成功、警告、エラー、情報という役割を表します。基礎トークンを参照して値を設定します。

色相を変更しても、コンポーネント側はstatus-successという意味を維持できます。

:root {  --status-success-text: var(--green-800);  --status-success-icon: var(--green-600);  --status-success-border: var(--green-600);  --status-success-background: var(--green-50); }

12.3 コンポーネントトークンを作る

通知、タグ、入力欄などで意味トークンを直接使えない場合は、コンポーネントトークンを作ります。

例えば、通知の成功背景と、成功タグの背景で濃さを変えたい場合に使用します。

12.4 色名を意味名に置き換える

text-redやbackground-greenというクラス名は、色を変更すると意味と一致しなくなります。text-error、background-successのように役割で命名します。

12.5 JSONでトークンを共有する

{  "status": {    "success": {      "text": {        "value": "#166534"      },      "border": {        "value": "#16A34A"      },      "background": {        "value": "#F0FDF4"      }    },    "error": {      "text": {        "value": "#991B1B"      },      "border": {        "value": "#DC2626"      },      "background": {        "value": "#FEF2F2"      }    }  } }

JSONなどの共通形式で管理すると、Web、モバイル、Figmaへ値を展開しやすくなります。

13. Figmaでステータスカラーを管理する

Figmaでは、カラー変数、スタイル、コンポーネントのバリアントを組み合わせて管理します。デザイナーが自由な緑や赤を追加しない仕組みを作ります。

13.1 基礎パレットを登録する

最初に、緑、黄、オレンジ、赤、青の明度段階をカラー変数として登録します。

基礎色はデザインシステム管理者が使用し、通常の画面設計では意味変数を選ぶ運用にすると、誤用を減らせます。

13.2 意味変数を登録する

Status/Success/Text、Status/Error/Backgroundのように、役割と用途を表す変数を作ります。

意味変数が基礎変数を参照する構造にすると、パレット変更時に画面側の割り当てを変更せずに済みます。

13.3 モードを作る

ライトモードとダークモードを変数のモードとして管理します。同じStatus/Success/Backgroundでも、モードごとに異なる値を設定します。

画面側は同じ変数を使い、フレームのモード変更だけで表示を切り替えられます。

13.4 通知コンポーネントを作る

通知コンポーネントには、成功、警告、エラー、情報のバリアントを作ります。アイコン、背景、枠線、見出しをバリアントごとに切り替えます。

13.5 使用例と禁止例を記載する

色見本だけでなく、どの状態を選ぶか、どの組み合わせを避けるかをドキュメント化します。

成功と通常状態、警告とエラー、情報とリンクの違いを具体例で示すと、デザイナーごとの判断差を減らせます。

14. CSSでステータスカラーを実装する

CSSでは、基礎値、意味変数、コンポーネントスタイルを分けます。状態ごとに同じ構造を使い、値だけを変更できる設計にします。

14.1 CSS変数を定義する

:root {  --status-success-text: #166534;  --status-success-icon: #16a34a;  --status-success-border: #86efac;  --status-success-background: #f0fdf4;  --status-warning-text: #713f12;  --status-warning-icon: #ca8a04;  --status-warning-border: #fde047;  --status-warning-background: #fefce8;  --status-error-text: #991b1b;  --status-error-icon: #dc2626;  --status-error-border: #fca5a5;  --status-error-background: #fef2f2;  --status-info-text: #1e40af;  --status-info-icon: #2563eb;  --status-info-border: #93c5fd;  --status-info-background: #eff6ff; }

14.2 共通通知スタイルを作る

.notice {  display: grid;  grid-template-columns: auto 1fr;  gap: 0.75rem;  padding: 1rem;  border: 1px solid;  border-radius: 0.5rem; } .notice__icon {  width: 1.25rem;  height: 1.25rem; } .notice__title {  margin: 0;  font-weight: 600; } .notice__body {  margin: 0.25rem 0 0; }

共通構造を一度定義し、状態クラスでは色だけを変更します。

14.3 状態別クラスを作る

.notice--success {  color: var(--status-success-text);  border-color: var(--status-success-border);  background: var(--status-success-background); } .notice--success .notice__icon {  color: var(--status-success-icon); } .notice--warning {  color: var(--status-warning-text);  border-color: var(--status-warning-border);  background: var(--status-warning-background); } .notice--error {  color: var(--status-error-text);  border-color: var(--status-error-border);  background: var(--status-error-background); } .notice--info {  color: var(--status-info-text);  border-color: var(--status-info-border);  background: var(--status-info-background); }

14.4 タグを実装する

.status-tag {  display: inline-flex;  align-items: center;  min-height: 1.5rem;  padding-inline: 0.5rem;  border-radius: 999px;  font-size: 0.875rem;  font-weight: 600;  line-height: 1.25rem; } .status-tag--success {  color: var(--status-success-text);  background: var(--status-success-background); } .status-tag--warning {  color: var(--status-warning-text);  background: var(--status-warning-background); } .status-tag--error {  color: var(--status-error-text);  background: var(--status-error-background); } .status-tag--info {  color: var(--status-info-text);  background: var(--status-info-background); }

14.5 HTMLへ適切な意味を追加する

<div  class="notice notice--success"  role="status" >  <span    class="notice__icon"    aria-hidden="true"  >    ✓  </span>  <div>    <p class="notice__title">      保存しました    </p>    <p class="notice__body">      プロフィールの変更を反映しました。    </p>  </div> </div>

すべての通知へ同じARIAロールを付けるのではなく、内容の緊急度と表示タイミングに合わせて選びます。軽い更新はstatus、即時対応が必要な動的エラーはalertが候補です。

15. 実務でステータスカラーを構築する手順

最後に、既存のUIまたは新しいデザインシステムへ、ステータスカラーを導入する流れを整理します。

15.1 既存の状態表示を調査する

最初に、製品内で使われている緑、黄、オレンジ、赤、青を収集します。通知、フォーム、タグ、表、グラフ、ボタンを確認します。

同じエラーに複数の赤が使われていないか、同じ青がリンクと情報背景に混在していないかを確認します。

15.2 状態の定義を決める

色を選ぶ前に、成功、警告、エラー、情報の使用条件を文章で定義します。

「黄色は注意に使う」という色基準ではなく、「続行できるが、望ましくない結果の可能性がある状態を警告とする」という意味基準を作ります。

15.3 パレットを作成する

各状態について、基準色、濃い文字色、薄い背景色、枠線色、ダークモード色を作ります。

パレット作成時に、通常文字4.5対1以上、状態理解に必要な非テキスト要素3対1以上を確認します。

15.4 代表コンポーネントで検証する

通知、フォームエラー、タグ、表、トーストへ適用します。一つの通知だけで判断せず、四状態を並べた画面や、多数のタグが表示される画面でも確認します。

色覚シミュレーション、モノクロ、ライトモード、ダークモード、文字拡大も試します。

15.5 トークン化して運用する

承認した色は、Figma変数、CSS変数、デザイントークンへ登録します。新しい状態色を追加する条件と、既存色を変更する手順も定めます。

実務では、次の流れで進めると管理しやすくなります。

1. 現在使われている状態色を収集する
2. 成功・警告・エラー・情報の意味を定義する
3. ブランドカラーとの重複を確認する
4. 各状態の基準色を選ぶ
5. 文字、背景、枠線、アイコン色を作る
6. ライトモードとダークモードを設計する
7. 文字のコントラストを計測する
8. アイコンや枠線のコントラストを計測する
9. 色以外のアイコンと文章を追加する
10. 通知、フォーム、タグ、表へ適用する
11. Figmaの意味変数へ登録する
12. CSSとデザイントークンへ反映する
13. 動的通知へ適切なARIAを設定する
14. 色覚シミュレーションと実機確認を行う
15. 使用例と禁止例を文書化する

おわりに

成功、警告、エラー、情報のステータスカラーは、単に緑、黄、赤、青を割り当てるだけでは完成しません。それぞれの意味と利用者が取るべき行動を定義し、文字、背景、枠線、アイコン、メッセージを一つの体系として設計する必要があります。

成功は期待どおりに完了した状態、警告は続行できるが注意が必要な状態、エラーは修正または再試行が必要な状態、情報は判断を助ける中立的な案内として使います。色を選ぶ前に、この意味の違いをチーム内で共有してください。

また、色だけに依存せず、状態名、アイコン、文章を併用することが重要です。文字と背景、アイコンと背景のコントラストを計測し、ライトモードとダークモードの両方で確認します。

完成した色は、status-success-text、status-warning-backgroundのような意味トークンとして管理します。FigmaとCSSで同じ命名を使用することで、プロダクト全体へ一貫した状態表現を適用でき、将来の配色変更にも対応しやすくなります。