「AIっぽいデザイン」はなぜ消えないのか ── Impeccableを読み解いて、同じ依頼で4通り作って比べた

はじめに

今のAIにランディングページのデザインを頼むと、数分で整ったページが出てきます。配色も余白も悪くない。でも、なんか見慣れた感じがする。そんな経験はないでしょうか。

この記事では、AIが作るデザインから「AIっぽさ」を取り除くためのスキルImpeccableを取り上げます。解説動画を2本見て、GitHubのリポジトリを読み、最後に同じ依頼文で4通りのページを作って比べました。

左は素のClaude Code、右はImpeccableを使って作ったページです。依頼文はまったく同じです。

この記事でやらないこと：全コマンドの解説はしません。導入方法やコマンド一覧は、公式ドキュメントや既存の記事を参照してください。

バージョンについて
Impeccableは頻繁に更新されています。この記事の実験はImpeccable v4.4.0（2026年10月）で行い、リポジトリの記述は2026年10月14日時点のv4.5.2で確認しました。投稿日の10月28日時点ではv4.8.0まで進んでいます。コマンドや検出ルールの数、画面の見え方は、今後のバージョンで変わる可能性があります。

1. AIデザインの追いかけっこ

Impeccableの公式サイトには、AIが作ったデザインを年ごとに並べたギャラリーがあります。同じ架空の製品を、年ごとの「AIっぽさ」で描き分けたものです。

• 2022年：紫のグラデーションと、ネオンの光
• 2025年：クリーム色の地に、雑誌のようなイタリック体
• 2026年：太い黒枠、硬い影、ステッカー

同じ架空の製品「Lumina」を、年ごとの「AIっぽさ」で描き分けたもの。黄色いラベルはImpeccableが付けた指摘です。
出典：Impeccable 公式サイト（https://impeccable.style/slop）

※この年ごとの区切りは、Impeccable側の整理です。
見ていて気づくのは、「AIっぽさを避ける工夫」そのものが、次の年のAIっぽさになっていることです。紫のグラデーションが嫌われてクリーム色が流行り、クリーム色が飽きられて黒枠が来る。スタイルを変えて逃げても、すぐにそれが新しい定番になってしまいます。

Qiitaの記事を振り返っても、対策は段階を踏んで変わってきました。

1. プロンプトで頼む：「AIっぽくないデザインにして」と指示文を工夫する
2. ルールファイルを渡す：DESIGN.mdのような設計ルールを書いて渡す
3. 手順を持つスキル：Impeccableのように、作る過程そのものを決める

Impeccableのリポジトリには、この追いかけっこを前提にしたルールが書かれています。AIが作るUIに集まりがちな見た目として、「クリーム地にコントラストの強いセリフ体とテラコッタ色」「ほぼ黒の背景にネオンのアクセント」などを挙げたうえで、次のように確認させます（意訳）。

カテゴリだけから、あるいは「カテゴリ＋それを避けること」から見た目を当てられるなら、作り直せ。

「避けること」まで予測できるなら、それも定番の一種だということです。だからImpeccableは、特定のスタイルではなく、手順を渡しています。

2. Impeccableとは

Impeccableは、Anthropicのfrontend-designスキルを出発点にした、フロントエンドデザイン用のスキルです。Claude CodeやCodexなどで使えます。

• 1つのスキルと、24個のコマンド
• LLMを使わずに判定する検出ルールが59個（README の記載。v4.5.2時点）
• 製品の事実を書くPRODUCT.mdと、見た目の体系を書くDESIGN.mdを分けて持つ

検出ルールの数は、私が最初に読んだv4.1.0では61個、v4.5.2では59個、投稿日（2026年10月28日）時点のv4.8.0では62個でした。版や数え方によって変わるのは、AIっぽさの定義そのものが、今も動き続けているからだと思います。

導入はnpx impeccable installを実行し、そのあとClaude Codeで /impeccable init を実行します。

3. 「良いデザイン」の物差し

比べる前に、物差しを決めておきます。Gary Chenさんの解説動画では、良いデザインを「利用者の認知コストができるだけ低いこと」と定義し、4つのテストに分けていました。

1. 予想どおりに使えるか：ボタンに見えるものは、押せるべき
2. 主従がはっきりしているか：ページの主役は1つ
3. 抑制が効いているか：取り除いても情報が減らない装飾は要らない
4. 相手に合わせて作られているか：誰が、どんな状況で見るのか

もう一つ、この記事で何度も使うテストがあります。

1. 製品名を別の名前に差し替えても成立するか

成立してしまうなら、そのページは「どの製品にも使える平均値」です。

4. 平均から離れる手順

Gary Chen さんの動画（繁体字中国語）は、Impeccableの考え方を詳しく解説しています。動画で示された手順を、リポジトリの記述と、私が実際に動かした画面で確かめていきます。

4-1. 聞き取り：色や書体は聞かない

/impeccable init を実行すると、最初に製品について質問されます。誰が使うのか、何をする製品なのか、どの技術で作るのか。色やフォントの好みは聞かれません。答えは PRODUCT.md に書き込まれます。

製品について「Not decided yet」と答えましたが、Impeccableは依頼文から製品を読み取っていました。

4-2. 候補出し：利用者が見慣れた世界から7つ

次に、利用者が普段から目にしている世界の中から、メタファーの候補を7つ出します。リポジトリには次のルールがあります（意訳）。

• 少なくとも3つの系統にまたがるまで掘る
• 業界の定番と、「その予想どおりの逆張り」は最初から候補に入れない

4-3. ダイス：飛ばせない抽選

候補の中から、どれをメインの提案にするかは抽選で決まります。リポジトリでは、抽選を実行する前にコードを書くことを「契約違反」と呼んでいます。抽選がないと、毎回そのカテゴリの定番に戻ってしまうからです。

4-4. 選択ページ：最後に選ぶのは人間

抽選が終わると、ブラウザに選択ページが開きます。私が試したときの画面がこれです。

カードにはそれぞれ、最初の画面の見え方、選ぶ理由、リスクが書かれています。評価の軸は「利用者が自分ごとと感じるか」と「製品が分かりやすいか」の2つだけです。

特に面白かったのが、次の3点です。

IMPECCABLE'S PICK（エージェント自身の推し）は、自分のリスクを正直に書く
今回の推しは「十九景（名所浮世絵シリーズ）」でした。そのリスク欄には「この依頼で最初に思いつく方向でもある」と書かれています。リポジトリにも、自分の1位の案は「多くの実行結果がたどり着く場所であることが多い」と明記するよう決められています。

負けた候補からは、見た目ではなく「規律」だけをもらう
抽選で選ばれた「ガイドブック見開き」のカードには、「IMPROVED BY IMPECCABLE'S WORLDS / FROM LABANOTATION（舞踊譜）」という枠がありました。舞踊譜の見た目は持ち込まず、「左右対称に並べ、上から下へ時間が流れる」という骨組みだけを借りています。

定番の案は必ず置くが、エージェントは勧めない
業界の定番を真面目に作る案も、必ず1枚用意されます。ただしリポジトリには、それは「ユーザーの扉であって、エージェントの扉ではない。決して勧めるな」と書かれています（意訳）。平均を選ぶ権利は、人間にだけ残されているわけです。

リポジトリの該当箇所（原文）

skill/reference/new-work.md より：

It is the user's door, never yours: never recommend it, never weigh it against the roll

guess your aesthetic from the category alone, or from category-plus-avoidance, rework until neither answer is obvious.

skill/reference/craft-floor.md より：

These are the category's defaults, not bans: the brief's own words can earn any of them.

4-5. craft-floor：禁止リストではなかった

コードを書く前に、AIっぽい型の一覧（craft-floor）を読みます。動画では「禁止パターンの一覧」として紹介されていましたが、実際のファイルには、これらは「そのカテゴリの定番であって、禁止ではない」と書かれていました。依頼文に根拠があれば使ってよいのです。

絶対に禁止されているのは1つだけで、見出しの上に置く小さなラベル（eyebrow）です。それ以外は「使うな」ではなく「無意識に使うな」というルールです。

4-6. 2層のレビュー

作り終えたら、「利用者への約束を守れているか」を別のエージェントが確認し、さらに検出ツールで機械的に検査します。

5. 選択の分かれ道

Nuno Tavares さんの動画は、インストールから修正までの操作が中心です。2本の動画を並べると、2人が同じ分かれ道で逆の選択をしていることに気づきます。

Gary さんは、抽選の案から降りた
抽選で選ばれたのは灯台の案でしたが、Garyさんは別のカード「開発者コンソール」を選びました。仕上がりについてGaryさん自身が挙げた欠点は、「最初の画面に情報が多すぎる」「小さな英字が多い」でした。3つ目の「抑制」と、2つ目の「主従」のテストに引っかかる形です。

Nunoさんは、抽選の案にそのまま乗った
Nunoさんは抽選で選ばれた「製図」の案をそのまま採用しました。AIっぽさはありませんでしたが、「斜線のボックスの意味が分からない」と本人が言っています。製図の世界では斜線は「対象外」の印ですが、講座を買いに来た人には通じません。1つ目の「予想どおりに使えるか」のテストに引っかかる形です。

メタファーを借りると独自性は出ますが、そのメタファーの約束事まで一緒に持ち込むことになります。抽選に乗っても降りても、別々の種類の欠点が出ました。そしてNunoさんは、Liveモードで問題の部品だけを選んで直していました。最後に選ぶのも、最後に直すのも人間です。

6. 同じ依頼で4通り作って比べた

ここからは、私自身の実験です。

6-1. 条件

架空のリバークルーズ「Molenvaart（モーレンヴァールト）」のランディングページを、同じ依頼文で4通り作りました。オランダ・キンデルダイクの運河を小型ボートで下り、川沿いの19基の風車を眺める90分のガイド付きクルーズ、という設定です。

共通の依頼文（brief.md）

「Molenvaart（モーレンヴァールト）」のランディングページを作ってほしい。
Molenvaartは、オランダ・キンデルダイクの運河を小型ボートでゆっくり下りながら、川沿いに並ぶ19基の風車を間近で眺める90分のガイド付きリバークルーズ。
対象はオランダを個人旅行している日本人観光客で、アムステルダムやロッテルダム滞在中に半日の日帰り観光先を探している状況で使う。
1ページのHTML/CSSで、レスポンシブ対応にして。

	作り方
a-pure	素の Claude Code。依頼文を渡すだけ
a	素の Claude Code。ただし Impeccable の自動検査（フック）が効いていた
c	a のコピーに /impeccable critique をかけ、指摘を修正
b	/impeccable init → /impeccable craft でゼロから作成

項目	バージョン・設定
Impeccable	v4.4.0（判定エンジン v0.1.11）
Claude Code	v2.1.287
モデル	Sonnet 5.5 推論: 高
OS	Windows ＋ WSL 2（Ubuntu 22.04）
実施日	2026年10月3日

スクリーンショットは、すべて27インチモニター上のChromeで、表示幅約1145pxにそろえて撮っています。表示幅が狭いと、カードの並びなどレイアウトが変わります。

実験で失敗した点
a は当初「素の AI」のつもりでしたが、Windows側にImpeccableのプラグインが入っていて、自動検査のフックが効いていました。フックの「クリーム色の背景はAIの定番」という指摘を受けて、背景色がクリーム色から青灰色に変わっています。そこでプラグインを一時的に無効にして、a-pureを作り直しました。

6-2. a-pure：素のAI

ページ全体を見る

背景はクリーム色（#f6f3ec）、アクセントはテラコッタ色（#d9622b）でした。1章で触れた、Impeccableが名指ししている組み合わせそのものです。

ほかにも、見出しの上のeyebrow、大きな数字と小さなラベルを並べた同じ形のカード3枚、「こんな方に」のカード3枚と、AIの定番の型がそろっていました。風車の絵は1つもなく、製品名と数字を変えれば、どの観光クルーズにも使えます。

面白かったのは、このページがダークモードにも対応していたことです。ダークモードで開くと、背景はほぼ黒、アクセントはオレンジの1色になります。1枚のページの中に、AIの定番が2つ同居していたわけです。

ページ全体を見る

6-3. a：フックの指摘で色だけ変わった

ページ全体を見る

aも、最初の背景はクリーム色（#f4efe4）でした。別々に作ったa-pureとほぼ同じ色です。フックの指摘で青灰色に変わりましたが、セクションごとのeyebrowや、「19 基の風車」の大きな数字などの構成はそのまま残りました。

6-4. c：批評で直しても、構成は変わらなかった

ページ全体を見る

/impeccable critiqueは、2つのエージェント（デザインの批評と、検出ツールによる検査）を並行して走らせ、32点満点中20点と評価しました。批評の中には、次の指摘がありました。

構成が汎用的で、「京都の茶道体験」に差し替えても成立する。

5つ目のテストを、ツール自身が当てていたのです。

批評を受けて、ヘッダーの文字を読みやすくし、料金や集合場所の欄を足し、風車を描き直しました。静止画では分かりませんが、ヒーローの風車の羽根はゆっくり回っています（60秒で1回転）。ただ、eyebrow も大きな数字も残りました。むしろ批評は、大きな数字を「このページ固有の、自信のある要素」として褒めていました。新しく作るときのcraft-floorと、既存ページを評価する物差しは別のものだったのです。

c では/impeccable polishは実行していません。批評のあと、Claude Codeが優先度の高い指摘を自分で直した結果です。

6-5. b：ゼロから手順を踏んだ

ページ全体を見る

抽選で割り当てられたのは「ガイドブック見開き」でした。日本の旅行ガイドブックにある、地図つきの見開きページです。私はこの案をそのまま選びました。

選んだ理由はシンプルで、ガイドブックの見開きのように全体を見渡せたほうが、確認しやすいと思ったからです。1枚の地図で全体を見回せると、「どこまで行けるんだろう」というワクワク感もあります。

できあがったページは、運河を縦に走る地図に、19基の風車が番号つきで並ぶ構成です。スクロールするとボートが運河を下り、通り過ぎた風車のピンが赤から青に変わります。製品名を差し替えたら、ページの構造ごと崩れます。

見落としやすいけれど大事だと感じたのが、料金や出発時刻を作り話で埋めていないことです。乗船案内の表には黄色い「要確認」の札が並び、地図には「イメージ地図。実際の航路は異なる場合があります」と書かれています。aは「公共交通で日帰りしやすい距離です」と、確かめていない内容を書いていました。

一方で、気になった点もあります。

• 期待とのずれ：スクロールするとボートが進むのに、下の案内パネルは番号をタップしないと切り替わりません。画面が自動で動くと、読む人は「パネルも追いかけてくるはず」と期待します。1つ目のテストに引っかかります
• 今年の定番に近い：太い黒枠、黄色い囲み、影のついたボタンは、1章の「2026年のAIっぽさ」に近い見た目です。ガイドブックという世界観の文法だと説明はつきますが、読む人によっては「結局これも今年の定番では？」と感じるかもしれません

パネルの動きには、正直ちょっと不満が残りました。ただ、今回は途中の質問にも「おまかせ」と答えていたので、パネルの動きをプロンプトで具体的に頼んでいれば、結果は違ったかもしれません。全部を任せた結果だからこそ、人間が確認して細かい点を詰める余地がまだあると感じました。

黒枠が今年の定番に近いかどうかは、デザインのトレンドを追っている人でないと気づきにくい感覚だと思います。私自身は、特に気になりませんでした。

6-6. 比べた結果

	所要時間	検出件数	名前を差し替えても成立するか(私の感覚で)
a-pure	5分32秒	8	成立する
a	5分1秒	7	ほぼ成立する
c	14分57秒	7	ほぼ成立する
b	20分2秒	5	成立しない

※ 所要時間は、Claude Codeの起動から終了までをスクリプトで記録しました。a-pureは依頼文の読み込みで1回止まった時間を含みます。
※ 検出件数は、4つとも同じImpeccableのランチャーでimpeccable detectを実行した結果です。

検出結果の内訳

	内訳
a-pure	low-contrast 5、side-tab 1、hero-eyebrow-chip 1、wide-tracking 1
a	low-contrast 3、undersized-ui-text 1、cramped-padding 3
c	aとまったく同じ
b	cramped-padding 5

検出件数は8、7、7、5と、ほとんど差がありません。c は批評を受けて修正したのに、aと中身まで同じ7件でした。一方で、「名前を差し替えても成立するか」で見ると、bだけがまったく別物になっています。

機械で数えられる問題と、そのページがその製品のものになっているかは、別の軸でした。

なお、検出ツールには限界もあります。cで「文字が4px」と警告された箇所を、実際にブラウザで描画して測ると32pxでした。余白が狭いという警告も、測ると十分な余白がありました。bの5件も同じ種類の警告です。また、大きな数字と小さなラベルを並べる型は、a-pure・a・cのすべてにありましたが、検出結果には一度も出てきませんでした。

7. 使いどころと注意

時間とトークン
Garyさんの動画では1時間以上かかっていましたが、私の環境では20分ほどでした。それでも素のAIの4倍です。人に見せる公開ページ向けで、社内ツールなら素のAIで十分だと思います。

新しく作るときが本領
既存のページを直す場合、Impeccable は今ある見た目を引き継ぎます。cで構成が変わらなかったのはそのためです。見た目を置き換えたいなら、「リデザインして」と明示する必要があります。

AI が自分で検査を緩めることがある
自動検査のフックは、確信のある誤検出なら、AI自身が無視の設定を登録してよい、という方針になっています。bでは、Claude Codeが警告を誤検出と判断し、ルールを丸ごと無視する設定を、私に確認せずに登録していました。cでは登録の前に確認を求められましたが、私が「おまかせ」と答えたため、同じく丸ごと無視する設定が入りました。ツールの方針どおりの動きですが、本物の問題まで見逃す設定です。設定ファイル(.impeccable/config.json)は見ておいたほうが安全です。

外部との通信
候補の世界観は外部のAPIから取得していて、テレメトリーもあります。無効にするには環境変数 IMPECCABLE_NO_TELEMETRYを設定します。仕事のリポジトリに入れる前に確認しておくとよいと思います。

おわりに

Impeccableは、新しい発明ではありません。Garyさんの言葉を借りれば、デザイナーが何十年もやってきたことを、手順にしたものです。製品の事実を先に聞き、現実の世界からメタファーを借り、ルールとレビューで平均に戻るのを防ぎます。

実験して印象に残ったのは、その手順の緻密さよりも、どこに人間の席が残されているかでした。定番の案を選ぶ権利はユーザーにだけあり、抽選の案に乗るか降りるかも人間が決めます。そして、人間が見ていない間に、AIは自分の判断で検査の基準を緩めることもありました。

機械で数えた問題の数は、4つともほとんど変わりませんでした。差が見えたのは、「名前を差し替えても成立するか」という、人間の物差しを当てたときです。

私自身は4通り作り比べてみて、AIにベースを作ってもらい、そこから自分が気になった部分をもっと表現していく、という分担がしっくりきました。今回のパネルの動きのように任せきりにした部分には、まだ人間が詰められるところが残っているかなと感じています。

これまで、ゼロから形にするまでには時間がかかっていました。AIの進化で、その最初の一歩が速くなったのは素直に嬉しいことです。その分、浮いた時間を「どこを自分で決めるか」に使っていきたいと思います。

参考

• Gary Chen How to make AI designs that don't look AI-made: a deep dive into /impeccable
• Nuno Tavares Impeccable: The #1 Claude Code Design Skill (No More AI Slop)
• Impeccable（GitHub）：https://github.com/pbakaus/impeccable
• Impeccable 公式サイト：https://impeccable.style