特定の語句（課金誘導・機密文言・ブランド語など）がエラー応答やユーザー向け出力に混入しないことを回帰テストで守るとき、ガードの「対象」と「配置」を誤ると検知力ゼロのまま green が続く。実際のレビューで3つの型が同時に見つかった。

落とし穴と判断基準

1. テスト内リテラルへの否定形アサーションは空通し。テストファイル内で自ら定義した文字列リテラル群に禁止語チェックを掛けるテストは、本番コードを一度も通らないため、本番側に禁止文言を書き戻しても必ず PASS する。テスト名が「全応答を検証」と主張していても検知力はない。ガードは対象コードを実呼び出しし、実際の応答本文に対して検証する。

2. exact match と否定形ガードの併置は原理的に発火しない。応答本文を完全一致で固定した直後に同じ本文へ禁止語チェックを置くと、完全一致が通った時点で禁止語の余地は消えており、ガードは冗長になる。この配置は「ガードが不要な場所にだけ存在し、必要な場所（未カバー分岐）には無い」という逆転を招きやすい。否定形ガードは exact match とは独立したテスト経路（別ケースで本番コードを通す）に置き、「将来 exact match 側の期待値リテラルごと文言が書き換えられても検知する」役割として設計する。

3. 同一文言の重複実装は網羅の錯覚を生む。同じ fallback 文言が複数の分岐に重複実装されていると、文言単位ではテストが揃って見えても分岐単位では未カバーが残る（4文言に対し実装箇所は6箇所、テスト済みは4箇所、という形）。守りたい文言の出現箇所を数え上げ、カバレッジツールで各分岐の実行カウントを確認する。到達条件が特殊な分岐（上限値が無制限＝nil の系など）ほど再混入が長期間検知されないため、ガードの価値が高い。

検証

禁止文言を本番コードへ意図的に書き戻し、テストが落ちることを確認する（mutation 的確認）。落ちなければガードは空通しか、配置が間違っている。

適用条件

審査・コンプライアンス・ブランド要件などで「出力に含めてはならない語」が契約になっている出力全般（API エラー応答、通知文面、生成テキストのポストプロセス）に適用できる。