042_宣言を書かないだけで全部素通りできた話

AIに作業をさせるとき、「検証結果を報告書に書いてね」とお願いする方式がある。ところがある日気づいた。報告書を書かなければ、チェック機構は全部素通りできる。実際に、報告フォーマットを無視して終了したセッションで、検証ゲートが一切発動せずにタスクが完了扱いになったのを実測してしまった。ゲートは全部「宣言があること」を前提に設計されていたので、宣言しないという行為そのものに防御がなかった。

これを「オプトイン型の罠」と呼ぶことにした。検査を「書いてください」と頼む方式は、書かない選択が常に最速の抜け道になる。対策は逆転して「書かないほうが不利」なfail-safe型にすること。宣言が無ければ全テスト必須としてデフォルトで扱い、宣言があったとしても機械の実測値と突合して矛盾すれば差し戻す。人の申告を信頼するのではなく、申告と実測の一致そのものを検査対象にした。

設計を固めるのに、3種類のAIレビューを3ラウンド回して48件の指摘を集め、「反対票も付ける」判断材料を人間に提出して3件の決定をもらった。最後の実証では、報告を避けるための攻撃パターンを8種類用意して1件でも見逃したら設計に戻るという安全弁付きで試し、全捕捉を確認。ここまでの工程に、発見から実証まで全部で機械的な検査が挟まっていて、「突破の試み」自体をテストケースとして扱うのが効いた。検査を強化するとき、まず最初に調べるべきは「今の検査を通らない方法が何通りあるか」だった。

<details><summary>▶ 技術的にどうなってるか</summary>

• 構造的欠陥の実測: 検証範囲宣言がオプトイン（書かなければ無視）のため、宣言を書かないだけで全ゲートを素通りできる。セッション実測で Task 8 素通りを確認し、fail-safe化（宣言なし＝デフォルト全テスト必須）を設計の中心に置いた。
• 設計の収束方法: 同一specに対し blind レビューを複数ラウンド回し（r1:18件・r2:18件・判断レビュー12件＝計48指摘）、反対票を2:1で潰すのではなく人間へ付議して最終判断をもらう構成にした。収束の自己判定をしないための措置。
• 実証（POC-0）: 合成transcript fixtureで突破攻撃8パターンを用意し、全捕捉を実証。1件でも捕捉失敗したら設計レビューへ自動復帰する安全弁（§9-3）を実装前に明記しておき、「実証が設計を追認するだけ」になるのを防いだ。
• 運用の落とし穴: enforce化後の誤発火率・タイプIII比率の上限・オプトアウト常用率を観測指標に置き、しきい値超過で設計に戻る契約にしている。ゲートは「入れたら完成」でなく「誤発火と回避行動を観測して初めて成立」。
• 関連スキル: <code>self-inspect</code>（成果物の深点検）, <code>multi-llm-review</code>（反対票付きの設計判断）, <code>ssot-record</code>（判断と証跡の記録） </details>