この記事でわかること
CLAUDE.md1ファイルで全画面のUI品質が統一される仕組みと設定手順がわかる。プロンプトに毎回スタイル指示を書く手間をゼロにする3段階の運用ルールが手に入る。フリーランスが1人で複数画面を実装する際のAI分業設計が5分から始められる。
Claude Codeにデザインシステムを組み込むと、CLAUDE.mdを1ファイル配置するだけで全画面のUI品質が統一されます。Tailwind CSS対応・フレームワーク非依存で、5分から始められる3段階の実装手順をフリーランス向けに解説します。
この記事の結論
Claude Codeのデザインシステム実装は「CLAUDE.mdを置く→Primitiveだけで組む→Design System側を更新する」という3段階の運用ルールを確立することで完結します。プロンプトに毎回UI指示を書く手間がなくなり、AIが一貫した品質のコードを出力し続ける環境が整います。フリーランスが1人で複数画面を実装する場合でも、この構造があれば人間は「判断者」に集中し、AIに「実装者」を任せる分業が機能します。
今日やるべき1つ： melta UIリポジトリからCLAUDE.mdをコピーしてプロジェクトルートに配置する（所要時間：5分）。
状況別ショートカット
| 状況 | 読むべきセクション | 所要時間 |
| まず今日動かしたい | Claude Codeデザインシステムは3段階で導入 | 5〜30分 |
| BMAD-METHODを理解したい | Claude CodeデザインシステムはBMAD-METHODで運用 | 10分 |
| どの手法が自分に合うか判断したい | 導入レベルを3分で診断 | 3分 |
| Figma連携まで視野に入れたい | Claude CodeはFigma MCPで双方向連携が可能 | 10分 |
| ハンドオフの品質を上げたい | 5つの仕組みで品質担保 | 15分 |
Claude Codeデザインシステムは3段階で導入
実際には最短5分で初期設定が完了し、プロジェクトの規模に応じて段階的に拡張できる構造になっています。
5分で始まるCLAUDE.md単体配置
最も手軽な導入は、melta UIリポジトリからCLAUDE.mdを1ファイルコピーしてプロジェクトルートに置くだけです。この1ファイルにはボタン・カード・テーブルなど基本コンポーネントの仕様が記述されており、Claude Codeはこれを参照しながらコードを生成します。
「一番手軽な方法（5分）——melta UIリポジトリからCLAUDE.mdだけコピーして、自分のプロジェクトルートに置く。これだけでClaude Codeの出力が変わる」とClaude Codeに特化したデザインシステムを作って工夫したことに記載されています。
Tailwind CSSがプロジェクトに入っていれば追加インストールは不要です。React・Vue・Svelteを問わずフレームワーク非依存で動作するため、既存プロジェクトへの追加コストはゼロに近い水準です。「まず試す」ための障壁がほぼ存在しないため、迷うくらいであれば5分で動作確認を済ませるのが最速の判断材料になります。なお、Claude CodeはCursorとも使い分けができるため、普段使いのエディタとの棲み分けも意識しておくと実務の混乱を減らせます。
中級構成はgit cloneで4ファイルを追加
CLAUDE.md単体では色・スペーシングの精度が不足すると感じる場合は、リポジトリをgit cloneしてfoundations/・components/・tokens.json・prohibited.mdの4点をプロジェクトにコピーします。
tokens.jsonは色とスペーシングの定義をJSON形式で管理するファイルです。CLAUDE.md単体の状態に比べてトークンレベルでの一貫性が確保されるため、デザイン修正が発生した際にtokens.jsonを1か所更新するだけで全コンポーネントに反映されます。prohibited.mdはAIが行うべきでないデザイン判断を列挙したファイルで、「AIが勝手にスタイルを決めてしまう」問題を構造的に防ぎます。
上級構成はMCPサーバーでAPI連携
最もフル機能の構成では、MCPサーバーを起動してAIエージェントがAPI経由でデザインシステムにアクセスします。この構成では複数のAIエージェントが同一のデザインシステムを参照するため、チーム規模が拡大しても一貫性が維持されます。フリーランスが複数クライアントのプロジェクトを並行して管理する場合にも、クライアントごとにMCPサーバーの設定を切り替えることで対応できます。
Cursor環境を使用している場合は.cursor/rules/に同梱するだけで同じ設定が流用できます。Claude Codeと別のエディタを使い分けているフリーランスにとって、設定の二重管理が不要になる点は実務上の負担軽減に直結します。
CHECK
▶ 今すぐやること：melta UIリポジトリにアクセスしてCLAUDE.mdをダウンロードし、プロジェクトルートに配置する（5分）
Q：CLAUDE.mdとDESIGN.mdはどちらを使えばよいですか？
A：プロジェクト初期にフロントエンドライブラリを決定した後、globals.cssでトークンを定義してDESIGN.mdを新規作成する流れが標準です。既存プロジェクトへの追加であればCLAUDE.mdの単体配置から始めるのが最短です。
Q：Tailwind CSSが入っていないプロジェクトでは使えませんか？
A：Tailwind CSSはこの構成の必須要件として位置づけられています。未導入の場合は先にインストールを済ませてから設定を追加してください。
Claude CodeデザインシステムはBMAD-METHODで運用
運用ルールを決めずにファイルだけ置いても、画面実装が増えるにつれてAIの出力がバラバラになっていきます。BMAD-METHODは、デザイン整備と画面実装を往復する明示的なワークフローです。
BMAD-METHODは4フェーズで構成
BMAD-METHODはinit-frontend・create-design-system・implement-with-ds・modify-designの4フェーズから構成されます（Claude Codeにおけるフロントデザインシステム）。
init-frontendフェーズでは使用するフロントエンドライブラリを決定し、globals.cssでトークンを定義してDESIGN.mdを作成します。create-design-systemフェーズではButton・InputなどのPrimitiveを導入し、以降の実装ではこれらを組み合わせるだけにします。implement-with-dsフェーズでは画面実装時にPrimitiveを選んで組み合わせ、トークンやスタイルの直接指定を禁止します。modify-designフェーズでは既存のPrimitiveでは要件を満たせない場合にDesign System自体を更新します。
この4フェーズの最大の価値は「画面側で場当たり対応をしない」という原則を構造的に強制できる点にあります。フリーランスが1人で複数画面を実装する場合、場当たり対応が積み重なると後から全体の整合性を取り直す工数が発生します。BMAD-METHODはその発生源を事前に断ちます。
Primitiveだけで組む原則が一貫性の核心
画面実装においてPrimitiveを選んで組み合わせるだけにするという制約は、一見窮屈に見えます。「Primitiveで足りない場合はDesign System自体を更新する」という原則と組み合わせると、デザインシステムが常に現実の要件を反映した状態に保たれます。
この原則を徹底するかどうかで、フリーランスの実装速度が中長期的に変わります。最初の数画面はPrimitiveが揃っていないため更新作業が発生しますが、10画面を超えた時点から組み合わせるだけで実装が完結する状態に移行します。作業効率を上げる仕組み化と組み合わせることで、AIへの指示コストも継続的に下がっていきます。
DESIGN.mdは初回設定後に変更しない
DESIGN.mdはinit-frontendフェーズで1度作成した後、原則として変更しません。途中でスタイルの定義を変更すると、それ以降に生成されたコードと以前のコードで見た目が乖離します。DESIGN.mdの変更が必要な場合は、modify-designフェーズとして明示的に管理します。
DESIGN.mdは「設計図」として固定し、変更の必要が生じたときは設計変更として扱うということです。フリーランスがクライアントへの説明責任を果たす観点でも、設計変更の履歴が残ることは実務上のリスク管理に役立ちます。
CHECK
▶ 今すぐやること：現在のプロジェクトでinit-frontendに相当する設定（フロントエンドライブラリの決定・DESIGN.md作成）を済ませる（30分）
Q：BMAD-METHODは既存のCI/CDパイプラインに影響しますか？
A：影響しません。BMAD-METHODはMarkdownドキュメントとAIのプロンプト設計に関するワークフローであり、ビルドやデプロイのパイプラインとは独立しています。既存の開発フローに追加する形で導入できます。
Q：Primitiveが足りないときに画面側で直接スタイルを書いてしまってよいですか？
A：BMAD-METHODでは画面側でのスタイル直接指定は禁止です。Primitiveで対応できない要件が出た場合は、modify-designフェーズとしてDesign Systemを更新してください。直接指定を許容すると一貫性が崩れ始め、デザインシステムの効果が失われます。
Claude Codeデザインシステムの導入レベルを3分で診断
以下の3問で現在の状況に合った選択肢を確認できます。
Q1：プロジェクトにTailwind CSSは導入済みですか？
未導入の場合 → まずTailwind CSSを導入してから診断を再開してください（設定時間：15〜30分）。導入済みの場合 → Q2に進んでください。
Q2：現在のプロジェクトは既存プロジェクトですか、新規プロジェクトですか？
既存プロジェクトへの追加 → Result A（5分セットアップ）。新規プロジェクト → Q3に進んでください。
Q3：複数のAIエージェントやチームメンバーと同じデザインシステムを共有しますか？
1人・単一ツールで使用 → Result B（中級セットアップ）。複数人・複数ツールで共有 → Result C（上級セットアップ・MCPサーバー）。
Result A：CLAUDE.md単体配置（5分）
melta UIリポジトリからCLAUDE.mdをコピーしてプロジェクトルートに置くだけで完了します。既存プロジェクトへの影響を最小化しながらAIの出力品質を改善したい場合に最適です。
Result B：git clone＋4ファイル追加（30分）
foundations/・components/・tokens.json・prohibited.mdをコピーし、色・スペーシングの精度を確保します。新規プロジェクトで最初から一貫性のある設計を構築したい場合に選択してください。
Result C：MCPサーバー起動（設定：1〜2時間）
複数エージェントやチームメンバーが同一デザインシステムを参照する環境を構築します。フリーランスとして複数クライアントの案件を同時並行で進める場合にも、クライアントごとにMCPサーバー設定を切り替えることで対応できます。スケジュール管理ツールと組み合わせると、クライアントごとの設定切り替えタイミングを可視化できます。
CHECK
▶ 今すぐやること：診断結果に従って対応するセットアップを開始する（5分〜2時間）
Q：MCPサーバーの設定はClaudeの公式ドキュメントで確認できますか？
A：MCPプロトコルの仕様はAnthropicが公開しています。melta UIとのMCP連携手順についてはClaude Codeに特化したデザインシステムを作って工夫したことを参照してください。
Claude CodeはFigma MCPで双方向連携が可能
フリーランスが1人でデザインと実装を兼務する場合、FigmaとClaude Codeを別々に管理するコストは無視できません。Figma MCPを活用すると、FigmaのデザインシステムライブラリとClaude Codeを接続してUIを自動生成できます。
Figma MCPはデザインシステムライブラリを接続点にする
Figmaでデザインシステムをライブラリとして公開し、Figma MCPでClaude Codeと接続します。この接続が確立されると、プロンプトでUI仕様を指定するだけでFigmaのライブラリ定義に準拠したコードが生成されます。デザイナーが調整したコンポーネントがコードに即時反映される流れを構築でき、デザイン変更のたびに手動でコードを修正する工数が削減されます。Figma AIの機能と組み合わせることで、デザイン提案から実装まで一気通貫のワークフローが実現します。
Claude CodeからFigmaへの双方向送信
UI構築後にgenerate_figma_designでFigmaに送信し、デザイナーが調整した後にget_design_contextでコードに反映する双方向ループが実現します。フリーランスがクライアントのデザイナーと協働する案件では、この双方向連携によってコードとデザインの乖離が発生しにくくなります。
なお、generate_figma_designおよびget_design_contextはFigma MCP連携の文脈で言及されるコマンド名ですが、利用するFigmaプラグインやMCP実装によって実際のコマンド名・仕様が異なります。最新の利用方法はFigma公式サイトおよび各MCPライブラリのドキュメントを参照してください。
Claude DesignからClaude Codeへのハンドオフは6項目で定義
Claude Designで作成したデザイン案をClaude Codeに渡す際は、見た目の情報だけでは不十分です。「目的・状態・制約・受け入れ条件・レスポンシブ条件・テスト条件」の6項目を明記して渡すことで、AIが独自に判断して仕様から外れたコードを出力するリスクを抑えられます（Claude DesignとClaude Code連携で何が変わる？）。
見た目の指示だけを渡した場合、AIはデザインの「意図」を推測して判断します。推測が外れると修正コストが発生します。6項目のハンドオフは推測の余地を排除するための設計であり、修正ループの発生頻度を構造的に下げる仕組みです。
CHECK
▶ 今すぐやること：次のClaude Codeへの指示に「目的・状態・制約・受け入れ条件」の4項目を追記して試す（5分）
Q：Figma MCPの利用にはFigmaの有料プランが必要ですか？
A：Figma MCPの利用条件はFigmaのプランや使用するMCP実装によって異なります。最新情報はFigma公式サイトでご確認ください。
Q：Figma MCP連携がないプロジェクトでも6項目ハンドオフは有効ですか？
A：有効です。Figma MCPの有無に関わらず、Claude Codeへの指示に目的・状態・制約・受け入れ条件を含めることでAIの判断ミスを減らせます。
Claude Codeデザインシステムは5つの仕組みで品質担保
「プロンプトに毎回UI指示を書くのが手間」「AIが勝手にデザイン判断をしてしまう」という状況は、仕組みで解決できます。以下の5つのハックは、フリーランスが1人で実装する現場で効果の高いものを優先順位順に並べています。
ハック1：CLAUDE.md配置でAIの出力が即日変わる
【対象】 ：Claude Codeを使っているが毎回プロンプトにスタイル指示を書いているフリーランス
【手順】 ：melta UIリポジトリにアクセスする（1分）。CLAUDE.mdをダウンロードしてプロジェクトルートにコピーする（2分）。Claude Codeに「CLAUDE.mdを参照して実装してください」とだけ伝えてコードを生成させ、出力が変わることを確認する（2分）。
【コツと理由】 ：「CLAUDE.mdにルールを定義しておき、プロンプトは最小限にする」方が出力の一貫性が高まります。毎回書くプロンプト指示はAIがセッションごとに再解釈するため、表現のブレが生まれます。CLAUDE.mdはプロジェクトスコープで参照されるため、AIの解釈の起点が固定されます。起点が固定されると「判断の余地」が減り、AIが独自判断でスタイルを変える機会が構造的に消滅します。「詳細なプロンプトが品質を決める」という前提と異なり、「ドキュメント定義がプロンプトを代替する」点がこの手法の核心です。
【注意点】 ：CLAUDE.mdを配置した後に内容を頻繁に手動編集するのは逆効果です。CLAUDE.mdは初期設定後は原則として変更せず、スタイル変更が必要な場合はDesign Systemの更新フェーズとして明示的に管理してください。
ハック2：prohibited.mdでAIの独自判断を遮断する
【対象】 ：AIが勝手にスタイルを選択してクライアントの意図に合わないコードを出力されて困っているフリーランス
【手順】 ：prohibited.mdを新規作成し、「禁止するスタイル指定・禁止するコンポーネント構造・禁止するライブラリ追加」の3カテゴリを定義する（20分）。過去に修正が発生した出力のパターンを振り返り、禁止事項として追記する（10分）。次の画面実装でprohibited.mdを参照させ、禁止事項に抵触するコードが出力されないことを確認する（実装時）。
【コツと理由】 ：プロンプトに「〇〇しないでください」と書くアプローチより、prohibited.mdとして独立ファイルで管理するアプローチが優れています。プロンプトに書いた禁止事項はセッションが変わると忘れられますが、prohibited.mdはプロジェクト全体に作用し続けます。AIはプロンプトよりもプロジェクトに存在するファイルを長期的な制約として扱う傾向があるため、ファイル化した制約は構造的な縛りとして機能します。
【注意点】 ：「すべてのスタイル変更を禁止」という包括的な記述は逆効果です。禁止は具体的なパターン単位（例：「style属性による直接指定を禁止」「外部フォントの追加インストールを禁止」）で記述してください。
ハック3：6項目ハンドオフでAIの推測ミスを防止
【対象】 ：Claude DesignとClaude Codeを連携させているが、意図通りのUIが出力されないことが多いフリーランス
【手順】 ：実装したいUIの「目的」（何のための画面か）と「状態」（通常・ローディング・エラー等）を1〜2文で書く（5分）。「制約」（使用不可のライブラリ・ブレークポイント等）と「受け入れ条件」（完成の判定基準）を追記する（5分）。「レスポンシブ条件」と「テスト条件」を追加してClaude Codeに渡す（5分）。
【コツと理由】 ：「できるだけ詳しく見た目を説明する」より「見た目より目的と制約を先に渡す」方がAIの出力精度が上がります。見た目の説明は多様な解釈を生みますが、目的と制約は選択肢を絞ります。6項目すべてが揃うと、AIが「判断しなければならない余地」が目に見えて減ります（Claude DesignとClaude Code連携で何が変わる？）。
なお、効果の度合いは実装環境や仕様の複雑さによって異なります。定量的な保証値として読まず、精度向上の方向性として参照してください。
【注意点】 ：6項目をすべて埋めようとして30分以上かけるのは非効率です。「目的・状態・制約・受け入れ条件」の4項目だけでも効果は出ます。レスポンシブ条件とテスト条件は余裕があるときに追加してください。
ハック4：tokens.jsonで色・スペーシングを一元管理する
【対象】 ：複数の画面で色やスペーシングがバラバラになっており、修正コストが高くなっているフリーランス
【手順】 ：tokens.jsonを作成し、使用する色・スペーシング・タイポグラフィのトークンを定義する（30〜60分）。CLAUDE.mdまたはDESIGN.mdからtokens.jsonを参照するよう記述を追加する（10分）。次の実装からトークン名で色・スペーシングを指定し、直接の色コード指定を禁止するルールをClaude Codeに伝える（実装時）。
【コツと理由】 ：tokens.jsonは後から追加するより初回実装時に設定する方が修正工数が少なくなります。tokens.jsonは「1か所を変更すれば全体に反映される」というシングルソース設計です。後から導入すると既存コードに散在する色コードをすべて置換する作業が発生するため、初回実装時に設定する価値があります（Claude Codeにおけるフロントデザインシステム）。
【注意点】 ：Material 3などUIライブラリを使用する場合、components.styleOverridesは使わないようにしてください。テーマ設定はpalette・shape.borderRadius・spacingの3項目に絞ることで、ライブラリのアップデートによる破壊的変更の影響範囲を最小化できます。
ハック5：Markdownドキュメント化でチームの専門知識格差を解消する
【対象】 ：UI専門知識のないエンジニアや外部パートナーがいるプロジェクトで品質のばらつきに悩むフリーランス
【手順】 ：CLAUDE.mdまたはDESIGN.mdに「なぜこのルールか」の理由を1行ずつ追記する（15〜30分）。理由付きのルールをクライアントや外部パートナーに共有し、合意を得る（打ち合わせ1回）。実装後に「このルールに従って実装しました」とMarkdownを根拠として提示する習慣をつける（実装のたびに）。
【コツと理由】 ：仕様の記述だけより理由付きルールの方が定着します。AIがMarkdownを参照するだけでなく、人間もMarkdownを読んで判断できる状態が整うと、クライアントへの品質説明が格段にしやすくなります。
「エンジニアがUIの深い専門知識を持っていなくても、プロンプトを通すだけで一定の品質が担保されたコードが生成される仕組みを構築しておこうと考えている」とClaude Codeで「動くデザインシステム」をつくり、小さなチームでに記載されています。
Markdownにルールと理由を記述することで、それを読む人（AIも人間も）が設計意図を理解した上で実装できます。フリーランスがプロジェクトを引き継ぐ際や、クライアントにレビューを求める際にも、このドキュメントが共通言語として機能します。Claude CodeのWebデザイン実装では、事前設計ドキュメントの質がUIの完成度に直結することが実務事例からも確認できます。
【注意点】 ：ルール記述が「やること」の羅列になるのは避けてください。「なぜか（理由）」を1行追記するだけで、AIの出力の安定性と人間の理解度が同時に改善されます。
CHECK
▶ 今すぐやること：現在のプロジェクトのルートディレクトリを確認し、CLAUDE.mdが存在しない場合はmelta UIからダウンロードして配置する（5分）
Q：フリーランスが1人で管理する場合、何ファイルから始めるべきですか？
A：CLAUDE.md単体から始めてください。効果を確認してからtokens.jsonを追加し、必要に応じてprohibited.mdを作成する順番が実務上の負担が最も少ない進め方です。
Q：AIがprohibited.mdの内容を無視することはありますか？
A：セッションのコンテキストが非常に長くなった場合に参照が弱まることがあります。その場合は「CLAUDE.mdとprohibited.mdを参照してください」と明示的にプロンプトに追記することで対応できます。
Claude Codeデザインシステムは3段階で即日運用
Claude Codeのデザインシステム実装は「CLAUDE.mdを置く→Primitiveだけで組む→Design Systemを更新する」の3段階ルールが核心です。5分のCLAUDE.md配置から始め、プロジェクト規模に応じてtokens.json・prohibited.md・MCPサーバーへと段階的に拡張できます。AIに「実装者」を任せ、フリーランス自身が「判断者」に集中できる構造が整うことで、毎回のプロンプト作成コストと修正工数の両方が削減されます。
品質担保の仕組みがMarkdownドキュメントとして存在することは、クライアントへの説明責任の面でもフリーランスにとって実質的な資産になります。「なぜこの実装品質が出ているのか」を明示できる根拠があることで、単価交渉や継続契約の場面でも具体的な差別化要因として活用できます。フリーランスの単価交渉では、技術的根拠の言語化が交渉成功率に影響することが繰り返し指摘されており、CLAUDE.mdのようなドキュメントはその言語化を補強します。
| 状況 | 次の一歩 | 所要時間 |
| デザインシステムが未導入 | CLAUDE.mdをプロジェクトルートに配置する | 5分 |
| CLAUDE.mdは配置済みだが色がバラバラ | tokens.jsonを作成してトークン定義を追加する | 30〜60分 |
| AIが勝手にスタイル変更する | prohibited.mdを作成して禁止パターンを定義する | 30分 |
| Figma連携を始めたい | Figmaのライブラリ公開とFigma MCP接続設定を行う | 1〜2時間 |
| ハンドオフ品質を上げたい | 次の指示に目的・状態・制約・受け入れ条件の4項目を追記する | 5分 |
Claude Codeデザインシステム実装に関するよくある質問
Q：React以外のフレームワークでも同じ設定が使えますか？
A：CLAUDE.mdベースのデザインシステムはフレームワーク非依存の設計です。Vue・Svelte・その他のフレームワークでも、Tailwind CSSが導入されていれば同じCLAUDE.mdを参照させることができます。
Q：BMAD-METHODとmelta UIは組み合わせて使えますか？
A：組み合わせて使えます。melta UIのCLAUDE.mdをinit-frontendフェーズで配置し、BMAD-METHODのワークフローに従って運用するのが最も効率的な構成です。DESIGN.mdの作成もinit-frontendフェーズで完了させてください。
Q：クライアントがデザインシステムの存在を理解していない場合、どう説明すればよいですか？
A：「すべての画面が同じルールに従って実装されるため、修正が1か所に集中します」という説明が最も伝わりやすい表現です。Markdownファイルを根拠として見せながら「この定義に従ってAIが実装しています」と伝えることで、技術的な背景を持たないクライアントにも品質担保の仕組みが伝わります。
【出典・参照元】
Claude Codeに特化したデザインシステムを作って工夫したこと – melta UI実装事例・5分セットアップ手順・AIの役割分担に関する一次情報
Claude Codeにおけるフロントデザインシステム – BMAD-METHOD・Primitive導入・tokens.json活用に関する解説
Claude DesignとClaude Code連携で何が変わる？ – ハンドオフ設計・6項目定義に関する解説
Claude Codeで「動くデザインシステム」をつくり、小さなチームで – Markdownドキュメント化・品質担保の仕組みに関する一次情報
Figma公式サイト – Figma MCPの利用条件・最新仕様の確認