2026-09-04  ·  ai · claudecode · ui · デザイン · frontend

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

生成AIに画面を作らせると、毎回これが出てきます。

• 全画面中央揃えのヒーロー。大きな見出し、サブテキスト、その下にCTAボタン
• アイコン付き3カラムの等幅カード
• 紫から青のグラデーション背景、またはグラデーションの見出し文字
• ワードマーク＋リンク5個＋右端にCTAのヘッダー
• 4カラムのリンク＋SNSアイコンのフッター
• 純黒 #000000 の文字に、純白 #ffffff の背景

見た瞬間に分かります。そして分かると信用されません。 「中身も同じように既製品なのだろう」と読まれるからです。

これはモデルの美的センスの問題ではありません。入力の欠落の問題です。

なぜ最頻値が出るのか

「プロフィール画面を作って」と頼んだとき、モデルには色も書体も余白も 指定されていません。判断材料がない状態で判断を求められたら、 学習データの中でもっとも頻度の高い形が出ます。上のリストは、その最頻値です。

つまり、実装役に造形の判断をさせている限り、この結果は避けられません。 プロンプトに「おしゃれにして」「モダンに」と足しても変わりません。 それらの語もまた、最頻値に紐づいているからです。

対処は、実装より先に仕様を確定させること

やることは1つです。造形を決める工程を、実装から切り離す。

[UI設計] docs/design/21-profile.md を書く
            ↓ 仕様書が確定してから
[実装]   仕様書を唯一の入力として実装する

実装役は、仕様書に書かれていない造形が必要になったら、自分で決めずに 実装を止めて差し戻します。 ここが肝です。「書かれていないので推測しました」を 許すと、推測の中身は最頻値に戻ります。

決める順序

構造 → トークン → 状態 → モーション → コピー の順です。

色から決めないことに意味があります。色から決めると、骨格が最頻値のまま残り、 配色だけ変わった同じ画面ができます。

1. 構造

ページの骨格を先に決めます。ルールを1つ置きます。

直前に作った画面と同じ骨格を繰り返さない

3画面続けて「ヒーロー＋3カラム＋フッター」になったら、設計していません。 画面ごとに、その画面の目的に合った骨格があるはずです。

一覧画面なら、そもそもヒーローは要らないかもしれません。 設定画面に3カラムカードを置く理由は、たぶんありません。

2. トークン

• アンカー色は1つ。 主役の色を1つ決め、他は無彩色とその派生に留める
• 書体は2つまで。 見出しと本文、または本文と等幅
• グラデーション背景・グラデーション見出しを使わない
• 純黒 #000000 と純白 #ffffff を使わない

最後の項目は理由を書いておきます。純黒と純白は、現実の紙にも自然光下の物体にも 存在しない色です。コントラストが最大になるので目が疲れますし、 「調整されていない」という印象を与えます。#16203D と #FFFEFB のように わずかに寄せるだけで、印象がかなり変わります。

3. 状態を8つ全部決める

default / hover / focus-visible / active / disabled / loading / error / success

欠けている状態は、実装時に実装役が発明します。 それが崩れの原因になります。

特に忘れられやすく、かつ抜けると実害が出るのが2つあります。

• focus-visible — キーボード操作時の見え方。抜けるとキーボードだけで 操作している人が現在位置を見失います。outline: none だけ書かれて代替が 無い実装は、これが設計されていないから起きます
• loading — 非同期処理中の見え方。抜けると、押したのか押していないのか 分からないボタンができます

4. モーション

足す前に削ります。 消して情報が失われないアニメーションは、消します。

判断基準はこれだけです。「なめらかに見せるため」だけの動きは、 待ち時間を増やしているだけです。1画面で3種類までに抑えます。

5. コピー

文言を仕様書に書きます。実装役に文言を考えさせない、という意味です。

そして数字・証言・ロゴを捏造しないこと。 未確定の数値は —（要確認）として 空けます。プレースホルダのつもりで「10,000+ ユーザー」と書かせると、 そのまま公開されます。これは実際によく起きます。

検査する

仕様書を書いても、実装が従っているかを見なければ意味がありません。 レビュー時に機械的に検査できる項目に落とします。

「色コードがコードに直書きされていないか」は grep で確認できます。 主観を挟まずに判定できる形にしておくと、レビューが機能します。

差し戻し先は実装役ではなく設計役です。仕様書の不足が原因だからです。

1画面ずつ設計する

最後に、運用上の注意を1つ。

設計は並列にしないでください。 複数画面を同時に設計させると、 直前の画面との構造の重複を検出できません。結果、全部同じ骨格になります。

実装は並列でよいのですが、設計だけは1画面ずつです。

まとめ

• AIっぽい画面は、センスではなく入力の欠落から生まれる
• 造形を決める工程を実装から切り離し、仕様書を唯一の入力にする
• 構造から決める。色から決めると骨格が最頻値のまま残る
• 状態は8つ全部。focus-visible と loading が特に抜けやすい
• 検査は主観を挟まない形に落とす
• 設計だけは並列にしない

この設計役をClaude Codeのサブエージェントとして定義し、実装役・レビュー役と 組み合わせた構成を配布しています。無料版（4人格・UI設計役なし）はMITで公開しています。

---

Claude Code に設計・実装・レビューを別々の人格として分担させ、GitHub Issue と ブランチを軸に並列開発を回すための設定一式を MIT で公開しています。 コピーして ./setup.sh を叩けば動きます。技術スタックには依存しません。

https://github.com/quintetkit/quartet

このワークフローだけで実際にツールを 1 つ作りました。Issue の分割から PR、 レビュー、マージまで記録が全部残っています。うまくいかなかった箇所も消していません。

https://github.com/quintetkit/mdlinkcheck

UI 設計人格・レビュー基準・Issue 単位の並列実行スクリプト・実践ガイド 10 章を 足したものは製品ページにあります。