配布資料 48事例 #08: CSS だけの監査が、同じ漏れを2回すり抜けさせた

7,868箇所を直しました。それでも漏れました。しかも一度ではなく、二度すり抜けました。監査そのものが間違っていたのです。

何が起きたか

マルチテナント対応——テナントごとにブランド配色を差し替える——のため、ハードコード色を全廃してテーマトークンに統一するプロジェクトを実施しました。

大規模一括修正で、inline style の CSS 化を7,868箇所・327ファイル規模で完遂しました
その直前に追加されたばかりのタブコンポーネントが、inline style に固定紫色を直書きしたまま対象リストから漏れました。 監査スナップショットを取ったあとに生まれたファイルでした
後日の「テーマ適用漏れ一括修正」でも捕捉できませんでした。 この監査は CSS ファイルの grep が中心で、inline style を構造的に見ていなかったからです
二重すり抜けの発覚を機に、対象領域の全 tsx ファイルを inline style・color/fill props まで含めて再監査したところ、さらに6件の漏れが出ました

影響としては、テナントが配色を変えても該当 UI だけ旧ブランド色のまま固定されます。

なぜ起きたのか

表面的には、タブコンポーネントの inline 直書きです。

盲点は2つありました。 ①監査手法の盲点。 CSS ファイルの grep は、inline style={{}}・color=/fill= props・SVG グラデーションを構造的に捕捉できません ②時間差の盲点。 一括修正の完了後に追加された新規コードは監査の対象外になります。「監査済み = 以後も安全」ではありません

そこから生まれたルール

「テーマ監査は CSS ファイルだけでなく inline style・color/fill props・SVG も対象に含める」を禁止事項として明文化しました。

そしてすべての監査系作業の共通規律「監査スコープの盲点に注意」に一般化しました。

どう機械に守らせたか

pre-commit フックが対象領域の追加行からハードコード色・inline style・非推奨クラスを検知して、コミットをブロックします。正当な固定色は明示トークンでバイパスでき、理由を記録します。

「一括監査」ではなく「混入をコミット境界で止める」方式への転換が本質でした。時間差の盲点はこれで消えます。

持ち帰るなら

grep 監査を設計するときは「この方法では何が見えないか」を先に書き出してください。

そして大規模な一括修正をしたら、必ず同時に「新規混入を止めるフック」を入れます。掃除と蛇口を閉めるのはセットです。