《綿貫佳祐のFigma思考ラボ｜Vol.7》スロット機能で変わるコンポーネント設計。Figmaでも「レイアウトと中身の分離」は実現するのか？

Web制作に携わる人にとって、いまや日々の業務に欠かせない存在となったコラボレーションプラットフォーム「Figma」。一方で、「もっと使いこなしたい」「ほかの人はどう活用しているのだろう」と感じている方も多いのではないでしょうか。

本連載では、Figmaの使い方や、Figmaを軸にしたワークフローを紹介します。ただし、単なる機能解説ではありません。各機能をどう捉え、どんな思考で使いこなしていくのか–––––その“思考”に焦点を当ててお届けします。ときには1人のUIデザイナーとして、ときにはチームの一員として、私がどのようにFigmaと向き合っているのかを共有していきます。

第7回は、Figmaの新機能「スロット」にフォーカス。同機能で何が実現できるのか、さっそくレビューしていきます。

はじめに：Figmaに足りなかった「レイアウトだけのコンポーネント」

頻繁に使うカードやリストのスタイルがあるのに、中身が変わるたびにコンポーネントを作り直したり、デタッチして個別に調整したりしていないでしょうか。

これまでのFigmaでは、同じ「器」で中身だけが異なるパーツを柔軟に扱う手段が限られていたため、そのような対応を取らざるを得ませんでした。

2026年3月6日、この課題を解消する新しいコンポーネントプロパティ「スロット」が追加されました。

コンポーネント内の特定のレイヤーを「スロット」として定義すると、そのスロットには任意のコンポーネントや要素を自由に差し込めるようになります。

一見するとインスタンススワップと似ているように思えますが、思想としては異なります。

インスタンススワップは「あるコンポーネントを別コンポーネントに入れ替える」機能ですが、スロットは「コンポーネントであろうとなかろうと、何でも入れられる領域を定義する」機能です。

この違いが意味を持つのは、コードの世界では当たり前だった「レイアウトと中身の分離」が、Figmaでもようやく実現できるようになったからです。

スロット機能の基本

コンポーネントプロパティとしてのスロット

スロットは、Figmaのコンポーネントプロパティの1つとして追加されました。

これまでプロパティは、バリアント、テキスト、ブーリアン、インスタンススワップの4種類でしたが、そこに5つ目のプロパティとして加わっています。

使い方はシンプルです。コンポーネント内の任意のフレームを選択し、スロットプロパティを適用するだけ。ただし、トップレベルのフレーム（コンポーネントの最も外側にあるフレーム）にはスロットを適用できないという制約があります。

スロットに入れられるもの

スロットの特徴は、入れられる要素の自由度が高い点です。

• 推奨コンポーネント（優先されるインスタンスとして設定したもの）
• それ以外のコンポーネント
• コンポーネント以外の通常の要素（テキスト、フレーム、画像など）

この「何でも入れられる」という点が、インスタンススワップとの決定的な違いです。

インスタンススワップではコンポーネント同士の差し替えしかできませんでしたが、スロットではその制約がなくなります。実務で考えてみると、コンポーネントの中に差し込みたいものは、実は単なるテキストや画像であることも多いはずです。

インスタンススワップではそれができなかったため、わざわざテキストをコンポーネント化するか、インスタンスをデタッチする必要がありました。スロットではその必要がなくなるため、実務的にもかなり使い勝手が良さそうだと感じています。

なぜスロットが重要なのか：Figmaとコードのギャップがまたひとつ埋まる

コードでは当たり前だった「レイアウトコンポーネント」

コードの世界では、「レイアウトだけを担当するコンポーネント」は以前から一般的な設計パターンでした。プラットフォームを問わず、多くのフレームワークがこの考え方を採用しています。

Webの例として、Next.jsには「Layout」という仕組みがあります。

これはコンポーネントの構造（外枠や配置のルール）を定義し、その中に入る具体的なコンテンツは、使う側が自由に決められるという設計です。

カードコンポーネントを例に取ると、カードの枠線や影、余白といった「器」の部分だけをコンポーネントとして定義し、カードの中に何を表示するかは使う側が渡す––––というのが、コードにおける標準的な作り方です。

1つのカードコンポーネントを作れば、中身を入れ替えるだけでさまざまなバリエーションに対応できます。

しかしFigmaでは、同じ構造で中身だけが異なるパーツを、1つのコンポーネントで柔軟に扱うことができませんでした。

スロットが埋めるギャップ

スロット機能により、この長年のギャップが埋まりました。

「レイアウトの構造はコンポーネントが担い、中身は使う側が自由に決められる」というコードと同じ考え方が、Figma上でも自然に実現できるようになったのです。

これは単に作業効率が上がるという話ではありません。

デザインとコードの設計思想が近づくことで、デザイナーとエンジニアの間でコンポーネントの考え方を共有しやすくなるという効果もあります。

スロットとインスタンススワップの関係：上位互換なのか、使い分けるべきなのか

スロットを触ってみると、「これはインスタンススワップの上位互換ではないか」という疑問が浮かぶかもしれません。実際、スロットはインスタンススワップでできることの多くを包含しています。

私自身も、今後の新規コンポーネント設計では、スロットを優先的に使っていきたいと考えています。ただし、「インスタンススワップが完全に不要になった」とまでは言い切れません。

両者の性質を整理してみましょう。

機能的な違い

	インスタンススワップ	スロット
入れられるもの	コンポーネントのみ	コンポーネント、テキスト、画像、フレームなど何でも
要素の追加・削除	不可（1対1の差し替え）	可能（複数要素の追加・並び替えもできる）
選択肢の制御	優先されるインスタンスで推奨を設定	優先されるインスタンスで推奨を設定
デタッチの必要性	想定外の構成にはデタッチが必要	デタッチせずに自由な構成が可能

こうして並べると、スロットはインスタンススワップの制約をほぼすべて取り払ったものだと言えます。

それでもインスタンススワップが活きる場面

では、インスタンススワップの出番はもうないのでしょうか。

私は、以下のような場面ではインスタンススワップの方が適していると考えています。

• 差し替え先を厳密にコントロールしたい場合
  アイコンの差し替えのように、「必ず特定のコンポーネントセットの中から選んでほしい」というケースでは、インスタンススワップの方が意図を明確に伝えられます。スロットは自由度が高い分、想定外の要素が入り込む余地があります。
• 1対1の差し替えで十分な場合
  要素の追加や並び替えが不要で、単に「あるアイコンを別のアイコンに差し替える」だけで済むのであれば、インスタンススワップの方がシンプルです。
  

つまり「自由度を与えたい場面ではスロット、選択肢を制限したい場面ではインスタンススワップ」という使い分けになります。

既存ライブラリの移行について

Figmaの公式ドキュメントでも、既存のインスタンススワップをスロットに移行するためのガイドが公開されています。

既存のバリアントやインスタンススワップで構築されたロジックには、スロットへ変換すると失われる部分もあるため、公式ガイドでもすべてを一括で置き換えることは推奨されていません。

移行の判断基準や具体的な手順については、こちらのガイドが参考になります。

新規にコンポーネントを設計する際はスロットを前提に考え、既存のライブラリについてはコンポーネントの用途ごとに移行の要否を判断する–––というのが現実的なアプローチではないでしょうか。

スロットが変えるデザインの実務

カードやリストだけではない、ページレイアウトへの応用

公式ブログの事例では、カードの中身を入れ替えるような使い方が中心に紹介されています。もちろんこれは代表的なユースケースですが、スロットの可能性はそれだけにとどまりません。

たとえば、ページ全体のレイアウトを構成するコンポーネントとして活用することもできます。

• ヘッダー・フッター・サイドバーの配置を定義したレイアウトコンポーネントを作り、メインコンテンツ部分をスロットにする
• ダッシュボードのグリッド構造をコンポーネント化し、各セルをスロットとして定義する
• モーダルの枠組みをコンポーネントにして、中身をスロットで差し替える

これは、先述したNext.jsにおける「Layout」の概念と、まさに同じものです。Figmaでも、ページの「骨格」と「中身」を分けて管理できるようになりました。

コンポーネント設計に求められる意識の変化

スロットの登場は、コンポーネントの作り方にも変化を求めます。

以前、この連載の第3回「コンポーネントはどこまで作り込むべきか？」で、視覚優先のコンポーネント設計が生む課題について書きました。

その中で挙げた問題のひとつが「バリエーションの爆発」です。使用場面ごとに別のコンポーネントを作ってしまう問題です。

例えば「トップページ用記事カード」「一覧ページ用記事カード」「サイドバー用記事カード」のように、同じ役割のコンポーネントが、使い方の違いだけで増殖してしまうケースです。スロットは、この問題に対する有力な解決策になります。

レイアウトの構造をコンポーネントとして定義し、中身をスロットとして開放すれば、使用場面ごとにコンポーネントを分ける必要がなくなります。1つのカードコンポーネントに対して、使う側が中身を自由に構成すればよいからです。

また、コンポーネントが硬すぎて柔軟性がなく、結局デタッチして個別に調整するしかない–––––という状況に対する解決策にもなります。スロットがあれば、デタッチしなくてもインスタンスのまま柔軟な構成が可能になります。

つまり、スロットの登場によって、第3回で提起した「視覚優先で場当たり的にコンポーネントを増やしてしまう」という問題に対して、機能レベルでの解決手段が与えられたことになります。

ただし、スロットがあるからといって問題が自動的に解消されるわけではありません。むしろ、コンポーネント設計の重要性はこれまで以上に高まると私は考えています。せっかくレイアウトの一貫性を保つ仕組みがあるのに、毎回デタッチしてしまうのはもったいないことです。

「この部分は可変にすべきか」「スロットとして開放すべきか」を設計段階で考えることが、より堅牢で使いやすいデザインシステムにつながります。第3回で「コンポーネント設計はデザイナーだけでは難しく、エンジニアとの協働が不可欠」と書きましたが、スロットの登場によって、この協働もやりやすくなったのではないでしょうか。

先述のとおり、コードでは「外枠だけを定義し、中身は使う側から渡す」という設計パターンが広く使われています。

スロットによってこの考え方がFigma上でも表現できるようになり、デザイナーとエンジニアが「このコンポーネントのどこを固定し、どこを可変にするか」を同じ仕組みの上で議論できるようになりました。コードに詳しくない方でも、スロット機能を通じてこの設計パターンを理解できるのではないでしょうか。

まとめ

スロット機能は、Figmaのコンポーネントに新たな柔軟性をもたらすものです。

• スロットはコンポーネントプロパティの5つ目として追加された機能で、コンポーネントに限らず任意の要素を差し込める領域を定義できる
• コードでは一般的だった「レイアウトと中身の分離」がFigma上でも実現でき、デザインとコードの設計思想のギャップが縮まる
• カードやリストの中身の差し替えだけでなく、ページ全体のレイアウト構成にも応用できる
• デタッチに頼らない、スロットを前提とした柔軟なコンポーネント設計が今後ますます重要になる

Figmaは着実に、コードの設計思想へと歩み寄ってきています。スロットの導入は、その流れの中でも大きな一歩と言えるでしょう。

デザインシステムを構築・運用している方にとっては、既存のコンポーネント構成を見直すよい機会にもなるはずです。

文：綿貫佳祐