非デザイナーでもデザインシステム通りに画面を作れる仕組みを作った話

新しいプロジェクトが始まったとき、私たちのチームはこんな流れで画面を作っていました。

まずエンジニアがClaude Codeと一緒に機能を実装します。この段階では画面まで一通り動くものができあがりますが、デザインシステムのことはひとまず無視し、動くことを優先します。そのあとにデザイナーが入り、できあがった画面のパーツをデザインシステムのものに入れ替えて、見た目を整えていく、という分担でした。

既存の分担で起きていた課題

役割分担としては悪くないはずでした。しかし実際にやってみると、数十ページに渡る画面を一枚一枚デザインシステムに合わせていく作業は、単純に時間がかかります。見落としも発生しやすくなります。何より課題だったのは、機能がすでに出来上がった状態で渡されるため、「このレイアウトで本当によいか」というデザイナーとしての検討がほとんどできない点でした。整えるだけの作業になってしまい、デザインの意思決定が形骸化していたのです。

このズレをどうにかしたくて、デザインシステムとページ構築の仕組みそのものを作る取り組みを始めてみました。

最初に試して、うまくいかなかったこと

最初に試したのは、画面の要件をそのままClaude Codeに渡して作らせるという、最もシンプルなやり方でした。

結果として出てきたのは、いわゆる「AIっぽいデザイン」が一つだけでした。パターンが1種類しか出てこないため、比較のしようがありません。デザイナーが普段行っているのは、複数の案を並べて「どれが最も適しているか」を検討する作業のはずですが、そこがまるごと抜け落ちていました。これでは結局、後から手直しが必要になり、仕組みを作る意味が薄れてしまいます。

思考プロセスを、手順として言語化する

そこで発想を変え、デザイナーが画面を作る際に頭の中で行っている判断を、そのまま手順として言語化することにしました。

普段の進め方では、デザインを作ったら必ず実際の画面として確認しますし、重要な判断は一人で抱え込まず複数人で検討することが多くあります。「とりあえず一案だけ作って終わり」という進め方は基本的にありません。この、当たり前すぎて意識してこなかった思考のクセを、仕組みの側に組み込むことにしました。

出来上がったのは、要件整理から本番移植まで続く14個のステップ（Step0〜13）です。すべてをここでは紹介しませんが、核になっているのは次の3点です。

判断材料はデザインシステム側の実データから取得する

AIの記憶や一般知識で色や余白の値を推測させるのではなく、既存のトークンやコンポーネントの仕様を、MCP経由で取得した実データを常に正として参照させます。

ページの骨格を決める場面では、複数候補を比較させる

レイアウトのようにページの骨格に関わる判断では、いきなり一つに絞らせません。候補を2〜3個挙げさせ、それぞれの向き不向きを比較表にします。表だけで決めきれない場合は、実際に画面として実装したものを人が見比べて選びます。以前手がけた、実験機の配置状況を確認する画面では、一覧と詳細を並べるレイアウトや検索特化のレイアウトなど3つを比較した末に、「編集機能を持たない確認用途であれば、シンプルなレイアウトで十分」という結論に至りました。比較して初めて見えてくるこの納得感は、一案しか出てこないやり方では得られないものでした。

読み込み中・データがない・エラーの3状態を必ず作らせる

動く画面だけを見て「完成」と判断しないよう、標準の完成条件として組み込んでいます。

現状と今後の可能性

この仕組みは、まだ実際の運用には乗せられていません。すべての課題を解決できたと言える段階ではなく、引き続き改善が必要です。

それでも取り組みを通じて得られた一番の収穫は、「デザイナーの思考は言語化できる」と確認できたことでした。比較して選ぶ、状態を網羅する、判断の根拠を実データに置く。こうした暗黙知だと考えられていたものは、手順として書き出せば、非デザイナーでも辿れるものになります。

デザインシステムを整備していても、現場での活用がうまくいかないという課題は多くのプロジェクトで起こり得るものだと考えています。パーツやルールを整備するだけでなく、デザイナーがページを作る際の思考の順番そのものを言語化することで、チーム全体で判断の質を共有できる可能性を感じています。

この取り組みについてより詳しく知りたい方や、自社のプロダクト開発について相談したい方は、お問い合わせフォームよりお気軽にご連絡ください。