デザインエンジニアのためのエージェントスタック

デザインエンジニアには、純粋なエンジニアとは異なるエージェントスタックが必要です。 標準的なエージェントインフラは正確性の最適化に特化しています。テストが通る、型チェックが通る、リンティングルールが守られる。しかし、デザイン品質に対する同等のインフラ——エージェントが「単に機能する」のではなく「考え抜かれた」アウトプットを生み出すことを保証する仕組み——は、まだ誰も構築していません。デザインエンジニアのエージェントスタックは、タイポグラフィフック、カラーシステムフック、レイアウト検証、Lighthouseゲート、アクセシビリティリンティング、そしてビジュアルリグレッションテストの6つのコンポーネントで構成されます。これらが一体となり、クラフトをパイプラインに組み込みます。

このギャップは、AIが生成したあらゆるインターフェースに表れています。スペーシングに一貫性がない。フォントサイズがスケールから逸脱する。ハードコードされたhex値がトークンシステムをバイパスする。エージェントがCSSを変更した後、誰もCLSを確認しなかったためにモバイルでレイアウトシフトが発生する。エージェントはすべてのテストに合格し、すべての型チェックを満たし、コードレビュアーが承認するようなアウトプットを生成しました——コードレビュアーはロジックを評価するのであって、視覚的な一貫性を評価するわけではないからです。デザインエンジニアは問題に即座に気づきます。エージェントインフラは何も気づきません。何を見るべきか、誰も教えていないからです。

エンジニア向けのエージェントインフラは急速に成熟してきました。フックが危険なgitコマンドをブロックする。エビデンスゲートが作業完了の前に証拠を要求する。品質ループがすべての行の再読を義務づける。エンジニアリング品質は検証可能なプロパティ（正確性、パフォーマンス、セキュリティ、型安全性）に分解でき、各プロパティはバイナリな結果を生成するツールに対応しています。

デザイン品質も同様に分解できます。テイストは技術的なシステムであり、制約、評価基準、パターン認識、コヒーレンスという4つのエンコード可能なコンポーネントで構成されます。最初の3つは自動化されたインフラに直接マッピングできます。コヒーレンスには人間の判断が必要ですが、残りの3つだけでも、エージェントが生み出す最も一般的なデザイン上の失敗を防ぐには十分です。タイポグラフィ違反、カラードリフト、レイアウトの不安定性、パフォーマンスリグレッション、アクセシビリティの欠陥——これらはすべて機械で検出可能です。デザインエンジニアのエージェントスタックは、それらを検出します。

デザインエンジニアがエージェントに求めるもの

純粋なエンジニアは問います：コードは動くか？デザインエンジニアはさらに6つの問いを投げかけます。それぞれが視覚的品質の異なる次元をターゲットにしています。

視覚的一貫性。 スペーシング値が8ポイントグリッドまたは定義されたスペーシングスケールに従っている。アラインメントがバーティカルリズムを尊重している。要素間のプロポーショナルな関係がビューポートサイズをまたいで安定している。新しいカードコンポーネントで var(--space-md) ではなく margin-top: 13px を使うエージェントは、テストでは検出できない視覚的ノイズを生み出しています。

タイポグラフィの規律。 コードベース内のすべてのフォントサイズがタイプスケールのステップに対応している。不正なサイズは存在しない。カスタムプロパティをバイパスするインラインオーバーライドもない。ウェイトの使用は確立された階層に従う：見出しに700、本文に400、メタデータに300。サブタイトルを font-size: 19px に設定するエージェントは、スケールに存在しないステップを発明しており、視覚的な階層が崩壊します。

カラーシステムコンプライアンス。 すべてのカラー値がデザイントークンを参照している。:root 外にハードコードされたhex値は存在しない。コントラスト比は最低でもWCAG AAを満たし、可能な限りAAAを達成する。私のサイトのゼロカラーシステムは、絶対的な黒に対する4つのオパシティティアを使用し、すべてのティアがAAAをクリアしています。color: #cccccc を導入するエージェントは、トークンシステムをバイパスし、誰も検証していないコントラスト関係を生み出しています。

パフォーマンスへの意識。 Cumulative Layout Shiftがゼロであること。First Contentful Paintが予算内に収まること。Total Blocking Timeがリグレッションしないこと。エージェントは、視覚的な変更がパフォーマンスに影響することを理解しなければなりません。スクロールのたびにレイアウトの再計算を引き起こすCSSの変更は、見た目がどうであれパフォーマンスバグです。

アクセシビリティ。 セマンティックなHTML構造。適切な見出し階層。必要な箇所にはARIA属性を、不要な箇所には付けない。カラーコントラストの検証。フォーカスインジケーター。スクリーンリーダーとの互換性。Lighthouse監査は計測可能なサブセットを捉えますが、自動化ツールが見逃す構造的なセマンティクスもエージェントは維持しなければなりません。

テイスト。 最もエンコードしにくい要素です。要素間のコヒーレンス。装飾における抑制。偶然の空白ではなく、意図的なホワイトスペース。テイストとは、すべてのルールに従いながらも違和感のあるレイアウトと、すべてのルールに従い、かつ正しく感じられるレイアウトを区別する品質です。自動チェックは違反を検出します。テイストレイヤーは、違反ではないが配慮に欠けるものを検出します。

デザインエンジニアのスタック：6つのコンポーネント

各コンポーネントは、エージェントが生成したアウトプットで実際に観察した特定の失敗モードに対応しています。理論的なものではありません。それぞれが何かが実際にうまくいかなかったから生まれたもの——私の95フックインフラのすべてのフックと同じ起源です。

1. タイポグラフィフック

タイポグラフィフックは、コミット内のすべての font-size 宣言がタイプスケールのCSSカスタムプロパティを参照していることを検証します。フックは変更されたファイルをスキャンし、定義されたステップにマッピングされない生のピクセル値やrem値を検出します。

#!/bin/bash
INPUT=$(cat)
DIFF=$(echo "$INPUT" | jq -r '.tool_input.command // empty')

# Catch font-size declarations that bypass the type scale
if echo "$DIFF" | grep -qE 'font-size:\s*[0-9]+(px|rem|em)'; then
  cat << EOF
{"decision": "block", "reason": "Font size must use a --font-size-* token"}
EOF
fi

このフックはシンプルです。より洗練されたバージョンでは、値をパースして、ピクセル換算値が13ステップスケールのいずれかのステップに一致するかを確認します。重要なのは洗練さではありません。重要なのは、エージェントがインフラのフラグなしに不正なフォントサイズを導入できないということです。ブリングハーストの調和的な活字関係の原則が保たれるのは、エージェントが調和を理解しているからではなく、フックがそれを体現するスケールを強制しているからです。¹

フォントウェイトにも別途検証が必要です。私のシステムでは3つのウェイトを使用しています：700、400、300。カードタイトルを font-weight: 600 に設定するエージェントは、確立された階層と矛盾するウェイトを導入しています。タイポグラフィフックはこの逸脱を本番環境に到達する前に検出します。

2. カラーシステムフック

カラードリフトは、エージェントが生成したCSSで最も一般的なデザイン上の失敗です。エージェントはダークバックグラウンドのテキストが白であるべきだと知っています。しかし、#ffffff を var(--color-text-primary) にすべきこと、または65%オパシティのセカンダリテキストが rgba(255,255,255,0.60) ではなく var(--color-text-secondary) であることは知りません。

カラーフックは、:root とデザイントークン定義の外側にあるハードコードされたカラー値をスキャンします：

# Block hardcoded colors outside token definitions
if echo "$DIFF" | grep -vE '^\+.*:root' | \
   grep -qE '#[0-9a-fA-F]{3,8}|rgba?\('; then
  cat << EOF
{"decision": "block", "reason": "Use color tokens, not hardcoded values"}
EOF
fi

ゼロカラーデザインシステム——サイト全体のビジュアルアイデンティティを駆動する同じブルータリストな制約——のおかげで、エンフォースメントは簡単です。パレットにはちょうど10個のトークンしかないからです。これらのトークンのいずれにも一致しないカラー値は、定義上誤りです。より広いパレットでは、より繊細な検証が必要になるでしょう。制約ベースのアプローチがフックを簡素化するのは、制約がデザインを簡素化するからです。

3. レイアウト検証

レイアウト検証は2つのカテゴリの失敗を検出します：CSSの変更によって導入されるCumulative Layout Shiftと、レスポンシブブレークポイントのリグレッションです。

CLS検出には、変更前後のページ計測が必要です。プリコミットフックではブラウザを実行できませんが、CIパイプラインなら可能です。インフラはヘッドレスChromeでステージングデプロイメントに対してLighthouseを実行し、CLS値を前回のビルドと比較し、差分が0.01を超えた場合にマージをブロックします。GoogleはCLS 0.1未満を「良好」と見なしていますが、私の閾値は10倍厳しく設定しています。CLS 0.493がどういうものか見てきたからであり、リグレッションは許容しません。

レスポンシブ検証では、定義されたブレークポイントでのレイアウト確認が必要です。ビジュアルリグレッションツールが375px（モバイル）、768px（タブレット）、1440px（デスクトップ）でスクリーンショットを撮影し、ベースライン画像と比較します。1440pxでは問題なく見えても、375pxでヘッダーが5ピクセルずれていれば、モバイルの比較で表面化します。レスポンシブ動作をテストせずに max-width プロパティを変更したエージェントは、レスポンシブ動作を自動的にテストするインフラによって検出されます。

4. Lighthouseゲート

Lighthouseゲートは、メインブランチへのすべてのマージの前にフル監査を実行します。4つの閾値を強制します：

カテゴリ	閾値
パフォーマンス	100
アクセシビリティ	100
ベストプラクティス	100
SEO	100

これらの閾値は目標ではありません。現在の本番スコアを反映しています。いずれかのスコアを100未満に下げるコミットはブロックされます。ゲートはCIで lighthouse-ci を使用して実行され、結果はステータスチェックとしてプルリクエストにフィードバックされます。

# lighthouse-ci configuration
assertions:
  performance: ["error", { minScore: 1 }]
  accessibility: ["error", { minScore: 1 }]
  best-practices: ["error", { minScore: 1 }]
  seo: ["error", { minScore: 1 }]
  cumulative-layout-shift: ["error", { maxNumericValue: 0.01 }]

Lighthouseゲートは、人間のレビュアーが気づかないパフォーマンスリグレッションを検出します。最適化されていない画像、レンダーブロッキングスクリプト、またはスタイル未適用のフラッシュを引き起こすCSSファイルを追加したエージェントは、変更が本番に到達する前にゲートで失敗します。ゲートはなぜ変更がリグレッションを引き起こしたかを理解しません。理解する必要もありません。リグレッションをブロックし、次の試行のためにエージェントのコンテキストに失敗理由を提供します。

5. アクセシビリティリンティング

アクセシビリティ検証は、静的解析とランタイム評価の2つのレイヤーに分かれます。

静的解析は、レンダリングされたHTMLに対してaxe-coreを実行します。WCAG 2.1 AAルールセットが、alt属性の欠落、不適切な見出し階層、不十分なカラーコントラスト、フォームラベルの欠落、ARIAの誤用を検出します。チェックはLighthouseゲートと同じヘッドレスChromeインスタンスで実行され、追加のオーバーヘッドはほぼありません。

// axe-core integration in CI
const { AxeBuilder } = require('@axe-core/playwright');
const results = await new AxeBuilder({ page })
  .withTags(['wcag2a', 'wcag2aa', 'wcag21aa'])
  .analyze();

if (results.violations.length > 0) {
  process.exit(1); // Block the merge
}

ランタイムレイヤーは、静的解析が見逃す問題を検出します：HTMXスワップ後のフォーカス管理、動的コンテンツのキーボードナビゲーション、状態変化に対するスクリーンリーダーのアナウンス。これらのチェックには、単なるDOM検査ではなくスクリプト化されたインタラクションが必要です。ノービルドアプローチはページを十分にシンプルに保ち、アクセシビリティの対象面積を管理可能な範囲に維持しています。

アクセシビリティリンティングは、ほとんどのエンジニアがすでに理解しているコンポーネントです。デザインエンジニアが加えるのはツールではなく閾値です：「許容できる」違反ではなく、違反ゼロ。Lighthouseスコア100/100/100/100と同じ哲学です——完璧をベースラインとし、目標とはしない。

6. ビジュアルリグレッションテスト

ビジュアルリグレッションテストは、現在のビルドのスクリーンショットを承認済みのベースラインと比較します。比較には知覚的な差分アルゴリズムを使用し、人間が気づく変化を検出しつつ、人間が気づかない変化（サブピクセルレンダリングの違い、アンチエイリアシングのばらつき）は無視します。

Percy、Chromatic、BackstopJSなどのツールが比較を自動化します。パイプラインは各定義ブレークポイントでスクリーンショットを撮影し、ベースラインとの知覚的差分を実行し、閾値を超えるページにフラグを立てます。フッターの0.1%のピクセル差異はノイズです。ヒーローセクションの2%のシフトはリグレッションです。

ビジュアルリグレッションは、「ページは正しく見えるか？」の最も近い自動近似値です。知覚的差分は、レイアウト変更が改善なのか劣化なのかを評価することはできません。変化が発生したことだけを検出します。フラグが立てられた差分を人間がレビューし、承認または却下します。自動化の価値はカバレッジにあります。すべてのコミットですべてのブレークポイントですべてのページをテストする——人間が手動で行うことのないタスクです。

スタックと私のインフラの対応関係

6つのコンポーネントは、このサイトのデザインエンジニアリングコンテンツ全体ですでに文書化されている決定と接続しています。

タイポグラフィフックは13ステップタイプスケールを強制します。コンテンツ駆動の段階的スケールがCSSカスタムプロパティとして存在し、フックはこれらのプロパティがコードベース内の唯一のフォントサイズであることを保証します。カラーシステムフックはゼロカラーデザインシステムを強制します：10個のトークン、4つのオパシティティア、ブランドカラーなし、省略不可。Lighthouseゲートは100/100/100/100スコアを維持し、そのスコアを達成したCSSの抽出とレンダーブロッキングの排除を覆すコミットを防ぎます。

ノービルドアプローチはスタック全体を簡素化します。ソースマップの照合が不要。ツリーシェイキングの曖昧さがない。記述されたCSSと出荷されるCSSの間にトランスパイルレイヤーがない。エージェントが書いたものがそのまま出荷されるため、フックが検証するものがユーザーの目に触れるものと一致します。

エビデンスゲートは、エンジニアリングレビューと同様にデザインレビューにも適用されます。「タイポグラフィは正しく見える」はエビデンスではありません。「差分内のすべてのfont-size宣言が --font-size-* トークンにマッピングされていることをタイポグラフィフックで検証済み」がエビデンスです。デザインシステムがフックの強制対象となるトークンを提供します。トークンがなければ、検証対象がありません。フックがなければ、トークンは単なる提案です。Nathan Curtisはこのダイナミクスを特定しました：ガバナンスのないシステムは、誰も読まないドキュメントへと退化します。²

テイストレイヤー

6つのコンポーネントは違反を検出します。タイポグラフィフックが不正なフォントサイズを、カラーフックがハードコードされた値を、レイアウト検証がCLSを、LighthouseゲートがパフォーマンスリグレッションをCLSを、アクセシビリティリンティングがWCAGの不備を、ビジュアルリグレッションが意図しない変更を検出します。

しかし、これらのどれも、すべてのルールに従いながらも違和感のあるアウトプットは検出できません。

正しいフォントサイズ、適切なトークン、CLSゼロ、完璧なLighthouseスコア、WCAG完全準拠、ビジュアルリグレッションなし——しかし、タイトルが画像に近すぎるスペーシング、可読性を損なう行長、唐突で配慮に欠けるホバーステート。すべての自動チェックをパスしています。カードは正しい。しかし、カードは良くない。

テイストはルールレイヤーの上で機能します。制約はルールに違反するものを検出します。評価基準はメトリクスに失敗するものを検出します。パターン認識は二度目の確認で明らかになるものを検出します。コヒーレンスはシステム全体の視点だけが露わにするものを検出します。6つの自動化コンポーネントは制約と評価基準を処理します。パターン認識とコヒーレンスには品質ループが必要です——作業を何度も（2回目、3回目、4回目と）繰り返し、そのたびにルールが守られているかではなく、結果が出荷に値するかを確認する、義務づけられたプロセスです。

品質ループこそ、デザインエンジニアがその肩書きの「エンジニア」の部分を正当化する場です。テストに合格するコードを出荷するエンジニアは最低限を行っているにすぎません。自動チェックに合格し、品質ループを生き延びたインターフェースを出荷するデザインエンジニアは、機械がまだ評価できない基準を維持しています。プライドチェックは5つの問いを投げかけ、最後の問い（「より良い状態で残せたか？」）には自動化された同等のものがありません。Steve基準も同様です：Blakeはこれに自分の名前を記すだろうか？

複合効果

各コンポーネントは特定のカテゴリのデザイン上の失敗を防ぎます。組み合わさると、個々のチェックの合計を超える複合効果が生まれます。

スタックなしのエージェントセッションは、アウトプットがドリフトします。フォントサイズがスケールの外に蓄積する。カラー値がトークン化されずにハードコードされる。パフォーマンスが、単一のコミットでは気づかないが数週間で蓄積する小さな増分でリグレッションする。このドリフトは個々の差分では見えず、集約すると明白になります。

スタックありのエージェントセッションではドリフトが起こり得ません。フックがタイプスケールからのすべての逸脱をブロックします。カラーシステムがすべてのハードコードされた値を拒否します。Lighthouseゲートがすべてのパフォーマンスリグレッションを検出します。エージェントがデザインエンジニアの基準を継承するのは、エージェントがその基準を理解しているからではなく、インフラがそれを強制しているからです。エージェントにテイストは必要ありません。エージェントに必要なのは制約であり、その制約がテイストを体現しています。

Jony IveはAppleのデザインプロセスを「たゆまぬ洗練」と表現しました——固定された一連の原則に対する反復を通じた品質であり、新奇さによるイノベーションではありません。³ デザインエンジニアのエージェントスタックは、同じ考えを運用に落とし込んでいます。原則はトークン、スケール、閾値として固定されています。洗練がたゆまないのは、自動化がすべてのコミットで実行されるからです。

基準をエージェントスタックにエンコードするデザインエンジニアは、自律生成中の品質維持以上のことを達成しています。品質をスケールさせているのです。すべてのセッション、すべてのエージェント、すべてのコミットが同じ制約を継承します。コヒーレンスの評価、品質ループの実行、アウトプットが出荷に値するかの判断は依然として人間が行います。しかし、フォントサイズの違反やハードコードされたカラー、CLSリグレッションは、もはや人間が検出する必要はありません。スタックがそれらを先に検出しているからです。人間の注意は、機械が答えられない問いに完全に振り向けられます。

FAQ

6つのコンポーネントすべてを最初から導入する必要がありますか？

いいえ。最も頻繁に発生する失敗モードに対応するコンポーネントから始めてください。タイポグラフィフックとカラーシステムフックが最もリターンが高く、エージェントが生成するデザイン上の欠陥で最も頻度の高いものを検出できるからです。次にLighthouseゲートとアクセシビリティリンティングを追加しましょう。ビジュアルリグレッションとレイアウト検証はインフラの構築負荷が最も高いため、導入順序としては後半に位置づけるのが適切です。

ビルドツールを使っていてもスタックは機能しますか？

どのフロントエンドアーキテクチャでも機能します。ノービルドアプローチでは、記述されたコードと出荷されるコードの間に変換レイヤーがないため実装が簡素化されます。ビルドツールを使う場合、フックはソースファイルを検証し、Lighthouseとビジュアルリグレッションはビルドされたアウトプットを検証する必要があります。コンポーネント自体は同じです。統合ポイントが変わるだけです。

スタックなしでエージェントはテイストを学べますか？

現在の言語モデルにテイストはありません。モデルは統計的に尤もらしいアウトプットを生成し、統計的に尤もらしいアウトプットは学習データの中央値に収束する傾向があります。スタックはエージェントにテイストを教えるものではありません。スタックはエージェントを制約し、テイストに欠けるアウトプットが出荷前にパイプラインで却下されるようにします。この区別は重要です。テイストをインフラとしてエンコードする方が、プロンプトからモデルがテイストを内在化することを期待するよりも信頼性が高いことが証明されています。

ビジュアルリグレッションテストは意図的な変更をどう扱いますか？

意図的な変更は予期されたビジュアル差分を生成します。ワークフローが差分にフラグを立て、人間がレビューして承認し、ベースラインを更新します。ビジュアルリグレッションの価値は変更を防ぐことではなく、意図しない変更を表面化させることにあります。ボタンの色を変更したエージェントが、同時にカードレイアウトを3ピクセルずらしていた場合、色の変更は意図的ですが、レイアウトシフトはそうではありません。ビジュアルリグレッションテストがその副作用を検出します。

出典

Robert Bringhurst, The Elements of Typographic Style, Hartley & Marks, 4th edition, 2012. Bringhurst establishes that typographic harmony follows mathematical ratios derived from musical intervals. ↩
Nathan Curtis, “Governance and Evolution,” Medium, 2019. Curtis documents the governance failure mode in unmanaged design systems, where tokens and guidelines exist but compliance degrades without enforcement mechanisms. ↩
Ian Parker, “The Shape of Things to Come,” The New Yorker, February 23, 2015. Ive describes Apple’s design process as iterative refinement within fixed constraints rather than open-ended exploration. ↩