AI に任せた画面がいつも似て見えるのはなぜか
モデルはおおむね同じ素材を見て学んでいる。公開ウェブに溢れる SaaS のランディングページとダッシュボードのテンプレートだ。だから特に指示なく画面を作らせると、別のモデル、別のプロジェクトでも同じ選択が繰り返される。本文は Inter、ヒーローの背景は紫から青へのグラデーション、見出しにもまたグラデーション、カードの中にまたカード、カードの左端に太い色帯、見出しの上に小さな大文字ラベル。
これをプロンプトで毎回直そうとすると、同じ言葉を延々と繰り返すことになる。「もっと洗練させて」「AI っぽくないように」といった指示には基準がなく、結果が会話ごとに揺れる。Impeccable が取ったのは逆の道だ。何が問題かに名前を付けて規則にし、その規則をエージェントが読む場所にファイルとして置く。
出発点は Anthropic が公開していた frontend-design スキルである。Impeccable はそこから始めてコマンドの語彙を 23 個に広げ、LLM なしで動く検出ルール 60 個と、編集の瞬間に介入するフックを加えた。リポジトリの説明にその系譜がそのまま書かれている。
どうインストールするか
いちばん手軽なのは CLI インストーラだ。プロジェクトのルートで一行走らせる。npx は Node.js に付属するコマンドで、パッケージを別途入れずにその場で実行してくれる。Node.js がなければ nodejs.org から LTS 版を先に入れる。
実行するとこの端末に入っている AI コーディングツールを自ら見つけて一覧にする。Claude Code、Codex CLI、Cursor、Gemini CLI などだ。検出された組をそのまま使うか自分で選ぶかを尋ね、続いてこのプロジェクトだけか端末全体かを尋ねる。答え終えるとスキルを取得して当該ツールの設定フォルダに入れ、対応するツールにはフックまで併せて入れたうえで、次に何をすればよいかを教えてくれる。
対話なしで走らせたいときは --providers=claude,codex,cursor や --scope=project といったフラグで答えを先に渡す。スクリプトやチームのオンボーディング文書に向く書き方だ。既に入れたものを最新に上げるときは npx impeccable update を使う。
導入経路はこれだけではない。Claude Code では /plugin marketplace add pbakaus/impeccable でプラグインマーケットプレイスを登録できるし、チームがバージョンをリポジトリに固定したいなら git サブモジュールとして入れ、npx impeccable link で各ツールのフォルダにつなぐ。サイトからツール別の ZIP を落とす方法、リポジトリの dist フォルダを直接コピーする方法も文書にある。最初は一つ目だけ知っていれば足りる。
npx impeccable install
# 対話なしで
npx impeccable install --providers=claude,cursor --scope=project
# あとで最新に
npx impeccable update/impeccable init は何を作るか
インストールが済んだら、AI ツールの中で /impeccable init を一度実行する。これはファイルを直すコマンドではなく、文脈を決める対話だ。まず作る画面がブランド寄りかプロダクト寄りかを尋ねる。ブランドはマーケティングページ、ランディング、ポートフォリオのように印象を残す画面で、プロダクトはアプリの UI、ダッシュボード、ツールのように毎日使う画面だ。同じ規則を両方に当てると片方は平板になり、もう片方は散らかるので、この分岐を先に決める。
対話が終わると PRODUCT.md と DESIGN.md が作られる。PRODUCT.md には誰が使う画面か、どんな印象を残したいか、避けたい参照は何かが入り、DESIGN.md には色・書体・コンポーネントといった視覚規則が入る。以後実行するすべてのコマンドがこの二つを先に読むので、毎回ブランドを説明し直す必要がなくなる。
すでに作ってある画面があるなら、/impeccable document で既存コードから DESIGN.md を逆に取り出すこともできる。白紙から始めるより、すでに使っている色と余白を文書として固めるほうが早いことが多い。
23 個のコマンドをいつ何に使うか
コマンドはすべて /impeccable のあとに名前を付けて呼ぶ。対象まで書けば範囲が狭まる。たとえば /impeccable audit blog はブログ画面だけ、/impeccable polish settings は設定画面だけを見る。名前なしで /impeccable とだけ打てば一覧が出るし、説明をそのまま添えてもよい。
よく使うものを絞ると下の表くらいになる。毎日使うコマンドができたら /impeccable pin audit のように固定して /audit の近道にできる。
使ううちに順番ができる。作る前は shape で構成と流れを決め、作ったあとは critique で人が見る観点を、audit で機械が見る項目を点検し、polish で仕上げる。結果が平板なら bolder、やり過ぎなら quieter、要素が多ければ distill で整える。
| コマンド | いつ使うか |
|---|---|
| shape | コードを書く前に画面の構成と流れを決める |
| craft | 構成から実装まで一気に進める |
| critique | 階層・可読性・印象を人の視点でレビューする |
| audit | アクセシビリティ・性能・レスポンシブなど技術項目を点検する |
| polish | 出荷前の仕上げとデザインシステムとの整合を見る |
| bolder / quieter | 結果が平板なとき、逆に過剰なときに強度を調える |
| distill | 要素が多く焦点がぼけたときに削ぎ落とす |
| harden | エラー状態・長い文言・多言語など壊れやすい場合を埋める |
| clarify | ボタン文言やエラーメッセージなど読んで迷う文を直す |
| adapt | モバイルなど別の画面サイズに合わせる |
エージェントなしで検査だけ回す
Impeccable には AI なしで動く検査器が別に入っている。npx impeccable detect にファイルかフォルダ、あるいは URL を渡すと、規則に触れた箇所を名前とともに知らせてくれる。LLM を呼ばないので API キーは要らず、結果は毎回同じだ。
検査のしかたは対象によって分かれる。HTML はリンクされた CSS まで含めて静的解析し、JSX や CSS といったそれ以外のファイルはパターンマッチ、URL を渡すと実際のブラウザで開いてレンダリングされた画面を見る。だからソースの走査が綺麗でも、URL の走査で引っかかる項目が別にありうる。
確かめるために、AI がよく出す形をそのまま真似た HTML を一枚作って走らせた。結果は 17 件、終了コードは 2 だった。指摘された箇所だけ直し、レイアウト構造はそのままにして再度走らせると 0 件、終了コード 0 になった。終了コードがゼロでないという点が重要で、これだけで CI のビルドを止められる。
特定の項目を切りたいときは、ファイルの中に impeccable-disable コメントを書いてその場だけ免除するか、npx impeccable ignores add-value でリポジトリの設定に例外を記録する。どちらも理由を書くことになるので、判断が記録として残る。
npx impeccable detect src/ # フォルダを検査
npx impeccable detect index.html # ファイルを検査
npx impeccable detect https://example.com # URL を検査（実ブラウザ）
npx impeccable detect --json . # CI 用の出力
# 指摘があれば終了コード 2、なければ 0インストール後に一度だけ片づけること
コマンドを使い始めるとプロジェクトに .impeccable フォルダができ、その中に作業ファイルが溜まる。レビューのスクリーンショット、実行状態、キャッシュ、人ごとに違う個人設定などで、大半はリポジトリに入れる必要がない。README にそのまま貼れる .gitignore のブロックが用意してあるので、最初に一度入れておけばよい。
ただし全部を無視してはいけない。共有すべきファイルがいくつかある。プロジェクト共通の設定、デザイン仕様、レビューレポートがそれで、これらはリポジトリに残してチームが同じ基準を見るようにする。無視規則を入れる前にスクリーンショットを既にコミットしていた場合、規則を足すだけでは追跡は切れないので git rm --cached で追跡だけ外す。
対応するツールではフックも一緒に入る。UI ファイルを直した瞬間に検出器が走り、結果をエージェント側へ返す仕組みだ。Cursor は誤った書き込みが反映される前に止め、それ以外は修正のあとに知らせる方式である。インストールの過程でフックを入れるか尋ねられるので、望まないならそこで外せばよい。