はじめに
こんにちは。レコチョクの河野です。
この記事は、社内で実施したデザインシステム勉強会の内容を記事化したシリーズの第3弾です。デザイントークン編ではColor・Typography・Dimensionのトークン設計を、命名管理・OOUI編では画面やコンポーネントの命名ルールとオブジェクトモデリングの手法を紹介しました。
最終回となるこの記事では、Figma上でチームとの連携やデザインデータを管理するうえで実践してきたTipsを抜粋して紹介します。個別のTipsは地味に見えるものの、チームの認識が揃いやすくし、日々の制作効率と品質に直結するような大切な取り組みだと考えています。
UI Stack ── UIの5つの状態を管理する
UIの制作でよく見落とされがちなのが「画面の状態パターン」です。データが0件のときの表示を考えていなかった、ローディング中の表示を誰も定義していなかったという事態は、制作の現場ではよく起こります。
この課題に対して、Saunaでは UI Stack という概念を導入しています。Scott Hurffが提唱したフレームワークで、UIが取りうる状態を次の5つに分類します。
| 状態 | 説明 | 例 |
|---|---|---|
| Ideal | データが正常に揃っている状態 | 楽曲が10件表示されている |
| Partial | データが一部のみ存在する状態 | プロフィール画像が未設定 |
| Empty | データが0件の状態 | 検索結果なし |
| Error | 何らかの異常が発生した状態 | 通信エラー |
| Loading | データ取得中の状態 | スケルトンスクリーン表示 |
こうすることで、要件定義時やFigmaのデザインデータを制作するときに「この画面の5つの状態はすべて考えたか？」という基準で画面がもつ状態を洗い出すことができます。
実務では命名管理・OOUI編の要領で整理した画面名を元に、次のようにスプレッドシート上にテキストとして考えうる状態を書き出して、チーム間で認識を揃えたりしています。
こうすることで画面制作の作業前に認識を揃えられるため、余計なコスト投資を抑えることができます。
UI StackとVRT
UI Stackで画面状態の認識を統一すると、要件定義や制作以外の領域でも応用が利きます。実際に取り組んだ例がVRT（Visual Regression Testing）のテストシナリオの洗い出しです。
VRTとは、正解画像と変更後の画像をピクセル単位で比較し、意図しない差分を検出する手法です。テストを実行するにはまずシナリオの洗い出しが必要になりますが、ここでUI Stackが基準として機能しました。
具体的には、ユーザーのログイン状態とUI Stackの5状態を掛け合わせて場合分けし、それぞれの組み合わせでスナップショットを撮影・管理するという運用をしていました。
画面名が統一されているので「この画面がこの状態ならこの正解画像」というマッピングが一意に決まり、VRTレポートの自動生成まで繋げることができました。
状態の網羅をデザイン段階で担保しておくと、QAの抜け漏れも減ります。実際にEggsでもUI Stackを整備してからは「この状態のUIが定義されていないので追加してほしい」という差し戻しが減ったというフィードバックをエンジニアから多くありました。
デザインデータをエンジニアにとって使いやすくするために
デザインデータはデザイナーのためだけのものではありません。エンジニアが実装するための仕様書でもあります。このトピックは参加者向けの事前アンケートでも関心が高く、「デザインデータをどのようにエンジニアへ渡しているか」「使いやすくするために意識していることが知りたい」といった声が多数寄せられていました。そうした背景も踏まえ、この観点で意識しているTipsをいくつか紹介します。
AutoLayoutを丁寧に使う
FigmaのAutoLayoutの活用はエンジニアとの連携において非常に重要な要素です。AutoLayoutはCSSのFlexboxやSwiftUIのVStack / HStackに近い概念です。これを適切に適用したコンポーネントは、エンジニアがDev Modeで確認した際にレイアウト意図が明確に伝わります。
逆に、固定座標で配置されたコンポーネントだと、「このマージンは何の意図？」「この絶対値指定は正しい？」といった疑問がエンジニア側で発生します。
AutoLayoutを適用しているかどうかで、エンジニアがDev Modeでデザインデータを見たときの分かりやすさ・実装のしやすさが大きく変わります。AutoLayoutが適切に組まれていれば、余白やパディング、配置意図といった情報が一目瞭然で、実装時の再現性も高くなります。一方、AutoLayoutが適用されていない場合「なぜこの位置に要素があるのか？」「この隙間はどこで指定しているのか？」といった疑問が生まれ、コーディング時に手戻りや確認コストが発生します。
勉強会では、デザインデータのレビューを支援するツールが充実してきている点にも触れました。社内ではFigmaのデザインデータを自動チェックする自作プラグインを開発・運用しています。fills・strokes・spacingsなどのプロパティが正しくVariablesにバインドされているかを一括で検証できる仕組みです。また、Figma公式の Check Design 機能も登場しました（What's new from Schema 2025 – Figma Learn）。デザインレイヤーが正しいスタイルや変数を使っているかを自動で監査し、不整合の検出と一括修正ができます。
こうしたツールが揃ってきたことで、AutoLayoutやVariablesを丁寧に適用しておくことの価値がさらに高まっています。データの構造がそのまま実装の正確さやスピードに直結するため、日頃から原則を守ってデザインデータを整備しておくことが重要です。
Variablesを使う
デザイントークン編で紹介したFigma Variablesを適切にバインドしておくと、Dev Modeで Semantic/Action/destructive のように定数名が表示されます。16進数のカラーコードをエンジニアに解読させるより格段にわかりやすくなります。
Dev Mode MCPの可能性
最近登場したFigma Dev Mode MCPは、AIがFigmaのデザインデータを直接読み取って実装コードを生成する仕組みです。AutoLayoutが丁寧に組まれ、Variablesが適切にバインドされたデータほどAIの出力品質が上がるという検証結果も報告されています。
引用：Figma MCPを活かすためのデータ作りとプロンプト 20パターンの検証で分かったこと
また、実況チャンネルでは「2月中旬ごろにClaudeとFigmaの連携が強化されてMCP経由で色々できるようになったりしたので、もっと楽になれそうな予感あり」という期待の声がありました。これはFigmaとAnthropicが発表した Code to Canvas 機能を指しています。Claude Codeで生成したUIを編集可能なFigmaフレームとして直接取り込める仕組みです（From Claude Code to Figma – Figma Blog）。
一方で、AutoLayout/Variablesが整備されていないデザインデータだと、AIが読み取るコンテキストの質が下がり、出力されるコードもそれなりになります。冒頭から繰り返している「デザインシステムを丁寧に整備することが、AIとのコラボレーションの前提条件になる」というメッセージは、ここにも直結しています。
アノテーションとコメントの使い分け
デザインデータ上に補足情報を残す方法として、 アノテーション と コメント の2つを使い分けています。
| 手段 | 用途 | 特徴 |
|---|---|---|
| アノテーション | 仕様上の意図や制約を記録 | フレームに固定される |
| コメント | レビューやQ&Aなど対話的なやりとり | 解決したら非表示にできる |
アノテーションは「この要素はタップ後に0.3秒のディレイがある」「このリストは最大50件まで表示」のような仕様をフレーム上へ残す用途で使っています。コメントはデザインレビューやフィードバックなど、解決したら消えてよいやりとりに使います。
以前はコメントへ仕様を書いてしまい、解決済みにした後で「あの仕様どこに書いてあったっけ？」と困ることがありました。情報の永続性によって使い分けるルールを導入してからは、この混乱がなくなりました。
デザイン制作を他のメンバーに委譲して気づいたこと
Eggsでは、デザイントークンやコンポーネント設計が終わった後に一部の画面デザインをアプリのエンジニアに委譲する運用を試みました。Figmaの操作経験は浅い状態からのスタートです。
この時、委譲を受けたエンジニアからは「ルールが明文化されていて作業しやすかった」「AutoLayoutやVariablesが整備されていると判断に迷わない」といった前向きなフィードバックがありました。一方で「Figmaの操作やプラグインの使い方に最初は戸惑った」という声もあり、ツール操作へのハードルも見えました。
こうした経験から、UIデザイン制作に慣れていないメンバーでも一定のクオリティを保てるよう、設計の型化や基本ガイドの整備が重要だと感じました。加えて、ノウハウを持つメンバーが知見やTipsを積極的に共有していく仕組みづくりも欠かせません。
逆にどんな納品だったら作りやすい？
実況チャンネルでは、「逆にどんな納品だったら作りやすいですかとか言われて困った記憶があります。どう言えばよかったのか今でも悩む」というエンジニア視点のコメントもありました。
デザイナーからエンジニアへの「納品」という観点では、先述のAutoLayout・Variables・アノテーションの整備が基本です。加えて「不明点はコメントで聞いてほしい」「Masterページだけを見ればよい」というルールを伝えるだけでもだいぶ楽になるはずです。正解が1つあるわけではなく、チームごとに認識合わせを繰り返しながら最適解を探っていくのがチーム全体で改善していくという観点でも重要です。
まとめ
この記事で紹介したFigma運用Tipsは、1つ1つは地味な施策です。ただ、これらが積み重なることで「Figmaのデザインデータを見れば、誰でも迷わずに作業できる」という状態が実現します。
勉強会の実況チャンネルを通じて、他チームの運用事例やエンジニア視点のフィードバックを数多くいただきました。チームや組織の事情に応じて正解は変わりますが、「関わる人の迷いを減らす」という目的意識はどのチームにも共通して当てはまるはずです。
3記事にわたるシリーズを読んでいただきありがとうございました。デザインシステムの構築や運用で悩んでいる方の参考になれば幸いです。
参考資料
- UI Stack（Scott Hurff）
- その状態のデザイン考えてなかった！ UI Stackってナニ（note）
- Figma MCPを活かすためのデータ作りとプロンプト 20パターンの検証で分かったこと
- From Claude Code to Figma – Figma Blog
この記事は RecoChoku Engineering Blog の記事を転載したものとなります。