Figma → コード実装ワークフロー

概要

Figma のデザインを忠実にコード化するには、プロンプトだけでは不十分です。質の高い実装には次の 4 つが揃っている必要があります。

要素	内容
Figma 設計ルール	トークン、コンポーネント、バリアントの命名・構造規約
コード設計ルール	デザイントークンの参照方法、コンポーネント分割の粒度
Skills / Rules	LLM に渡すレビュー観点・パターン集
段階的フロー	設計読取 → 計画 → 実装 → レビュー → 修正の順序厳守

これらを欠いた場合、トークンの直書き・既存コンポーネントの再実装・デザイン仕様との乖離が典型的な問題として発生します。

river-review との統合

river-review には Figma → コードの品質チェックを担う 2 つの midstream スキルが含まれています。

`design-token-enforcement`

デザイントークンの直書きを検出するスキルです。カラーコード・フォントサイズ・スペーシングなどが設計システム変数を経由せず直接ハードコードされている場合に警告を発します。

`design-system-component-reuse`

既存コンポーネントを再実装しているコードを検出するスキルです。すでにコンポーネントライブラリに同等の実装が存在するにもかかわらず、インラインで再定義しているケースを報告します。

これらのスキルは midstream フェーズ（PR 作成後のレビュー）で自動的に実行されます。明示的に有効化する必要はありません。

推奨ワークフロー

Step 1: Figma MCP でデザイン仕様を読み取る
        - get_design_context でコンポーネント・トークン情報を取得する
        - get_screenshot でビジュアルを確認する

Step 2: コンポーネント対応表を作成する
        - Figma コンポーネント名 ↔ コードコンポーネント名の対応を一覧化する
        - 既存コンポーネントと新規作成が必要なものを区別する

Step 3: 実装計画を出力する（コードは書かない）
        - ファイル構成・依存関係・トークン参照方法を文書化する
        - 計画のレビューをチームに依頼する

Step 4: コンポーネント単位で実装する
        - 対応表に沿ってインポート・props・スタイルを記述する
        - デザイントークンは必ず変数/定数経由で参照する

Step 5: river-review でレビュー（トークン違反・再実装を検出）
        - PR を作成すると midstream フェーズが自動実行される
        - design-token-enforcement と design-system-component-reuse の結果を確認する

Step 6: 差分を修正する
        - Critical / Major の指摘を解消してから再レビューを依頼する
        - Minor は次スプリントのフォローアップ Issue で追跡する

エージェント用プロンプト例

調査用（Step 1–2）

Figma の <URL> からデザイン仕様を読み取り、以下の情報を抽出してください：
1. 使用されているコンポーネント一覧（Figma 名 / コード名 / 新規作成要否）
2. 使用されているカラートークンとスペーシングトークンの種類
3. 既存コンポーネントライブラリで流用できるものとそうでないものの分類

実装はまだ行わないでください。対応表の形式で出力してください。

実装用（Step 4）

以下の対応表をもとに <コンポーネント名> を実装してください：
- Figma 仕様: <URL>
- デザイントークンのインポートパス: <path>
- 既存コンポーネントのインポートパス: <path>

制約：
- カラー・フォント・スペーシングは必ずトークン変数を使用すること
- 既存コンポーネントが流用可能な場合は必ず再利用すること
- 一度に実装するのは 1 コンポーネントに限定すること

修正用（Step 6）

river-review から以下の指摘が返されました：
<指摘内容をここに貼り付ける>

各指摘を修正してください。修正方針は以下のとおりです：
- トークン直書き → 対応するデザイントークン変数に置き換える
- 再実装 → 既存コンポーネントをインポートして使用する

修正後、変更箇所の一覧を報告してください。

よくある失敗パターン

原因	起きること	対策
Step 3 をスキップして即実装	計画なしで実装するため全体像がずれる	計画フェーズを省略しない
Figma MCP を使わず目視でトークンを確認	読み取りミスでトークン名を誤入力	`get_design_context` で正確な値を取得する
1 プロンプトで複数コンポーネントを依頼	コンポーネント間の依存が混在してデバッグ困難	1 依頼 = 1 コンポーネントを徹底する
レビュー結果を無視してマージ	トークン違反が本番に混入する	Critical / Major はマージ条件として扱う
既存コンポーネントの存在を確認しない	ライブラリが肥大化し一貫性が失われる	Step 2 の対応表作成を怠らない

概要​

river-review との統合​

design-token-enforcement​

design-system-component-reuse​

推奨ワークフロー​

エージェント用プロンプト例​

調査用（Step 1–2）​

実装用（Step 4）​

修正用（Step 6）​

よくある失敗パターン​

関連ページ​

概要