書いた当日に監査する

自分が数時間前に書いたコードでも、監査という別の読み方をすれば欠陥は出る。 「新鮮な目でないと見つからない」は、少なくとも実装レベルでは成り立たない。

2026-08-22 の実例。API キーらしき文字列を伏せる関数を書き、テストを 10 件つけて通した。 その数時間後に同じファイルを監査として読み直したら、3 通りの入力で素通りしていた ——KEY:xxxx（コロン区切り）、タブ区切り、x=xxxx&y=1（クエリ文字列）。 空白で 1 語ずつ切って判定していたためで、入力が空白で区切られている保証はどこにも無かった。

書いたときと監査のときで、頭の使い方が違うのが効く。

• 書くときは「動くか」を問う。用意した例が通れば先へ進む
• 監査のときは「破れるか」を問う。自分が用意しなかった入力を探しに行く

だから同じ人間・同じ日でも成立する。必要なのは時間の経過でも他人の目でもなく、 問いの切り替えと、それを強制する枠（監査という工程が別に立っていること）。

逆に、テストは守ってくれない。 テストは自分が思いついた入力の集合でしかなく、 思いつかなかった入力はテストにも無い。上の 3 件は、監査で見つけてからテストに足した。 テストが穴を塞ぐのではなく、塞いだ穴が二度と開かないようにするのがテストの仕事。

「テストが通った」は「壊れない」ではなく「思いついた壊し方では壊れない」。

出典：parabel（textproc.mask_secrets・監査 parabel F2）。 関連：名付けた退避路は発火条件まで書く（そちらは名前が検証を代替してしまう話）