Claude Codeが作るUIが金太郎飴になる問題｜デザインの好みを学習させる

Q: テイスト定義はCLAUDE.mdに直接書いてはいけませんか?

問題ありません。数行ならCLAUDE.mdに直接書くほうが手軽です。 行数が増えたら.claude/rules/へ切り出し、pathsでUIファイル限定にするとコンテキストを節約できます。

Q: 指摘の記録はClaude Codeに書かせてもいいですか?

構いません。修正の直後に「今のやり取りを4項目で.claude/notes/ui-feedback.mdに追記して」と頼めば記録できます。 ただしReactionは自分の言葉に直してください。「より洗練された見た目に」といった要約は、ルールに変換できません。

Q: 初期案そのものを多様にするにはどうすればよいですか?

参照対象を具体的に指定するのが早道です。「既存のsrc/components/Table.tsxの余白と線の使い方に合わせて」のように手元の実装を基準として示すと、既定値から離れられます。 最初の指示の作り方は「Claude Codeに最初に頼むこと10選」も参考になります。 ハブネコのひとこと デザインの好みは、思い出そうとすると出てこないのに、目の前に「違うもの」が出てくると即座に言葉になります。だからこそ、その瞬間のReactionを書き留める価値があるのです。

公開: 2026年9月3日・読了目安8分

#デザイン#CLAUDE.md #Skills

Claude Codeが作るUIが金太郎飴になる問題｜デザインの好みを学習させる

先に結論: AIが作るUIが似通うのは、好みを一度も言語化していないからです。UIへの指摘をRequest/Attempt/Reaction/Statusの4項目で記録し、CLAUDE.mdやSkillから参照させると、同じ指摘の繰り返しを減らせます。

Claude Codeに画面を作らせると、角丸のカードに淡いグラデーション、中央寄せの見出し……と、どのプロジェクトでも似た見た目になる。そんな経験はないでしょうか。

その場で直しても、次のセッションではまた元に戻ります。

この記事では、デザインの好み(テイスト)をMarkdownに蓄積してClaude Codeに参照させ、同じ指摘を繰り返さなくする手順を解説します(2026年9月時点)。

この記事の要点

AIのUIが金太郎飴になる主因は、学習データに多い「無難な既定値」と、好みを言語化していない指示不足の2つです。

対策は3ステップで、①テイスト定義ファイル ②指摘の記録 ③反証レビューによる自動チェックの順に組みます。

記録はRequest(依頼)/Attempt(実装)/Reaction(指摘)/Status(採否)の4項目で1件ずつ残します。

テイスト定義は.claude/rules/に置き、frontmatterのpathsでUIファイルを触るときだけ読み込ませるとコンテキストを節約できます(2026年9月時点、公式ドキュメント)。

効果は「同じ指摘が何回再発したか」で測り、3回目が出た指摘だけをルール本体へ昇格させます。

前提・動作環境

ターミナル版のClaude Codeを想定しています。使うのはCLAUDE.md・.claude/rules/・Skillsという標準機能だけで、追加のツールは不要です。

.claude/rules/のpaths指定やSkillsの挙動はバージョンで差があるため、動きが違う場合はまず版を確認してください。

claude --version

2.1.248 (Claude Code)

なぜClaude Codeが作るUIは”金太郎飴”になるのか

理由は2つあります。1つ目は学習分布の偏りです。世の中に多く存在する書き方ほど「無難な既定値」として出やすくなります。

角丸カード、ドロップシャドウ、青紫のグラデーション、中央寄せのヒーロー。どれも間違いではないため、指定がなければ真っ先に選ばれます。

2つ目は指示不足です。「ログイン画面を作って」だけでは、判断材料が「一般的に多いUI」しかありません。

つまり金太郎飴になるのはモデルの限界というより、好みを一度も言語化していないことが原因です。

やっかいなのは、その場で直しても次のセッションでは元に戻る点です。Claude Codeのセッションは毎回まっさらなコンテキストから始まるため、チャットで伝えただけの好みは残りません(公式ドキュメント、2026年9月時点)。

直す3ステップの全体像

海外の開発者コミュニティでは、UIへの指摘を項目立てて記録に残し、次のセッションの入力として再利用する手法が共有されています(2026年8月時点)。狙いは「一度した指摘を二度させない」ことです。

Claude Codeのデザインテイストを学習させる3ステップのフロー図。ステップ1でテイスト定義ファイルを作り、ステップ2でRequest/Attempt/Reaction/Statusの4項目で指摘を記録し、ステップ3で反証レビューにより違反を自動チェックする流れを示す

ステップ1: デザインテイストをMarkdownに言語化する

最初に、好みを書き出したファイルを1つ作ります。置き場所は.claude/rules/design-taste.mdがおすすめです。

書くときのコツは、後から守られたか判定できる粒度にすることです。公式ドキュメントも「2スペースインデントにする」のように検証可能な表現を推奨しています。

悪い書き方	良い書き方
おしゃれにして	角丸は最大4px、円形はアバターのみ
落ち着いた色で	彩度の高い背景色は使わない。面はグレースケール、色は状態表示だけ
余白を適切に	余白は4の倍数。セクション間は48px
モダンな感じ	グラデーション背景とドロップシャドウは使わない

.claude/rules/に置く利点は、frontmatterのpathsで適用範囲を絞れることです。

---
paths:
  - "src/**/*.{tsx,css}"
---

# デザインテイスト

## 装飾
- グラデーション背景・ドロップシャドウは使わない
- 境界は1pxの実線のみ。角丸は最大4px

## 余白とタイポグラフィ
- 余白は4の倍数。セクション間は48px
- 見出しは左寄せ。中央寄せはエラー画面のみ

pathsを指定したルールは、Claudeが該当ファイルを読んだタイミングで初めて読み込まれます(公式ドキュメント、2026年9月時点)。UIを触らないセッションではコンテキストを消費しません。

なおpathsを書かないルールは起動時に読み込まれ、.claude/CLAUDE.mdと同じ優先度で扱われます。CLAUDE.md本体の書き方は「CLAUDE.mdの書き方」で解説しています。

ステップ2: 4項目でUI指摘を記録する

テイスト定義だけでは「思いついた範囲の好み」しか書けません。使いながら出てくる指摘を、その都度ためていきます。

UI指摘をRequest・Attempt・Reaction・Statusの4項目で記録し、同じ指摘が3回出たらテイスト定義ファイルのルールへ昇格させる流れを示す図解

記録する項目は次の4つです。.claude/notes/ui-feedback.mdのようなファイルに追記していきます。

項目	書く内容
Request	どんなUIを依頼したか
Attempt	Claude Codeが出してきた実装
Reaction	自分がどこを、なぜ嫌だと感じたか
Status	採否と現在地(採用/却下/ルールへ昇格済み)

実際の記録は次のようになります。

## 2026-09-03 売上ダッシュボードのカード

- Request: 売上サマリーのカードを3枚横並びで作って
- Attempt: 角丸16px・ドロップシャドウ・紫グラデーション背景のカード
- Reaction: 影とグラデーションが不要。角丸4px・1pxの境界線だけにしたい
- Status: 採用 → design-taste.md「装飾」節へ昇格済み

4項目のうち最も重要なのはReactionです。「なんか違う」で終わらせず、何がどう違うのかを1文で書くと、そのままルール文に変換できます。

Statusは肥大化を防ぐ役割を持ちます。すべてをルールに昇格させるのではなく、同じ趣旨の指摘が3回出たものだけをdesign-taste.mdへ移す、という運用にします。

Claude Code自身にも、ユーザーの訂正をfeedbackとして保存する自動メモリの仕組みがあります(公式ドキュメント、2026年9月時点)。ただし何を保存するかはClaudeの判断次第なので、確実に残したい指摘は手動記録が安全です。

ステップ3: 反証レビューでテイスト違反を検出させる

記録はためるだけでは効きません。実装後に照合する工程を入れて、初めて再発が減ります。

ここで役に立つのが「敵対的レビュアー」の考え方です。「問題ないか確認して」ではなく「テイスト定義に違反している箇所を探せ」と役割を反転させます。

繰り返し使うなら、Skillとして.claude/skills/design-check/SKILL.mdに置いておくと/design-checkで呼び出せます。

---
description: UI実装がデザインテイスト定義に違反していないか反証する
allowed-tools: Read Grep
---

.claude/rules/design-taste.md と .claude/notes/ui-feedback.md を読み、
直近の変更がテイストに違反している箇所を最低3つ挙げてください。
「問題ありません」で終えることは禁止です。
違反が本当に見つからない場合のみ承認してください。

Skillsは本文が呼び出されたときにだけ読み込まれるため、チェック項目が長くなっても常時コンテキストを圧迫しません(公式ドキュメント、2026年9月時点)。

出てきた指摘のうち妥当だったものは、またステップ2の記録に戻します。この往復が回り始めると、テイスト定義は自分の好みに寄っていきます。

コピペで使える記録ファイルのひな形

.claude/notes/ui-feedback.mdとして保存し、指摘が出るたびに下へ追記するだけです。

# UIフィードバック記録

運用ルール
- 指摘が出たらその場で1ブロック追記する
- Reactionは自分の言葉で書く(AIの要約に置き換えない)
- 同趣旨が3件たまったら .claude/rules/design-taste.md へ昇格し Status を更新

---

## YYYY-MM-DD 対象画面・コンポーネント名

- Request:
- Attempt:
- Reaction:
- Status: 未処理 / 採用 / 却下 / 昇格済み(昇格先の節名)

日付と対象名を見出しにしておくと、同じ画面で何度も同じ指摘をしていないかを追いやすくなります。

効果の測り方: 同じ指摘の再発回数を数える

デザインの良し悪しは主観ですが、同じ指摘の再発回数なら数えられます。記録ファイルを月に一度見返し、同じ趣旨のReactionが何件あったかを数えるだけです。

指標	測り方	判断の目安
同一指摘の再発回数	記録ファイルの同趣旨Reactionを数える	3回目が出たらルール本体へ昇格
1画面あたりの手直し往復	完成までのやり取り回数	前月より減っていれば効いている
ルール本体の行数	ファイルの行数を確認	200行を超えたら整理する

再発が減らない指摘は、ルールの書き方が曖昧な可能性が高いです。「余白を適切に」のような判定できない表現になっていないか見直してください。

つまずきポイント: 制約のかけすぎとファイル肥大

バグイヌ

気合いを入れて禁止事項を40行書いたら、今度はどの画面もグレー一色の寂しい見た目になってしまいました…。

ハブネコ

禁止だけを並べると逃げ場がなくなるのです。「使わない」の隣に「代わりにこうする」を1行添えると、方向を示すルールに変わりますよ。

最初から作り込みすぎる: 思いつきで30項目のルールを書かないでください。2回以上出た指摘だけを昇格させるほうが、結果的に効くルールが残ります。
禁止事項だけを並べる: 「〜を使わない」だけでは選択肢が消えます。「代わりに〜を使う」を対で書きます。
ファイルが肥大化する: 公式ドキュメントの目安は1ファイル200行程度です。@pathのimportは分割にはなりますが読み込みは起動時なので、コンテキスト量は減りません。paths付きルールかSkillへ移します。
ルールが読み込まれていない: /contextを実行し「Memory files」に対象ファイルが出ているか確認します。paths付きルールは該当ファイルを読むまで載りません。
書いたのに従わない: CLAUDE.mdやルールは文脈として渡されるもので、強制設定ではありません。守らせたい処理はHookで実装します。

よくある質問

テイスト定義はCLAUDE.mdに直接書いてはいけませんか?

問題ありません。数行ならCLAUDE.mdに直接書くほうが手軽です。

行数が増えたら.claude/rules/へ切り出し、pathsでUIファイル限定にするとコンテキストを節約できます。

指摘の記録はClaude Codeに書かせてもいいですか?

構いません。修正の直後に「今のやり取りを4項目で.claude/notes/ui-feedback.mdに追記して」と頼めば記録できます。

ただしReactionは自分の言葉に直してください。「より洗練された見た目に」といった要約は、ルールに変換できません。

初期案そのものを多様にするにはどうすればよいですか?

参照対象を具体的に指定するのが早道です。「既存のsrc/components/Table.tsxの余白と線の使い方に合わせて」のように手元の実装を基準として示すと、既定値から離れられます。

最初の指示の作り方は「Claude Codeに最初に頼むこと10選」も参考になります。

ハブネコのひとこと

デザインの好みは、思い出そうとすると出てこないのに、目の前に「違うもの」が出てくると即座に言葉になります。だからこそ、その瞬間のReactionを書き留める価値があるのです。

まとめ

Claude Codeが作るUIが金太郎飴になるのは、好みが伝わっていないからです。

対策は、①テイストを検証できる粒度で言語化する ②Request/Attempt/Reaction/Statusの4項目で指摘を記録する ③反証レビューで違反を検出させる、の3ステップです。

効果は同じ指摘の再発回数で測り、3回目が出た指摘だけをルール本体へ昇格させると、肥大化させずに精度を上げられます。

Claude Code全体の使い方は「Claude Codeの使い方完全ガイド」、レビュー役の作り方は「Claude Codeのコードレビュー精度を上げる敵対的レビュアー活用術」、メモリ設定は「CLAUDE.mdの書き方」、手順の自動化は「Claude Code Skillsの作り方」をあわせてご覧ください。