AI 協働の実装プロセスで、レビュー回数・監査装置（証跡パッケージ・帳簿・収束ループ）の密度を一律にすると、内部ツールにも規制産業級の固定費が掛かり壁時計が支配される。密度は変更の爆発半径（不可逆性×外部影響の大きさ）だけに比例させる。

段階化の判断基準

• 挙動に触れない → 機械ゲートのみ（レビューなし）
• 通常の変更（デフォルト） → 出荷前レビュー 1回、must 相当のみ即対応し should/nit は蓄積して後続バッチ。残存 edge case は「使って直す」ループ（fail-closed な品質ゲートと摩擦記録）を受け皿にする
• 高リスク面（認可・並行処理・migration・境界間契約）や検知器の新設 → 異種レビュアを各1回（収束ループなし）。修正後の再レビューは機械ゲートで代替
• 不可逆（復旧不能なデータ変更・公開後取り消し不能）×外部影響（公開 API・課金・第三者データ）が重なるときだけ、二者承認までの収束ループと監査証跡を使う。個人・小規模開発では年数回が正常頻度

根拠（実測と研究）

• 実測: 検知器新設タスクで本体実装 15〜20 分に対し、収束型二者レビュー（10R・差し戻し8回）とラウンド毎固定費で壁時計 5.7 時間。改善は R1→R2 に集中し R3 以降は逐減
• 研究と一致: LLM の反復修正は 2 ラウンドで利得の大半を取り以降逐減。人間のレビューでも大手の実践は大半の変更を1レビュアで回し、追加レビュアの限界価値は急減
• 収束型（指摘ゼロまで反復）は「フロンティアモデルは全文を再読すれば必ず何か実在の指摘を出せる」性質と組み合わさると構造的にラウンドが伸びる。停止条件に重大度の重みと限界コストの問いを入れない限り、品質向上の大半は初回で2回目までに得られている

落とし穴

• 設計合意の重さと実装工程の重さを結合しないこと。「設計文書を書いたから重いパイプライン」にすると、設計を丁寗にやるほど実装が遅くなる倒錯が起きる。設計合意（人間との対話）は重く、実装密度は爆発半径で、と独立に決める
• 軽量化の前提は受け皿：残存欠陥を拾う fail-closed な機械ゲートと、発見を改訂につなげる記録ループが無いままレビューだけ削ると品質が黙って落ちる