テストが全部緑でも検出器は死んでいる — 変異テストでテストの検出力を機械的に検定する

AI エージェントにルールを守らせるため、hook / gate / lint などの「検出器」を何十本も書いている プロジェクト向け。検出器のテストが全部 pass していることは、その検出器が動いている証拠にならない。 テストが「壊れた検出器」と「動く検出器」を区別できるかどうかは、別に検定しないと分からない。

実測: 検出器 34 本を検定したところ、2 本のテストは検出器を無害化しても全部 pass した （片方は判定を 11 箇所ひっくり返しても誰も気付かなかった）。さらに 11 本は検定手段が無く「緑だが未検証」。 テストに検出力があると確認できたのは 21 本（62%）だけだった。

何を作るか

検出器のソースを「常に無害な判定を返す」よう書き換えた変異体を作り、同じテストスイートを流す。

• テストが落ちる → killed（検出力あり）
• テストが通る → survived（そのテストは動く検出器と死んだ検出器を区別できない）
• 変異させられない → unmutatable（合格にしない。検定不能を合格に化けさせないため終了コードを分ける）

実装（Node.js / 依存パッケージなし）

1. 変異ルール

検出器の「判定の語彙」は驚くほど少ない。次の 4 つを潰せば実務上は足りる。

ルール	置換
判定文字列	クォート内の完全一致 'block' 'warn' → 'pass'、'deny' → 'allow'。識別子（blocked など）は置換しない
終了コード	process.exit(<非ゼロ整数>) → process.exit(0)。変数引数は対象外
真偽値の判定	ok: false → true、blocked: true → false
蓄積	findings.push( → false && findings.push(（行を消すと構文が壊れるので短絡で無効化する）

重要: 変異体は構文として妥当なままにすること。クラッシュするとテストが落ち、 「検出力がある」と誤判定される（クラッシュを検出したのであって判定を検出したのではない）。 置換が 0 件なら unmutatable を返す。0 件を「合格」にしてはいけない。

2. 実行

1. リポジトリ root ごと一時ディレクトリへコピーする（fs.cpSync / node_modules と .git は除外）
2. コピー先でテストを 1 回流す（baseline）。落ちたら検定不能として打ち切る
3. コピー先の検出器を変異体で上書きし、もう 1 回流す
4. 落ちれば killed / 通れば survived

⚠️ ここで 1 回失敗する: コピー範囲を「検出器の入っているディレクトリだけ」にすると、 リポジトリ root 直下のファイルを読む検出器が起動に失敗し、baseline_failing が大量に出る。 これは偽陽性で、潰さないと本物の survived がその中に埋もれる（実際に 1 件埋もれていた）。

3. 🔴 最大の罠: テストの中から子プロセスで node --test を起動すると失敗が exit 0 になる

親のテストランナーが立てる環境変数 NODE_TEST_CONTEXT を子が継承するため。実測:

起動方法	わざと落とすテストの exit code
node --test fail.test.mjs	1
NODE_TEST_CONTEXT=child-v8 を継承	0

失敗信号が消えるので変異体が常に生き残り、全検出器が「対照群なし」に化ける。 しかも survived を期待する側のテストは空振りで通るため、スイートは緑のまま気付けない。 spawn する側で必ず外すこと:

export function childEnv(env = process.env) {
  const copy = { ...env };
  delete copy.NODE_TEST_CONTEXT;
  return copy;
}
spawnSync(process.execPath, ['--test', testPath], { env: childEnv(), /* ... */ });

一般化: 子プロセスの exit code で判定する計測器は、親のランナーが注入する環境変数を疑う。

4. このツール自身の対照群（これが無いと意味がない）

テストに次の 2 本を必ず入れる。片方だけでは自分自身が空振りする。

1. 合成の検出器＋両側を assert するテスト → killed が返ること
2. 同じ検出器＋正常側しか assert しないテスト → survived が返ること

実際にこの 1 本目が落ちたことで、上の NODE_TEST_CONTEXT の罠が見つかった。

hook として常時強制する

作っただけでは使われない。検定結果を台帳に追記し、未検定なら止める。

• 検定のたびに { name, sha256, verdict, at } を JSONL へ追記する。sha256 は検定した時点の 検出器ソースのハッシュ
• セッション終了時の hook で、作業ツリーで変更された検出器を列挙し、 現在のソースの sha256 と一致する killed の記録が無ければ block する
• ハッシュ一致を条件にするのが肝。名前だけで照合すると「昔検定したから」で素通りする （検定後にコードを 1 行足したら再び block されるのが正しい）

block のメッセージには実行すべきコマンドをそのまま書く。「検定してください」だけでは動けない。

測定限界（報告に必ず添える）

変異は判定語彙の置換に限られ、ロジックの分岐は変異させない。よって killed は 「この変異なら検出できる」であって、テストが十分である証明ではない。 unmutatable は「検定できていない」であり、緑とは違う。この 2 つを混ぜて 「全部 OK」と報告すると、この仕組みを作った意味が消える。