AIに作らせた画面が「AIっぽい」のは、センスの問題ではない

生成AIに「プロフィール画面を作って」と指示すると、毎回同じパターンが出てくる。全画面中央のヒーロー、3カラムの等幅カード、紫から青のグラデーション、純黒の文字に純白背景。見た瞬間に「AIが作った」と分かり、中身も既製品だと思われてしまう。これはモデルの美的センスが貧弱だからではなく、指示に色も書体も余白も書かれていないから。判断材料がない状態で判断を求められたら、学習データの中でもっとも頻度の高い形（最頻値）が出る。「おしゃれにして」と足してもダメ。その語もまた最頻値に紐づいているからだ。

対処は実装より先に設計を確定させること。造形を決める工程を実装から切り離し、仕様書を唯一の入力にする。実装役は仕様書に書かれていない造形が必要になったら、自分で決めずに実装を止めて差し戻す。「書かれていないので推測しました」を許すと、推測の中身は最頻値に戻ってくる。決める順序も重要で、色から決めない。色から決めると、骨格が最頻値のまま残り、配色だけ変わった同じ画面ができる。構造→トークン（色・書体・グラデーション禁止）→状態（ホバー・フォーカス・ローディング・エラー・成功の8つ全部）→モーション→コピーの順だ。特に忘れられやすい状態が2つある。キーボード操作時のfocus-visibleと、非同期処理中のloading。この2つが抜けると、ユーザー体験が壊れる。

AIにUIを作らせるなら、仕様書を先に完成させよ。その仕様書には「純黒#000000を使わない。#16203Dに寄せる」のように、判定可能な基準を書く。実装後のレビューで「なぜこの色？」と主観で返すのではなく、「仕様書の5.2節に違反している」と機械的に指摘する。並列実装は許せるが、設計だけは1画面ずつ。複数画面を同時に設計させると、直前の画面との構造の重複を検出できず、全部同じ骨格になる。この設計・実装・レビュー役の3人格をClaude Codeのサブエージェントとして定義し、GitHub Issue単位で並列運用する事例も既にある。「AIっぽさ」は、入力の品質で消える。