レビュアーは同じなのに結果が違う — AI実装の品質はレビューの手前で決まる

先に結論を書くと、AIが書いたコードの品質はレビュアーの賢さよりレビューの手前で決まる。コードを1行も書く前に人が設計を承認したか。人が最初に見るPRがすでに一度ふるいにかけられているか。この2つだ。読み終わる頃には、作業の大きさを見てどちらのやり方を使うか選べるはずだ。

もともとのやり方

長いことこうやって仕事をしていた。

Claude Code に「作って」→ 実装 → PR → レビューコマンド → 画面 Before/After キャプチャ

文言1つ、設定値1つを変える程度なら、これがいちばん速い。不満もなかった。

そこへ会社（RailsのSaaS）にAI実装ハーネスが入ってきた。ハーネスとは、AIに仕事をさせる順番と止まる場所をチームであらかじめ決めておく枠組みのことだ。

/plan → plan.md（設計要約）を人が読んで approved: true
  → /implement（git worktree で実装 → spec → rspec・rubocop
                → セルフレビュー → Draft PR → 事前レビュー → 自己修正 最大2回）
  → 人が Ready → 最終レビュー

最初に思ったのは正直これだった。「最終レビューは今まで使っていたレビューコマンドと同じレビュアーなのに、何が変わるんだ？」

並べてみると、差はレビューではなくその手前にあった。

分かれるところ

段階	「作って」	ハーネス
設計	会話の流れで暗黙に決まる	plan.mdで固定。人が承認するまでコードは0行
要件の読み方	チケットに書かれた解決策をそのまま実装しがち	「チケットの解決策を信じず上位の要件に戻れ」という段階が別にある
止まる場所	その日のセッション次第	ルールで4か所 — 設計承認・前提確認・マイグレーション直後・報告
spec	実装に合わせて後から書く	テストケース表の1行 = example 1つ
人が最初に見るPR	生のまま	事前レビューで一度ふるいにかけたDraft
「なぜこうしたか」	セッションを閉じると消える	plan.mdに残る

増えたのは自動化ではなく「止まる場所」

表を見直すと、ハーネスが足したのはほとんどが止まる地点だ。人が判断する場所をコードより前に引き寄せて、そこに固定している。

方向違いを書き終わったコードで見つけたら、そのコードは丸ごと捨てることになる。plan.mdの段階で見つければ、捨てるのは設計メモ1枚だ。どんなに良いレビュアーを使っても、このコスト差は埋まらない。

ハーネスはReadyとマージをあえてやらない。生成されたコードの責任はReadyを押した人にある。責任の境目をボタン1つに結びつけたわけで、ここはかなり気に入っている。

とはいえ上位互換ではない

画面確認が抜けている。 元のやり方ではBefore/Afterキャプチャが流れに入っていたのに、ハーネスには「画面の目視確認は人が行う」の一行しかない。画面が変わるPRだと、結局古い道具を後ろに付け足すことになる。

小さい作業には重い。 承認を省くモードはあるが、worktreeと事前レビューのコストはそのまま残る。

plan.mdを手で直せない。 手で直すと調査結果とずれたまま実装されるので、会話で作り直すことになる。地味に面倒だ。

ブランチが塞がる。 gitは同じブランチを2つのworktreeで同時にcheckoutできない。ハーネスがworktreeでブランチを握っている間に既存のレビューサイクルコマンドを回すには、先にworktreeを片付ける必要がある。

どちらを使うか

作業	選ぶ方
文言・設定値1つ	「作って」
やり方は自明、ファイルは複数	どちらでも。ハーネスなら承認省略モード
設計の選択肢がある・DB変更・影響調査が必要	ハーネス
画面が変わる	ハーネス + 最後にBefore/Afterキャプチャを付け足す

まだ測っていないこと

数字はまだない。同じ大きさのチケットを2つのやり方で1件ずつ回して、かかった時間とレビュー指摘数を比べるつもりだ。それまでは「方向違いをコードの前に捕まえる」というのはフローの構造上そうなっているという話で、実際に捕まえた事例で証明したわけではない。

プロンプトを上手に書くこととハーネスを組むことの違いは、ハーネス vs プロンプトエンジニアリングに別でまとめてある。

チームにAI実装の流れを入れようとしていて、どこで止めるかに迷っているなら、negabaroに相談してもらって構わない。うちも今まさにこの順番を実務で回しているところだ。