コードとデザインを自由に行き来する ― Figma MCPとAIエージェントがもたらしたSpindle開発フローの変革

Figma MCPやCursor、Claude CodeといったAIツールの浸透によって、Amebaデザインシステム「Spindle」の開発フローが変わりつつあります。エンジニアがAIツールを使ってFigmaを操作したり、デザイナーがコードを変更してPull Requestを出したり、実際に動くツールを作ったり。このようなコードとデザインの間を、職種を問わず自由に行き来する開発フローが、私たちSpindleチームでも自然になってきました。

この記事では、最近のチームでの事例を紹介します。

ケース1: 頓挫していたイラストメーカーを、1日で実用化

朝10時、Spindleチームの定例ミーティング(この日はめずらしく朝でした)。最近リリースされたFigma MCPサーバーやStorybook MCPの話題になりました。「どういうふうに使えるか？」という雑談の中で、ひとつのアイデアが浮かびます。

頭・体・脚・アクセサリを着せ替えのように組み合わせるイラストメーカーを、Webアプリとして独立させる話です。約600パーツ・7ポーズぶんの座標系やレイヤー構造がFigmaのコンポーネント構造に暗黙的に埋め込まれており、コードに変換しきれず長く頓挫していました。

試しにFigma MCPを使ってコンポーネントの状態を解析したところ、実現可能そうだったのでもう一度挑戦してみることにしました。

Spindleでは、「Amebaらしさ」を体現するために多様なイラストを作成しています。今日は、そのイラストを効率的に利用する仕組みをご紹介します。

▶️ Figmaの「Instance swap」と「Variant」を使って様々な組み合わせのイラストをトライアル・・・🧑‍🔬

あっという間にファンキーに変身しました🔜😎 pic.twitter.com/9ToOhX6dcm

— Ameba Design System Spindle (@AmebaSpindle) July 19, 2022

Figma上に作成されたイラストメーカー

まず、Figma MCPのget_design_context

次に、約600パーツのSVG画像をFigma REST APIで一括ダウンロードするスクリプトを作成しました。Spindleではアイコン取得で同様の処理を使っており、それを転用するだけで済みました。

Head+Body+Leg+アクセサリ

Head+Body+Leg+アクセサリ

Head+Body+アクセサリ

Head+Body(自転車)+アクセサリ

Head -14.71° 回転

レイヤー座標データとSVG画像が揃ったところで、Claude Codeに実装を依頼しました。Webアプリ用のプロジェクトを初期化し、Canvas APIでSVGを重ねて描画する処理を実装。初稿の時点でパーツの選択・ポーズの切り替え・PNG出力まで一通り動作しています。

13:39 「理想だ！これが作りたかった半年前」 — ホンディ

ある程度コードが形になったところで、デザインとロジックの調整両方を並行して進めるために、generate_figma_design

14:02 「すでに割とデザインいいかんじなんですよねw」 — ホンディ

Figma上で調整を進める中で、面白い気づきがありました。

14:35 「AIが作ったFigmaをいじるとき、必須スキルとして人の作ったAutoLayoutの意図を早く見抜くっていうのがあって結構センス問われそう」 — ホンディ

HTML-to-designが生成するFigmaデータは見た目が正確な一方、構造的にはフラットなフレームの集合になっています。デザイナーがAutoLayoutを適用していくには、元のHTML/CSSのレイアウト意図を読み解く力が必要になりそうです。

デザイナーはFigma上でAutoLayoutを整えながら、Spindleコンポーネントライブラリから必要な部品を手動で配置していきました。性別切替をSegmentedControlに、アイテム選択リストをAutoLayout対応に変えるなど、見た目だけでなく構造レベルでSpindleらしいUIに仕上げていきます。

デザイン調整が完了して「Ready for dev」になったら、再びget_design_context

Canvas描画のデバッグにはChrome DevTools MCPを活用しました。take_screenshot

ロジック修正と並行して、コード側でもSpindle UIのコンポーネントを適用していきました。完成形をFigma上でも確認できるようgenerate_figma_design

search_design_system

たとえば「この要素をToggleSwitchに置き換えて」と指示すると、search_design_system

// 1. デザインシステムからToggleSwitchを検索 search_design_system({ query: "ToggleSwitch", fileKey: "..." }) // → componentKey: "aa59f079a24d9e3a696e43ed6378182baa246599" // 2. use_figmaでインスタンスを作成・置き換え const componentSet = await figma.importComponentSetByKeyAsync(componentKey); const offVariant = componentSet.children.find(v => v.name.includes('false')); const instance = offVariant.createInstance(); // 位置を合わせて古いノードを削除

またお辞儀ポーズだけはFigmaにコンポーネントがなかったため、エンジニアがuse_figma

最後は開発環境にデプロイして、チームで触れる状態に。これにて初日の開発完了です。途中、会議を挟みつつもAIエージェントとともに開発したことで、半年ほど頓挫していたイラストメーカーがあっという間にでき、チーム一同とても感銘を受けました。

19:04 「一旦今日はここまでいけました」 — herablog

19:17 「これはやばいすな」 — J

ケース2: デザインシステム運用でも起きている双方向の越境

「コードとデザインを行き来する」ワークフローは、デザインシステムの日常的な運用でも行われています。ここでは、エンジニアがFigmaコンポーネントを追加した例と、デザイナーがコードを変更した例を紹介します。

エンジニアによるFigmaコンポーネントの追加 — LinkButton

きっかけは、LinkButtonのDesign Docレビューでした。「Code Connectも追加したいですね」というコメントに対し、「対応するFigmaファイルがないので作るとこからなんですよね…」と返しました(#1726)。

Spindle UIにはコードにLinkButton

既存Buttonの構造をget_design_context

既存のButtonコンポーネントの構造をget_design_context

Spindle MCPから既存のButtonの実装コードを取得

デザイントークンとAutoLayout設定を踏襲してLinkButton用のコンポーネントセットを設計

デザイナーによるコード領域への進出

エンジニアがFigmaを操作した例に対し、逆方向としてデザイナーがコードやツールに手を伸ばした事例もあります。

View Transition PRの例

デザイナーがSpindle公式サイトにView Transitionを追加するPRを出しました。slide遷移の整理、不要なサイドバー入場アニメーションの抑制、vhからdvhへの置換などの変更です。

アニメーションのタイミングや挙動のニュアンスは、職種をまたぐと言語化しにくく、依頼しづらいことがあります。そこで、デザイナー自身がAIを補助にしながらコードに落とし込むことで、自分の意図をそのまま実装に反映しやすくなりました。

別のデザイナーは、Figma Makeを使ってブログ記事のOGP画像生成ツールを作りました。記事タイトル・著者情報を入力するとイラストパターンを選んで1200×630pxのOGP画像をプレビュー・出力できるWebツールです。OGP画像の作成は記事を書くたびに毎回発生する作業で、これまでブログを書く多くの人が抱えていた手間でした。デザイナーがAIツールを使って自分でコードを作り、チーム全体の課題を解決している点が印象的です。

なお、この記事のOGP画像も同ツールで生成しています。

Spindleチームの従来の開発フローは、Design(デザイナー)→ Document(デザイナー＋エンジニア)→ Develop(エンジニア)と、工程ごとに担当が分かれていました。

それが今、AIエージェントを介することでDesign・Document・Developの境界が曖昧になり、職種を問わず同じ領域を行き来するフローに変わっています。

ケース1ではエンジニアがFigma MCP経由でデザインデータを直接読み解き、デザイナーがClaude Codeで生成されたUIをFigma上でブラッシュアップしていました。ケース2ではエンジニアがFigmaコンポーネントを追加し、デザイナーがコードのPRを出していました。どちらも、従来の一方向のハンドオフでは起きなかった動きです。

実装の担当が逆になっても、レビューはデザインをデザイナーが、コードをエンジニアが見る流れは続いています。AIによって専門外への越境が容易になる一方、得意な領域では今までと変わらず自分の手で仕上げられます。越境と本職の両方が地続きになることで、速度と品質がともに上がったと感じています。

デザインシステムが整備されていると、その世界観で作るプロダクトはあっという間に一定水準以上に仕上がります。Spindle UIのコンポーネントとデザイントークンが揃っていることで、UI実装の多くが「どのコンポーネントを使うか」「どのトークンを割り当てるか」の選択になり、MCPを通じてAIがドキュメントや型定義と矛盾しにくい候補を提案・適用してくれます。

これはコードに限った話ではありません。デザインでも同様に元の構造が整理されているほどAIが出力するアウトプットの品質が上がります。先ほどのLinkButtonの例では、既存のButtonコンポーネントの構造・トークン・AutoLayout設定を読み取って、30バリアントのコンポーネントセットを一括生成しました。Buttonがきちんと整備されていたからこそ、そのパターンを踏襲したLinkButtonを高い品質で作れました。

Figma MCP (get_screenshot)

Figma上のイラストをスクリーンショットで取得し比較検証

Figma MCP (get_design_context)

コンポーネントの座標・レイヤー構成・プロパティの取得。Code Connect経由でimport文・props名も取得

Figma MCP (get_metadata)

コンポーネントセットのバリアント一覧取得

Figma MCP (use_figma)

Figma Plugin API経由でノードの置き換え・編集

Figma MCP (generate_figma_design)

ブラウザの表示をFigmaキャンバスにキャプチャ

Figma MCP (search_design_system)

Spindle UIライブラリのコンポーネント検索

Chrome DevTools MCP (new_page, navigate_page, take_screenshot, take_snapshot, click, list_console_messages)

ページ表示・リロード、スクリーンショット取得、DOM操作、コンソール確認

Spindle MCP (get_component_info)

コンポーネントの詳細Props定義・使用ガイドライン・アクセシビリティ要件の取得

※ CursorやClaude Codeではプラグインインストール時にバンドルされるAgent Skillsを使うと精度が上がります。詳しくはFigma MCP Server Guideを参照してください。

MCPやAIエージェントの進化によって、デザインシステムの使い方や使い手の幅が広がっていることを今回改めて実感しました。専門領域を持ちながらも、お互いの得意・不得意を補い合える環境が自然に生まれてきています。Spindleチームでは、デザインシステムをAIにとってより良い基盤に育てつつ、チームのより多くの人がその恩恵を受けられる状態を目指していきたいと考えています。