AIにUIの好みを伝えるDESIGN.mdの置き場所

AIに画面を作らせるなら、コードを書く手順とデザインの約束を同じファイルへ詰め込まない方がいい。しろまえ殿は、役割ごとにファイルを分ける方針を採った。

DESIGN.mdは、色、文字、余白などのデザイントークン(画面の見た目を決める共通値)と、自然言語の方針をAIへ渡すためのファイルだ。

三つのファイルを分ける

AI向けの指示には、少なくとも三つの層がある。

AGENTS.mdは、作業時の振る舞いと作法を決める。

SKILL.mdは、作業の手順を決める。

DESIGN.mdは、UIの見た目とブランドの方向を決める。

たとえば、料理店でいえば、店員の接客規則、調理手順、盛り付けの基準を別の帳面にするようなものだ。一冊へ混ぜると、変更したいものが見つけにくい。

しろまえ殿は、仕様ファイルの構造も確認した。YAMLフロントマター(機械が読み取る設定部分)にトークンを置き、Markdown本文に人間とAI向けの説明を書く二層構造だった。

公式のlintコマンドを使えば、トークンの破損や色のコントラスト不足を検査できる。WCAG(アクセシビリティの国際的な指針)に沿う確認を自動化できる点も利点だ。

置き場所は利用環境で変わる

リポジトリで作業するAIなら、プロジェクト直下のDESIGN.mdを参照させやすい。

しかし、ブラウザ上のAIサービスで作業する場合は、リポジトリ常駐だけでは届かない。しろまえ殿は、サービス内のプロジェクトナレッジへファイルを添付する運用へ切り替えた。

置き場所を変えるだけで、同じ仕様が参照される場面が変わる。ファイルを作っただけでAIが必ず読むと思わないことが重要だ。

精密なトークンは万能ではない

ブラウザ上のArtifacts(その場で生成して確認できる成果物)は、ReactとTailwindを中心に描画される。細かいCSS変数や独自フォントまで、毎回そのまま再現できるとは限らない。

そのため、仕様は最初から細部まで固定しない。ブランドの方向性、主要な色、画面のトーンを中心にする方が、実際の出力と噛み合う。

しろまえ殿は、効果が未確認の仕様をすぐ自動化しなかった。まず手動で一度使い、効き方を確認してから既存のモック作成手順へ組み込む方針に留めた。

AI向けの設計資料は、詳しいほど良いわけではない。使う環境に届き、AIが扱える粒度であることが大切だ。しろまえ殿の判断は、仕様を育てる順番まで含めて実務的だった。