新規制作と既存コード、Figma連携プロンプトの使い分け
新規制作と既存コード、Figma連携プロンプトの使い分け
この記事でわかること
- 「整理→実装」の2段階プロンプトが、新規制作ではそのまま使えない理由
- 既存コードがある場合と、新規制作の場合で、何を変えるべきか
- それぞれの実際のプロンプト全文
前回、FigmaのURLを渡してコーディングを依頼するとき、「まず整理、次に実装」の2段階に分けると精度が上がるという話をしました。ただこれは、すでに動いているコードがある前提の指示でした。ゼロから新規に作る場合は、同じ型のままでは機能しない部分があります。今回は、その2つを並べて、何が違うのかを整理します。
何が同じで、何が違うのか
どちらの場合も、「先にコードを書かせず、方針を確認してから実装させる」という2段階の骨組みは変わりません。違うのは、1段階目で何を確認させるかです。
| 既存コードがある場合 | 新規制作の場合 | |
|---|---|---|
| 1段階目で確認すること | 既存のルールに沿えるか | これから採用するルールそのもの |
| 命名規則・CSS設計 | すでにあるものに合わせる | AIに方針を提案させ、先に決める |
| 再利用できるか | 既存コンポーネントの中から探す | まだ何もないので、部品分けから設計する |
| 変更範囲の制限 | 対象セクション以外は触らせない | 今回の設計が以降のページ全部の基準になる |
| 実装後にさせること | 変更ファイル一覧を出させる | 決めた設計方針を文章に残させる |
既存コードがある場合は「今あるものからズレていないか」を確認する指示になります。新規制作の場合は、そもそも従うべきものがないので、「これから何に従うか」を先に決めさせる指示に変わります。
既存コードがある場合のプロンプト(前回のおさらい)
すでに動いているサイトに、新しいセクションを追加するようなケースです。
1段階目:整理を依頼する
Figma MCPを使って、指定したフレームのサービス一覧セクションを確認してください。
まずコードは書かず、以下を整理してください。
1. 使用されているコンポーネント・カラー・余白・文字スタイル
2. PC版とスマホ版で変わるレイアウト
3. 既存リポジトリ内で再利用できるコンポーネント
4. 新規作成が必要なHTML・CSS・JavaScript
5. 実装時に注意すべきアクセシビリティ・CMS・長文表示の問題
6. 変更対象ファイルと影響範囲
既存の命名規則とCSS設計を優先し、不要な共通クラスやライブラリは追加しないでください。
2段階目:実装を依頼する
先ほどの実装計画に沿って、サービス一覧セクションだけを実装してください。
【条件】
・PCは3カラム、768px以下は1カラム
・画像は16:9でトリミング表示
・カードタイトルはh3
・カード内リンクはリンク文言が分かる構造にする
・既存のBEM命名規則に合わせる
・対象セクション以外のファイルは変更しない
実装後は、変更したファイル一覧と確認すべき表示パターンも出してください。
ポイントは「既存のルールに従わせる」ことと、「対象範囲を絞り込んで、それ以外に手を広げさせない」ことです。すでにルールがあるので、そこからズレていないかを都度チェックする形になります。
新規制作の場合のプロンプト
まだ何もないところから作り始めるケースです。この場合、そのまま同じ指示を使うと「既存リポジトリ内で再利用できるコンポーネント」を聞いても「まだ何もありません」となり、「既存の命名規則に合わせる」も従う対象がなく空振りします。
1段階目:設計方針の提案を依頼する
Figma MCPを使って、指定したフレームのサービス一覧セクションを確認してください。
まだ何もない新規のコーディングです。まずコードは書かず、以下を提案してください。
1. デザインから読み取れるコンポーネント構成(カード・ボタン・見出しなど、どう部品分けするか)
2. 採用するCSS設計方針(BEM / OOCSSなど)とその理由
3. カラー・余白・文字スタイルを変数として管理する場合の設計案
4. PC版とスマホ版で変わるレイアウトと、採用するブレイクポイント
5. HTML構造の草案(見出しレベル・リンク構造など)
6. アクセシビリティ・CMS化・長文表示を見据えた注意点
今後複数ページに展開する前提なので、この1セクションだけに閉じない、拡張しやすい設計を意識してください。
「既存のルールに合わせる」がそのまま「採用するルールを提案させる」に置き換わっています。ここで一度立ち止まって内容を確認することが、後から出てくる大量のページで命名や設計がバラバラになるのを防ぎます。
もう一つ、「今後複数ページに展開する前提」という一文が新規制作では重要になります。新規制作は多くの場合、1セクションで終わりません。最初のセクションで決めた設計が、その後の全ページの基準になるという点を、既存コード版よりも強く意識させる必要があります。
2段階目:実装を依頼する
先ほどの設計方針に沿って、サービス一覧セクションを実装してください。
【条件】
・PCは3カラム、768px以下は1カラム
・画像は16:9でトリミング表示
・カードタイトルはh3
・カード内リンクはリンク文言が分かる構造にする
・提案いただいた命名規則・変数設計に沿う
実装後は、今回決めた設計方針(命名規則・変数の使い方)を簡潔にまとめてください。それ以降のセクションもこの方針に統一します。
締めくくりの一文が、既存コード版とは役割が異なります。既存コード版の「変更ファイル一覧を出させる」は、変更範囲を確認するためのものでした。新規制作版の「決めた設計方針を簡潔にまとめてください」は、次のセクションを依頼するときにそのまま渡すための文章を作らせているという違いがあります。
2回目以降のセクションでは
新規制作の場合、2セクション目以降は1段階目の指示が変わります。ゼロから提案させる必要はなく、1回目でまとめさせた設計方針をそのまま渡します。
以下の設計方針に沿って、次は料金セクションを実装してください。
【前回決めた設計方針】
(1回目の実装後にまとめさせた内容をここに貼り付ける)
【条件】
(このセクション固有の条件)
こうすることで、ページが増えても命名規則やコンポーネントの考え方が途中でブレなくなります。新規制作における1段階目の提案フェーズは、実質「1回目だけ厳密にやればいい作業」です。
まとめ
| 既存コードがある場合 | 新規制作の場合 | |
|---|---|---|
| 1段階目の狙い | 今あるルールからズレていないか確認 | これから従うルールを先に決める |
| 2段階目の締めくくり | 変更ファイル一覧を出させる | 設計方針を文章化させ、次回に引き継ぐ |
| 2セクション目以降 | 毎回既存コードを確認させる | 1回目でまとめた方針を貼り付けるだけ |
同じ「整理してから実装する」という骨組みでも、土台があるかないかで、確認すべき中身は変わります。今どちらの状況にいるのかを踏まえて、プロンプトを選んでみてください。
