【実務・中級編】Sketchの「Smart Components」応用編：複雑なネスト構造を持つUIでのサイズ可変エラーを防ぐ厳格なルール設計 – UI/UX・デザインツール活用バイブル

Sketch「Smart Components」応用編：複雑なネスト構造のUI崩壊を防ぐ、厳格なサイズ可変ルール設計

プロダクトがスケールし、デザインシステムが肥大化していくにつれて、避けて通れない問題がある。それは、「ネストされたシンボルのレイアウト崩れ」だ。

親コンポーネントのテキストを一行増やしただけで、内部の子コンポーネントが不自然に引き伸ばされたり、パディングが消滅したり、要素が重なり合ったりする。デザインの修正にエンジニアとデザイナーが何時間も費やす――そんな不毛な開発サイクルの犠牲になっていないだろうか？

私はこれまで数々の大規模プロダクトのデザインシステム構築をリードしてきたが、Sketchの「Smart Layout」と「Nested Symbols」の挙動の本質を理解していないチームは、例外なくこの泥沼にハマる。

今回は、複雑なネスト構造を持つUIであっても「絶対にサイズ可変エラーを起こさない」ための厳格なルール設計と、チームの生産性を限界突破させる実践的テクニックを伝授する。

—

1. なぜレイアウトは崩壊するのか？（根本原因の特定）

Smart Layout（水平・垂直方向の自動リフロー）は強力だが、「親のレイアウト方向」と「子の制約（Constraints）」が矛盾した瞬間、レイアウトエンジンはパニックを起こす。

よくあるアンチパターンは以下の通りだ：

方向性のミスマッチ: 水平方向（Horizontal）に伸びる親シンボルの中に、固定幅を無視する垂直方向（Vertical）の可変シンボルを直置きしている。
パディングの汚染: ネストの深さ（Deep Nesting）が3層を超えたあたりで、Auto-width / Fixed-width の継承が途絶え、絶対座標（Absolute Positioning）的な挙動にフォールバックする。
オーバーライドの呪縛: デザイナーがインスタンス側でテキストを無理やり長文化させ、オーバーライドの制限を超えたレイアウト再計算を引き起こす。

これらを防ぐには、「コンポーネントの物理法則」を定義し、チーム全体で共有しなければならない。

—

2. 破綻しないネスト構造を作るための「3つの鉄則」

鉄則 1: 「方向の単一性（Directional Purity）」を徹底する

親から子へ流れるレイアウトの方向は、一貫していなければならない。

水平スタック（例: テーブルの行、カードのアクションボタン群）の内部では、子要素も水平方向のSmart Layout、または固定幅を持つべきである。
垂直スタック（例: フォームフィールド、カード全体）の中に水平スタックを内包する場合は、内包された水平スタックを必ず独立した「アトム（Atom）」レベルのシンボルとして切り出すこと。

鉄則 2: 「Fixed（固定）」と「Wrap Content（可変）」の境界線を明確にする

Sketchのレイアウトエンジンに正しい計算をさせるためには、各レイヤーのサイズタイプを厳密に指定する必要がある。

テキストレイヤー: 基本は `Auto`。ただし、マルチ行のカードタイトルなどでは最大幅（Max-width）の概念を親のコンテナ側で担保する。
背景/ベース・コンテナ: 背景のシェイプは絶対に直接サイズ変更させず、Smart Layoutを持つグループ（Stack）の背景として自動追従させる（Background Colorの活用）。

鉄則 3: ネストの深さは「最大3階層」に制限する

デザインシステムのアーキテクチャとして、以下の階層設計を強制する。
1. Level 1 (Atom): ボタン、アイコン、バッジ、単体テキスト（Smart Layout: None or 単一方向）
2. Level 2 (Molecule): リストアイテム、フォームグループ（Smart Layout: Horizontal / Vertical）
3. Level 3 (Organism): カード、モーダル、ナビゲーションバー（Moleculeを組み込んだ最終コンテナ）

これを超える階層が必要な場合、それはコンポーネントの設計が肥大化（God Component化）している証拠だ。分子レベルに分解し直すべきである。

—

3. 開発スピードを劇的に高めるキーボードショートカット

プロフェッショナルなUIエンジニア/デザイナーは、マウスをほぼ使わない。Sketchのレイアウト操作を指先の反射神経に焼き付けろ。

—

4. 導入必須：レイアウト崩壊を防ぐ「神プラグイン」

Sketch標準の機能だけでは、ヒューマンエラーを完全に防ぐことはできない。以下のプラグインをチーム全員の環境に強制インストールせよ。

1. Runner (by Bohemian Coding / 継承版)

用途: コマンドパレット型ランチャー。
なぜ神なのか: `Ctrl + ‘` で起動し、「Smart Layout」「Padding」「Symbol」などの操作をキーボードだけで完結できる。メニュー階層を探す無駄な時間がゼロになる。

2. Automate Sketch

用途: 複雑なレイヤー整理・一括処理の自動化。
なぜ神なのか: 大量のネストされたシンボルに対して、一括でSmart Layoutの向きやパディングを監査・修正するスクリプトを実行できる。チームのレビュープロセスにおいて、デザインの「構造的負債」を検出するのに必須。

—

5. チーム開発で絶対共有すべき「設定・ルール化」の作法

属人性を排除し、誰が触っても壊れないデザインシステムを維持するためのガバナンスルール。

1. 命名規則（Nomenclature）の厳格化

シンボル名には必ずレイアウト方向と挙動を含める。
例: `Component / Card / Vertical-Fixed` `Atom / Button / Horizontal-Auto`

2. デザインレビュー時の「ストレッチテスト」の義務化

新規コンポーネントをマージする前に、必ず「テキストを極端に長くする（例: 日本語で3行、英単語で30文字）」ストレッチテストを行い、レイアウトが破綻しないことを動画で記録してPRに添付する。

—

6. 実用的な設定・構造定義のベストプラクティス (JSON/YAML)

デザインシステムをコード（React / Vue / Flutter等）へシームレスにトランスレーションするため、またSketchのトークン管理としても、以下の構造化フォーマットをベースにした設計を推奨する。

以下は、厳格なサイズ可変ルールとネスト制約を定義した、デザインシステム・トークンのJSON構成例だ。

{
“$schema”: “https://json-schema.org/draft/2020-12/schema”,
“name”: “enterprise-design-system”,
“version”: “2.4.0”,
“layoutEngine”: {
“sketchSmartLayout”: {
“rules”: {
“maxNestingDepth”: 3,
“enforceDirectionalPurity”: true
},
“components”: [
{
“name”: “Organism/Card/Standard”,
“level”: 3,
“smartLayout”: “vertical”,
“padding”: {
“top”: 16,
“right”: 16,
“bottom”: 16,
“left”: 16
},
“spacing”: 12,
“children”: [
{
“name”: “Molecule/CardHeader”,
“level”: 2,
“smartLayout”: “horizontal”,
“alignment”: “space-between”,
“constraints”: {
“width”: “fill-container”,
“height”: “hug-contents”
}
},
{
“name”: “Atom/BodyText”,
“level”: 1,
“smartLayout”: “none”,
“constraints”: {
“width”: “fill-container”,
“height”: “auto”,
“maxLines”: 4
}
}
]
}
]
}
}
}

このJSON設計思想をデザイナー・エンジニア双方が共通言語として持つことで、「なぜこのレイアウトが崩れるのか」という議論がコードレビューやデザインレビューの場で一切不要になる。

—

エピローグ：プロダクトのスケールは構造の美しさに宿る

UIのレイアウト崩れは、単なる「見た目の不具合」ではない。それはチームの設計プロセスの欠陥の表れだ。

SketchのSmart Componentsを使いこなし、厳格なネストのルールと構造化された設計を取り入れることで、デザインとコードの乖離は消え去る。デザイナーはよりクリエイティブな課題解決に集中でき、エンジニアは迷うことなく高速に実装を進められる。

あなたのチームのデザインシステムを、今日から「壊れない要塞」へとアップデートしてほしい。