デザイナーの脳内をコピーして、誰でも90点以上のUIを作れるようにする
こんにちは、令和トラベルでデザイナーをしているtoyです。
いま社内で、AIを前提にしたプロダクトデザイン環境を整えています。ひとことで言うと「デザイナー以外でも、Claude CodeでNEWTのデザインを作れるようにする」仕組みづくりです。
先に、実際のアウトプット例をお見せします。
作ったのは、デザイナーではありません。Claude CodeにPM/エンジニアが指示したもので、デザイナーはレビューのみに回ります。
NEWTでは今、一部のデザインがこのような流れで作られています。なぜこんなことをしているのか、どういう仕組みなのか、順に書いていきます。
チームは増える、デザイナーは増えない
これまでNEWTの開発チームには必ずデザイナーがいましたが、その前提がAIで崩れました。開発が速くなり、エンジニアのフルスタック化も進んで、少人数でもチームが組めるようになり、チームの数はどんどん増えていっています。しかし、デザイナーの数はそのままなので「デザイナーのいないチーム」が生まれ始めました。
Before：3チーム体制。各チームにエンジニア3名ほど＋PM1名＋デザイナー1名
After：8チーム体制。うち5チームはデザイナー不在（PM＋エンジニアのみ）
ひとりで複数チームを掛け持ちする手もあります。全チームの全画面を手で描いて手でレビューするのは、正直あまり現実的ではないです。
事業の成長にはスピードが欠かせません。でも、スピードのために世に出るものの品質は落としたくありません。
品質がブレる原因は、判断基準がわたしたちデザイナーの頭の中にしかないことです。AIに「NEWTっぽく作って」と頼んでも、AIはデザイナーの頭の中を覗けません。
だったら、頭の中を外に出せばいい。そう考えて、AIを前提にしたプロダクトデザイン環境を作ることにしました。
狙いは、デザイナー以外の人でもNEWTで使う特定のUIを90点以上で作れるようにして、デザイナーは出てきたものをレビューして判断する立場に回ることです。
デザイナーが考えていることとデザインフローを踏襲したまま、誰もがUIを作れる状態を目指します。
実現したかった5つのこと
この狙いを分解すると、仕組みに求める条件は5つになりました。
① Figmaではなく、Claude CodeでUIを組み立てられること
FigmaをPMやエンジニアが使いこなすには、壁があります。一方でClaude Codeは全社導入していて、職種を問わずみんな毎日触っています。
② デザイナーの考える流れが、そのまま再現されること
デザイナーは、いきなり画面を描きません。調査して、仕様を理解して、案を複数出して、その中から提案します。この頭の中のフローごと仕組みにしないと、出てくるのは「それっぽい画面」止まりです。
③ デザインレビューがしやすい成果物が出てくること
レビューする際に、UIの見た目だけをポンと見せられても、良し悪しは判断できません。なぜ作るのか、競合はどうしているのか、仕様はどうなっているのか、判断材料が揃った形で出てくるようにします。
④ 実装の都合を忘れてデザインだけを考えられること。それでいて、実装へそのまま接続できること
デザインを広く考えるとき、APIのつなぎ込みのような、デザインの検討には不要な実装まではAIに作らせたくないです。でも、成果物は作り直しゼロで引き渡したいので、その両立をさせます。
⑤ 確定したデザインが、そのまま最新のマスターになること
NEWTでは、画面デザインのマスターをFigmaで管理しています。デザインが変わるたびに、誰かが手作業でFigmaのマスターを更新し続けています。この運用をやめて、確定した案が自動的に正となり、常に最新を参照できる状態にしたいです。
ここからは、この5つをどう実現しているかの仕組みの話です。
構成：newt-design-system の中身
仕組みは、2つのリポジトリでできています。ひとつは newt-design-system。NEWTのデザインの正、つまりシングルソースを管理する場所です。もうひとつが newt-spec。PRDや機能仕様を管理して、実際のデザイン作業を行う場所です。デザインの基準を持つのが前者、その基準を参照しながらデザインを作るのが後者、という分担です。
まずは newt-design-system から見ていきます。
newt-design-systemの設計の考え方は、@tsubotax さんの melta-ui を参考にさせていただきました。人間とAIの両方が読めるデザインシステムというアーキテクチャや、コンポーネントを機械可読な仕様（contract）として持つ発想です。この考え方は melta-ui の記事がとても分かりやすいので、ぜひそちらも読んでみてください。この記事では、NEWT固有の部分を中心に書いていきます。
newt-design-system の全体はこうなっています。
newt-design-system/
├── tokens/ # デザイントークン（色・余白・フォントの値のSSOT）
│ └── newt.tokens.json
├── packages/ui/ # Web UIパッケージ @reiwa-travel/newt-ui
│ └── src/components/ # 実装(.tsx)と仕様(.md)を同居させたUIコンポーネント群
├── design-mock/ # ★ デザインのプレイグラウンド（Next.js アプリ）
│ ├── components/ # domain-component の実体（TSX）※ui-componentはpackages/uiからimport
│ ├── screens/ # page（画面モック）
│ ├── design/contracts/# コンポーネントの機械可読な仕様（contract）
│ ├── foundations/ # UX哲学・UXライティングなどのガイドライン
│ └── src/ # design-system MCP サーバの実装
├── docs/
│ └── communication-design/ # ブランド・コミュニケーションデザイン
├── plugin/ # Figmaプラグイン群
└── storybook/ # コンポーネントカタログUIコンポーネントだけではなく、デザイントークン、UX哲学やUXライティングのガイドライン、ブランド・コミュニケーションデザイン、Figmaプラグイン。NEWTのデザインに関わるシングルソースを、ここに集めています。デザイナーの頭の中を外に出す先が、このリポジトリです。
設計をした際のいちばん大きな判断は、デザイン案を、本番と同じ部品・同じ構造で作ると決めたことです。
当初、デザイン案は素のHTMLで組んでいましたが微妙でした。コンポーネントが使えないので、画面ごとに少しずつズレが発生しました。そこで、実際のプロダクトで使うUIコンポーネントを packages/ui に集めて、本番のWebアプリもデザイン案も同じ部品を import する形に変更しました。そうすることで、デザイン案の段階から実装と同じ品質で揃います。
そのデザイン案を作る場所が design-mock です。ここで packages/ui のコンポーネントを使って、NEWTのデザイン案を考えます。APIやデータの取り回しといった実装の都合は一切持ち込みません。狙い④で書いた、実装の都合を忘れてデザインだけを考えるプレイグラウンドがここです。
design-mock の中では、デザインを4つの粒度で構造化して持っています。
この4つのうち、実体を本番と共有しているのは ui-component だけです。ui-component の実体はさきほど出てきた packages/ui で、本番のWebアプリも design-mock も同じものを import しています。一方、domain-component や section、page は共有部品にしていません。実装側では画面ごとに組み立てるものなので、部品として共有する必要がないからです。
その代わり、粒度の切り方と命名規則は本番Web・app（iOS / Android）と揃えています。デザイン案を引き渡すとき、ui-component は実物がそのまま使えて、それ以上の粒度は同じ語彙で会話できる。狙い④の後半に書いた、作り直しゼロの引き渡しはこれで実現しています。
MCP：デザインの実体を配信する
構造ができても、AIがそれを読めなければ意味がありません。そこで design-mock は Next.js アプリとして動いていて、画面のプレビューと同時に design-system MCP というMCPサーバを配信しています。AI（Claude Code）はこのMCPを通して、デザインの実体を取得します。用意しているツールはこんな感じです。
このほか、UXライティングガイドを検索するツールなどもあります。
設計のポイントは、取得の粒度です。NEWTは画面数が多くて、デザイン変更の大半は既存画面の修正です。だから、画面全体からひとつの部品まで、必要な粒度でピンポイントに引ける形にしました。ツアー詳細の料金セクションを直したいなら、get_section でそのセクションだけを取ります。ボタンを置きたければ、get_ui_component で本物のButtonの仕様を引きます。
そしてこのMCPは、reiwatravel-mcp という社内共通のMCP環境に載せており、ここが結構大事なポイントです。
MCPサーバは使う側のセットアップが必要で、リポジトリごとに接続設定を書いて、サーバを立てて、トークンを配る必要があります。この手間があるかぎり、プロダクト部署以外の人が使うのはハードルが高いです。reiwatravel-mcp はclaudeのチームプランに入っている社内メンバーが最初から繋がっている環境なので、接続の手間がありません。社内の誰でも、どのリポジトリで作業していても、何も設定せずにデザインのシングルソースへ届きます。
ワークフロー：newt-spec から design-mock の main まで
では、実際のデザインはどう進むのか。ここからは、もうひとつのリポジトリ、newt-spec の出番です。
newt-spec には、実際にデザイン案を組み立てる design-builder や、その中の文言をレビューする ux-writing といったスキルを用意していて、これらのスキルが newt-design-system 内のデザインのシングルソースを取得しながら動きます。PRDと同じ場所でデザイン作業をしつつ、デザインの基準は常に newt-design-system から引いてくる、という動き方です。
前提として、何を作るか・なぜ作るかは newt-spec のPRDで決定済みです。この仕組みが担当するのは、その先のどう作るかになります。
中核になる design-builder スキルの中身は、こういうフォルダ構成です。
design-builder/
├── SKILL.md # ワークフロー本体（Step 0〜8 の手順書）
├── references/ # 判断ルール集（11ファイル）
│ ├── principles.md # UI生成物に適用する非交渉の10原則
│ ├── proposal-rules.md # 成果物HTMLのセクション構成・文章ルール
│ ├── checklist.md # 完成条件。全項目チェックが付くまで終われない
│ └── ...
├── scripts/ # 競合スクショ取得・プレビュー撮影の補助スクリプト
└── templates/ # 成果物HTMLのテンプレートSKILL.md がワークフローの手順書で、references/ が判断ルール集。この references/ の11ファイルが、まさにデザイナーの頭の中の明文化です。ここに書いた判断が、毎回のデザインタスクで再現されます。
実際のステップはこう進みます。
前提の確認：どの画面の、どんな課題かを決める
資料の読み込み：PRDやデザインシステムなどの前提資料を読む
曖昧な点の解消：設計に関わる不明点を、1問ずつ質問して潰す
調査：社内の既存画面をMCPから引き、他社の事例をスクショと出典つきで集める
デザイン案の実装：案ごとに、本物の部品で動く画面を作る
提案：候補から推す案を決めて、理由と仕様をまとめる
成果物づくり：調査・案・仕様を1枚のHTMLにまとめる
共有：PRを出して、Vercelプレビューで誰でも見られるようにする
PM/エンジニアがやることは、newt-spec で Claude Code を開いて design-builder スキルを呼んで、PRDを渡すだけです。あとはステップが順に走って、曖昧な点があれば途中で質問が飛んでくるので、それに答えていけば成果物までたどり着きます。
調査して、仕様を詰めて、案を並べて、推して、まとめる。この、狙い②で書いたデザイナーが頭の中でやっている流れが、そのまま再現されます。
成果物は、調査・デザイン案・仕様が1枚にまとまったHTMLです。
よくあるのが、「AIでUI作りました！」とUI案だけをポンと渡されるシーンで、「これは何のための画面？」「この挙動はどうなってるの？」という往復が始まって、レビューが進みません。判断材料が1枚に揃っていれば、デザイナーは表層だけでなく、仕様まで含んだレビューができます。狙い③の答えが、この成果物の形です。
このHTMLをPRとして出すと、Vercelのプレビュー上でそのまま参照できます。レビューする側はURLをひとつ踏むだけです。プレビューにはコメント機能もあるので、気になる箇所への指摘もその場で完結します。デザイナーがレビューして、OKならそのまま実装に入ります。
ただし、まだできないこともあります。まったく新しい機能の、前例のない画面を、一貫したデザインと最適なUXで最終アウトプットまで仕上げることです。参照すべき前例がシングルソースの中にないゼロイチの画面は、案としては出てくるものの、そのままリリースできる水準にはまだ届きません。
これは割り切りでもあります。UIは一貫性が大事なので、ルールとパターンの上で作ること自体はマイナスになりません。ただ、縛られるのは事実です。なので、体験を大きく変えたい勝負どころの機能はデザイナーが作って、日々の改修はこの仕組みで回す、という棲み分けです。その際も、AIの案を素材にしてデザイナーがFigmaで組み立て直すステップを挟めるようにしてあります。Figmaは中間成果物のマスターから、必要なときに使うツールという位置づけになりました。
そして、確定した案は最終的に design-mock の main にマージされます。これで、誰もが常に最新のデザインを参照できる状態が保たれます。手作業だったFigmaのマスター管理が、ワークフローの一部になりました。
デザインシステムの「読み手」が変わった
ここまで作ってみて、気づいたことがあります。変わったのは、デザインシステムの読み手だということです。
かつてのデザインシステムは、人間が読むガイドラインでした。今は、AIが参照する判断基準になりつつあります。デザインの正の置き場所も、仕様の書き方も、届く範囲も、ここまで書いてきた通り全部変わりました。
人間だけが読み手だった頃、デザインシステムは、ちゃんと読んでもらうことに苦労する存在でした。整備しても参照されず、更新が止まり、いつの間にか実装と乖離していきます。読み手にAIが加わると、この構図が逆転します。AIは毎回律儀に参照してくれるし、参照される限りシステムは死にません。デザインシステムを整備するモチベーションが、初めて仕組みとして回り始めた感覚があります。
これから：デザイン全体のシングルソースへ
design-mock は、いまは design-system の中のひとつのディレクトリですが、目指しているのはもっと先です。
構成の章で触れたとおり、design-system にはすでにUIだけでなく、ブランド・コミュニケーションデザインやUXライティングなどのシングルソースも集まりつつあります。ただ、現時点でMCPとして十分に配信できているのはUIまわりが中心で、それ以外はまだ配信しきれていません。
最終的には、ブランド、広告、LP など、NEWTのデザインに関わるものすべてを design-system に集約して、シングルソースとして reiwatravel-mcp で配信します。UIを作るときも、広告のトーンを合わせるときも、LPを起こすときも、AIも人も同じ一箇所を参照して、NEWTらしさを引きたければここに来れば必ず最新がある状態を目指しています。
やっていることを一言でいえば、デザイナーの頭の中を、構造とワークフローとして外に出した、ということです。
これで変わるのは、デザイナーの仕事のレバレッジです。これまでは、わたしが画面をひとつ描いても、良くなるのはその画面だけでした。この仕組みでは、シングルソースに判断をひとつ書き加えれば、全チーム・全AIの出力に同時に効きます。デザイナーの基準が、デザイナーのいないチームの画面にまで届きます。
この仕組みも、デザイナーという仕事も、まだ変わっていく途中です。同じようなことを試している方がいたら、ぜひお話聞かせてください！
コメント