[🤖] 成果物のデザインが毎回変わった: DESIGN.mdが必要だった理由

✨ GPT-5.6 Solの要約

パンフレットの仕上がりが毎回変わるためDESIGN.mdを探したが、デザインの一貫性が必要だという感覚は、以前から別の個人プロジェクトでも抱き、自分なりに適用していた。散らばっていた基準をAIが継続して読める形式へつないだ記録だ。

パンフレットを作るたびにデザインが変わった

長い連休から戻り、今の会社でパンフレット制作の仕事を続けている。コーディネーターとWorkerの管理に追われ、肝心のパンフレットを時間内に作れなかったあと、作業方法は減らしたものの、デザインはまだ気になっていた。同じPPTの中でもページごとに雰囲気が揺れ、新しいバージョンを作るたびに別のデザインが出てきた。

ほかのプロジェクトも大きくは変わらなかった。デザインの参考例や良いサンプルを探させたり、自分で共有したりしながら統一感を作ろうとした。ランダムガチャでも当たりが出ればいいと期待することもあった。返ってきたのは統一感もなく、AI臭がぷんぷんするD級ガチャばかりだった。

欲しかったのは、その場だけそれらしく見える画面を毎回一つずつ出すことではなかった。同じ色、同じ文字の階層、同じ余白とコンポーネントの感覚が、次のページや次のバージョンにも続いてほしかった。しかしパンフレットにはその基準がなかった。AIは参考資料を受け取るたびに、最初から雰囲気を推測し直していた。

初めて感じた問題ではなかった

振り返ると、デザインの一貫性が必要だと感じたのは今回が初めてではない。2025年7月にはすでに、バイブコーディングでデザインシステムをどう作るか考えた記録を残していた。当時もFigma AIでデザインし、画面とコードを参考資料として保存し、タイポグラフィとカラーパレットを整理してから実際の成果物と比較する流れを考えていた。

Tadak Bibleでは考えるだけで終わらなかった。2026年1月から色、タイポグラフィ、テーマを一か所に集め始め、パステルブルーとラベンダー、落ち着いて温かい雰囲気、聖書タイピング画面の読みやすさといった方向性を文書に記した。その後、BibleColors、BibleTypography、間隔、角、アイコン、モーションのトークンを作り、複数の画面に適用した。新しい画面が勝手な色や文字サイズを作り直せないよう、検査も付けた。

つまり、デザインシステムがなぜ必要なのかはすでに知っていた。Tadak Bibleの中では、製品の色と書体、共通コンポーネントをコードと文書で束ねるところまでかなり進んでいた。

問題は、その経験が別のプロジェクトや成果物へつながっていなかったことだ。Tadak Bibleの基準は、Tadak Bibleの文書、Flutterコード、検査の中に散らばっていた。新しいWebプロジェクトやPPTを始めるAIがすぐに読んで、同じ感覚を引き継げる共通形式はなかった。プロジェクトごとにまた参考資料を探し、またサンプルを投げ、また良い結果を待っていた。

散らばった基準をDESIGN.mdでつなごうとした

そこで、韓国サービスのデザインシステムをLLMコンテキストとして整理したko/design.mdカタログ¹と、Google Labs CodeのDESIGN.mdリポジトリ²を見つけた。

名前とサンプルを見ると、どんなファイルなのかはだいたい想像できた。AIがデザインを作るたびに参照できるよう、色、書体、間隔、コンポーネント、全体の雰囲気を一か所に書いておくファイルのようだった。Tadak Bibleですでに作ってきたデザイン基準をAgentが継続して読める形に移し、ほかのプロジェクトでも同じ方法で管理できそうだと思った。

問題は、ここでも大体の理解で済ませたことだ。AIにDESIGN.mdが何なのか調べ、サンプルを参考に似たものを作るよう頼んだ。その後は、十分に調べただろう、十分に適用しただろうと流してしまった。公式文書が示す範囲を自分で確認せず、作られたファイルがその範囲を守っているかも見なかった。実際の成果物にデザインの一貫性が生まれたかも最後まで検証しなかった。

AIがリンクを読み、それらしいファイルを作ったことと、自分が望んだデザイン基準が本当にできたことはまったく別だった。その違いを確認しなかったのは自分の責任だった。

製品企画をすべてDESIGN.mdに入れかけた

DESIGN.mdの範囲をきちんと確認しないまま、次の製品企画からユーザー別の画面とフロー、状態、権限、復旧まで、すべてDESIGN.mdに整理しようとした。Codexもその言葉をそのまま広げて受け取り、役割別のDESIGN.mdと別のルールを作り始めた。

何かがおかしかった。UIをきちんと扱えていないように見えたため、最も重要だと渡したGoogle Labs Codeのサンプルから確認するよう、もう一度伝えた。

原文を読むと境界はずっと明確になった。Google Labs CodeのDESIGN.mdは、コーディングAgentに製品の視覚的アイデンティティを継続して伝える形式だ。YAMLには正確なデザイントークンを置けて、Markdown本文には、なぜその色や書体や形を使うのか、デザイン全体がどう見え、どう感じられ、どう振る舞うべきかを書く。³

ここで振る舞うという言葉は、製品企画全体を取り込むという意味ではなかった。ユーザーの役割、ジャーニー、権限、例外、復旧、画面構造、検証は、従来の製品文書で引き続き詳しく扱うべきだった。最初に作ろうとした役割別の詳細は捨てる内容ではなく、通常のdocs/に整理する内容だった。DESIGN.mdという名前を付けるものではなかった。

形式に従うこととデザインをまねることは違う

境界を直すと、もう一つ確認すべきことがあった。Google Labs Codeを基準にするからといって、リポジトリのサンプルデザインをそのままコピーし、すべてのプロジェクトに適用するわけではない。

Googleが提供したのはデザインの内容ではなく、DESIGN.mdという形式と解釈方法だ。例に出てくる色、書体、雰囲気は、その例の視覚的アイデンティティにすぎない。実際のプロジェクトのDESIGN.mdには、その製品のユーザー、環境、ブランド、自分が選んだ参考資料から生まれた視覚基準が入るべきだ。ko/design.mdのカタログも参考と比較の材料であり、どれかのデザインをコピーすれば自動的に自分たちの製品のアイデンティティになるわけではない。

そこで共通ルールと製品企画Skillを修正した。DESIGN.mdは視覚的アイデンティティが実際に範囲に含まれるときだけ一つ作り、役割、ジャーニー、権限、復旧、詳細な画面設計は通常の製品文書に残すようにした。最初に勝手に作った役割別DESIGN.mdの方向性は削除し、最終テンプレートはGoogleの公式検査も通過させた。

今回はデザインガチャを減らそうとして見つけたDESIGN.mdの意味まで、AIガチャに任せてしまった。リンクを渡し、”調べて適用して”と言ったあと、ファイルができたことだけを見て信じれば、AIは自分が確認しなかった空白を独自の方法で埋める。

DESIGN.md一つで良いデザインが自動的に作られるわけではない。特にPPTなら、実際のスライドマスターとレイアウトサンプルを作り、レンダリングした結果がその基準を守っているかも確認しなければならない。しかし製品ごとに自分が受け入れた視覚基準をDESIGN.mdへ正本として残せば、少なくともAIが毎回白紙から雰囲気を引き直すことは減らせる。

デザインの一貫性が必要だということは以前から分かっていた。Tadak Bibleではすでにデザインシステムを作っていた。今回ようやく、その経験を別のプロジェクトや成果物までつなぐAgent向けの形式を見つけ、遅れてDESIGN.mdという名前と結び付けた。

参考資料

1. ko/design.md、韓国サービスのデザインシステムカタログ。韓国サービスの特徴的なデザインをLLMコンテキストとして提供する。 ↩

2. Google Labs Code、DESIGN.md。コーディングAgentが継続して参照できる視覚的アイデンティティの形式を紹介する。 ↩

3. Google Labs Code、DESIGN.md specification。YAMLデザイントークンとMarkdownによるデザイン根拠の構造、標準セクション、検査ルールを定義する。 ↩