第4章　人間は、似たものを仲間だと思う

画面内に青い角丸ボタンが五つあるとします。四つは次の画面へ進み、一つだけは入力内容を削除します。見た目が同じなら、利用者は同じ種類の操作だと予想するかもしれません。

反対に、五つとも同じ「詳細を見る」という操作なのに、高さ、色、角丸、文字の太さが一つずつ違っていたらどうでしょうか。役割は同じでも、別の重要度、別の状態、別の機能に見える可能性があります。

人は、似たものをまとまりとして見やすい傾向を持ちます。しかし、画面で似て見えることと、同じ役割であることは同じではありません。HTML や部品が同じこととも、同じトークンを参照していることとも違います。

本章では、類似を次の四層に分けます。

1. 知覚: 何が似て見え、同じまとまりとして見えるか
2. 役割: 同じ種類の情報・操作・状態だと予測するか
3. 動作: 実際に同じ結果や操作方法を持つか
4. 実装: 部品、トークン、CSS 値の何を共有するか

この章の必修は三つです。

1. 何と何の、どの属性が似ているかを指す
2. 見た目の類似と、役割・状態・動作の類似を分ける
3. 差の意図を仮説にし、画面・実装・人の行動で確かめる

この章で見るもの

• 色、形、大きさ、向き、タイポグラフィ、アイコンの何が反復するか
• 同じ役割なのに違う見た目がないか
• 違う役割なのに同じ見た目がないか
• 例外が状態、重要度、危険性、文脈を表しているか
• 部品、デザイントークン、CSS カスタムプロパティのどこから差が生じたか

4.1 同じ制服、同じ標識から規則を見つける

駅で同じ色と形の衣服を着た人を見れば、同じ活動に参加していると予想するかもしれません。しかし、服装から職業、権限、所属を決めつけることはできません。同じ形の標識が反復されれば、同じ種類の案内だと考えるかもしれません。作業台に同じ向きで並んだ道具は、一つの工程のために用意されたまとまりに見えることがあります。

ただし、ここには複数の説明があります。

• 色や形が知覚的なまとまりを作った
• 制服や標識の社会的な意味を知っていた
• 同じ場所に近接していた
• 同じ方向を向き、同じ行動をしていた
• その場の状況から役割を推測した

色が同じだから同僚だ、と知覚だけで決まるわけではありません。似た外観は分類の手がかりですが、その分類へ何の意味を与えるかには、経験と状況が加わります。

図 F01 では、最初に意味ラベルを隠します。何を同じ組へ入れたか、次に何が似ていたためかを答えます。その後で複数の状況説明を開き、同じ配置にも別の社会的解釈がありうることを比べます。正しい所属を当てる課題にはしません。

観察の基本形

私は A と B を同じまとまりとして見た。色は同じだが、形と向きは異なる。意味を知る前は同じ役割だと予想したが、説明を読むと役割は異なっていた。

「似ている」で止めず、似ている属性と、そこから予測した意味を分けます。

4.2 同じ役割なのに違うボタン

文化祭サイトに「詳細を見る」というボタンが五つあります。どれも出演者カードから詳細プレビューが開く操作です。しかし、一つだけ高さが 2px 低く、一つだけ角丸が強く、一つだけアイコンを持つとします。

一度に一属性だけを見る

色、高さ、角丸、文字、アイコンを同時に変えた比較では、どの差が見え方を変えたのか分かりません。図 F02 では、文言、位置、動作、状態を固定し、一つの属性だけを段階的に変えます。属性を個別に見た後は実際の画面へ戻り、タイポグラフィ、余白、画像、構図を含む全体の調子として差がどう働くかも見ます。

統合画面では、カード群の画像比率、見出しの書体、余白の周期、色面の配置が同じ調子を作っているかを観察します。ボタンだけが揃っていても、画像の扱いとタイポグラフィがカードごとに別の調子なら、画面全体の一貫性は保たれない場合があります。属性分析は入口であり、造形全体の評価の代わりではありません。

見る順序も分けます。

1. 差を検出したか
2. 同じ役割だと予想したか
3. 重要度の差だと思ったか
4. ホバー、フォーカス、無効などの状態差だと思ったか
5. 実際に操作すると同じ結果だったか

見た目の差を検出しても、役割は同じだと判断する人がいるでしょう。反対に、小さな差から別状態を予測する人もいるでしょう。「違って見える」と「違う役割に見える」を同じ回答にしません。

差は情報になる

一つだけ異なる見た目は、例外として注意を引く可能性があります。その差が選択中、危険な操作、主要な行動、読込中を一貫して示すなら、必要な情報です。

問題は、差があることそのものではありません。

この差は、利用者が知る必要のある何の違いと対応しているのか。

答えられない差は、制作途中の偶発差かもしれません。ただし、スクリーンショットだけから「技術的負債だ」と断定はできません。実装、設計意図、履歴も確認します。

同じ役割の範囲を決める

「すべてボタンだから同じ見た目」にする必要もありません。送信、削除、閉じる、カード全体の補助操作は、いずれもボタンであっても役割、重要度、危険性、配置が違います。

比較する単位を、HTML 要素名だけで決めません。

• 同じ結果を起こすか
• 同じ重要度か
• 同じ状態か
• 同じ文脈にあるか
• 同じ入力方法と操作を持つか

どの範囲を同じ役割として設計したかを先に書きます。

4.3 違う役割なのに同じ見た目

角丸の枠に短い文字が入ったピル状の要素を考えます。次の要素が、ほぼ同じ見た目を持っています。

• 別ページへ移動するリンク
• フィルターを適用するボタン
• 現在選択中の条件を示す文字
• 条件を解除するボタン

知覚上は、同じ種類の要素としてまとまって見えるでしょう。しかし、クリック後の結果、選択状態、キーボード操作、フォーカス、解除方法は異なります。操作要素を別の操作要素へ入れ子にせず、状態を表す文字と解除ボタンを別の操作単位として設計します。

見た目は意味を自動的に作らない

CSS で a と button を同じ外観にできます。div をボタンのように見せることもできます。しかし、外観を似せただけで HTML の意味や標準的なキーボード動作が同じになるわけではありません。

反対に、ネイティブの button を使っただけで、役割が見て分かるとも限りません。アクセシブルネーム、状態、フォーカス表示、操作結果、エラー時の動作まで確認します。

見た目と実装を、次の表で分けます。

本章の例では、ページ移動は a[href]、フィルター適用と解除は button、現在条件は文字として実装します。フィルターの押下状態には aria-pressed を使う案を、一覧更新には状態メッセージを使う案を検証します。ただし、ARIA 属性を付ければ完了とは考えません。Tab 順、Enter／Space、フォーカスの維持、更新範囲、読み上げ、ローディング、0 件、エラーを状態表にして確認します。

単一選択か複数選択かを先に決めます。本章の基準画面は複数ジャンルを選べるトグルボタン群とし、各ボタンは aria-pressed で現在の押下状態を伝えます。リンクは Enter、ボタンは Enter と Space というネイティブの操作差を維持します。フィルター実行後もフォーカスを押したボタンへ保ち、一覧更新はフォーカスを移動せず状態メッセージで件数を通知する案を検証します。

同じ外観を使うなら、利用者が同じ種類だと予測しても困らない範囲かを確かめます。違う外観を使うなら、その差が役割や状態の差と対応するかを見ます。

4.4 類同の原則と一貫性

第2章では近接を扱いました。知覚的グルーピングの別の手がかりが類同です。

簡単に言えば、似たもの同士は同じまとまりとして知覚されやすい、という傾向です。色、形、大きさ、向き等の類似が手がかりになります。

より正確には、他の条件がおおむね等しい刺激で、ある視覚属性が類似する要素が知覚的にグループ化されやすい現象を扱います。どの属性の類似が、どの条件で、どの程度働くかは一様ではありません。

類同は役割を決めない

同じ赤い円が一列に見えても、それらが削除ボタンであるか、エラー表示であるか、装飾であるかは類同から決まりません。類同は知覚上のまとまりを説明します。意味と役割は、内容、経験、操作、文脈から推定されます。

一貫性は実務上の設計原則である

一貫性は、同じ役割や状態へ反復した表現・動作を与え、画面や製品の規則を保つ設計原則です。知覚心理学の類同と関係する場面はありますが、同じ概念ではありません。

• 類同：似た視覚属性がまとまりを作る知覚的傾向
• 一貫性：役割、状態、動作、表現の対応を反復する設計判断

「類同の原則があるから、ボタンはすべて同じ色にする」とは結論できません。主要ボタン、補助ボタン、危険なボタン、選択状態を同じにすれば、必要な差を失う可能性があります。

近接と類同が競合するとき

近い要素は縦の組を作り、同じ色の要素は横の組を作る配置があります。このとき「類同は近接より強い」という固定順位を覚えません。距離差、色差、形、配置、課題を変えれば、まとまりの報告も変わり得ます。

図 F04 では、距離を固定して色差を変える系列と、色を固定して距離差を変える系列を分けます。最後に競合画面へ戻ります。一つの原則名で勝敗を宣言するのではなく、どの手がかりがどの関係を示しているかを書きます。

4.5 UI は使われながら自分の規則を教える

初めて見る Web サイトでも、利用者は完全に知識がないわけではありません。過去の Web 利用から、青い下線付き文字はリンク、歯車は設定、虫眼鏡は検索、といった期待を持ち込みます。この外部の慣習は第15章で扱います。

同時に、一つのサイト内でも規則を学びます。

1. 最初の青い角丸要素を使う前に、結果と確信度を答える
2. プレビューが開く経験をする
3. 複数の既知要素で同じ対応を経験する
4. 未知の青い角丸要素について、結果と確信度をもう一度答える

これは図だけで実証された学習効果ではなく、観察するための仮説シナリオです。「3 回で学ぶ」という回数則ではありません。経験回数、順序、既存の Web 経験を記録し、経験前、経験後、未知要素への転移で予測と確信度がどう変わったかを確かめます。

一貫性が破れたとき

四回目だけ、同じ青い角丸要素がフィルターを解除したらどうでしょうか。利用者は過去の対応から移動を予測し、意図しない結果を起こすかもしれません。

ただし、予測違反が常に悪いわけではありません。購入完了、危険な操作、現在位置など、重要な例外を強く示すために規則を変えることがあります。例外が必要なら、差を明確にし、文言、アイコン、配置、確認手順などでも意味を支えます。学習を観察する試行では、削除、購入、公開などの不可逆または高リスクな結果を使わず、プレビューやフィルターのように安全に戻せる課題を使います。

学習を観察する

次の三つを別に記録します。

• 操作前に何が起きると予測したか
• 操作後に何が起きたか
• 次の同種要素への予測がどう変わったか

「分かりやすかったですか」という感想だけでなく、予測と行動の変化を見ます。一人の結果を全利用者へ一般化しません。

4.6 部品とデザイントークンが守るもの

実装と接続する――章末課題の後に読んでも構いません

同じボタンを何度も手作業で描けば、色、高さ、角丸、内部余白に小さな差が生じやすくなります。部品は、外観と動作を再利用する単位を作る手段です。デザイントークンは、色や寸法などの設計判断を名前付きデータとして共有する手段です。

しかし、次の四つは同じではありません。

1. 画面上で同じに見える
2. 同じ部品を使う
3. 同じトークンを参照する
4. 計算後スタイルの値が同じである

別の部品でも同じ見た目を作れます。同じ部品でもバリエーションや状態で見た目は変わります。同じトークンを異なる役割へ流用すれば、後の変更で意図しない連動が起こることがあります。自由値が偶然トークンと同じ値になることもあります。

部品は外観だけではない

ボタン部品を考えるとき、色と角丸だけでなく次を含めます。

• 内容とラベル
• HTML の意味
• ポインターとキーボードの操作
• 通常、ホバー、フォーカス、押下中、無効、ローディング
• アイコン有無と長い文言
• レスポンシブ条件
• エラーと成功後の動作

同じ見た目を再現するだけでは、同じ部品とは言い切れません。反対に、同じ部品内で必要な状態差を作ることも、一貫性の一部です。

トークンは判断を代行しない

color-blue-600 のような基礎トークンや、action-primary-background のような意味トークンが考えられます。名前を細かくすれば必ずよいわけではありません。どの変更を一緒に波及させ、どの差を閉じ込めたいかで層を選びます。

Design Tokens Community Group の Format Module は、トークンデータを交換する形式を整理しています。これは知覚原則でも、部品設計の正解でもありません。草案の版を確認し、仕様が定義する範囲と自分たちの命名規則を分けます。

四層監査表で一つの差を追う

一つの青いボタンだけ色が違う事例を、4.6 と 4.7 で継続して追います。画面上の差から始め、役割と状態を確認し、部品、トークン、CSS へ進みます。四層すべてが一致することを正解にはしません。どの層の差が意図を持ち、どこで説明が途切れているかを見ます。

4.7 CSS Custom Properties で差異の出所をたどる

発展――CSS の詳細です。四層監査表まで読めば章末課題へ進めます

画面で、同じ主要操作の一つだけ色が違うと気づいたとします。すぐ値を上書きせず、出所を予想します。

• 別の部品か
• 状態による上書きか
• テーマか
• 親から継承されたカスタムプロパティか
• 代替値が使われたか
• 局所的な自由値か
• カスケードの優先関係か

画面から実装へ進む

1. 何と何の、どの属性が異なるかを書く
2. 役割と状態が同じか確認する
3. 適用値を予想する
4. 計算後スタイルを見る
5. スタイルパネルなどで宣言と var() 参照を辿る
6. 計算後スタイルの最終値と、定義位置、継承、代替値、状態による上書きを分けて見る
7. 一つだけ一時変更し、画面全体へ戻る

カスタムプロパティは、値を共有し、出所を辿る手がかりになります。計算後スタイルは最終的なプロパティ値を確認する場所であり、すべてのカスタムプロパティの継承・代替値・カスケード経路を説明する標準化された履歴画面ではありません。親で未定義、登録プロパティの inherits: false、無効値、代替値使用を別条件にします。同じ変数を使っているから同じ役割だとも限りません。--blue をリンクとボタンが共有していても、役割は違います。

スクリーンショットから技術的負債を断定しない

見た目の差は、技術的負債の兆候かもしれません。しかし、次の可能性もあります。

• A/B テスト中である
• 新旧部品を段階移行している
• ブランドやサブプロダクトが違う
• 状態または権限差を表している
• アクセシビリティモードが働いている
• ブラウザのネイティブ部品差である

DOM、CSS、デザインファイル、部品の利用例、トークン、変更履歴を確認します。見た目から作った仮説を、コード上の事実にすり替えません。

4.8 一貫していればよいわけではない

一貫性は、すべてを同じにすることではありません。必要な違いを、規則的に表すことでもあります。

状態の違い

選択中、無効、ローディング、エラー、成功は、通常状態と同じ見た目では状態を伝えられません。差は必要です。ただし、色だけで示さず、文字、アイコン、形、位置、支援技術へ伝わる状態を組み合わせます。

危険性と重要度

削除や公開の操作は、通常の補助操作と区別する理由があります。ただ赤くすれば安全になるわけではありません。文言、配置、確認、取り消し、権限、結果のフィードバックも設計します。

文脈の違い

同じ「保存」でも、自動保存の設定画面と、公開を伴う編集画面では意味が違います。製品全体で完全に同じ見た目へ揃えるより、文脈に必要な説明を加える方がよい場合があります。

アクセシビリティ

強制色や文字拡大では、通常テーマと異なる境界線や形が現れる場合があります。これは「アクセシビリティが一貫性を壊す例外」ではありません。色の置換後にも役割と状態を一貫して識別できるよう、文字、形、システム色、境界線を含めて設計する条件です。一貫性の対象を、特定ピクセルの一致ではなく、役割と状態が伝わることへ置き直します。

段階的な移行

デザインシステム更新中は、新旧部品が同時に存在することがあります。これは負債かもしれませんが、安全な移行計画かもしれません。移行範囲、期限、互換性、利用状況を確認します。

一つの差を見つけたら、次の順で考えます。

1. 何が違うか
2. 役割、状態、文脈も違うか
3. 差を説明する意図はあるか
4. その意図は利用者に伝わるか
5. 実装上の出所は何か
6. 変更すると何が波及するか

4.9 問い――この違いは、役割の違いを教えているか

文化祭のフィルターと出演者カード一覧を観察します。

観察条件

• 人：好きなジャンルの出演者を探す初見の来場者
• 課題：「音楽」を選び、15 時以降の出演者を一人開く
• 道具：幅 1280px、マウスとキーボード
• 基準状態：通常の内容、キーボードフォーカスなし
• 派生状態：幅 390px、キーボードフォーカス、ローディング、エラー、Windows 強制色を一軸ずつ

問い

1. 何と何の、どの属性が似ていますか。
2. 似た要素は、本当に同じ役割・状態・動作ですか。
3. 一つだけ違う要素は、何の差を示している可能性がありますか。
4. 画面だけでは分からないことを、何で確認しますか。
5. フィルター選択と、その後の時刻からの出演者探索を通して、一つだけ変えるなら何を変え、何が起きると予想しますか。
6. 知覚、役割推定、操作課題をどう分けて確かめますか。

答えの例

1. 属性を指す

「音楽」「演劇」「展示」のフィルターと「選択中：音楽」というタグは、青い文字、薄い青の背景、角丸の外形が似ています。一方、フィルターには枠線があり、選択中タグにはチェックアイコンがあります。

2. 役割を分ける

フィルターは押すと一覧条件を変更するボタンです。選択中タグは現在の条件を表示し、末尾の削除ボタンで解除できます。知覚上は同じまとまりに見えても、操作単位と結果は同じではありません。

3. 概念を候補にする

色と形の類同によって、フィルターと選択状態が同じ機能群として見える可能性があります。これは関連性を示す点では役立つかもしれません。しかし、全体をクリックできるか、状態表示なのかは類同だけでは説明できません。

4. 別仮説と証拠を残す

近接、位置、文言、チェックアイコン、フォーカス表示も役割推定へ関わります。HTML 要素、アクセシブルネーム、キーボード操作、クリック結果、部品の利用例を確認します。スクリーンショットだけから「同じ部品の使い回し」とは断定しません。

5. 変更仮説を作る

フィルターの外形を固定し、現在条件の表示だけに「選択中」という文字ラベルと独立した解除ボタンを加えると、関連する機能群であることを保ちながら、操作と状態表示を区別しやすくなるのではないか。その後の一覧では、時刻列の位置とカードの詳細リンクは変えず、フィルター修正だけが 15 時以降の出演者探索へ与える影響を比べます。

6. 確かめ方を書く

知覚課題では、どの要素を同じまとまりへ分類したかを記録します。役割推定では、操作前に各要素を押すと何が起きると思うかを聞きます。操作課題は二段階に分けます。第一段階は音楽フィルターを正しく選べたかを主要指標、フィルター／解除の誤操作と所要時間を補助指標にします。第二段階は更新後の一覧から 15 時以降の出演者を正しく開けたかを主要指標、時刻条件の見落としと所要時間を補助指標にします。全体完了率を示す場合も、止まった段階を併記し、合成値だけで解釈しません。

四層監査表を完成させる

四層は一致／不一致を一語で採点する表ではありません。どの層で予測が成立し、どの層で関係が変わるかを残します。

キーボード条件では Tab 順、フォーカス表示、Enter／Space の動作を記録します。Windows 強制色では色や背景が変わっても、フィルターと選択状態を識別できるか確かめます。基準状態と派生状態を同時に変えません。

別の答え方

主要操作の「出演者を開く」と、補助リンクの「会場を見る」が同じ塗りボタンに見える点を中心にできます。この場合は、どちらを主要行動として予測するか、移動先の違いが外観から伝わるかを検討します。

ローディング中のスケルトンがカードと同じ角丸・幅を持つことは、対応位置を予測させるための一貫性として説明できるかもしれません。ただし、スケルトンを操作可能なカードと誤認しないかも確認します。

よくある考え方

ボタンのデザインを全部統一します。

この考え方の注意点

どこからどこまでを同じ役割としたか、状態や重要度の差をどう残すかが分かりません。リンク、フィルター、タグまで同じ外観へすれば、役割差を失う可能性があります。

次のように書きます。

出演者詳細へ進む主要操作は、同じ役割・重要度・状態なのにカードごとに高さと角丸が異なる。文言と動作を固定し、同じ部品バリエーションへ揃えると、一覧内で同じ操作として予測しやすくなるのではないか。危険な操作と選択状態は別の役割・状態なので変更対象から外す。

必須セルフチェック

• 何と何の、どの属性が似ているかを指したか
• 見た目の類似と、役割・状態・動作の類似を分けたか
• 差の意図を仮説にし、画面・実装・人の行動で確かめたか

発展セルフチェック

• 類同と一貫性を同義語にしていないか
• 近接、文言、位置、状態等の別の手がかりを残したか
• HTML 要素名だけで見た目を決めていないか
• 部品名、トークン、CSS 値、見た目を同一視していないか
• スクリーンショットだけから技術的負債を断定していないか
• 色だけで役割や状態を示していないか
• レスポンシブ、キーボード、ローディング、エラー、Windows 強制色を確認したか

次章へ

似た見た目は、離れた要素にも共通の規則を感じさせます。しかし、画面のすべてを境界線、背景、影で囲めば、既に距離や類似で見えていた構造を重ねて説明することになります。

次章では、人が足りない輪郭を補い、共通の領域からまとまりを作り、前景と背景を分ける仕組みを扱います。

参考資料

• 入口: York University, “Max Wertheimer, Laws of Organization in Perceptual Forms（英訳）.” 類同を含む古典的な知覚的組織化の原典英訳です。
• 発展: Johan Wagemans et al., “A Century of Gestalt Psychology in Visual Perception I,” 2012. 色、形、大きさ、向きによる類同を含むレビューです。
• 研究: Claessens and Wagemans, “Grouping principles in direct competition,” 2013. グルーピング手がかりの競合を扱います。UI の固定順位表としては使いません。
• 仕様: WHATWG, “The button element” and “The a element.” 見た目とは別に HTML 要素の意味を確認します。
• 仕様: W3C, “CSS Custom Properties for Cascading Variables Module Level 1.” カスタムプロパティの定義、カスケード、継承、var() を確認する仕様です。
• 仕様候補: Design Tokens Community Group, “Design Tokens Format Module.” トークン交換形式の草案です。公開状態と版を再確認してください。
• 調査資料: Open UI. 部品の構造、状態、振る舞いを横断的に調査する資料への入口です。Web 標準として確定した全ての部品仕様という意味ではありません。

検索キーワード：類同の原則、grouping by similarity、perceptual grouping competition、UI consistency、design token format、CSS custom properties cascade、component variant state