Figma Make + CodexでAIコーディングを達成する

Date2026/02/26
Last Modified2026/03/02

概要

Figma Make + Codexで挑んだデザインコーディングの続編で、おおよそ自分なりのフローができたのでまとめる。

成果物の前提条件(社内ルール等)

  • HTML/CSS/JSで生成すること。
  • png画像はもれなくwebp画像にすること。
  • svgアイコンはファイルにすること。
  • 人が手直しすることはなく、エージェントに指示を出して直してもらえるくらいの形にする。

手順

何度か試した中で、おそらく最適な手順を以下に示してみる。

0. 事前準備

Playwright-MCPはかなり有用なので、あらかじめ用意。
今回はChatGPT有料プラン(business)で、GPT-Codex-5.3 highを利用する。
Figma Makeは無料の月内クレジットが残っていれば生成可能。Figma MCPは利用しないので、Devモードへの課金等は不要。
適宜オリジナルのAGENTS.mdなどを用意。

1. Figma MakeでPC版とSP版を同時に生成する

一番重要なのはここ。
Figma Makeではフレームを複数個添付できるため、「w=1440pxをPC版, w=390pxをSP版としてレスポンシブに生成して」のように指示すればよい。
これを個別にやってしまうと、統合したときに「SP版のメディアクエリになったらJSで動的レンダリングする」のような地獄の仕様になってしまい修正が大変になる。

2. ローカルに取り込んでチェック

zipでダウンロードを行い、npmのセッティングをしてローカルで確認を行う。

npm install
npm run dev

Figma Makeで見たものと相違ないかをチェック。だいたいいくつかデザイン崩れがあるが、後で直していく。
この時点でいったん、Gitにコミットしておく。ここから怒涛の修正を入れる。

3. Codexに依頼して、HTML/CSS/JSで再生成する

どのように生成していくかは、Planモードでプロンプトを精査していく。(まとまってきたらSkill化を検討中)
一時出力において、個人的に気を付けているポイントは以下の通り。
[ ] 単一のHTML/CSS/JSファイルにまとめる(default.cssなどは別とする)
[ ] BEM記法にして、修正指示でクラス名を参照しやすくする
[ ] 「デザインを忠実に再現する」という指示を忘れない
[ ] Tailwindのような単一ユーティリティクラスを作成せず、レイアウト単位でのクラス化を要求する
[ ] 正しいクラスの出力例を添える

Reactで出力された例と見比べて、まったく同じデザインになっていることが大事。
ここで少しの差異を許すと、後で正しいデザインを伝えるのが難しくなってしまう。

(3.2追記)  
Tailwind -> BEM記法という指示だと、単にユーティリティにクラス名を付けるという意味で解釈されてしまう。  
ゆえに、レイアウト単位での出力を明示する必要あり

4. 修正指示で保守性をなるべく上げる

静的なページに変換した後は、パフォーマンス改善も含めて以下の点に留意する。
[ ] SVGはファイルにして外部化する
[ ] 画像のファイル名は「文脈から再命名して」と指示する [ ] フォーマットしたときにテキストに改行を入れないようにする
[ ] すべての変更は「段階的」ではなく「一括で」行ってもらう
[ ] スタイルの誤りは追記ではなく上書きさせる。意味が重なるものは削除

煮詰まってくると、だんだんと!importantを多用して無理やりスタイルを付けようとしてくるので、崩壊し始める。
特にTailwindの雰囲気を残そうとしてくるせいで、インラインスタイルや複数CSSファイルを参照しようとして勘違いしてしまう。 これは互換性を残して変更したいという習性によるもので、少なくとも新規の場合は不要な考え方なので、きちんと上書き修正させる必要がある。
また、インデントなども自動フォーマットだと対応を間違える場面がある。例えば

<p>
    テキスト
</p>

のようにフォーマットすることがあり、これだと余計なスペースが入ってしまう。
なので、テキストを入れる要素(h1~6, p, span, liなど)は、一行で記述するように指示する。

また、Playwright MCPが実際にSP版の大きさで出力できず、2xの大きさを基準で出力しているようなので、そのあたりで認識齟齬がある事も。

ひとまず、意図と違うスタイルが出力された場合は、

私の意図は〇〇してほしいということでしたが、〇〇というスタイルになってしまっています。
なぜそのような出力結果になったのかを説明してください。

のように質問して、一つ前のバージョンと比較しながら再生成してもらう手順を取る。

現時点の総評

試行錯誤しながら3~4日かけてエージェントベースのデザインコーディングをしてみた感想。

  • 具体的に指示を出せばほとんどの場合直してくれるので希望はでかい
    うまくデザインされていないのは大抵指示の不足であって、原因を聞きだして再生成すれば解決する。
    かなり昔のバージョンもバックアップを取りながら進めてくれるので、「二度と元に戻らない！」なんて心配もない。

  • トークンの使用量が半端ない
    小～中規模のプロジェクトでガンガン回しまくった経験はあれど、ChatGPT Business版では消費トークンはせいぜい50%程度だった。
    しかし、今回のデザインコーディングを全力で回した結果、残り15%くらいになってしまった(他の業務に支障が……)
    何度もバックログを参照させたり、曖昧な指示でコンテキストを大量消費してしまったのが原因だと思うので、このあたりはSkill化などして改善していきたい。

  • 保守性で言うと、30/100点くらい
    直したい部分は一応クラス名で辿れるようにはなっているのと、新規追加するときに似たパーツの再利用をしたい場合は具体的に指示を出せば修正はできる。
    けれど、直感と異なるレイアウトだったり複雑な構造になっていたりと、手動でちょいと直すというのはかなり難しくなりそうだ。
    おそらく、100回近くプロンプトを投げて修正を入れた結果こうなったのだと思うが……。それでも手修正の経験がある身からすると、簡単な修正もエージェント経由じゃないと難しいというのは、結構ストレスになるかもしれない。
    デザインまったくわからない、初心者がやるのであればお勧めできる。でもそういう機会は実務じゃ少ないかな～……。 まだまだ課題あり。ルールをもっと整備したり、レイアウトの具体的な指示など、工夫次第ではもうちょっと改善できるはず。

  • 疲れた！！
    システムは要件を整理するのにロジック的な思考をするけれど、デザインはレイアウトを説明しないといけないので、久々の筋肉を使った気分……。
    バックエンドのエージェント化は、少なくとも自分のやってきた範囲では「よしなに」感があったが、デザインは本当にパワハラ並みの指示量だった。
    視覚を再現するというのはなかなか難しい。「創造」は得意だけど「再現」はやっぱり大変なんだな、と改めて思ったのであった。

また何か改善しそうだったら、進捗を記事にまとめていきたい。

追伸
なんかCodex GUIのアプデが来てて、MCPが使いやすくなってるみたい。こっちも気になるなぁ