Impeccable:AIコーディングエージェントのためのデザイン言語と決定的検出ルール

背景と課題の所在

コーディングに使われる大規模言語モデルは、ほぼ同じ公開ウェブコードのコーパスで学習されている。同じコンポーネントライブラリ、同じSaaSマーケティングサイト、同じTailwind系テンプレート。その結果、どのモデルで生成しても、AIが作るフロントエンドは狭い範囲の視覚的習慣に収束する。既定フォントとしてのInter、紫から青へのグラデーションヒーロー、カードの中にカードが入れ子になった構造、色付き背景の上の薄いグレー文字、そして見出しの上に浮かぶ角丸正方形のアイコンタイル。

これらは特定モデルの欠陥ではなく、学習データが生む統計的な産物であり、プロンプトの工夫だけでは確実に取り除けない。モデルは前日に何を納品したかを記憶しておらず、自らの出力をルールブックと照合する仕組みも持たないからだ。AnthropicのfrontendデザインスキルはAI向けに明示的なデザイン指針を与える最初の広く採用された試みだった。Paul Bakausが開発したImpeccableはこの土台から出発し、課題を単一のスキルファイルではなく、ワークフローとツールの欠落として捉え直す。エージェントにはセッションをまたいで持続する製品コンテキスト、変更を依頼するための共通語彙、そして同一モデルの自己評価に頼らない検証手段が必要だという考え方である。

コアアーキテクチャと技術原理

Impeccableは`/impeccable`という単一コマンドとしてインストールされるが、実際のアーキテクチャは2つの文書と2層の検証の分離にある。`PRODUCT.md`は`/impeccable init`によって一度だけ記録され、対象ユーザー、目的、運用文脈、制約、トーン、根拠といった持続的な製品事実をまとめる。これは表層的な視覚方向とは意図的に切り離されており、視覚方向は各画面ごとに選ばれ、既存または新規の視覚システムが確立された時点で別途`DESIGN.md`に記録される。

この基盤の上に、設計ワークフローの異なる段階に対応する24のコマンドが乗る。計画と構築を担う`shape`と`craft`、レビューを担う`critique`と`audit`、納品準備を担う`polish`、`harden`、`onboard`、そして全体の方向性を蒸し返さずに強弱を調整するダイヤル系コマンド群——`bolder`、`quieter`、`distill`、`animate`、`colorize`、`overdrive`。2層目はLLMもAPIキーも不要な61の決定的検出ルールで、CLIと専用ブラウザ拡張機能の両方で同じルールセットが走るため、コントラスト比や余白のリズム、フォントの組み合わせ違反といったチェックは、実行やモデルが変わっても常に同じ結果を返す。

実用性と検証結果

実際の運用では、プロジェクトは一度`npx impeccable install`を実行し、新しい取り組みを始めるたびに`/impeccable init`を実行する。セットアップ手順は持続的な製品コンテキストの欠落部分だけを尋ね、すでに記録済みの事実をチームに再び聞き直すことはない。そこから`/impeccable craft`が、ライブブラウザでの反復を伴う「方向付けから構築まで」の一連の流れを実行し、エージェントは自分がレンダリングした結果を確認し、制御を戻す前に自ら修正できる。

決定的ルールが最も重要になるのはレビュー系コマンドだ。`/impeccable audit`はアクセシビリティ、パフォーマンス、レスポンシブ対応という61ルールの技術的検査を実行し、`/impeccable critique`は階層構造、明快さ、感情的な響きといった定性的判断を、デザインリードがレビュー会で行うように保つ。`/impeccable document`と`/impeccable extract`は、既存コードから`DESIGN.md`を生成し、再利用可能なコンポーネントとトークンを共有システムに取り込むことでループを閉じる。これは、文書化されていないまでも既に独自の視覚言語を持つコードベースにImpeccableを導入するチームにとって特に重要だ。

業界への影響と今後の展望

Impeccableが短期間で7万4千を超えるスターを集めたことは、エージェント型コーディングツールがフロントエンドコードの大部分を実際に書くようになった今、画一化への懸念がいかに切実かを物語っている。この取り組みの本当の貢献は個々のコマンドではなく、AI出力のデザイン品質チェックはテストスイートと同じ厳格さを備えるべきだという主張にある。判断を要しない部分は決定的で再現可能、かつモデルを介さずに実行できるべきだという考え方だ。

主観的な半分はLLMによる批評に、検証可能な半分は決定的ルールに委ねるこの分担は、同じモデルに書かせてから採点もさせるという矛盾を避ける唯一の方法であるため、この領域の後続ツールが踏襲していく型になる可能性が高い。残る疑問は、デザインの流行が移り変わる中で61のルールがどこまで通用するかだ。今日の「AIらしさ」に合わせて調整されたルールセットも、どのリンター設定とも同様に継続的な保守を要する。さもなければ、エージェントがすでに明日の既定スタイルに乗り換えている間に、昨日のグラデーションを追いかけ続けることになる。