再利用可能なUIコンポーネント：命名、バリアント、レイアウトルール

ビジュアルビルダーで画面の一貫性が崩れる理由

ビジュアルビルダーは画面を素早く出せるようにします。その速さが、UIの見た目や挙動のゆっくりとしたずれを隠してしまうことがあります。複数人が同時に作業すると、小さな選択の差が積み重なります。ある人はパディングを12pxにし、別の人は16pxにし、さらに別の人は古い画面からボタンをコピーします。

初期には症状が目に付きやすいです：ほぼ同じコンポーネントがいくつもある、画面間でスペーシングがずれる、同じ操作に対して微妙に違う言葉が使われる（保存、送信、確認）など。状態も分岐しがちです。あるフォームは読み込み状態を明示するが、別のフォームはしない。エラーメッセージがばらつき、“とりあえずの修正”が一方のページに残り、共有パターンには戻されないことがあります。

こうしてUI負債が始まります。それぞれの不一致は小さいように見えても、時間とともに製品の信頼性を損ない、正しいバージョンを探したり画面を比較したり、レビューの後で微細な差分を直す作業が増えてチームの速度を落とします。

ビジュアルビルダー内のコンポーネントライブラリは、ボタン、フィールド、カード、ヘッダー、空の状態などの共通部品を共有し、毎回作り直す代わりに皆がそこから引っ張って使う仕組みです。AppMasterのようなプラットフォームでは、ビジュアルUIビルダー内に再利用可能なUIパーツを作り、命名、設定、配置のルールに合意しておくことで、異なる人が作っても画面が一貫するようにできます。

目的はクリエイティビティを奪うことではなく、日常的な部分を予測可能にして選択を意図的にすることです。ずれを防ぐ4つのレバーは、明確な命名、妥当なバリアント、基本的なレイアウトルール（間隔、揃え、グリッド）、そしてライブラリを健全に保つチーム習慣です。

何をコンポーネント化すべきか（すべきでないもの）

すべての見た目の良い要素がコンポーネント化に値するわけではありません。何でもコンポーネントにすると、ライブラリの中を探し回り、存在すべきでないオプションをいじる時間が増えます。

良い再利用可能コンポーネントとは、多くの画面で繰り返し使われるもの、または毎回同じ見た目と挙動である必要があるものです。ユーザーがすぐに認識するパターンを考えてください：プライマリボタン、ヘルプテキスト付きのテキスト入力、レコードをプレビューするカードなど。

小さな初期セットでほとんどの画面をカバーできます：ボタン、入力、カード、ページヘッダー、確認・フォームの2種類くらいのモーダル。

実務的な抽出ルールは決断を簡単にします：同じUIを2〜3回使っているか、ブランド上重要で毎回同一である必要があるなら抽出する。一度しか出ないものはローカルに置きましょう。

一度きりにすべきものは、特定画面に紐づいた高度に固有なレイアウト、毎日変更する実験的なセクション、主にコンテンツであるものです。例えば、カスタム文言とイラストが入った一度きりのオンボーディングバナーはコンポーネント化する価値が低いことが多いです。

各コンポーネントは焦点を絞ってください。一つのコンポーネントは一つの仕事をするべきです。権限、請求状態、管理アクションまで扱う“User Card”は再利用しにくくなります。表示に集中した“User Card”と、別のアクションボタンやステータスチップに分ける方がクリーンです。

圧力下でも読みやすい命名規則

チームが速く出すとき、名前が最初に崩れます。誰かが “Button2” を複製し、別の人が “CTA Button” を作り、さらに別の人が “BlueButton” を作る。1週間後にはどれを使うべきかわからず、新たに作られてしまう——それが重複の山の始まりです。

疲れているときでも一貫性を保てるシンプルなパターンが役立ちます：Component - Part - State。ほとんどのコンポーネントはすべての要素を必要としませんが、順序は統一しておきます。

チームが実際に使う言葉を用いましょう。チームが“Customer card”と言うなら“CRM Tile”と名付けないでください。プロダクトが“Plan”と呼ぶなら“SubscriptionBox”にしないでください。プレーンな言葉は検索しやすいので勝ちます。

一つのルールが多くの混乱を防ぎます：見た目（ビジュアル）と用途（目的）を同じレイヤーで混ぜないこと。用途で命名するなら色名は避け、見た目で命名するならビジネス意味は避けます。一般的には用途ベースの命名の方がスケールしやすいです。

一覧で見やすい例：

• Button - Primary
• Button - Secondary - Disabled
• Input - WithLabel
• Card - Compact
• Modal - ConfirmDelete

フォーマットを一度決めて文書化しましょう：Title Caseかsentence caseか、ハイフンの前後にスペースを入れるか、略語は普遍的なものだけにする（例: “URL”）。多くの人が寄稿する環境では、こうした小さな選択がリストの可読性を保つのに重要です。

バリアント：選択肢を出して混乱を作らない方法

バリアントは、一つのコンポーネントを多くの場所で再利用できるようにします。コツは、どの差分が重要かを事前に決め、その他はロックすることです。

まず現実的なニーズをカバーする少数のバリアント次元を設定します。多くのコンポーネントでは三つで十分です：サイズ（S/M/L）、意図（primary/secondary/danger）、状態（default/hover/active）。新しいオプションがこれらに当てはまらない場合は、“もう一つのバリアント”ではなく新しいコンポーネントとして扱います。

デフォルトは思ったより重要です。誰かがコンポーネントをドラッグして何も変更しなかったときに、新しい画面が正しく見えるように安全なデフォルト（例: size=M, intent=primary, state=default）を設定します。

バリアントのあるコンポーネントごとに記録して厳守しましょう：

• サポートする次元と許容値（短く保つ）
• デフォルト値
• バリアント間で絶対に変わらないもの（パディング、フォント、角丸、アイコンの間隔）
• 無効や読み込みのような必須状態、失敗があり得る場合はエラーも
• 新しいバリアントを作るべきでない場合（新しいコンポーネントにする基準）

例：カスタマーポータルに“Submit”ボタンがあるとします。ある人が“Wide Submit Button”を作り、別の人が“Rounded Submit Button”を作るとすぐにずれが生じます。ルールがあればボタンは一つに保てます。サイズと意図は許可し、カスタムパディングや角丸は禁止し、“Loading”は一度だけ定義（スピナーを表示してクリックを無効にする）してどこでも同じ振る舞いにします。

「もう一つだけスタイルを」と頼まれたら、その要望がどんなユーザ課題を解くのか尋ねてください。答えが明確でなければ、それは混乱のもとである可能性が高いです。

レイアウトルール：みんなが従う間隔、揃え、グリッド

レイアウトルールがあいまいだと、すべての画面が徐々に一度きりのものになります。コンポーネントを一貫させる最速の方法は、間隔と揃えを「退屈」にすること：許可された選択肢を少数にして、毎回同じように使わせます。

間隔スケールを決めてそれ以外を禁止しましょう。小さなセットを選び（例えば 4, 8, 12, 16, 24）鍵盤のように扱います：その鍵だけで多くの曲が弾けます。誰かが“18px”を要求するなら、多くの場合コンポーネントかグリッドがずれているサインです。

間隔が何を意味するかを明確にします：

• パディングはコンポーネント内側にあり、画面間で一貫します。
• gap はコンテナ内のアイテム間（フォーム行、ツールバーの項目）です。
• マージンはコンポーネントの外側で、使いすぎないようにします。
• コンポーネント同士の間隔はスタックしたマージンではなく gap を優先して、重ねて倍になるのを防ぎます。

揃えルールは「ちょっとずらす」編集を減らします。シンプルなデフォルトで十分です：テキストは左揃え、ラベルと入力は同じ垂直線に並べ、プライマリのアクションは一貫させる（例：モーダルは右下、フォームフッターは右揃え）。文字の多い行はベースライン揃えを使い、アイコンだけの行は中央揃えを使うと良いでしょう。

グリッドは派手である必要はありませんが、存在は必要です。カラムとガターを決め、小さい画面でどうなるかを定義します（例えばデスクトップは12カラム、モバイルは単一カラム）。コンテナ幅とブレークポイントを一度決め、それらのレール内で画面を作ります。

よくある落とし穴：パディングを追加するネストしたコンテナ、ページごとに違うマージン、固定幅とレスポンシブカラムの混在、そしてその画面だけを直す“魔法の数値”です。

スタイルトークン：フォント、色、アクセシビリティの基本

スタイルトークンは皆が使う共通の選択肢です。トークンが明確なら、違う人が画面を作っても再利用可能なUIコンポーネントは一貫します。

まずタイポグラフィを唯一の真実の出所にします。フォントサイズ、ウェイト、行間の小さなスケールを選んで止めてください。多くのチームは数ステップで十分です（例：body, small, caption, title, page heading）。これらをひとつの場所にまとめておけば、新しいテキストも同じデフォルトから始められます。

色は塗料コードではなく意味で命名すると良いです。“Primary”は主要なアクションを示し、“Success”は成功、“Warning”は注意を促す。もしチームが既にパレットで考える習慣がなければ “blue-500” のような名前は避けます。

後で問題にならないためのアクセシビリティの基本：

• テキストは背景に対して十分なコントラストを確保する。
• タップターゲットはマウスのカーソルではなく親指向けの大きさにする。
• エラーメッセージは何が起きたかと次に何をすべきかを明示する。
• 状態を色だけで伝えない。

トークンはコンポーネントバリアントに直接結びつけます。例えば Button の Primary/Secondary/Danger は承認されたトークン（色、ボーダー、テキストスタイル）を切り替えるだけで、新たな一-off スタイルを導入しないようにします。

トークンは短く保ち、実際に使われる量にしておきます。良いテストは：誰かが5秒で正しいトークンを選べるかどうか。選べなければ統合するか削るべきです。

シンプルな初期セットの例：タイポグラフィ（text.body, text.small, text.title）、色（color.primary, color.success, color.warning, color.danger）、間隔（space.8, space.16, space.24）、角丸（radius.sm, radius.md）、フォーカス（focus.ring）。

ステップバイステップ：ビジュアルビルダーでコンポーネントライブラリを作る

コンポーネントライブラリは“デザインの完璧さ”よりも日々の小さな判断を減らすことが目的です。皆が同じビルディングブロックを選べば、異なる人が作っても画面は一貫します。

実用的な5ステップの導入

1. 既存の状況を監査する。実際の画面5〜10枚を選び、繰り返し出てくる重複（ボタン、テキスト入力、セクションヘッダー、カード、空状態）を記録します。
2. 最初に標準化する小さな波を選ぶ。どこでも出てきて不一致を最も引き起こす上位10個を目標にします。多くのチームではボタン、入力、ドロップダウン、モーダルダイアログ、テーブルヘッダー、カードが該当します。
3. 作る前にルールを書き出す。短く：コンポーネント名、使いどころ、許可されるバリアント、周囲のレイアウトルール（間隔、揃え、幅）。
4. 一度作り直し、徐々に置き換える。ビジュアルビルダーで新しいコンポーネントを作り、合意したバリアントをロックします。古いコピーは画面ごとに置き換え、一度にすべてをリファクタリングしようとしないでください。
5. 軽いレビューゲートを追加する。週替わりの1人が新しいコンポーネントやバリアントをチェックします。目的は取り締まりではなく、偶発的な派生を防ぐことです。

“十分に良い”状態とは

デザイナーやPMが「標準のカードの compact header を使って」と言えば、二人の実装者が同じ結果を出せるようになれば成功です。得られる効果は：ワンオフの選択が減る、微妙な不一致が減る、画面構築が速くなることです。

ライブラリは意図的に小さく保ってください。誰かが新しいバリアントを要求したらまず一つだけ尋ねます：本当に新しい必要性か、それとも既存のバリアントで中身を変えれば足りるか？

遅く、一貫性を欠くUIを生む一般的なミス

多くの不一致はセンスの問題ではなく、コピーが簡単で調整が速く、誰も戻って整理しないことから発生します。結果はほとんど同じ画面群で、更新が難しくなります。

よくある罠の一つは、バリアントを増やす代わりに近似コピーを作ることです。ある人が“少し背の高いプライマリボタン”を求めてコンポーネントを複製すると、別の人もまた複製します。すると3つの似たボタンが存在し、挙動が少しずつ違うため、修正が大変になります。

もう一つは過度に設定可能なコンポーネントです。設定が多いと柔軟に見えますが、予測不可能になります。人々は信頼しなくなり“この場合だけ”のバージョンを作り、それが問題を悪化させます。

レイアウトのミスも同じくらいダメージを与えます。最大の問題は責任の混在です：コンポーネントが外側のマージンを制御し、画面でもスペーシングを追加するとランダムな隙間が生まれます。簡単なルールで解決できます：コンポーネントは内部パディングを定義し、画面がコンポーネント間のスペースを管理します。

通常最初に現れる問題：命名ルールが乱れる、状態が後回しになる（loading, empty, error）、一度きりの調整が恒久化する、異なる人が同じレイアウトを別々に解決する、などです。

新しい画面ごとのクイック一貫性チェックリスト

何かを追加する前に60秒立ち止まって基本をチェックしてください。画面は見た目は問題なくても、システムを静かに壊すことがあります。そしてそれらの小さな壊れが並行して作業する複数人の間で急速に増えます。

• 命名: すべてのコンポーネントが合意したパターンに従っているか（例: Form/Input, Form/Input.HelperText, Table/RowActions）。検索してすぐ置けない名前なら今すぐリネーム。
• オーナー＋用途: 共有コンポーネントにはオーナー（個人またはチーム）と、いつ使うかの一文説明があること。
• 間隔スケールのみ: すべてのパディング、gap、マージンが承認された間隔ステップを使っているか。新しい数値を打ち込んで“見た目が良いから”としない。
• 状態を含む: 主要なインタラクティブ要素には読み込みやエラー状態を含める（ハッピーパスだけでなく）。無効化されたボタン、入力のエラー、空リスト、リトライなど。
• 新しいスタイルは作らない: 既存のトークンとコンポーネントで画面を作る。新しい色、フォントサイズ、角丸、シャドウが必要なら画面レベルの修正ではなくシステムリクエストとして扱う。

例：ルールなしとルールありで同じ機能を二人が作ると

MayaとLeonはカスタマーサポートチームで、チケット一覧（スキャン用）とチケット詳細（操作用）という二つの画面を作る必要があります。作業を分担してビジュアルビルダーで構築しました。

ルールがないと、それぞれが“カード”を別々に作ります。Mayaは薄いボーダーとシャドウのある白いカードを使い、Leonはボーダーなしで余分なパディングのあるグレーのカードを使います。片方の画面は丸みのあるプライマリボタン、もう片方は四角いボタンとテキストリンク。ステータスは片方が色付きドット、もう片方がピル型。詳細ページではラベル幅が揃っておらずフィールドがずれてフォーム全体が落ち着かなく見えます。

レビューはスタイルの議論になり、単純な更新（たとえば “Priority” を追加する）は複数のワンオフレイアウトに手を入れる必要が出ます。

ルールがあれば、彼らは共有の再利用コンポーネントから出発します：構造と間隔のための TicketCard、スタイルとコントラストのための StatusBadge、一貫した主要アクションのための ActionBar。

一覧画面は compact な TicketCard バリアントを使い、詳細画面は説明やタイムライン、追加フィールドのための詳細バリアントを使います。構造は同じで、バリアントが何を表示するかをコントロールします。

見えない部分が最も良い点です：レビューコメントが減り、「なぜ違うの？」という質問が減り、将来の更新も速くなります。チームが“Closed”を“Resolved”に名前を変え、色を調整する必要が出ても、StatusBadge を一度変更すれば両方の画面が同時に更新されます。

時間を経て一貫性を保つ方法（次のステップ）

一貫性は一度きりの設定では終わりません。より多くの人が画面を作ると“このページだけ”の選択が増え、ライブラリは徐々にずれていきます。

シンプルな変更プロセスがチームの動きを止めずに保守を可能にします：

• 提案：何を変えるか、なぜ変えるか（新コンポーネント、新バリアント、リネーム、廃止）
• レビュー：デザイナーやUIオーナーが命名、間隔ルール、アクセシビリティの基本をチェック
• 承認：明確なイエス／ノー、限定的な場合は短い注記を付ける
• リリース：共有ライブラリを更新し、ひとつの場所で変更を告知する

決定には帰る場所が必要です。短い“UIルール”ドキュメントで十分で、命名規則、公式バリアントリスト（何があるか、何がないか）、およびやってはいけないこと（例：「異なるパディングの ‘Primary Button’ を二つ作らない」）を含めてください。

月次のクリーンアップ枠を予定しましょう。重複を統合し、未使用のパーツを削除し、古いコンポーネントを非推奨にマークして誤って取られないようにします。

同じパターンが2回見られたらリファクタの合図です（たとえば二つのチームがわずかに異なる空状態を作っている）。一度きりで本当にユニークで時間的制約があり再現しないものはワンオフのままで構いません。

AppMasterで作っているなら、実用的な次の一歩はまず一つのワークフロー（“Create ticket” や “Checkout” など）を標準化することです。UIビルダーは同じコンポーネントを画面間で共有しやすく、appmaster.io はノーコードでありながらページレイアウト以上の実アプリをサポートする参考になります。