実案件で見えた、DESIGN.md × Copilot × Claudeという新しい進め方
ここ最近、「AIでUIを作る」「デザインもAIがやる時代」といった話題をよく目にするようになりました。
ただ正直なところ、
- 絵はそれっぽく出るけど、実装につながらない
- プロトタイプ止まりで、案件では使えない
- 結局人が作り直している
…という印象を持っている人も多いのではないでしょうか。
先日行った UIデザイナーさんとの案件確認ミーティングで、その認識が大きく変わる話を聞く機会がありました。
それは「AIを使ったUIデザインの進め方」そのものが、すでに次のフェーズに入っている、という話です。
「Figmaで画面を作る」前にやっていること
まず印象的だったのは、
いきなりFigmaで画面を作っていない という点です。
やっていることはシンプルで、
- クライアントからもらった要件を、すべて日本語で整理する
- それを AI に渡して「開発に落とせる要件定義」に再定義させる
- API、DBテーブル、画面一覧、必要な機能がリストアップされる
- そのうえで フロントエンド向けの設計情報を明確化する
この段階ですでに、
「どんな画面が必要か」
「どんなデータ構造になるか」
「どんなUIパーツが要るか」
がかなりの精度で見えています。
UIデザインの核は「DESIGN.md」
ここで使われていたのが DESIGN.md という考え方です。
DESIGN.md は、
- 色
- タイポグラフィ
- レイアウトルール
- コンポーネントの使い方
- レスポンシブの考え方
といった 「デザインの意図そのもの」 を
Markdownで言語化したドキュメントです。
この案件では、
- Tailwind CSS を前提
- shadcn/ui をベースにしたコンポーネント設計
- CTAはニアブラック、ブルーはリンク・フォーカス用途のみ
- ガラス感のあるSoft Glass Dashboardスタイル
といったルールが、すべて文章として定義されていました。
つまり 「絵」ではなく「ルール」 がデザインの本体になっています。
Copilot / Claude は「描くAI」ではない
重要なのは、
AIは「勝手にデザインを考えている」わけではない、という点です。
実際には、
- DESIGN.md
- 要件定義
- API仕様
- DB構造
これらを すべて読ませたうえで、
このルールに従って、新しい画面を作ってください
と指示しています。
その結果、
- ページ追加
- ボタン追加
- フォーム追加
- 既存UIのトーンを保ったままの改修
といった作業が、
ほぼ人手の微調整だけで完了する 状態になっていました。
デザイナーの仕事は「オーケストレーション」へ
この話の中で、とても印象的だったのがこの視点です。
人がやるべきなのは、デザインそのものじゃなくて
AIをどう動かすかのオーケストレーション
- どの情報を与えるか
- どこまで厳密に定義するか
- どこを人がチェックするか
ここを設計することで、
- 人が作るより速い
- 人が作るよりブレない
- 修正コストが圧倒的に低い
という状態が実現されていました。
「デザインの味」は消えるのか？
よくある不安として、
AIを使ったら、デザイナーの個性がなくなるのでは？
という話があります。
このミーティングでは、それに対してこんな方向性が示されていました。
- 過去の自分のデザインをMarkdown化する
- 判断基準・美意識を言語化する
- それを DESIGN.md として蓄積する
つまり
デザイナーの個性は「絵」ではなく「言語」に宿る
という考え方です。
これはPoCではなく「実務で使われている」
ここが一番重要なポイントですが、
このやり方は デモでも研究でもなく、実際のクライアント案件で使われていました。
- 要件定義
- デザイン
- 実装
- レビュー
すべてがAI前提で回り始めている、というのはかなり衝撃的です。
これからのUIデザインに必要なスキル
この話を通して見えてきたのは、
- Figmaが不要になる、という話ではない
- ただし「描ける」だけでは足りない
という現実です。
これから価値が高まるのは、
- 要件を構造化できる力
- デザインを言語化できる力
- AIに正しく渡すための設計力
UIデザインは、
「作る仕事」から「定義する仕事」へ
確実にシフトしていると感じました。
もしこれまで
「AIデザインはまだ早い」
と思っていた人がいたら、
一度 DESIGN.mdを書くところから 試してみるのは、かなりアリだと思います。
Discussion