要件表に「ダークモード対応」と一行だけ書かれていることがあります。見積もりの段階では小さな項目に見えます。実装に入ると、これが3つの作業に分かれます。配色の二重定義、切り替えUI、そして選択状態の保存です。
このうち工数を最も食うのは、たいてい3つ目です。 特に「ライト／ダーク／システム設定に従う」の3択を用意した場合、保存すべき状態が3通りになり、初期表示のちらつき（FOUC）対策も3通りの分岐を持ち、QAの確認パターンはOSの設定と掛け合わさって6通りになります。
その3択が本当に必要かという問いが、2026年8月に改めて議論になりました。
3択が増やしているのは、選択肢ではなく検証パターン
Lea Verou が提起したのは、3状態を露出させることはデータモデルをそのままUIに出しているだけではないか、という指摘です。内部的には確かに3つの状態があります。ユーザーが明示的にライトを選んだ、ダークを選んだ、何も選んでいない（OS設定に従う）。しかしユーザー側から見ると、ある瞬間においてそのうち1つは常に無関係 です。
理屈はこうです。ダークモードの切り替えは、その場の見づらさを直すための一時的な操作です。ユーザーの目的は2つしかありません。「今の見え方で問題ないので、そのまま読む」か、「明るすぎる／暗すぎるので直したい」か。いま起きていない問題について意思表示させる選択肢は、そもそも選ばれません。
制作側にとっての具体的な影響は、検証の掛け算です。
| 切り替え方式 | 保存する状態 | QAで確認する組み合わせ |
|---|---|---|
| 3択（ライト／ダーク／システム） | 3通り | OS設定2通り × 保存値3通り = 6 |
| 2択（ライト／ダーク・初期値はOS） | 2通り＋未設定 | OS設定2通り × 保存値2通り＋未設定 = 4 |
数字だけ見れば6が4に減るだけですが、実際には「システムを選んだ状態でOS設定が変わったとき」という、再現に手間のかかるケースが丸ごと消える のが効きます。
2状態でも「システム追従」は失われない
ここが誤解されやすいところです。3択をやめる＝OS設定を無視する、ではありません。
推奨される形はこうです。何も選んでいない初期状態では OS の設定に従う。ユーザーが切り替えを押した時点で、その選択を上書きとして保存する。 保存先は localStorage で構いません。
つまり「システムに従う」は選択肢としてUIに出さないだけで、状態としては最初から存在しています。ユーザーが一度も触らなければ、その状態が続きます。
実装の骨格は次のようになります。ちらつきを避けるため、保存値の反映はスタイルシートの適用前、head 内の同期スクリプトで行います。
<script>
// 保存された上書きがあれば適用。無ければ何もせずOS設定に委ねる
const saved = localStorage.getItem("color-scheme");
if (saved === "light" || saved === "dark") {
document.documentElement.style.colorScheme = saved;
}
</script>:root {
/* 上書きが無いときはOS設定に従う */
color-scheme: light dark;
}
body {
background: light-dark(#ffffff, #14171a);
color: light-dark(#1a1a1a, #e8e8e8);
}切り替えボタン側は、現在の実効値を見て反対側の値を保存するだけです。「システムに戻す」導線を用意しない代わりに、保存処理と分岐が1本になります。
なお light-dark() と color-scheme の組み合わせは、配色定義そのものを二重管理から解放します。この関数を含む近年のCSS実装標準をどこまで採用するかの判断はState of CSS 2026 から見る採用順で整理しています。
3択が正当化される設計もある
一律に2択が正しいわけではありません。Verou 自身も例外を挙げています。配色がOS側の設定を踏まえて明るさを調整する設計になっているなら、3状態はUIに出る資格がある という整理です。
具体的には、OSがダークのときのダークテーマと、OSがライトのときにユーザーが明示的に選んだダークテーマとで、コントラストや輝度を変えている場合です。この設計では3つの状態が実際に3つの異なる見た目を生むため、選択肢として意味を持ちます。
また、この論点には反論も出ています。3状態のトグルを擁護する立場からは、ユーザーが「自分は明示的に選んだのか、OSに従っているだけなのか」を確認できること自体に価値がある、という指摘があります。設定画面の性格が強いUI、つまりユーザーが腰を据えて自分の環境を整える場所では、この主張のほうが妥当な場面もあります。
判断軸としては、切り替えが「読んでいる途中の一時的な調整」なのか「アカウント設定の一項目」なのかで分かれます。コーポレートサイトやメディアサイトのヘッダーに置くトグルは前者です。管理画面やSaaSの設定ページは後者に寄ります。
受託の要件定義で先に決めておくこと
制作を請ける側として、この論点は着手前に片付けておく価値があります。実装が済んでから「システムに戻すボタンが無い」と指摘されると、保存処理とQAをやり直すことになるためです。
要件定義の段階で確認するのは次の3点です。
- 切り替えUIをどこに置くか（ヘッダー常設か、設定ページ内か）
- OS設定を踏まえた明るさの出し分けをするか（するなら3状態が要る）
- 保存の範囲（ブラウザローカルか、ログインユーザーに紐づけるか）
2番目に「しない」と答えが出るなら、2状態で確定できます。この一問だけで、後工程の分岐が減ります。 3番目は、ログイン機能があるサイトで見落とされがちです。端末をまたいで設定を引き継ぐ要求があるなら、保存先はサーバー側になり、要件の重さが変わります。
配色そのものの設計、特にコントラスト確保の考え方についてはコントラスト自動調整の使いどころが参考になります。
次にやること
いま制作中、あるいは保守しているサイトで、ダークモードの切り替えが3択になっているなら、アクセス解析やイベント計測で「システム」を選んだユーザーがどれだけいるかを見てください。 ほぼゼロであれば、その選択肢は検証コストだけを発生させています。
新規案件なら、要件表の「ダークモード対応」の行に「切り替えは2状態、初期値はOS設定に従う」と1行足しておく。それだけで、実装とQAの前提が揃います。
サイトのリニューアルや既存サイトのデザインシステム整備、配色まわりの実装標準の策定については、グリームハブのHP制作・リニューアル相談で承っています。既存実装の構成によって改修範囲が変わるため、個別にお見積りします。お問い合わせからご相談ください。
