もう一人の目でレビューし、指摘を仕分ける

前のレッスンで、Claudeの報告と差分を自分の目で突き合わせる習慣を扱いました。ただ、同じセッションの中で書いたコードを、同じセッションの中で見直すのには限界があります。書いた本人は、書いたときの前提や判断をそのまま引きずってレビューしてしまうためです。

このレッスンでは、記憶を持たない別の目を入れる方法と、出てきた指摘をどう扱うかを扱います。

/code-reviewでもう一人の目を入れる

/code-reviewは、いまの差分やPR番号・ブランチ・パスを指定して、正しさに関わるバグを探すコマンドです。ローカルで実行すると、独自のコンテキストウィンドウを持つバックグラウンドのサブエージェントとしてレビューが動くため、自分のセッションの会話履歴を汚しません。レビューが終わると、指摘だけが会話に戻ってきます。

$/code-review
差分をバックグラウンドでレビュー中…
3件の指摘が見つかりました

このレビューには、確信度と網羅性を切り替えるeffortレベルがあります。lowやmediumでは確信度の高い指摘だけに絞り、highからmaxにかけては見つかる範囲が広がる代わりに、確信の薄い指摘も混ざってきます。レベルを指定せずに実行すると、前回自分が打ったレベルがそのまま引き継がれます。見つけた指摘をそのまま作業ツリーに反映させたいときは、--fixを添えます。

/code-reviewが探しているのは、正しさに関わるバグと、重複や単純化・効率化の余地です。見た目の好み（インデントの揃え方など）を細かく指摘するための道具ではありません。効率よく使うなら、まず正しさに関わる指摘だけを見て、見た目の好みは別の機会にまとめて整える、という線引きをしておくと消耗しません。

指摘を3つの山に分ける

レビューが返す指摘は、すべて同じ重さで扱う必要はありません。直す・尋ねる・そのまま置くの3つに仕分けると、対応の優先順位がはっきりします。

3つ目の「そのまま」を選ぶこと自体は怠慢ではありません。すべての指摘を直そうとすると、必要のない抽象化や過剰な防御コードが増え、かえって読みにくくなることがあります。軽微な指摘を「そのまま」に置く判断も、レビューの一部です。

レビュアーも間違えることがある

「尋ねる」の山が必要なのは、レビュアーが常に正しいとは限らないからです。たとえば、すでに入力値を整えている箇所を指して「値が整えられていない」と指摘してくることがあります。この場合、指摘をそのまま直しに行くのではなく、「この箇所はすでに整えているはずですが、どの入力を想定した指摘ですか」と尋ね返すと、レビュアー側の誤りだったのか、自分が見落としていた別の入力があったのかがはっきりします。

指摘を鵜呑みにして直しに行くことも、指摘を無視することも、どちらも近道に見えて遠回りです。尋ねるという一手間が、結局いちばん早く正しい対応にたどり着きます。

やってみよう

演習1：直近の指摘を3つの山に仕分ける

直近で/code-reviewや誰かからもらった指摘を思い出し、直す・尋ねる・そのままの3つに仕分けてみましょう。「そのまま」に置いた指摘があれば、なぜいま直さなくてよいと判断したかも一言添えてください。

演習2：「尋ねる」に対する問いかけを1つ書く

「尋ねる」に分類した指摘のうち1つを選び、実際に送る問いかけの文を書いてみましょう。「なぜそう判断したか」だけでなく、自分がすでに確認済みの情報も添えると、やり取りが1往復で終わりやすくなります。

今日のまとめ

3行で振り返ります。

• /code-reviewは独自のコンテキストを持つサブエージェントとして動き、自分のセッションの会話履歴を汚さずにもう一人の目を入れられる
• effortレベルは確信度と網羅性のトレードオフで、レベルを指定しなければ前回の設定が引き継がれる
• 出てきた指摘は直す・尋ねる・そのままの3つに仕分け、レビュアーの誤りもありうる前提で「尋ねる」を使う

次のレッスンでは、自分用のカスタムサブエージェントの作り方を扱います。