ダークモードUI設計：配色・コントラスト・コンポーネントの状態

ダークテーマには、読みやすい文字、見分けやすい操作部品、そして画面の各面の関係が分かる配色が必要です。白い背景を黒に変えるだけでは十分ではありません。このガイドでは、色の役割を決め、ライトとダークの両方のデザインで共通して使う方法を説明します。

Pixsoのデザインシステム共有ワークスペースでは、再利用するコンポーネントやスタイルを用途ごとに整理できます。多くの画面へテーマを展開する前に、名前と期待する見た目について開発者と合意しておきましょう。

暗い背景と読みやすい文字の組み合わせを選ぶ

ダークUIでは、背景、カードなどの面、文字の関係を意図的に設計します。背景には純粋な黒もダークグレーも使えます。表示する内容、利用環境、面同士に必要な区別を基に選び、実際に使う前景色と背景色の組み合わせを確認してください。

ダークテーマで必ず使うべき16進カラーコードはありません。よく使われるダークグレーを出発点にすることはできますが、人気のある色だからといって、その上や隣に置くすべての色が見やすくなるわけではありません。

暗い背景に非常に明るい文字を表示すると不快に感じる人もいれば、その配色を好む人もいます。特定の色の組み合わせに誰にでも当てはまる医学的効果があるとは言えません。文字の読みやすさを確保し、利用者の好みを尊重しながら、実際の利用条件で画面を評価しましょう。

面と文字には、少数の明確な役割を設けます。ベースとなるキャンバス、カード、オーバーレイは、境界が分かるように塗りや枠線を変える必要がある場合があります。主となる文字と補足の文字は別々に確認してください。見出しに十分なコントラストがあっても、補足文を薄くしすぎると読みにくくなります。

ブランドカラーを用途に合わせて調整する

明るいページで使えるブランドのアクセントカラーでも、暗い面では別の色値が必要になることがあります。テキストリンク、ボタンの背景、選択済みの操作部品、装飾図形など、実際の用途ごとに評価してください。用途によって周囲の色や求められる条件が異なります。

すべての色の彩度を一律に下げるのではなく、検証で問題が見つかった場合に明度や彩度を調整します。ブランドらしさが分かる関係を保ちつつ、ダークテーマでも読みやすく、区別しやすい色値を選びましょう。

視覚的な強調は、特に重要な操作や状態に使います。操作部品に加えて、ロゴやイラストも確認してください。背景が白で固定された素材にはダークテーマ用の別バージョンが必要になる一方、そのまま使える画像もあります。

テーマに関する決定を一か所にまとめる

共有コンポーネントと名前を付けたカラースタイルを使うと、変更内容を確認しやすくなります。代表的なライト画面とダーク画面を並べて管理し、ラベルやコンポーネントの構造を変更したときに、片方の仕様だけが不明なまま残らないようにします。

デザインツールは見た目の仕様を管理するために役立ちますが、アプリケーション側にはテーマを選択するロジックと、その実装が必要です。キャンバス上のプレビューが正しく表示されても、実際の製品ですべての状態が正しく切り替わることの証明にはなりません。

合意したテーマの色値、コンポーネントの例、未解決の疑問は、デザインの近くにまとめておきます。チームのコメント機能で特定の面や状態について話し合い、実装に渡すバージョンがどれなのかを明確にしてください。

色には目的が分かる名前を付ける

色の名前が用途を表していれば、管理しやすくなります。大規模なシステムでは、生の色値、意味に基づく役割、コンポーネント固有の役割を分ける方法があります。小規模な製品なら、必要のない3層構造を作るより、少数の役割から始められます。

生の色値には、Gray-900やBlue-500のように、使える色そのものを表す名前を付けます。これはパレット内の色を示す名前であり、ページ背景に使うのか、選択済みの操作部品に使うのかまでは説明しません。

セマンティックな役割は、ページ背景、手前に浮いた面、主となる文字、補足の文字、重大なメッセージといった用途を示します。役割の意味を変えずに、ライトとダークそれぞれに適した色値を割り当てられます。

コンポーネント固有の役割は、フォーカスされた入力欄の枠線など、操作部品についてより具体的な指定が必要な場合に役立ちます。個々のインスタンスすべてに別のトークンを作るのではなく、実際の挙動を明確にできる箇所へ追加しましょう。

共有する役割ごとにライト用とダーク用の両方の色値を記録し、対応するColor Styles（カラースタイル）を代表的なフレームへ適用します。これらの名前を実装上の名前にどう対応させるかも合意してください。デザインファイルとアプリケーションで保存形式が異なっていても、役割と色値の対応表があれば仕様を伝えられます。

色値を変更したら、その色を使うコンポーネントを見直します。ページ上のラベルを読みやすくする色が、アクセント色のボタン内にあるラベルでは逆効果になることもあります。共有スタイルは繰り返しの編集を減らしますが、色の組み合わせの確認まで不要になるわけではありません。

実装の次の段階では、デザイントークンによるテーマ切り替え（英語ガイド）を検討します。モード間で色値が変わっても、それぞれの色が担う意味は一貫させます。

面とオーバーレイを見分けやすくする

ダークUIでも、画面の奥行きが理解できることが大切です。ライトUIでは、影がオーバーレイと背後のページを区別する手がかりになります。ただし、影は複数ある手がかりの一つであり、すべてのオーバーレイに必須ではありません。

暗い背景では、影が見えにくい場合があります。濃い影一つで階層全体を表そうとせず、塗り、枠線、余白、影を適切に組み合わせて、面同士を区別しましょう。

一つの方法は、ベースを暗くし、カードやオーバーレイを少し明るくすることです。これは評価すべき相対的な関係であり、どの製品にも当てはまる固定の明るさではありません。画像やアクセント色の領域も含め、オーバーレイが重なる可能性のあるすべての面との組み合わせを比較してください。

控えめな枠線は、重なったメニューの端を明確にできます。ただし、合成後の実際の色は不透明度と背後の背景色によって変わるため、描画された結果を評価します。一枚のサンプルカードで見栄えがよかったという理由だけで、低い不透明度の白い枠線を選ばないようにしましょう。

コンポーネントの状態とコントラストを確認する

ボタン、フォームの入力欄、表、ダイアログなど、ダークテーマで使うコンポーネントを見直します。通常、ホバー、フォーカス、押下中、選択済み、無効、エラーなど、それぞれに必要な状態を確認してください。メインフレームの背景を変更するだけでは、これらの組み合わせを確認したことにはなりません。

WCAG 2.2のレベルAAでは、通常の文字には原則として4.5:1以上、大きな文字には3:1以上のコントラスト比が必要で、達成基準には例外も定められています。W3Cのコントラストに関する解説（英語）で適用される条件を確認してから、実際の色を測定してください。

対象となる前景色と背景色の組み合わせごとに、コントラストチェッカーで確認します。通常時のボタンだけでなく、選択済み、ホバー、フォーカス、エラーの各状態も含めてください。エラーには文章と役立つ案内を添え、状態の違いを色だけに頼らず伝えます。コントラストの測定はアクセシビリティ評価の一部であり、それだけですべての要件を満たしたとは言えません。

具体例：外観設定パネルを設計する

「ライト」「ダーク」「システムに従う」の選択肢、短い説明文、保存完了の通知を持つ設定パネルを例にします。この小さな画面なら、ダッシュボード全体を作り直さなくても、複数の役割を確認できます。

「システムに従う」が有効な状態から「ダーク」を選ぶ、再び「システムに従う」へ戻す、パネルを開き直す、という操作を試します。保存に失敗した場合、未保存の選択肢を確定済みの設定であるかのように黙って表示してはいけません。選択した設定と、プレビューが現在表示している外観を区別して扱いましょう。

次に、パネルの上にオーバーレイを開きます。その境界、閉じる操作、フォーカス状態が引き続き明確か確認してください。色見本だけを並べたシートでは分からない組み合わせを見つけられます。

テーマの挙動を開発用の仕様にまとめる

製品が外観をどのように選ぶかを決めます。使いやすい選択肢の一例は「ライト」「ダーク」「システムに従う」です。「システムに従う」は端末の設定を使い、明示的な選択があればそれを優先できます。次回のアクセス時やOSの設定変更時にどう動くかも指定してください。

両テーマの色の役割、選択時の挙動、合意したデザインのバージョンを開発者へ渡し、該当するPixsoの画面の近くにまとめておきます。設定の保存、システムの外観設定への対応、実際のコンポーネントの各状態は、開発者が実装する必要があります。

まず、通常の文章、入力欄、選択項目、オーバーレイを含む代表的な画面を一つ用意します。それらの状態が一貫して機能することを確認できたら、同じ役割をほかの画面へ広げ、グラフ、イラスト、埋め込みコンテンツなどの例外を見直してください。