リーダーが実装をエージェントに委譲しレビューを裁くマルチエージェント運用では、リーダーの生成量のかなりの部分が中間報告・帳簿づけ（状況まとめ・完了報告・記録転記）に費やされる。実測ではリーダー出力の3〜4割が報告系で、これがセッションの体感速度を直接悪化させていた。判断に使われない詳細を報告から外し、置き場を移す運用ルールで、品質に触れずに高速化できる。

運用ルール

• 中間報告は差分のみ: 直前の報告から変わった事実だけを数行で書き、既報や全体状況の描き直しをしない。状態が変わらない通知（委譲先の待機通知・バックグラウンド処理の生存確認）への応答は1行。
• 指摘の本文は差し戻し指示にだけ書く: ユーザー向け報告には件数・重大度・処理先（差し戻し／直修正／棄却）のみ。同じ指摘を報告と差し戻しの両方に書く二重生成をやめる。
• 最終報告は要点のみで分量上限を決める: 変更一覧はコミット1件につき1行、検証結果は合否と件数、レビューは収束経過を1行（例: R1 must4 → R2 must2 → R3 ゼロ）。詳細は計画ドキュメントの完了記載・コミット・差し戻し指示に残す。

なぜこのレバーか（却下した代替案）

• 報告量の削減はレビューの検出力・設計品質に一切影響せず、どのモデルでも効く。
• 却下した代替案: オーケストレーション局面だけリーダーを軽量高速モデルに切り替え、代わりに文脈を持たない重モデルの検証エージェントを追加する構成。リーダー検証の検出力は会話文脈（設計議論の経緯を知っているから異常を診断できる）に依存しており、文脈なしの検証役への移管は守りたい品質を最も危険に晒す。さらに手動のモデル切り替えは忘れたときにサイレントに壊れ、指摘の裁定プロトコルなど層が増えて維持コストが上がる。「速いリーダー＋賢い検証役」より「賢いリーダーを寡黙にする」を選ぶ。

落とし穴

• 詳細の置き場（計画ドキュメント・コミットメッセージ・差し戻し指示）をセットで決めずに報告だけ削ると、情報がどこにも残らない。先に置き場を規定してから報告を絞る。
• 状態が変わったときの短報まで省くと進捗の可視性が失われる。削るのは再掲と二重記載であって、変化の通知ではない。

検証

導入前後のセッションログで、出力トークンに占める報告系の比率と実働時間を比較する。