反復・一貫性 (Consistency / Repetition)

同じ機能なのに画面ごとにボタンの色や形が違うと、ユーザーは「これはさっきと同じ機能か？」と毎回学習し直す必要があります。「この赤いボタンは『削除』だと思って押したら、ここでは『保存』だった」——こうした重大な誤操作は、一貫性のなさが引き起こします。

ユーザーは新しい画面を開くたびに、過去の学習を転用して操作します。「青いボタンが主要アクション」「右下にCTAがある」——こうした暗黙のルールが画面ごとに崩れると、ユーザーは毎回ゼロから判断しなければならず、認知負荷が積み重なります。

一貫性のないUIはツギハギに見え、「このサービスは作り込まれていない」という印象を与え、製品やブランドへの信頼を損ないます。逆に、一貫性が高いUIはユーザーに「このサービスはわかりやすい」という安心感を与え、学習コストを下げ、操作ミスを減らします。

よくある失敗は「画面ごとに担当者が違う」ことで起きる自然発生的な不一貫性です。意図せず生まれたバラつきは、デザインシステムやコンポーネント化によって防ぐことができます。

1. 原則の定義

反復・一貫性（Visual Consistency）とは、同じ機能や意味を持つ要素に同じ見た目・振る舞い・言葉を繰り返し適用し、ユーザーが「ここはこう動くだろう」という予測を裏切らないよう設計する原則。

本質は「予測可能性」の担保です。一貫性には3つの種類があります——内部一貫性（同一プロダクト内でのルールの統一）、外部一貫性（業界標準・他サービスとの共通パターンの踏襲）、機能的一貫性（見た目だけでなく振る舞いの統一）。この3つを意識することで、ユーザーは新しい画面でも直感的に操作できる安心感を得られます。

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

特に重要になるケース

• 複数画面にまたがるワークフロー（例：購入プロセス、設定ウィザード）。
• 機能が多く、学習コストが高い複雑なSaaSや業務ツール。
• デザインシステムやコンポーネントライブラリをチームで構築・運用する時。

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

• 一貫性 vs 強調（コントラスト）: すべてを同じ見た目にしすぎると、本当に見てほしい重要なアクションが埋もれる。あえて一貫性を崩す（異化する）ことで注意を引く戦略も必要。破壊的アクション（削除・退会）は意図的に一貫性を外して警告として機能させる。
• 一貫性 vs 改善: 既存のパターンに問題があっても「一貫性のため」に変えられない状況が生まれることがある。改善する場合は段階的な移行期間を設け、ユーザーが新旧パターンを同時に目にしないよう配慮する。
• 内部一貫性 vs 外部一貫性: 自社プロダクト内のルールと、業界標準のパターンが衝突することがある。ユーザーが他サービスで学習した操作感（外部一貫性）を優先するか、自社ルール（内部一貫性）を優先するかは、ユーザーの習熟度と文脈で判断する。

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

一貫性は「退屈さ」を生むためではなく、ユーザーの「迷う時間」を削るためにある。

設計判断の基準

• ある要素のデザインを変更する時、「この変更は、ユーザーが新しくルールを覚える手間に見合う価値があるか？」を問う。価値がなければ変更しない。
• 理由なきデザインの変更（表記揺れ、気まぐれな色使い）は行わない。「なんとなく変えた」は一貫性の最大の敵。
• 「この要素は他の画面と同じルールに従っているか？」を常に確認する。例外を作る場合は必ず明確な理由を文書化する。

優先順位の考え方

• 1. ラベル・表記の統一（最優先）: 「送信」「送る」「Send」の混在は最も気づかれにくく、最も信頼を損なう。まず言葉の一貫性を確保する。
• 2. インタラクティブ要素の見た目: ボタン・リンク・フォームの色・形・配置ルールを統一する。
• 3. フィードバックの出方: 成功・エラー・ローディングの通知パターンを統一する。

例外条件

• 「破壊的なアクション（削除・退会・取り消し不可の操作）」は、意図的に一貫性を崩して（赤色・警告アイコンなど）、通常アクションと区別する。
• ユーザーが業界標準のパターンを強く期待する要素（ハンバーガーメニュー・検索アイコン・閉じるボタンのX）は、内部ルールより外部一貫性を優先する。

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

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

ここをクリアしていないと製品として機能しないレベルの要件

同じアクション（例：保存）を行うボタンの色・形・サイズが全画面で統一されているか？
ラベルの表記揺れがないか？（「送信」「送る」「Send」が混在していないか）
見出しや本文のフォントサイズ・ウェイトの階層ルールが守られているか？

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

熟練者が目指すべきUXをさらに高めるための品質基準

操作に対する「フィードバック（成功・エラーの通知）」の出方やアニメーションが統一されているか？
業界の標準的な慣習との「外部の一貫性」も保たれているか？（ヤコブの法則の遵守）
複数人で作ってもブレないようにコンポーネント化（UIキットの整備）がされているか？

5. UI例

改善プロセス

1. UIインベントリの作成: アプリケーション内のすべてのボタン・見出し・フォーム・通知などをスクリーンショットで一覧化する。並べて見ると、バラつきが一目で見えてくる。
2. グループ化と統合: 似た役割の要素をグループ化し、1つの基本スタイル（コンポーネント）に統合する。この時「どれが正解か」ではなく「ユーザーにとって最も予測しやすいのはどれか」を基準にする。
3. 例外の定義: どうしても別スタイルが必要な「例外」のみ、明確な理由をつけてバリエーションとして定義する。例外を定義することで、「意図した違い」と「うっかりバラついた違い」を区別できる。
4. コンポーネント化: 定義したスタイルをコンポーネント（UIキット・デザイントークン）として実装し、チーム全員が同じ部品を使えるようにする。これにより、担当者が変わっても一貫性が保たれる。

6. 関連リンク

• 関連リファレンス（理論）: ヤコブの法則 (Jakob's Law), メンタルモデル (Mental Model), 親近性バイアス (Familiarity Bias)
• 用語集（定義）: 一貫性の原理, ヤコブの法則
• 関連するUI原則（横）: コンポーネントの視覚一貫性 (Component Consistency), 画像・アイコンの役割 (Iconography)

7. まとめ

今日から直せる一手 現在の画面を開き、「戻る」や「キャンセル」などの共通アクションが、他の画面と全く同じ位置・見た目で配置されているか確認してください。

チームに共有するなら一言 「『ここだけ特別』は、ユーザーにとっては『ここだけルールが違うバグ』になる。」