impeccableでAIっぽいUIはどこまで消えるのか

デザイナーさんから「なんかAIっぽいね」と赤字が返ってきて、どこを直せばいいのか迷ったことはない？ impeccableの検出ルール61個を使うと、AIっぽいUIの癖の一部は機械で拾える。ただ日本語の画面だと、ルールの中身から当たりそうだと読めるものと、試すまで分からないものに分かれるんだよね。

AIっぽいUIと言われたら、先に自分のメモを作る

「AIっぽい」という赤字は、たいていそこで止まっている。どこがどうなのかを言葉にするのは、実装側の仕事になりがち。

わたしは検出ツールを入れる前に、直近の3画面を並べて、気になるところを「色と形」「文字組み」「文言」の3列に分けて書き出すようにしている。色と形なら「見出しが紫から水色のグラデーション」、文字組みなら「本文の行間が詰まっている」、文言なら「シームレスな体験、みたいな決まり文句」といった具合。

あなたが最近言われた「っぽさ」は、この3列のどこに入りそう？

このメモが、あとで検出結果を読むときの答え合わせの紙になる。ツールの指摘を先に見ると、指摘されたものだけが問題に見えてしまうから、順番は逆にしないほうがいい。

impeccableの検出ルール61個、AIっぽさを見るのは32個

GitHub - pbakaus/impeccable: The design language that makes your AI harness better at design.

The design language that makes your AI harness better at design. - pbakaus/impeccable

github.com

impeccableは、Paul BakausさんがつくったAIコーディングツール向けのデザインスキル。READMEには、Anthropicのfrontend-designスキルが出発点だと書かれている。Claude Code、Cursor、GitHub Copilotなど17のツールに入れられて、/impeccable audit や /impeccable polish のように24個のコマンドを呼び分ける。

ライセンスはApache-2.0で、GitHubのスターは10月4日時点で7万5,000超。スキルは10月2日に4.5.0が出たばかりで、古い解説とはコマンド数もルール数も違うことがある。手順は公式サイトかREADMEで確かめるのが確実。

コマンドの名前より先に、何を検出してくれるのかが気になるんだよね。検出ルールは61個で、どれもLLMを使わず決まった条件で判定する（これとは別に、AIに批評させるときだけ使うチェックもある）。ルールの定義ファイルで分類を数えると、AIっぽさを見るものが32個、一般的な品質を見るものが29個だった。

AIっぽさの側には、カードの片側だけに太い色付きの線を引く side-tab、文字にグラデーションをかける gradient-text、カードの中にカードを重ねる nested-cards、紫系のグラデーションや暗い背景にシアンを合わせる ai-color-palette、クリーム色やベージュの背景の cream-palette が並ぶ。InterやRobotoなど6つの書体を挙げた overused-font もここ。

おもしろいのは、行間の詰まり（tight-leading）、1行の長さ（line-length）、小さすぎる文字（tiny-text）、コントラスト不足（low-contrast）が品質の29個のほうに入っていること。デザイナーさんの「読みにくい」という赤字は、AIっぽさより品質側に近いのかも。メモの「文字組み」の列は、主にこっちと突き合わせることになる。

インストールの前に、impeccable detectだけ試す

検出だけなら、スキルを入れなくてもNode.jsがあればターミナルから動く。APIキーもいらない。

npx impeccable detect index.html           # HTMLファイルを1つ
npx impeccable detect src/                 # ディレクトリごと
npx impeccable detect https://example.com  # 公開中のページ
npx impeccable detect --json .             # CIに渡すならJSONで

URLを渡すときは、手元にChrome、Chromium、Edgeのどれかが要る。終了コードは、指摘なしが0、指摘ありが2、スキャン失敗が1。CIに組み込むなら、2で止めるか警告だけにするかを先にチームで決めておくと揉めにくい。

出てきたルール名は、最初に作ったメモの列に書き写していく。メモにあるのに出てこなかったものが、このツールでは拾えない「っぽさ」の候補になる。あなたのメモで最後まで残りそうなのは、どの列だろう？

この残り方が、日本語の画面だと少し変わりそうなんだよね。

日本語UIで、どの検出ルールが当たるのか？

ルールの説明と既定値を読むと、言語に関係なさそうなものと、英文を前提にしたように見えるものが混ざっている。分けるとこうなる。

右の列はどれもわたしの読みで、確かめた結果じゃない。ルールの定義ファイルにも、日本語への言及は見当たらなかった。

特に気になるのが1行の長さ。CSSの ch は数字の0の幅が基準なので、0が全角の半分くらいの幅のフォントなら、75chは全角で40字弱になる。英文の80文字と日本語の40字前後では、画面の見え方がだいぶ違う。あなたの案件の本文は、1行に何文字くらいで組んでいる？ ルールの説明には描画された行で測るとあるから、HTMLファイルとURLの両方で反応を見比べておくと安心。

逆に、クライアント指定の書体がInterで、overused-font に毎回引っかかる案件もあると思う。その場合は除外を登録できる。

npx impeccable ignores add-value overused-font Inter --reason "Brand font"

試すなら、使い捨てのHTMLを1枚作るのが手っ取り早い。紫から水色のグラデーションの見出し、カードの入れ子、左だけ太い枠線、行間1.2で組んだ日本語の長文、「次世代プラットフォームでシームレスな体験を」みたいなコピーを1ファイルに入れて、detect に通す。出たルールと出なかったルールを表の3つに振り分ければ、自分の案件でどこまで任せられるかの目安になる。

impeccableをインストールすると増えるものと、フックの止め方

スキルとして入れるなら、プロジェクトのルートで npx impeccable install を実行する。対話式で使っているツールを選ぶ形で、--providers=claude --scope=project のように指定しておけば選ぶ手間が省ける。

Claude Code向けにプロジェクト単位で入れると、.claude/ の下にスキル本体、コマンドごとの手順書、検出エンジン、フックの設定が置かれる。このフックはファイルを編集したあとや作業の区切りで検出を走らせるもので、READMEにはモデルのツール承認とは別に動くと書かれている。エンジンが手元に無ければ ~/.impeccable/bin/ にダウンロードされることもあるので、勝手に動いてほしくない案件なら --no-hooks を付けて入れる。

あなたの案件では、.claude/ をリポジトリにコミットしている？ しているなら、入れた直後に git status で増えたファイルを見て、どこまで共有するかを決めておきたい。作業中にできる .impeccable/ については、スクリーンショットや作業中の状態は無視して、config.json や design.json、批評の記録は残す前提の .gitignore の書き方がREADMEに載っている。

入れたあとは、AIツールのチャットで /impeccable init を打つ。プロジェクトを読み、足りないところだけ質問して PRODUCT.md を書くコマンドで、対象読者、目的、使われる状況、制約、トーンといった見た目以前の前提が残る。見た目の方針は DESIGN.md に分ける作り。受託は読者も制約も案件ごとに変わるから、この前提を最初に書き残せるのはありがたい。

指摘ゼロのAIっぽいUIも、最後は人の目で見る

READMEには、検出結果がきれいでもそれは証拠のひとつで、見た目やアクセシビリティの品質の証明にはならない、と書かれている。表示した画面を必要な画面幅で確かめる作業は、人に残る。

ブラウザで画面を見ながら手を入れる live モードも、対象はローカルの開発サーバーか手元のHTMLだけで、本番サイトには使えない。公開中のページは、さっきの detect にURLを渡すか、ブラウザ拡張で見る。

わたしの見立てでは、impeccableで消しやすいのは色と形のような言語に関係しない癖。日本語の行の長さや決まり文句がどこまで拾えるかは、まだ自分の画面で確かめる段階だと思う。まずは直近の1画面に npx impeccable detect をかけて、最初に作ったメモと並べてみてほしい。メモに残った行が、次にデザイナーさんと話すときの言葉になる。