deep-audit

深層敵対的監査

時間のかかるラウンドごとのレビューに代わる、収束性の高い方法です。各パスで1人のレビュアーが1、2件の問題を見つけるのではなく、多数の独立した懐疑派に成果物全体を一斉に調べてもらい、見つかった問題を判定し、確認されたものをすべて修正して、再検証します。難易度の高い形式的証明の取り組みで使われるマルチエージェント手法（多様で独立したポートフォリオ、全行程を通じた敵対的検証、具体的な証拠のみ、統合・反証・反復）をモデルにしています。

どんな場合に使うか

• 成果物が十分に複雑で、1回のレビューではパスごとに新たな問題が見つかり続ける場合（これはラウンドごとのレビューが適切でないことを示しています）。
• 正確性が最優先で、欠陥を見逃した場合のコストが高い場合（トップカンファレンスに投稿する論文、証明、セキュリティ上重要な変更、移行など）。
• ユーザーが「全部修正して」「もっと深く」「もっと早く収束させて」「100％盤石にして」と依頼した場合。

ユーザーがマルチエージェント・オーケストレーションを利用することに同意している必要があります（ワークフロー／深層監査／エージェントの並列実行を依頼した、または ultracode が有効になっている場合）。同意していない場合は、まず提案し、おおよそのコストを伝えてください。

手法

1. 分解する（多様なポートフォリオ）。 成果物をセクションではなく、アイデアごとにコンポーネントへ分割します。独立した主張、補題、推定器、サブシステム、不変条件などが対象です。横断的な失敗モードの観点（後述）も加えます。すべての根幹となる主張が、その主張を直接調べる少なくとも1人のエージェントに検証されるよう網羅性を確保してください。エージェントには、自分が有力だと考える解釈を伝えないでください。独立性を保ち、全員が同じ魅力的だが誤った結論に収束するのを防ぎます。

2. 敵対的な検出担当を並行実行する（コンポーネントごとに1人）。 各検出担当には、まず「バグがある」と考えて反証するよう指示し、すべての主張を実際のテキスト／コードに基づかせます（記憶から言い換えるのではなく、実際に読んでください）。有効な手法から得られた厳格なルールは次のとおりです。

• 具体的な指摘のみ。 指摘にはすべて、正確な場所（ファイル名:行番号／ラベル＋引用テキスト）、1文での欠陥の説明、失敗ケース（具体的な入力／設定から誤った出力に至る例、または正確に不足している仮定）を含めます。
• 状況報告、「問題なさそうです」、「これは標準的／定型的です」といった報告、曖昧な楽観論、「全体のステップは簡単です」といった主張は却下します。
• 同じ難しさを別の場所に持ち込む修正や、自らの結論を前提にする修正は、修正ではありません。そのようなものは指摘してください。
• 十分に検証しても何も見つからなかった場合は、エージェントは実施した具体的な検証内容と、それぞれの検証で問題が解消された理由を示さなければなりません。「問題なし」だけでは不十分です。

3. すべての指摘を判定する（独立した判定担当）。 別の判定担当が引用された箇所をそれぞれ再確認し、成果物と指摘の両方を疑いながら、CONFIRMED / REFUTED / DOWNGRADED のいずれかに判定します。これにより、誤検知（読み違い、別の場所に実際は存在する仮定、記載された条件では発生しない失敗ケース）を排除します。このステップによって、修正リストの信頼性を保ちます。

4. 統合する。 場所ごとに重複を除き、致命的 > 重大 > 軽微の順に優先順位を付け、整理された欠陥リストを1つにまとめます。この段階を通過するまでは、問題として認めてはいけません。

5. 確認されたものをすべて修正し、その後再検証する。 確認された修正をすべて適用します（修正には慎重さと判断が必要なため、メインループで行います）。その後、変更した箇所を再監査し、修正によって新たな欠陥が生じていないことを確認します。監査パスが2回連続で空になるまで、検証を繰り返します（上限は5ウェーブ。ウェーブNとN+2の両方で残った指摘は、3回目の修正に進まずユーザーに伝えます）。最初のウェーブの後に止めないでください。

失敗モードのレンズ（領域に合わせて適用）

コンポーネントごとの攻撃に加えて、次の横断的なモードを明示的に確認してください。実際の欠陥はこうした箇所に潜んでいます。

• 過大な主張： 見出しや要旨が、定理やテストで実際に示されている以上のことを主張している。
• 証明における適用範囲の拡大： 点ごとの結果を必要な箇所で一様な結果として使う、両方が正しい場合の性質を限定条件なしで述べる、特殊ケースの議論を一般論として適用する。
• 暗黙の仮定： 微分可能性・密度・連続性・有界性・正値性の条件を（数学で）使っているのに明記していない、または（コードで）前提条件や不変条件を確認していない。
• エッジケース： 原子・同順位、端点・非有界なサポート、空または退化した入力、パラメーター空間の境界。
• 循環性： 結論そのものを前提としている仮定、自分自身を引用する結果、主張より範囲の狭い内容しか示していない引用（引用元を確認する）。
• 内部矛盾： 定義や記法を二通りの意味で使用している、表のセルが命題と矛盾している、本文と付録の不一致、参照先がない、または誤った相互参照。

新鮮な目での監査（最終ゲート）

対象を絞った各監査では、プロンプトを作成した人の見落としを引き継ぎます。注目箇所のヒント、修正履歴、想定される失敗モードのすべてが、監査担当者の意識を既知の領域に向けるためです。対象を絞った監査と修正をすべて終えたら、ほとんど予備知識を与えずに、先入観のない監査を一度実施してください。 独立した監査担当者に、対象物と最小限の指示（「具体的な欠陥を見つけること：箇所＋失敗するケース」）だけを渡し、クラスタの割り当て、履歴、特別な注目箇所の一覧は渡しません。変えるのは着手点だけにします（ジャーナルの査読者のように本文から始める、付録から始める、表や主張から始める、監査担当者が選んだ単一の箇所を深く調べる）。判定は通常どおり行います。先入観のない監査で指摘がなく、対象を絞った確認にも漏れがなく、機械的テスト一式がすべて成功していることを完了基準とします。先入観のない監査で、対象を絞った監査が見落とした指摘が見つかった場合は、プロンプトの構成にも問題があることを示しています。見落とされた失敗モードをレンズに追加してください。

完全な一覧 — 抽出して確認しない

論文や証明の成果物では、まずすべての形式的な主張を列挙し（\begin{theorem|proposition|lemma|corollary} とラベルを grep する）、各証明を検証担当者に割り当てます。負荷を担う主張は「査読者が選んだ少数の証明」ではなく、100％を確認する必要があります。サンプリングの収束は線形かつ確率的ですが、一覧の作成は一度の監査で完了します。密接に関連する小さな補題はクラスタにまとめ、大きな証明には個別の検証担当者を割り当てます。各検証担当者は、指摘事項に加えて、検証済みのステップの一覧と仮定の台帳（使用したものと明記されたものの比較。使用しているが明記されていない仮定は指摘事項とする）を提出します。

機械的テスト一式（最も効果の高い確認）

文章による議論は正しく見えても、定義された対象が間違っていることがあります。推定方程式、影響関数の恒等式、識別に関する主張、母集団モーメントのすべてについて、敵対的な玩具設計を使って母集団対象を計算する実行可能なテストを書いてください。対象には、打ち切り（打ち切りの終点が結果の終点より小さい場合）、内部の原子、誤指定されたナイサンス、境界・オーバーラップの失敗を含め、主張されている中心化や恒等式が数値的に成り立つことを検証します（解析的に、または固定シードを使った高密度グリッドや大規模 N で確認します）。スクリプトは README とともに、リポジトリ内の永続的なテストディレクトリに保存してください。対応する式を変更したら、必ず再実行します。母集団を計算する 5 行のコードで、注意深く読んでもモデル間の合意を得ても確実には見つけられない種類の欠陥（裾で再正規化された根、符号の反転、質量不足による重み付け）を検出できます。

修正時の衛生管理

• 修正で新たに導入した数学は未監査の数学です。 修正を行う各ウェーブの後は、完了と宣言する前に、修正箇所だけを対象とした検証ウェーブを実施します。
• ワークフローの統合では、指摘事項と判定を INDEX で対応付けてください（判定者には、指摘事項と同じ順序で判定を返すよう求めます）。箇所の文字列で対応付けてはいけません。判定者は箇所を言い換えるため、気付かないまま項目が抜け落ちるからです。対応する対応を取る前に、統合した要約を監査記録と照合してください。

ブロックされた経路も結果です

明示された前提のもとでコンポーネントを修正できない場合、それは監査の失敗ではなく、所見です。残っている不足点（欠けている仮定や破綻している手順を正確に）と、率直な選択肢（主張を弱める、仮定を追加する、対象範囲を限定する）を報告してください。都合のよい解釈を探してはならず、定理の強度に関わる不足をエージェントに「定型的な作業」として取り繕わせてはなりません。

オーケストレーション

• 1つのメッセージで Agent を並列に呼び出して作業を振り分け（コンポーネントごとにファインダーを1つ）、次にコンポーネントごとに1人のジャッジがそのコンポーネントの所見をすべて審査し、その後に統合します。詳しくは orchestrator-protocol.md を参照してください。Workflow ツールが利用できる場合（例：ultracode セッション）、pipeline(components, finder, judge) は、ファインダーの結果が戻り次第、そのコンポーネントを即座に審査する高速化手段として任意で使えます（全ファインダーの完了を待つ必要はありません）。これは必須ではありません。確認済みのリストを返し、その後の修正は自分で行ってください。
• モデルの役割分担： ファインダーには、強力な実行・分析モデル（発見して攻撃する）を、ジャッジには強力な裁定モデルを使います。ローカルの規約 model-routing.md に合わせてください（ここでは両方の役割に Opus ティアを使い、ティアを変える前にジャッジへより多くのエフォートを割り当てます。Fable ティアはセッションごとの選択であり、フリート全体のデフォルトではありません）。審査予算を節約するため、ジャッジはコンポーネントごとに1人とし、そのコンポーネントの所見を一度にすべて裁定させてください。
• 最後までやり遂げてください。 「最善の努力」や、難しい理由の一覧を返してはいけません。確認済みの欠陥を返してください（修正後はクリーンな再監査結果も返してください）。それができない場合は、残っている最も重大な不足点を1つだけ正確に述べてください。

プロンプトのひな形

ファインダー：「あなたは、1つのコンポーネントを監査する敵対的な査読者です。{locations} にある実際のテキストを読んでください。攻撃対象：{failure modes}。具体的な所見のみを返してください（場所＋欠陥＋失敗するケース）。『問題なし』『定型的な作業』や曖昧な記述は不可です。難しさを再び持ち込む修正は修正とはいえません。問題がなければ、実施した具体的な攻撃と、それぞれがどのように退けられたかを列挙してください。」

ジャッジ：「敵対的な査読者が、コンポーネント X について以下の所見を返しました。それぞれについて、引用された箇所を開き、テキストに実際に書かれている内容と証明を照合して、CONFIRMED／REFUTED／DOWNGRADED のいずれかを付けてください。成果物と所見のどちらも鵜呑みにしないでください。」

共通の原則は一箇所にまとめる

この監査が前提とする次の3つの事項は、ここでは繰り返しません。ほかのすべての検証箇所で同じ規則を使うためです。3つ目のコピーを作ると、内容にずれが生じます。

• シード済み障害による較正 — 埋め込まれた欠陥を検出できていないチェックには、何の保証もありません。 → /vaccinate と verification-ladder.md の段階0を参照してください。
• 独立性と相関誤差 — モデル同士の一致は確認にはなりません。同じように誤る可能性があります。→ verification-ladder.md の段階3を参照してください。
• 5つの信頼性に関する問い — 1つに対する証拠が、ほかの問いまで解決することはありません。 → external-oracle-process.md §6 を参照してください。

このリポジトリ自体の監査

リポジトリ基盤への適用（サーフェス同期、スキル／エージェント／ルールの整合性、フックとスクリプトのレビュー、ドキュメントと実態の乖離）については、 references/repo-infrastructure-audit.md を参照してください。 まず ./scripts/backtest.sh を実行してください。機械的なテスト群はすでに用意されています。スクリプトが判定できることを、エージェントが手作業で確認してはなりません。