Figmaデータより先に「画面」がある──制作フローの変化と「仕様の定義（設計の基準）」の所在《綿貫佳祐のFigma思考ラボ｜Vol.10》

WebページをそのままFigmaに取り込む公式Chrome拡張機能

Figmaが公式のGoogle Chrome拡張機能を公開しました。この機能を使うと、ブラウザで表示しているWebページを、編集可能なFigmaレイヤーとして取り込むことができます。

特長は、取り込んだ結果が単なるスクリーンショットではないこと。Figma上で編集・調整できるレイヤー構造として貼り付けられます。

FigmaのChrome拡張機能の使い方

1. 拡張機能のインストール

Chrome Web Storeにアクセスして、Figma拡張機能をインストールします。

2. 初回起動時にFigmaへログイン

インストール後、ブラウザのツールバーにある拡張機能のアイコンを初めてクリックすると、まずはFigmaアカウントへのログインが求められます。

ログインが必要なのは初回のみです。

3. 取り込みたいページで拡張機能を起動

ログインを終えたら、取り込みたいWebページを開き、改めて拡張機能のアイコンをクリックします。「Figma Capture」と書かれたバーが表示されるので、ページ全体を取り込むか（「Capture page」）、特定の要素を選択して部分的に取り込むか（「Select element」）のいずれかを選びます。

4. Figmaのキャンバスにペースト

取り込み操作が完了すると、クリップボードにコピーされた状態になります。あとはFigmaのキャンバスを開いて貼り付けると、編集可能なデータとして展開されます。

「公式」の拡張機能として登場した意味

実は、ブラウザ上のWebサイトをFigmaに取り込むような仕組みは、以前からサードパーティによって提供されていました。‹div›RIOTS社が提供していた「html.to.design」というプラグインが、その代表例です。

ただ、サードパーティ製のツールだと、Figmaのアップデートに追従できなくなったり、メンテナンスが止まったりするリスクが付きまといます。実際に、使い続けていたプラグインが突然動かなくなった経験をしたことがある方もいらっしゃるでしょう。

今回、公式から提供されたことで、こうした不安はかなり少なくなるはずです。Figmaのアップデートに合わせて、これまでの機能が維持されることや、データの取り扱いがFigmaのエコシステム内で完結すること、そして今後の継続的な機能改善を期待できることなども、大きなメリットと言えます。

つまり、今回のリリースは、「まったく新しい機能が生まれた」というよりも、「これまでも使われていた機能が公式のサポートを得た」という意味合いが強いものだと解釈できるでしょう。

この機能が活きる場面

私の理解では、この機能の核心は「ブラウザ上にしか存在しない見た目を、編集可能なデザイン環境に持ってくること」です。

実務の場面を想定すると、以下のような場面の使い道が考えられます。

1. 既存ページを改修する際に、現状をFigmaに取り込んで作業の起点にする
2. 実装が先行していてデザインデータが存在しない、あるいは古くなっているページを、編集可能な状態に引き上げる
3. 複数のページの現状を1カ所に集めて、横断的に把握・整理する

特に1については、この拡張機能が登場する前の手順を思い出すと、その価値がよくわかります。

既存ページに小さな改修を加えたいとき、イチからFigmaデータを整備するほどの工数はかけられないが、かといってビジュアルなしに実装へ渡すのも伝わりにくい、という場面があります。そのような状況では、既存ページのスクリーンショットを撮って、それをFigmaに貼り付けて、変更したい箇所だけを手で切り貼りしてモックアップをつくる、といったひと手間がかかっていました。

たとえばこの場合、静止画を貼り合わせているのでテキストは編集できず、余白や寸法の確認もしづらいですし、少し内容が変われば撮り直しが必要になります。この拡張機能を使えば、ページをそのままFigmaのレイヤーとして取り込めるため、テキストを直接書き換えたりレイアウトを調整したりしながらモックアップをつくれます。この機能自体は、大きな機能追加とは言えませんが、従来生じてきた手間のかかる作業から解放される場面は少なくないはずです。

そもそも「Figmaを使っているチームのWebサイトには、対応するFigmaデータが整っている」というのは、必ずしも成り立つ前提ではありません。工数を優先して、既存ページを見ながらそのまま実装する「インブラウザデザイン」的な進め方をしたページは、最初からFigmaデータが存在しないからです。

過去にPhotoshopやIllustratorで作られたデータしかなく、継ぎ足しで運用しているケースもあります。外部のデザインパートナーから完成した実装物だけを納品されていて、編集可能なデータが手元にないというパターンも珍しくありません。StudioやFramerのようなノーコードツールで構築されたサイトも同様で、実装の正規データがそのツール上にある場合、リニューアルや改修をFigmaで検討したいなら、ブラウザに映っている状態を起点にするしかありません。

きちんとFigmaデータを整備するのが理想なのは間違いありません。ただ、理想と現実の間には距離があることも多く、「画面に映っているものが現実を表していて、Figmaデータはそれに追いついていない（整っていない）」という状態は、それほど例外的な話ではないのです。

制作フローが変わると「仕様の定義」の位置づけも変わる

もう少し先の話をしてみます。

従来の制作フローは、おおよそ「デザインデータを作成する」→「実装する」→「デプロイする」という順序でした。このフローだと、Figmaのデータが「設計の基準」、もしくは最終的な「仕様を定義するもの」となります。実装はFigmaをもとに行われ、最初の一歩はFigmaから始まります。

ところが、AIによる制作支援が進むにつれて、このフローの順序が変わりつつあります。たとえば、AIがコードまで含めて直接生成し、それをデプロイした後、実際に動いているプロダクトに基づきデザインの改修を進めるという流れです。

あるいは、コードベースがプロダクトの「生きたドキュメント」として更新され続ける一方で、Figmaデータは、そのスナップショットやUI改修の起点として位置づけられるケースもあります。

他にも、各種AIツールによって、まずコードやプレビューが生まれ、関係者とのレビューや議論のためにFigmaへ取り込む「コード発のプロトタイピング」もあります。もしくは、実装が先行して育ってきたプロダクトから現状のUIをFigmaに取り込み、そこからコンポーネントやデザイントークンを整理していく「デザインシステムの後追い整備」も、選択肢として浮上してきています。

これらに共通しているのは「実装・デプロイ済みの状態こそが『最終的な仕様の定義（設計の基準）』であり、Figmaはその後から始まる」という流れです。制作の出発点が、ゼロから描き起こすFigmaデータではなく、すでに画面に描かれた結果というケースは、これからさらに増えていく可能性があります。

機能の裏側を考えること

この文脈に立つと、今回取り上げた「Webサイト（Webページ）をそのままFigmaに取り込む」機能は、単なる便利ツールという以上に、今後の制作フローの変容を先取りした機能として見えてきます。

この機能がアナウンスされた際、SNS上では「公式が無断複製を容認した」「すでにFigmaデータがあるから意味がない」といった否定的な声も見られました。たしかに、自分の現場のFigmaデータが整っている環境から見れば、この機能を必要とする状況が想像しづらいかもしれません。しかし、自分の現場に必要ないことと、その機能に価値がないこととは、同義ではありません。

ここまで説明してきたように、現場の状況はさまざまで、デザインデータのあり方も、制作フローも、ひとつの形に収まるものではありません。ある機能が登場したとき「自分には関係ない」と判断するのは簡単です。一方で「なぜFigmaがこの機能をつくったのか？」や「この機能を通じて、どのような課題を解決しようとしているのか？」を考えることは、その機能をより深く理解するだけでなく、自分たちの仕事のやり方を見直すきっかけにもなります。

今後も本連載では、「機能の裏側を考える習慣」が「Figmaをちゃんと使いこなすことにつながる」といった視点をお伝えし続けていきたいと思っています。

まとめ

今回の内容を整理します。

みなさんの現場では、何が「仕様の定義（設計の基準）」になっているでしょうか。そして、その「仕様の定義（設計の基準）」は、これからも同じ場所にあり続けるでしょうか。

著者プロフィール

文：綿貫佳祐