Claude Codeで完璧なFigmaを出力させたい
Claude Codeに「この画面、Figmaに起こして」と頼むと、Figma上に数分でフレームが出てきます。
ただ、一見して完成品でもデザイナー的には未完成です。
配置や既存画面の情報設計を無視していることも多く、そこは押さえていても色にはデザイントークンの変数を当てずにカラーコードが直書きであるなど。
また、ボタンやテーブルは既存コンポーネントのインスタンスではなく、パッと見ではそれっぽいけどよく見ると素のフレームであることも多いです。
見た目の観点でもデザイン運用の観点でも不十分で、修正指示を送ることすら面倒な気持ちになります。
仮にパッと見が合っているなら何が困るのか。
わざわざFigmaでデザインシステムを管理している意味がなくなる
- ブランド色やステータス色を変えたいとき、変数が当たっていれば1箇所直すと全画面が追従します。直書きだと1個ずつ直接直すことになります
- ダークモードやテナントごとの配色にも追従しません
- コンポーネントのインスタンスでなければ、あとからボタンの高さを変えても、そのフレームだけ取り残されます
結局、単体の要素としては許容できても、プロダクトとしてデザインに継続して一貫性をもたせるためには、1つ1つレビューし、手で直すことになります。
生成は数分だけど、直しはその何倍となると、何のために生成させているのかわかりません。
前提として、UX観点でのあるべき姿や審美的な観点でのレビューは、引き続き人間がやるべきだと思います。
ただしAIに任せるなら、インスタンス適用や変数適用、フレーム構成、などの本質的じゃない部分については、人が作るFigmaよりも一層完璧なFigmaを出力させたいです。
この記事は、そのレビューと修正の工程までClaude Codeに任せるために組んだ仕組みの話です。
(そもそもFigmaいらないんじゃないか? という議論については後半に触れます。)
まず、結果から
Claude Codeを通じて清書したばかりの画面を作った会話とは別のAIエージェントに全数検査させてみました。
清書というのは、ラフをデザインシステムに沿って整え、実装に渡せる状態にしたもののことです。
結果、変数が当たっていない生の色指定が31件でてきました。
スクリーンショットを何度も見比べて「もう大丈夫」と自分で判断したあとの画面からです。
その後もチェックを通したはずの清書から10件、2件と続けて出てきました。
「パッと見は正しいけどトークンに準拠していない」という状態は目では見えません。
作ったAI本人に「確認して」と頼んでも、自分の仕事は甘く採点しがちです。まあ人間と同じですね。
見えないものを見るには、見る係を別に立てるしかない。
この試行をそのまま仕組みに固めました。
結果、私の役目は「レイヤーを全部開いて確かめる人」から「検査結果の裁定に立ち会う人」に変わりました。
手で直す作業はゼロとまではいませんが、どこを直すべきかが実測値つきのリストで出てくるので、確認にかかる手間が全然違います。
UXや審美的なレビューは前提どおり今も自分でやっています。変わったのはその手前の機械的に判断がつく部分です。
以下はその仕組みと、回してみてわかったことです。
コードの世界では、ループの次にグラフが来た
ご存じの方も多いと思いますが、この仕組みの元になっている考え方を改めて書いておきます。
今年の6月上旬、Claude Codeを率いるAnthropicのBoris Cherny氏が「もう自分ではClaudeにプロンプトを打たない。ループを書くのが仕事だ」という趣旨の発言をしました。Peter Steinberger氏の「コーディングエージェントにプロンプトを打つのはやめて、エージェントにプロンプトを打つループを設計しろ」という投稿が広く拡散して、Addy Osmani氏がこれにループエンジニアリングという名前を付けています。
人が毎回指示を出す役を降りて、「作業を渡す・結果を確かめる・次の一手を決める」までをシステムとして設計する。
そういう考え方ですね。「書いた本人に採点させない」という原則もこの中に入っています（日本語ではこの記事が実践手順まで解説しています）。
翌月には、その続きにあたるグラフエンジニアリングの議論が出てきます。
ループを1本回すのではなく、役割の違うノードを並べて、どういう条件でどこへ渡すかまで設計しようという話です。ノードはLLMでも、決定的な関数でも、人間でもかまいません。
ループが要らなくなったわけではありません。
ノード1つの内側でAIが考えて動く部分は今までどおりループで、その外側に「ノード同士をどうつなぐか」という設計対象が増えた、という関係です（日本語の解説はこちら）。
この記事でやっているのは、この「結果を確かめる」の係を別のAIに分けて、デザインの機械的な部分に当てた、というだけの話です。
出典と時系列（2026年6〜8月）
- 6月上旬: Boris Cherny氏（Anthropic、Claude Codeを率いる）が「もう自分ではプロンプトを打たない。ループを書くのが仕事」という趣旨の発言
- 6月7日: Peter Steinberger氏の投稿が拡散。同日、Addy Osmani氏がLoop Engineeringを公開し、名前が定着
- 6月9日ごろ: 0xCodez氏の14ステップのロードマップ。日本語の解説記事が扱っているのはこれ
- 7月4日: Josh Simmons氏のWe are entering the graph engineering phase
- 7月18日: Steinberger氏が「まだループの話か、もうグラフに移ったか」と投稿し、グラフエンジニアリングの議論が広がる
- 8月5日: 日本語の解説Graph Engineering とは。8月13日にHexabaseの記事
作る係と検査する係を分けた
登場するAIは2者だけです。デザインを作るClaude Codeと、それを検査する別のAI。
作る側が生成し、検査する側が違反を挙げ、作る側が裁定して直す。合格すれば実装へ、2周しても収束しなければ私に戻ってくる。
グラフの語彙で言えば、係がノード、受け渡しの条件がエッジで、私も終端のノードの1つです。組んだのはこれだけです。
検査する側は、デザインを作った会話の文脈をまったく共有していない別のエージェントとして立てます。
検査係に見せるのは、変数が当たっているか、インスタンスになっているか、余白や角丸がトークンの値か、といった機械的に判断がつく項目だけです。UXの良し悪しや審美的判断は、前提どおりメインは人間が担当のままです。
この検査係には、3つのルールを課しています。
ルール1：検査係は、直してはいけない
検査係にはファイルの変更・作成・削除を禁止して、報告だけをさせます。
指摘には「対象・実測値・期待値」を必ず添えさせ、スクリーンショットの見た目ではなく、FigmaのAPIで読んだ実測値だけを証拠として認めます。「たぶん違反していそう」という推測は書かせません。
ルール2：検査係の言うことを、鵜呑みにしない
検査係は経緯を知らないからこそ公平に見られるのですが、同じ理由で冤罪も出します。
実装仕様どおりに置いた要素を「仕様にない」と指摘してきたり、あえてプロトタイプに寄せた箇所を「実装と違う」と挙げてきたり。実測値そのものに解釈が混ざることもあります。
鵜呑みにして画面を壊した例
半透明の塗りに「透明度が二重にかかっている」と指摘され、そのまま直したらバナーがベタ塗りになりました。変数側が持つ透明度をFigmaが表示上ミラーしていただけで、同じファイルの他の箇所も全部同じ値でした。
なので指摘は一旦、経緯を知っている側のClaude Codeが裁定して、直すものと退けるものに分けます。
直す前に同じプロパティを他の正常な箇所でも読んで、本当に外れ値なのかを確かめる手順も入れました。退けた理由は私にも報告させます。
ルール3：2周で決着しなければ、人間に返す
指摘を直したら、同じ検査係に差分だけを再検査させます。全部を見直すより速いからです。
合格が出れば終わりにして、2周しても違反が残る場合は止めて、残った違反リストを私が引き取ります。
何周回しても消えない指摘は、たいてい機械的な修正ではなく判断が必要なものなため。
デザインには、テストがない
コードの世界でこの手のやり方が成立するのは、テストという答え合わせの装置があるからです。デザインにはそれがありません。
ここを埋めずにAIどうしで検査させると、それらしい体裁の指摘が並ぶだけで中身がない状態になります。
Carlos E. Perez氏はこれを「整然としたナンセンス（organized nonsense）」と呼び、グラフエンジニアリングを解説したこちらの記事が一番厄介な落とし穴として紹介しています。
すべてのループが別のループを見ているが、どのループも地面に触れていない
— Carlos E. Perez（上の記事の訳より）
だからエージェントの評価をエージェントに任せるなら、システムの外側にある決定的な証拠が要る、という話です。
テストの部品を次のように置き換えました。
| テストで言うと | 私たちの検査では |
|---|---|
| 期待値 | 実装仕様やスタイルガイドの記述。「正解」として検査係に渡す |
| 実測値 | FigmaのPlugin APIで読んだ値。「証拠」はこれだけ |
| 判定 |
fillsに変数がバインドされているか、paddingがトークンの値と一致するか |
ここは感想ではなく、読めば判断がつきます。
逆に言うと、読んでも白黒がつかないもの、つまりUXや審美的判断はこの検査に乗せていません。テストの代わりになるものを外に用意できる範囲に絞る、というのが、デザインに持ち込むうえで必要だった読み替えでした。
手元でどう動かしているか
道具立てはシンプルです。Claude CodeにFigma公式のMCPサーバーをつなぐと、会話からFigmaファイルのノードを読み書きできるようになります（MCPは、AIエージェントに外部ツールをつなぐための規格です）。
私たちのやり方ではまずHTMLでプロトタイプを作って見た目を固め、それをFigmaのフレームに変換しています。
HTMLをフレームに変換するのがgenerate_figma_designで、Plugin APIのコードを実行してノードを読み書きするのがuse_figmaです。検査係が実測値を読むのも後者です。
生成では、変換したフレームの素の矩形をデザインシステムのコンポーネントに差し替え、色や書体に変数をバインドしていきます。モデルは普段、Fable 5.1とOpus 5をその時々で切り替えています。
使っているモデルについて
この手法はOpus 5.5が出る前に作ったもので、Fableを使わずにOpus 5でも回せるように整えてきました。執筆中にOpus 5.5が出てモデル自体の性能が上がったことで、検査時のエラーも減り、清書がスムーズに通るようになりました。記事の実測値は、どれもOpus 5.5が出る前に測ったものです。
グラフだのノードだのと書きましたが、専用のフレームワークは使っていません。 要るものは3つです。
- Claude CodeとFigma公式のMCPサーバーの接続
- 「検査は文脈を共有しない別のサブエージェントに、読み取り専用でやらせる」という約束
- 「正解」にあたる資料。実装仕様がなければ、スタイルガイドやデザイントークンの一覧で十分です
ラフ作成後に以下のような指示を書くことで実現できます。
Figmaの以下のフレームを、実装に渡せる状態（清書）まで仕上げてください。
対象: https://www.figma.com/design/xxxx?node-id=10059-144587
■ 手順
1. まず自分で清書する。素の矩形はデザインシステムのコンポーネントのインスタンスに差し替え、
色・テキストスタイル・余白・角丸は変数（トークン）にバインドする。
2. 清書が終わったら、検査を別のサブエージェントに依頼する。
このサブエージェントには、この会話の文脈を渡さないこと。
3. 検査結果を受け取ったら、指摘ごとに「直す／退ける」を裁定して直す。退ける場合は理由を書く。
直す前に、同じプロパティを他の正常な箇所でも読んで、本当に外れ値かを確かめる。
4. 直したら、同じ検査係に差分だけを再検査させる。
5. 総合判定がPASSなら終了。2周しても違反が残る場合は止めて、残った違反リストを私に返す。
■ 検査係への依頼に必ず含めること
- ファイルの作成・変更・削除・移動は禁止。報告だけ。
- 検査観点:
A配置（既存画面との情報設計の整合）
Bトークン準拠（色・テキストスタイル・余白・角丸・gap。余白も必ず見る）
C実装忠実性（下の実装仕様を正解とする）
D視覚品質（見切れ・重なり・はみ出し）
- 証拠はFigma Plugin APIで読んだ実測値だけ。スクリーンショットの印象で判定しない。
- 実測に基づかない推測は書かない。
- 出力形式: [重要度] / 対象ノードID / 事実（実測値） / 期待値 / 修正提案。最後に総合判定PASS / FAIL。
■ 正解（実装仕様・スタイルガイド）
ここに実装コードを読み取った仕様とclaude.mdに記載したデザイントークンの一覧を正解とする。
やっていることは、前の節の3つのルールをそのまま文章にしただけです。
ただ、毎回これを書くのは面倒で、書き忘れも出ます。実際に観点を1つ落として痛い目を見た話は、あとの節で書きます。
なのでこの指示を丸ごと、Claude CodeのSkillに移しました。Skillは、手順や判断基準を書いてAIに渡しておくMarkdownの手順書です。今はラフ作成が終わったところで、こう投げるだけです。
このFigmaファイルのフレームを検査・改善ループを通じて清書してください。
上の長い指示は全部スキルの中にあって、Claude Codeがそれを読んで実行します。「正解」の資料も、実装コードから仕様を抽出する手順ごとスキルに入れてあります。スキルがなければ、長いほうをそのまま投げれば同じことになります。
返ってきた裁定の報告には、退けた指摘とその理由が並びます。私がそこだけ読めば十分です
全部を検査するのはやめた
一度うまくいくと、何にでも検査を付けたくなります。
ただし、実際に試したもののやめました。
理由は待機時間とコストです。
検査1周あたり、AIの消費量にして8万〜13万トークン。画面1枚ほどの規模での実測です（ここでのトークンはデザイントークンじゃなくて、AIが読み書きする文章量の単位のほうです）。
アイデア出しの段階の画面にまで毎回これを回すと、時間もトークンも無駄にします。
今は、回すのは実装に渡す直前の清書だけと決めています。アイデア出しの段階は、ディテールの部分は大事ではないため全数検査は要りません。
清書のとき以外の、ループ／グラフの使いどころ
1画面ずつの検査とは別に、Claudeの週ごとの利用上限がリセットされる直前に枠が余っていたら、重い依頼をまとめて投げています。「ページ全体でスタイルのルール違反をループ形式で検査・修正して」「情報設計をユーザビリティの観点で検査して、複数のパターンを出して」といった類のものです。
このときは思考量をultracodeに上げています。思考を深くしたうえで、複数のエージェントを使うワークフローをClaude Codeに自動で組ませるモードで、1画面の清書には重すぎますが、ページ全体を相手にするならちょうどいい重さです。
グラフの中身より、どの工程で回してどこでは回さないかを決めたことのほうが有効でした。
検査装置と採点基準は別に育てる
仕組みだけあっても機能しません。検査係に「何がダメか」を渡さないと、見えているものを違反にできない係になります。
今年の8月に、それで痛い目を見ました。
観点に無いものは、見えていても違反にならない
検査観点として色と書体は入れていたのに、余白を入れていなかったのです。検査係はpadding 14,18,16,18という値をちゃんと読んで報告していました。ただ「事実」として書くだけで、違反には挙げませんでした。カード47枚の余白がトークンから外れたまま通過していました。
この採点基準は、さっきのスキルに書いています。
- 変数の付け方
- コンポーネントの使い方
- 過去に踏んだ失敗のリスト。新しい失敗が見つかるたびに、ここに一行足す
ノードの配線が検査を担当し、スキルが「何をもって合格とするか」を担当する分業です。
グラフの形をどれだけ工夫しても、各ノードの判定精度は別の変数です。
判断基準を会話の外に書き出してスキルとして持つ考え方は、同僚のこの記事が詳しいので、あわせてどうぞ。
検査を並列にしてみた
観点を1つの検査係に全部背負わせていると、観点が増えるほど1回の検査が重くなります。
そこで観点ごとに検査係を分けて同時に走らせ、結果を1つにまとめてから裁定に渡す形を試しました。グラフエンジニアリングの語彙で言うfan-outとfan-in（分岐と合流）です。
実装に渡したばかりの画面を1枚選んで、同じフレームを2通りで検査させました。1体に3観点をまとめて渡した場合と、トークン準拠・レイアウト整合・コンポーネント規約の3体に分けた場合です。
1フレーム・1回ずつの比較なので、以下は傾向ではなく実例として読んでください。
| まとめて1体 | 分けて3体 | |
|---|---|---|
| 違反件数 | 21件 | 130件 |
| 消費トークン | 18万 | 40万（2.2倍） |
| 実時間 | 10分 | 8分（並列なので最長の1体分） |
件数の差にはあまり意味がありません。分けたほうは余白の違反をプロパティ単位で数えていて、まとめたほうは同じ内容を1件にたたんでいるからです。件数ではなく、中身が違いました。
分けたほうだけが見つけたもの
はっきり差が出たのは見落としです。
レイアウト担当の検査係が、タブの1つだけ幅が160pxで固定されていて、議事録フォーマット名が「営業向け（次アクシ…」と切れているのを見つけました。横に882px空いているのにです。
まとめたほうは、これを見つけられませんでした。それだけなら見逃しで済むのですが、報告書にはこう書いて、合格だと明言していました。
全テキストの描画範囲（absoluteRenderBounds）はノード内に収まる。クリップによる文字の欠けは無し
切れた文字は省略記号に置き換わるので、描画範囲だけ見ると収まって見えます。それらしい検査をして、それらしく通す。 前に書いた「整然としたナンセンス」が、手元で出た形です。
ほかに、ボタンがカードに24px食い込んでいる件と、セクションの本文が1つだけ4px右にずれている件も、分けたほうだけが見つけました。
まとめたほうが良かった点
私が渡した採点基準のうち2つが間違っていて、まとめたほうはそれを自分で却下してきました。
「カードの角丸は12」と書いて渡したのに、このファイルのカードコンポーネントは実測8で、デザインシステムのキットに準拠しているのはむしろ現状のほうだ、という指摘です。
トークン担当の検査係は同じ箇所を違反として挙げ、「規定が正ならバインド先の選び間違い、8が正なら規定の記載が古い」と判断を私に投げ返してきました。担当の外にあるコンポーネントの実値までは見に行かなかったので、自分では決めきれなかったのです。
観点を分けると、境目に落ちるものも出ます。フレーム名の乱れ6件は、コンポーネント担当が「インスタンス名の上書き」しか見ていなかったので、まとめたほうしか拾えませんでした。
結論が正反対になった箇所
あるフレームについて、まとめたほうは「コンポーネント名と紛らわしいのでリネームしろ」、コンポーネント担当は「これはインスタンスが剥がれた（detachされた）残骸なのでインスタンスに戻せ」と言ってきました。
こういうものが出てくると、裁定は人間の仕事に戻ります。
この1回では、分けたほうが見落としは少なく、そのぶん裁定の仕事が増えました。文脈を持たない検査係を3体に増やしたのだから当たり前で、前半に書いた「鵜呑みにしない」がその分だけ重くなります。消費トークンも2.2倍です。
先に触れたグラフエンジニアリングの解説記事も、まず1本のループと本物の検証器と強制停止から始めろ、という助言を紹介しています。
今のところの落としどころ
並列にするのは、実装に渡す直前の最後の1周だけ。普段の周回は検査係1体のままにしています。
そもそもFigmaは要るのか
ここまで読んで、そこまで手をかけるならFigmaを介さずコードを直接生成すればいい、と思った人もいるはずです。
中間の制作物としてFigmaはもう要らないんじゃないか、という議論もあります。
この議論に対して、私は中立です。 正直、Figmaなしでもデザイン・開発はできると思いますし、もうFigmaは要らないかも? という気持ちはあります。
それでも今もFigmaを使っている理由は2つあります。
ひとつは、誰でも資料や既存の実装を並べて見渡せて、個人としてアイデアを発散させるホワイトボードとして便利なこと。
もうひとつは、細部の調整をいちいちAIに指示せず、手で直せること。
現時点でこの2つは、Claude Designのようなツールや、デザインを挟まないvibe coding形式ではやりづらいところだと思っています。
今のチーム状況や自身のスキルを考えたときに、Claude CodeとFigmaを掛け合わせるのがベストだと思っていて、引き続きFigmaを使うやり方をしています。
最終的なプロダクトのクオリティとそれに至るスピード感が何よりも大事
その前提に立った上で、トータルで考えてFigmaを使わないもっと良い手法があればすぐにでも取り入れたいと思っています。
なので、デザインシステムとしてFigmaを運用しつつ、Figma上でデザインを作成する時間やメンテナンスにかかる時間を削減したい場合の一つの手法として、この記事は読んでください。
一緒に設計する人を探しています
私が所属するSapeetでは、ソリューションデリバリーやプロダクト開発に加えて、こういう「AIへの任せ方の設計」を日常的にやっています。
開発の文脈では、デザイナーやPdM、エンジニアの境界が今後溶けていくと感じています。AIに任せる部分が増えるほど、任せ方の設計そのものが大事な仕事になっていきます。
面白そうだと思った方は、採用ページからぜひ👇