UIデザインの配色は、ボタンやアクセントカラーばかりに目が向きがちです。
しかし、実際の画面を見渡すと、面積の60%以上を占めているのは背景やカード、枠線、テキストといったグレー（無彩色）の要素です。

過去の自分も、画面内のグレーをカラーピッカーでその場しのぎに選んでいました。
その結果、画面内に20種類以上のグレーが乱立し、カードの境界が背景に埋もれたり、文字の視認性が落ちて開発現場への引き渡しで大きな手戻りを経験しました。

今回は、画面を濁らせずに美しく整理するためのUIグレー設計の原則と4層の明度ステップを解説します。
感覚的な色選びから脱却し、誰が見ても破綻しない配色ロジックを身につけていきましょう。

1. なぜUIのグレー選びは失敗しやすいのか？画面が散らかる2つの原因

UIデザインにおいて、グレーは最も使用頻度が高いにもかかわらず、最も破綻しやすい要素です。
画面の統一感が損なわれる背景には、設計段階における明確な2つの原因が存在します。

原因①：感覚的なカラーピッカー選択によるグレーの増殖

1つ目の原因は、新しいコンポーネントを作るたびにカラーピッカーで感覚的にグレーを拾ってしまうことです。
「この枠線は少し薄くしたい」「この文字は少し濃くしたい」と場当たり的に数値を調整すると、プロジェクト全体で無数のグレーが乱立します。

自分自身の失敗談としても、エンジニアから「この枠線とあの枠線で微妙にカラーコードが違うが、どちらが正しい仕様なのか」と指摘された経験があります。
ルールがないまま選ばれたグレーは、デザインシステムの保守性を著しく低下させ、実装現場の手戻りを生む要因になります。

原因②：彩度0%の「無機質なグレー」による画面のくすみ

2つ目の原因は、完全な無彩色（RGBの値がすべて等しい彩度0%のグレー）を使ってしまうことです。
白背景の上に彩度0%の純粋なグレーを置くと、人間の目には冷たく不自然に映り、画面全体がくすんで見える現象が起きます。

自然界や日常の印刷物において、純粋な無彩色はほとんど存在せず、周囲の光や環境の色を微細に反射しています。
デジタル画面上でも、周囲のブランドカラーと全く関係を持たない無彩色は反発し合い、洗練された印象を損ねてしまうのです。

2. 洗練されたUIを作る「グレー設計の3原則」

画面のくすみを防ぎ、破綻しない配色を作るためには、感覚ではなく論理に基づいたルールが必要です。
実務で即座に活用できるグレー設計の3原則を押さえておきましょう。

原則①：ブランドカラーの「色味（Tint）」をわずかに加える

グレーを設計する際は、完全な無彩色を避け、ブランドカラーの彩度を2%〜5%程度混ぜた色味のあるグレー（Tinted Gray）を採用します。
ブルー系のサービスであれば青みを帯びたスレートグレー、温かみのあるサービスであれば暖色を含んだストーン系を選ぶのが基本です。

わずかな色味を含めることで、主要ボタンやブランドアイコンと背景・枠線が自然に馴染みます。
画面全体に上質な一体感と奥行きが生まれ、プロダクト固有のトーン＆マナーを無彩色エリアからも表現できます。

原則②：「真っ黒（#000000）」を避け、濃紺・チャコールで止める

テキストの最も濃い色として、背景の白（#FFFFFF）に対して真っ黒（#000000）を配置することは推奨されません。
コントラスト差が極端すぎると、文字のエッジがチカチカとして視覚的な疲労を引き起こし、長時間の閲覧に適さないUIになってしまいます。

実務では、最も濃いテキストであっても、明度10%〜15%前後の濃紺やチャコールグレーを上限にします。
十分な可読性を維持しながら、画面全体のコントラストを柔らかく整え、目への刺激を抑えた読みやすいレイアウトを実現できます。

原則③：1画面で同時に使うグレーの役割を制限する

画面内で同時に使用するグレーは、無制限に増やさず、あらかじめ役割ごとにステップ数を固定します。
背景、カード面、境界線、テキストの各役割に対して、明確な明度差を確保して運用します。

隣接する要素同士で明度が近すぎると、境界線がぼやけて要素の分離が難しくなります。
役割ごとに階層を厳格に割り振ることで、誰が画面を見ても直感的に情報の境界を判別できる状態を作ることができます。

3. 破綻しない「4層の明度ステップ」と役割分担

UIの無彩色は、画面の奥行きと情報の優先度に応じて4つの階層に分類できます。
この4層の明度ステップを明確に分けることで、迷いのないUI構造を構築できます。

第1層：Background（背景色 / 最明ステップ）

第1層は、画面全体の下地となるキャンバスの背景色です。
真っ白ではなく、わずかに色づいた淡いペールトーン（ペールブルーや淡いスレートグレーなど）を配置します。

この淡い背景色を用意することで、その上に乗る白いカード領域が際立ちます。
画面全体に落ち着いたトーンを敷くことが、次層のカードを浮き立たせるための土台になります。

第2層：Surface（面・カード / ピュアホワイト）

第2層は、情報コンテンツを乗せるカードやコンテナの面領域です。
背景色の上に配置するサーフェスには、基本的にピュアホワイト（#FFFFFF）を採用します。

淡い背景色と白い面の明度差によって、枠線に頼らなくても直感的なグルーピングが成立します。
ユーザーの視線が自然とコンテンツ面に集まり、情報のまとまりを一瞬で把握できる視覚階層が完成します。

第3層：Border & Divider（枠線・境界線 / 中明度ステップ）

第3層は、カードの外枠やテーブルの行を分ける仕切り線の領域です。
枠線はコンテンツの邪魔をしてはならないため、主張しすぎない中明度のグレーを選定します。

実務での目安として、隣接する面に対してコントラスト比1.2〜1.5:1程度の薄い線（線幅1px程度）を推奨します。
背景と同化して消えてしまわない視認性を保ちつつ、画面のノイズにならない端正な輪郭を定義します。

第4層：Text & Icon（文字・記号 / コントラスト確保ステップ）

第4層は、情報をユーザーへ正確に伝えるテキストとアイコンの領域です。
文字情報の中核を担うため、アクセシビリティ基準を満たす十分なコントラスト比を確保します。

実務では、以下の3段階に分類して明度をコントロールします。

• Primary（主要見出し・本文）: 濃紺チャコールで最も濃く設計し、WCAG 4.5:1以上の高コントラストを確保
• Secondary（補足テキスト・メタ情報）: 中明度グレーで優先度を一段落とし、3:1〜4.5:1程度で設計
• Disabled（非活性・プレースホルダー）: 意図的にコントラストを下げ、操作不能な状態を直感的に伝達

4. Figma Variablesで組むニュートラルトークン実践手順

整理した4層のグレーをプロダクト全体で一貫して運用するには、デザインシステムとしてのトークン化が不可欠です。
FigmaのVariables（変数）を活用した2層トークン構造の実践手順を解説します。

手順①：Primitive Tokens（基本値）のスケール定義

まずは、純粋な色の物差しとなるPrimitive Tokens（プリミティブトークン）を定義します。
Gray-50からGray-900まで、明度ステップを段階的に9〜10段階で並べたパレットを作成します。

この段階では「ボタン用」「テキスト用」といった用途は考えず、均等な明度のグラデーションを客観的に並べます。
ブランドカラーの青みを数パーセント混ぜた独自のカラースケールを固定することで、デザインの基礎パレットが確立します。

手順②：Semantic Tokens（役割）へのマッピング

次に、実際のコンポーネントへ適用するSemantic Tokens（セマンティックトークン）を作成します。
Primitive Tokensで定義した数値を、画面上の「役割（意味）」に紐付けてマッピングします。

実務で基本となる代表的なマッピング例は以下の通りです。

• bg/canvas: 背景色として「Gray-50」を指定
• surface/card: コンテンツ面として「#FFFFFF」を指定
• border/default: 標準の枠線として「Gray-200」を指定
• text/primary: 主要テキストとして「Gray-900」を指定
• text/secondary: 補足情報として「Gray-600」を指定
• text/disabled: 操作不能テキストとして「Gray-400」を指定

直接カラーコードを入力せず、Semantic変数を介してスタイルを当てる設計を徹底します。
将来的にダークモードへ対応する場合や、ブランドリニューアルの際にも、トークンの参照先を変更するだけで画面全体を一括更新できる柔軟性が得られます。

実践例：デザペディアの配色構造から学ぶ背景とボックスの関係

自社メディア「デザペディア」の実際のUI構造でも、この明度ステップの考え方を厳格に適用しています。
デザペディアでは、記事本文エリアを含むページ全体の背景色に淡いブルー（#F5F7FF）を採用しています。

そのため、記事内で要約や補足情報をグルーピングするボックス（サーフェス）を配置する際は、背景と同化しないよう真っ白（#FFFFFF）を敷き、自然なドロップシャドウやごく薄いボーダーを添えて階層を分離しています。
淡い下地と白いボックスの明度差を論理的に設計することで、画面のノイズを抑えながら、読者の視線を重要コンテンツへスムーズに誘導できる視覚階層を担保しています。

次のステップ：あわせて深掘りしたい知見

UIのグレー設計を確立した後は、カラーパレット全体の比率や、カードコンポーネントへの落とし込み、アクセシビリティ基準の検証へとステップを進めましょう。
実務で直結する以下の関連記事もあわせて確認してみてください。

UI全体のカラーバランスを見直し、無彩色のベースカラーとアクセントカラーの調和を保ちたい方へ。

【60-30-10の法則】アクセントカラーの使いすぎを防ぐUI配色の黄金比率

UIデザインでアクセントカラーを使いすぎて画面が散らかる原因と解決策を解説。「60-30-10の法則」をUI構造に落とし込み、破綻しない配色設計を網羅します。

今回設計したグレーの背景・面・枠線を活用し、美しいカードコンポーネントを組むレイアウト術を知りたい方へ。

カード型UIの設計ルール｜枠線・影・余白の使い分けと情報整理術

カード型UIの設計ルールと情報整理のコツを現役デザイナーが解説。枠線・影・背景色・余白の境界線4パターンの使い分けから、詰め込みすぎを防ぐ視覚階層まで具体的に整理します。

テキストやアイコンのグレーがWCAG基準を満たしているか、視認性と美しさを両立させる判定基準を深掘りしたい方へ。

UIアクセシビリティ基礎｜コントラスト比4.5:1とデザイン性の両立ルール

コントラスト比4.5:1を守りながら洗練されたUIを作るための実践ルール。WCAG 2.2基準と美しい色設計を両立させる具体的な手法を解説します。

終わりに

最後までお読みいただき、ありがとうございます！

UIデザインにおいて、グレーは単なる「色味のない隙間埋め」ではありません。
情報の優先順位を整理し、ユーザーを迷わせずに導くための最も重要な骨格です。

感覚的なカラーピッカーの指定をやめ、4層の明度ステップとわずかな色味（Tint）を味方につけるだけで、画面の洗練度は格段に向上します。
まずは手元のプロジェクトで、散らばっているグレーを整理し、整然としたニュートラルトークンを構築してみてください。

The post UIのためのグレー配色ルール｜背景・枠線・文字の破綻しない明度設計 first appeared on デザペディア.

プロダクトの機能を充実させようとするほど、画面上の入力項目やボタンの数は増えていきます。
しかし、親切心のつもりですべての選択肢を1画面に並べてしまうと、かえってユーザーを混乱させてしまいます。

自分自身も以前、業務管理画面のUI設計で大きな失敗をした経験があります。
「設定項目をすべて見せておけば迷わないだろう」と考え、1画面に20項目以上の入力欄や注釈テキストを詰め込んで提案したところ、クライアントから「どこから手を付ければいいか分からない」「威圧感があって使うのが怖い」と指摘され、全面的なレイアウト見直しになりました。

この「多機能にしたいが、画面はシンプルに保ちたい」という矛盾を解決する原則が、プログレッシブディスクロージャー（Progressive Disclosure：段階的開示）です。
今回は、情報過多を防ぐ基本概念から、実務で使える4大展開パターン、隠しすぎて失敗しないための境界線ルールまで具体的に整理します。

1. プログレッシブディスクロージャーとは？情報過多を防ぐ基本概念

プログレッシブディスクロージャーは、ユーザビリティの第一人者であるヤコブ・ニールセン（Jakob Nielsen）が体系化したインタラクション設計の標準原則です。
画面の初期状態では「80%のユーザーが日常的に使う基本的な情報・操作」だけをクリーンに表示し、残りの「20%のユーザーだけが求める高度な設定や二次的情報」は、ユーザーが能動的にクリックやタップを行ったときに初めて表示します。

この設計が極めて有効な理由は、UIデザインが常に抱えている「使いやすさと多機能性のジレンマ」を論理的に解消できる点にあります。
初心者にとっては画面がシンプルで操作を学習しやすく（Learnability）、上級者にとっては必要なときに高度な機能へ素早くアクセスできる効率性（Efficiency of use）を両立できます。

なぜ「全部並べるUI」は破綻するのか？

画面上に選択肢を無秩序に並べると、人間の脳は強い認知負荷（Cognitive Load）を感じて処理落ちを起こします。
心理学における「ヒックの法則」が示す通り、人間が選択肢の中から1つを選び出すまでの時間は、画面上の選択肢の数が増えるほど対数的に増加します。

さらに、人間のワーキングメモリ（作業記憶）が一度に保持できる情報数は、一般に「4±1個」程度と限られています。
最初から20個の設定項目を視界に突きつけられると、ユーザーは何が重要なのかを判断できず、操作を諦めて画面を閉じてしまいます。

そのため、優れたUIデザイナーは「画面に何を置くか」よりも「初期表示から何を隠し、どのタイミングで見せるか」に細心の注意を払って設計します。
必要な情報が必要な瞬間にだけ目の前に現れる状態を作ることが、プログレッシブディスクロージャーの本質です。

2. 段階的に開示する4大UIパターンと使い分け基準

プログレッシブディスクロージャーを実際の画面に落とし込む際、情報の性質や作業コンテキストに応じて適切なUIパターンを選択する必要があります。
実務で頻繁に使われる代表的な開示パターンは、以下の4つのアプローチに分類されます。

① インライン展開（アコーディオン / 詳細トグル）

同一画面のレイアウトを保ったまま、ボタンの押下によってその場（インライン）で領域が広がるパターンです。
「高度な設定を表示」「FAQの回答を見る」のように、前後の文脈を保ったまま少しの追加情報を取り出したい場面に最も適しています。

コンポーネントを設計する際は、アコーディオンの開閉状態（展開前 / 展開後）を縦並びのレイアウトで構築します。
開閉トリガーには回転するChevronアイコン（下向き・上向き）を添え、クリックで領域が展開することを視覚的に示します。
ただし、展開時にページ全体の高さが変わり、後続の要素が下へ押し出されるため、頻繁に開閉する項目を縦に何十個も連続して並べる構成は避ける必要があります。

② レイヤード展開（モーダル / ボトムシート / ドロワー）

現在の画面の上に半透明のオーバーレイを敷き、別のサーフェス（階層）を重ねて詳細情報を表示するパターンです。
複雑な絞り込みフィルターや、項目の詳細編集、確認ダイアログなど、元の画面から一時的に集中を切り替えて行う作業に適しています。

レイヤード展開を採用する場合、PCでは画面中央に浮遊するモーダル、スマートフォンでは親指で操作しやすいボトムシート（ハーフモーダル）を活用するのが実務の標準です。
作業が完了したら「保存」または「閉じる」操作で迷わず元の画面へ復帰できるため、ユーザーが現在地を見失うリスクを最小限に抑えられます。

③ ステップ式展開（マルチステップフォーム / ウィザード）

アカウント登録や購入手続き、初期設定などの長い入力プロセスを、論理的な手順（ステップ1、ステップ2、ステップ3）に分割して順番に開示するパターンです。
全30項目の入力欄が1画面に連なる巨大なフォームを、1画面あたり3〜5項目ずつに分解して提示することで、ユーザーの心理的抵抗を大幅に軽減できます。

ステップ式展開を機能させるためには、全体のステップ数と現在の進捗を示す「ステッププログレスバー」の併設が必須です。
「あとどれくらいで完了するのか」という全体像が見えているからこそ、ユーザーは途中で挫折せずに次のステップへと進むことができます。

④ オンデマンド展開（ツールチップ / ヘルプアイコン / ポップオーバー）

画面上のテキストに添えられた「？」アイコンやリンクに対して、ホバーまたはタップしたときだけ小さな吹き出しを表示するパターンです。
専門用語の解説や、パスワードの文字数条件、入力例の補足など、「知りたい人だけが読めばよい補助情報」をスマートに配置できます。

ツールチップの最大のメリットは、主要なUIのレイアウトや文字量を一切圧迫しない点にあります。
ただし、スマートフォンのようなタッチデバイスではホバー操作が存在しないため、タップで表示・枠外タップで非表示となるインタラクションを正しく設計することが重要です。

段階的開示の4大UIパターン比較まとめ

3. 隠しすぎて失敗しないための「3つの境界線ルール」

プログレッシブディスクロージャーは強力な設計原則ですが、使い方を誤ると「必要な機能が見つからない不親切なUI」に転落します。
画面をシンプルにしたい一心で重要な情報まで奥深くに隠してしまう設計ミスを防ぐため、以下の3つの境界線ルールを実務の基準として設定してください。

ルール①：80%のユーザーが必要とするPrimary情報は絶対に隠さない

プログレッシブディスクロージャーの基本は、「主要タスク（Primary）は露出させ、例外タスク（Secondary）を段階化する」ことです。
大多数のユーザーが利用する検索窓、主要アクションボタン、基本的な入力項目をアコーディオンやモーダルの奥に隠してはなりません。

自分自身も過去のレビューで、「画面をスッキリさせたい」という理由から、配送先住所の入力フォーム全体をアコーディオンの中に隠してしまったことがあります。
その結果、ユーザーテストで「どこに入力すればいいのか分からない」と全員が迷ってしまい、Primary情報の不可視化がどれほど致命的かを実感しました。
隠してよいのは、あくまで「知らなくても目的を達成できる高度なオプション」だけに限定します。

ルール②：開示トリガーのラベルは具体的に記述する

ボタンやリンクのテキストが「詳細」「その他」「設定」のように抽象的すぎると、ユーザーはその中に何があるのかを推測できません。
中身が分からないボタンをわざわざクリックしてくれるユーザーはごく少数です。

開示トリガーのラベルには、展開されるコンテンツの内容を具体的に予告する文言を用います。
たとえば、「詳細」ではなく「詳細な通知タイミングを設定する」、「その他」ではなく「配送日時の指定オプションを開く」のように記述します。
何が表示されるのかが事前に予測できるからこそ、ユーザーは目的を持って安心してクリックできます。

ルール③：展開状態から迷わず戻れる「閉じる導線」をセットにする

情報を開示するトリガーを設置したら、それと対になる「折りたたむ」「閉じる」ための導線を必ずセットで設計します。
一度展開したアコーディオンが二度と閉じられなかったり、開いたモーダルの閉じるボタンが見当たらなかったりすると、ユーザーは画面を元に戻せずストレスを抱えます。

アコーディオンであれば再度のクリックで元のコンパクトな状態に戻り、モーダルであれば右上「×」ボタンだけでなく背景オーバーレイのタップやESCキーでも閉じられる可逆性を担保します。
「いつでも初期のクリーンな状態に戻れる」という安心感があるからこそ、ユーザーは自由に画面を探索できます。

4. 次のステップ：あわせて深掘りしたい知見

プログレッシブディスクロージャーをさらに深く実務に応用するためには、関連する認知心理学の基礎理論や、パーツ設計のルールをあわせて押さえておくことが効果的です。
以下の記事でも、画面設計の根拠となる基準を詳しく解説しています。

人間が選択肢に直面したときの意思決定負荷や、情報のチャンキング原則を理論的に学びたい方は、こちらの記事も参考にしてみてください。

UIデザインに効く認知心理学の法則5選｜ヒック・フィッツ・ヤコブの実務応用

UIデザインの意思決定を感覚論から論理的な設計へ変える認知心理学の法則5選（ヒック、フィッツ、ヤコブ、ミラー、フォン・レストルフ）を解説。現場のFigma実務ですぐに使える設計基準を網羅します。

段階的開示をカードコンポーネントの中で展開する際の枠線やシャドウ、余白のバランス感覚を掴みたい方は、以下の記事で具体的な整理基準を確認できます。

カード型UIの設計ルール｜枠線・影・余白の使い分けと情報整理術

カード型UIの設計ルールと情報整理のコツを現役デザイナーが解説。枠線・影・背景色・余白の境界線4パターンの使い分けから、詰め込みすぎを防ぐ視覚階層、クリック領域のアクセシビリティまで具体的に整理します。

レイヤード展開（モーダルやボトムシート）をスマートフォン実務で破綻なく実装したい場合は、以下の使い分けマトリクスが役立ちます。

モーダル・ボトムシートの使い分け基準｜スマホで失敗しないUI選定ルール

スマホUIでモーダル、ボトムシート（ハーフモーダル）、ドロワー、画面遷移のどれを使うべきか迷っていませんか？操作の不可逆性と情報量の2軸で整理したUI選定マトリクスを現役デザイナーが詳しく解説します。

まとめ：段階的な情報開示が使いやすさと多機能性を両立させる

UIデザインにおける「親切さ」とは、持っている情報をすべて一度に差し出すことではありません。
初期表示ではユーザーの目的達成に必要な主要タスクを明快に整え、詳細な設定や補助情報を求めるユーザーにだけ適切なタイミングで次の選択肢を提供する設計が大切です。

画面が情報過多で整理がつかなくなったときは、ぜひ「どの情報を初期に表示し、何を段階的に開示できるか」という視点でレイアウトを見直してみてください。

The post 段階的開示（プログレッシブディスクロージャー）入門｜情報過多を防ぐUI設計 first appeared on デザペディア.

UIをデザインしているとき、ブランドカラーを目立たせようとしてボタンやアイコン、見出し、タグに同じ色を使いすぎてしまった経験はないでしょうか。
良かれと思って色を足した結果、画面全体がチカチカして「結局どこが最重要のアクションなのか」が分からなくなるケースは現場で頻繁に見られます。

配色はセンスや感覚だけに頼ると、画面内の要素が増えるにつれて整合性を保つのが難しくなります。
そこで役立つのが、インテリアデザインの黄金比率をUI向けに応用した「60-30-10の法則」です。
本記事では、この黄金比率をUIコンポーネントの構造へ具体的に落とし込み、迷わず美しい配色システムを構築する実践手法を整理します。

1. そもそもUIにおけるアクセントカラーの役割とは？

装飾ではなく「Primaryアクションへの誘導」

UIデザインにおけるアクセントカラーは、グラフィックデザインやイラストのような「見た目を華やかに飾るための色」ではありません。
その本質は、画面内で「次に押してほしい主要なアクション（Primary CTA）」をユーザーに迷わず見つけてもらうことにあります。

画面を開いたユーザーは、わずか数秒のうちに「どこを見ればいいのか」「どこを押せば目的が達成できるのか」を判断します。
その際、周囲の背景やテキストから最も際立った色（アクセントカラー）が、最優先で視線を集めるPrimaryボタンとして機能します。

有彩色が多すぎると何が起きる？「コントラストの飽和」が引き起こす視線誘導の混乱

人間の視覚システムは、無彩色（白・黒・グレー）の背景に対して、色味を持った「有彩色（アクセントカラー）」に無意識に視線を引きつけられる性質を持っています。
しかし、アクセントカラーを画面内のあらゆる要素に散りばめてしまうと、「コントラストの飽和（Contrast Saturation）」が発生します。

有彩色（色味を持った強い色）の面積や主張が画面全体で大きくなりすぎると、ユーザー視点では「画面のどこに目を引かせればいいのか（何が一番重要なのか）」が直感的に分からなくなります。
「すべてが強調されている画面」は、ユーザーにとっては「何も強調されていない画面」と同じです。

その結果、デザイナーが本来最も意図していたはずのアクション（「新規登録」や「購入手続き」などのPrimary CTA）をユーザーが正確に行えない状況に陥ります。
視線が定まらず操作に迷ったユーザーは、目的のアクションを完了できずに画面から離脱してしまいます。

UIにおける配色の役割は、画面をカラフルにすることではなく、デザイナーが意図した順序でユーザーを迷わずアクションへ導くことです。
有彩色を10%の1〜2箇所に厳密に絞り込み、周囲を無彩色で抑えるからこそ、ユーザーは一瞬で目的のボタンを見つけ出し、意図通りの操作を実行できます。

現場でブランドカラーが散らかりやすい背景と構造的要因

実際のプロダクト開発現場でも、この「有彩色のインフレ」は非常によく起こります。
例えば、ブランドの認知を高めようと意識するあまり、Primaryボタンだけでなく、ヘッダー背景、見出しテキスト、アイコン、ステータスタグ、さらにはグラフの枠線に至るまで、同じブランドカラーのブルーを適用してしまうようなケースです。

一見するとブランドの統一感が出ているように思えますが、いざ画面全体を俯瞰すると、「画面全体が青すぎて目が疲れ、どれが押せるボタンで、どこが重要ステータスなのか判別できない」という状態に陥ります。
実際にプロトタイプでユーザーテストを行っても、本来押してほしい決定ボタンを見落として迷う様子が顕著に現れるなど、感覚的な色選びはユーザービリティを直接損ねる要因になります。
アクセントカラーは「絞り込んで使う」からこそ機能するのだと意識することが、UI配色における第一歩です。

2. UIデザインにおける「60-30-10の法則」基本思想

インテリアから生まれた「60-30-10の法則」

「60-30-10の法則」は、もともとインテリアデコレーションの世界で、部屋のカラーコーディネートを誰でも失敗なく調和させる経験則として長年使われてきた黄金比率です。
部屋全体を見渡したときに、ベースカラー（壁や床）を60%、メインカラー（家具やカーテン）を30%、アクセントカラー（クッションや小物）を10%の比率で配分すると、空間が最もバランスよく美しく整うとされています。

この考え方は、情報設計と視認性が求められるUIデザインの画面設計においても極めて有効です。
画面内の色面積を論理的な比率で制御することで、統一感のある落ち着いた土台と、際立ったアクション領域を両立できます。

Web/UIで「70:25:5」ではなく「60:30:10」が機能する理由

デザインの入門書などでは、ポスターやWebサイトの配色比率として「70:25:5（ベース70%、メイン25%、アクセント5%）」が紹介されることもあります。
グラフィックやシンプルなLPであればアクセント5%でも十分に目立ちますが、機能的なWebアプリや管理画面のUIでは「60:30:10」がより実用的です。

UIには、ボタンの通常状態だけでなく、ホバー、アクティブ、選択状態のタブ、未読バッジなど、ユーザーの操作に応じて状態を示す要素が複数存在します。
アクセント比率を10%程度確保しておくことで、操作要素の存在感を損なわずに状態変化を明快に表現できるようになります。

3. UIコンポーネントへの具体マッピング（Base 60% : Main 30% : Accent 10%）

「60-30-10の法則」を実際のUIに適用する際、画面全体のピクセル数を厳密に計算する必要はありません。
画面を構成するUIコンポーネントのレイヤー（役割）ごとに、どの色を割り当てるかを明確にルール化することが重要です。

「メインカラー＝ブランドカラー」ではない？UI配色における用語の落とし穴

従来のグラフィックやWebデザインでは、「メインカラー＝企業のブランドカラー（ロゴの色）」と呼ぶことが多かったため、ここで少し混乱しがちです。
しかし、UIデザインにおける「60-30-10の法則」でいうMain 30%は、「画面内の情報構造とコンテンツ（文字や線）を担う色」を指します。

もしブランドカラー（例えば鮮やかな青や緑）を30%もの大面積で使ってしまうと、画面の大半が色で埋め尽くされ、アクセント10%が全く目立たなくなってしまいます。
UIにおけるMain 30%は、あくまで「コンテンツを快適に読ませるためのテキストや枠線」に充てるのが成功の鉄則です。

【具体例】このサイト「デザペディア」で見る60-30-10の配分

イメージを掴みやすくするために、今見ていただいている当サイト（デザペディア）の画面構造を例に分解してみましょう（※2026年9月時点のデザインを元にしています）。

• Base 60%（背景・キャンバス）: 記事本文エリアの背景（淡いペールブルー）やカード面のホワイト。画面の約6割を占める広大な下地であり、無彩色〜淡いトーンで敷くことで視覚的ノイズをなくし、コンテンツを引き立てます。
• Main 30%（構造・テキスト・コンテンツ）: 本文のダークグレー、見出しのブラック、H2下線のライトグレーや枠線。画面の約3割を占め、読者に情報を正しく届けるための文字情報と境界線をしっかり形作ります。
• Accent 10%（Primaryアクション・視線誘導）: ブランドブルーのPrimaryボタン、タグバッジ、H2見出し左側のアクセントライン、青リンク。画面全体のわずか1割程度に絞り込まれているからこそ、読者の視線が迷わず「押すべきボタン」に吸い寄せられます。

このように、「背景（60%）の上に、文字と線（30%）で骨格を作り、一番押してほしい箇所だけ色（10%）を差す」と捉えると、どんな画面でも迷わず配色を決められるようになります。

Base 60%（ベースカラー）：背景とサーフェス（Surface / Background）

Baseの60%は、画面全体の基盤となる背景領域です。
コンテンツを配置する余白を十分に確保し、視覚的な圧迫感をなくして情報を受け入れやすくする役割を持ちます。

• 背景色: 純白（#FFFFFF）や、目に優しいオフホワイト・ペールブルー（#F8FAFC, #F5F7FFなど）。
• カード・コンテナ面: 背景とわずかに明度差をつけたサーフェス色。
• モーダル・ドロワーの背景面: 主要コンテンツを支える下地領域。

ベース領域に余計な色味を持たせず無彩色（ニュートラルグレー）またはごく淡いトーンを維持することで、上位のテキストやボタンが引き立ちます。

Main 30%（メインカラー）：情報構造と可読性（Text / Border / Neutral）

Mainの30%は、情報の骨格を作り、コンテンツの可読性を担保する構造領域です。
画面内の大半を占めるテキストや線がこの領域に該当し、UI全体の秩序と安心感を形作ります。

• 見出し・本文テキスト: 背景とのコントラスト比4.5:1以上を確保したダークグレー・濃紺（#0F172A, #1E293Bなど）。
• 補足テキスト・メタ情報: 優先度を下げたミディアムグレー（#64748Bなど）。
• 境界線・区切り線: カードやテーブルの輪郭を定義する薄いグレー（#E2E8F0など）。
• 入力フォームの未選択枠線: 入力エリアの境界を示すニュートラルなボーダー。

真っ黒（#000000）を避け、わずかに青みや暖かみを含んだダークグレーを採用すると、画面全体のトーンが柔らかくまとまります。

Accent 10%（アクセントカラー）：行動喚起の焦点（Primary Action / Highlights）

Accentの10%は、ユーザーの視線を集めて具体的なアクションへと導く焦点領域です。
1画面（またはファーストビュー）の中で、「ユーザーが次に取るべき最も重要な1〜2箇所の操作」だけに限定して適用します。

• Primary CTAボタン: 「新規登録」「購入手続き」「保存」などの最重要ボタン。
• アクティブ状態の選択要素: 選択中のタブ、選択されたラジオボタンやトグルスイッチ。
• 重要通知・未読バッジ: ユーザーの注意を喚起する小さなバッジやインジケーター。

この領域にだけ高彩度のカラーを適用することで、ユーザーは迷うことなく目的の操作を見つけ出すことができます。

【UIコンポーネント別】60-30-10適用早見表

各UIコンポーネントがどの比率に属するのかを以下の表に整理しました。

4. 画面を破綻させないための「3つの実務調停ルール」

基本の60-30-10比率を定めても、実際のプロダクト運用では「エラー表示」「複数のボタン」「ダークモード」などの例外ケースに直面します。
ここでは、現場で配色が崩れないための3つの実務調停ルールを解説します。

ルール①：セマンティックカラー（エラー・成功）との衝突を防ぐ「フィードバック層」の分離

UIには、アクセントカラー以外にも、エラー（赤）、警告（黄・オレンジ）、成功（緑）といったセマンティックカラー（状態伝達色）が必要です。
これらをアクセントカラーと同じテンションでベタ塗りしてしまうと、画面内で強烈な色が衝突し、10%の枠を大きくオーバーしてしまいます。

セマンティックカラーは「アクセント層」ではなく、独立した「フィードバック層」として分離して扱います。
背景全体を濃い赤にするのではなく、「淡い赤の背景色（明度95%前後）＋濃い赤のテキスト・アイコン」の組み合わせで表現するのが実務の定石です。
面積あたりの彩度を抑えることで、Primaryボタンの視認性を邪魔せずに状態を的確に伝えることができます。

ルール②：Secondary・Tertiaryボタンは「Main 30%の無彩色（グレー）」を基本にする

画面内に「保存（Primary）」と「キャンセル（Secondary）」のように、複数のアクションが並ぶ場面は日常的に発生します。
このとき現場でよく見かけるのが、Secondaryボタンにも同じアクセントカラーを流用してしまうパターンです。

具体的には、「青いベタ塗りのPrimaryボタン」の隣に、「青い枠線＋青い文字のアウトライン型Secondaryボタン」を並べてしまうようなケースです。
デザインシステムによっては許容される設計もありますが、「60-30-10の法則」に基づいて画面のノイズを抑え、Primaryへの視線誘導を迷わせないベースラインとしては、Secondary以下を無彩色（グレー）で組むアプローチが推奨されます。これには明確な2つの根拠があります。

根拠1：アクセント比率（10%）をオーバーし、視線誘導の優先度が崩れる

アクセントカラーは「画面全体で最も注目させたい1〜2箇所」に絞るからこそ機能します。
しかし、SecondaryボタンやTertiaryボタンにまで同じ青色を使ってしまうと、画面内の青の占有率が10%を大きく越えてしまいます。その結果、画面内に強い有彩色が散らばり、ユーザーの視線が分散して「今どちらを優先して押すべきか」の判断にわずかな迷いが生じます。

根拠2：屋外やスマホ画面における認知負荷と誤認リスク

ベタ塗りとアウトライン（枠線）の差は、じっくり画面を見ているデザイナーにとっては明確に見えても、移動中にスマホを操作しているユーザーや直射日光下のディスプレイでは、同じ色相であるだけで「同列の強いボタン」として目に飛び込んできます。明度差だけに依存した差別化は、認知負荷を高める原因になります。

推奨アプローチ：Secondary以下を無彩色に倒し、Primaryの「青」を際立たせる

AppleのHuman Interface GuidelinesやモダンなWebアプリケーションのUIでは、SecondaryやTertiaryボタンを「Main 30%のグレー（無彩色）」で解決する設計パターンが多く採用されています。

• Secondaryボタン: 薄いグレーの背景（#F1F5F9）＋濃いグレーの文字（#1E293B）
• Tertiaryボタン: 枠線なし・背景なしのゴースト型＋ミディアムグレーの文字（#64748B）

このように設計すると、「画面内でアクセントカラー（有彩色）をまとっているのはPrimaryボタンただ1つだけ」という状態が作れます。これによって視線の着地点が完全に固定され、ユーザーは一切迷わずに目的の操作を完了できます。

ルール③：ダークモード時の比率維持と彩度コントロール（OKLCH知覚調和）

ダークモードでは、Base 60%が「黒〜濃いグレー」に反転します。
この暗い背景の上に、ライトモードと同じ高彩度のアクセントカラーをそのまま配置すると、知覚的なコントラストが強すぎて文字が滲んで見えたり、目がチカチカしたりする問題が生じます。

ダークモードにおけるアクセントカラーは、ライトモードの値から彩度を5〜10%程度抑え、明度をわずかに引き上げた調整値を用意するのが実用的です。
OKLCH色空間などを活用して人間の知覚に沿ったトーン調整を行うことで、ダークモード特有の眩しさを防ぎつつ、10%のアクションとしての際立ちを維持できます。

5. 次のステップ：あわせて深掘りしたい知見

配色の黄金比率を押さえた後は、グラデーションの濁り防止やダークモードの変数設計、Figma Variablesでのトークン管理をあわせて学ぶことで、さらに強固なUIデザインシステムを構築できます。

以下の記事では、現場で起こりがちな配色の失敗パターンと、Figma上での具体的な操作テクニックを詳しく解説しています。

グラデーションカラーがダサい原因は？Figmaで濁らない配色ルール【2026】

中間色がグレーに濁る現象をOKLCH知覚色空間で解決。Figmaで美しく澄んだグラデーションを作る具体的な配色テクニックを解説します。

ダークモードでのサーフェス階層や配色の破綻を防ぐ基準については、こちらの記事が役立ちます。

ダークモードは必要？3つの導入基準とFigma変数設計・便利プラグイン

安易な白黒反転で失敗しないための3つの導入基準と、Figma Variables（変数）を用いた実務設計手順を体系的に整理しました。

Figma上でカラーパレットを定義し、Primitive（生の色）とSemantic（UI上の役割）の2層トークン構造としてチーム運用する具体的な手法については、以下の完全ガイドを参考にしてみてください。

Figma Variables（変数）の使い方完全ガイド｜破綻しない命名規則とトークン設計【2026】

Variablesの基本概念からStylesとの違い、PrimitiveとSemanticの2層トークン構造まで、破綻しない設計術を徹底解説します。

あわせて読みたい推薦書籍

ベース・メイン・アクセントの3色を軸に、多色使いによる視線散乱を防ぎ、まとまりのある配色を組み立てるための実践書です。

終わりに

最後までお読みいただき、ありがとうございます！

UIデザインにおいて、色を効果的に扱う秘訣は「足すこと」ではなく、役割を定めて「引き算すること」にあります。
インテリアの黄金比である「60-30-10の法則」をUIのレイヤー構造に当てはめることで、感覚に頼らない論理的で美しい画面を作ることができます。

アクセントカラーを10%の重要なアクション要素として大切に扱い、ユーザーが迷わず心地よく操作できるインターフェースをぜひ目指してみてください。

これからも、心地よいUI配色とデザイン設計を一緒に楽しんでいきましょう。
それでは、良いデザインライフを！

The post 【60-30-10の法則】アクセントカラーの使いすぎを防ぐUI配色の黄金比率 first appeared on デザペディア.

UIデザインのコンポーネント設計を進める中で、「気づけば無駄なバリアントが増えすぎてしまったな」と感じた経験はないでしょうか。
「これって別の機能を使えばもっと減らせるんじゃないか」「もっとスマートにまとめられるはずでは」と、肥大化したバリアントの整理に悩む場面は多いはずです。

Figmaのコンポーネントプロパティ（Component Properties）を適切に組み合わせることで、バリアントの過剰な肥大化を防ぎ、スマートな運用体制を整えられます。
今回は、実務で迷わないプロパティの使い分け基準と、現場で役立つ具体的な設計手順を分かりやすく整理しました。

1. なぜ「バリアント爆発」が起きるのか？Variants単体運用の限界

コンポーネントを設計する際、あらゆるバリエーションをVariantsだけで解決しようとすると、「掛け算によるパターンの急増」に直面します。
海外のデザインシステムや国内のUI設計現場では、この状態を「バリアント爆発（Variant Explosion）」と呼ぶこともあり、管理の破綻を招く典型的なつまずきポイントとなっています。

掛け算で増え続けるバリアントの構造的課題

例えば、標準的なアクションボタンをVariantsだけで作成する場合を考えてみましょう。
ボタンに必要な要素を細かく掛け合わせていくと、以下のようにパターン数が急速に膨らんでいくのが実態です。

• ボタンサイズ: 3種類（Small / Medium / Large）
• スタイル種別: 3種類（Primary / Secondary / Outline）
• アイコン構成: 4種類（アイコンなし / 左アイコン / 右アイコン / 両方アイコン）

これらのかけ合わせだけでも、3 × 3 × 4 = 36通り のバリアントがキャンバス上に並ぶ計算になります。
さらにHoverやActive、Disabledなどの状態（States）まで真面目に全部バリアントで再現しようとすると、1つのボタンだけで100個以上のバリアントを管理しなければならなくなってしまいます。

大量のバリアントを抱えたコンポーネントは、Figmaの動作を重くするだけでなく、共通の角丸や文字サイズを1箇所変更するだけで莫大な修正工数を生み出します。
「では世の中で運用されている優れたデザインシステムはどう管理しているんだろう？」と公式ライブラリを観察し、実務での構造を徹底的に洗い出してみました。

Material DesignやShopify Polarisなどの著名なデザインシステムを見てみると、バリアントの数は最小限に抑えられています。
見た目の骨格だけをバリアントに残し、要素の出し入れや中身の差し替えはコンポーネントプロパティへ綺麗に逃がしていることが分かりました。

従来のVariantsとComponent Propertiesの根本的な違い

バリアントの急増を防ぐために導入された仕組みが、コンポーネントプロパティ（Component Properties）です。
両者は対立する機能ではなく、コンポーネントの「変化の性質」に応じて以下のように明確な役割分担を持っています。

「構造そのものが切り替わるものはVariants」「中身の差し替えや表示切替はComponent Properties」という境界線を引くことが、破綻しないコンポーネント設計の第一歩となります。

2. まず押さえたい「3大コンポーネントプロパティ」の役割と設定手順

Figmaのコンポーネントプロパティにはいくつかの種類がありますが、実務で頻繁に活躍するのは「Boolean（ブール値）」「Text（テキスト）」「Instance Swap（インスタンスの切り替え）」の3つです。
それぞれの役割と具体的な設定方法を順番に見ていきましょう。

1. Boolean（ブール値）：要素の表示・非表示をトグル化する

Booleanプロパティは、コンポーネント内の特定のレイヤーをスイッチ（True / False）で表示・非表示できる機能です。
ボタンの左右アイコンや入力欄のヘルプテキストなど、「必要なときだけ出す要素」を扱う場面に適しています。

設定手順はとてもシンプルで、わずか数クリックの操作で完了します。
コンポーネント内の対象レイヤーを選択し、右サイドバーの操作を行うだけで連動が完了します。

1. 対象レイヤーを選択: コンポーネント内の非表示にしたい要素（例: Icon_Left）を選択します。
2. レイヤーセクションのアイコンをクリック: 右パネル「レイヤー（Layer）」の右端にある「プロパティ作成アイコン（四角に下向き矢印）」をクリックします。
3. 名前と初期値を設定: プロパティ名（例: showLeftIcon）を入力し、デフォルト値（TrueまたはFalse）を指定して「プロパティを作成」を押します。

オートレイアウトが適用されたフレーム内でBooleanプロパティを使用すると、非表示にした際に自動で余白が詰まるため、手動で幅を調整する必要がなくなります。
アイコンあり用とアイコンなし用のバリアントを別々に用意していた手間が、このトグル1つで完全に解消されます。

2. Text（テキスト）：キャンバスを崩さず右パネルから文言変更

Textプロパティは、コンポーネント内の文字情報を右サイドバーのテキストフィールドから直接編集できる機能です。
キャンバス上の文字を何度もダブルクリックして深い階層に潜る手間を削減できます。

特に複数人で作業を進める際、ダブルクリックの誤操作でレイアウト位置やフォント設定を崩すミスを未然に防止できます。
設定手順は以下の3ステップで完結します。

1. テキストレイヤーを選択: コンポーネント内の文字レイヤー（例: Label）を選択します。
2. テキストセクションのプロパティを作成: 右パネル「テキスト（Text）」セクションのコンテンツ横にあるプロパティ作成アイコンをクリックします。
3. プロパティ名と初期テキストを登録: プロパティ名（例: label）と、初期表示させたい文字列を入力して作成します。

インスタンスを選択した際、右サイドバーのプロパティ欄にテキスト入力ボックスが並ぶため、フォームに入力するような感覚でスピーディーに文言を流し込めるようになります。

3. Instance Swap（インスタンスの切り替え）：アイコンやパーツを素早く差し替える

Instance Swapプロパティは、コンポーネント内にネストされたインスタンスを、別のアセットへ素早く交換できる機能です。
ボタン内のアイコンやアバター画像、ステータスバッジなど、共通規格の別パーツへ切り替える際に重宝します。

設定は、ネストされているコンポーネントインスタンスを選択した状態で行います。
右パネルのコンポーネント名横にあるプロパティアイコンから、以下の手順で紐付けを行います。

1. ネストされたインスタンスを選択: ボタン内のアイコンインスタンス（例: Icon / Search）を選択します。
2. インスタンス切り替えプロパティを作成: 右パネルのコンポーネント名横にあるプロパティ作成アイコンをクリックします。
3. Preferred values（推奨値）の指定: プロパティ名（例: leftIcon）を設定すると同時に、差し替え候補となるアイコン一覧を「推奨値（Preferred values）」として登録します。

この推奨値設定を活用することで、プロジェクト内で使用を許可したアセットのみをドロップダウンの上位に優先表示できます。
デザイナー仲間が数十〜数百個あるアイコン一覧から延々と探す手間を省き、デザインシステム全体の統一感を維持するのにも役立ちます。

3. 実践！ボタンと入力フォームでバリアントを激減させる設計手順

3大プロパティの役割を把握したところで、実務で誰もが作成する「アクションボタン」と「入力フォーム」を題材に、具体的な削減手順を検証してみましょう。
バリアントとプロパティを正しく組み合わせることで、どれほどデータ構造がシンプルになるかを体感できます。

実践例1：ボタンコンポーネント（36バリアント → 6バリアントへ圧縮）

まずは先ほど例に挙げた、サイズ3種×スタイル3種×アイコン状態4種で計36バリアントあったアクションボタンの再設計です。
このボタンコンポーネントを、以下の役割分担ルールに従って再構築します。

• Variantsに残すもの（見た目の枠組み）:
  – Size: Small（高さ32px）/ Medium（高さ40px）/ Large（高さ48px）
  – Variant: Primary（塗りつぶし）/ Secondary（枠線のみ）
• Component Propertiesに逃がすもの（要素の制御）:
  – showLeftIcon: Boolean（初期値: True）
  – showRightIcon: Boolean（初期値: False）
  – leftIcon: Instance Swap（推奨値: アロー、検索、プラスなど主要アイコン）
  – label: Text（初期値: “Button”）

この再構成によって、キャンバス上に用意するバリアントは「3サイズ × 2スタイル = わずか6個」にまで激減します。
アイコンの有無や種類、テキストの長さはすべて右パネルから柔軟に切り替えられるため、デザインの自由度を損なうことなくキャンバスを大幅に軽量化できます。

さらに、ボタン全体に適切なオートレイアウトを設定しておけば、テキスト文字数やアイコンの出し入れに応じてボタン幅が自動伸縮します。
オートレイアウトの基礎やレスポンシブに連動する余白設計をあわせて理解しておくと、プロパティの効果を最大限に引き出すことができます。

Figmaオートレイアウト完全ガイド！崩れないネストと余白設計

Figmaのオートレイアウトを基礎から徹底解説。リサイズ挙動（Hug/Fill/Fixed）の使い分けや崩れないネスト構造、実務で役立つコンポーネント余白設計をまとめました。

実践例2：入力フォーム（テキストフィールド）の設計

入力フォームも、バリアントが増えすぎて管理が煩雑になりやすい代表的なUIコンポーネントです。
上部ラベルや必須マーク、下部のヘルプテキストやエラー表示など、付属する要素が多岐にわたるためです。

入力フォームでは、「状態（States）」のみをVariantsで切り替え、周辺パーツをプロパティ化するアプローチが極めて有効です。
具体的な分担ルールを整理してみましょう。

• Variantsで管理する要素:
  – State: Default（通常）/ Focused（入力中・青枠）/ Error（エラー・赤枠）/ Disabled（非活性・グレー）
• Component Propertiesで管理する要素:
  – showLabel: Boolean（上部ラベルの表示切替）
  – labelText: Text（ラベルの文言変更）
  – placeholder: Text（入力欄内のプレースホルダー文言）
  – showHelperText: Boolean（下部注釈の表示切替）
  – showTrailingIcon: Boolean（末尾のクリアボタンやパスワード可視化アイコン）

周辺パーツをすべてバリアントとして掛け算すると数十パターンに及ぶ入力フォームも、4つの状態バリアントだけで完結します。
エラーメッセージの表示切替や文言変更も右パネルから数秒で調整できるため、画面仕様書の作成スピードも格段に向上します。

整ったレイヤー構造はプロパティの設定ミスを防ぎ、将来的なデザインシステムの拡張性を高める重要な土台となります。
チーム開発でも破綻しないレイヤーの階層ルールやセマンティックな命名規則については、以下の記事で体系的に解説しています。

ぐちゃぐちゃにならない！Figmaレイヤー整理術と「AIレディ」な命名ルール完全ガイド【プロンプト付き】

チーム開発やAI連携で破綻しないFigmaのレイヤー整理術。階層構造のルール化やセマンティックな命名規則、一括リネームの実践テクニックを現場目線で解説します。

4. さらに一歩進んだ実務ワザ：ネストされたプロパティの公開

複数のコンポーネントを組み合わせた複合的なUI（カードやリスト行など）を作る際、非常に重宝するのが「ネストされたプロパティの公開（Expose nested instances）」という機能です。
この機能を活用することで、親コンポーネントから子コンポーネントの操作パネルへダイレクトにアクセスできます。

深い階層のレイヤーを開かずに親から直接操作する

例えば、ヘッダー画像・タイトル・本文・アクションボタンで構成される「カードコンポーネント」の実装を想定してみましょう。
従来はカード内のボタン文言を変えるために、キャンバス上でカードを3〜4回ダブルクリックして深いレイヤーまで潜る必要がありました。

親コンポーネント側でネストプロパティを公開しておくと、カード全体を選択しただけで、内包されているボタンのプロパティが親の右パネルにそのまま表示されます。
設定手順は以下の通りです。

1. 親コンポーネントを選択: カード全体のメインコンポーネントを選択します。
2. プロパティ一覧から「ネストされたインスタンス」を追加: プロパティセクションの「＋」ボタンを押し、「ネストされたインスタンス（Nested instances）」を選択します。
3. 公開したい子コンポーネントにチェック: カード内に配置されているボタンインスタンス（例: Button）にチェックを入れます。

この設定を施しておくだけで、画面デザインを組む作業者はカードをクリックした瞬間に、ボタンのラベル打ち替えやアイコン切り替えを右パネルだけで完結できます。
階層を行き来する無駄なクリック操作を削減でき、画面作成のテンポがスムーズに向上します。

フロントエンド実装（React等のProps構造）との親和性

Component Propertiesを整える最大の恩恵の1つは、エンジニアの実装コード（ReactやVueのProps）と設計思想が1対1で直結する点です。
フロントエンド開発では、ボタンのアイコン有無を別コンポーネントとして量産せず、hasIcon={true} のようなPropsで制御するのが一般的です。

Figma側のプロパティ名とコード側のProps名を揃えておくことで、Dev Mode（開発モード）を開いたエンジニアは「どのプロパティを渡せばよいか」を一目で理解できます。
デザイナーとエンジニアの間で「このバリアントはどう実装すべきか」という仕様確認の往復が減り、チーム間の協業が格段にスムーズになります。

プロパティによる構造制御と、Variablesによる値のトークン管理を組み合わせることで、変更に強い柔軟なUIライブラリが完成します。
Figma変数の階層設計やPrimitive/Semanticの2層トークン運用については、以下のガイド記事で詳しく紹介しています。

Figma Variables（変数）の使い方完全ガイド｜破綻しない命名規則とトークン設計【2026】

Figma Variablesの使い方を基礎から解説。Stylesとの使い分け、PrimitiveとSemanticの2層トークン設計、スラッシュ命名規則まで現場UIデザイナーが整理しました。

5. デタッチせずに中身を自由に入れ替える！注目の機能「スロット（Slots）」

コンポーネント設計において、多くのデザイナーが一度は直面するのが「外枠は共通化したいけれど、中身のレイアウトやコンテンツだけは画面ごとに自由に変えたい」というジレンマです。
これを解決する最新の設計手法として注目されているのが、「スロット（Slots）」と呼ばれるアプローチです。

デタッチを防ぐ「スロット構造（入れ替え領域）」の仕組み

モーダルダイアログや汎用カードを作成する際、中身にフォームを入れたり、リストを入れたり、画像を並べたりとコンテンツの自由度が求められるケースは珍しくありません。
従来のFigmaでは、中身を自由に変えたいがためにコンポーネントをデタッチ（Detach instance）してしまい、デザインシステムから切り離されるトラブルが多発していました。

スロットの仕組みを取り入れると、コンポーネントの外枠（ヘッダーやフッター、余白、影）を保ったまま、中央のコンテンツ領域だけをごっそり自由なUIに差し替えることができます。
これにより、親コンポーネントのアップデート恩恵を受け続けながら、画面ごとの柔軟な表現を両立できます。

実務でのスロット設計：Instance Swapスロットと最新機能

実務でスロットを実装するには、主に以下の2つのアプローチがあります。
案件の規模やライブラリの運用ルールに応じて使い分けるのが実用的です。

1. Instance Swapを活用した「スロットコンポーネント」:
   – 中身の入れ替え領域にあらかじめダミーの「Slotコンポーネント」を配置し、プロパティでInstance Swap可能にしておく定番手法です。
   – インスタンス配置時に、画面ごとに作成したカスタムフレーム（コンポーネント化済み）をスワップするだけで、外枠を崩さずに中身を丸ごと差し替えられます。
2. Figmaの新機能「スロットに変換（Convert to slot）」:
   – コンポーネント内のフレームを直接「スロット」として定義し、インスタンス側で中身を直接追加・削除・並べ替えられる公式アプローチです。
   – 別途コンポーネント化する手間なく、インスタンスの枠内へ直接パーツをドラッグ＆ドロップして中身を構築できます。

単一のアイコン差し替えであれば通常のInstance Swapで十分ですが、「中身の構造自体が画面ごとに可変するコンテナ系UI」にはスロットを活用するのが最もスマートです。

6. Variants・プロパティ・スロットの使い分け判断基準マトリクス

「これはVariantsで作るべきか、プロパティにすべきか、それともスロットを使うべきか」と迷ったときは、以下の判断基準に沿って整理するのがおすすめです。
チーム内でのレビュー時にも、共通の判断軸としてそのまま活用できます。

迷わないための機能選定マトリクス

チームで破綻させない運用のコツ

コンポーネントプロパティやスロットは非常に便利ですが、何でもかんでも多機能化してしまうと、右サイドバーが設定項目で埋め尽くされて操作性が低下します。
実務で運用する際は、「頻繁に変更する要素トップ3〜4個」に厳選してプロパティ化するのがちょうど良いバランスです。

最初から完璧な網羅を目指すのではなく、日々のデザイン制作の中で「何度もダブルクリックして編集しているパーツ」を見つけたらプロパティ化する、という段階的なアプローチがおすすめです。
無理のない範囲でスモールスタートさせることで、チーム全体に自然とルールが定着していきます。

あわせて読みたい推薦書籍

Auto Layoutやコンポーネントプロパティの活用から、エンジニアへのハンドオフまで、実務で迷わないFigma操作を体系化した実践書です。

終わりに

最後までお読みいただき、ありがとうございます！

今回は、Figmaコンポーネントの肥大化を防ぎ、スマートに管理するためのコンポーネントプロパティ（Component Properties）の使い方と実務設計を解説しました。
バリアント、各種プロパティ、そしてスロットの役割を明確に分けるだけで、キャンバスの軽快さもメンテナンスの手間も大幅に改善されます。

デザインシステムは、作って終わりではなく「日々の制作を支えるための道具」です。
まずはよく使うボタンや入力フォームのアイコンから、プロパティによる効率化を試してみてはいかがでしょうか。

これからも、日々のコンポーネント設計やUI制作を一緒に楽しんでいきましょう。
それでは、良いデザインライフを！

The post Figmaコンポーネントプロパティの使い方｜バリアント増えすぎを防ぐ設計術 first appeared on デザペディア.

数年前からOSやアプリで標準機能となったダークモード。
「とりあえず流行っているから」「今っぽく見えるから」という理由で、導入を検討したことのある方も多いのではないでしょうか。

しかし、単に背景を黒にして文字を白に反転させただけでは、コントラストがきつくて目が疲れたり、カードやモーダルの重なりが見えなくなってしまいます。
また、運用のルールを決めずにコンポーネントを別々に作ってしまうと、デザイン修正のたびに二重のメンテナンス工数がかかってしまいます。

ダークモードはすべてのサービスに無条件で必要な機能ではありません。
この記事では、そもそもダークモードを用意すべきかを見極める「3つの導入基準」から、実務でのメリット・デメリット、Figma Variablesを活用した破綻しない変数設計、制作を効率化するプラグインまでを体系的にまとめました。

1. そもそもダークモードは用意すべき？「導入基準」の3つの判断軸

ダークモードの設計に入る前に、まず考えるべきは「そのサービスに本当にダークモードが必要なのか」という根本的な問いです。
ユーザーの利用シーンやコンテンツの特性に合っていない場合、多大な工数をかけて実装しても、使われないどころかUXを損ねてしまうリスクがあります。

導入の是非を判断する際は、以下の3つの基準でサービスの性質を客観的に照らし合わせてみてください。

基準①：利用シーンと時間帯（暗所・夜間に使われるか？）

ユーザーがその画面を「どんな環境で開くか」は、最もわかりやすい判断材料です。
寝室や夜間の移動中、照明を落とした室内で使われるサービスであれば、ダークモードの眩しさ低減効果が大きく活きます。

SNS、動画配信アプリ、チャットツール、電子書籍リーダーなどは夜間の利用頻度が高いため、優先して対応すべき領域と言えます。
一方で、オフィスの明るい照明下でしか使われないBtoBの経理システムや、日中の閲覧がメインのコーポレートサイトでは、ダークモードの需要はそこまで高くありません。

基準②：コンテンツの性質（写真・映像中心か、長文・ECか？）

画面の中に配置されるメインコンテンツの種類によっても、向き不向きがはっきりと分かれます。
写真、映像、色分けされたデータグラフ、プログラムのコードなどは、暗い背景に置くことで周囲の光に邪魔されず、要素そのものが引き立ちます。

しかし、長文テキストをじっくり読ませるオウンドメディアや、商品の色味・質感を正確に確認する必要があるアパレル・食品のECサイトでは注意が必要です。
暗い背景に白い文字をぎっしり並べると、人間の眼球はピントを合わせにくくなり、読解スピードが低下することが知られています。
また、ECサイトで服の色味が背景の暗さで誤認されてしまうと、購入後の返品やトラブルに繋がりかねません。

基準③：デザインシステムの運用リソース（2重管理を許容できるか？）

見落とされがちですが、デザイナーやエンジニアの運用工数も極めて現実的な判断基準です。
ダークモードを用意するということは、カラーパレット、コンポーネント、アイコン、画像アセットを2つのテーマ分メンテナンスし続けることを意味します。

新規施策や機能追加のたびに「ライトとダークの両方で破綻していないか」をレビューする工数が恒常的に発生します。
専任のUIデザイナーやデザインシステム管理者がいない小規模チームでは、無理にダークモードを導入するよりも、ライトモードの使い勝手を磨き込む方にリソースを集中させる方が結果的に良いプロダクトになります。

2. ダークモードは本当に目に優しい？知っておくべきメリット・デメリット

チーム内でダークモードの導入を検討する際は、感覚的な好悪ではなく、客観的なメリットとデメリットを共通認識として持っておくことが重要です。
「ダークモードは目に優しい」というイメージが広く浸透していますが、視覚人間工学や眼科学の観点からは「暗い環境での眩しさを抑える点では目に優しいものの、明るい場所や長文読解ではかえって目が疲れやすくなる」というのが客観的な事実です。

暗い背景に白い文字を表示すると、周囲の光を取り込もうとして瞳孔が開き気味になり、光の屈折で文字の輪郭が滲んで見える「ハレーション現象」が起こります。特に乱視傾向のあるユーザーの場合、白文字がぼやけて焦点が合いにくくなり、長時間のテキスト閲覧では眼精疲労に繋がりやすくなります。
海外の人間工学研究やNielsen Norman Group（NN/g）の調査レポートでも、白背景に黒文字（ポジティブ表示）の方が文字の誤読が少なく読解速度が速いことが実証されています（参考：Dark Mode vs. Light Mode: Which Is Better? – Nielsen Norman Group）。

そのため、ダークモードを導入する際は「すべてのユーザーにとって目に優しい万能のモードではない」という前提を理解した上で、メリットとデメリットを天秤にかける必要があります。

それぞれのメリットとデメリットを対比して整理しました。

※バッテリーの節電効果についても、パーデュー大学（Purdue University）の実測研究において、液晶（LCD）では効果がなく、有機EL（OLED）端末でも画面輝度を高めに設定している環境で約39〜47%の節電効果が確認される一方、通常の明るさでは3〜9%程度の差にとどまることが報告されています（参考：Dark mode may not save your phone’s battery life as much as you think, but there are a few silver linings – Purdue University ECE）。

このように、ダークモードは万能の正解ではなく、「暗い環境で特定の作業に集中する」という目的に特化したモードです。
屋外や明るい照明下ではかえって視認性が落ちることもあるため、利用環境に応じた使い分けを前提として捉えておく必要があります。

3. 「読みにくい・平坦」を防ぐ！ダークモード配色の4大設計ルール

ダークモードの導入を決めた後、多くのデザイナーがつまずくのが「配色の設計」です。
単に白を黒に、黒を白に機械的反転させただけでは、文字がギラついて目がチカチカしたり、カードの重なりが見えなくなって画面全体が真っ平らに沈んでしまいます。

洗練された視認性の高いダークUIを組むために、現場で役立つ4つの配色ルールをご紹介します。
※本セクションで紹介するカラーコードや不透明度の数値は、Google Material Design（Dark themeガイドライン）をベースにした代表的な参考値（ベースラインの一例）です。自社プロダクトのブランドカラーや世界観に合わせて柔軟に調整してください。

ルール①：ベース背景は純黒（#000000）を避け「ダークグレー（#121212〜#181818）」を敷く

画面の一番底に敷くベース背景には、純黒（#000000）ではなく、ごくわずかに明度を持たせたダークグレー（#121212 や #181818 など）を敷くのが実務的なアプローチです。
純黒を敷いてしまうと、その上にある文字とのコントラスト比が最大値（21:1）に達してしまい、白文字の周りが発光して見えるハレーション（光背現象）を引き起こしやすくなります。

さらに、背景を真っ黒に塗りつぶすと、より深い影（ドロップシャドウ）を落とすための「暗さの余白」が消滅してしまいます。
ベースに一段淡いグレーを敷いておくことで、奥まった窪みやシャドウを表現する余地を残すことができます。

ルール②：影の代わりに「サーフェス明度（Elevation）」と「極細半透明ボーダー」で階層化する

ライトモードでは、カードやモーダルなどの浮遊感を「ドロップシャドウ（黒い影）」で表現するのが一般的でした。
しかし暗い背景の上では、黒い影を落としても背景と同化してしまい、要素の前後関係がまったく見えなくなります。

ダークモードでは、影の代わりに「手前にある要素ほど背景色を段階的に明るくする（Elevation Surfaces）」というルールで奥行きを作ります。
物理的な光源が上部にある空間では、手前（高い位置）にある板ほど光を反射して明るく見えるという知覚現象を模倣した手法です。

• Base（最下層背景）: #121212（参考値）
• Surface Level 1（カード・リスト面）: #1E1E1E（参考値）
• Surface Level 2（ドロップダウンメニュー）: #252525（参考値）
• Surface Level 3（モーダルダイアログ）: #2C2C2C（参考値）

さらに、カードの周囲に rgba(255, 255, 255, 0.08) 程度の「ごく薄い1pxの半透明ボーダー」を添えると、明度差だけに頼らず輪郭がキリッと引き締まり、視認性が大幅に向上します。

ルール③：テキスト色は純白（#FFFFFF）を避け、不透明度で階層化する

背景をダークグレーにしたとしても、テキストに純白（#FFFFFF）を100%で当ててしまうと、依然としてコントラストが強すぎて眼精疲労の原因になります。
GoogleのMaterial Designでも推奨されている通り、テキスト色は固定のグレーではなく、白の「不透明度（Opacity / Alpha）」を使って階層化するのが実務的です。

• High Emphasis（見出し・主要本文）: rgba(255, 255, 255, 0.87)（87%）
• Medium Emphasis（補足テキスト・ラベル）: rgba(255, 255, 255, 0.60)（60%）
• Disabled（非活性・プレースホルダー）: rgba(255, 255, 255, 0.38)（38%）

不透明度で色を定義しておくことで、背面のサーフェスが一段明るいカードになっても、テキストが自然に背景色と馴染み、コントラスト比のバランスが自動で保たれます（固定のグレーを指定してしまうと、背景の明度変化によって文字のコントラストがブレてしまいます）。

ルール④：アクセントカラーの彩度を落とし、暗闇でのギラつきを抑える

ライトモードで使用していた鮮やかな青や緑（プライマリカラー）をそのままダークモードに持ってくると、黒背景の上でネオンサインのように強く浮き上がって見えます。
暗い背景の上では、人間の目は色をより鮮やかに知覚する傾向があるためです。

ダークモード用のアクセントカラーは、ライトモードのカラーから「彩度（Saturation）を10〜20%落とし、明度（Lightness）をわずかに引き上げる」のが基本です。
例えばライトモードで #2563EB（鮮快なブルー）を使っている場合、ダークモードでは #60A5FA（少し淡く明るいブルー）を指定することで、眩しさを抑えつつ十分なアクセント効果を発揮できます。

アクセントカラーや色の濁りを防ぐ知覚色空間の調整については、グラデーションの配色ルールを解説した以下の記事でも詳しく紹介しています。

グラデーションカラーがダサい原因は？Figmaで濁らない配色ルール【2026】

色相環のデッドゾーンを回避する3つの中間色ルールや、知覚色空間OKLCHを活用して濁らないグラデーションを作る方法を解説します。

4. Figma Variablesで構築する「破綻しない2層変数（トークン）設計」

配色のルールが定まったら、それをFigma上でどう実装・管理していくかが次のステップです。
スタイル（Styles）を複製して「Button-Dark」のように別コンポーネントを量産する手法は、修正時の手戻りが多すぎて実務では耐えられません。

FigmaのVariables（変数）機能とMode（モード）を活用すれば、ひとつのコンポーネントのまま、ワンクリックでライトとダークを切り替えられる破綻しない基盤が作れます。

PrimitiveとSemanticのシンプルな2層トークン構造

変数設計で最も重要なのは、「生の色（Primitive）」と「UI上の役割（Semantic）」をしっかりと分離することです。

• Tier 1：Primitiveトークン（生の値）
  カラーパレットそのものを保持する階層です。画面上の意味を持たせず、色の名前と濃淡スケールで登録します。
  例：_primitive/neutral/50（#F8FAFC）、_primitive/neutral/900（#0F172A）
• Tier 2：Semanticトークン（役割と意味）
  UIコンポーネントに実際に適用する階層です。Primitiveの値を参照（エイリアス）して登録します。
  例：surface/default、surface/card、text/primary、border/subtle

UIパーツには必ずSemanticトークンを割り当てます。
デザイナーが直接Primitiveを選べないよう、Primitiveコレクションには先頭に `_`（アンダースコア）をつけてライブラリ非公開にしておくのが運用のコツです。

Variablesの「Mode」機能を使った設定手順

FigmaでLightとDarkの2つのモードを設定する手順は非常にシンプルです。

1. コレクションにMode列を追加:
   変数パネルでSemanticコレクションを開き、右上の「+」ボタンからモード列を2つ作成します（名前を「Light」「Dark」に設定）。
2. モードごとの参照先（エイリアス）を指定:
   例えば surface/default という変数に対し、Light列には `_primitive/neutral/white`、Dark列には `_primitive/neutral/900` をそれぞれ紐付けます。
3. テキストやボーダーも同様に対応付け:
   text/primary に対して、Light列には濃いグレー（`_primitive/neutral/900`）、Dark列には白の不透明度87%（`_primitive/white/87`）を割り当てます。
4. フレーム側でModeを切り替える:
   デザインフレームを選択し、右サイドパネルの「Layer」セクションにある変数アイコンから「Change variable mode ➔ Dark」を選択します。

この設定を一度組んでおけば、フレーム内の全コンポーネントが一瞬でダークモード配色へ適応されます。
画面を二重に作成する必要がなくなるため、レイアウト修正や文言変更の工数が半減します。

Variablesの命名規則やトークン設計の基礎をより体系的に学びたい方は、以下の完全ガイドもぜひ参考にしてみてください。

Figma Variables（変数）の使い方完全ガイド｜破綻しない命名規則とトークン設計【2026】

生の値（Primitive）と役割（Semantic）の2層構造でスモールスタートし、Light/Darkモード切り替えやスコープ制限を破綻なく運用する実践ルールを解説します。

5. 実務がスムーズに進む！ダークモード設計におすすめのFigmaプラグイン4選

ダークモードの設計を手動ですべて行おうとすると、コントラスト比の計算や色の反転作業に多くの時間が取られてしまいます。
実務で役立つ便利なFigmaプラグインを4つ厳選しました。目的に応じて使い分けてみてください。

① Appearance

Appearance | Figma Community

スタイル名の命名規則をもとに、選択した要素のライト／ダークテーマを瞬時に切り替えるFigmaプラグイン。

カラースタイルの命名規則（名前の中に [day] と [night] を含めるルール）をもとに、選択したUIパーツの配色を一括でライト／ダークへ反転・切り替えてくれるプラグインです。
コンポーネントを複製して別々に作ることなく、既存のスタイルを保ったまま配色の見え方を瞬時にスイッチして検証したいときに役立ちます。

② Dark Mode Magic

Dark Mode Magic | Figma Community

ライトテーマのフレームを選択するだけで、ダークモード用の配色を自動計算・生成して瞬時に適用してくれるFigmaプラグイン。

選択したフレームの色構成を自動解析し、明暗を反転させたダークモード画面を手早く自動生成してくれるプラグインです。
背景色、テキスト色、ボーダーの明度を推測して変換してくれます。
完全な完成形には手動の微調整が必要ですが、「とりあえずダークモードにしたときの全体的な見え方を瞬時に確認したい」という初期ブレストの段階で非常に作業時間を短縮できます。

③ Stark（コントラスト・アクセシビリティチェック）

Stark - Contrast & Accessibility AI Checker | Figma Community

コントラスト比の自動判定や色覚シミュレーションなど、アクセシビリティ基準のチェックを効率化するFigmaプラグイン。

ダークモード設計において最も神経を使う「WCAGコントラスト基準（4.5:1以上）」をリアルタイムで検査できるアクセシビリティツールです。
レイヤーを選択するだけで、背景色と文字色のコントラスト比が基準を満たしているかを即座に判定してくれます。
「見た目は格好いいけれど、実は文字の視認性が不足していた」という手戻りをデザイン段階で確実に防止できます。

④ Tokens Studio for Figma

Tokens Studio for Figma | Figma Community

Figma Variablesを超える高度なデザイントークン設計と、JSON形式によるGitHubリポジトリ直接同期を実現するプラグイン。

Figma Variablesよりもさらに高度なトークン管理を行いたい場合や、開発チームとのJSON連携を本格化させたいプロジェクトで重宝するプラグインです。
Light/Darkテーマのトークン構造をJSON形式でGitHubリポジトリと直接同期できるため、エンジニアの実装コードとデザインデータを完全に一致させることができます。
大規模なデザインシステムを運用している中〜大規模プロダクトに向いています。

6. まとめ：ダークモードは「目的」ではなく「ユーザーへの配慮」

ダークモードは、単に画面を黒くして見た目の印象を変えるための装飾ではありません。
暗い環境で作業するユーザーの目の疲労を和らげ、コンテンツへの集中を支えるための「機能的な選択肢」です。

• 導入基準を見極める: 夜間利用が多いか、写真・コード中心かなど、利用シーンに合致しているかを冷静に判断する。
• 配色のルールを守る: 純黒を避け、サーフェス明度で階層を作り、テキストは不透明度でコントラストを緩和する。
• Variablesとプラグインで仕組み化する: PrimitiveとSemanticの2層構造を組み、プラグインで検証・変換工数を削減する。

そして最も重要なのは、「ユーザーに選択の自由を残すこと」です。
OSの設定に合わせて自動適用するだけでなく、画面内のトグルスイッチなどでユーザー自身がライトとダークをいつでも手動で切り替えられるUIを用意しておくことが、最も親切で誠実なUX設計につながります。

まずは自社のサービスでダークモードが本当に求められているかを振り返り、必要な場面で破綻のない美しいダークUIを組み立ててみてください。

ダークモードのVariables運用とあわせて、ボタンや入力フォームの肥大化を防ぐコンポーネント設計術については、以下の記事で詳しく解説しています。

Figmaコンポーネントプロパティの使い方｜バリアント増えすぎを防ぐ設計術

Boolean・Text・Instance Swapの3大プロパティを活用し、増えすぎたバリアントを最小限に抑えるコンポーネント設計術とスロット運用のコツを解説します。

終わりに

最後までお読みいただき、ありがとうございました！
それでは、良いデザインライフを！

The post ダークモードは必要？3つの導入基準とFigma変数設計・便利プラグイン first appeared on デザペディア.

エンジニアの方にデザインデータを引き渡した直後、Slackで「ここの余白は16pxと24pxのどちらが意図した数値ですか？」「この色は既存のどのトークンを使えばいいですか？」と何往復も確認のやり取りが続いた経験はないでしょうか。
お互いに悪気はないものの、デザインカンプから意図を正確に読み取ってもらうのは思いのほか難しく、確認作業に多くの時間を取られてしまいがちです。

こうしたデザイナーとエンジニアの間にある引き渡しのすれ違いや確認コストを減らすために作られたのが、Figmaの「Dev Mode（開発モード）」です。
今回は、Dev Modeで何ができて何ができないのか、最新の料金体系や無料プラン（Viewer）との機能境界、そして現場で手戻りをゼロにするための運用ルールを整理しました。

1. Figma Dev Mode（開発モード）とは？通常エディタとの決定的な違い

Figmaの画面右上にあるスイッチ（またはショートカット Shift + D）を切り替えるだけで、開発者専用の表示に切り替わるワークスペースがDev Modeです。
従来のFigmaは主に画面を制作するためのエディタでしたが、Dev Modeはエンジニアがデザインを解析してコードへ変換するための「インスペクター（検証画面）」として機能します。

通常のデザイン画面では、誤ってレイヤーをドラッグして位置をズラしてしまったり、フォント設定を変更してしまうリスクが常にありました。
Dev Modeではデザイン編集権限が安全にロックされるため、エンジニアはレイアウトを崩す心配をすることなく、安心して必要な数値やアセットを抽出できます。

デザイナーとエンジニアで画面の見え方がどう変わるか

通常のデザインエディタでは、右パネルに配置の座標やフォントの詳細パネルが並びます。
一方のDev Modeに切り替えると、右パネルが「Box Model（ボックスモデル）」や「CSS/Swift/Composeコード」の表示へと切り替わります。

要素にカーソルを合わせるだけで、PaddingやGapの余白、適用されているデザイントークン（Variables）の名前がエンジニア向けのシンタックスで明示されます。
デザイナーが意図した構造がそのまま開発言語のフォーマットで可視化されるため、推測に頼った実装がなくなります。

なぜ引き渡し（Handoff）の手戻りが大幅に減るのか

従来のWeb制作現場では、余白やフォントサイズを細かく書き込んだ「指示書」を別途作成したり、口頭で変更点を伝える作業が発生していました。
Dev Modeを活用すれば、デザインデータ上で直接コードや数値を参照できるため、別途仕様書を用意する必要がなくなります。

仕様書を作成・更新する二重管理の手間がなくなり、デザイナーは本来のUI設計に集中できるようになります。
またエンジニア側も、Slackで都度質問を投げる必要がなくなるため、お互いの集中力を途切れさせずに開発サイクルを回せるようになります。

2. Dev Modeの最新料金プランと無料プラン（Viewer）のできること比較

Dev Modeを検討する上で、チームが最も慎重になるのが「料金体系」と「無料プランでどこまでできるのか」という点です。
かつてFigmaに搭載されていた無料のInspect機能とは異なり、現在の本格的なDev Modeは有料シート（DevシートまたはFullシート）が必須となっています。

どのメンバーに有料シートを付与し、どのメンバーを無料の閲覧シート（Viewer）にとどめるべきかを判断するために、プランごとの権限差を把握しておきましょう。

無料のViewer（閲覧シート）でできること・制限されること

無料のViewer（閲覧のみの権限）であっても、Figmaファイルを開いてデザインを閲覧すること自体は可能です。
また、デザイン上のテキストをコピーしたり、選択した要素の単純なCSSプロパティ（Hexコードや幅・高さなど）を確認する最低限のインスペクト操作は引き続き行えます。

ただし、後述する差分比較（Diff）、Ready for dev専用ビュー、VS Code連携、Dev Mode専用プラグイン、高度なCode Syntaxの利用にはアクセスできません。
あくまで「デザインの確認と単純なスタイルの参照」に限られるため、本格的なフロントエンド実装を日常的に行うエンジニアには有料シートの導入が現実的な選択肢となります。

有料「Devシート」の料金体系

Figmaでは、デザイン編集を行う「Fullエディターシート」よりも安価な、開発者専用の「Devシート」が用意されています。
プロジェクトのプラン形態（Professional / Organization / Enterprise）に応じて、以下の料金設定となっています。

※料金は為替やFigmaの改定により変動する可能性があるため、導入時は必ずFigma公式の料金ページをご確認ください。

日々の実装を担当するフロントエンドエンジニアには「Devシート」を割り当て、仕様確認のみを行うディレクターやQA担当者は「無料Viewer」で運用するのが、コストパフォーマンスを高めるおすすめの構成です。

3. 実務でエンジニアを助けるDev Modeの4大コア機能

Dev Modeが現場で高く評価されている理由は、単にCSSが表示されるからではありません。
日々の開発ワークフローに深く入り込み、手作業の確認工数を大幅に減らす4つのコア機能が備わっているからです。

① コード生成とCode Syntax（CSS / SwiftUI / Compose）

要素を選択するだけで、Web（CSS）、iOS（SwiftUI）、Android（Jetpack Compose）向けのコードスニペットが瞬時に出力されます。
単に生の色コード（#2563EB など）が出力されるのではなく、デザイナーが設定したVariables（変数名）が紐づいて出力される点が実務上の大きな利点です。

さらに、Figmaの「Code Syntax」機能を利用すれば、コードベースで使用している変数名（例: var(--color-surface-brand)）をあらかじめ登録しておくことができます。
エンジニアは頭の中で命名規則を変換する必要がなく、画面に表示されたコードをそのまま実装ファイルへコピー＆ペーストするだけで作業が進みます。

② 変更履歴の差分比較（Compare Changes / Diff）

「デザインを少し修正しました！」と連絡を受けた際、「具体的にどこが変わったのか探すのに時間がかかる」という問題は、開発現場でよく起きていました。
Dev Modeの「Compare changes（変更の比較）」機能を使えば、過去のバージョンとの変更点が視覚的なオーバーレイと差分リストで一目瞭然になります。

余白が4px広がった、テキストのカラーが変わった、新しいアイコンが追加された、といった変更点だけがハイライト表示されます。
修正箇所の見落としによる実装漏れを防ぎ、デザイナー側も変更箇所を文章で細かく説明する負担を大きく減らせます。

③ VS Code拡張機能（Figma for VS Code）によるエディタ統合

Figmaを開き、コードエディタを開き、またFigmaに戻るという画面の往復は、開発中の作業テンポを崩す原因になります。
公式提供されているVS Code拡張機能を利用すれば、VS Codeエディタの画面内で直接Figmaのレイアウトやプロパティを確認できます。

VS Code連携 – Figma Learn – ヘルプセンター

FigmaのVS Code連携拡張機能を使用すると、開発環境から出ることなくVS Code内で直接デザインの閲覧やプロパティのインスペクト、差分確認が可能です。

コードを記述しながら、同じウィンドウのサイドバーでデザインのPaddingやVariablesをインスペクトできます。
さらにデザイン上のコメントにもVS Codeから直接返信できるため、画面を行き来する手間を省き、集中しやすい開発環境が整います。

④ 開発準備完了（Ready for dev）ステータスとフォーカス表示

作業中のデザインファイルには、レビュー中の未完成な画面と、すでに実装に着手してよい画面が混在しがちです。
デザイナーが実装対象のフレームに「Ready for dev（開発準備完了）」ステータスを付与することで、エンジニアはその画面だけに集中できるようになります。

Dev Modeを開くと、Ready for devが付いたフレームだけがサイドバーに一覧化され、作業中のカンプは自動的に除外されます。
「作りかけの画面を誤って実装してしまった」という実装ミスを、仕組みで未然に防ぐことができます。

4. デザイナー自身がDev Modeを活用するセルフチェック手法

Dev Modeはエンジニアだけのものではなく、デザイナーにとっても「自分のデータが実装に耐えうる構造になっているか」をセルフチェックするための優れた検証ツールです。
納品前に自分自身でDev Modeを開いて確認する習慣をつけることで、データ品質が格段に向上します。

実装目線（Box Model）でオートレイアウトの破綻を検知する

デザイン画面では綺麗に見えていても、Dev ModeのBox Modelを開いてみると、Paddingが不均一だったり不要なネストが重なっていることに気づくケースがよくあります。
エンジニアが見るのと同じBox Model（外側のMargin、内側のPadding、要素幅）を確認することで、実装時にレイアウト崩れを引き起こす原因を事前に発見できます。

絶対配置（Absolute position）が無駄に残っていないか、テキストの折り返し設定が適切かをDev Mode上で確認し、事前に修正しておく配慮によって、エンジニアへの引き渡しがぐっとスムーズになります。

アノテーション（注記）と計測機能で実装仕様を正しく伝える

Dev Modeでは、画面上に「アノテーション（Annotations）」として実装時の注意事項や動的な振る舞いのメモを直接ピン留めできます。
例えば「画面スクロール時はこのヘッダーを上部に固定する」「最大文字数は30文字で超過時は三点リーダー」といった仕様を、デザイン要素に直接紐づけて記録できます。

別ドキュメントに仕様を逃がすのではなく、該当のUIパーツ自体に仕様が直接紐づいている状態を作ることで、確認漏れを確実に防ぐことができます。

5. AIコーディング・MCP連携におけるDev Modeの価値【2026】

2026年のフロントエンド開発において、CursorやClaude CodeなどのAIコーディングエージェントを活用した開発スタイルがデファクトスタンダードになりつつあります。
このAI駆動開発の文脈においても、Figma Dev Modeと構造化されたデザインデータの重要性がさらに高まっています。

Cursor / Claude Codeへの構造化データ引き渡し

AIエージェントにフロントエンドの実装を依頼する際、単なるスクリーンショット画像を渡すだけでは、正確な余白やトークン設計を反映したコードを出力させることは困難です。
FigmaのMCP（Model Context Protocol）サーバーやDev Mode連携を通じて、デザインのツリー構造やVariablesのメタデータをJSONとして直接AIに渡すことで、コード生成の精度が大きく高まります。

AIは「ここは単なる24pxの余白ではなく、space/layout/md という共通ルールである」と文脈を解釈し、デザインシステムの思想を反映したメンテナンス性の高いコードを的確に出力してくれます。

「AI Ready」なデザインデータを作るための最低条件

どれほどAIやDev Modeが進化しても、元となるFigmaデータが適当に作られていては、AIも乱雑なコードしか生成できません。
現場で「AI Ready」な制作環境を確立するためには、以下の3つの基本設計を徹底しておく必要があります。

• オートレイアウトの完全適用: すべてのコンポーネントでPaddingとGapを構造化し、絶対配置の乱用を避ける
• Variables（変数）の徹底: カラーや余白の数値を直書きせず、セマンティックなトークンとして紐づける
• 適切なレイヤー命名規則: 何の役割を持つUIなのかがAIに伝わる英語のケバブケースや命名ルールで整頓する

デザイナーが論理的にデータを整頓しておくことこそが、AI時代における開発チーム全体の生産性を最大化する土台となります。

6. Figma Dev Modeに関するよくある質問（FAQ）

Figma Dev Modeの導入や運用に際して、現場でよく耳にする疑問とその回答をまとめました。

• Q. 無料プラン（Starter）でもDev Modeは使えますか？
  現在の仕様では、本格的なDev Mode機能の利用には有料プラン（Professional以上）でのDevシートまたはFullシートの契約が必要です。無料のViewer権限では、デザインの閲覧や単純なCSSプロパティの参照といった最低限のインスペクト機能のみに制限されます。
• Q. Dev Modeを導入すればフロントエンドエンジニアは不要になりますか？
  不要にはなりません。Dev Modeが生成するのはあくまで静的なスタイルやレイアウト情報です。複雑なビジネスロジックの実装、状態管理、アクセシビリティ対応、パフォーマンス最適化など、エンジニアの専門的な設計スキルは今後も変わらず不可欠です。
• Q. デザイナーもDevシートを別途購入する必要がありますか？
  いいえ、購入する必要はありません。すでに編集権限を持つ「Fullエディターシート」を契約しているデザイナーは、追加料金なしでDev Modeの全機能を利用できます。Devシートは、デザイン編集権限を持たないエンジニア向けにコストを抑えて提供されている専用シートです。

次のステップ：あわせて深掘りしたい知見

Dev Modeを使いこなすためには、大前提となるVariables（変数）やオートレイアウトの構造設計を正しく理解しておくことが欠かせません。

デザインシステムを運用破綻させずに構築するための命名規則やトークン設計のルールは、以下の完全ガイドで詳しく解説しています。

Figma Variables（変数）の使い方完全ガイド｜破綻しない命名規則とトークン設計【2026】

Variablesへの心理的ハードルを下げ、スモールスタートで運用を回すための2層トークン構造（PrimitiveとSemantic）とガバナンス設計ルールを徹底解説。

Dev Modeでのコード出力精度を左右するオートレイアウトの組み方と余白設計については、こちらの記事で体系的に整理しています。

Figmaオートレイアウト完全ガイド！崩れないネストと余白設計

Figmaオートレイアウトの基本と崩れないネスト設計を解説。Padding・Gapの設定からHug・Fill・Fixedの使い分け、メディアカードの組み立て手順まで網羅。

日々の制作でFigmaと組み合わせて愛用しているデザインツールや実務ワークフローについては、以下のまとめ記事も参考にしてみてください。

Figmaコンポーネントプロパティの使い方｜バリアント増えすぎを防ぐ設計術

Figmaのコンポーネントプロパティの使い方を解説。Variantsとの境界線、Boolean・Text・Instance Swapの3大プロパティ設定、ネスト公開や注目のスロット（Slots）活用までバリアント増えすぎを防ぐ実務設計をまとめました。

まとめ：Dev Modeを活かす鍵は「データの構造化」にある

Figma Dev Modeは、デザインと開発の引き渡しを効率化し、チーム全体の作業スピードを高める便利な機能です。
しかしその出力クオリティは、元となるデザインデータの構造化レベルに大きく左右されます。

• 無料Viewerと有料Devシートの権限差を理解し、チームに最適なライセンスを配置する
• Code SyntaxとVariablesを活用し、デザインとコードの命名規則を1対1で同期させる
• Ready for devと差分比較（Diff）を活用し、作業途中の画面を誤って実装するミスを防ぐ
• オートレイアウトを徹底し、AI駆動開発（Cursor/Claude Code）に耐えうるデータを渡す

ツールをただ導入するだけでなく、デザイナー側でも実装を意識したデータ作りを心がけることで、手戻りのないスムーズな協業が実現できます。
まずは次のデザイン引き渡しから、オートレイアウトのセルフチェックやReady for devステータスを試してみてください。
日々のちょっとした運用の工夫で、開発チームとのやり取りがぐっとスムーズになります。

The post Figma Dev Mode（開発モード）の使い方と料金体系｜できること・できないことと実装連携【2026】 first appeared on デザペディア.

先にこの記事の結論をお伝えすると、2026年のUI/UXデザイナー市場はAIの台頭により「作業型」と「意思決定型」の年収二極化が急速に進んでいます。
生き残り、市場価値を上げるためには、単なる画面制作から脱却し、「ビジネス視点の獲得」と「AIを使いこなしたデザインの判断力（審美眼）」を身につけることが不可欠です。

最近、同職種のデザイナー仲間と話していても、「ジュニアデザイナーの採用枠が本当に少なくなった」という話題がよく出ます。
企業側からすれば、基本的なUIレイアウトであればAIに課金した方がはるかに安価で利益が出るため、わざわざ未経験のジュニアを雇うメリットが薄れているという厳しい現実があるそうです。

私自身もこうした話を聞いて、ただ綺麗に画面を作るだけの仕事は価値を失っていくのだなと、強い危機感を覚えています。
今回は、2026年現在の最新の市場調査データをもとに、AI時代におけるUI/UXデザイナーの具体的な生存戦略や年収動向について深掘りしてみました。

1. 2026年 UI/UXデザイナーの最新年収レンジと「二極化」の現実

2026年現在の労働市場において、UI/UXデザイナーの求人は依然として活発だそうです。
しかし、その実態を調べてみると、デザイナー個人のスキルセットによって「年収の二極化」が非常に顕著になっているとのことです。

以下は、2026年におけるUI/UXデザイナーの経験年数別の最低限求められるスキル範囲と年収レンジの目安です。

求人ボックスの「UIデザイナーの年収・時給」調査データによると、UIデザイナー全体の平均年収は約450〜550万円が最大のボリュームゾーンだそうです。
また、UXデザイナーの年収データでも同様の傾向が見られ、AIツールの進化によって「画面を組み立てるだけの作業」の価値が急速に下がった結果、ジュニア層の年収は伸び悩む傾向にあるとのことです。

一方で、ビジネスの数字を理解し、プロダクト全体の体験設計に関与できるシニア以上のデザイナーは、深刻な人材不足から年収が高騰する傾向が続いています。
つまり、単なる「オペレーター」から「意思決定のパートナー」へとシフトできるかどうかが、市場価値の分かれ道になっているそうです。

2. AI時代の「市場価値」の再定義：自動化される作業と、高まる「審美眼・判断力」

AIの急速な発達によって、デザイナーの仕事内容はその本質から見直されるようになっています。
バナーのレイアウト調整や、基本的なモックアップ作成といった手を動かす作業は、AIにほぼ置き換え可能になってきている、あるいは今後完全に置き換わる見込みだそうです。

しかし、だからこそ「なぜこのUIにするのか」という意図を明確にし、周囲を納得させる思考や戦略の価値がかつてないほど高まっています。
さらに今後は、AIが高速で出力してきた無数のデザイン案から、どれがビジネスやユーザーにとって最適かという「デザインのよしあしを判断する審美眼」が極めて強く求められるとのことです。

これは、かつてシニアデザイナーがジュニアデザイナーにデザインレビュー（評価・指導）を行っていたときの「判断価値」と同じものです。
つまり、今後はジュニアやミドルであっても、シニア級の確固たる判断軸を持てなければ、市場から必要とされなくなっていく未来があるそうです。

非デザイナーのステークホルダーと対話し、プロダクトのデザイン方針を言語化して合意形成するプロセスは、人間にしかできません。
デザインの意図を論理的に翻訳する重要性については、以前公開した下記記事でも詳しく解説しています。

undefined

3. 将来予測：AI時代に生き残るUI/UXデザイナーに共通する3つのキャリアシフト

これから先の市場で生き残り、年収を上げていくためには、従来の「デザイン業務」の枠を飛び越えるキャリアシフトが必要だそうです。
2026年以降の市場動向から予測される、活躍し続けるデザイナーの共通項は以下の3点のアプローチに集約されるとのことです。

① 「デザイン＋α」の職能を拡大する（PdM視点の獲得）

デザインの技術だけでなく、ビジネスモデルやプロダクトマネジメント（PdM）の視点を積極的に獲得することが大切だそうです。
事業目標であるKPIやコンバージョン率といった数値を理解し、「事業成長に繋がるユーザー体験」を設計できるデザイナーは極めて強い市場価値を持つとのことです。

この「体験とビジネスの融和」については、下記記事で詳細に解説していますので、併せて参考にしてください。

undefined

② AIを「思考の壁打ち相手」にし、プロトタイピングを高速化する

AIツールを敵視するのではなく、強力なアシスタントとして自分のワークフローに組み込むことが重要だそうです。
AIを活用して大枠のレイアウトを素早く作り、人間は「本当に解決すべきユーザーのペインポイント」の深掘りに時間を割き、検証する流れが主流になるとのことです。

作業時間を圧倒的に短縮することで、ユーザーインタビューや行動データの分析など、より上流の仮説検証にエネルギーを注ぐことができます。

③ 定量的な実績で「デザインの貢献度」を証明する

「使いやすくなった」という感覚的なアピールだけでなく、自分のデザインが事業数値にいかに貢献したかを定量的なデータで示せるようにします。
例えば、「UI設計の見直しによって、ユーザー操作への反応速度を示すINPを15%改善し、コンバージョン率を5%向上させた」といった具体的な実績を示すことが極めて有効だそうです。

ビジネスの言葉である「数字」で語れるようになることが、経営陣やPdMから信頼を勝ち取り、年収アップの直接的な交渉材料になるとのことです。

4. AIを使いこなして「判断力」を高める第一歩

私自身も、現在ではAIツールを毎日のデザインワークにパートナーとして活用しています。
具体的には、以下のような形でAIを実務のワークフローに組み込んでいます。

• ワイヤーフレームのバリエーション生成：新規案件の検討時に、AIに複数案を出させて「アイデアの幅を広げるためのたたき台」として活用する。
• デザインデータの機械的チェック：開発へ連携する最終データのアノテーション（注釈）漏れなどがないか、MCPサーバー経由でAIに自動チェックさせる。
• 仮想のシニアとしてのデザインレビュー：AIが出力した複数案に対して、「どれが最も使いやすいか」「なぜこの案が良いのか」を比較検討し、よしあしを判断する。

AIにレイアウト出しや不備の検出を任せることで、人間は「デザインの意図を考え、言語化する」ことだけに集中できます。
あえて「AIが作ったデザインをレビューする」というシニアデザイナーの役割を、自分の頭の中でロールプレイングしているのです。

この訓練を繰り返すことで、ただ手を動かすだけでは身につかない「デザインの判断軸（審美眼）」が少しずつ鍛えられている感覚があります。
そして、その判断に基づいた客観的なロジックを、クライアントに対しても自信を持って提案できるようになりました。

AIに作業を任せることは、決してデザイナーの敗北ではないはずです。
むしろ、作業から解放され、「シニアレベルの判断力と体験設計」に集中するための大きなチャンスなのだと実感しています。

5. 終わりに

AIが瞬時に綺麗なデザインを作成できるようになった現代は、ある意味でデザイナーにとって「本当に面白い仕事」に集中できる素晴らしい時代だと言えます。
画面の美しさにこだわるクリエイティビティを持ちつつ、それをビジネスの成果や体験のロジックに結びつけられる能力を磨いていきましょう。

今回の記事で押さえておきたい重要ポイントは以下の通りです。

それでは、良いデザインライフを！

The post 2026年 UI/UXデザイナー市場調査レポート：AI時代の市場価値、年収動向、および将来予測 first appeared on デザペディア.

「PCで綺麗に2行に収まっていたキャッチコピーが、スマホで見ると1文字だけ改行されて崩れてしまい、不格好になってしまった」
「スマホでタップしようとしたら、隣のボタンと近すぎて誤タップしてしまい、毎回イライラする」

デザイナーやコーダーの皆さんなら、レスポンシブ対応の過程でこうしたヒヤッとする瞬間に一度は遭遇したことがあるのではないでしょうか。
画面サイズの異なる多様なデバイスに1つのレイアウトで対応するのは、思っている以上に骨が折れる作業ですよね。

Webデザインにおけるレスポンシブ設計では、あらゆる画面サイズに力技で対応しようと複雑なメディアクエリを重ねるよりも、そもそも「壊れない（破綻しない）シンプルな構造」をあらかじめ仕込んでおくことのほうが、結果的にデザインの品質と保守性を長く保つ秘訣になります。

1. なぜレスポンシブは「崩れやすい」のか？現場で起きる崩れの正体

私たちが日々Webサイトを構築する中で、デバイス間のレイアウト破綻はなぜ起きてしまうのでしょうか。

最も大きな要因は、デスクトップ（PC）用のレイアウトを基準とし、それをメディアクエリ（@media）によって縮小・調整していくという「デスクトップファースト」の考え方にあります。
PC版に配置された複雑な要素や装飾を、スマートフォンの狭い画面に収めるために、不要なものを非表示（display: none）にしたり、無理やり文字や画像を縮小して詰め込むといったアプローチは、コードを複雑化させるだけでなく、特定の画面幅で予期せぬ崩れを引き起こしやすくなります。

現代のWebアクセス、特にBtoC向けのサービスやLP（ランディングページ）、ECサイトにおいては、アクセスの80%以上がスマートフォンから行われています。
こうしたモバイル偏重の環境下では、Googleの「モバイルファーストインデックス（MFI）」への完全移行もあり、スマートフォンでの表示がすべての基準となっています。

モバイルでのユーザー体験（UX）を損なうようなレイアウトの不具合（想定外の横スクロール、タップしにくいほど小さなボタン、画像読み込み時に画面が動く現象など）は、離脱率の上昇を招き、SEO評価にも直接的な悪影響を及ぼします。

したがって、これからのレスポンシブ設計では、あらかじめ要素自体に「自己調整」のルールを持たせ、どのような画面幅になっても崩れにくい頑丈な骨組みを構築することが不可欠です。

2. CSSで防ぐ！レイアウト破綻を回避する4つのコーディング技術

CSSの実装段階で発生しやすいレイアウトのバグは、いくつかのモダンなCSSプロパティや記述ルールを徹底することで、スマートに回避できます。

100vwのスクロールバー罠と width: 100%

画面幅いっぱいに要素を広げたいとき、width: 100vw; と指定することがよくあります。
しかし、WindowsなどのPCブラウザでスクロールバーが表示されている場合、100vw は「スクロールバーを含んだ画面幅」として計算されてしまいます。
その結果、画面幅を超えてしまい、意図しない横スクロールが発生するという問題が起きます。

この現象を根本から防ぐには、width: 100vw; ではなく、親要素の幅を基準とする width: 100%; を使用するのが基本です。
さらに、パディングや枠線の幅によって要素が親要素からはみ出るのを防ぐため、あらかじめすべての要素に box-sizing: border-box; を指定しておくことが、安全なレイアウト計算の前提となります。

画像のアスペクト比崩れとCLS（累積レイアウトシフト）の防止

画像をレスポンシブ対応にする際、max-width: 100%; height: auto; とだけ指定していると、画像が読み込まれる前にブラウザが画像の高さを計算できません。
そのため、画像が読み込まれた瞬間にコンテンツが下へとガクッと押し下げられる現象（CLS: Cumulative Layout Shift）が発生します。
これはユーザーの誤タップを引き起こし、Webパフォーマンス（Core Web Vitals）の測定においても低い評価を受ける要因になります。

これを防ぐためには、HTML側で明示的に width と height 属性を記述するか、CSSの aspect-ratio プロパティを活用して、あらかじめ画像が表示される予定のスペース（アスペクト比）をブラウザに確保させることが重要です。

img {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

この数行の記述により、画像が読み込まれる前でも常に正しいスペースが描画エリアとして確保され、不快なコンテンツのズレを完全に防ぐことができます。

動的ビューポート dvh によるアドレスバー問題の解決

スマートフォンでの閲覧時、画面の天地いっぱいにファーストビューを表示させるために height: 100vh; を使うと、iOS SafariやChromeのアドレスバーが伸縮するたびに、ボタンやコンテンツが隠れてタップできなくなってしまう問題が長くエンジニアを悩ませてきました。

この問題は、最新のCSS仕様である動的ビューポート単位 dvh（Dynamic Viewport Height）を使用することでスマートに解決できます。

• svh（Small Viewport Height）：アドレスバーが展開した、最も可視領域が狭い状態を基準とする
• lvh（Large Viewport Height）：アドレスバーが引っ込んだ、最も可視領域が広い状態を基準とする
• dvh（Dynamic Viewport Height）：アドレスバーの伸縮に合わせて、高さを動的に再計算する

全画面のファーストビューを作りたいときは、height: 100dvh; を指定するだけで、どのようなスマホブラウザでも画面にぴったりと収まる堅牢なレイアウトを実現できます。

メディアクエリ要らず！ clamp() 関数での流動的な文字サイズ

ブレイクポイントごとにメディアクエリを書いてフォントサイズを細かく切り替えるアプローチは、中途半端な画面幅（例えばタブレットとスマホの中間など）で文字のバランスが崩れる原因になります。

そこで役立つのが clamp() 関数です。
clamp(最小値, 推奨値, 最大値) の形で値を指定することで、指定した範囲内で文字サイズや余白が画面幅に応じて滑らかに流動変化する（Fluid Typography）ようになります。

p {
  font-size: clamp(1rem, 0.667rem + 1.667vw, 2rem);
}

この指定を行っておけば、画面幅が小さいときは最小の 1rem を保ち、画面が広がるにつれて推奨値に従って段階的に拡大し、一定の画面幅を超えたら最大の 2rem でストップします。
メディアクエリを大量に書く手間が省け、あらゆるビューポート幅に対して文字が美しく収まります。

3. コンテナクエリで実現する「自己完結型」のコンポーネント設計

これまでのレスポンシブ設計は、ブラウザのウィンドウ全体の幅（ビューポート）を基準にレイアウトを制御してきました。
しかし、コンポーネント指向の開発が進む現代においては、「画面幅」ではなく「そのコンポーネントが配置されている親要素の幅」を基準にスタイルを適応させることが求められます。

同じカード型のUIであっても、それが広いメインエリアに置かれるか、あるいは狭いサイドバーに置かれるかによって、自動的に表示形式（縦並びか横並びか）を切り替えられるのが理想です。
これを実現するのが「コンテナクエリ（Container Queries）」です。

実装は、まず親要素となるコンテナに container-type を指定し、ブラウザに対してこの要素の幅を基準にするよう宣言します。

.card-container {
  container-type: inline-size; /* 横幅を基準とする */
}

そして、その子要素であるカードコンポーネントに対して、メディアクエリ（@media）の代わりに @container を使用してスタイルを記述します。

/* 通常は縦並び */
.card {
  display: block;
}

/* 親要素の幅が500px以上になったら自動で横並びに切り替え */
@container (min-width: 500px) {
  .card {
    display: flex;
  }
}

このアプローチにより、コンポーネント自身が「自分が今どれくらい広い場所に置かれているか」を検知し、自ら最適なレイアウトへと自己調整するようになります。
配置する場所ごとの調整コードが不要になるため、レイアウト破綻を未然に防ぐ上で最も洗練された設計手法の1つです。

また、コンテナの幅を基準とする相対単位 cqw（Container Query Width）と、前述の clamp() 関数を組み合わせることで、親要素の広さに完全に連動する自己完結型の流動タイポグラフィ（例: font-size: clamp(1rem, 5cqw, 1.8rem);）を定義することも可能です。

4. キーワードとしての「スマポンシブ」設計とその特徴

複数デバイスのすべてに対してレイアウトを細かく調整するコストを削減し、最もアクセスの多いスマートフォンでのUXを究極に高めるためのアプローチとして、「スマポンシブ（スマホ特化型レスポンシブ）」という設計手法も知っておくべき選択肢です。

スマポンシブとは、スマートフォンの表示幅（概ね320px〜550px程度）を基準にメインコンテンツの最大幅を物理的に固定し、PCなどの大きなディスプレイで閲覧した際にも、スマートフォンと同様の「1カラム（縦長）のレイアウト」を維持する設計手法です。

すべてのサイトに適用できるものではありませんが、キャンペーンLPやSNSからの直接流入を狙うプロモーションサイト、BtoCのアパレル・コスメサイトなど、スマホ利用者が圧倒的多数を占めるプロジェクトにおいては極めて強力な効果を発揮します。

従来のレスポンシブデザインが「画面の広さに応じて複数カラムへとダイナミックに組み替える」のに対し、スマポンシブは「コンテンツ幅そのものを固定値に縛ることで、レイアウトの破綻を物理的に防ぐ」という割り切った考え方をします。

これにより、PC版の複雑な表示ロジックを組む必要がなくなり、開発コストや保守管理の負荷が劇的に下がります。
PC閲覧時に発生する左右の広い余白（マージン）には、ブランドの世界観を表現する背景ビジュアルや、回遊性を高めるための固定メニュー、あるいはモバイルアプリへの誘導QRコードなどを配置することで、無駄のないUI空間として再定義できます。

このスマポンシブ設計をWordPressで手軽に実現するツールとして、株式会社ベクトルが開発したブロックテーマ「SmaVeksive（スマベクシブ）」が挙げられます。
このテーマでは、専用の「Smaponsive」ブロックを用いることで、中央にモバイル基準のメインコンテンツ（SmaVeksive プレーンなど）を固定し、左右にヘッダーやフッターのカラムを自動配置して余白を有効活用できる仕組みを提供しています。

5. Figmaで仕込む！実装段階で崩れないためのデザイン設定

どれほどCSSの実装を工夫しても、その前段であるデザインデータの段階で「固定された絶対値のキャンバス」しか考慮されていなければ、エンジニアとの間で解釈のズレが生じ、実装時にレイアウトが破綻してしまいます。

Figmaでデザインを作成する初期段階から、実際のCSSの挙動（可変ロジック）をシミュレートした制約を設定しておくことが、手戻りのないスムーズな開発連携に繋がります。

オートレイアウト（Auto Layout）の正確な設定

Figmaのオートレイアウト機能は、CSSのFlexboxに非常に近い概念です。
デザインを作成する際は、単に要素をグループ化するのではなく、要素間の関係性（パディング、余白の詰め方、方向）をオートレイアウトで定義します。
特に、リサイズ設定（Resizing）を以下のように正しく使い分けることが重要です。

• Hug (コンテンツを内包): 中に入るテキストや要素の量に合わせて、自動的にフレームが伸縮する設定。多言語対応やテキストの変更があっても枠からはみ出さない構造を作れます（CSSの fit-content や max-content に相当）。
• Fill (コンテナに合わせて拡大): 親フレームの幅が広がった際に、余白を埋めるように自動で広がる設定。レスポンシブな流動要素に指定します（CSSの width: 100% に相当）。
• Fixed (固定): アイコンや特定のボタンなど、画面サイズが変わっても大きさを変えたくない要素に使用します（CSSの固定px指定に相当）。

Wrap（折り返し）とMin/Max-widthの活用

オートレイアウトの方向設定にある「Wrap（折り返し）」を使用し、個々のアイテムに対して「最小幅（Min-width）」と「最大幅（Max-width）」を事前に設定しておきます。
これにより、画面が狭くなったときに「カードが自動で次の行に落ちる挙動」や「一定幅以下には潰れない挙動」をデザインデータ上で検証できるようになります。

あらかじめデザインデータ上で可変シミュレーションを行い、破綻が起きないことを確認しておくことで、エンジニアも「どの画面幅で要素が折り返されるべきか」を迷わずに実装できます。

デザインシステムやVariables（変数）の設計に配慮しつつ、こうした可変の「制約」をデータに持たせることが重要です。

デザイナーとエンジニアが実装時の共通認識を持つためのアプローチについては、以前紹介した記事『エンジニア連携の手戻りをゼロにする。「状態（States）」考慮漏れを防ぐUI Stackと包括チェックリスト』でも、状態定義の面から詳しく触れています。

undefined

終わりに

レスポンシブ・レイアウトにおいてデバイス間の仕様を破綻させないためのアプローチは、もはや「画面サイズごとに細かくスタイルを継ぎ足していく」という対症療法的な作業ではありません。
モダンな技術とデザインプロセスを上手に組み合わせることで、スマートに解決できます。

今回の記事で紹介した、レスポンシブ設計における重要なポイントは以下の3点です。

• モダンCSSの積極的な活用: 100%幅の設計やdvh、clamp()関数、コンテナクエリなどを活用し、要素自体に自己調整のルールを持たせること。
• Figmaでの上流データの仕込み: オートレイアウトやWrap、Min/Max-widthを活用し、デザインデータ自体に可変の制約を事前に持たせること。
• スマポンシブという戦略的選択: ターゲットユーザーのアクセス傾向に合わせて、スマホ表示幅にコンテンツを固定し、PC表示時は左右の余白（マージン）を有効活用する設計を視野に入れること。

可変性と頑丈さの美しいバランスを探りながら、ぜひ次回のデザインやコーディングで実践してみてくださいね！

それでは、良いデザインライフを！

The post 画面崩れを根本から防ぐ。モダンCSSとFigmaで構築する「絶対に破綻しない」レスポンシブ・レイアウト設計 first appeared on デザペディア.

今回は、変数の増えすぎによる管理の破綻を防ぎ、スモールスタートで運用を回すための「2層トークン構造」と「ガバナンス設定」を整理して解説します。
バリアントの過剰な肥大化を抑え、日々のコンポーネント制作を効率化していきましょう。

1. Figma Variables（変数）とは？Stylesとの決定的な違い

FigmaのVariables（変数）を導入する際、最初に突き当たる疑問が「これまでのStyles（スタイル）と何が違うのか」という境界線です。
両者の役割を曖昧にしたまま導入してしまうと、デザイン作業中に「どちらを適用すべきか」で迷いが生じてしまいます。

使い分けの判断基準は、管理したいデータが「単一の値（Atomic Value）」か「複合パッケージ（Compound Properties）」かという点にあります。
それぞれの性質を正しく理解すれば、迷うことなく適切な機能を選択できます。

Variablesで管理すべき「単一値」

Variablesは、カラーコードや余白のpx値など、それ以上分解できない単一のデータを保持することに特化しています。
最大の特徴は、Mode（モード）機能によって、Light／Darkテーマのように状況に応じた値を瞬時に切り替えられる点です。

• ソリッドカラー: 背景色、テキスト色、ボーダー色などの単一のカラー値
• 数値（Number）: 余白（Padding／Gap）、角丸（Radius）、要素の幅・高さ
• ブーリアン（Boolean）: UIパーツの表示・非表示を制御する真偽値
• 文字列（String）: 多言語展開のラベルやステータス表示のテキスト

Stylesで管理し続けるべき「複合プロパティ」

一方のStylesは、複数のプロパティが組み合わさったパッケージです。
単一のVariablesでは表現しきれないリッチなビジュアル設定は、今後も変わらずStylesが主役を務めます。

• タイポグラフィ（Text Styles）: フォント名、サイズ、ウェイト、行間、文字間隔のセット
• グラデーション: 複数の色とカラーストップ位置の組み合わせ
• エフェクト: 複数のドロップシャドウやレイヤーブラーの重ねがけ

「カラーと数値はVariables、タイポグラフィとグラデーションはStyles」という基本原則をチーム内で共有するだけで、運用の混乱は一気に解消されます。
なおタイポグラフィに関しては、Text Stylesというパッケージを使いつつ、フォントサイズや行間の数値にのみVariablesを紐づけるハイブリッド運用が実務では扱いやすいです。

自分自身も初期はすべてを変数化しようとして混乱しましたが、この分担ルールに落ち着いてからは迷いが完全になくなりました。

2. 破綻を防ぐ「2層トークン構造（PrimitiveとSemantic）」の設計ルール

デザインシステムやトークン設計の解説書を開くと、よく「3層構造（Primitive / Semantic / Component）」が推奨されています。
しかし、現場で最初から3層すべてを厳密に構築しようとすると、設定の手間と認知的負荷に圧倒されて運用が破綻しがちです。

これから導入する段階であれば、まずは最も重要な「Primitive」と「Semantic」の2層構造からスモールスタートすることをおすすめします。
この2階層さえしっかり組めていれば、中規模までのUI設計で困ることはほとんどありません。

Tier 1：Primitiveトークン（生の値）

Primitiveトークンは、具体的なカラーコードや数値を定義する「生の素材置き場」です。
ここには「ボタン」や「背景」といった画面上の役割や意味を持たせず、純粋な色の名前や数値のスケールとして定義します。

• 命名例: _primitive/color/blue/600、_primitive/space/16、_primitive/radius/8
• 値の実装: #2563EB、16px、8px
• 運用のルール: PrimitiveトークンはUIに直接適用せず、後述するSemanticトークンから参照させるためだけに使用します。

Tier 2：Semanticトークン（役割と意味）

Semanticトークンは、「その値をどこで、何の目的で使用するのか」というデザイン上の役割を定義する階層です。
UIをデザインする際にデザイナーが選択パネルから選ぶのは、すべてこのSemanticトークンになります。

• 命名例: color/surface/brand、color/text/primary、space/layout/md
• 値の実装: _primitive/color/blue/600（Primitiveを参照するエイリアス）
• 運用のルール: 画面の背景色を変えたいときは、色コードを直打ちするのではなく、このSemanticトークンを割り当てます。

このように「生の色」と「画面上の役割」を分離しておくことで、将来的にブランドカラーが刷新された際も、参照元のPrimitiveを1箇所書き換えるだけでサイト全体のトーンが一瞬で更新されます。
また、特定のボタンや入力フォーム専用の「Componentトークン」は、必要に迫られた段階で初めて追加すれば十分です。

実務で運用する際も、まずは主要な無彩色とブランドカラー数色から2層化を始めることで、チームメンバーへの負担を最小限に抑えられます。

3. 実務でよく使う4つのVariables設定手順

Variablesの概要と構造を把握したところで、実務で頻出する4つの変数の具体的な設定手順を見ていきましょう。
日常のUI設計でこれら4種類を使いこなせるようになると、制作スピードとデータの整合性が格段に上がります。

① カラー変数（Color）：ダークモードとテーマ切り替え

カラー変数の真価は、複数モード（Mode）によるテーマ切り替えにあります。
LightモードとDarkモードをひとつのコレクション内で共存させる手順は以下の通りです。

1. ローカル変数パネルでコレクションを新規作成し、モード列を「Light」「Dark」の2つ用意します。
2. Semantic階層に color/surface/primary という名前でカラー変数を作成します。
3. Light列の値には _primitive/neutral/50（明るいグレー）を割り当て、Dark列には _primitive/neutral/900（濃いグレー）をエイリアスとして割り当てます。
4. 作成した変数をフレームやカードのFillに適用します。

この設定を済ませておけば、親フレームの右パネルにある「Change variable mode」からDarkを選ぶだけで、子要素のコンポーネント全体が一瞬で反転表示されます。
画面ごとに別々のカンプを用意する必要がなくなるため、メンテナンスの工数を大幅に削減できます。

② 数値変数（Number）：8ptスペーシングと角丸の共通化

余白や角丸の数値をハードコード（直接入力）せず、Variablesで共通化することで、デザインの秩序が自然と保たれます。
特に8ptグリッドルールを採用しているプロジェクトでは、数値変数の導入が大きな威力を発揮します。

1. space/4, space/8, space/16, space/24, space/32 などの基準スケールを数値変数として登録します。
2. オートレイアウト（Auto Layout）のPaddingやGapの入力欄にマウスを乗せ、表示される変数アイコンから対応する数値を割り当てます。
3. 角丸（Radius）についても同様に、radius/sm (4px), radius/md (8px), radius/lg (16px) を用意してコンポーネントに紐付けます。

手入力による「7px」や「15px」といった微細なズレがなくなり、チーム全体のデザイン品質が均一になります。
余白を変数にバインドしておけば、後から「全体の情報密度を少し上げたい」となった場合でも、変数の数値を調整するだけで全画面に反映されます。

③ ブーリアン変数（Boolean）：バリアント肥大化の防止

ブーリアン変数は、要素の表示（true）と非表示（false）を切り替えるための真偽値データです。
バリアント（Variants）を無駄に増やしたくない場面や、コンポーネント内のパーツの出し入れに重宝します。

1. has_icon や is_badge_visible というブーリアン変数を作成し、初期値を true に設定します。
2. コンポーネント内の対象レイヤー（例: アイコン）を選択し、右パネルのレイヤー表示（目のアイコン）を右クリックして変数をバインドします。
3. インスタンス側で変数の値を false に切り替えると、レイヤーが自動的に非表示になります。

従来は「アイコンあり」「アイコンなし」で別々のバリアントを作成していましたが、ブーリアン変数を使えば1つのコンポーネント内で完結します。
結果としてバリアントの総数を半分に圧縮でき、キャンバスの動作軽量化にも直結します。

④ 文字列変数（String）：多言語展開と動的ラベル

文字列変数は、テキストレイヤーに入力される文言をデータとして保持する仕組みです。
画面レイアウトを崩さずに多言語（日本語／英語）での見え方を検証したい場面で役立ちます。

1. label/submit_button という文字列変数を作成します。
2. モード列を「JA」「EN」に分け、JAには「送信する」、ENには「Submit」と入力します。
3. ボタン内のテキストレイヤーを選択し、テキスト設定の「Apply variable」から割り当てます。

英語化によってボタン幅が想定を超えて広がらないか、テキストが意図せず折り返されないかを、デザイン段階で即座にチェックできます。
開発チームへ画面を引き渡す前に文字あふれを検知できるため、手戻りを未然に防ぐことができます。

4. デザイナーが迷わないための「ガバナンス」設定（スコープ・非公開）

Variablesを本格的に運用し始めると、「変数の候補が多すぎて、どれを選べばいいか分からない」という新たな問題が発生しがちです。
この検索ストレスを解消するために、Figmaが用意している2つのガバナンス機能を初期段階で必ず設定しておきましょう。

スコープ（Scope）設定で不要な変数を非表示にする

スコープ設定は、変数を「どのプロパティパネルに表示させるか」を絞り込める機能です。
変数の編集画面を開き、「Scoping」のチェックボックスを調整することで設定できます。

• 角丸用の変数: 「Corner radius」のみにチェックを入れ、余白やサイズからは除外する。
• 余白用の変数: 「Auto layout padding and gap」のみに絞り込む。
• テキストカラー用の変数: 「Text fill」のみに限定し、背景色や線色の候補から隠す。

これにより、デザイナーが角丸を設定しようと選択パネルを開いた際、パディング用の数値変数が候補に出なくなります。
選択画面のノイズが消え、誤った変数を適用してしまうヒューマンエラーを未然に防止できます。

_（アンダースコア）によるライブラリ非公開化

Primitiveトークン（生の値）をデザイナーが間違えてUIに直接選んでしまう事故を防ぐための機能です。
Primitiveを直接適用してしまうと、Modeを切り替えても色が反転しなくなる原因になります。

Figmaでは、コレクション名やグループ名の先頭に _ （アンダースコア）または . （ドット）を付けるだけで、ライブラリ公開（Publish）の対象から一括除外できます。

• 設定例: _primitive` というコレクション名、または `_color/blue/600 というグループ名

この設定を行っておけば、チームメンバーの画面には目的が明確なSemanticトークン（例: color/surface/brand）だけがクリーンに表示されます。
事故が起きない「仕組み」を初期に整えておくことが、無理のない継続運用の秘訣です。

実務でも「間違えて選べない構造」をあらかじめ作っておくことで、デザインレビュー時の指摘事項を大幅に削減できます。

5. 開発連携（Dev Mode・Code Syntax・AIコード生成）を見据えた設計

Variablesを構造化して管理する恩恵は、デザイナー単体の作業効率化にとどまりません。
エンジニアへのハンドオフ（実装引き渡し）の円滑化や、近年のAIコーディング連携においても非常に強力な武器となります。

Code Syntaxの登録で実装の翻訳コストをゼロにする

Figmaの変数設定画面には、「Code syntax」という入力欄が用意されています。
ここにエンジニアリング側で使用する変数名（CSS Custom Propertiesなど）をあらかじめ登録しておきます。

• Figmaの変数名: color/surface/brand
• Web（CSS）のCode syntax: var(--color-surface-brand)
• iOS（SwiftUI）のCode syntax: Color.surfaceBrand

エンジニアがDev Modeで要素をインスペクトした際、脳内変換することなく、コードをそのままコピー＆ペーストして実装に組み込めます。
デザインとコードの命名が1対1で同期するため、デザインレビュー時の手戻りも激減します。

AIコーディング・MCP連携における構造化データの価値

近年、CursorやClaude CodeなどのAIエージェントを活用したフロントエンド開発が急速に浸透しています。
FigmaのVariablesによってデザイン上の決定事項が構造化されていると、AI連携の精度が飛躍的に高まります。

AIはFigmaのデータを解析する際、単なるHexコードではなく「これは背景色としての役割を持つトークンである」という文脈を正確に読み取ります。
その結果、ハードコードされた汚いスタイルではなく、デザインシステムの思想を反映したメンテナンス性の高いコードを一発で生成してくれます。

次のステップ：あわせて深掘りしたい知見

Variablesを基礎から理解した後は、コンポーネントプロパティやダークモード設計と組み合わせることで、UIの管理破綻をより強固に防げるようになります。

バリアントの過剰な肥大化を防ぎ、ボタンや入力フォームを最小限のパーツで設計する具体的な実践テクニックは、以下の記事で体系的に解説しています。

Figmaコンポーネントプロパティの使い方｜バリアント増えすぎを防ぐ設計術

Boolean・Text・Instance Swapの3大プロパティを活用し、増えすぎたバリアントを最小限に抑えるコンポーネント設計術とスロット運用のコツを解説します。

VariablesのMode機能を活用して、ライトモードとダークモードを一瞬で切り替える具体的な配色ルールと変数設計は、以下のガイドが参考になります。

ダークモードは必要？3つの導入基準とFigma変数設計・便利プラグイン

ダークモードの導入基準から配色の4大ルール、Figma VariablesのMode機能を活用した破綻しない2層変数設計とおすすめプラグインを解説します。

数値変数をAuto LayoutのPaddingやGapに割り当てて、崩れないレスポンシブコンポーネントを組む手順については、こちらの記事で詳しく解説しています。

Figmaオートレイアウト完全ガイド！崩れないネストと余白設計

Figmaのオートレイアウトを基礎から徹底解説。リサイズ挙動（Hug/Fill/Fixed）の使い分けや崩れないネスト構造、実務で役立つコンポーネント余白設計をまとめました。

まとめ：まずはカラー数色・スペーシングからのスモールスタート

Figma Variablesは、一見すると設定項目が多くて難解な機能に感じられるかもしれません。
しかしその本質は、「デザインの意思決定を一貫したルールで整理整頓するための道具」にすぎません。

• カラーと数値はVariables、タイポグラフィとグラデーションはStylesで管理する
• 生の値（Primitive）と役割（Semantic）のシンプルな2層からスタートする
• スコープ設定と _（非公開設定）でデザイナーの選択肢を適切に絞り込む
• Code Syntaxを登録してエンジニアへの引き渡しとAIコード生成を円滑にする

最初から大規模なデザインシステムを組もうと気負う必要はありません。
まずはプロジェクトのブランドカラー数色や、よく使うスペーシングの数値から少しずつ変数化してみてください。
小さな整理整頓の積み重ねが、将来的にチーム全体を支える強固な制作基盤へと育っていくはずです。

The post Figma Variables（変数）の使い方｜バリアント肥大化を防ぐ2層トークンと命名規則【2026】 first appeared on デザペディア.

最近、打鍵感にこだわって少し高めのメカニカルキーボードを新調しました。キーを「カチャッ」と押し込むときの、あの指に返ってくる反発と心地よい音。用もないのに、つい無駄にタイピングしてしまうほど気に入っています。

物理的なスイッチを押す気持ちよさって、理屈じゃなく本能的に惹かれるものがありますよね。

最近ではスマートフォンの画面でも、こうした「触る気持ちよさ」を持ったUIを見かけるようになりました。
たとえば、語学アプリの『Duolingo』を使ったことがある方は、ボタンを押したときに「ぷにっ」と沈み込むような独特の弾力を感じたことがあるかもしれません。

あの操作感は、画面の動きだけでなくスマートフォンの細かな振動機能（ハプティクス）とも連動していて、本当に柔らかい物理ボタンを押しているような錯覚を生み出していますよね。

本記事では、この新しいデザイン手法がなぜ私たちに心地よさを与えるのか、その仕組みや法則を解説していきます！

1. 2026年のデザイントレンド「Squishy UI」とは？ 効率化された画面に足された手触り

今のアプリやウェブサイトは、フラットデザインがすっかり定着し、無駄が削ぎ落とされて本当に使いやすくなりましたよね。

その洗練された使いやすさをベースにしつつ、さらに「触る楽しさ」をプラスしようとするのが、触覚的マキシマリズム（Tactile Maximalism）と呼ばれるアプローチです。
これは、画面の中の図形が、単なる平坦な色面ではなく、ゼリーや粘土のような「体積」を持っているかのように振る舞うデザインのことです。

• これまでのデザイン：効率的で整理されており使いやすい反面、物理的な手ざわりはない。
• 新しい潮流：ユーザーの操作に合わせて、画面上の要素が物理的にへこんだり、跳ね返ったりする「生きた」反応を返す。

あわせて読みたい
効率化されすぎた「完璧なUI」の反動から生まれている2026年のトレンドについては、以下の記事でも解説しています。

完璧なUIに疲れたら。Future Retroがもたらす人間味と不完全さの美学

効率化されすぎた「完璧なUI」の反動から生まれているデザイントレンドを解説します。

2. なぜSquishy UIは「触って気持ちいい」のか？ 感情を動かすUX/UIデザイン

Yunyの視点：Squishy UIのボタンを触っていると、子供の頃にお気に入りのおもちゃのボタンを何度もカチカチと押したときの、あの素朴な安心感に似ているなと感じます。

なぜ私たちは、画面がぷにぷにと動くことに心地よさを感じるのでしょうか。
そこには、はっきりとした心理学的な理由があります。

本能的な安心感

私たちがボタンを押したとき、それが物理的に「へこみ、跳ね返る」という反応を返してくれると、脳は「自分の操作が正しく受け付けられた」という強い確証を得ます。
これがデジタル特有のストレスを和らげ、安心感に繋がるのです。

親しみやすさを生む形状（数値の根拠）

Squishy UIでは、20px〜40pxという非常に大きな角丸（要素の角の丸み）がよく使われます。
このぽってりとした丸みが、どこかホッとする親しみやすさを生んでいるんです。

3. Squishy UIはどう作る？ 心地よさを生み出すアニメーションとCSSの法則

あのように柔らかく動くボタンも、実はCSSやアニメーション設定での数値計算によって作られています。
「なんとなく柔らかい」のではなく、そこには心地よさを生むための明確なルールが存在するのです。

体積を保存する法則

画面上のボタンが指で押し潰されるとき、「サイズのピクセル値と角丸のピクセル値の合計を一定に保つ」という計算が行われています。
これにより、ボタンがただ小さくなるのではなく、本物のゴムのように横に少し広がりながら押し潰される「リアルな物理法則の錯覚」が生まれます。

「完璧なバネ」のスイートスポット

アニメーションを設定する際、バネの強さを決める剛性（Stiffness）を400、揺れの収まり具合を決める減衰（Damping）を15といった数値に設定するのが、ひとつのスイートスポットとされています。
これにより、無駄に揺れすぎず、指に吸い付くような完璧な弾力感が表現できるのです。

あわせて読みたい
UIから「質量」や「手ざわり」を感じさせる実装アプローチに興味がある方は、こちらの記事も参考になります。

Apple HIG（ガイドライン）が教える心地よさの正体。44ptと文字設計

44ptのタップ領域や物理法則のアニメーションなど、HIGの心地よいUI設計思想を徹底解説します。

4. Squishy UIをデザインに取り入れる際の注意点・アクセシビリティ

触って楽しいSquishy UIですが、どんな場面にでも使っていいわけではありません。
適材適所の見極めが重要になってきます。

適している場面

毎日の習慣をサポートするウェルネスアプリや、学習ツールなどに最適です。
ユーザーの不安を取り除き、「もっと触りたい」という前向きな気持ちを引き出します。

避けるべき場面

逆に、金融機関のアプリや業務用システムなど、大量の情報を素早く処理する場面には不向きです。
UIがぽってりしすぎていると、「自分のデータが真剣に扱われていない」という不信感を与えてしまう危険があります。

また、柔らかさを表現するために淡い影などを多用するため、文字と背景のコントラスト比（推奨値は4.5:1）を満たしにくくなる点にも注意が必要です。
見た目の楽しさとアクセシビリティのバランスを取ることが、プロのデザイナーの腕の見せ所ですね！

まとめ：Squishy UIがもたらす次世代のデジタル体験

今回ご紹介した内容を振り返ると――

• Squishy UIは、単なる見た目の流行ではなく「触る楽しさ」の実用的なアプローチ
• 物理的な「へこみ」や「バネ感」が、ユーザーに本能的な安心感を与える
• 心地よさの裏には、CSSやアニメーションの緻密な数値ルールが存在する
• 美しさと同時に、情報を取り扱う信頼感やアクセシビリティへの配慮が必要

この4点に集約されます。

Squishy UIは、効率化が進んで単調になりがちなアプリに、確かな「手ざわり」を取り戻してくれます。

明日、スマートフォンを触るとき。
お気に入りのアプリのボタンが、どんな風に指を押し返してくるか、少しだけ意識してみてください。

普段使っているアプリの動きに少し注目してみるだけで、毎日のスマホ操作がちょっと楽しくなるかもしれませんね！

さらに深掘りしたい方へ（参考リンク）

実際にSquishy UIを採用しているサイトをご紹介します。ぜひ、お手元のスマートフォンなどで触って、その「心地よさ」を体験してみてくださいね！

• Duolingo（デュオリンゴ）
  学習アプリの代表格です。ボタンを押した際の立体的な沈み込みや、バネのような反発がSquishy UIの最も分かりやすい例と言えます。
• Family（ファミリー）
  暗号資産ウォレットのアプリです。前述の通り、金融関連など信頼性が求められるサービスには不向きとされがちですが、あえてSquishy UIを振り切って採用することで「親しみやすさ」を演出し、競合優位性を生み出している好例です。UI全体が非常に柔らかく、タップやスワイプに対する触覚的な反応（バウンスやスクイーズ）が徹底されており、触っているだけで楽しくなるデザインに仕上がっています。

終わりに

最後までお読みいただき、ありがとうございます！

UIデザインの世界は、見た目だけでなく「触り心地」まで工夫されるようになってきて、ますます面白くなっていますね。
今回の記事が、皆さんの日々のデザインワークのヒントになれば嬉しいです。

これからも、素敵なデザインを見つけたらどんどんシェアしていきますね。
それでは、また次回の記事でお会いしましょう！

The post Squishy UIとは？触って気持ちいいぷにぷにUIの特徴と作り方 first appeared on デザペディア.