デザイン修正の手戻りはデザイナーの説明不足だけで生まれるわけではない。
Figma上では完成しているのに、実装担当が余白や状態変化の意図を読み直し、コードへ移した後にデザイナーが再確認する。
小さな変更ほど依頼、実装、確認の往復が相対的に重くなり、公開を遅らせる。
Figma Makeが狙うのは、この受け渡しを短くすることだ。
Figmaは2026年5月、既存コードをローカルで扱い、デザインの注釈や会話を手掛かりに編集し、GitHubのプルリクエスト作成まで進める新機能を限定ベータとして発表した。
さらに6月にはGitHubリポジトリやローカルフォルダを取り込み、コードをFigmaのキャンバスへ持ち込む流れを紹介している。
ただし、「デザイナーだけで本番実装が完結する」と読むのは早い。
発表時点の新機能は対象者が限られ、生成コードの正しさもコードベースごとに異なる。
価値が出るのは、UI修正を小さく切り、変更差分を開発者が検収できるチームだ。
本稿では公開済みの公式情報と編集上の判断を分けながら、安全に試せる範囲を整理する。
従来のFigmaは、画面の見た目、コンポーネント、プロトタイプ、開発者向け仕様を共有する場所として強かった。
コードは別のリポジトリにあり、デザイン変更を実装へ移す作業は、チケット、コメント、口頭説明を介して開発者へ渡される。
Dev Modeが距離を縮めても、最終的な変更主体はコード側に残っていた。
Figma Makeの新しい流れでは、既存コードを作業の起点にできる。
公式のWorkflow Labはコードベースを接続し、対象ページを表示し、デザイン上で変更を指示し、チームで確認した後にPRへ進む例を示した。
FigmaのMCP Serverを使った社内例でも、デザインで追加した状態をコンポーネントへ戻し、GitHubへ送れる差分として用意する使い方が紹介されている。
事実として確認できるのは直接編集、注釈、チャット、PR作成を含む機能が2026年5月28日に限定ベータとして始まり、当初はMac向けBeta desktop appに限られ、ベータ中はクレジットを消費しないという点だ。
AIクレジットの価格は後日発表予定とされていた。したがって、通常版Figma Makeの料金や利用条件と、新しいローカルコード連携の提供条件は分けて記述する必要がある。
編集上の推論として、最大の変化は「デザインからコードへ一方向に渡す」工程が、同じ変更をデザインとコードの双方から検討する共同作業へ近づくことにある。仕様書をなくすというより、実物の差分を会話の中心へ置ける。修正後の画面とコード差分が同時に見えるなら、抽象的な説明に費やしていた時間を検収へ回せる。
一方、Figma Makeが既存の開発環境、CI、テスト、コードレビューを置き換えるわけではない。
リポジトリには設計規約、依存関係、型、データ取得、セキュリティ要件があり、画面だけを見ても判断できない制約が多い。
Figma上で見栄えが合ったことは、本番品質の証明にならない。
最初に対象を「一つのページ、一つのコンポーネント、一つの変更目的」へ限定する。
たとえば、料金ページのカード間隔を調整し、スマートフォン表示でCTAを下部へ移し、既存の色トークンだけを使う、といった単位が扱いやすい。
サイト全体を刷新する指示では、意図しないファイルまで変わり、レビュー可能性が落ちる。
次に、作業用ブランチとローカル確認環境を用意する。
生成AIへ本番ブランチの直接更新権限を渡さず、読み取り対象と書き込み対象を分ける。
環境変数、顧客データ、秘密鍵を含むファイルは対象外にし、必要なコンポーネントとデザインシステムだけを読み込ませる設計が望ましい。
Figmaへコードベースを接続したら、変更対象の画面を開き、現状と修正後の条件を明示する。
「モバイルで見やすく」だけでは基準が曖昧だ。
対象幅、既存トークン、変更禁止領域、動作状態、受け入れ条件を一緒に渡す。
Figmaの注釈は、画面上の位置と意図を結び付けやすいため、文章だけの依頼より範囲を限定しやすい。
生成後はプレビューで見た目を確かめ、差分を読む。
意図しない依存関係の追加、ハードコードされた色や余白、既存コンポーネントの重複、不要なファイル変更がないかを確認する。
問題があれば変更を小さく戻し、指示を追加して再生成する。
完成後にまとめて直すより、一つの条件ごとに差分を確定する方が原因を追いやすい。
最後にPRを作り、通常の開発フローへ戻す。
PR本文には目的、変更ファイル、確認した画面幅、未確認事項、スクリーンショットを残す。
Figma MakeがPRを作れることと、そのPRを承認できることは別だ。
承認権限は開発責任者に置き、CIとテストを通してからマージする。
任せやすさは変更の難易度より「正解を観察できるか」で決まる。
文言、余白、色、アイコン位置、レスポンシブ配置、既存コンポーネントの状態追加は、画面と差分から合否を判断しやすい。
反対に、認証、決済、権限、個人情報、価格計算、データ削除は、見た目が正しくても内部動作の誤りが重大事故につながる。
指示には目的、対象、制約、完了条件の四つを入れる。
「購入ボタンを目立たせる」ではなく：
「商品詳細ページの購入ボタンをスマートフォン幅375pxでファーストビュー内に置く。
既存PrimaryButtonを再利用し、色トークンはbrand-primaryのみ。
価格計算、在庫処理、クリック後のAPIは変更しない。
既存テストを維持する」と書けば、変更範囲が読み取れる。
以下の分担表は、Figmaの公式保証ではなく、小規模チームがレビュー強度を決めるための編集上の整理である。
レビューでは、スクリーンショットの一致だけでなく「変更していないこと」を確かめる。
まずgit diffで対象外ファイルを探し、依存パッケージ、設定、API、ルーティングに意図しない変更がないかを見る。
差分が大きすぎるなら、生成結果を説明させるより作業単位を切り直した方が安全だ。
画面確認は少なくとも主要なスマートフォン幅、タブレット、デスクトップで行う。文言が長い日本語、未入力、最大文字数、通信失敗、読み込み中も試す。
通常状態だけ整っていても、エラー時にボタンが押せない、テキストが切れる、フォーカスが消えるといった問題は残りやすい。
アクセシビリティでは、見出し構造、ラベル、コントラスト、キーボード移動、フォーカス表示、画像の代替テキストを確認する。
AIが生成したaria属性が存在しても、意味が正しいとは限らない。
実際の操作順と読み上げ結果まで人が見る。
コード品質では、既存コンポーネントを再利用しているか、定数や色がハードコードされていないか、重複コードが増えていないかを確かめる。
自動テストが通ることは最低条件であり、テスト対象外の仕様まで保証しない。
新しい状態や分岐を足したなら、対応するテストも追加する。
セキュリティ上、Figma Makeへ渡す権限は最小限にする。
接続するリポジトリ、ブランチ、ファイル、外部ツールを限定し、秘密情報をプロンプトや注釈へ書かない。
組織で利用する場合は、生成内容の保存、ログ、外部コネクタ、管理者設定を公式ドキュメントと契約条件で確認する。
第一段階は、手戻りが多い一方で事故時の影響が小さい変更を一件選ぶことだ。
既存LPの余白調整、空状態の追加、文言変更などが候補になる。
決済画面や顧客データを扱う管理画面から始めない。
第二段階では、役割を決める。
デザイナーは目的と見た目の受け入れ条件、開発者は変更可能な技術範囲とレビュー、プロダクト担当は公開判断を持つ。
AIは実装候補を作るが、責任主体にはならない。
第三段階は作業環境の分離だ。
専用ブランチ、テストデータ、制限した権限を用い、復元方法も用意する。
限定ベータを使う場合は対象OSやアプリ、クレジット条件が変わっていないか、開始前に公式情報を読み直す。
第四段階では、同程度の修正を従来フローとFigma Makeで一回ずつ行い、依頼からPRまでの時間、往復回数、レビュー時間、修正件数を比べる。
生成速度だけを測ると、後工程の負担を見落とす。
第五段階で継続範囲を決める。
差分が小さくレビューしやすい作業は広げ、毎回大幅な書き直しが必要な領域は戻す。
成果が出ても、認証や決済へ自動的に範囲を拡張しない。
変更のリスクに応じて承認者とテストを増やす。
Figma Makeの注目点は、きれいなプロトタイプを素早く作れることだけではない。
既存コードを起点に、デザイン上の修正を差分へ変え、チームレビューとPRへつなぐことで、デザインと開発の往復を短くできる可能性にある。
同時に、2026年5月に発表されたローカルコード連携は限定ベータであり、提供条件や価格は確定した一般機能と同じではない。
画面が意図通りに見えることと、コードが安全で保守可能なことも別の評価だ。
小規模チームが試すなら、影響の小さいUI変更を一件選び、変更禁止領域と完了条件を先に書く。
生成結果は作業用ブランチへ置き、ローカル確認、テスト、アクセシビリティ、PRレビューを通す。
その運用で往復と修正が減るなら、Figma Makeは「デザイナーが開発者になる道具」ではなく、両者が同じ差分を見て話すための有力な作業面になる。
.png){kind=logo}
