コンポーネントの視覚一貫性 (Component Consistency)

「このボタン、さっきの画面と色が違うけど、同じ機能？」「このカード、なんでここだけ角が丸くないんだろう？」 ユーザーは画面を見るたびに、こうした小さな疑問を無意識に処理しています。1つひとつは些細に見えても、積み重なると「このサービスは作りが雑だ」という印象に変わり、信頼を静かに蝕みます。

特に複数人のデザイナーやエンジニアが関わるプロダクトでは、「自分の担当画面だけ良ければいい」という局所最適が積み重なり、気づけばUIが「寄せ集め」の状態になっています。ボタンのスタイルが3種類、カードの角丸が4パターン、フォームの入力欄の高さが画面ごとにバラバラ——これは単なる「見た目の問題」ではなく、ユーザーの認知負荷を確実に増やし、操作ミスと離脱を引き起こします。

1. 原則の定義

同じ役割・意味を持つUIコンポーネント（ボタン、カード、フォーム、アイコンなど）の見た目・サイズ・間隔・振る舞いを、プロダクト全体で統一するルール。

本質は「コンポーネントを『約束』として扱うこと」です。「青い塗りつぶしボタン＝主要アクション」という約束が全画面で守られていれば、ユーザーは新しい画面を開いた瞬間に、何も読まずに「何をすべきか」を把握できます。この約束が破られるたびに、ユーザーは脳のリソースを「解釈」に使わされます。

2. いつ使うか（適用場面）

特に重要になるケース

• 複数人チームでの開発: デザイナーとエンジニアが複数いる場合、明示的なルール（デザインシステム・コンポーネントライブラリ）がなければ、担当者ごとに実装がブレる。
• 機能追加・改修が続くプロダクト: リリース初期は統一されていても、機能追加のたびに「とりあえず動けばいい」実装が積み重なり、一貫性が崩れていく。
• 複数ページにまたがるワークフロー: 購入フロー・設定ウィザードなど、ユーザーが複数画面を連続して操作する場面では、コンポーネントの不一致が直接的な操作ミスにつながる。

トレードオフが起きる場面

• 一貫性 vs コンテキスト最適化: 「このページだけ、ボタンをより大きく・目立たせたい」という要求は正当な場合もあります。ただし、コンポーネントのバリエーション（サイズ違い・強調バリアント）として明示的に定義し、「なんとなく大きくした」との違いを明確にする必要があります。

3. なぜ重要か（設計判断の核）

コンポーネントの一貫性は「見た目の統一」ではなく、「ユーザーとの約束の履行」である。

設計判断の基準

• 「このコンポーネントのスタイルを変えたい」と思った時、「これは新しい約束（バリアント）か、それとも約束破り（不一致）か？」を問う。明確な理由と定義があれば前者、なければ後者。
• 「このコンポーネントは、他の画面の同じコンポーネントと同じソース（同じコードやデザインデータ）から来ているか？」→ コピー＆ペーストで作られた「似て非なるもの」は一貫性の敵。

優先順位の考え方

• 1. インタラクティブ要素（ボタン・リンク・フォーム）の統一: 操作に直結するため、不一致が誤操作を生む。最優先で統一する。
• 2. 状態表現の統一: ホバー・フォーカス・ディセーブル・エラーなど、各状態の見た目が全コンポーネントで一貫しているか。
• 3. 装飾的要素（カード・区切り線など）の統一: 機能への影響は小さいが、品質感に直結する。

例外条件

• 「削除」「退会」など破壊的アクションのボタンは、意図的に通常の主要アクションと異なるスタイル（赤色など）にすることで、警告として機能させる。これは「約束破り」ではなく「意図的な例外バリアント」として定義する。

4. 具体の設計ルール（チェックリスト）

最低ライン（Must - これ守らないと危険）

ここをクリアしていないと、ユーザーが「このUIは信頼できない」と感じるレベルです。

ボタンの役割別スタイル統一: 「主要アクション（Primary）」「副次アクション（Secondary）」「破壊的アクション（Destructive）」の3種類のボタンスタイルが定義され、全画面で同じスタイルが使われているか？（同じ役割なのに画面ごとに色・形が違うボタンが存在しないか）
フォーム要素の統一: テキスト入力欄・セレクトボックス・チェックボックスなどのフォーム要素の高さ・ボーダー・フォントサイズが全画面で統一されているか？
状態表現の統一: ボタンやリンクの「ホバー」「フォーカス」「ディセーブル」「ローディング」状態の見た目が、全コンポーネントで一貫したルールで表現されているか？

理想ライン（Better - できると強い/プロの品質）

コンポーネントの一貫性を「感覚」ではなく「仕組み」で担保できている状態です。

コンポーネントの単一ソース化: デザインデータ（Figmaなど）とコード（Reactコンポーネントなど）が連動しており、「コピー＆ペーストで作られた似て非なるコンポーネント」が存在しないか？変更が1箇所で全体に反映される構造になっているか？
バリアントの明示的定義: サイズ違い（Small / Medium / Large）や状態違い（Default / Hover / Active / Disabled）が、「なんとなく」ではなく、明確なバリアントとして定義・文書化されているか？
UIインベントリの定期実施: 実装済みの画面を定期的にスクリーンショットで並べ、「同じ役割なのに見た目が違うコンポーネント」を洗い出す作業（UIインベントリ）を行っているか？

5. UI例

同じ「カード」コンポーネントでも、ルールなく実装が積み重なった画面と、単一ソースから生成された画面では、品質感に歴然とした差が出ます。

改善プロセス

1. UIインベントリの作成: 実装済み画面のスクリーンショットを並べ、「同じ役割なのに見た目が違う」コンポーネントをすべてリストアップする。
2. 基準コンポーネントの決定: バラバラなバリエーションの中から「これを正とする」1つを選び、他を統合する。
3. 単一ソース化: Figmaのコンポーネント機能やReactコンポーネントとして定義し、コピー＆ペーストによる「似て非なる実装」を排除する。

6. 関連リンク

• 関連リファレンス（理論）: ゲシュタルト原則
• 用語集（定義）: デザインシステム, 一貫性の原理
• 関連するUI原則（横）: 反復・一貫性 (Consistency), 画像・アイコンの役割 (Iconography), グリッドシステム (Grid System)
• 関連するUIコンポーネント: Sheet / Drawer（ドロワー / シート）

7. まとめ

今日から直せる一手 今すぐ、プロダクト内の「ボタン」だけに絞ってスクリーンショットを並べてみてください。同じ「主要アクション」のボタンが、何種類の見た目で存在しているか数えてみましょう。3種類以上あれば、今日から統合を始める価値があります。

チームに共有するなら一言 「コンポーネントは『約束』だ。約束を守るから、ユーザーは次の画面でも迷わずに動ける。」