Figmaからコードを自動生成する実験で、最初の実装は5分でトークン上限に達した。原因はテストパターンの過剰指定。Agent構築、コード生成、仕上げの3ステップで異なるLLMを使い分け、最終的に実用化できるパイプラインを組んだ記録。

Figmaコーディング自動化で、最初にぶつかる壁

「Figmaのデザインから自動でReactコンポーネントを吐かせたい」。SaaS開発をしているクライアントからの依頼でした。

デザイナーが作った画面を、フロントエンドエンジニアが手作業でコーディングしている。納品までのリードタイムを短くしたいという要望です。最初は Claude に Figma の JSON を渡してコンポーネントを生成させた。出力は速い。ただ、5つ目の画面を渡した時点でトークンが尽きた。

原因は、テストパターンを全て含めた指示を毎回送っていたからです。ボタンの状態パターン、フォームのバリデーション、レスポンシブ対応。全て1プロンプトに詰め込んだ結果、コンテキストが膨れ上がった。

Agent、生成、仕上げで LLM を分けた

方針を変えました。処理を3つに分割し、それぞれ異なるツールを使う。

まず、Figma JSON をパースして必要な情報を抽出する Agent を Claude Code で作った。レイヤー構造を読み取り、コンポーネント名、props、子要素の関係を構造化する。ここは対話形式で要件を詰めていく作業だったため、会話ベースの Claude Code が向いていた。コンポーネントの命名規則をどうするか、どこまで階層を分けるかといった設計上の判断を、コードを見せながら確認できた。

次に、構造化されたデータから実際の React コードを生成する処理は Cursor に任せた。すでに既存のコンポーネントライブラリがあり、スタイルの適用ルールも決まっていたため、プロジェクトのコンテキストを理解した上でコード補完してもらう方が精度が高い。Cursor はエディタ内で、既存ファイルを参照しながらインラインで提案を出す。この段階では指示を最小限にしても、期待通りのコードが返ってきた。

最後に、生成されたコードのレビューと微調整は Codex で行った。import 文の整理、型定義の補完、不要な props の削除。既存コードとの整合を取る作業では、Codex のファイル横断の補完が速かった。

トークン消費を抑えるために削ったもの

実装後、トークン消費量を測定しました。最初の構成では、1画面あたり平均 18,000 トークンを使っていた。3ステップに分けた後は、同じ画面で 6,200 トークンまで下がった。

削ったのは、テストコードのパターン指定です。当初は「ボタンのホバー時」「disabled 時」「ローディング時」といった全状態のテストを自動生成しようとしていた。これをやめて、コンポーネントの構造だけを出力し、テストは別途人間が書くことにした。結果、トークン消費は 3分の1 になり、出力速度も上がった。

もう1つ削ったのは、CSS の詳細指定です。Figma にはピクセル単位のスタイル情報が全て含まれている。それを全て props として渡そうとすると、プロンプトが膨らむ。最終的には、色とフォントサイズのみを渡し、余白やレイアウトはデザインシステムの既定値を使うルールにした。

自動化の精度は、何を諦めるかで決まる

実装から2ヶ月。現在、このパイプラインは週に15〜20画面のコード生成に使われています。ただし、生成されたコードをそのまま本番に投入することはない。エンジニアがレビューし、必要に応じて手を入れる。

自動化の目的は、エンジニアをゼロにすることではなかった。デザインをコードに起こす単純作業を減らし、状態管理やエラーハンドリングといった設計判断に時間を使えるようにすることでした。完全自動化を目指してトークンを浪費するより、70%の精度で安定稼働する方が、実務では役に立つ。

あなたのプロジェクトで Figmaコーディング自動化を試すなら、まず「何を自動化しないか」を決めることから始めてください。