ほとんどのAIコードレビューツールでプルリクエストを開くと、コメントの壁が現れます。指摘一つにつき一つ。細かい指摘一つにつき一つ。「これはヘルパーに切り出した方がいい」につき一つ。修正をプッシュしてレビューを再実行すると、最初の壁の上にもう一つの壁が積み上がります。今度はチームメイトが、本当に重要なコメントを見つけるために2枚の壁をスクロールする羽目になります。
Surmado Code Reviewは違う動き方をします。1つのPRに、1つのコメント。再実行しても、同じコメントがその場で編集されるだけです。
仕組み
Scoutがプルリクエストをレビューすると、すべての指摘は1つの構造化されたコメントにまとまります。上部に重要度別の区分。その下に指摘事項そのもの。最後に短いブリーフがあり、人間のレビュアーがまずどこを見るべきかがわかります。
修正をプッシュして /rerun-review とコメントすると、Scoutは2つのものを読みます。
- 新しい差分。
- 以前投稿したレビュー。
そしてScoutは同じコメントをその場で編集します。修正済みの問題は解決済みとしてマークされます。修正されていない問題は、以前指摘されたものだという注記付きで再度フラグが立ちます。新しいコードで見つかった新しい問題は下部に追加されます。
PRのコメントスレッドが膨らむことはありません。単一のレビューが、プッシュのたびに正確になっていくだけです。
なぜこれが重要か
PRのコメントスレッドは会話であるべきで、掲示板であるべきではありません。ボットが投稿する余分なコメント一つ一つが、チームメイトが本当に重要なコメントを見つけるためにスクロールしなければならないコメントになります。数サイクル経つと、誰もどれも読まなくなります。
これはCodeRabbit代替ツールについての記事やGreptileの分析記事で出てきたのと同じトレードオフです。検出率だけが指標ではありません。シグナル対ノイズ比も指標です。すべてを検出しても40個のコメントに埋もれさせるレビュアーは、何も検出しないレビュアーと実用的な価値がほぼ同じです。
「以前言ったことを把握している」という部分
その場で編集すること自体は一つの要素にすぎません。より難しいのは、再実行を短くするだけでなく役立つものにすることです。
Scoutの再実行は、以前のレビューに基づいています。最初のパスで「ある関数にPIIのredactionが欠けている」と指摘したなら、再実行ではその関数が今PIIをredactしているかどうかを具体的に見ます。「どこかにPIIの問題があるか」ではなく、「指摘したことが修正されたか」です。修正されていれば、その指摘は解決済みセクションに移動します。されていなければ、2回目の指摘であることを示すマーカー付きで未解決のまま残ります。
このフィードバックループがあるからこそ「1つのコメント」が機能します。コメント自体が自分の履歴を持っています。以前何が指摘されたかを覚えておくために、ボットコメントの時系列スレッドは必要ありません。現在のコメントがすでに知っています。
実際にどう見えるか
PRをプッシュします。Scoutから1つのコメントが返ってきます。御社のSTANDARDS.MDにあるルールに基づいたものです。それを読みます。重要な部分を修正します。もう一度プッシュします。/rerun-review とコメントします。同じコメントが、何が解決したか、何がまだ未解決か、何が新しいかを反映して更新されます。新しいスレッドはありません。「17回通知されました」もありません。
このツールがどう作られたかの長い話が読みたければ、vibe-codingについての記事で、私たちが手作業で作った部分とScoutに任せて作らせた部分について書いています。
結論
PRのコメントスパムは機能ではありません。他のツールが身につけた習慣です。コメントを増やす方が、どれが重要かを知るより簡単だからです。
Surmado Code Reviewはそれをやりません。1つのコメント。再実行で編集。以前言ったことを把握しています。
Surmado Code Reviewを試す、月額$15。100PR。御社のSTANDARDS.MD。チームメイトが開く前に、すべてのPRで。