「Claudeで作った感じ」と言われて、デザインの違和感を言葉にするSkillを作った

「Claudeで作った感じがする」と言われて、悲しかった。

実際に手を動かし、考えながら作ったサイトだった。AIを使ったことは事実だとしても、上から見て「AIっぽい」とまとめられると、自分の判断まで消されたように感じた。

でも、悔しいだけでは次を直せない。

何がAIっぽかったのか。余白なのか、色なのか、構成なのか。それとも、どこにも作り手の選択が見えなかったのか。

この曖昧な違和感を、AIと人が一緒に調べるためのCodex Skillを作った。名前は design-judgment-loop。完成した要望を書けない人でも、「うーん」から始められる。

まず30秒で使う

Skill本体はGitHubで公開している。

• design-judgment-loopをダウンロードする

ダウンロードしたフォルダを、使うAIに合わせて丸ごと置く。

Codex       $HOME/.agents/skills/design-judgment-loop/
Claude Code $HOME/.claude/skills/design-judgment-loop/

次に、直したい画面を添えて呼ぶ。

Codex
$design-judgment-loop この画面、AIっぽい気がする。でも何を直せばよいかわからない

Claude Code
/design-judgment-loop この画面、AIっぽい気がする。でも何を直せばよいかわからない

言葉が出なければ、これだけでよい。

$design-judgment-loop うーん

追加後に表示されない場合は、CodexまたはClaude Codeを再起動する。

実際には5段階で進む

1. 画面と「うーん」を渡す
2. Skillが、画面から確認できる事実を短く返す
3. 一度に一つだけ質問する
4. 答えが「わからない」なら、質問を止めて比較案を出す
5. 最後に、次に試す修正を一つだけ決める

AIに正解を選ばせるのではない。人が比較し、自分で「こちらのほうが近い」と判断できるところまで運ぶ。

デザインの要望を書ける人だけが、入口に立てる問題

AIにサイトを作ってもらうとき、よく「要望を詳しく書いてください」と言われる。

ところが、デザインに自信がない人ほど、ここで止まる。

• どんな雰囲気にしたいか浮かばない
• 参考サイトを何と比べればよいかわからない
• 画面を見ても違和感を感じにくい
• 違和感はあっても、名前をつけられない

つまり、センスがないから困っているのに、最初からセンスのよい指示を要求される。これは入口の設計が逆だと思った。

必要なのは、完成した要望ではない。「なんとなく違う」という未完成の反応を受け取り、糸口を一緒に探す仕組みだった。

「わからない」を有効な入力にした

このSkillでは、最初から専門用語を求めない。

画面と一緒に、次の一言だけでも始められる。

$design-judgment-loop うーん。違和感はあるけど言葉にできない

AIはすぐに採点せず、まず画面から確認できる事実を短く返す。

たとえば「見出しとボタンの強さが近く、最初にどこを見るか迷いやすく見える。あなたも近い？」と聞く。

そこで「わからない」と答えてよい。候補をいくつか示し、「正しいもの」ではなく「一番違わないもの」を選べるようにする。

二度続けてわからなければ、質問をやめる。現在の案と、要素を減らした案、主役を強くした案、固有の要素を足した案を並べる。比較して初めて見える差があるからだ。

4つの入口から、1本だけ深く見る

何もわからない状態で自由回答を求めても、答えは出にくい。そこで最初の入口を4つにした。

1. 使う：目的を達成できるか。迷わず操作できるか。
2. 整える：情報の順番、余白、文字、視線が整理されているか。
3. 残す：作り手やブランドの固有性が見えるか。
4. 届ける：相手と状況に合い、意図した印象が伝わるか。

選んだ入口から、さらに4つの観点へ進む。その先も4つある。ただし、64問を全部聞く仕組みではない。

一度に進むのは1本だけ。深さも最大3層まで。最後は「次に試す一つの修正」で止める。

デザインの判断を増やすのではなく、今見るべき場所を狭めるための木だ。

AIっぽさは、摩擦が消えすぎた結果かもしれない

2026年に公開されたWeb vibe codingの研究では、生成AIが主流の様式を再生産し、Webデザインを均質化する可能性が検討されている。研究チームが対策として挙げた中心概念は、迷いを完全になくすことではなく、既定の出力へ異議を唱えるための「productive friction」だった。

これは今回の感覚に近い。

速く生成し、すぐ完成に見せるだけでは、人が「なぜこれを選ぶのか」を考える瞬間まで消えてしまう。便利さを捨てる必要はない。しかし、比較して迷い、選び直す小さな摩擦は残したほうがよい。

design-judgment-loop は、AIの出力を自動で美しくするSkillではない。人が一度立ち止まり、自分の判断を画面へ戻すためのSkillだ。

センスは、頭の中だけで完成させる力ではなかった

デザイン研究を読み直すと、今回の会話と重なる考えが多かった。

Nigel Crossは、デザインには科学や人文学とは異なる「designerly ways of knowing」があると論じた。その後の論考では、専門家に強く発達している能力も、程度の差はあれ誰もが持つと整理している。

DorstとCrossは、デザインでは問題と解決案が同時に変化すると説明した。最初から正しい問題文があり、それに答えるだけではない。案を見て初めて「本当に気になっていたのはここだ」とわかる。

日本デザイン学会の「違和感をデザイン対象として扱うための基礎研究」も、違和感を単なる失敗ではなく、認知や行動につながる対象として体系的に捉えようとしている。

センスを磨くとは、正解を暗記することではないのかもしれない。

見る。少し変える。並べる。自分の反応を確かめる。その判断を言葉に残す。次の画面でも試す。

この反復で、美的判断の解像度が少しずつ上がる。

このSkillが返すのは、正解ではなく次の一手

最終的な出力は長い評論ではない。

• 観察できた事実
• まだ確認できていない仮説
• 今回選んだ判断軸
• 変更前と変更後の差
• 次に試す一つの修正

この5つを分けて返す。

修正後は、最初に意図した印象と、実際に人が受け取った第一印象を比べる。AIだけの推測なら「未確認」と明記する。

うまくいった判断も、一回で普遍原則にはしない。別の画面でも再現したときに、ようやく「自分の原則候補」として残す。

以前、私はデザインを小さな判断へ分解する方法を書いた。今回は、その小さな判断さえ思い浮かばないときの入口を作ったことになる。

GitHubのSkillは完成品ではなく、自分の困り方に合わせて育てられる。GitHubのSkillを自分用に派生させた記録と同じように、このSkillも使うたびに判断例を増やしていきたい。

「AIっぽい」と言われた痛みは、まだ消えていない。

ただ、次に同じ言葉を聞いたときは、落ち込むだけでは終わらない。「どこがそう見えた？」から始められる。その問いを、責める言葉ではなく、比較できる小さな実験へ変えられる。

そこに、人がAIと一緒にデザインする意味があると思っている。

参考リンク

• GitHub: design-judgment-loop
• OpenAI Academy: Build with Skills
• Claude Code Docs: Extend Claude with skills
• Shin et al. (2026): Interrogating Design Homogenization in Web Vibe Coding
• 山根ほか（2021）: 違和感をデザイン対象として扱うための基礎研究
• Cross (1982): Designerly ways of knowing
• Cross (1990): The nature and nurture of design ability
• Dorst & Cross (2001): Creativity in the design process
• Hekkert (2006): Design aesthetics