FigmaをやめてClaude Codeで動くモックを作る：マージしない design/ ブランチと「文脈の三層」
指示は粗く、文脈は正確に。ただし仕様を毎回丸ごと貼らず、「常駐させる」「取りに行かせる」「その場で渡す」の三層に分けて渡す。
どんな問題を解決するか / いつ使うか
PMからAI製の動くモックが仕様として届くようになったソロデザイナーが、Figmaで状態のパターンを描き分ける代わりに、本物のリポジトリ上でClaude Codeにモックを作らせた実例。リポジトリ、shadcnベースの部品、Storybook、トークンのJSONがすでにあるプロダクトで、デザインを「動く画面」で確認してもらいたいときに使える。
やり方
運用の形
- デザイン専用のブランチを切る。命名は
design/<Issue番号>-<画面名>（例：design/123-reservation-list）。接頭辞で「マージしないブランチ」と分かるようにする。 - 流れは、GitHubのIssueからタスクを選ぶ → design/ ブランチを切る → モックを作る → PMに確認を依頼 → 問題なければ実装を依頼。エンジニアはこのブランチをローカルで動かして仕様の参照先にする。
- 開発環境を持たない人（営業やサポートなど）にも見せるなら、ブランチをデプロイした確認用環境が要る。始める前に「誰が確認するか」を洗い出しておく。
Claude Codeに渡す文脈の三層
- 常駐させる層：誰のための何のプロダクトか、ビジネスモデル、絶対に守る制約（例：安全に関わる情報は常に見える位置に置く）、デザインの基本方針。Claude Codeが自動で読むファイル（CLAUDE.mdなど）に置く。
- 取りに行かせる層：画面ごとの仕様、Storybook、トークンのJSON、過去のIssueやPR。量が多く毎回は要らないので、リポジトリの中に置いて必要なときだけ読みに行かせる。仕様がNotionやGoogle Docsにしかないと、この層は働かない。
- その場で渡す層：今回のIssueで、誰がどの場面で何に困っているか。Issueに書いてあれば、Issueを読ませるだけでよい。
作り方：何をどう作るかは粗く投げ、出てきた画面を見て直す。一度に完成させようとせず、1画面ずつ短いやりとりを繰り返す（文脈が長いほど、手順が多いほど失敗しやすいため）。
注意点
- 前提はエンジニアとの合意。ローカル環境の構築手順をもらい、ブランチの扱いを決めてから始める。
- Figmaが不要になるわけではない。バナーやアイデアを広げる段階では今もFigmaを使う、と筆者は書いている。
- 良し悪しの判断は人がする。変わるのは、判断の材料が絵から動く画面になること。
関連
- ガイド：AIエージェントに守らせるデザインシステム・DESIGN.md
- エージェントへの指示は1つの巨大ファイルにせず、AGENTS.md・DESIGN.md・SKILL.mdに分けてgitで管理する
- AIが実装の多くを書くチームで「デザイナーが触った画面の割合」を数え、後追いの修正をlintとルールに育てる