AI生成UIの画一化を防ぐOSS「Impeccable」の仕組み

「AI で書かせたコードなのに、どこかで見たことのある画面になる」——Claude Code や Cursor でフロントエンドを書き進めているエンジニアなら、一度は感じたことがあるのではないでしょうか。紫から青へのグラデーション、カードの中にさらにカードを入れ子にする構造、見出しの上に必ず配置されるラウンド角のアイコンタイル。プロジェクトが変わっても「同じ絵づら」が生まれ続けます。

この「画一化」は個々のプロンプトの書き方だけで解決できる問題ではありません。原因はもっと構造的なところにあります。AI モデルはどれも似た SaaS テンプレートで学習しており、明示的なガイダンスを与えない限り、判で押したようなデフォルトが出力に混ざってきます。単発のプロンプトを工夫しても、次の画面ではまた同じ癖が顔を出す——というのがフロントエンドリードの多くが直面している状況です。

こうした AI 生成 UI の画一化（俗に「AI slop」と呼ばれる問題）に、デザイン語彙・決定的な検知ルール・エージェントへのフックの三本柱で立ち向かおうとしているのが、本記事で扱う OSS「Impeccable」です。Anthropic が公開している frontend-design skill を起点に派生し、Claude Code だけでなく Cursor、GitHub Copilot、Gemini CLI、Codex CLI など複数の AI コーディングツールで共通のデザイン言語を共有できるように拡張されています。

本記事では、Impeccable が具体的にどんな仕組みで AI slop を抑制するのか、23 のコマンドと 46 の決定的検知ルールがどう機能するのか、そして Anthropic frontend-design skill や shadcn/ui とはどのように住み分けるのか——「自チームで採用すべきか」を判断できるレベルまで整理して解説します。まだリポジトリが誕生して間もないため、成熟度やメンテナンス状況への言及も含めます。

Impeccableとは何か｜AI生成UIの画一化を防ぐデザイン言語OSS

Impeccable は、pbakaus/impeccable で公開されているオープンソースプロジェクトです。リポジトリの自己紹介は "The design language that makes your AI harness better at design."（AI ハーネスをデザインで賢くするためのデザイン言語）とシンプルにまとまっており、公式サイトは impeccable.style から辿れます。

具体的には、AI コーディングエージェント（Claude Code、Cursor、GitHub Copilot 等）に対して、フロントエンド生成時に一貫したデザイン基準を守らせるためのスキル・コマンド・検知ルール・フックを 1 パッケージで束ねた OSS です。位置づけとしては、Anthropic の frontend-design skill を起点に、複数の AI コーディングツールで共有できる デザイン語彙 + 決定的な検知ルール + プロバイダ横断のフック の 3 本柱に拡張したものと捉えると分かりやすいでしょう。

基本情報のスナップショット

初見のエンジニアが最初に確認したい客観情報を整理します。数値・属性はすべてリポジトリ API から取得した現時点の値です。

archived や fork のフラグはいずれも false のため、本記事執筆時点で pbakaus/impeccable は「アーカイブ済みでもフォーク版でもない、アクティブに開発が続く本家リポジトリ」であることが確認できます。ライセンスは Apache-2.0 で、企業内利用時の法務チェックも比較的通しやすい部類です。

一方で、リポジトリ作成は 2025-11 と新しく、記事公開時点で約 8 ヶ月しか経過していません。スター数は 47,756 と急伸していますが、後述する「採用判断の指針」でも触れる通り、成熟度やメンテナンス継続性の観点では新興 OSS として扱う必要があります。

なぜAI生成UIは似た見た目になるのか｜Impeccableが対処するAI slop

Impeccable の README では、AI 生成 UI が陥りがちなパターン——通称 AI slop——を、ツールが対処する対象として明確に定義しています。「そもそも何を防ごうとしているのか」を理解しておくと、後述する検知ルールや polish / audit などのコマンドの立ち位置が腹落ちしやすくなります。

具体例：purple グラデ・カード入れ子・Inter 独占の典型パターン

Impeccable の README が挙げている典型的な AI slop は、次のようなものです。

• 過剰使用されるフォント（Inter、Arial、システムデフォルト）
• 紫 → 青のグラデーションだけで作られた背景・ボタン
• カードの中にカードを入れ子にする構造
• 有彩色の背景に灰色のテキストを重ねてしまう誤配色
• 見出しの上に必ず配置されるラウンド角のアイコンタイル
• Bounce / elastic イージング（時代遅れの印象を与えるモーション）

いずれも「AI が悪意を持って選んだ」ものではなく、学習データの分布上、モデルが安全牌として選びやすいデフォルトが積み上がった結果です。React + Tailwind で軽くプロトタイプを作らせるだけで、同じ組み合わせが繰り返し出力される背景にはこの構造があります。

根本原因：同一テンプレートで学習したAIモデル固有のバイアス

Impeccable の README はこの現象の根本原因を、"Every model trained on the same SaaS templates. Skip the guidance and you get the same handful of tells on every project." と表現しています（出典: pbakaus/impeccable の README）。日本語に置き換えると「あらゆるモデルが同じ SaaS テンプレートで学習してしまった。ガイダンスを与えなければ、どのプロジェクトでも同じ手癖がわずかな種類しか出てこない」というニュアンスです。

裏を返せば、Impeccable が提供するのは「もう一つのオシャレなデザインシステム」ではなく、AI エージェントが手癖で書き飛ばそうとするアウトプットに ガードレールを差し込む ためのツール群だと理解できます。単体で使う既製コンポーネント集ではなく、AI コーディングエージェントの背後に常駐して差別化を担保するレイヤー——これが Impeccable の設計思想です。

Impeccableの中核構造｜1スキル・23コマンド・46検知ルール

Impeccable は README 上、機能を「1 skill、23 commands、46 deterministic detector rules、live browser iteration」という 4 つの柱で整理しています。以下、順に見ていきます。

入口となる init：PRODUCT.md と DESIGN.md で設計コンテキストを共有

Impeccable のスキルは /impeccable <command> <target> という統一されたインターフェースで呼び出します。導入直後の入口となるのが init コマンドで、プロジェクトに対して PRODUCT.md（対象プロダクトの目的・ペルソナ）と DESIGN.md（デザイン方針・トーン）の 2 つを生成し、以降のコマンドが常に参照する設計コンテキストを整えます。

さらに init の際に、対象サーフェスが brand（マーケサイト・LP・ポートフォリオ等の第一印象を作る面） か product（アプリ UI・ダッシュボード・社内ツール等の日常使いする面） かを選択します。これは Impeccable の "dual registers" と呼ばれる仕組みで、以降の全コマンドは選ばれたレジスタに応じて挙動が変化します。同じ polish コマンドを叩いても、brand ならより大胆に、product ならより落ち着いた方向にアウトプットが寄る、という設計です。

23 コマンドマトリクス

/impeccable の下には現在 23 のコマンドが用意されています。ここでは README の分類に沿って主要なものを整理します（一覧は pbakaus/impeccable の README を参照）。

多いように見えますが、実運用ではよく使うコマンドは限られます。README では /impeccable pin <command> によって単独ショートカット（例: /audit）を作れることも示されており、チームで頻用するコマンドだけをエディタのコマンドパレットに常駐させる運用が想定されています。

46 の決定的検知ルールと CI 連携

Impeccable の特徴で最も差別化されているのが、LLM に判断を委ねない決定的な detector です。46 のルールがコード・URL に対して機械的に走り、AI slop 該当箇所を検出します。CLI としては次のようなインタフェースが提供されています（出典: pbakaus/impeccable の README）。

npx impeccable detect <path|url>
npx impeccable detect <path|url> --json

出力形式は通常出力（ファイル単位でグルーピング）と JSON（--json）から選べます。終了コードは以下の設計で、CI と接続する前提が最初から意識されています。

• 0: 検出なし
• 1: 実行失敗
• 2: 検出あり

このため、GitHub Actions などで exit 2 を warning ではなく failure として扱うだけで、AI 生成 UI の品質を PR ゲートに組み込むことができます。詳細なルールカテゴリと構成は公式の Detector ドキュメント にまとまっており、AI slop 系（サイドタブ枠線・紫グラデーション・bounce easing・ダークグロー等）と一般デザイン品質系（行長・詰まったパディング・小さいタップ領域・見出しレベルスキップ等）の 2 系統でカテゴライズされています。

プロジェクト単位の抑制は .impeccable/config.json の detector.ignoreRules / ignoreFiles / ignoreValues で制御し、ファイル単位の免除にはインラインコメント（例: <!-- impeccable-disable overused-font: exported brand doc -->）を使う設計になっています（出典: Detector ドキュメント）。ルール抑制の理由をコード内に残す形になるため、後から見返しても「なぜここは検知を無視したのか」を追跡できる点は運用面での安心材料です。

Live browser iteration モード

live コマンドは、開発サーバー上で動く実要素を対象にブラウザで直接編集し、3 つのバリアントを生成、フレームワーク HMR 経由でソースコードに反映する Beta 機能です。ソースコード側には diff の形で戻ってくるため、コードレビュー可能な形でビジュアル反復が回せる想定になっています。README では Beta と明記されているため、本番運用には慎重に扱う機能として捉えるのが妥当です。

対応するAIコーディングツールと導入手段

Impeccable のプロバイダ横断性は、Anthropic 公式の frontend-design skill との差別化ポイントの一つです。README の "Supported Tools" では、次の 12 種類がサポート対象として明記されています。

サポート対象 12 ツールと brand / product レジスタの切り替え

• Cursor
• Claude Code
• GitHub Copilot
• Gemini CLI
• Codex CLI
• Grok Build
• OpenCode
• Pi
• Kiro
• Trae
• Rovo Dev
• Qoder

これらのツールを日常的に使い分けているチームであれば、Impeccable を入れることで エディタが変わっても同じデザイン語彙・同じ検知基準 を横串で当てられます。フロントエンドリードが Cursor でプロトタイプを組み、バックエンドチームが GitHub Copilot でクライアント側の型を触り、テック PM が Claude Code でモックを叩く——という体制でも、AI 生成コードの見た目のブレを最小化できる想定です。

5 通りの導入手段と推奨パス

README では 5 通りの導入手段が提示されています。推奨は最初の npx 経由です。

1. npx impeccable install（推奨。対応プロバイダを自動判定してインストール）
2. Git submodule + npx impeccable link
3. Plugin install（Claude Code なら /plugin marketplace add pbakaus/impeccable、Grok Build なら grok plugin install pbakaus/impeccable --trust）
4. impeccable.style から ZIP をダウンロード
5. dist/<provider>/* を手動コピー

パッケージは npm に公開されており（impeccable - npm）、Node.js が動く環境なら npx impeccable install の一発でセットアップが始まります。CI と組み合わせて動かす場合は、リポジトリ内に .impeccable/config.json を持つ形になるため、Git submodule 派の運用でもクリーンにバージョン管理できます。

Design hook が編集前後どちらでフィードバックするか（プロバイダ別）

Impeccable の中でも実運用への影響が大きいのが、Design hook の挙動差です。対象は Claude Code / GitHub Copilot / Cursor / Codex の 4 プロバイダで、インストール時に各プロバイダ固有の設定ファイル（.claude/settings.local.json、.github/hooks/impeccable.json、.cursor/hooks.json、.codex/hooks.json など）に自動で登録されます。詳細な挙動は Hooks ドキュメント に整理されていますが、要点は以下の通りです。

Cursor だけが編集前ブロック型で、その他 3 プロバイダは編集後リマインダー型という違いは、期待値管理の観点で重要です。Claude Code や Copilot を主軸にしているチームは「壊れた UI が一度は書かれるが、次のターンで直させる」運用になり、Cursor 中心のチームは「そもそも書かせない」運用に寄ります。どちらが自チームの開発リズムに合うかで、主軸に置くツールの選択が変わり得ます。対象ファイルは .tsx、.jsx、.vue、.css、.scss などです。

類似OSSとの違い｜Anthropic frontend-design・shadcn/uiとの住み分け

Impeccable を採用すべきかを判断するには、隣接する選択肢との違いを整理しておく必要があります。ここでは Impeccable の起点である Anthropic frontend-design skill、AI 生成コードのデフォルトになっている shadcn/ui、そして同じ「AI slop 対策」領域に位置する Hallmark・Taste Skill という 4 種類との棲み分けを整理します。

Anthropic frontend-design skill との差分

Impeccable の README では、"Anthropic's frontend-design was the first widely-used design skill for Claude. Impeccable started from there."（Anthropic の frontend-design は Claude 向けに広く使われた最初のデザインスキルで、Impeccable はそこから出発した）と、その起源を明言しています（出典: pbakaus/impeccable の README）。Anthropic 側の実体は anthropics/skills リポジトリの frontend-design skill にあります。

両者の主な違いは以下です。

まとめると、Anthropic 版は「Claude Code だけで軽量に導入したい」場面での最短パスであり、Impeccable は「複数の AI コーディングツールで共有できる、より厚めのガードレールが欲しい」場面で優位に立ちます。「Anthropic 版を試して手応えが得られたが、チームで使うエディタが揃わない・CI に組み込みたい」段階に到達したチームが、乗り換え候補として検討する という順番が自然です。

shadcn/ui との住み分け

もう一つよく比較の俎上に載るのが shadcn/ui です。Vercel v0 が既定で採用していることから、Claude や Cursor、Lovable などの出力も事実上「shadcn 形状」になりがちです。ただし、これは Impeccable と競合する存在ではなく、アプローチが逆方向 の関係と捉えるのが正確です。

つまり、shadcn/ui は「AI が組み立てる部品箱」であり、Impeccable は「AI がその部品箱をどう使うか」を制約するレイヤーです。両者は競合ではなく、shadcn/ui のコンポーネントをベースに、Impeccable の検知ルールで AI 生成の外観のブレを抑える——という組み合わせが素直な構成になります。「shadcn/ui を使うから Impeccable は不要」ではなく、「shadcn/ui を使っているから Impeccable が刺さる」という捉え方が意思決定を早めます。

AI slop対策の他OSS（Hallmark・Taste Skill）との違い

「AI 生成 UI の画一化を抑える」という同じ課題領域には、Impeccable と方向性の近い OSS がいくつか存在します。当サイトでは代表的な 2 つを別記事として深掘りしており、Impeccable とどう棲み分けるかを短く整理します。

• AI 生成らしさを消すデザインスキル「Hallmark」の仕組みと 20 テーマ（Nutlope/hallmark）
• AI生成UIの量産化を防ぐ「Taste Skill」が選ばれる理由（Leonxlnx/taste-skill）

3 者の主な違いを一枚に整理すると次のようになります。

意思決定の目安を挙げると、次のような分岐で捉えると迷いにくくなります。

• 複数の AI コーディングエディタを横断してデザイン基準を維持したい・CI で機械的に検知させたい → Impeccable（12 プロバイダ対応と impeccable detect の存在が決定打）
• 主に Claude Code / Cursor / Codex 内での運用で、テーマカタログから離散選択して AI slop を機械的に落としたい → Hallmark（20 テーマ + 58 の slop-test ゲート）
• ブリーフ側で「もう少し密度を上げる」「もう少し控えめに」といった連続的なトーン調整をしたい → Taste Skill（数値ダイヤル型）

3 者はいずれも「AI slop 対策」という同じ目的を掲げますが、制御哲学は明確に異なります。Impeccable は「決定的なルール検知＋マルチプロバイダ」を最重要視した基盤寄りの位置づけであり、テーマカタログ型（Hallmark）や数値ダイヤル型（Taste Skill）とは競合というより並列の選択肢と捉えるのが実態に近い理解です。用途によっては Impeccable の detector を CI で回しつつ、生成フェーズは Hallmark や Taste Skill を併用するといった組み合わせも成り立ちます。

採用判断の指針｜Impeccableを試すべきプロジェクト・そうでないプロジェクト

ここまでの整理を踏まえて、初見のエンジニアが「自チームで採用すべきか」を判断するための指針をまとめます。

Impeccable の採用が向いているケース

• 複数の AI コーディングツールを併用しているチーム（Cursor + Claude Code + GitHub Copilot など）。プロバイダ横断のフックとレジスタで、エディタが変わっても同じデザイン基準を維持できるため、費用対効果が最も高い層です
• AI slop の是正が実際に課題になっているプロダクト（B2B SaaS の管理画面、社内ダッシュボード等、量産系 UI）。46 の決定的ルールが体系的にブレを抑えます
• CI で決定的な検知を回したい組織。impeccable detect --json の終了コード 2 を PR ゲートにするだけで、目視レビュー依存を減らせます
• 既に Anthropic の frontend-design skill を使っているが、Claude Code 以外にも展開したい チーム。同じ設計思想の延長線上でスコープを広げられます

慎重に判断すべきケース

• リポジトリ作成が 2025-11 と新しく、記事執筆時点で約 8 ヶ月しか経っていない ため、機能追加の変化が速く、破壊的な仕様変更のリスクをゼロにはできません。バージョン固定・変更履歴の追跡運用ができるチーム向けです
• 既に独自のデザインシステム・デザイントークンが機能しているチーム。Impeccable のレジスタや検知ルールと衝突する部分の学習コストと、.impeccable/config.json での抑制設定の運用コストを見積もる必要があります
• 単一のエディタでしか AI コーディングをしていないチーム で、その対象が Claude Code のみの場合。Anthropic の frontend-design skill だけで十分な可能性があり、Impeccable の追加機能（マルチプロバイダ・detector・live）を活かしきれないなら、より軽量な選択肢から始める判断もあり得ます

判断のショートカット: 「複数の AI コーディングツールを混在利用しているか」「AI slop を CI で機械的に止めたいか」の 2 つに Yes が付くなら、Impeccable の導入検討は費用対効果に見合います。どちらも No なら、まずは Anthropic 版 frontend-design skill から始め、Impeccable は後日の乗り換え候補として温めておくのが妥当な進め方です。

まとめ

本記事のキーテイクアウェイを整理します。

• Impeccable は「もう一つのデザインシステム」ではなくガードレール型 OSS です。デザイン語彙 + 46 の決定的検知ルール + プロバイダ横断のフックの 3 本柱で、AI 生成 UI の画一化（AI slop）を抑制します
• Anthropic frontend-design skill との差別化は「マルチプロバイダ対応」「決定的な検知」「dual registers」 の 3 点にあります。Claude Code 単体で完結するなら Anthropic 版が最短パス、複数エディタを混在利用しているなら Impeccable がフィットします
• shadcn/ui とは対象領域が逆で併用可能 です。shadcn/ui がコンポーネント実体を提供し、Impeccable がそれを AI にどう使わせるかを制約する構成が自然です
• 同じ AI slop 対策領域の Hallmark・Taste Skill とは制御哲学が異なる並列の選択肢 です。決定的なルール検知とマルチプロバイダを最重視するなら Impeccable、テーマカタログ型なら Hallmark、数値ダイヤル型なら Taste Skill と切り分けられます
• 成熟度は新興 OSS レベル です。リポジトリ作成が 2025-11 と新しく、機能追加・変更が速い可能性があるため、バージョン固定と変更履歴の追跡運用を前提に採用するのが安全です

次の一手として、以下 3 ステップの検討順序を提案します。

1. まずは npx impeccable install --help などで対応プロバイダとオプションを確認し、自チームの利用ツールがサポート範囲に収まるか照合する
2. パイロットプロジェクトで init を実行し、対象サーフェスに応じて brand / product どちらのレジスタで進めるかを判断する
3. CI に npx impeccable detect --json を組み込むかを検討する。終了コード 2 を PR ブロックに使うだけで、AI slop の再発防止フローが一つ完成します

Impeccable は生まれて間もない OSS ですが、AI コーディング時代のフロントエンド品質担保に必要な要素——語彙・検知・フック——を単一の座組みで束ねている点で、ウォッチしておく価値があるプロジェクトです。まずはドキュメントを一巡し、自チームのユースケースに合うかを見極めるところから始めてみてください。