PR: 本記事には広告・アフィリエイトを含む場合があります。
Figma to Code AI、2026年に入って一気に現場っぽい話が増えました。
結論から言うと、ネットの声は「下書きは頼もしい。でも納品物は人が見る」に寄っています。
自分も現場目線で見ると、ここは外せない論点だと思います。
ぶっちゃけ、Figmaからコードが出るだけで全部ラクになる、という話ではないです。そこを先にそろえたいです。
Figma to Code AIで、いま何が起きている？
Figma to Code AIは、FigmaのデザインをもとにHTMLやReactなどのコードを作る流れです。
Reactは画面部品を作るJavaScriptの仕組み、TailwindはCSSを短いクラスで書く道具です。
最近はFigma Make、Figma MCP、Cursor、Claude Code、Codex連携まで出てきて、とても速い勢いで増えています。
- Figma Makeは、文章から画面やプロトタイプを作る寄りです。
- Figma MCPは、AIがFigmaのレイヤーや変数を読む連携です。
- CursorやClaude Codeは、読み取った情報をコードに落とす側で使われます。
- Codex to FigmaやClaude Code to Figmaは、コード側からFigmaへ戻す流れです。
話題化した理由は、ここ半年の発表ラッシュ
2025年6月にFigma Dev Mode MCP Serverが広がり、2026年2月にはClaude Code to FigmaとCodex to Figmaの話も出ました。
2026年3月にはAIクレジットの上限や追加購入も現実味を持ちました。
やっぱり、機能より仕事に入れたときの費用と手戻りが気になりますよね。
使った人の声は「70〜80%までは速い」に寄っています
50件超の声を見ると、温度感ははっきりしています。
肯定側は「初速が速い」「たたき台がすぐ出る」「数値拾いがラク」。
否定側は「そのまま納品は怖い」「レスポンシブや設計で崩れる」です。
肯定側では、1画面のUI実装が短時間で進んだ、LPの下書きが一気にできた、レイヤー整理の手間が減った、という声が目立ちます。
Zenn・Qiita・note・個人ブログの声を要約
否定側では、コードが大きな1部品になりやすい、細かいズレが残る、デザインシステムまでは読み切れない、という教訓が多いです。
制作会社記事・海外レビュー・実装ログの声を要約
正直、「7割できた！」のあとに残る3割が、現場ではいちばん大変な部分だったりします。
noteの実体験は温度差を見るのにちょうどいい
コスト検証、冷静評価、個人ブロガーの挑戦など、noteには生々しいログがあります。
流れの中で読むほうが判断しやすいです。
肯定・否定・様子見をまとめるとこう見える
個人的には、Figma to Code AIの評価は「速いか」だけで見ないほうがいいです。
あとで直す人が困るコードだと、結局は時間がかかります。
逆に、初稿を人が整える前提なら、かなり頼もしい相棒になります。
| 分類 | よくある声 | 現場での見方 |
|---|---|---|
| 肯定 | LP下書き、画面再現、レイヤー整理が速い | 初稿づくりにはかなり向く |
| 否定・教訓 | 設計、レスポンシブ、保守性で手直しが残る | 納品前レビューは人が持つ |
| 中立・条件付き | Figmaファイルを整えるほど精度が上がる | Auto Layoutと命名が勝負 |
| 少数派 | Design System MCPやYAML化が本筋という声 | 将来は連携設計が重要になりそう |
ここで大事なのは、AIの良し悪しより前に、Figma側の整理です。
Auto Layout、コンポーネント化、命名規則が荒いと、AIも迷います。
これは外せないです。
「デザインが汚いけどAIなら読めるでしょ」は、現場ではだいたい遠回りです。やっぱり前処理が大事です。
立場別で見ると、期待値がかなり変わります
同じFigma to Code AIでも、個人ブログと受託案件では景色が違います。
個人なら「公開まで行けた！」でうれしいです。
でも受託では、引き継ぎ、保守、表示崩れ、権限管理まで見ます。
この差が、口コミの割れ方を作っています。
| 立場 | 期待していること | 引っかかりやすい点 |
|---|---|---|
| 個人ブロガー | アイデアをすぐ形にする | 費用枠と公開手順 |
| 副業Web制作者 | LPや社内ツールの初稿を速く作る | 本番納品との境目 |
| 受託フリーランス | 実装時間を減らす | 設計、規約、レビュー責任 |
| デザイナー | 会話できる試作品を作る | コード品質と設計思想のブレ |
個人的には、副業や小さなLPなら相性がいいです。
一方で、会員制サイトやECのように情報管理が重い案件は慎重に見たいです。
「AIが作ったからOK」ではなく、責任を持つ人を決めるところまでが仕事ですね。
ツール別に見る、現場での使い分け
Figma Make、Cursor + MCP、Claude Code + MCPは、同じ箱に入れると迷います。
正直なところ、目的が違います。
Figma Makeは「見せる試作品」、MCP連携は「既存デザインを読んで実装」と見ると整理しやすいです。
アイデア段階ならFigma Makeで触れる画面を作ります。
合意の速さが目的です。
Auto Layout、命名、コンポーネントを整えます。
ここを飛ばすと、あとで修正が増えます。
MCPでデザイン情報を読み、コードに落とします。
最後は表示確認と人間レビューで締めます。
正直、ツール選びより「どの段階で使うか」のほうが大事です。ここを混ぜると迷子になります。
料金と上限で、期待値はかなり変わります
Figma MakeはAIクレジット、Figma MCPはシートやツールコール上限、Claude CodeやCursorは月額プランが関わります。
LLMは大規模言語モデル、つまりChatGPTのように文章やコードを扱うAIのことです。
ここを見ずに「便利そう」で入ると、思った以上の請求になりがちです。
コスト面では、Figma Makeのクレジット消費や追加購入の重さを見て、プラン内でどこまで試すかを先に決めたい、という声がありました。
noteのコスト検証記事を要約
まずは小さなLPやポートフォリオで、1画面だけ試すのがラクです。
費用より、修正にかかる時間を見ます。
Figmaの整理、コード規約、レビュー担当を先に決めます。
AI出力を下書きとして扱う線引きが大事です。
自分なら、納品前提ではこの順番で試します
自分なら、いきなり案件本体には入れません。
まず小さなセクションを1つ選び、Figma MCPで読み、CursorかClaude Codeでコード化します。
そのあと、レスポンシブ、命名、コンポーネント分割、アクセシビリティを人間が見ます。
アクセシビリティは、見え方や操作しやすさを幅広い人に合わせる考え方です。
- 同じプロンプトを連投して偶然の当たりを待たない。
- Figmaファイルを整えずにAIへ投げない。
- アニメーションや細かい状態管理をAI任せにしない。
- 出力コードをそのまま納品物として扱わない。
- Starter枠だけでチーム運用を前提にしない。
個人的には、「AIで作る」より「AIが作ったものを直せる」ほうが、仕事では強いです。
公式情報と体験談はここで見直す
料金、上限、MCPの対応クライアントは変わりやすいです。
2026年6月8日時点では、公式ヘルプと実体験ログの両方を見るのが現実的です。
公式だけだと現場のしんどさが見えにくいです。
※掲載内容は執筆時点の情報をもとにしています。サービス内容・料金・仕様などは変更される場合がありますので、最終的には公式サイト等をご確認ください。
まとめ：Figma to Code AIは、下書き係として見ると強い
- Figma to Code AIは、下書きと試作品づくりで評価が高いです。
- ネットの声は、精度70〜80%くらいで人間レビュー前提に寄っています。
- 個人、副業、受託、デザイナーで期待値がかなり違います。
- 料金と上限は、課金前に公式情報で見直したいポイントです。
- 納品前提なら、Figma整理とレビュー体制までセットで考えるのが現実的です。
Figma to Code AIは、個人的には「仕事を奪う道具」より「下書きを一気に出す相棒」に近いです。
ここを間違えなければ、Web制作の現場でもかなり楽しい付き合い方ができると思います。
