テストは緑なのに壊れている ― Coverage AuditとAssurance Auditの違い

• URL: https://zenn.dev/ichikawa_y/articles/assurance-audit-grading-engine
• 日付: 2026-06-22
• Tier: Tier 3
• 要旨: カバレッジ95%・テスト緑・CIも緑でも脆弱性が見つかるのは、Coverage Auditが「どれだけテストしたか」を測るのに対し、Assurance Auditが「守るべきことが本当に守られているか」を問うから。制御が存在しない、モックが防御を無効化、テストが期待値でなく副作用しかassert していないといったTest Theater（テスト劇場）を見抜く必要。Control（None/Detective/Preventive）→ Test → Quality（Strong/Weak）→ Statusで信頼度を採点する採点モデルが有効。Expected Outcome を明文化する工程自体が制御の不在を暴く最良のタイミング。

詳細

Coverage Audit は カバレッジ率・テスト件数で「どれだけテスト」を測るが、20%の未テスト部分が危ないか、80%が実は守れていないか何も言わない。Assurance Audit は「起きてはならないこと」の制御（None/Detective/Preventive）→ テスト有無 → テスト品質（Strong/Weak）→ Status で信頼度を採点。assertが存在・テストが通る・CIが緑でも、本当に守りたいものは一度も検証されていない Test Theater を見抜く。Quality の判定基準：Strong は期待される結果（Expected Outcome）を直接assertしている（response.status==403を直接見ている）；Weak は副作用やモック裏の本体隠蔽・別機能経由での間接カバー。重要なルール：Weakが件数を上書きする――10件のWeakは10件の赤のまま。テストの数増は Assurance Audit 観点では信頼度を上げない。通常テスト思想は「テスト書く→assert」で終わるが、Assurance Audit は「テスト前に Expected Outcome を1行明文化」を加える。これは「テストの前に仕様を監査」である。実施例で起きたのも Expected Outcome を書いた瞬間に制御が実装側に存在するか確認せざるを得なくなり、確認過程で制御の不在が露呈。Control Strength：None は機構がない；Detective は悪いことが起きた後に気づく（監視・アラート・ログ）；Preventive は起きる前に止める（403・429・UNIQUE制約）。「ログに残す」は Detective で Preventive でない。Status の組み合わせ：Missing Control（None）は赤；Stale Control（テスト0件なのに台帳上は対策済み）は赤；Weak Test（テストあるが品質Weak）は赤；Structural Weakness（Preventive可能なのにDetective のみ）は黄；SPOF（Strong なテスト1件のみ）は黄；OK（Strong 2件以上）は緑。Status は健全度で重要度でない。「grep で0件」は存在しないの結論でなく「もっと深く掘れ」のトリガー――タグだけで検索0件なら、期待される結果と制御の具体的な識別子で再検索。