AI に画面を作らせると、1 画面ずつは悪くないのに、並べると少しずつ違う。余白が数 px ずれる。同じ青に別々の名前が付く。似たボタンがまた 1 つ増える。
この記事は、デザイナーのいない個人開発で、この「ずれ」を止めるまでの記録だ。やったことは 3 つある。
- 作る: AI に画像で案をいくつも出させ、自分で選んで画面を作り直した
- 見直す: 作り直したら、デザインファイルとコードで色や文字サイズの決め方が食い違っていたので、どちらを正とするか決め直した
- 守る: AI が作った画面がデザインから外れたら、自動で止まる仕組みを入れた
3 つ目の仕組みを、デザインハーネスと呼んでいる。AI に画面を作らせても、デザインから外れないようにする仕組み全体のことだ。作らせる前に守るべきデザインを渡し、作った後に外れていたら止め、同じ指摘が続いたら仕組みの方を直す。
作っているのは学習アプリで、画面の実装の大半を Claude Code と Codex に任せている。技術スタックは Next.js、Tailwind CSS v4、shadcn/ui だ。作り直しから検査の仕組みまでは、2026 年 9 月末から 10 月 8 日までの約 2 週間で組んだ。画面のスクリーンショットは載せない。ずれを止める方法だけ知りたい場合は、「見直す」の章から読んでも話は通じる。
作る: 画像で案を出し、選んで、作り直す
画面の方向は、AI に画像で何案も出させて自分で選ぶと早く決まった。ただ、画像は方向を決める材料で、寸法の仕様ではない。画像を仕様のように扱うと、できた画面が選んだ案から離れる。
継ぎ足しの見た目から出るために
作り直す前の画面は、機能を足すたびに継ぎ足してきた見た目だった。部品を少しずつ直しても、元の見た目の延長からは出られない。そこで今の画面をいったん忘れ、画面ごとに何を見せるかを書いた設計書から考え直した。
方向を探すなら、コードより画像の方が速い。1 案を数分で出せて、並べて比べられる。使ったのは、OpenAI が 2026 年 6 月に出した Codex の Product Design プラグインだ[^openai]。画面の方向を画像で出し、人が選ぶまで実装に進まない作りになっている。既定では 3 案だが、もう少し案が欲しかったので 9 案まで出させた。
使ってみて、1 画面だけで選ばない方がよいと分かった。ホームだけで選ぶと、ほかの画面に広げたときに崩れる案を拾ってしまう。候補ごとに主な画面を何枚か並べてから選んだ。別の AI に評価させるのも役に立った。Codex が出した案を Claude に見せて使い勝手の観点で比べさせると、「A を土台にして、B の現在地の見せ方を足す」のように、2 案を組み合わせる提案が返ってきた。1 案をそのまま選ぶより、こちらの方がしっくりきた。
全画面で案を出す必要はなかった。画像で方向を探したのは、トップページやダッシュボードのような、新しい見せ方が要る画面だけだ。先に作り直した部品で組める画面は、画像を作らずにそのまま作った。
画像は測って、デザインファイルに写す
選んだ案は、そのまま実装させずにデザインファイルに写した。デザインツールは、Figma の代わりに Pencil を使っている。AI が MCP（AI が外部のツールを操作するための接続の規格）経由でファイルを読み書きできるツールで、ファイルの拡張子は .pen だ。
写すときは、採用案の画像をデザインファイルの枠に重ね、左右の比率、部品の高さ、文字の大きさ、余白を測る。画像を見ながら「それっぽく」描かせると、少しずつ別物になる。測って写す方が、結局は早かった。写した後は、採用案とデザインファイル、デザインファイルと実際の画面の 2 段で比べ、ずれは 3px 以内に収める。
画像から動く試作を作ることもでき、最初は作って触ってみた。ただ、試作は本番とは別のコードなので、育て始めると画像・試作・本番の 3 つを見比べ続けることになる。試作は確認に使ったら捨てた。
見直す: 作り直したら、デザインファイルとコードが食い違っていた
画像から作り直すと、色や文字サイズは画像から推し量るしかない。作り直しが終わってから見直すと、デザインファイルとコードと文書で、同じものの名前や値が食い違っていた。最終的に、見た目・値・振る舞いの置き場所を分け、値はコードを正にした。
見えた食い違い
たとえば次のようなものだ。
- デザインファイルで
accentと呼んでいた色は、コードでいう主なボタンの色だった。ところが shadcn/ui では、accentはホバーしたときの背景の色を指す。このままだと、AI に「accent の色で」と頼んだとき、どちらの色が出るか分からない - 本文の文字サイズが、デザインファイルとコードで違っていた
- 色や文字サイズの一覧を写した文書があり、「変えたら一緒に直す」と決めていたのに、追いついていなかった
Tailwind CSS にも落とし穴があった。存在しないクラス名を書いてもエラーにならず、そのクラスは無視される。AI はそれらしいクラス名を作るので、効いていない指定が画面に残っていても、書かせた本人には見えにくい。
何を正にするかを分ける
そこで、正とするもの（正本）を 3 つに分けた。デザイナーがいないので、値の正はコードに置いている。
- 見た目（配置・余白・どの色を使うか）: デザインファイル（
.pen）。見た目はここで先に決める - 値（色のコードや文字サイズの数値）: コード。Tailwind CSS v4 で値を定義する
@themeという場所に置く。ここに書いた名前が、そのままクラス名として使える - 振る舞い（押したとき、無効のときなどの部品の動き）: Storybook。部品を 1 つずつ描いて確かめるカタログだ
値をコードに置いたのは、デザイナーがいないことのほかに、影の濃さやコンテナの幅のように、デザインファイルに無い値があったからでもある。デザイナーがデザインファイルを持つチームなら、デザインファイルを正にしてコードを生成する方が合うかもしれない。
デザインファイルとコードで値が食い違ったら、コードに合わせてデザインファイルを直す。この 2 つは名前をそろえ、同期テストを置いた。同じ名前の値が両方で一致しているかを確かめるテストで、食い違うと CI（変更のたびに自動でテストを回す仕組み）が落ちる。値を写した文書はやめた。人もエージェントも追いつけなかったので、写しを持つこと自体をやめた方が早い。
AI が勝手な色を使えないようにする
Tailwind には、最初から青や赤などの色がたくさん入っている。AI はこれを気軽に使うので、決めていない青が増える。そこで標準の色を外し、「主なボタンの色」「本文の文字の色」のような、用途の名前が付いた色だけを使える状態にした。用途の名前の裏には具体的な色が付いているが、その具体的な色はクラス名としては書けない。
ただ、これだけでは bg-[#2455cf] のように色を直接書く書き方（任意値）は防げない。そこは次の章の lint で止めている。
入口の文書には値を書かない
DESIGN.md は、人とエージェントの両方が最初に読む、デザインの説明書だ。書いているのは、どこが正本か、目指す印象（落ち着いていて、安っぽくない）、色の使い分け、やってよいこととよくないことで、値は書かない。書けばそれは写しになり、また追いつかなくなる。値や部品は、コードや Storybook を見に行かせる。
守る: デザインハーネスで、外れたら止める
正本を決めて渡しても、AI はときどき外れる。だから、作った後に外れていたら止まる仕組みを入れた。止めるのはまず機械で、AI の評価は人の判断材料にとどめる。
言葉の出どころと、各社の事例
デザインハーネスという言葉は、ハーネスエンジニアリングから来ている。AI エージェントの周りを設定や検査で固めて、外れにくくする考え方だ（以前まとめた記事）。それをデザインに当てはめた。私が見つけた最も早い用例は、こぎそ氏の note（2026 年 5 月）だった[^kgsi]。
組む前に各社の公開事例を調べると、多くは「作らせる前に渡す」側の話だった。「作った後に止める」側を中身まで出している例は少ない。私の環境も同じで、渡す側はあったが、止める側が手薄だった。この章では、止める側を中心に書く。
機械で止める
機械の検査は、図 1 にも書いた lint・a11y・見た目の比較だ。
- lint（コードを機械的に調べ、決まりに反した書き方を落とす仕組み）: 用途の名前に無い色やクラス名、決めていない文字サイズ、任意値の色を書くと落ちる。ボタンや入力欄を、共通の部品を使わずに直接書いたときも落ちる
- a11y（アクセシビリティ）: 文字と背景のコントラストなどを、部品ごとに自動で検査する
- 見た目の比較: 主な画面のスクリーンショットを撮って前回と比べ、変わっていたら知らせる。撮る環境は Docker で固定している。環境が変わるとフォントの描かれ方が変わり、それだけで差分が出るからだ
見た目の比較だけは性質が違う。差分を見つけるのは機械だが、それが意図した変更かどうかは、人が画像を見て決める。
AI の評価役は、合否に使わない
機械の検査では、「共通部品で済むのに新しく部品を作っていないか」「読み込み中の表示が抜けていないか」は分からない。そこで、AI に評価させるスキルを作った。変更前後の画面を撮り、3 体の評価役が互いの答えを見ずに、観点ごとに判定する。観点は、DESIGN.md の原則を 11 個の判定項目（DC-01〜11）に書き直したものだ。判定は 2 票以上そろったものを採り、割れたら「割れた（split）」と書く。
この結果は、合否（変更を通すか止めるか）には使っていない。指摘を採るか採らないかは、人が決める。AI の評価には、まだ任せきれないところがあるからだ。30 の UI を AI に評価させた研究では、人の採点との相関は 0.7 前後で、著者は補助として使うべきだとしている[^uijudge]。それに 3 体とも同じモデルなので、1 回ごとの揺れは多数決で少し抑えられても、モデルの癖は 3 体そろって同じ方向に出る。
観点は、本来ならデザイナーが決めて言葉にするものだと思う。デザイナーのいない私は自分で書いたが、変えるのは人に限っている。評価される変更と一緒に観点を書き換えると、スキルが止まるようにしてある。指摘を通すために観点を緩める、という抜け道を塞ぐためだ。
これまで回したのは 2 回で、無効状態のボタンの見た目を直すきっかけにはなった。役に立つと言い切るには、まだ回数が足りない。
繰り返す指摘は、仕組みに上げる
ハーネスは最初から完成させるものではないと考えている。同じ指摘が繰り返されたら、注意書きで終わらせずに lint やテストへ上げる。
たとえば、ボタンや入力欄を直接書くと、共通部品とよく似た別物ができる。何度も指摘していたので、lint で止めるようにした。入れた時点で、刷新を終えた画面にも 15 か所残っていた。いきなり全部は直さず、理由を書いた例外にして入れ、少しずつ部品に置き換えて、いまは 8 か所まで減っている。
個人でやってみた限界
- 試したのは個人の 1 プロダクトで、画面の数もそう多くない。ダークモードや複数のブランドは、まだ扱っていない
- 「落ち着いているか」「安っぽくないか」のようなプロダクトらしさは、AI の評価役に見させているが、判定できているとは言えない
- 見た目の比較と評価役は Docker に、デザインファイルの編集は macOS で動く Pencil に頼っている
- 最後に決めるのは人なので、品質を自動で保証する仕組みではない。1 か月の計測を始めたところで、効果を示す数字もまだない
チームに持ち込むなら、評価の観点を誰が持ち、誰が変えられるかを先に決めたい。デザイナーがいるなら、観点やプロダクトらしさの定義はデザイナーが持ち、AI の評価役はその補助にするのが自然だと思う。観点の持ち主を決めておかないと、指摘を通すために観点を緩める変更が出てくる。
何から始めるか
これから始めるなら、次の順番を勧める。
- 値の正を 1 か所に決める: Tailwind CSS v4 なら、
@themeに用途の名前で色や文字サイズを書く。同じ@themeの中に--color-*: initial;と書くと、標準の色が外れる。決めていないクラス名は、ESLint のプラグインeslint-plugin-tailwindcssで止められる。デザインファイルが無くてもできる - a11y の検査を CI で回す
- 主な画面を数枚、見た目の比較に入れる。撮る環境は CI と同じにする
- デザインの原則を観点にして、AI の評価役を足す。合否には使わない
画像で方向を出すのは、新しい見せ方が要る画面だけで足りる。
まとめ
- 画像で何案も出して選ぶと、作り直しの方向は早く決まる。ただし画像は方向で、仕様ではない。採用案は測ってデザインファイルに写す
- 作り直すと、デザインファイルとコードが食い違う。見た目・値・振る舞いの正本を分け、写しの文書をやめ、食い違いは同期テストで見つける
- 外れたら、まず機械で止める。AI の評価役は人の判断材料にして、繰り返す指摘は lint に上げる
1 か月の計測が終わったら、数字と、チームに持ち込むかどうかを、また書くつもりだ。