AI レビュアーを「指摘ゼロまで反復」するループ運用で、レビュー出力が自由文だと、終了判定（総合判定の読み取り）と差し戻し対象の抽出（重大度別の指摘の拾い出し）がリーダー側の解釈作業になる。解釈は非決定的で、判定のブレ・見落とし・ラウンド間の指摘引き継ぎの要約劣化を生む。

判断基準

• ループ制御に使う信号（重大度別の指摘件数・承認可否・指摘の位置と推奨対応）は構造化出力で受け取る。実行系にスキーマ強制機能（CLI の output-schema 相当のフラグや structured output API）があるなら、スキーマで強制して不適合出力を構造的に排除する。
• 終了判定は要約的なフラグ（approve / needs-attention のような verdict）でなく、指摘配列の重大度件数で機械判定する。verdict と件数が矛盾した場合（例: needs-attention なのに blocking 指摘ゼロ）は fail-closed で継続側に倒し、不確実性を終了の根拠にしない。
• スキーマ強制機能の無い実行系（ヘッドレス CLI で出力形式フラグが無い等）には、プロンプトで同一スキーマの JSON のみを要求し、不適合時は再実行1回→自由文として読み取りへ段階フォールバックする。フォールバック発動は逸脱として記録し、常態化したら仕組み側を見直す。

落とし穴

• スキーマ定義ファイルを作業ディレクトリへ書き出して実行系に渡す方式で「無ければ作成」にすると、スキーマ改訂後も旧ファイルが渡り続けて機械判定と食い違う。毎回上書き作成にする。
• 出力形式の指示（JSON のみ・スキーマ適合）をレビュープロンプトの共通観点部に混ぜると、同じ観点リストを流用する別経路（ファイル出力しない対話型レビュアーなど、別の報告契約を持つ実行）に形式指示が流入して契約が衝突する。プロンプトは「観点」と「出力形式」に分離し、流用先には観点のみを渡す。

検証

• 矛盾ケース（verdict が承認なのに blocking 指摘あり／その逆）を想定し、どちらも継続側に倒れることを手順上で確認する。
• スキーマ改訂後の初回実行で、実行系に渡ったスキーマが新版であること（旧ファイル残存が無いこと）を確認する。