Impeccable：モデル不要の62ルールでAIスロップを見抜く

モデルが作ったページには、独特の見た目がある。嫌というほど見てきたはずだ。どこもかしこも Inter、ヒーローには紫から青のグラデーション、カードの中にカード、色付きの背景に灰色の文字、そして見出しの上に浮かぶ角丸スクエアのアイコンタイル。Paul Bakaus はその見た目に名前をつけ、さらにそのための linter を書いた。

Impeccable はコーディングエージェント向けのデザインスキルだ。今週だけで約 6,700 個のスターを獲得し、累計はおよそ 91,500 に達する。うたい文句は「あなたのコーディングエージェントのためのデザイン語彙」だが、この言葉は本当に珍しい部分を過小評価している。62 項目のチェックが、モデルを一切介さない決定的なルールとして動くという点だ。

具体的に何なのか

スキルがひとつ、コマンドが 24 個、そして検出器がひとつ。もともとは Anthropic の frontend-design スキルの拡張として始まり、やがて独自の主張を持つものに育った。

インストールはプロジェクトのルートで 1 行だけ:

npx impeccable install
/impeccable init

飛ばされがちなのが 2 つ目のステップだ。init は製品について、対象ユーザー、目的、制約、トーンを聞き取り、その答えを PRODUCT.md に書き出す。別の document コマンドは、既存のコードから DESIGN.md を生成する。この分割が効いている。製品の事実とビジュアルシステムは別々の成果物であり、更新されるタイミングも違う。ひとつのファイルにまとめることこそ、デザインドキュメントが陳腐化する近道なのだ。

続いて 24 個のコマンド。これはワークフローというより語彙に近い:

craft は「形を決めてから作る」工程を、視覚的な反復込みで通しで回す。critique は階層、明快さ、情緒的なトーンを評する。audit はアクセシビリティ、パフォーマンス、レスポンシブを点検する。polish はリリース前にデザインシステムへ寄せる。bolder と quieter は方向性の調整で、強めるか抑えるか。harden はエラー状態、i18n、テキストのあふれ、エッジケースを扱う。typeset と layout は、エージェント製 UI が最もよく間違える 2 点を直す。live はブラウザを開き、指定した要素のバリエーションをその場で生成する。

どれでも単体のショートカットとして固定できる:

/impeccable pin audit

これで /audit がトップレベルのコマンドとして生まれる。小さな機能だが、この語彙が実際に使われるかどうかを分ける差は大きい。

面白いのは検出器のほうだ

Impeccable をプロンプト集の山と分かつのはここにある。62 のルールはモデルも API キーもエージェントも必要としない。

npx impeccable detect src/
npx impeccable detect index.html
npx impeccable detect --json .
npx impeccable detect --list-rules

つまり CI で動く。バウンスのイージングを戻したり、紫のグラデーションを紛れ込ませたり、14px の灰色文字をティールの上に置いたりしたプルリクエストは、誰もトークン代を払わずにチェックで落とせる。--github フラグがあり、GitHub Actions のアノテーションを出力する。ほとんどのチームにとって意味のある統合の詳細は、これだけだ。

ルール群ははっきり偏向していて、人によっては腹が立つだろう。ドキュメントもそれを隠していない。アンチパターン集は Arial、Inter、システム既定のフォントを禁じ、純黒と純灰を禁じ(必ず色味を持たせる)、何にでもカードを被せることとカードの中のカードを禁じ、バウンスとエラスティックのイージングを時代遅れとして禁じ、色付き背景の上の灰色文字を禁じる。

その一部は職人論として筋が通っている。彩度の高い背景にコントラスト不足の本文を置くのはアクセシビリティの欠陥であり、同時に安っぽくも見える。Inter 禁止のほうは流行の判断で、流行のルールはすぐ古びる。Inter を禁じた同じ文書が、3 年後には時代物に見えているはずだ。だが意見のない linter はただのフォーマッタであり、このツールの存在意義は立場を持っていることにある。

決定的であるということは、裏を返せば抜け道もあるということだ。紫のグラデーションをどうしても出したいチームは、インラインの除外を一行足せばいい:

<!-- impeccable-disable overused-font: exported brand doc -->

あるいは npx impeccable ignores add-value overused-font Inter --reason "Brand font" で無視設定を全体管理する。--reason フラグは静かな社会的工作をしている。例外を diff の中で見えるようにするのだ。

エージェントにどう噛ませるか

どのインストール経路を選ぶかで、侵襲性が変わる。Claude Code、Copilot、Codex、Cursor、Grok Build では、install が各プロバイダー固有のフックマニフェストを書き込む。Claude Code なら .claude/settings.local.json で、これは gitignore されマシンローカルだ。Copilot なら .github/hooks/impeccable.json で、コミットされクラウドのエージェントとも共有される。Cursor なら .cursor/hooks.json で、ファイル書き込み時の postToolUse に発火する。

結果として検出器はエージェント自身の編集に対して走り、検出結果をそのループに返す。「思い出したときに audit コマンドを叩く」とは仕組みとして明確に違う。レビューの時点ではなく、生成の瞬間にスロップを捕まえる。

代償はいつものとおりだ。リポジトリの設定に書き込むフックはコードレビューにも現れるし、Codex のユーザーはインストール後に /hooks でプロジェクトフックを明示的に承認する必要がある。ツール設定をコミットすることに強い意見を持つチームのために、サブモジュール経路が用意されている。git submodule add と npx impeccable link --source=.impeccable --providers=claude,cursor を組み合わせれば、ツールはそれが統治するコードと一緒にバージョン管理される。

直せないもの

限界を 3 つ挙げておく。

そのページが良いかどうかは分からない。62 のルールが捕まえるのは表層の兆候だ。すべてのチェックを通り抜けながら、視点をひとつも持たないページはあり得る。AI スロップ問題のより深い層であり、どの linter も解けていない層だ。

live モードはローカルのチェックアウトでしか動かない。本番サイトには HTTPS であっても注入しない。妥当な判断だが、視覚的な反復ループは開発時の道具であって、レビューの道具ではないということでもある。

そして語彙は、エージェントが読んで初めて効く。Impeccable 自身の説明はこの点で正直だ。すべてのモデルが同じデザインを出すのは、すべてのモデルが同じ SaaS テンプレートで訓練されたからだ。スキルファイルは訓練分布への軽い突つきにすぎず、突つきは分布に負けることのほうが、誰が望むよりも多い。

チェックリストを書けば済む話では?

もっともな疑問だ。markdown のスタイルガイドはコストゼロで、やることはほぼ同じに見える。

違うのは強制力だ。プロンプトの中のチェックリストは提案にすぎない。モデルは読み、同意し、それから紫のグラデーションを出す。そのグラデーションが訓練データに 4 万回入っていたからだ。決定的なルールはビルドを落とす。これは圧力の種類が違うし、締め切りを跨いで生き残るのはその種類だけだ。

2 つ目の違いは粒度だ。チェックリストは「良いタイポグラフィを使え」と言う。Impeccable の typeset コマンドは階層、スケール、ペアリングを具体的に扱い、検出器は個々の失敗に対して個別のルールを持つ。つまりフィードバックは、センスに向かって手を振るのではなく、CSS の 1 行を指せる。ツールがドキュメントに勝つという論の全部がここにあり、20 年前に linter でそれが成立したのと同じ理由で、ここでも成立している。

3 つ目は、語彙が共有できることだ。bolder、quieter、distill、harden。デザイナーもエージェントも、これらを行動に移せる。「もっとポップに」は移せない。

なぜ今バズっているのか

量の問題が到来したからだ。1 年前、エージェントがランディングページを作るのはたまのことだった。今はチームが昼前に 40 案を生成できる。ボトルネックは「作れるか」から「どれが良いかを、間に合う速さで見分けられるか」へ移った。

安上がりな失敗に対する決定的なチェッカーは、この問題の中で唯一スケールする部分だ。センスはスケールしない。フォントとイージングに関する 62 の正規表現的なルールはスケールする。そしてそれを、モデル呼び出しなしで CI で動くものとして出荷したことが、このリポジトリで最も地味で最も有用な判断だった。