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 デザペディア.

UIデザインの現場で「なぜその配置にしたのか」を問われた際、うまく言葉にできず困った経験がある方も多いと思います。
自分自身もデザインを始めたばかりの頃は、「見た目の収まりが良いから」といった感覚的な理由しか返せず、手戻りを繰り返すことがよくありました。

画面の使いやすさは、デザイナー個人のセンスや勘ではなく、人間の脳が情報を処理する認知特性のルールで決まります。
この記事では、実務のUX/UI設計ですぐに役立つ代表的な5つの認知心理学の法則と、デザインレビューでそのまま使える具体的な言語化テクニックを詳しく共有します。

なぜUIデザイナーに「認知心理学」が必要なのか？

ユーザーがWebサイトやアプリを操作するとき、画面上の情報を見つけ、理解し、行動を決定するまでに多くの脳のリソース（認知負荷）を消費しています。
操作に迷ったり戸惑ったりする原因の大半は、レイアウトの美しさではなく、人間の情報処理プロセスに対して不自然な負荷がかかっている点にあります。

認知心理学の法則を設計の土台に据えると、デザインレビューの議論が「個人の好み」から「客観的な使いやすさの検証」へと大きく変わります。
チームのエンジニアやプロダクトマネージャーに対しても、科学的な根拠を持った提案ができるため、無駄な手戻りを防ぎながらスムーズな合意形成を図ることができます。

1. ヒックの法則（Hick’s Law）｜選択肢の増えすぎを防ぎ、意思決定を加速させる

ヒックの法則とは、ユーザーが意思決定を下すまでの時間は、提示された選択肢の数と複雑さに応じて対数関数的に増加するという心理学の基本法則です。
1952年に心理学者のウィリアム・エドマンド・ヒックとレイ・ハイマンによって定式化され、人間工学や情報設計の現場で広く活用されています。

UI設計において選択肢を1つの画面に並べすぎると、ユーザーは何を選べばよいか分からなくなり、行動の停止や画面からの離脱を引き起こします。
たとえば、ドロップダウンメニューの中に数十個の項目が無秩序に並んでいたり、ヘッダーに10個以上のナビゲーションリンクが密集していたりする状態がこれに当たります。

実務での実践：松竹梅の3択設計と段階的開示

SaaSの料金プラン表や機能選択画面では、主要な選択肢を3つ程度（いわゆる松竹梅の構成）に絞り込むことが実務における標準的なアプローチです。
どうしても選択肢が多くなる場合は、最初からすべてを見せるのではなく、段階的開示（Progressive Disclosure）の手法を取り入れます。

初期表示では最も利用頻度の高い主要項目だけを提示し、詳細な設定や高度なオプションはアコーディオンやモーダルで必要なときだけ展開させます。
実際にFigmaで画面を組む際も、初期状態の選択肢を3〜4個に制限するだけで、ユーザーテストでのタスク完了時間が大きく短縮されることを実感します。

選択肢の絞り込みやあえて制約を設けるUX設計のアプローチについては、以下の記事でも詳しく解説しています。
現場での情報整理に迷ったときの指針として、ぜひ参考にしてみてください。

デザインハーネス入門｜AIのUI生成とレビュー停滞を解く4層構造【2026】

無限の選択肢による疲弊を防ぎ、あえて制約を設けることでUXを高めるフレームワークを解説。

2. フィッツの法則（Fitts’s Law）｜移動距離とターゲットサイズで誤操作をゼロにする

フィッツの法則とは、ある目標（ターゲット）に素早く到達して選択するまでの時間は、目標までの距離に比例し、目標の大きさに反比例するという法則です。
1954年に心理学者のポール・フィッツが提唱したもので、マウスカーソルの移動やスマートフォンのタップ操作における基本中の基本となる指標です。

この法則から導き出されるのは、「頻繁に押すボタンは大きく、指やカーソルに近い場所に置くべき」という極めて明快な設計原則です。
逆に、画面の端にある小さな文字リンクや、親指が届きにくい位置にある重要なCTAボタンは、操作時間を無駄に長引かせ、誤タップの原因になります。

実務での実践：親指操作ゾーン（Thumb Zone）と44pt基準

スマートフォンアプリの設計では、片手持ちの親指が自然に届く画面下部エリア（親指操作ゾーン）に主要アクションを配置するのがセオリーです。
購入ボタンや送信ボタンをページ最下部の固定ボトムバーに配置する設計は、まさにフィッツの法則に基づいた移動距離の最小化の実践例と言えます。

また、Appleのヒューマンインターフェイスガイドライン（HIG）が定める「最小タップ可能領域44×44pt」のルールも、フィッツの法則に直結しています。
Figmaでボタンコンポーネントを設計する際は、見た目のアイコンが小さくても、オートレイアウトの余白を含めたヒットエリアを確実に44pt以上確保することが不可欠です。

タップ領域の具体的な数値基準やHIGの設計思想については、以下の記事で体系化しています。
モバイルUIの操作性を引き上げるための基本ルールとして、あわせて確認してみてください。

Apple HIG実務ガイド｜タップ領域44pt・文字11pt基準とiOSの基本原則【2026】

Appleが定める44ptタップ領域や文字サイズの論理的根拠と、iOS実務への落とし込み方を網羅。

3. ヤコブの法則（Jakob’s Law）｜「既視感」を味方につけ、学習コストを最小化する

ヤコブの法則とは、ユーザーは他の無数のWebサイトやアプリで大半の時間を過ごしているため、あなたのサイトもそれらと同じように機能することを期待しているという法則です。
ユーザビリティ研究の第一人者であるヤコブ・ニールセンが2000年に提唱したもので、Web標準やデザインシステムの重要性を端的に表しています。

デザイナーが独自性や斬新さを求めすぎるあまり、一般的な操作ルールを逸脱してしまうと、ユーザーは強いストレスと学習コストを強いられます。
たとえば、ヘッダー左上のロゴをクリックしてもトップに戻らない設計や、右上に置かれるはずの検索バーやカートアイコンがフッターの隅に隠れているような構成です。

実務での実践：メンタルモデルの流用と独自性の住み分け

使いやすいUIを構築する近道は、ユーザーがすでに獲得しているメンタルモデル（頭の中の操作イメージ）をそのまま流用することです。
ECサイトであれば「右上にカート」「画面下部に固定の購入ボタン」、メディアサイトであれば「左上にロゴ」「上部にグローバルナビゲーション」といった配置を素直に踏襲します。

UIデザイナーがクリエイティビティを発揮すべき領域は、操作の基本構造ではなく、ブランドの世界観を伝えるビジュアルや丁寧なインタラクションです。
基本の導線ルールを業界標準にしっかりと揃えることで、ユーザーは使い方に悩むことなく、サービス本来の価値やコンテンツに集中できます。

4. ミラーの法則（Miller’s Law）｜短期記憶の限界「マジックナンバー7」と情報のチャンキング

ミラーの法則とは、平均的な人間が一度に短期記憶（ワーキングメモリ）に保持できる情報の数は、「7加減2（5個から9個）」程度に限られているという心理学の基本法則です。
一般には「マジックナンバー7（マジカルナンバー7±2）」という呼び名でも広く親しまれており、1956年に認知心理学者のジョージ・ミラーが発表した論文に由来します。

近年の認知心理学の研究では、複雑なUI環境においては保持できる数がさらに少ない「4±1個程度」とも言われています。
区切りのない数字の羅列や、整理されていない長大な箇条書きリストは、ユーザーの記憶のキャパシティをあっという間に圧迫してしまいます。

実務での実践：情報のチャンキングとフォームのステップ分割

この記憶の負荷を軽減するための最も強力な手法が、複数の情報を意味のある塊にまとめる「チャンキング（Chunking）」です。
クレジットカード番号を4桁ずつハイフンで区切ったり、電話番号を市外局番ごとに分ける入力フォームの設計は、チャンキングの典型的な応用例です。

また、20項目以上におよぶ会員登録やアンケートフォームを設計する際は、1画面にすべてを詰め込まず、3〜4ステップに分割して案内します。
Figma上でカード型UIをレイアウトする際も、1つのカード内に含める主要情報は3〜4要素以内に抑え、視覚的なグループを明確に分けることが大切です。

実務で注意したいのは、画面上のUIは「記憶」ではなく「視覚認識」できるため、メニュー項目などを機械的に7個以下に制限する必要はない点です。
重要なのは数を無理に減らすことではなく、関連する項目同士を適切なチャンク（塊）に整理して、スキャンしやすい構造を作ることです。

5. フォン・レストルフ効果（孤立効果）｜視覚的コントラストで最重要アクションを際立たせる

フォン・レストルフ効果（別名：孤立効果）とは、複数の似た要素が並んでいるとき、他と異なる視覚的特徴を持つ1つの要素が最も記憶に残り、注目を集めるという効果です。
1933年に精神科医のヘドウィグ・フォン・レストルフによって発見され、CTAボタンの設計や価格表のレイアウトにおいて最も頻繁に活用される理論です。

この効果をUIに応用する際の注意点は、画面内のあらゆる要素を目立たせようとして、有彩色や強いコントラストを多用しすぎないことにあります。
すべてのボタンが同じ鮮やかなブルーで塗られている画面では、強調の効果が相殺され、結果としてユーザーはどこをタップすべきか迷ってしまいます。

実務での実践：Primaryボタンの孤立化と「おすすめ」バッジ

この効果を最大限に活かすためには、画面内で最優先してほしい操作（Primaryアクション）に対してのみ、明確な視覚的差異を与えます。
たとえば、主要な「購入する」「登録する」ボタンだけを鮮やかな塗りのボタンにし、キャンセルや戻るなどの副次的なボタンは枠線（Secondary）やテキストリンク（Tertiary）に抑えます。

また、3つの料金プランが並ぶ比較表において、中央の推奨プランだけカードの枠線を太くし、上部に「人気No.1」といったバッジを付与する手法もフォン・レストルフ効果の実践です。
周囲を均一で控えめなトーンに整えておくことで、際立たせたい1点にユーザーの視線を自然かつ的確に誘導できます。

実務で使える！デザインレビューを突破する「言語化フレーズ」早見表

認知心理学の知識は、実際の画面設計だけでなく、チーム内でのデザインレビューやクライアントへの提案において大きな力を発揮します。
感覚的な指摘を受けた際に、そのまま根拠として使える実践的な言語化フレーズを以下の表に整理しました。

「なんとなく使いにくい」「自分の感覚と違う」といった主観的な指摘に対しても、心理学の法則に基づいた客観的な意図を返すことで、議論を建設的な方向へ進められます。
デザイナー自身が論理的な言葉を持つことは、デザインの品質を守り、チーム全員が納得して開発を進めるための確かな強みになります。

デザインの意図をチームやクライアントに的確に伝え、合意形成をスムーズにするための言語化スキルについては、こちらの記事でも詳しくまとめています。
レビューでの伝え方に課題を感じている方は、あわせて目を通してみてください。

段階的開示（プログレッシブディスクロージャー）入門｜情報過多を防ぐUI設計

UIの情報過多を防ぎ、シンプルさと多機能性を両立させる「プログレッシブディスクロージャー（段階的開示）」を解説。ヤコブ・ニールセン提唱の基本原則から実務の4大展開パターン、隠しすぎを防ぐ境界線ルールまで網羅します。

終わりに

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

UIデザインにおいて認知心理学の法則を学ぶことは、表現の幅を狭める制約ではなく、自信を持ってデザインを届けるための論理的な土台になります。
画面の向こう側にいるユーザーの脳や身体の仕組みに寄り添うことで、迷いのない心地よい操作体験を生み出すことができます。

日々の制作の中で配置やサイズに迷ったときは、ぜひ今回紹介した5つの法則を振り返り、実務の設計に役立ててみてください。
これからも、論理的なUIデザインを一緒に楽しんでいきましょう。
それでは、良いデザインライフを！

The post UIデザインに効く認知心理学の法則5選｜ヒック・フィッツ・ヤコブの実務応用 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 デザペディア.

テキストの打ち替えやパーツ追加のたびに余白が崩れると、手作業による再調整が発生します。
オートレイアウトを活用すれば、コンテンツの増減に合わせてフレームが自動伸縮し、手動修正の工数を大幅に削減できます。

本記事では、実務で破綻しないオートレイアウトの基礎知識と、レスポンシブなネスト（入れ子）設計の手順を整理して解説します。

そもそもオートレイアウトとは？（通常フレームとの決定的な違い）

Figmaのオートレイアウトは、フレーム内の要素に対して規則的な並び順と余白ルールを適用し、コンテンツ量に応じてサイズを自動調整する機能です。
通常のフレームとの最大の違いは、「絶対座標（X, Y）」から「要素間の相対的な関係性」への変化にあります。

従来のグループや通常フレームは、キャンバス上の固定位置に要素を配置するため、文字数が増えても周囲のパーツは連動しません。
一方、オートレイアウトを適用したフレームは、テキストが増加するとフレームの高さが自動で拡張され、下部のパーツも自然に押し出されます。

この仕組みは、Webやアプリ開発におけるCSSの「Flexbox」と同様のレイアウトモデルに基づいています。
そのため、オートレイアウトを用いたデザイン設計は、エンジニアへの正確な実装意図の伝達に直結します。

オートレイアウトの適用と解除で使用する基本ショートカットキーは以下の2つです。

• オートレイアウトの追加: Shift + A
• オートレイアウトの解除: Option + Shift + A（Mac） / Alt + Shift + A（Windows）

要素を選択して Shift + A を実行すると、選択要素が即座にオートレイアウトフレームへ変換されます。
実務でUIパーツを作成する際は、要素を選択して Shift + A を適用する操作が標準的な手順になります。

なぜ実務で必須なのか？オートレイアウトを使う2大メリット

実務でオートレイアウトを使用するメリットは、主に「レスポンシブ対応の効率化」と「AI・MCP連携時の精度向上」の2点です。

① デザイナー視点：画面幅の伸縮やテキスト変更に柔軟に対応できる

Webサイトやアプリは、PC・タブレット・スマートフォンなど複数の画面幅で表示されます。
また、多言語展開などによってテキストの文字数が大きく変動するケースもあります。

オートレイアウトで構築しておけば、親フレームの幅を伸縮させるだけで、内部のカードやテキストが自動追従します。
画面幅ごとに個別のデザインをゼロから作り直す必要がなくなり、レスポンシブ検証の工数を削減できます。

② 開発・AI連携視点：MCPやCursorがレイアウト構造を正確に解釈できる

最近の実務では、MCP（Model Context Protocol）経由でFigmaのデザインデータをClaudeやCursorなどのAIツールに連携し、コードを自動生成する手法が普及しています。
この連携において重要になるのが、デザインの親子関係とレイアウト構造です。

座標のみで配置されたデータの場合、AIは要素同士の前後関係を推測できず、不要なタグが乱立したコードを出力しがちです。
適切にオートレイアウトが組まれていれば、AIはFlexboxの方向や余白サイズを正確に認識し、実務で再利用しやすいコンポーネントコードを出力できます。

Figmaレイヤー整理と命名規則｜AI実装とチーム開発で破綻しない設計ルール【2026】

Figmaでレイヤー名が「Frame 123」で散らかる悩みを解消！ClaudeやMCP、Cursor連携で破綻しない「AIレディ」な命名規則と整理ルールを徹底解説。コピペで使える実践ネーミング一覧とAI自動リネーム用プロンプト付き。

オートレイアウトを「使うべき場面・使わない場面」

オートレイアウトは有用な機能ですが、キャンバス上の全要素に適用する必要はありません。
用途に応じて、「使うべき場面」と「あえて使わない場面」を明確に切り分ける運用が実務に適しています。

オートレイアウトを使うべき場面

• ボタンやタグ・バッジ: ラベルとアイコン間の間隔（Gap）やPaddingを一定に保ち、アイコンの有無や状態（バリアント）の切り替えによる崩れを防ぐ
• 入力フォームや検索バー: 先頭・末尾のアイコン、プレースホルダー、クリアボタンなどの配置間隔を均等に保ち、親コンテナの幅に連動して伸縮（Fill）させる
• カードUI、記事リスト、ナビゲーションバー: 反復する要素を等間隔（Gap）で整列させ、項目の追加・削除や並び替えをワンアクションで行う
• レスポンシブな画面全体のレイアウト: デバイス幅の変更に合わせて、内部のセクションやカラムを自動で伸縮・再配置させる
• デザインシステムの共通アセット: チーム全体でパーツを再利用する際、手動調整によるレイアウトの崩れを防ぎ一貫性を担保する

あえてオートレイアウトを使わない場面

• 初期のアイデア出し・自由なブレスト: 構造や余白を固定せず、直感的にメモや参考画像を配置する段階
• イラストレーションやアイコン作成: 幾何学図形やベクターパスを自由な重なり順や角度で配置する場合
• キービジュアルや自由配置のコラージュ: 規則的な並び順ではなく、非対称に配置するグラフィック表現

まずはボタンやカードなど、規則的に並べるパーツから適用するのが扱いやすい進め方です。

オートレイアウトの「3大基本パラメーター」

オートレイアウトを適用すると、右側のプロパティパネルに専用の設定項目が表示されます。
基本となる設定は、「方向」「余白」「間隔」の3つです。

① 方向（Direction）：縦積みと横並びの指定

方向は、フレーム内の子要素をどの向きに整列させるかを決定する設定です。
UIの構成要素は、基本的に以下の2つの向きを組み合わせて設計します。

• 垂直方向（Vertical layout）: 要素を上から下へ縦方向に積み重ねます（記事リスト、入力フォーム、カードの上下パーツなど）。
• 水平方向（Horizontal layout）: 要素を左から右へ横方向に並べます（アイコン付きボタン、ナビゲーションメニュー、タグの並びなど）。

パネル上の矢印アイコン（↓ / →）を選択することで、いつでも向きの切り替えが可能です。

② 余白（Padding）：外枠と要素間のスペース

パディングは、オートレイアウトフレームの内側と、内部の要素との間に設ける余白です。
例えばボタンを作成する場合、ラベルテキストの上下左右に配置するスペースをこのパディングで定義します。

Figmaでは、上下・左右の一括設定と、4方向を個別に指定する方法を選択できます。
デザインの一貫性を確保するため、8の倍数（8px、16px、24pxなど）を基準とした数値設計が広く用いられています。

③ 間隔（Gap / Spacing between items）：要素間の距離

間隔（Gap）は、フレーム内に並ぶ要素同士の距離を指定する数値です。
リストアイテム間の距離や、ボタン内のアイコンとテキスト間のスペースを均等に保つ際に指定します。

間隔設定には、数値を指定する固定モードのほかに、「Auto（自動 / Space between）」設定があります。
Autoを指定すると、フレーム全体の幅や高さに応じて、子要素が両端に均等に離れて配置されます。

ヘッダーの左端にロゴ、右端にメニューボタンを配置するレイアウトなどで活用されます。

3つのリサイズ挙動（Hug・Fill・Fixed）の使い分け

オートレイアウトでレイアウト崩れが発生する主な要因は、親要素と子要素のリサイズ設定の不一致です。
Figmaでは、幅（W）と高さ（H）のそれぞれに対して3種類のリサイズ挙動を指定できます。

この3つの挙動は、言葉で理屈を追うよりも、実際にFigma上でテスト用のフレームを作り、親要素の端を左右にドラッグしてみるのが最も直感的に把握できます。
まずはそれぞれの役割と挙動の違いを整理します。

1. Hug contents（コンテンツを内包）

Hug contentsは、フレーム内部のコンテンツサイズに合わせて、外枠が追従して伸縮する設定です。
テキストの文字数に応じて、フレームの幅や高さが自動的に伸縮します。

• 主な用途: ボタン、ラベルタグ、ステータスバッジなど
• 特徴: パディング数値を維持したまま、中身のサイズに応じてフレームが動的に変化します。

2. Fill container（コンテナに合わせて拡大）

Fill containerは、親フレームの余剰スペースを埋めるように、子要素が自動で拡大する設定です。
レスポンシブな画面設計において中心となる挙動です。

• 主な用途: カード内の本文テキスト、全幅バナー、レスポンシブな入力フォームなど
• 特徴: 親フレームの幅を変更した際、内部の要素が連動して拡大・縮小します。

3. Fixed size（固定サイズ）

Fixed sizeは、中身のコンテンツ量や親フレームの大きさに関わらず、指定した幅や高さを固定する設定です。

• 主な用途: アイコン（例: 24×24px）、アバター画像（例: 48×48px）など
• 特徴: 親フレームの伸縮に影響されず、要素の寸法を維持します。

実務で参照しやすい推奨設定の組み合わせは以下の通りです。

設定で迷ったときは、親フレームの端をドラッグして伸縮させてみてください。
意図した通りに追従しない場合は、親要素と子要素のW/H設定（Hug / Fill / Fixed）を1階層ずつ確認します。
Fillに指定すべき要素がFixedやHugのままになっているケースが大半です。

破綻しない「ネスト（入れ子）構造」の組み立て手順

複数のパーツで構成されるUIは、最小単位の要素から順にオートレイアウトを組み、外側のフレームへネスト（入れ子）していく構造をとります。

ここでは、実務で頻出するメディアカードUIを例に組み立て手順を解説します。

Step 1: アイコンとラベルの最小パーツを作る（横並び）

アイコンと「保存する」というラベルテキストを選択し、Shift + A で横並びのオートレイアウトを適用します。
幅・高さともに「Hug」に設定し、要素間の間隔（Gap）を4pxに設定します。

Step 2: ユーザー情報ヘッダーを作る（横並び）

アバター画像（Fixed: 40×40px）とユーザー名テキストを選択し、Shift + A を適用します。
方向を水平（横並び）にし、ユーザー名テキストの幅を「Fill container」に設定します。
テキスト幅をFillにしておくことで、ユーザー名の長さに応じて柔軟にスペースが確保されます。

Step 3: タイトルと本文テキストをまとめる（縦並び）

見出しテキストと本文テキストを選択し、Shift + A で縦並びのフレームを作成します。
見出しと本文の両方の幅を「Fill container」に指定します。
幅をFillに設定することで、カード全体の横幅を変更した際にも文章が自動で折り返されます。

Step 4: 外枠フレームへ統合する

作成した各グループ（ヘッダー、画像、テキスト、ボタン）を選択し、再度 Shift + A を押して外枠フレームを作成します。
カードフレームの方向を垂直（縦並び）にし、内側のパディング（例: 16px）と要素間の間隔（例: 12px）を指定します。

内部に含まれる各グループの幅をすべて「Fill container」に切り替えます。
外枠フレームの幅を左右にドラッグして伸縮させ、内部の画像やテキストが追従して伸縮すれば設定完了です。

参考になる公式コンポーネントライブラリ（Material Design / HIG）

コンポーネントのレイヤー構成やネスト設計の参考として、公式のデザインシステムライブラリを活用するのが有効です。

Figma Communityでは、Google公式の「Material 3 Design Kit」や、Apple公式の「Apple Design Resources」が無償公開されています。
実際のコンポーネントのレイヤー構造を確認することで、実務で通用する設計手法を参照できます。

• Google Material Design 3: ボタンやダイアログにおけるPadding・Gapのルールや、ネスト階層の整理手法が確認できます。
  Figmaリンク: Material 3 Design Kit（Figma Community）
• Apple HIG (Human Interface Guidelines): ナビゲーションバーやリストアイテムなど、可変テキストに対応するレイアウト構造が参考になります。
  Figmaリンク: Apple Design Resources – iOS 18 and iPadOS 18（Figma Community）

自分自身も、新しいコンポーネントを設計する際はMaterial DesignやHIGのレイヤー構造をリファレンスとして確認しています。

応用テクニック（Wrapと絶対配置）

基本の整列とネストに加えて、レイアウトの柔軟性を高める2つの実務向け設定があります。

① 折り返し（Wrap）：幅に応じた自動改行

タグ一覧や検索フィルターのボタンなど、画面幅が狭くなった際に自動で複数行へ改行させたい場面があります。
このレイアウトには「折り返し（Wrap）」を使用します。

水平方向のオートレイアウトを選択した状態で「Wrap」アイコンを有効にします。
親フレームの幅を狭めると、収まりきらない子要素が自動的に下段へ回り込みます。

② 絶対配置（Absolute Position）：特定位置への固定配置

オートレイアウトフレーム内で特定の要素を重ねて配置したい場合、「絶対配置（Absolute Position）」を使用します。
カード右上のバッジや、モーダルの閉じるボタンなどが対象になります。

対象の要素を選択し、プロパティパネルのオートレイアウト項目右上にある「重なりアイコン」をクリックします（UI3環境では「Ignore auto layout / オートレイアウトを無視」アイコンとして表示されます）。
その要素のみがオートレイアウトの整列計算から除外され、自由な座標へ配置できます。
Constraints（制約）を「Right」「Top」に設定しておくことで、親フレームが伸縮しても右上の位置が固定されます。

実務でよくあるトラブルと解決策

実務で遭遇しやすいトラブルと、その対処手順をまとめました。

トラブル1: テキストを打ち替えると枠を突き抜ける

• 原因: テキストレイヤーの幅が「Fixed」になっており、自動折り返しの設定が外れているケースがあります。
• 対処法: テキストレイヤーの幅を「Fill container」に変更し、テキストパネルの折り返し設定を「自動高さ（Auto height）」に指定します。

トラブル2: 親フレームを広げても中身が横に広がらない

• 原因: ネスト階層内の子要素の幅が「Fixed」または「Hug」のまま残っていることが原因です。
• 対処法: レイヤー階層を順に確認し、横幅を連動させたい要素の幅をすべて「Fill container」に統一します。

トラブル3: アイコンが縦横に歪んで伸び縮みする

• 原因: ベクターデータに直接Fill設定が適用されているか、縦横比の固定が外れています。
• 対処法: アイコンを24×24pxなどの固定サイズフレームでラップし、そのフレームの幅・高さを「Fixed」に指定します。

次のステップ：あわせて参照したい関連記事

オートレイアウトで作成したコンポーネントをエンジニアへ正確に引き渡すための「Dev Mode」の活用法については、以下の記事で解説しています。
余白やリサイズ設定がCSSコードにどのように反映されるかを把握することで、開発チームとの連携がスムーズになります。

Figma Dev Mode（開発モード）の使い方と料金体系｜できること・できないことと実装連携【2026】

こんにちは！ UIデザイナーの自分（Yuny）です。 エンジニアの方にデザインデータを引き渡した直後、Slackで「ここ…

PaddingやGapの数値をデザインシステムとして共通化する場合は、Figmaの「Variables（変数）」との連携が有効です。
余白ルールを変数化することで、デザイン全体の整合性を保ちやすくなります。

Figma Variables（変数）の使い方｜バリアント肥大化を防ぐ2層トークンと命名規則【2026】

FigmaのVariables（変数）を活用すると、ライト／ダークモードの切り替えやスペーシングの動的変更がスムーズに実…

終わりに

オートレイアウトは、ボタンやタグなどの最小パーツから段階的に適用していくことで、実務への導入がスムーズになります。
要素間の余白や並び順をルール化しておくことで、画面サイズやコンテンツ量の変更に伴う手作業の修正工数を大幅に削減できます。

まずは日常的なコンポーネント設計から活用し、レスポンシブなUI設計に役立ててみてください。
それでは、良いデザインライフを！

The post 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 デザペディア.

今回は、変数の増えすぎによる管理の破綻を防ぎ、スモールスタートで運用を回すための「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 デザペディア.

画面を何十枚も一瞬で作れるようになっても、デザイナーが1枚ずつ手作業で目視確認していては、結局そこで作業が止まってしまいます。
そんな「AIが作るUIの品質やルールを、どうやってチームで守っていくか？」という悩みを解く仕組みとして、いまデザイン界隈で注目されているのが「デザインハーネス（Design Harness）」という考え方です。

1. デザインハーネスとは？「AI生成は並列、レビューは直列」の停滞を解く仕組み

デザインハーネスは、プロダクトデザイナーのこぎそ（@kgsi）氏が提唱した設計思想です。
AIエージェントにデザイン作業を任せるときに、その出力がチームのルールやブランドのトンマナから外れないよう、あらかじめ外枠で支えてあげる仕組みのことを言います。

2026年に入ってからはグッドパッチ社が支援ソリューションをスタートするなど、現場への導入が一気に現実味を帯びてきました。
この考え方が生まれた背景には、AIツールを導入したチームがほぼ確実にぶつかる「生成は並列、レビューは直列」というリアルな問題があります。

AIに指示を出すと、数十画面のUIやバリエーションがあっという間に並列で作られますよね。
でも、その画面の余白が合っているか、変な色が混ざっていないかをチェックするデザイナーの目は、画面の数だけ増えるわけではありません。

結局、デザイナーが1画面ずつ手作業で確認することになり、AIが速くなればなるほどレビュー待ちのタスクが山積みになってしまいます。
しかも「チームとして何をもってOKとするか」の基準が曖昧なままだと、レビューする人の好みで判断がブレてしまいがちです。

もともと「ハーネス（馬具）」というのは、力強い馬を人間がコントロールして、安全に目的地へ走らせるための道具です。
エンジニア界隈の「テストハーネス（テストを自動で回すための実行環境）」と同じで、パワフルなAIの出力を一定の枠組みで支える仕組みをイメージするとわかりやすいと思います。

AIに「適当にいい感じの画面を作って」と丸投げするのではなく、あらかじめ決めたルールと検証のレールを通すことで、おかしなデザインが出ないように先回りします。
自分自身も現場でAIツールを使うときは、自由気ままに作らせるより、カチッとした制約を渡した方が手戻りが圧倒的に少ないなと実感しています。

2. デザインハーネスを支える「4層構造モデル」

デザインハーネスは、何か特定の有料ツールを指すわけではありません。
AIの出力をうまくコントロールして、日々のデザイン運用に落とし込むための「4層の設計フレームワーク」として整理されています。

「AIにどんな情報を渡して、どうチェックして、どう改善していくか」という一連の流れを4つの階層に分けたものです。
それぞれのレイヤーが担う役割と具体的な要素をまとめると、以下のようになります。

まず土台となる第1層の「制約」は、AIが使っていい色やフォント、余白のサイズを最初から絞り込んでおく枠組みです。
デザインシステムに定義されていない謎のカラーコード（いわゆる野良カラー）が勝手に作られるのを、入口の段階でシャットアウトします。

続く第2層の「文脈」は、「この画面は誰がどんな状況で使うものか」という背景情報をAIに共有するレイヤーです。
ただ見た目のパーツを並べるだけでなく、前後の画面遷移やユーザーの目的をしっかり渡すことで、的外れなレイアウトが出てくるのを防ぎます。

そして第3層の「検証」では、AIが書き出したコードやFigmaデータに対して、自動テストや静的解析（lint）を走らせます。
「フォントサイズが基準値と合っているか」「コントラスト比が足りているか」といった機械的に白黒つけられる部分は、すべてここで自動判定します。

こうして機械的なチェックをパスした画面だけを、最後の第4層「評価」で人間のデザイナーが確認します。
「操作していて違和感がないか」「体験として気持ちいいか」という定性的な判断に集中し、気づいた改善点はまた第1層や第2層の指示にフィードバックしていきます。

3. Figmaとデザインシステムを「機械可読なハーネス」にする手順

「考え方はわかったけれど、実際の現場では何から手をつければいいの？」と思いますよね。
一番手軽でおすすめなのが、いまあるデザインシステムを「AIが読めるデータ形式」に整えることです。

人間向けに作った分厚いスタイルガイドを、AIエージェントがそのまま解釈できる形へ落とし込んでいきます。
現場ですぐに取り入れやすい3つのステップを見ていきましょう。

1. Figma Variablesでトークンをかっちり決める

最初の一歩は、Figma上のカラーや余白を「デザイントークン」として整理することです。
カラーコードを生でベタ打ちするのではなく、PrimaryやSurfaceといった役割ベースの変数名で管理します。

変数のルールが綺麗に整っていれば、AIに対しても「ボタンの色は --color-button-primary だけを使ってね」とシンプルに指示を出せます。
これだけで、AIが勝手なカラーコードをでっち上げるミスを一気に減らせます。

2. ルールファイル（DESIGN.md）をプロジェクトに置く

CursorやClaude Codeを使ってUIを組むときは、プロジェクトのルートフォルダに DESIGN.md というルールファイルを1枚置いておくのがおすすめです。
フォントサイズのスケールや余白の基本ルール（4px/8pxグリッドなど）を、簡潔なMarkdownでメモ書きしておきます。

AIエージェントはコードを書くときにこのファイルを自動で読み込んでくれるので、毎回プロンプトに細かな指示を書く手間が省けます。
指示文が短くて済む分、入力トークン数の節約になって生成スピードが上がるのも嬉しいポイントです。

配置場所に迷ったら、まずはプロジェクトのルート直下（./DESIGN.md）に置くのが基本ルールです。AIツールが作業開始時に一番認識しやすい場所だからです。
フロントエンドとバックエンドが分かれているリポジトリなら、フロントエンド側（apps/web/DESIGN.md や frontend/DESIGN.md）、またはコンポーネント管理フォルダ（packages/ui/DESIGN.md）に配置するのが実務上の定石です。
さらに、Claude Codeの CLAUDE.md や Cursorの .cursorrules の中に「UIの実装時は DESIGN.md のルールを参照すること」と1行メモを添えておくと、AIが確実にルールを優先して読み込んでくれます。

3. プラグインやテストで機械的に自動チェックする

画面が出来上がってきたら、Figmaプラグイン（Figma Linterなど）を使ってワンクリックでスタイル違反をスキャンします。
未登録のフォントや勝手な余白が使われていれば、その場ですぐにアラートを出して修正できます。

「1pxズレていないか」「スタイルが合っているか」を目を凝らして探す作業は、ツールに任せてしまえばいいんですよね。
機械でできるチェックを自動化するほど、デザイナーは「本当に使いやすいUIになっているか」という本質的な体験設計に時間を使えるようになります。

デザイントークンを破綻させずに運用するVariablesの設計ルールについては、こちらの記事で具体的な命名のコツをまとめています。

Figma Variables（変数）の使い方｜バリアント肥大化を防ぐ2層トークンと命名規則【2026】

FigmaのVariables（変数）を活用し、デザイントークンを破綻させずに管理・運用するための設計ルールと命名規則を解説します。

4. デザイナーの役割の変化：パーツの配置者から「ハーネス設計者」へ

デザインハーネスが浸透してくると、現場のデザイナーに求められる動き方も少しずつ変わっていきます。
これまで時間をかけていた「ボタンやテキストを1px単位で並べる作業」は、AIエージェントにどんどん任せられるようになっていきます。

その代わり、デザイナーの大事な役割になっていくのが、「AIが迷わずにクオリティの高いUIを作り続けられるよう、ハーネス（ルールシステム）を整えてあげること」です。
部屋の壁紙を自分で1枚ずつ貼る作業から、建物全体の設計図を引いて安全基準を決める建築家のような立ち位置にシフトしていく感覚に近いかもしれません。

実務では、特に次のような領域が大切になってくると感じています。

• トークンと変数のルール設計: 画面数が増えても破綻しない、すっきりとした変数構造を組み立てる。
• 品質の合格ラインの言語化: どんな状態ならチームとしてリリースOKなのか、判断ロジックを整理する。
• フィードバックによるルールの更新: AIが間違えた箇所を分析して、DESIGN.mdや指示文を微調整していく。

デザインエンジニアの台頭と、溶け合うデザインとコード

こうした流れの中で、国内外の現場でいま急速に数が増えているのが「デザインエンジニア（Design Engineer）」という職種です。

これまでは「Figmaで画面を作るデザイナー」と「それをコードに落とし込むエンジニア」で分業するのが当たり前でした。
しかし、AIツールがFigmaデータから直接コードを書き、コードからUI画面を一瞬で生成する時代になったことで、デザインと実装の境界線が一気に溶け合っています。

Figma Variablesなどのデザイントークンを理解しつつ、それをDESIGN.mdやコード側のLint・テスト（ハーネス）として落とし込める人材の需要が急増しているんですよね。
自分自身も現場で作業していて、「画面を作る作業そのもの」よりも「Figmaとコードの間でルールが破綻しないよう仕組みを整える役割」がどんどん重要になっているのを強く実感しています。

最初から完璧な仕組みを作る必要はないので、まずは普段よく使う余白やカラーのルール化から気軽に試してみるのがおすすめです。

まとめ：適切な制約が、AIとの共創をスケールさせる

デザインハーネスは、AIの自由を奪って窮屈にするためのルールではありません。
しっかりとした安全帯（制約）があるからこそ、AIは迷わずに素早く画面を作れますし、人間も安心してその出力をレビューできます。

「生成は一瞬、でも確認に追われて疲弊する」という悪循環を抜ける鍵は、レビューを人間の根性で乗り切るのではなく、仕組みで軽くしていくことです。
制約、文脈、検証、評価という4つの層を意識しながら、日々のデザインシステムをAI時代に合わせて少しずつ育てていきましょう。

まずはプロジェクトに小さな DESIGN.md を1枚置いてみる。そんな身近な一歩から、AIとの気持ちいいチームプレイを始めてみてくださいね。

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

デザインハーネスの土台となる「崩れないUI構造」や「OS標準のガイドライン」を把握しておくと、ルール作りの解像度がさらに上がります。
現場の実務ですぐに役立つ記事をピックアップしましたので、ぜひあわせてチェックしてみてください。

オートレイアウトを使った崩れないフレーム設計の手順は、こちらの記事でステップ順に詳しく解説しています。

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

Figmaのオートレイアウトを駆使し、崩れないネスト構造と整然とした余白設計を実現するための実践的な組み立て手順を解説します。

Appleが定めるOS標準のタップ領域や文字基準については、以下の実務ガイドで数値を整理しています。

Apple HIG実務ガイド｜タップ領域44pt・文字11pt基準とiOSの基本原則【2026】

AppleのHuman Interface Guidelines（HIG）が定めるタップ領域44ptや最小フォント基準など、iOSアプリ設計に必須の実務数値を網羅解説。

The post デザインハーネス入門｜AIのUI生成とレビュー停滞を解く4層構造【2026】 first appeared on デザペディア.

日々のUI制作で画面に向き合っていると、「なんとなく良さそうな青色を選んでみた」「いまっぽい角丸の数値にしてみた」と、自分の直感や感覚だけに頼って決めてしまう場面はないでしょうか。
デザインの意図をチームやエンジニアに説明する際、「なぜここはこの余白なのか」「なぜこの色なのか」という根拠が曖昧だと、レビューでの合意形成に時間がかかったり、手戻りが発生する原因になりがちです。

そんな「デザイン決定の根拠」をロジカルに整理する上で大きな助けになるのが、Googleが策定・公開しているオープンソースのデザインシステム「Material Design 3（M3）」です。
M3は単なるコンポーネントのカタログではなく、人間の知覚に基づいた配色ロジックや、アクセシビリティを仕組みで担保するトークン設計など、実務で今すぐ活かせる実践知見が体系化されています。

今回は、Material Design 3の基本思想から、配色迷子をなくす「HCT理論」、実務で破綻しないカラートークンの階層設計、そしてFigmaでの具体的な活用フローまでを分かりやすく整理しました。

1. Material Design 3（M3）とは？通常ルールとの決定的な違い

Material Design 3 – Google's Open Source Design System

Googleが提供するオープンソースデザインシステム。個人の嗜好に適応するダイナミックカラーやHCTカラースペース、最新のUIコンポーネント仕様を網羅。

Material Design（マテリアルデザイン）は、GoogleがAndroidやWeb向けに展開してきたデザインシステムです。
従来のMaterial Design（M2）は、「紙とインク」の物理法則を画面上に模倣し、影（Elevation / Drop Shadow）の高さによって要素の階層関係を伝えるアプローチが中心でした。

それに対して最新のM3では、「ユーザー個人の好みや利用環境に合わせて、デザイン側が柔軟に変化する」という思想へと大きく舵を切っています。
均一で固定された1枚のデザインカンプを作るのではなく、ユーザーごとに心地よい形へと適応させる「システムの柔軟性」を設計するスタンスが根本にあります。

Form follows feeling（形態は感情に従う）

近代デザインの有名な原則に「形態は機能に従う（Form follows function）」がありますが、M3が掲げるテーマは「形態は感情に従う（Form follows feeling）」です。
使いやすさや機能性は大前提とした上で、使う人が愛着を感じられるパーソナルな体験を重視しています。

その代表例が「ダイナミックカラー（Dynamic Color）」です。
ユーザーがスマートフォンの壁紙を変更すると、壁紙から抽出されたキーカラーをもとに、OSやアプリ全体の配色パレットが自動生成され、調和のとれた色合いへとシームレスに変化します。

このアプローチは単なる思いつきではなく、数千人規模のユーザー調査と認知心理学の実験を経て導き出された設計です。
固定的なビジュアルを押し付けるのではなく、ユーザーのコンテキストに寄り添うUI設計の思想は、自社サービスをデザインする際にも大きな示唆を与えてくれます。

Apple HIG vs Google M3 の設計思想の対比

UIデザインの現場で双璧をなすのが、AppleのHIG（Human Interface Guidelines）とGoogleのM3です。
どちらが優れているかという話ではなく、両者が目指す哲学の違いを理解しておくと、プラットフォームごとの適切なUI判断が下しやすくなります。

両者の思想を把握しておくことで、iOSとAndroidのマルチプラットフォーム展開時にも、それぞれのユーザーのメンタルモデルに沿った自然なデザインの出し分けが可能になります。

2. 配色の迷子をなくす「HCTカラースペース」とコントラストの科学

UIデザイナーが最も多くの時間を費やし、かつ迷いやすいのが「配色」の決定です。
「綺麗に見えるけれど文字が読みにくい」「ダークモードにしたらコントラストが崩れてしまった」という問題は、従来のカラーモデルの仕組みそのものに原因がありました。

その課題を根本から解決するためにGoogleが開発したのが、M3の基盤となる「HCTカラースペース」です。

従来のRGBやHSLが抱えていた限界

Web制作で広く使われてきたRGBやHSLは、コンピュータの画面表示にとって都合の良い数値モデルです。
しかし、人間の目は色相（Hue）によって明るさの感じ方が大きく異なるという特性を持っています。

例えば、HSLで同じ明度（Lightness 50%）に設定した場合でも、人間には「黄色」が非常に明るく見え、「青色」は暗く見えます。
そのため、HSLの数値を揃えるだけではアクセシビリティ（WCAGのコントラスト比）を担保できず、デザイナーが画面を見ながら手作業で微調整を繰り返す必要がありました。

HCT（Hue / Chroma / Tone）の仕組み

HCTは、人間の知覚モデル（CAM16）を組み込むことで、この「見え方のズレ」を解消した新しい色空間です。

• Hue（色相 / 0〜360）: 色味そのもの（赤、青、緑など）
• Chroma（彩度 / 0〜無制限）: 色の鮮やかさ。0は無彩色（グレー）
• Tone（トーン / 0〜100）: 人間の目が知覚する明るさ（輝度）。0は純粋な黒、100は純粋な白

HCTの最大の特徴は、「色相が何色であっても、Toneの数値が同じなら人間が知覚する明るさが同一になる」という点です。
Tone 40の青も、Tone 40の黄色も、人間にとっては全く同じ明るさとして認識されます。

この仕組みのおかげで、「Toneの差がそのままコントラスト比になる」というシンプルな計算式が成立します。
例えば「背景がTone 90なら、文字にはTone 40以下の色を置く」というルールを守るだけで、どんな色相を選んでもWCAG 2.1のコントラスト基準（4.5:1以上）を自動的にクリアできます。

3. 実務で破綻しない「カラートークン（Roles）」の階層設計

HCT理論の優れた知見を日々のUI設計に落とし込むための仕組みが、M3の「カラートークン（Color Roles）」です。
M3では、生の色コード（#1E40AF など）をUIパーツに直接指定することを推奨していません。すべて「その色が果たす役割（Role）」として名前をつけて管理します。

主要カラートークンの役割と階層一覧

M3のカラーパレットは、UIの構成要素に合わせて明確なグループに分かれています。
実務で頻出する主要なトークンの役割は以下の通りです。

「Container」と「On-〜」の命名規則の読み解き方

M3の命名規則で最初に覚えるべき重要なパターンが、「Container」と「On-〜」の接頭辞・接尾辞です。

• 単体名（例: Primary）: 最もコントラストが高く目立つ塗り。メインボタンなどに使用。
• Container（例: Primary Container）: 明るい淡いトーン（ダークモードでは適度に沈んだトーン）の面。視覚的な圧迫感を抑えつつグルーピングしたい領域に使用。
• On-〜（例: On-Primary, On-Surface）: 「その面の上に載せる色（On top of）」を意味する。背景のトーンに応じた視認性の高い文字色やアイコン色を指す。

「Primaryの上にはOn-Primaryを載せる」「Surfaceの上にはOn-Surfaceを載せる」という組み合わせルールが名前自体に組み込まれているため、デザイナーもエンジニアも迷うことなくコントラストを担保できます。
この設計思想は、自社サービスで独自のデザイントークンを組む際にもそのまま流用できる強力なフレームワークです。

4. Figma実務でM3を取り入れる3つのステップ

M3の設計思想やトークン構造を、日々のFigma作業で効率的に活用するための3つの実践ステップを紹介します。
複雑な計算を手動で行う必要はなく、公式ツールを賢く組み合わせることで素早く高品質な基盤を整えられます。

Step 1: 公式プラグイン「Material Theme Builder」でトークンを一括生成

Google公式がFigma向けに無償提供しているプラグイン「Material Theme Builder」を使用します。
プラグインを開き、ブランドの核となるキーカラー（Primary Color）を1色指定するだけで、HCT理論に基づいて計算されたLightモードおよびDarkモードのフルカラーパレットが一瞬で生成されます。

SecondaryやTertiaryも自動で調和する補色が提案されますが、ブランドガイドラインに合わせて個別にキーカラーを上書き指定することも可能です。
コントラスト計算に頭を悩ませる作業をツールに任せ、デザイナーはUI全体の情報設計に集中できます。

Step 2: Figma Variablesにトークンをマッピングする

Material Theme Builderで生成されたカラートークンは、Figmaの標準機能である「Variables（変数）」としてそのままファイル内に登録されます。
コレクション内に「Light」列と「Dark」列が自動生成され、color/primary や color/surface といったセマンティックな変数名で管理されます。

フレームのFillやテキストのカラーに変数を割り当てておけば、親フレームのModeを「Dark」に切り替えるだけで、画面全体のカラーが適切なコントラストを保ったまま一瞬で反転表示されます。
ライト版とダーク版のカンプを2重管理する手間がなくなります。

Step 3: 公式「Material 3 Design Kit」からレイヤー構造をリバースエンジニアリングする

Figma Communityで公式配布されている「Material 3 Design Kit」は、公式チームの手によるコンポーネント構造の実践的なお手本です。
ボタン、カード、トップアプリバー、ダイアログなど、すべてのUIコンポーネントが最新のAuto LayoutとVariablesで精緻に組み上げられています。

Material 3 Design Kit – Figma Community

Google公式提供のMaterial Design 3 UIキット。最新のAuto Layout、カラートークン、コンポーネント構造をFigma上で直接複製・参照可能。

自分自身も、新しいUIパーツの余白設計やネスト階層で迷った際は、このM3 Design Kitを開いて「Googleのチームはここをどう組んでいるのか」を必ず確認するようにしています。
公式データのレイヤー階層を分解して観察するだけでも、プロの構造設計ルールが自然と身につきます。

5. 動き（Motion）に物理法則を取り入れるスプリングアニメーション

UIの触り心地や操作感を決定づけるのが「動き（Motion / Micro-interactions）」です。
ボタンを押したときや画面が遷移するとき、どこか機械的で味気なく感じてしまう原因の多くは、等速（Linear）で動いて急停止するなど、自然界の物理法則を無視している点にあります。

M3では、アニメーションに「スプリング（バネ力学）」の考え方を全面的に取り入れています。
「0.3秒で移動する」という時間（Duration）指定ではなく、物体の「重みや反発」という質感で動きを表現するアプローチです。

• Stiffness（剛性 / バネの硬さ）: 数値が高いほどキビキビと素早く反応し、低いほどゆったりと追従する。
• Damping（減衰 / 摩擦の強さ）: 数値が低いとボヨンとバウンドし、高いと揺れずにスーッと静かに収束する。

例えば、成功トースト通知や重要なバッジは少しバウンドさせて視線を集め、設定シートのスライド表示は減衰を高めて滑らかに定位置へ収める、といった調整を行います。
指先のタップ操作に対して自然な手応えを返す配慮が、プロダクトへの心地よさと信頼感を高めてくれます。

6. Material Design 3に関するよくある質問（FAQ）

M3の導入や学習を進める中で、現場のデザイナーからよく寄せられる疑問とその回答をまとめました。

• Q. WebサイトやiOSアプリのUI設計でもM3の考え方は活用できますか？
  十分に活用できます。ダイナミックカラー自体はAndroid OS独自の機能ですが、HCT理論によるアクセシブルな配色ルールや、Surface/Containerによるカラートークン構造、スプリング力学などは、プラットフォームを問わずWebやiOSのプロダクト設計にもそのまま応用できる普遍的な知見です。
• Q. ダイナミックカラーはすべてのプロダクトで導入すべきですか？
  いいえ、必須ではありません。強いコーポレートカラーやブランドの世界観を厳密に固定したいプロダクト（金融、BtoB SaaS、特定ブランドアプリなど）では、あえて壁紙連動のダイナミックカラーを採用せず、ブランド固定のPrimaryトークンを運用するのが実務上一般的です。
• Q. M3のトークン数が多すぎてチームで管理しきれない場合はどうすればいいですか？
  最初から全トークンを網羅する必要はありません。まずは「Primary」「Surface」「On-Surface」「Background」「Error」の主要5系統に絞ってスモールスタートし、運用しながら必要に応じてContainerやTertiaryを段階的に増やしていく運用をおすすめします。

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

M3のカラートークン設計をチームで破綻させずに運用するためには、FigmaのVariables機能とオートレイアウトの基礎を押さえておくことが不可欠です。

トークンの2層構造（PrimitiveとSemantic）やライブラリの非公開化など、実務で迷わない変数設計ルールは以下の記事で詳しく解説しています。

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

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

コンポーネント内の要素間余白やPaddingを崩さずに組むオートレイアウトのネスト設計手法については、こちらの解説記事を参考にしてください。

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

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

設計したトークンや余白をエンジニアへ手戻りなく引き渡すためのDev Mode活用法については、以下の記事で体系的に整理しています。

Figma Dev Mode（開発モード）の使い方と料金体系｜できること・できないことと実装連携【2026】

Figma Dev Modeで何ができて何ができないのか、有料シートの料金体系やVS Code連携、差分比較（Diff）による手戻り防止フローを徹底解説。

まとめ：デザインの「感覚」を強固な「ロジック」に変える

Material Design 3は、単なるGoogle専用のデザインガイドラインではありません。
アクセシビリティを担保しながら、デザインの意思決定に確かな根拠を与えるための優れた設計思想です。

• HCTカラースペースを理解し、Toneの数値差によってアクセシビリティを自動担保する
• Hex値の直打ちをやめ、Primary / Surface / Containerなどの役割（Role）でトークンを管理する
• Material Theme Builderと公式Design Kitを活用し、Figma実務での設計精度を高める

まずは次の案件から、主要なカラーを「役割」で定義してみたり、公式のDesign Kitを覗いてみることから始めてみてください。
「なんとなく決めた色や余白」に論理的な説明がつくようになるだけで、チームとの合意形成がぐっとスムーズになります。

The post Material Design 3（M3）入門ガイド｜カラートークン設計とFigma実務活用【2026】 first appeared on デザペディア.