AIが実装の多くを書くチームで「デザイナーが触った画面の割合」を数え、後追いの修正をlintとルールに育てる

どんな問題を解決するか / いつ使うか

デザイナー1人、フロントエンドの多くをClaude CodeやCodexが書くチームで、デザイナーが一度も見ていない画面がリリースされ、部品や色が画面ごとに少しずつずれていくとき。事前レビューでリリースを止めずに、見落としの範囲を減らしたいときに使う。

やり方

1. 現状を数える：顧客向けの画面ファイルのうち、デザイナーが一度でもコミットで触った割合（デザインカバレッジ）を出す。gitの履歴だけで計算できる。事例では255本中73本（28.6%）だった。トークンを使わない直書きの色の数も数える。
2. 週の候補を見る：未判断の画面のうち、直近3か月によく変わったものから3本を、週の最初にClaude Codeを開いたとき表示させる。見てずれていれば直すかチケットを切る。問題なければ手元のファイルに日時つきで「見た」と記録し、判断済みに数える（後から見た目の変更が入ったら未判断に戻す）。
3. design: で記録する：デザインが理由の修正は、コミットの件名を design: で始め、本文の最後に Design-Kind: を1行付ける（例：design(web-ui): 検出事項の状態切替をタブからフィルターへ と Design-Kind: info-arch）。種類は「その他」を作らず、1コミット1種類にする。エンジニアやAIレビュー経由の修正にも付けてもらう。
4. ルールにする：月に一度、Design-Kind: ごとに数え、同じ種類が2回以上あればルールを書く。1回だけのものはルールにしない。
5. 仕様はlint、物差しはレビュー：正誤が決まるもの（生の色、インラインスタイル、存在しないクラス、タブの入れ子など）はlintで止める。@shadcn/lint は、違反時に使うべき部品やトークンをエラー文で示すので、エージェントがそのまま直せる。判断が要るものはDESIGN.mdを根拠にAIレビューで指摘させる。
6. ルールの正本はDESIGN.md：lintにだけあるルールは作らない。部品ごとに「使う場面」と「Don't」を書く（例：取り消せない操作は Button の variant="destructive" を使い、自作の DestructiveButton は使わない）。エージェントには「デザインを変えるとき」でなく「画面を書くとき」に必ずDESIGN.mdを読ませる。
7. 既存の違反は据え置く：初日に大量の違反（事例では630件）が出るので、ESLintの bulk suppressions でファイル×ルールごとの件数を固定し、新しく増えた分だけCIで止める。

注意点

• gitで分かるのは「触った」ことで「判断した」ことではない。design: コミットで触った画面数も並べて出す。
• 成り立つ条件は、デザイナーの判断がデザイナー自身のコミットとして残ること。デザイナーがコードを書かないチームでは「見た」の記録だけで数える。
• 恩恵を受けるのがデザイナー1人なら、カバレッジの仕組みはリポジトリに入れず手元で動かす。
• エージェントは周りのコードを真似るので、ずれは放っておくと増える。入れるなら早いほうがよい。

関連

• デザインハーネスを「作る・見直す・守る」で組む：値の正本を1か所にし、外れたらlintで止め、AI評価は合否に使わない
• デザインハーネスは「5行の採点表」から：対抗する3案を作って採点し、別社のモデルに反論させ、人が決める
• PRごとに「Figmaの設定値」と実装を照合し、差分をPRコメントに出す（figma-vrt-review）
• FigmaをやめてClaude Codeで動くモックを作る：マージしない design/ ブランチと「文脈の三層」

出典

• @kgsi · 2026-11-01
• 記事：セキュリティ思考で作る、1人デザイナーのデザインハーネス（Hiroaki Sasaki）