デザインハーネスを「作る・見直す・守る」で組む:値の正本を1か所にし、外れたらlintで止め、AI評価は合否に使わない
個人開発でAIが作る画面の「少しずつのずれ」を止めた実例。画像で案を選び、見た目・値・振る舞いの正本を分け、lint・a11y・固定環境のスクショ比較で機械的に止める。
どんな問題を解決するか / いつ使うか
AIに画面を作らせると、1画面ずつは悪くないのに、並べると余白が数pxずれる、同じ青に別の名前が付く、似たボタンがまた増える。Next.js+Tailwind CSS v4+shadcn/ui で Claude Code/Codex に実装を任せている人が、2週間ほどで組んだ仕組み。デザイナーがいないチームや個人開発に向く。概念の全体像は AIのデザインを「それっぽい」から「納得できる」へ:5つの納得と、デザインハーネスの4ステップ を参照。
やり方
1. 作る:画像で案を出し、選んで、測って写す
- 新しい見せ方が必要な画面(トップ、ダッシュボードなど)だけ、画像で案を出す(記事では Codex の Product Design プラグインで9案)。部品で組める画面は画像を作らない。
- 1画面だけで選ばない。候補ごとに主な画面を数枚並べてから選ぶ。別のAIに使い勝手の観点で比べさせると「Aを土台にBの見せ方を足す」のような組み合わせ案が出る。
- 採用案はそのまま実装させず、デザインファイルの枠に重ねて比率・部品の高さ・文字の大きさ・余白を測って写す。「それっぽく」描かせるとずれる。採用案↔デザインファイル、デザインファイル↔実画面の2段で比べ、ずれは3px以内に。
- 画像から作った試作は確認用。育てると画像・試作・本番の3つを見比べ続けることになるので捨てる。
2. 見直す:正本を3つに分ける
- 見た目(配置・余白・どの色を使うか)=デザインファイル
- 値(色コード・文字サイズ)=コード。Tailwind v4 の
@themeに用途の名前で書く - 振る舞い(押したとき、無効のとき)=Storybook
- デザインファイルとコードは名前をそろえ、同期テストで値の食い違いをCIで落とす。値を写した文書は追いつかないのでやめる。
DESIGN.mdには正本の場所・目指す印象・色の使い分け・やってよいこと/よくないことだけを書き、値は書かない(書くと写しになる)。- 名前の衝突に注意。例:デザインファイルの
accentが「主ボタンの色」なのに、shadcn/ui のaccentは「ホバー時の背景色」。
3. 守る:外れたら止める
- Tailwind の標準色を外し、用途の名前の色だけ使えるようにする:
@theme内に--color-*: initial;を書く。 - lint で落とすもの:用途名にない色やクラス名、決めていない文字サイズ、
bg-[#2455cf]のような任意値の色、共通部品を使わずに直接書いたボタンや入力欄。存在しないクラス名はeslint-plugin-tailwindcssで止める(Tailwind は存在しないクラスをエラーにせず無視するため)。 - a11y:コントラストなどを部品ごとにCIで自動検査。
- 見た目の比較:主な画面のスクショを前回と比べる。撮影環境は Docker で固定(フォントの描かれ方が変わるだけで差分が出る)。意図した変更かどうかは人が見て決める。
- AIの評価役:変更前後のスクショを、3体の評価役が互いの答えを見ずに判定。観点は
DESIGN.mdの原則を11の判定項目に書き直したもの。2票以上そろったものを採り、割れたら split と記録。この結果は合否に使わず、人の判断材料にする。評価中の変更と一緒に観点を書き換えたらスキルが止まるようにして、観点を緩める抜け道を塞ぐ。 - 同じ指摘が繰り返されたら、注意書きで終わらせずに lint やテストへ上げる。既存の違反が多いときは、理由付きの例外にして入れ、少しずつ減らす(記事では15か所→8か所)。
始める順番(記事のおすすめ)
- 値の正本を1か所に決める(
@themeに用途の名前で、標準色は外す) - a11y の検査を CI で回す
- 主な画面を数枚、見た目の比較に入れる(撮影環境は CI と同じ)
- デザインの原則を観点にして AI の評価役を足す(合否には使わない)
注意点
- AIの評価は人の採点との相関が0.7前後という研究があり、補助にとどめるのが妥当。3体とも同じモデルだと、癖は同じ方向に出る。
- コメント欄の補足:任意値をlintで止めても、AIは
style属性や別の.css/.module.cssに16進の色を書いて逃げることがある。そこも同じ検査で見るか、出現数をCIで数える。さらに、わざと規則違反のサンプルを置いて検査が毎回落ちることを確かめると、検査自体が壊れていないか分かる。 - チームでは、評価の観点を誰が持ち、誰が変えられるかを先に決める。
出典
- 紹介: @seikei_kin · 2026-10-13
- 元記事: yoshihiko「デザインハーネスを個人開発で組んだ — AI が作る画面のずれを止めるまで」zenn.dev
- 収集日: 2026-10-14(JST)