ダークモード実装が教える、Next.jsを読む前に知るべき設計の原則

May 02, 2026

1 min read

3 views

71%

最初に問うべきは、色ではなく構造である

ダークモードの実装は、見た目の話に見えて、実は設計思想の話です。多くの人は「ライトとダークで色を切り替えるにはどうするか」を考えますが、本当に重要なのはそこではありません。問うべきなのは、変化しうるものをどこに閉じ込め、変化してほしくないものをどこに固定するかです。

この問いは、UIの配色にも、フロントエンドのフレームワークにも、そのまま通じます。CSS変数で色の意味を定義し、Tailwindのカスタムカラーにその意味を接続するやり方は、単なる実装テクニックではありません。意味と見た目を分離し、変化の責任を一箇所に集めるという、非常に強い設計の型です。

Next.jsを理解するうえでも、この視点は決定的です。フレームワークの価値は、機能の多さではなく、複雑さの置き場所を決めてくれることにあります。つまり、ダークモードの設計とNext.jsの考え方は、同じ核心を別の角度から見ています。アプリケーションは、変化の管理技術であるということです。

ダークモードの本質は「色替え」ではなく「意味の固定」

ダークモード実装でつまずくのは、多くの場合、色そのものを直接扱ってしまうからです。ボタンはこの青、背景はこの白、テキストはこの黒、と具体色を各所に散らばらせると、テーマが増えた瞬間に崩壊します。変更が必要になったとき、修正箇所は増殖し、意図は失われます。

ここで効くのが、色を意味へ変換する発想です。たとえば background, foreground, muted, accent のような役割名を先に定義し、その意味に対してCSS変数で実際の色を割り当てます。すると、UIコンポーネントは「何色か」ではなく「何の役割か」だけを知ればよくなります。

この構造は、キッチンの調味料棚に似ています。料理人が毎回「塩はどのブランドか」を気にするのではなく、「塩味を足す」という役割を知っていればよい。ブランドが変わっても、料理の設計は変わりません。UIでも同じで、見た目の値は交換可能でも、意味のレイヤーは安定しているべきです。

優れたデザインシステムは、色を管理するのではない。色の意味を管理する。

この考え方の強さは、将来の変更に耐える点にあります。ライトモードとダークモードだけでなく、ハイコントラスト、ブランド別テーマ、季節限定テーマまで、同じ仕組みで拡張できます。変更のたびにコンポーネントを作り直すのではなく、意味のマッピングを差し替えるだけで済むからです。

Next.jsが扱っているのは「ページ」ではなく「責務の分配」

Next.jsについて語るとき、しばしば「Reactで何が便利になるか」に話が寄ります。しかし本質は、画面を作ることよりも先に、どの責務をどこに置くかを決めやすくする点にあります。データ取得、レンダリング、ルーティング、最適化、配信の境界を整理し、アプリの複雑さを扱いやすい形へ圧縮する。ここに価値があります。

これはダークモードのCSS変数設計と驚くほど似ています。コンポーネントの中に直接色を書けば、その場では速く見えるかもしれません。しかしそれは責務の侵食です。見た目の変更がロジックの隣に散らばると、変更コストが増え、認知負荷も上がります。Next.jsはこの問題を、構造のレベルで減らそうとします。

たとえば、商品一覧ページを考えてみます。商品取得、表示、絞り込み、ページング、SEO対応、レスポンシブ対応が一つのファイルに混ざっていたら、機能追加のたびに怖くなります。けれども、責務が整理されていれば、データはデータ、画面は画面、テーマはテーマとして扱えます。変更しやすさは、分離の質で決まるのです。

ここで重要なのは、分離とは「バラバラにすること」ではない、という点です。むしろ逆で、変える場所を少なくするために、構造を分けるのです。CSS変数とTailwindの組み合わせが有効なのも、色を散らすからではなく、色の入口を一箇所に集めるからです。Next.jsの価値も同様で、責務を増やすのではなく、責務の境界を明確にすることで、全体をシンプルに保ちます。

良い抽象化は、自由を増やすのではなく、変更の恐怖を減らす

抽象化というと、「何でもできるようになること」だと誤解されがちです。しかし本当に優れた抽象化は、自由度を無限に増やすものではありません。将来の変更に対する恐怖を下げるものです。

ダークモードの設計でCSS変数を使うと、画面の各所に散っていた具体色が、役割名に置き換わります。すると、デザイナーが配色を変えたいときも、開発者がコンポーネントを調整したいときも、互いの変更が衝突しにくくなります。これは単なる見た目の話ではなく、チームの協働の話です。

Next.jsの「考え方」も同じで、フレームワークは単に便利なAPI集ではありません。開発者が「これはどこに置けばよいか」を迷いにくくする、いわば意思決定の足場です。どこでデータを取るか、どこで表示するか、どこで最適化するか。こうした判断のガイドラインがあると、実装速度は上がるだけでなく、レビューや保守も楽になります。

ここから見えてくるのは、設計の目的は「未来を予測すること」ではない、という事実です。未来は予測できません。だからこそ、変化が起きたときに破綻しないよう、変更点を隔離する。設計とは、未来を当てる技術ではなく、未来に耐える技術です。

抽象化の価値は、難しいことを隠すことではない。変更の影響範囲を狭めることにある。

この視点を持つと、ダークモードの実装もNext.jsの採用も、単なる「楽になる選択」ではなくなります。どちらも、将来のチームと将来の自分に対する投資です。今の実装が少し遠回りに見えても、変更が増えるほど、その差は大きくなります。

ひとつの設計原則で、UIもフレームワークも見通せる

ここまでを一つの原則に圧縮すると、答えはこうなります。変わりやすいものは境界の内側に閉じ込め、意味のある名前だけを外に出す。ダークモードでは、具体色を内側に閉じ込め、background や primary のような意味を外に出します。Next.jsでは、配信やレンダリングの複雑さを内側に閉じ込め、ページやコンポーネントには理解しやすい責務だけを見せます。

この原則は、実装における判断基準として強力です。コードを書くとき、次の質問を自分に投げてみてください。

これは意味なのか、実体なのか。
これは今後変わる可能性が高いのか、低いのか。
これはどこに置けば、変更の影響が最小になるのか。

たとえばボタンの色を直接 #1d4ed8 のように書くのは、実体を露出させるやり方です。一方で text-primary のようなクラス名を使えば、ボタンは「primaryである」ことだけを知り、実際の色はテーマ層に任せられます。Next.jsでも、データ取得の詳細を画面の隅々に散らすのではなく、責務を集約することで、画面はより単純な意味だけを持てます。

この原則が身につくと、設計の見え方が変わります。良いコードとは、短いコードではありません。変更のたびに読み直す範囲が小さいコードです。ダークモードの変数設計とNext.jsの責務分割は、そのための具体的な道具立てです。

Key Takeaways

色を直接管理しない。色の意味を管理する。 background や primary などの役割名を先に定義し、実際の色はCSS変数に閉じ込める。
コンポーネントは実体ではなく役割を見るべき。 UI部品が知るべきなのは「何色か」ではなく「何のための色か」。
フレームワークの価値は、責務の置き場所を決めてくれること。 Next.jsの強みは、複雑さを消すことではなく、複雑さの境界を整理することにある。
変更しやすさは、抽象化の品質で決まる。 良い抽象化は自由を増やすのではなく、変更の影響範囲を狭める。
設計の判断は三問で十分に鋭くなる。 それは意味か、実体か。変わるか、変わらないか。どこに置けば一番壊れにくいか。

変化を怖がらないための設計へ

ダークモードの実装とNext.jsの考え方が重なって見えるのは偶然ではありません。どちらも、本当のテーマは「機能」ではなく、変化との付き合い方だからです。見た目を変えるときも、アーキテクチャを選ぶときも、私たちは同じことをしています。未来の変更が、今の構造をどれだけ壊すかを見積もっているのです。

だから、設計は最初から壮大である必要はありません。むしろ大切なのは、変わる場所を見極める目を持つことです。色は変わる。レイアウトも変わる。データの取得方法も変わる。ならば、変わるものを前面に出さず、変わらせたい意味だけを残す。その姿勢が、UIを美しくし、コードを長持ちさせ、チームを強くします。

最後に残るのは、こういう問いです。あなたが今設計しているものは、見た目を整えているだけでしょうか。それとも、未来の変更に耐えられる意味の構造を作っているでしょうか。もし後者なら、あなたはもう単に画面を作っているのではありません。変化に強い思考そのものを実装しているのです。