Figma連携で精度を上げるプロンプトの分け方

Figma連携で精度を上げるプロンプトの分け方

この記事でわかること

  • FigmaのURLを渡すだけでは精度が安定しない理由
  • 「整理」と「実装」を分けて依頼する2段階の指示の出し方
  • 実際に使っているプロンプトの型

FigmaのMCPを繋いで、URLを渡せばコードが出てくる。ここまではすでに紹介しました。ただ、実際に使ってみると、いきなり「コーディングして」とだけ伝える依頼の仕方では、精度が安定しないことがあります。今回は、その精度を上げるために使っている、指示の出し方を紹介します。

いきなり実装させると起きること

FigmaのURLを渡して「これをコーディングして」とだけ伝えると、AIはその場で見えている情報だけを頼りにコードを組み立てます。

このとき起きやすいのが、次のようなことです。

  • 既存のコードにあるクラス名の付け方を無視して、新しいルールでクラスを作ってしまう
  • すでにあるコンポーネントを使わず、似たようなものを新しく作ってしまう
  • 本来触る必要のない、他のセクションのファイルまで書き換えてしまう

これは、AIが「今見えているデザイン」と「今のプロジェクトの状態」を、こちらが伝えない限り同時に把握できないために起きます。デザインの数値は完璧に読み取れても、それを既存のコードにどう馴染ませるかは、伝えないと汲み取ってもらえません。

2段階に分けて依頼する

そこで、依頼を1回で終わらせず、2段階に分けます。

1段階目:まず整理だけしてもらう
2段階目:整理した内容をもとに、対象を絞って実装してもらう

コードを書く前に、一度立ち止まって整理させることで、こちらが認識のズレをチェックできる一呼吸を作ります。

1段階目:整理を依頼するプロンプト

実際に使っている文面がこちらです。

Figma MCPを使って、指定したフレームのサービス一覧セクションを確認してください。

まずコードは書かず、以下を整理してください。

1. 使用されているコンポーネント・カラー・余白・文字スタイル
2. PC版とスマホ版で変わるレイアウト
3. 既存リポジトリ内で再利用できるコンポーネント
4. 新規作成が必要なHTML・CSS・JavaScript
5. 実装時に注意すべきアクセシビリティ・CMS・長文表示の問題
6. 変更対象ファイルと影響範囲

既存の命名規則とCSS設計を優先し、不要な共通クラスやライブラリは追加しないでください。

ポイントは大きく2つです。

まず「まずコードは書かず」と明示していること。これがないと、AIは整理と実装を同時に進めようとします。整理の段階で止めることで、実装前にこちらが内容を確認する余地が生まれます。

もう一つは「既存の命名規則とCSS設計を優先し、不要な共通クラスやライブラリは追加しない」という一文です。AIは何も指定しないと、新しい共通クラスや便利そうなライブラリを持ち込みたがる傾向があります。これを先に釘刺しておくことで、既存のコードに馴染む形を優先させます。

整理結果は必ず自分の目で確認する

ここで出てきた整理結果は、そのまま次に進めず、一度目を通します。

見るポイントは、「3. 既存リポジトリ内で再利用できるコンポーネント」と「6. 変更対象ファイルと影響範囲」の2つです。ここがズレていると、実装後に想定外のファイルまで変わっていた、ということが起こります。

認識のズレがなければ、次の段階に進みます。

2段階目:対象を絞って実装を依頼するプロンプト

整理結果に問題がなければ、次のように伝えます。

先ほどの実装計画に沿って、サービス一覧セクションだけを実装してください。

【条件】
・PCは3カラム、768px以下は1カラム
・画像は16:9でトリミング表示
・カードタイトルはh3
・カード内リンクはリンク文言が分かる構造にする
・既存のBEM命名規則に合わせる
・対象セクション以外のファイルは変更しない

実装後は、変更したファイル一覧と確認すべき表示パターンも出してください。

ここでのポイントは「対象セクション以外のファイルは変更しない」という制限と、「実装後は、変更したファイル一覧と確認すべき表示パターンも出してください」という締めくくりです。

前者は、意図しない範囲まで手を広げさせないための歯止めです。後者は、実装後にどこを見て確認すればいいかを、AI自身に言わせることで、レビューの起点をはっきりさせます。

共通ファイルを触る必要が出てきたら

「対象セクション以外は変更しない」という条件を付けていても、実際には色の変数やユーティリティクラスなど、共通のファイルに手を入れないと実装できないケースが出てきます。

その場合に備えて、次のような一文も加えておくと詰まりにくくなります。

共通ファイルの変更が必要な場合は、先に理由を報告してから許可を求めてください。

これがないと、AIは「実装するために必要だから」と判断して、共通ファイルを黙って書き換えてしまうことがあります。一言添えておくだけで、影響範囲の広い変更の前に、必ず一度確認が入る流れになります。

まとめ

  • FigmaのURLを渡すだけでは、既存のコードへの馴染ませ方までは汲み取ってもらえない
  • 「まず整理、次に実装」の2段階に分けて依頼する
  • 整理段階では「コードは書かない」「既存の命名規則を優先する」を明示する
  • 実装段階では「対象範囲の限定」と「変更後の確認ポイントを出させる」を明示する
  • 共通ファイルに触る可能性がある場合は、先に報告させる一文を足しておく

1回の指示で完成させようとせず、間に確認のステップを挟む。手間が増えたように見えて、実際は手戻りを減らすための一番の近道です。

関連記事

ブログ

BLOG

PAGE TOP