レビュー役のAIにコードを直させると、バグが無かったことになる — Claude Code サブエージェント4役の境界設計

AIのレビュー役に直させるたび、バグが「記録に残らない形」で消えていく——これは品質管理の視点では極めて危険だ。Claude Codeのサブエージェントを4役に分けて実装・レビュー・テスト・文書作成を回した112チケットの運用から見えてきた落とし穴である。

一見すると効率的に見える。コーダーが実装し、レビュアーが指摘を見つけ、テスターがテストを回し、ライターがドキュメントをまとめる——人間の職能をそのまま役割分担させただけだ。だが実際に動かすと、3役すべてが同じ罠に落ちる。見つけた問題を自分で直してしまうのだ。Reviewerが明らかな誤字を見つけて修正する。一見親切だが、その修正は記録に残らずコーダーのコミットに紛れ込む。誰もレビューしていないコードが、レビュー済みの顔をして入る。Testerがテストの失敗を見つけて実装を直す。テストは通る。でもバグが無かったことになる。後から品質を数えようとしても、数えるべき欠陥の事実そのものが存在しない。Doc Writerが設計書と実装の食い違いを見つけて設計書を直す。実装が間違っていた場合、その誤りが「正しい仕様」として文書に固定される。

問題は親切心ではなく、指示文だけでは役割分担が守られないということだ。効く対策はツール権限だった。Reviewerの定義からEdit権限を外す。そうするともう直す手段がない。指摘を記録ファイルに書き、Coderがそれを読んで直す流れだけが残る。ただしTesterとDoc Writerは編集が必要だから外せない。権限単位は粗すぎて、パス単位では制御できない。結局、指示文を厚くする——「勝手に直すな」「原因と対処を分ける」と何度も書く方法に頼った。

AIは指示を守る前に、守れない仕組みを敷くことだ。そしてその仕組みが「誰が最終決定者か」を定める。権限で囲めない部分は、人間が何度でも判断する覚悟が要る。中小企業がAIを内部システムに導入するなら、速く作る前に「何がコミットに残るべきか」を設計してから役割を割り当てよう。