UIデザインをゼロから作る ― 近接とコントラスト、開発者が最初に押さえるべき2原則

はじめに

フロントエンド開発において「どうやってデザインすればいいかわからない」は永遠の悩みです。

• 「何から手をつければいいの？」
• 「なんとなくダサいけど、何が悪いかわからない」
• 「デザイナーがいない場合、どこまで自分でできる？」

この問題に対して、デザインの世界には4つの基本原則があります。Robin Williamsの『ノンデザイナーズ・デザインブック』で提唱された、近接・整列・反復・コントラスト（CRAP原則）です。^[1]

原則	意味
近接（Proximity）	関連する要素をグループ化する
整列（Alignment）	要素を見えないラインに沿って揃える
反復（Repetition）	視覚的要素を全体で繰り返す
コントラスト（Contrast）	要素間の重要度の差を明確にする

なぜ「近接」と「コントラスト」が特に重要なのか

4原則すべてが大切ですが、開発者が特に意識すべきは近接とコントラストです。

理由は、整列と反復は現代のツールが実装を補助してくれるからです。もちろん「何を基準に揃えるか」「どのパターンを反復すべきか」の判断は人間が必要ですが、一度決めれば実装はツールに任せられます。

原則	ツールによる実装サポート
整列	Figmaのオートレイアウト、CSSのFlexbox/Grid
反復	コンポーネント化、デザインシステム、Tailwindのユーティリティクラス

Figmaのオートレイアウトは「ボタン内のテキストが変わっても自動でリサイズ」「リストの並び替えで自動で再配置」を実現します。^[2] shadcn/uiのようなコンポーネントライブラリを使えば、「統一されたデザイン」は最初から担保されます。^[3]

一方、近接とコントラストは設計者の意図がなければ生まれません。また、これらは「一度決めれば終わり」ではなく、画面ごとに判断が必要です。

• 「どの要素とどの要素が関連しているか」（近接）
• 「どの要素が最も重要か」（コントラスト）

これらはドメイン知識やユーザーの目的を理解している人間が決める必要があります。

この考え方は、Nielsen Norman Groupがデザインタスクを「戦術的タスク」と「戦略的タスク」に分類した議論と通じます。^[4]

Tactical tasks, like organizing raw data or generating quick mockups, are good candidates for automation because they follow predictable patterns. Offloading these tasks to AI can save hours of effort, freeing up time and mental energy for designers to focus on high-impact activities.

— Nielsen Norman Group ^[4:1]

（訳：データ整理やモックアップ生成のような戦術的タスクは、予測可能なパターンに従うため自動化に適している。これらをAIに任せることで、デザイナーはより影響度の高い活動に集中できる。）

この分類を4原則に当てはめると：

タスクの種類	4原則での例	自動化適性
戦術的タスク	整列の実装、パターンの反復適用	ツール/AIが得意
戦略的タスク	何を強調するか、どうグルーピングするか	人間の判断が必要

生成AIにUIを作らせても、整列や反復はきれいに出てきます。しかし「この画面で最も重要なのは何か」「どの情報をグループ化すべきか」は、要件を理解している人間が指示しなければ適切に表現されません。

本記事では、この近接とコントラストを軸に、ゼロからデザインを作り上げるプロセスを解説します。

---

Part 1: 原則編 - 何を意識するか

---

第1章：近接 - グルーピングで関係性を示す

近接の原則とは

近接の原則は、関連する要素を近くに、関連しない要素を離すことです。

Items relating to each other should be grouped closely together. When several items are in close proximity, they become one visual unit rather than several separate units.

— The Non-Designer's Design Book ^[1:1]

（訳：関連する項目は近くにグループ化すべきだ。複数の項目が近接していると、別々の単位ではなく1つの視覚的単位になる。）

これは単純に見えますが、情報の構造を理解していないと実践できません。

なぜ近接が重要か

近接ができていないと、ユーザーは情報の関係性を読み取るのに認知的負荷がかかります。^[5]

たとえば名刺のデザインで、会社名がカードの真ん中、担当者名が左上、電話番号が右下にあると、「この情報はどう関係しているのか」を理解するのに時間がかかります。

近接を適用すると：

• 会社情報（会社名、住所）→ 1つのグループ
• 担当者情報（名前、役職、連絡先）→ 1つのグループ

情報が組織化され、瞬時に構造が伝わります。

近接の判断基準

「何を近くに置くか」は、以下の問いで判断できます：

1. 同じカテゴリか？ - 名前と役職は同じ「人物情報」
2. 同時に使うか？ - 電話番号とメールアドレスは同時に参照される
3. 同じ文脈か？ - 商品名と価格は同じ購買判断の文脈

補足：近接とドメインモデリング

実は、近接の原則はドメインモデリングの凝集性（Cohesion）と同じことを言っています。

• UIの近接: 関連する視覚要素をグループ化
• モデリングの凝集性: 関連するデータ・振る舞いをグループ化

どちらも「関連するものを近くに、関連しないものを離す」という同じ原理です。^[6]

運用を見据えたUIを設計するなら、「このUIで扱っているモデルは何か」「それぞれのモデルの責務は何か」を先に整理することで、近接の判断基準が明確になります。見た目を整えているつもりが、実はドメイン設計をしているのです。

ただし、プロトタイプ段階では見た目ベースで近接を決めてOKです。検証が目的なら、まず動くものを作ることが優先されます。

---

第2章：コントラスト - 要素の優先度を明確にする

ビジュアル階層 - デザインが「良く見える」最大の要因

「このデザイン、なんかいい感じ」の正体は何でしょうか。

色使い？フォント選び？余白の取り方？

もちろんそれらも重要ですが、最も影響度が高いのはビジュアル階層（Visual Hierarchy）です。

ビジュアル階層とは、画面上の要素に「重要度の順位」が視覚的に表現されている状態です。

これは大げさではなく、デザインの良し悪しを決定づける最大の要因です。配色が微妙でも、フォントが平凡でも、ビジュアル階層が明確なデザインは「整っている」と感じます。逆に、どんなにオシャレな色やフォントを使っても、階層がなければ「ごちゃごちゃしている」という印象になります。

インターフェース上のすべての要素が同じ重みで競い合うと、どこを見ればいいかわからない、騒がしく混沌としたものになります。逆に、重要な要素が際立ち、副次的な要素が控えめになっていると、配色やフォントを変えなくても「デザインされた感じ」が生まれます。^[7]

❌ 階層がない状態
┌─────────────────────────┐
│ タイトル                │  ← 全部同じ
│ 説明文がここに入ります  │  ← 重みで
│ 価格: ¥1,000           │  ← 競い合う
│ [購入する] [詳細を見る] │  ← どれが重要？
└─────────────────────────┘

✅ 階層がある状態
┌─────────────────────────┐
│ タイトル（大・太）      │  ← 最も重要
│ 説明文（小・薄）        │  ← 補足情報
│ ¥1,000（中・太）        │  ← 判断材料
│ [購入する]  詳細を見る  │  ← 主/副アクション
└─────────────────────────┘

コントラストはビジュアル階層を作る手段

では、ビジュアル階層をどう作るか。それがコントラストです。

コントラストとは単に「色の差」ではありません。要素間の重要度の差を視覚化することです。

概念	役割
ビジュアル階層	ゴール（達成したい状態）
コントラスト	手段（そのための技法）

この関係を理解すると、後述する「グレースケールで始める」「ラベルを減らす」「ボタンに階層をつける」といったテクニックの意味がわかります。すべてはビジュアル階層を明確にするためです。

コントラストを作る3つの手段

コントラストをフォントサイズだけで作ろうとすると、メインの文字が大きすぎ、サブの文字が小さすぎるという問題が起きます。

代わりに、3つの手段を組み合わせてください：

手段	効果
フォントウェイト	太字（600-700）で強調、通常（400-500）で抑制
色のコントラスト	濃い色を主要に、薄いグレーを副次的に
サイズ	補助的に使用、極端な差は避ける

❌ NG: サイズだけで階層を作る
見出し: 32px（大きすぎ）
本文:   16px
補足:   10px（小さすぎて読めない）

✅ OK: 複合的に階層を作る
見出し: 24px / Bold / #1a1a1a
本文:   16px / Regular / #333333
補足:   14px / Regular / #666666

アクセシビリティとのバランス

色のコントラストを使って階層を作るとき、WCAGのコントラスト比基準を意識してください。^[8]

レベル	本文テキスト	大きなテキスト（18px以上または14px太字）
AA（最低限）	4.5:1	3:1
AAA（推奨）	7:1	4.5:1

副次的なテキストを薄いグレー（例：#999999）にしたくなりますが、白背景では2.8:1程度しかなく、AA基準を満たしません。#666666〜#767676あたりが実用的な下限です。

シャドウで奥行きを表現する

コントラストはXY平面だけでなく、Z軸（奥行き）でも作れます。

シャドウは単なる装飾ではなく、ユーザーとの距離を示す手段です。ユーザーに近い要素ほど注目を集めます。

シャドウ	Z軸の位置	用途
小さく、ぼかし少	背景から少し浮く	ボタン、カード
中程度	中間	ドロップダウン、ポップオーバー
大きく、ぼかし多	ユーザーに最も近い	モーダル、ダイアログ

モーダルが最も手前に浮き、背景が暗くなるのは、「今これに集中してほしい」というコントラストの表現です。

---

Part 2: プロセス編 - どう進めるか

---

第3章：機能から始める

レイアウトから始めてはいけない

アプリのデザインを始めるとき、「トップナビにするかサイドバーにするか」「ロゴはどこに置くか」といった外枠のレイアウトから入ると、すぐに行き詰まります。

The thing is, an "app" is actually a collection of features. Before you've designed a few features, you don't even have the information you need to make a decision about how the navigation should work.

— Refactoring UI ^[7:1]

（訳：アプリとは機能の集合体だ。いくつかの機能を設計する前に、ナビゲーションの最適な形を判断する情報すらない。）

「機能」とは何か

ここでいう「機能」とは、ユーザーが実際に行う具体的なタスクです。

たとえば航空券予約サービスなら：

抽象的すぎる	具体的な「機能」
❌ ホーム画面	✅ フライトを検索する
❌ ユーザー管理	✅ 予約履歴を確認する
❌ 設定画面	✅ 通知のオン/オフを切り替える

「フライトを検索する」機能なら、必要な要素は：

• 出発地の入力フィールド
• 目的地の入力フィールド
• 出発日・帰着日
• 検索ボタン

これだけです。ナビゲーション、サイドバー、フッターは後回しです。

なぜ機能から始めるのか

機能から始める理由は、近接とコントラストを正しく判断するためです。

• 近接: 「検索条件」と「検索結果」は別グループ。検索条件内の「出発地」と「目的地」は近くに。
• コントラスト: 「検索ボタン」が最も重要。入力フィールドのラベルは副次的。

レイアウトから始めると、「このスペースに何を入れよう」という発想になり、近接やコントラストの判断が曖昧になります。

---

第4章：サイクルで磨く

短いサイクルで回す

すべての機能を事前に設計しようとすると、想像力だけでエッジケースを考えなければならず、非効率です。

It's a lot easier to fix design problems in an interface you can actually use than it is to imagine every edge case in advance.

— Refactoring UI ^[7:2]

（訳：実際に使えるインターフェースでデザイン問題を修正するほうが、すべてのエッジケースを事前に想像するよりはるかに簡単だ。）

短いサイクルで進めてください：

設計（ローファイ）
    ↓
実装（動くもの）
    ↓
使用（実際に触る）
    ↓
改善（問題を発見）
    ↓
設計...（ループ）

UXの表現技法はいつ決める？

「動画にチャプターを付ける」「会社概要に写真を入れる」といった付加的な判断は、基本機能が動いてから決めます。

1. まず最小限の機能を設計・実装
2. 実際に使ってみる
3. 「ここがわかりにくい」を発見
4. 改善として付加要素を追加

最初から「チャプターがあると良いよね」と決めると、それが本当に必要かわからないまま工数だけ増えます。

グレースケールで階層を検証する

サイクルの中で「コントラストが弱いかも」と感じたら、グレースケールに変換して検証してください。

色は階層を曖昧にします。赤いボタンが目立つのは「重要だから」ではなく「赤いから」です。

By designing in grayscale, you're forced to use spacing, contrast, and size to do all of the heavy lifting.

— Refactoring UI ^[7:3]

（訳：グレースケールでデザインすることで、スペーシング・コントラスト・サイズだけで重い仕事をこなす力が身につく。）

グレースケールで階層が明確なら、色を加えたときにデザインが一気に洗練されます。

実務での活用方法

グレースケールは「最初からグレーで作る」より「検証ツール」として使うのが現実的です。色付きでデザインした後、Figmaのプラグイン（Stark等）でグレースケール変換し、階層が維持されているか確認します。

---

Part 3: 実践編 - 具体的なテクニック

---

第5章：近接の実践

余白は「足す」のではなく「削る」

Webデザインでは、窮屈に見えたときに余白を足すのが普通です。しかしこのアプローチだと、要素には「悪く見えない最低限」の余白しか与えられません。

最初から「多すぎる」くらいの余白を取り、そこから削るアプローチが有効です。

グループ間の余白 > グループ内の余白

近接の原則を実践する最も効果的な方法は、グループ間の余白をグループ内の余白より大きく取ることです。

❌ NG: すべて同じ余白
[タイトル]
         16px
[説明文]
         16px
[価格]
         16px
[購入ボタン]

✅ OK: グループで余白を変える
[タイトル]
         8px  ← グループ内（商品情報）
[説明文]
         24px ← グループ間
[価格]
         8px  ← グループ内（購入情報）
[購入ボタン]

スペーシングシステムを事前に定義

余白の値を毎回手探りで決めるのは非効率で、一貫性も損なわれます。

事前に制約のあるスケールを定義しておき、そこから選ぶようにします：

スペーシングスケール例（8pxグリッドベース）:
4, 8, 12, 16, 24, 32, 48, 64, 96 (px)

このスケールは8pxを基本単位としています（4pxは微調整用）。8pxグリッドは多くのデザインシステムで採用されており、Tailwind CSSのデフォルトスケールとも互換性があります。

---

第6章：コントラストの実践

ラベルは最終手段

データを表示するとき、安易に「ラベル: 値」形式を使いがちです。

❌ NG: すべてにラベル
名前: 山田太郎
メール: [e-mail]
電話: [phone]

しかしこれでは、すべてのデータが同じ重みになり、コントラストが作れません。

改善策：

パターン	例
ラベル不要	メールアドレス、電話番号、価格は形式でわかる
ラベルと値を組み合わせ	「在庫: 12」→「残り12点」
ラベルを副次的に	ラベルを小さく・薄く・軽くする

✅ OK: コントラストを意識
山田太郎（大きく、太く）
[e-mail]（小さく、薄く）
03-1234-5678（小さく、薄く）

アクセシビリティの注意点

視覚的にラベルを省略しても、スクリーンリーダーユーザーには意味が伝わりません。「形式でわかる」は晴眼者視点のバイアスです。

解決策として、aria-label属性やvisually-hiddenクラスを使い、視覚的にはラベルなし、意味的にはラベルありの状態を作ります：

<!-- 視覚的にはラベルなし、スクリーンリーダーには「メールアドレス」と読み上げ -->
<span class="visually-hidden">メールアドレス:</span>
<a href="mailto:[e-mail]">[e-mail]</a>

ボタンの階層

ページ上のアクションにも階層があります。すべてのボタンを同じ見た目にすると、何が重要かわかりません。

階層	スタイル	用途
Primary	塗りつぶし、高コントラスト	メインアクション（1ページに1つ）
Secondary	アウトライン、低コントラスト	補助アクション
Tertiary	リンクスタイル	目立たないが発見可能

// 例: 商品編集画面
<Button variant="primary">公開する</Button>  {/* 最も重要 */}
<Button variant="secondary">下書き保存</Button>
<Button variant="tertiary">削除</Button>  {/* 目立たせない */}

shadcn/uiを使っていれば、この階層はvariantプロップで簡単に表現できます。^[3:1]

選択肢を制限する

無限の選択肢があると、決断が苦痛になります。「12pxか13pxか」「透明度10%か15%か」と悩む時間は、デザインの質を上げません。

システムを事前に定義してください：

要素	アプローチ
色	8〜10段階のパレットを事前に作る
フォントサイズ	制限されたタイプスケールから選ぶ
スペーシング	固定のスケール（4, 8, 16, 24, 32...）から選ぶ
シャドウ	small, medium, large, xlなど段階を決める

選択肢が限られていると、少数の候補から消去法で選べるため、決断が速くなります。

---

まとめ：近接とコントラストで、多くの「ダサい」は解決する

デザイン4原則のうち、近接とコントラストを意識するだけで、多くの「なんとなくダサい」は解決します。

4原則の学習優先度

以下は「開発者が最初に学ぶべき順序」としての優先度です。4原則すべてが重要ですが、判断の難易度とツールによる補助の度合いを考慮しています。

原則	学習優先度	理由
近接	高	画面ごとに判断が必要、ドメイン知識に依存
コントラスト	高	優先度判断が必要、要件理解に依存
整列	中	判断は必要だが、実装はツールが補助
反復	中	判断は必要だが、デザインシステムが補助

プロセス

1. 機能から始める - ユーザーの具体的なタスクを設計
2. 近接を決める - 何と何をグループ化するか
3. コントラストを決める - 何が最も重要か
4. サイクルで磨く - 実物を触って問題を発見

デザインは「センス」だけではありません。原則を知ることで、「なんとなく良い/悪い」を言語化し、再現可能にできます。近接とコントラストを意識すれば、誰でも「デザインされた」UIを作れるようになります。

この記事が適用しにくいケース

本記事のアプローチは、情報密度が高いBtoB管理画面やデータテーブル中心のダッシュボードでは調整が必要です。これらの場面では「情報の削減」より「大量情報の整理」が優先されることがあります。

---

参考文献

脚注

1. Robin Williams, "The Non-Designer's Design Book" - Amazon。デザイン4原則（CRAP）の原典。1995年の初版から20年以上売れ続けるベストセラー。

2. Figma, "Design more, resize less, with Auto Layout" - figma.com。Auto Layoutにより、ボタンのテキスト変更やリストの並び替えが自動で反映される。

3. shadcn/ui Documentation - ui.shadcn.com。「Components naturally fit with one another. Each component is built to match the others, keeping your UI consistent.」

4. Nielsen Norman Group, "Redefine Your Design Skills to Prepare for AI" - nngroup.com。戦術的タスクと戦略的タスクの区分、AIによる自動化の適性について。

5. Clueify, "How the 4 C.R.A.P. Design Principles enhance User Experience" - clueify.com。近接により情報の関係性が明確になり、認知負荷が軽減される。

6. 型設計においても同様に、アクター（ユースケース）ごとに型を分離することで凝集性を高められる。詳しくは「TypeScript型設計入門 ― 分ける・守る・派生させる」を参照。

7. Adam Wathan & Steve Schoger, "Refactoring UI" - refactoringui.com。開発者視点でUIデザインの具体的テクニックを解説した書籍。

8. W3C, "Web Content Accessibility Guidelines (WCAG) 2.1" - w3.org。Success Criterion 1.4.3 Contrast (Minimum) でテキストと背景のコントラスト比基準を規定。