SECTION 01
rulesに書く3つの情報でFigma実装の再現性は上がりやすくなる
FigmaのデザインをClaude Codeに渡してコードを生成するとき、毎回出力がぶれるという問題にぶつかる人は多いはずです。同じ画面なのにクラス名が変わったり、コンポーネントの粒度がバラバラになったりします。
この問題の原因は、AIに渡している情報が足りないことではありません。AIがプロジェクトのお作法を知らないまま生成しているからです。毎回プロンプトで指示するのは現実的ではなく、どうしても抜け漏れが出ます。
解決策は、CLAUDE.md（Claude Codeがセッション開始時に読み込むpersistent instructions）に3つの情報を定義しておくことです。なお、より細かいモジュール単位やパス単位のルールは .claude/rules/ で管理できます。具体的に定義すべき3点は以下の通りです。
- デザイントークン：カラー、スペーシング、フォントサイズなどの値の定義
- コンポーネント分割ルール：粒度の基準と命名規則
- 技術スタックの制約：Tailwind CSS、React、Next.jsなど使用技術の指定
rulesなしで生成した場合、AIは汎用的なクラス名やインラインスタイルを使いがちです。一方、この3点をrulesに書いておくと、多くのケースでプロジェクトの既存コードと整合する出力が得られやすくなります。
筆者の経験では、最低限ここから始めるだけでもBefore/Afterの差が一目でわかるレベルになりました。ただし、プロジェクトの複雑さや既存コードの状態によって効果の度合いは変わります。
SECTION 02
Figma MCPでデザイン情報をClaude Codeに渡す方法
Figmaのデザインデータをそのまま自然言語で説明して渡すのは、かなり非効率です。「ヘッダーが固定でサイドバーがあって」と文章で伝えても、何度も修正指示を出すことになります。視覚的な完成形をAIに渡せる状態にしてから指示を出すのが基本です。
Figma MCP（Model Context Protocol）を使うと、FigmaのデザインデータをClaude Codeに直接読み込ませることができます。Claude Codeでの導入方法は、Figma公式が推奨するリモートMCPサーバー方式が現在の標準です。
具体的には、以下のいずれかの方法で設定します。
claude mcp addコマンドで追加する：ターミナルからFigma MCPを登録し、ブラウザ認証で接続を完了させます- Figmaプラグインを導入する：Figma側からMCP連携プラグインをインストールして接続します
いずれの方法でも、ブラウザ上でFigmaアカウントの認証を行うステップが必要です。従来のようにsettings.jsonを直接編集したり、アクセストークンを手動で発行したりする必要はありません。
渡すデータの方法には段階があり、精度に明確な差が出ます。大きく分けると以下の3パターンです。
- スクリーンショットだけ渡す：手軽ですが、レイアウト構造やカラーコードが曖昧になりやすいです
- Dev Modeのプロパティ情報を併用：CSS値やスペーシングが正確に伝わり、出力の精度が上がります
- レイアウト構造のテキスト補足を追加：コンポーネント階層や状態変化まで伝えられます
経験上、画像だけで十分な場面もあれば、プロパティ情報が必要な場面もあるというのが正直なところです。シンプルなカードUIなら画像で足りますが、レスポンシブ対応やホバー状態を含む複雑なUIでは、テキスト補足がないと再現精度が落ちます。
渡す情報を増やせば精度は上がりますが、準備コストとのバランスを考えることが重要です。rulesにデザインシステムの定義が書いてあれば、画像＋最小限の補足だけでもかなり正確な出力が得られます。
SECTION 03
CLAUDE.mdに書くFigma実装用rulesテンプレート
CLAUDE.mdの全体構成は、デザインシステム定義・コンポーネント設計・出力形式の3ブロックに分けるとすっきりします。この構成であれば、Figmaから情報を渡したときにAIが迷わずに正しいコードを生成しやすくなります。
なお、CLAUDE.mdはプロジェクト全体に適用されるpersistent instructionsです。特定のディレクトリやファイルパスに限定したルールを定義したい場合は、.claude/rules/ にmodular/path-specific rulesとして配置することで、より細かい制御が可能になります。
デザインシステム定義のブロックには、カラーパレット、スペーシングの倍数ルール、フォントサイズのスケールを書きます。たとえばプライマリカラーのCSS変数名と値、余白の基準値（4pxの倍数で使うなど）を明記しておくと、生成されるコードが同じトークンを参照しやすくなります。
コンポーネント設計のブロックでは、以下のような分割の基準と命名規則を定義します。
- Atomicデザインの粒度で分割するのか、ページ単位で分けるのかを明示する
- コンポーネントのファイル命名規則（PascalCase、kebab-caseなど）を指定する
- propsの型定義方針（TypeScriptのinterfaceで書くかtypeで書くかなど）を書く
出力形式のブロックには、技術スタックの制約を書きます。「Tailwind CSSのユーティリティクラスのみ使用」「カスタムCSSは禁止」「Next.jsのApp Routerを使用」といった明確な制約です。ここが曖昧だと、AIが独自のCSS設計を毎回発明してしまいます。
テンプレートは一度作ればプロジェクト間で使い回せるのも利点です。共通部分をベースにして、プロジェクト固有のカラーやコンポーネント名だけ差し替える運用がうまくいきます。
SECTION 04
Tailwind CSS向けのrules：クラス設計ごとAIに生成させる
AIファーストでコーディングするなら、Tailwind CSSとの組み合わせが合理的です。CSSファイルを分けずにクラスで直接スタイルを指定するため、AIがデザインまで含めてコードをまとめて生成できます。
Tailwind向けのrulesで特に効くのが、カスタムカラーとスペーシングの定義です。tailwind.config.jsに定義されたトークンをそのままCLAUDE.mdにも書いておくことで、AIがプロジェクト専用のユーティリティクラスを正しく使ってくれます。
具体的にrulesに書くべきポイントは以下の通りです。
bg-primary、text-accentなどのプロジェクト固有クラス名とその用途の説明- レスポンシブブレークポイントの使い分けルール（
sm:、md:、lg:の基準） @applyの使用可否や、コンポーネント内でのクラス整理の方針
Figmaのスクリーンショットや画面情報を渡すとき、Tailwindを使っていればクラス設計ごと生成してもらえるのが大きな利点です。CSSファイルとHTMLの行き来がないため、AIが生成するコードの一貫性が保ちやすくなります。
rulesに命名規則を書いておけば、チーム内でコードの見た目が統一されるという副次効果もあります。AIが生成したコードを人間がレビューする際にも、ルールに沿っているかどうかの判断が明確になります。
SECTION 05
React・Next.js向けのrules：コンポーネント粒度とファイル分割
ReactやNext.jsプロジェクトでは、コンポーネントの粒度とファイル配置がrulesの核になります。AIに任せると、1つのファイルに全部書くこともあれば、過剰に分割することもあり、一貫性が保てません。
rulesに書くべき最低限の情報は、ディレクトリ構成とコンポーネントの分割基準です。たとえば「components/ui/ に汎用UIコンポーネント」「features/ に機能ごとのコンポーネント」といった配置ルールを定義しておきます。
Next.js特有のルールとしては、以下を明記しておくと出力が安定します。
- Server ComponentとClient Componentの使い分け基準（
'use client'をどこで付けるか） - App Routerのルーティング規約（page.tsx、layout.tsxの使い方）
- データフェッチの方針（Server Actionsを使うか、API Routeを使うか）
素のHTML/CSSプロジェクトの場合は方向性が変わり、BEM命名規則やCSS変数の定義をrulesに書きます。AIはデフォルトで独自のクラス名を付けがちなので、命名パターンを指定しておくだけで出力の統一感が大きく変わります。
SECTION 06
.cursorrulesからCLAUDE.mdへ——rules設計で学んだこと
rulesファイルの考え方は、Cursor時代の.cursorrulesから始まったものです。Cursorを使い始めた頃、コーディング精度が上がらないことに悩んでいました。プロジェクトのお作法を毎回プロンプトに書くのが面倒で、忘れることもありました。
そのときに.cursorrules（Cursorが自動で読み込むプロジェクト固有のルールファイル）の存在を知り、ここに書いておけば毎回指示しなくていいと気づいたのが転機でした。ルールファイルの存在も大きく貢献して、エディタ統合型AIの作業効率が格段に上がった実感があります。
なお、.cursorrulesは現在のCursorではLegacy扱いになっています。現行の推奨は .cursor/rules（Project Rules）または AGENTS.md です。当時の学びは今でも有効ですが、Cursorで新しくプロジェクトを始める場合は現行の仕組みを使ってください。
Claude Codeに移行してからはCLAUDE.mdという名前になりましたが、発想はまったく同じです。ツールが変わっても、AIへのルール定義で品質を安定させるという考え方は変わりません。
ただし、一つ大きな違いがあります。Cursorは対話しながら都度指示を修正するスタイルですが、Claude Codeはより自律的に動く前提で設計されています。そのため、rulesに書く内容も変わってきます。
- 都度指示する前提のrules：出力フォーマットの指定が中心になります
- AIが自律的に動く前提のrules：判断基準や禁止事項まで含める必要があります
- Claude Codeでは「こういうときはこう判断しろ」という判断軸の定義が効きやすいです
この気づきから、筆者は毎プロジェクトの最初にrulesを書くのが習慣になりました。コードを書き始める前にCLAUDE.mdを整えることで、後から修正指示を出す回数が減る傾向にあります。
SECTION 07
既存プロジェクトにFigma画面を組み込むときの実践手順
Figmaの画面をClaude Codeで実装するとき、1画面まるごとゼロから生成するのは避けた方がよいケースが多いです。既存のコードベースがある場合、丸ごと生成すると既存のコンポーネントや設計パターンと矛盾するコードが出てきます。
筆者が試行錯誤の中で確立した方法は、AIに実装計画書を作らせてからGoを出すというフローです。要件を箇条書きで渡して、どのファイルをどう変更するかのステップバイステップをAIに出してもらい、それをレビューしてから進めます。
このフローが特に効くのは、既存コードベースへの差分実装で進める場面です。
CLAUDE.mdや .claude/rules/ のルールはセッション開始時に読み込まれます。そのため、実運用では事前にinstructionsを整えたうえで、Figmaのリンクや選択情報を各プロンプトに添えるのが基本の流れになります。具体的な手順は以下の通りです。
- CLAUDE.mdと
.claude/rules/にプロジェクトのルールを事前に定義しておく - FigmaのモックアップURL（画像やDev Mode情報）をプロンプトでClaude Codeに渡す
- AIに「既存の○○コンポーネントを使って実装計画を出して」と指示する
- 出力された計画書をレビューしてから、実装に進む許可を出す
ここで重要なのが、デザイン忠実性より保守性を優先すべき境界線の判断です。Figmaの見た目を完全に再現しようとすると、既存のデザインシステムから逸脱するコードが生まれることがあります。そういう場面では、保守性を優先してデザイン側に微調整を提案する方が結果的にうまくいきます。
SECTION 08
丸投げ指示が壊す、計画書が守る
「会員登録機能を作って」のような漠然とした丸投げ指示は、AIが文脈を理解できずにコードベースを壊す原因になります。筆者がこれまでの経験で何度も痛い目にあった結果、必ず計画書を挟むフローに落ち着きました。
CLAUDE.mdに計画優先の指示を書いておくと、AIが計画→確認→実装の順序で進める傾向が強くなります。ただし、CLAUDE.mdはpersistent instructionsであり強制的な設定ではないため、必ずその通りに動く保証はありません。
より確実に計画ステップを踏ませたい場合は、Claude CodeのPlan Mode（/plan）を明示的に使う方法もあります。Figma画面の実装でも同じで、いきなりコードを書かせるのではなく、どの既存コンポーネントを使うか、どこにファイルを置くかを先に整理させます。
計画書に含めるべき内容は明確で、以下の項目をAIに出力させます。
- 変更対象のファイル一覧と、それぞれの変更内容の要約
- 新規作成するコンポーネントの名前とpropsの型定義
- 既存コンポーネントとの依存関係の確認
この計画書をレビューする時間は、後から壊れたコードを修正する時間と比べれば圧倒的に短いです。特にFigmaの複雑な画面を実装するときは、計画書なしで進めると手戻りが大きくなります。
SECTION 09
Claude Code・v0・Cursor・Figma標準コード生成の使い分け
Figmaのデザインをコードに変換するツールは複数ありますが、それぞれ得意な場面が異なります。どれか1つに決めるよりも、場面に応じて使い分ける方が効率的です。
Claude Codeの最大の強みは、rulesによる出力制御と既存コードベースとの整合性です。プロジェクト固有のルールを定義できるため、チームの設計方針に沿ったコードが安定して生成されます。既存プロジェクトへの組み込みでは、この特性が最も活きます。
他のツールとの役割分担は、以下のように整理できます。
- v0（Vercelが提供するAI UIジェネレーター）：新規プロトタイプの高速生成が得意です。デザインのアイデアをすぐ形にしたいときに強みがあります
- Cursor：エディタ上での対話的な修正が得意です。細かいスタイル調整を会話しながら進められます
- Figma標準のコード生成：Dev Modeから直接CSSやレイアウト情報を取得できます。ただし実装可能なコード一式にはなりません
組み合わせ運用の例として効くのが、v0でプロトタイプを作り、Claude Codeでプロダクション実装するというフローです。v0で素早く見た目を確認してから、Claude Codeでrulesに基づいた本番品質のコードに仕上げます。
Claude Codeを選ぶべきケースを一言でまとめると、「すでにコードベースがあり、チームのルールに従った実装が必要な場面」です。ゼロからの新規生成よりも、既存の資産を活かした実装で真価を発揮します。
SECTION 10
すぐに始められる実践ティップス
ここまでの内容を踏まえて、今日から始められる具体的なアクションを整理します。rulesの完璧さを追求する前に、まず最小限の定義で効果を実感することが大切です。
最初にやるべきは、CLAUDE.mdにデザイントークンを3つだけ書くことです。プライマリカラー、基準のスペーシング値、メインのフォントファミリーの3つを定義するだけで、出力の一貫性が変わりやすくなります。
次のステップとして、以下の順番で段階的にrulesを充実させていくのがおすすめです。
- 初日：カラー・余白・フォントのデザイントークンだけ書く
- 1週間後：コンポーネントの命名規則とファイル配置ルールを追加する
- 実装を重ねながら：出力がぶれたポイントをrulesに追記していく
パス単位で細かい制御が必要になってきたら、.claude/rules/ にmodular rulesを追加していくとよいでしょう。たとえば components/ 配下だけに適用するルールなどを分離できます。
rulesは一度書いて終わりではなく、プロジェクトの進行とともに育てていくものです。AIの出力を見て「ここが毎回ぶれる」と感じたら、その都度ルールを追記していくサイクルが回り始めると、実装の再現性は着実に上がっていきます。
Figmaのデザインを実装する工程は、rulesの質がそのまま出力の質に影響しやすい領域です。最初のひと手間をかけてCLAUDE.mdを整えることで、その後の実装サイクル全体が効率化されます。ぜひ今日のプロジェクトから試してみてください。
