Figmaコンポーネントの使い方｜インスタンス・プロパティと変更管理

※本記事にはPRを含む場合があります。

こんにちは。『脱会社員』脱サラを応援し続けるブログ、運営者の『なかびー』です。

Figmaで同じボタンを何度もコピーしていると、「一か所直したのに、ほかの画面には古い形が残っていた」という状態になりがちです。コンポーネントは、繰り返し使う部品の元を決め、使う場所とつながりを持たせる仕組みです。ただ部品化するだけでなく、共通にしたい部分と個別に変えたい部分を分けると扱いやすくなります。

この記事では、ボタンを一つ作り、インスタンスを配置し、文言や状態を変え、最後に更新の影響を確かめる流れで説明します。最初から大規模なデザインシステムを作る必要はありません。架空の予約サービスを題材に、部品を使う側が迷わない設計と、変更が伝わらないときの確認方法まで整理します。

Figma Designの公式資料を2026年10月3日に確認しました。画面の位置や表示名は、言語設定や更新によって変わる場合があります。作成・編集には対象ファイルへの編集権限が必要です。本記事の課題と命名例は独自に作成した練習用で、図版は説明用の生成イメージです。実際のFigma画面を撮影した画像ではありません。

Figmaコンポーネントの基本｜元と使う側の関係を理解する

メインコンポーネントとインスタンスの役割

メインコンポーネントは、共通部品の基準になるものです。インスタンスは、その部品を画面の中で使うためのものです。元になる部品と使用箇所が結び付いているので、共通の見た目を変更するときに、同じ形を一つずつ探して直す手間を減らせます。

たとえば、予約ボタンをトップページ、料金ページ、紹介ページに使うとします。各ページで独立した四角形と文字を作ると、角丸や文字の大きさを変えるたびに三か所を直します。コンポーネントなら、共通ルールの変更を元へ集約し、それぞれの使用箇所で何が変わったかを確認する運用にできます。

ただし、インスタンス側で個別に上書きした値や、別ファイルのライブラリ更新なども関係します。「メインを変えれば、どんな変更でも全画面が無条件で同じになる」と理解すると混乱します。最初は同じファイル内で、何も上書きしていないインスタンスから試しましょう。

通常のコピーとの違いを一度体験する

練習では、普通の図形を二つ複製した場合と、コンポーネントからインスタンスを二つ配置した場合を並べてみます。元の塗りを変えたときに、どちらが連動するかを見ます。見た目が似ていても、更新のつながりが違うことを自分で説明できれば、第一段階は十分です。

アイコンの色だけを記憶するより、選んだものが何なのかを確認する癖を付けます。レイヤーパネル、選択時の情報、メインへ移動する操作などから、現在の対象が元なのか使用側なのかを判断します。見た目だけで決めると、別のメインを誤って編集することがあります。

Figma公式のコンポーネントガイドでは、再利用する要素と、メイン・インスタンスの関係が説明されています。本記事ではこの基本を使い、予約ボタンの変更管理という小さな課題に落とし込みます。

※表は横にスクロールできます。

オートレイアウトとコンポーネントを混同しない

オートレイアウトは、要素の並び方や余白、内容に応じた伸縮を扱う仕組みです。コンポーネントは、部品の再利用と共通ルールの管理を扱います。一つのボタンで両方を使えますが、目的は異なります。コンポーネントにしただけで、長い文字でも自然に広がるとは限りません。

まず普通のフレームで文字量に対応できるボタンを作り、その構造をコンポーネントにすると、問題の場所を分けやすくなります。長い文字ではみ出すなら配置や寸法の設計、共通の色が伝わらないなら上書きや参照先の関係を調べる、と考えられます。

学習の順序としては、「形を作る」「中身が変わっても崩れないか確認する」「繰り返し使う部品としてまとめる」の三段階がおすすめです。操作をまとめて覚えようとせず、今確認しているのが伸縮なのか再利用なのかを明確にしてください。

部品化する単位を小さく選ぶ

最初のコンポーネントには、ボタン、ラベル、入力欄、カードのような繰り返し使う要素が向いています。一ページ全体を巨大な部品にすると、一部分だけ違う場面で調整が難しくなることがあります。反対に、意味のない線一本まで細かく部品化すると、探して使う負担が増えます。

判断基準は、同じ役割で繰り返すか、共通の変更をまとめたいか、使う人がその単位を理解できるかです。仮定の予約サービスなら「予約する」という操作を表すボタンは部品の候補ですが、キャンペーンで一度だけ使う装飾は、急いで共通化しなくてもよいでしょう。

作り始めにすべての可能性を予測する必要はありません。同じ修正を二度三度繰り返している場所を見つけ、共通部分を整理する方法でも進められます。コンポーネントの数を増やすことより、使う場所で迷いなく選べることを目標にします。

共通ボタンを部品化する｜作成・配置・更新を一巡する

練習用ファイルと部品の置き場を用意する

共有ライブラリを直接変更する前に、自分の練習用ファイルを用意します。元の部品を置く場所と、画面に配置して試す場所を分け、見出しを付けておくと分かりやすくなります。業務ファイルを教材にする場合は、変更権限だけでなく、練習として編集してよいかも確認してください。

課題は、文字が「予約する」のボタンを一つ作り、使用例を三つ並べることにします。ひとつは初期状態、二つ目は文字だけを変更、三つ目は長い文字を使う試験用です。比較対象を残すことで、変更した結果を記憶だけに頼らず確認できます。

最初からアイコン、複雑な影、すべての状態を入れなくても構いません。基本の背景と文字だけで、作成・配置・更新が一周できることを優先します。見た目の完成度より、部品がどこにあり、どこで使われているかを把握しましょう。

作りたい範囲を選び、コンポーネントを作成する

ボタンの背景と文字を含むフレームを選び、Create componentの操作を実行します。公式資料では、右サイドバーの操作、右クリックメニュー、ショートカットが案内されています。操作前に、ボタン全体を選んでいるかをレイヤー階層で確認すると、文字だけを部品化するミスを避けられます。

Figma公式のコンポーネント作成手順には、一つを作る方法と複数をまとめて作る方法が掲載されています。今回は一つのボタンを一つの部品にするので、一括作成を混ぜずに進めてください。

作成後は、元の部品に「Button／Primary」など役割が伝わる名前を付けます。これは命名例であり、必須の形式ではありません。チームのルールがあればそちらを優先します。「青い四角」のような見た目だけの名前より、役割から探せる名前の方が、配色変更後も使いやすくなります。

インスタンスを置き、文言を一つだけ変える

アセットから作成した部品を探し、練習用の画面へ配置します。表示言語や画面構成が異なる場合も、対象のコンポーネントをアセットから挿入するという目的を手掛かりに探します。配置後は、元の部品そのものを動かしていないか、インスタンスとして選択できるかを確認します。

三つのインスタンスを用意したら、二つ目の文字を「空き状況を見る」に変更します。背景や形は触らず、文言だけを変えます。これが、共通部品を使いながら、使用箇所に必要な情報を入れる練習になります。後で文字プロパティを用意すると、この変更をより分かりやすく操作できます。

三つ目には「体験プランの空き状況を確認する」のような長めの文言を入れます。これは実際のサービス文言ではなく、崩れを見つけるための試験です。短い言葉で整って見えるだけでは、実際の原稿に差し替えたときの問題を見つけられません。

※表は横にスクロールできます。

メインの変更と個別変更を見比べる

メインコンポーネントへ戻り、角丸など共通の見た目を一項目だけ変えます。各インスタンスの形に反映されたか、個別に入れた文字は残っているかを確認します。変える項目を絞ると、何が連動し、何が個別の変更として残るかを観察しやすくなります。

次に、一つのインスタンスだけ背景を変える練習を行います。その後でメインの背景を変えると、すべてが同じ見え方にならない場合があります。そこで「つながりが切れた」と決めつけず、その属性が個別に上書きされていないかを調べます。上書きと切り離しは別の状態です。

この練習では、正しい見た目を早く作ることより、変更した場所と影響を対応させることが大切です。記録には「メインの角丸を変更」「二つ目のラベルは保持」「三つ目で文字が折り返した」と、確認できた結果を具体的に書きます。

初回の合格条件を決める

最初の課題は、元の部品を特定できる、インスタンスを追加できる、個別の文字を変更できる、共通変更の影響を確認できる、という四点を説明できれば合格にできます。ボタンの色が好みかどうかだけで判断すると、部品化を学んだ成果が分かりにくくなります。

もし長い文字で崩れたら、部品化を解除する前に、元のレイアウトと文字の設定を確認します。短い文字しか想定していない固定幅なのか、余白が不足しているのか、親の幅に制限があるのかを分けます。共通部分を直すなら、ほかのインスタンスも確認対象です。

できた部品の横には、使う場面と変えてよい部分を短く書きます。たとえば「主要な予約操作に使う。文言は変更可。危険な操作の警告には使わない」という説明です。こうしたルールは、見た目だけでは分からない部品の意味を伝えます。

プロパティとバリアントを設計｜変えてよい範囲を決める

プロパティは使う側への操作口になる

コンポーネントプロパティは、使う側にどの部分を変えられるかを示す仕組みです。毎回レイヤーの奥へ入って文字を探すより、「Label」という項目で文言を変えられる方が、操作する場所を理解しやすくなります。作成者の都合より、使用者が必要な変更を迷わずできるかを考えます。

文字、表示のオン・オフ、入れ子のインスタンス交換、バリアントなど、目的に応じた種類があります。現在の公式資料にはスロットも含まれています。最初のボタンでは、文字とアイコンの表示など、必要な種類だけを使い、すべての機能を一度に盛り込まないようにしましょう。

種類と作成方法は、Figma公式のコンポーネントプロパティ解説で確認できます。本記事の「Label」「Show icon」などは練習用の名称です。同じ意味を別々の名前で増やさないことが、使いやすさにつながります。

文言の違いをすべてバリアントにしない

「予約する」「空き状況を見る」「問い合わせる」のような文言だけの違いなら、文字プロパティで扱うことを検討できます。文言ごとに別のバリアントを増やすと、原稿が変わるたびに部品一覧が増え、目的のものを探しにくくなります。

一方、主要操作用と補助操作用など、見た目と用途をセットで区別したい場合は、種類を表すバリアントが候補になります。ただし、色が違うという理由だけで分けるのではなく、どの場面で使うのかを言葉にします。意味が決まっていない差分を部品化しても、判断は楽になりません。

自作の設計例では、文言はLabel、アイコンの有無はShow icon、種類はType、状態はStateと分けます。すべての案件でこの名前が正しいわけではありません。使う言語とチームの慣習に合わせ、同じ意味が同じ名前で伝わることを優先します。

※表は横にスクロールできます。

バリアントは属性と値の組み合わせで考える

バリアントは、関連するコンポーネントを一つのセットとして整理する方法です。たとえばSizeにSmall・Large、StateにDefault・Disabledという値を設けると、使う側は必要な条件を選べます。色や形を見比べて探すだけより、違いを言葉で表現できるようになります。

Figma公式のバリアント解説では、セット内の各バリアントに一意の値の組み合わせが必要とされています。同じ属性値の組み合わせが二つある場合は、見た目が違っていても衝突になります。名前を追加する前に、区別すべき意味を整理してください。

属性を増やしすぎると組み合わせが膨らみます。たとえば大きさ、状態、種類をそれぞれ複数用意すると、考える条件が急に増えます。ただし、考えられる組み合わせを全部作る必要はありません。実際に必要なものを選び、使わない組み合わせを無理に埋めないようにします。

状態の見た目と動作を区別する

Disabledと名付けた見た目を作っても、それだけで実際のWebサイトのクリックを無効にするコードが完成するわけではありません。Figmaの部品は設計資料の一部であり、実装や動作確認とは別です。プロトタイプ上での振る舞いも、必要に応じて別途設定します。

状態を増やすときは、どの条件でその状態になるか、利用者には何が伝わるべきかを添えます。たとえば入力が不足しているときに利用不可にするなら、不足内容をどう説明するかも設計の対象です。灰色にしただけでは、使えない理由が伝わらないことがあります。

デザイン担当と実装担当でStateの意味が違うと、見た目はそろっていても動作がずれます。部品の説明には、表示条件、操作できるか、必要なメッセージを短く書きます。コードを知らない段階でも、利用者の行動として説明することはできます。

プロパティを追加したら使用側で確認する

メインで設定しただけでは、使う側に分かりやすく見えているかは判断できません。新しいインスタンスを配置し、名前、初期値、表示順を確認します。作成者が構造を知っているから使える状態と、初めて触る人が使える状態は違います。

練習相手がいる場合は、「文言を変えて、アイコンを非表示にしてください」とだけ伝え、どこで迷うかを観察します。操作を先回りして説明すると、名称や設計の問題が見えにくくなります。相手が止まった場所を、部品説明の改善材料にしましょう。

相手がいなくても、一日置いてインスタンス側だけを見る方法があります。どの項目を選べば目的の状態になるか、自分でも忘れてしまうなら、プロパティの数や名前を見直す余地があります。多機能さより、よく使う変更を少ない判断で行えることが大切です。

カードと入れ子の運用｜上書き・交換・切り離しを使い分ける

既存のボタンをカードの中で使う

次の課題では、画像、タイトル、説明文、予約ボタンを持つカードを作ります。ボタンは別の図形を作り直さず、先ほどのインスタンスを入れます。こうすると、カード全体の構造と、ボタンという共通部品の責任を分けて考えられます。

カードをコンポーネントにすると、内側にボタンのインスタンスを持つ入れ子の構造になります。親のカードと子のボタン、どちらを編集しているかをレイヤー階層で確認してください。外側を選んだまま、内側の文字が変わらないと悩むような混乱を減らせます。

入れ子を深くするほど便利とは限りません。毎回何段も開かないと文言を変えられないなら、外側へ必要なプロパティを見せるなど、使う側の操作を見直します。構造を整える目的は、作成者がきれいに分類することだけではなく、使用時の負担を減らすことです。

上書きはその使用箇所に必要な違い

インスタンスに対する変更は、オーバーライドと呼ばれます。カードのタイトルや写真のように、共通の構造を使いながら内容だけ変えたい場面で役立ちます。どこまで個別変更を認めるかを決めておくと、共通部品の意味を保ちやすくなります。

一つの画面だけ文字を変えたいなら、使用側で変更するのが自然です。すべてのカードで共通の文字サイズを見直すなら、メインの修正が候補です。変更対象が一か所なのか全体なのかを先に考えれば、どちらを触るか判断しやすくなります。

意図しない上書きを戻す場合は、リセットする範囲を確認します。全体を戻す操作では、残したい文字や画像まで初期値へ戻る可能性があります。作業用の複製などで影響を確認し、必要な内容を把握してから実行してください。

※表は横にスクロールできます。

交換と上書きの保持には構造が関係する

入れ子のアイコンやボタンを、別のインスタンスへ交換する使い方もあります。交換候補が多すぎると選びにくいので、用途に合う候補を整理します。同じ場所へ何でも入れられる設計にするより、必要な選択肢が分かる方が、画面全体の一貫性を保てます。

交換やバリアント切り替えの際に、文字などの上書きがどう引き継がれるかは、レイヤーの名前や構造にも関係します。Figma公式のインスタンス変更の説明を確認し、実際の部品で保持される範囲を試してください。必ず全部残ると決めつけないことが重要です。

練習では、カードAに固有のタイトルを入れ、ボタンの種類を切り替えます。残ってほしい内容が残るか、初期値へ戻った項目がないかを見ます。戻ってしまうなら、使用者の操作ミスだけでなく、元の部品の構造や命名を見直す余地があります。

切り離しを最初の解決策にしない

インスタンスを切り離すと、メインとの更新の関係を失うことになります。自由に編集したい場面では選択肢になりますが、共通変更を受け取りたい部品で多用すると、後から修正漏れが増えます。変更できないと感じたら、まずプロパティや交換で解決できないかを確認します。

一回限りの特殊な表現として切り離す場合は、共通部品から外れた理由を残します。「この画面だけ特別だから」だけでは、次の担当が同じ変更をほかにも広げてよいのか判断できません。例外の目的、使う範囲、今後の扱いを短く書きましょう。

現在のFigmaには、部品の中に柔軟な領域を設けるスロットという仕組みもあります。公式のスロット解説を確認すると、インスタンスを切り離さずに内容を追加・調整する設計の選択肢が分かります。今回は基礎を優先し、必要になった段階で検討すれば十分です。

カードの試験用データを用意する

カードは短い見本の文章だけで完成としないでください。長いタイトル、説明文なし、画像がない場合、ボタンの文言が長い場合など、実際に起こりそうな条件を用意します。本文の内容を変えても、情報の優先順位と操作の場所が分かるかを確認します。

架空の予約サービスなら、「朝の体験」「週末の少人数向けじっくり体験プラン」の二種類のタイトルで比較できます。文字数は実測の利用者データではなく、設計の弱点を探すための仮定です。長いものを入れること自体が目的ではなく、許容する長さと表示方針を決める材料にします。

結果は「崩れた」で終わらせず、「タイトルが三行になるとボタンが隠れる」「画像なしのとき余白が残る」と具体化します。そのうえで、部品の構造を変えるのか、内容の入力ルールを設けるのかを判断します。文章側に制約を付けるなら、使う人が分かる場所へ明記してください。

変更が伝わらないときの確認｜命名・点検・引き継ぎを整える

まず参照先と選択対象を確認する

メインを直したのに見た目が変わらないときは、対象が本当にそのメインのインスタンスかを確認します。似た名前の別部品、古い複製、切り離した要素が混ざっている場合があります。見た目の一致だけでは、更新のつながりまでは判断できません。

次に、変更した属性が個別に上書きされていないかを見ます。背景だけ変わらず、角丸は伝わっているなら、すべての接続が失われたとは限りません。変わる項目と変わらない項目を分けると、調べる範囲を絞れます。

別ファイルのライブラリを使っている場合は、作成元の変更、ライブラリへの反映、使用側の更新確認という段階も関わります。利用できる共有機能や操作権限はプランと設定により異なるため、現在の環境の案内を確認します。同じファイル内でできたことを、そのまま別ファイルへ当てはめないでください。

名前と説明を、探す人の視点で整理する

部品名は、見つけるための入口です。同じ意味のボタンを「Primary」「Main」「Important」と別々に呼ぶと、違いがあるように見えます。意味が同じなら表現をそろえ、違うなら用途の説明を添えます。命名の巧妙さより、判断が一致することが大切です。

プロパティの名前も、SizeとScaleを混在させるなど、似た言葉の乱立を避けます。作成途中の便宜的な名前が残っていないか確認し、初期値も含めて読みやすくします。使わない古い部品は、今後使ってよいものと区別できるよう整理方針を決めます。

説明には、用途、使用しない場面、変えてよい項目、関連する部品を含めると役立ちます。長い文章をすべての部品に書く必要はありません。使う人が迷いやすい判断を優先し、実際の質問が出た場所から補足していく方法でも十分です。

※表は横にスクロールできます。

共通変更は代表的な使用例で確認する

メインの余白や文字サイズを変えたら、部品単体だけでなく、実際の画面に置いた使用例を確認します。単体では整っていても、隣の部品との間隔やカードの高さに影響することがあります。共通部品の修正は、使用箇所を含めて完了させる必要があります。

試験用のページには、初期状態、長い文字、短い文字、アイコンなし、必要な状態を並べておくと便利です。変更のたびに毎回作り直さず、代表例を比較できます。ただし、試験ページだけ正常ならすべて大丈夫とは限らないため、重要な実画面も確認します。

変更内容は「デザイン調整」ではなく、「主要ボタンの左右余白を変更。長文ラベルとカード内の使用例を確認」のように記録します。影響範囲と確認した条件が分かれば、ほかの担当者も自分の画面で何を見るべきか判断しやすくなります。

引き継ぎでは部品一覧より判断ルールを伝える

ファイルを渡すときは、部品が何個あるかだけでなく、どこを元として管理するか、どの画面が使用例か、変更時に誰へ相談するかを説明します。元と練習用の複製が並んでいるなら、どちらが正規のものか分かるようにしてください。

実装担当には、見た目の名前に加えて、状態の意味や入力内容の制約を伝えます。Figmaのコンポーネントとコードのコンポーネントが一対一になるとは限りませんが、共通して扱いたい役割を説明できると、話し合いの土台になります。

副業の納品なら、編集可能なファイルを渡すのか、閲覧のみの共有なのか、共有ライブラリの管理まで含むのかを事前に確認します。素材や顧客情報の利用範囲にも注意し、練習用の公開作品へ勝手に流用しないでください。部品の整理と、共有する権限の判断は別々に行います。

学習の振り返りは、三つの質問で行う

最後に、自分の部品について「何を共通にしたか」「どこを個別に変えられるか」「元を直したら何を確認するか」の三つへ答えてみてください。操作手順を暗記していても、この説明ができない場合は、部品の単位やプロパティを見直す余地があります。

次の練習では、ボタンの数を増やすより、別の人にカードを使ってもらうことがおすすめです。文言変更、アイコンの切り替え、長いタイトルの入力を頼み、迷った場所を記録します。自分で作る力に加え、相手が使える状態へ整える力を養えます。

レビューを受けたい、設計の考え方を体系的に学びたいという段階では、Webデザインスクールの学習内容・副業支援の比較も判断材料になります。受講を先に決めるより、今回の部品で何に困ったかを整理すると、必要な添削や質問支援を選びやすくなります。

Figmaのコンポーネントは、同じ見た目を速く増やすだけの機能ではありません。共通の判断を部品にまとめ、必要な違いを使う側へ渡し、変更の影響を確かめるための仕組みです。まず一つのボタンで作成・配置・変更を一巡し、その後にカードや状態へ広げていきましょう。