検知器・検証の設計（証跡・実測での担保、fail-closed、故意ずれ検体、検算）

「〜したと報告された」「ドキュメント／設定にそう書いてある」「計画上そう割り当てた」を、それが実際に起きた・効いている証拠として扱わない。最適化するのは、機械的な実行証跡・一次情報・生成物や実挙動の実測で『実在』と『効力』を確認してから判断・完了を宣言すること。避けるのは、自己申告・書面・宣言的設定を額面どおり受け取り、宣言と実態の乖離を静かに残すこと。

判断基準

• 主体の自己申告（AI・サブエージェントの「実行した」「成功した」報告）は、実行イベントログ・権威側データの再取得・書き込み後の読み直し（read-back）で裏づけが取れて初めて事実として扱う。裏づけの無い申告は事実にも逸脱にもカウントしない。
• ドキュメント・コメント・契約・外部仕様の記述は、一次情報や実挙動での再照合を経てからレビュー・設計判断の根拠にする。『書いてある＝効いている／正しい』を信じない。
• 宣言的設定・役割定義・計画上の割り当ては、生成物や実行メタデータの実測で『実際に適用されているか』を確認する。スキーマ検証の無い設定は未知キーを黙殺し、定義と起動処理が結び付かない役割は親設定を黙って継承するなど、静的整合チェックが通っても到達不能が残る。
• ゼロ件の良好メトリクスや『テスト通過』は、検知母数（実施率・カバレッジ）と検証対象の一致を併記して初めて実績とみなす。検知が回っていないゼロや、別 checkout を検証した通過は証拠にならない。

適用条件・例外

外部書き込み・委譲・自動化・宣言的設定・可変な外部契約が絡む判断に効く。純粋に決定論的で即時に読み戻せる操作や、実測コストが確認価値を明らかに上回る些末な場面では省いてよい。実測・一次情報が未取得の段階の推論は『確認待ち』として結論扱いせず、検証されるまで保留する。

根拠（synthesize 元）

• 906 委譲エージェントの外部書き込みは成功報告を信用せず、権威台帳との突き合わせ監査で実在を検証する
• 911 委譲AIエージェントの行動制約は許可ツール設定を信頼境界にせず、実行イベントログの機械判定で検証する
• 910 外部のAI開発プラクティスは要素分解し、対象工程の実在を成果物の実測で確認してから取り込む
• 822 外部・可変な契約はコードコメントでなく一次情報で再照合してからレビュー判断する
• 851 設計ドキュメントは仮実装のcommit値を『現状』として書かず、実測を設計入力に採用する
• 782 ゼロ件の良好メトリクスは検知母数を併記しないと実績と解釈しない
• 898 固定コンテナ経由でテストを流す構成は worktree の変更を検証せず『テスト通った』誤報を生む
• 912 開発手法は『設計成熟度』と『実証成熟度』を分けて評価する

検知器（テスト基盤・検証スクリプト・パーサ・品質ゲート）の変更を第三者（別ベンダーの AI レビュアー・read-only sandbox のレビュー環境）に検証させる運用では、検体ハーネスが実行時に一時ディレクトリや作業ファイルを書き込む作りだと、read-only 環境で起動すらできず、独立実行検証が実装者の証跡の静的照合へ縮退する。

運用

• 故意ずれ検体（synthetic な壊れ入力）は、生成スクリプトで事前に fixture ファイルとして固定し、検証ハーネス本体は読み取りと外部プロセス起動だけで完結させる（書込ゼロ）。
• 生成スクリプトは検体の出自・意図の記録として fixture と並置して残す。検体一式はレビュー完了まで削除しない — 独立検証は残存する検体で再現できることが前提。
• 実ログ由来の検体（切り詰め・実イベントログ）も同じ fixture ディレクトリに置き、synthetic と同列に列挙する。

なぜ

検知器の false green は静的読解では見抜きにくく、検証の価値は「レビュアーが自分で実行して合否を再現できる」ことにある。ハーネスの書込依存はこの独立性を環境要因で壊す。実装者側は書込可能な環境で動くため、この欠陥は実装者の自己検証では顕在化せず、レビュー段階で初めて発覚する。

検証

ハーネス作成後に、書込系 API（一時ディレクトリ作成・ファイル書出し）への参照がゼロであることを機械確認し、可能なら read-only 制約下で1回実行して exit 0 と全件合否を確かめる。

コマンド監査・アクセス判定など、入力を構文解析してから許可/違反を分類する検査では、「解析できなかった入力」を info 扱いで素通りさせると、複雑なクォート・ラッパー形式の入力が検査の死角（false green）になる。逆に正当な定型実行を許可する仕組みが無いと、毎回人手の裁定が要る false positive が決定論的に再発する。

判断基準

• 分類を三値にする: 解析済み違反（deny 一致）/ 解析済み許可（allow 一致は info 列挙に留める）/ 解析不能（クォート不均衡・ラッパー形式なのに中身を取り出せない等）。
• 解析不能は allow 判定より優先して違反に倒す。何が実行されたか検証できない入力を許可しない — 許可の前提は解析の成立。
• 過検知（読み取り専用の複雑クォートコマンドが違反扱いになる等)は許容し、逸脱記録・人の確認で吸収する。素通りの温存より安い。
• allow パターンは検査の呼び出し文脈ごとに狭く渡す（この検査で正当と分かっている実行だけに一致する形）。恒常の広い許可は監査の骨抜きになる。

なぜ

解析器の能力を超えた入力は「違反が無いことを確認できた」のではなく「確認できなかった」。この2つを同じ合格に潰すのが素通りの正体で、意図的な難読化にも同じ経路が使える。

検証

故意ずれ検体を最低4クラス用意する: 解析不能に隠れた実行系（違反になること）/ allow 一致の正当実行（許可されること）/ allow 非一致の実行系（allow を渡しても違反のままであること）/ allow に一致し得る解析不能（許可されず違反になること＝優先順位の検証）。

イベントログ等から復元した実測値（実働時間など）を、別系統の参照値（フレームワークが報告する所要時間など）との乖離率で検算する設計では、両系の観測範囲が揃っていないと、測定自体が正しくても乖離が大きく出て採用不能（欠測）になる。

判断基準

• 参照値が「完了した単位」だけを報告する系なら、実測側も完了した単位に含まれる分だけを検算の分子にする。進行中の単位・完了記録の欠けた単位は、集計本体には残しつつ検算からは両側対称に除外する。
• 同じ単位が二重に報告される系（入れ子・重複レコード）では、計上済み範囲と重なる報告を検算から除外し、同じ壁時計を分母へ二重計上しない。
• 除外は必ず分子・分母の両側から対称に行う。片側だけ除外すると検算自体が偏る。
• 対象単位がゼロのときは検算不能（null）として fail-closed に扱い、0% 一致と混同しない。

なぜ

乖離の原因が「測定のバグ」か「観測範囲の差」かを検算は区別できない。範囲差を放置して閾値を緩めると、本物の測定バグ（桁違いの乖離）を検知する唯一のガードを失う。範囲を揃えれば閾値は厳しいまま維持できる。

落とし穴

• 作業の進行中に実測する運用（完了前の記録）では、最後の未完了単位が実測側にだけ入る。この型は完了後に測り直すと乖離が消えるため、実測タイミング依存の再現困難な欠測に見える。
• 文言・運用ルールの改訂では直らない。計測器側の検算設計の問題として扱う。

検証

実ログを単位の途中で切り詰めたスナップショットを故意ずれ検体にする: 範囲を揃える前の検算は大きく乖離し、揃えた後は閾値内に収まることを対で確認する。入れ子報告の検体では、二重計上時の期待値と除外後の期待値を両方固定する。