クイック判断テーブル
変更内容に基づいて使用すべきテストレベルを決定する。
クイック判断テーブル
このテーブルを使って、現在のタスクに必要な最小テストレベルを判断します：
| 変更内容 | 最小レベル | 理由 |
|---|---|---|
| 純粋なロジック/ユーティリティ関数 | レベル1 | DOMやCSSが関与しない |
| コンポーネントのprops/状態 | レベル2 | 出力を検証するためにシミュレートDOMが必要 |
| ビルド設定/テンプレート/SSG | レベル3 | ビルドされた出力ファイルを検査する必要がある |
| CSS/レイアウト/表示 | レベル5 | CSSは実際のレンダリングエンジンが必要 |
| インタラクティブなUIフロー | レベル4 | ユーザーインタラクションには実際のブラウザが必要 |
| ビジュアルバグの報告 | レベル5 | 算出スタイル + 視覚的結果を確認する必要がある |
| 「表示されない」 | レベル5 | 表示は視覚的な属性 |
| 「まだ壊れている」（テストがパスした後） | 1つ上のレベル | 現在のレベルはこのバグに対するブラインドスポットがある |
| canvas／フォトエディタ／ズーム・リサイズなどで、L4が書けず、かつL5でも到達できない | レベル6（最終手段） | E2Eも決定論的視覚検証もアサーションを表現できない |
Warning
「最小レベル」とは、バグを確実にキャッチできる最低のレベルを意味します。 より低いレベルを使用すると誤った確信を与えます -- テストはパスしますが、バグは残ります。
判断フローチャート
重要な原則: CSSは常にレベル5が必要
CSS、レイアウト、視覚的な外観に関わる変更はレベル5をデフォルトにすべきです。その理由：
レベル1（ユニットテスト）-- DOMがまったくなく、CSSを処理できない
レベル2（jsdom）-- DOMはあるがCSSエンジンがない；
getComputedStyle()は空文字列を返すレベル3（ビルド出力）-- ファイルの内容を検査するが、レンダリングは検査しない
レベル4（Playwright）-- 実際のブラウザで実行するが、通常は視覚的な外観ではなくDOMの状態をアサートする
レベル5（verify-ui + headless-browser）のみが、算出スタイルの値を決定論的にチェックし、結果を視覚的に確認できます。
エスカレーションのトリガー
以下の場合に次のレベルに進みます：
テストがパスしたがユーザーが問題の継続を報告した
ロジックをテストしているがバグが視覚的な可能性がある
下位レベルのテストでデータの正しさが確認されたが出力が正しく見えない
CSSまたはレイアウトの問題が疑われる
複数の下位レベルのテストがパスしたが機能がブラウザで動作しない
L6へのエスカレーションルール
レベル6（AIベース）へのエスカレーションは、通常の「次のレベル」進行の一部ではありません。同時に以下の両方が真である必要があります：
L4が書けない。 対象サーフェスに対してクリーンなE2Eを書くことが真に不可能 — canvasベース、多重のカメラ／ズーム、ステートフルなリサイズ変換など — 単に「いつもより難しい」ではない。
L5がアサーションに届かない。 安定したbounding rectを返すDOM要素がない、算出スタイルが適用できない（対象が
<canvas>）、スクリーンショットのピクセル差分はノイズが多すぎる。
どちらか片方しか真でない場合、正しい答えはもう一方の階層です。L6は最終手段であり、「L5が難しいときの次の試み」ではありません。
レベルを選んだ後：実行場所を決める
適切なテストレベルを選ぶことで、テストが何を見るかが決まります。残る2つ目の決定は：テストはどこで・いつ実行されるのか？ それが実行ティアです — 独立した別の軸です。
実行ティア — T0（インナーループ）からT4（ローカルヘビーレーン）までを定義し、各ティアの適用条件とティア間の移行ルールを説明します。
重いテストの判断ルール — PR CIに重すぎると感じるテストへの対処手順：レベルを下げるか、削除するか、「なぜ重いのか」を分類して適切なティアを割り当てます。