コードとデザインを自由に行き来する ー 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を使ってコンポーネントの状態を解析したところ、実現可能そうだったのでもう一度挑戦してみることにしました。

デザインを読み解く

まず、Figma MCPのget_design_contextを使い、イラストコンポーネントのレイヤー構成・CSS inset値・回転角度・コンポーネントプロパティを一括取得しました。get_metadataと合わせて7ポーズ分のバリアント構成やキャンバスサイズ・パーツ構成の違いも把握できました。

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

AIで一気に実装する

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

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

デザインとコードを往復する

ある程度コードが形になったところで、デザインとロジックの調整両方を並行して進めるために、generate_figma_designツールを使ってブラウザの表示をFigmaキャンバスに書き出しました。デザイナーが使い慣れたFigma上でUIをブラッシュアップできる状態を作れました。

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で差分を確認しコードに反映しました。FigmaのCode ConnectとSpindle MCPを使い分け、コンポーネントの置き換え、カラーコードのセマンティックトークンへの置き換えをおこないました。

Canvas描画のデバッグにはChrome DevTools MCPを活用しました。take_screenshotでブラウザの描画結果を確認しつつFigmaの値と照合するサイクルを反復し、SVGオーバーフローやCSS insetのズレを素早く解決できました。

ロジック修正と並行して、コード側でもSpindle UIのコンポーネントを適用していきました。完成形をFigma上でも確認できるようgenerate_figma_designでキャプチャし、search_design_system + use_figmaによりインスタンスに差し替えました。最終的にSegmentedControl・Form.DropDown・Form.ToggleSwitchなど6種類を使用しています。

// 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より手動の方が早く確実だったため、デザイナーがFigmaで直接修正しました。AIと手動を状況に応じて使い分けられる点が、このフローの利点です。

そして完成へ

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

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

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

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

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

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

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

Spindle UIにはコードにLinkButtonコンポーネントがある一方、Figma上には同名コンポーネントがなく、Code Connectを設定しても紐づけ先がないという状態でした。今までの開発フローならデザイナーにFigmaコンポーネントの作成を依頼するところですが、上述のお辞儀ポーズと同じ流れで、use_figmaを使ってFigmaに直接コンポーネントを作成してみました。

既存Buttonの構造をget_design_contextで読み取り、同じトークンとAutoLayout設定を踏襲しつつuse_figmaで30バリアントを一括生成しました。デザイナーへの依頼もFigmaの手動操作も不要で、プロンプトだけで一連の作業が完結しています。

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

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

View Transition PRの例

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

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

OGP画像生成ツールの例

別のデザイナーは、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によって専門外への越境が容易になる一方、得意な領域では今までと変わらず自分の手で仕上げられます。越境と本職の両方が地続きになることで、速度と品質がともに上がったと感じています。

デザインシステムとAIの相性

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

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

使用したMCPサーバー

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

おわりに

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