開発者が30秒でバグを承認する瞬間を目撃しました

How Developers Actually Review Code in 2026の意訳です。

最近、CodeRabbitのapp.jsカンファレンスブースで、コードレビューをスピード勝負のゲームにしました。app.js、JS Nation、React Summitで、私たちは何百人もの開発者に、普段どのようにコードレビューしているのかを聞きました。返ってきた答えは、そのゲームよりずっと笑えないものでした。

ルールはシンプルです。画面にコードスニペットが表示され、参加者はスマートフォンから30秒以内に承認するか、変更を依頼するかを選びます。

正解が早いほど高得点なので、プレッシャーの中で判断することになります。投票が締め切られると、見落とされたバグとその修正内容を公開します。

各ラウンドでは、その時点のリーダーと最速で正解した人を紹介しました。そのため、賞品を持ち帰る上位3人だけでなく、より多くの人が「それ、自分だ！」と思える瞬間を得られました。

ラウンドを重ねるたびに、同じことが繰り返されました。バグが表示され、制限時間が進み、会場の一定数が自信を持ってそのコードを通してしまうのです。バグが「明らか」に見えるかどうかは、時間制限の中で見つけられるかどうかと、ほとんど関係がありませんでした。

その後、私たちは皆さんと話しました

3つのカンファレンスの期間中、そしてゲームの合間にも、私たちは何百人もの開発者と、普段どのようにコードレビューしているのかについて話しました。同じテーマが何度も出てきました。チームがコードレビューをどう捉えているかと矛盾するものが多いため、振り返る価値があります。

最初から組み込まれている

最もよく聞いた構成は、コードホスティングサービスに同梱されているレビューボットを使うというものでした。すでにPR内にあり、開くタブが1つ減るからです。

その理屈はわかります。コードレビューにおける、オフィスの冷蔵庫に入っているサンドイッチのようなものです。そこにある一方で、レストランまでは少し歩かなければなりません。ただ、そう話してくれた開発者の多くは、同じ会話の中で、レビューがリリースまでのボトルネックの1つだとも言っていました。

何かが本当にチームの足を引っ張っているなら、それを解決するはずのツールに対して「最初から入っていたから」という基準を置くのは不思議です。

私たちは、その基準は引き上げる価値があると考えています。コードレビューは、類語辞典を持ったLinterではなく、チームメイトが残したコメントのように読めるべきです。そして、リポジトリ側をツールに合わせるのではなく、ツールがリポジトリに合わせて振る舞うべきです。コードレビューに関わるすべては、レビュー品質を中心に作られるべきです。

エージェントが問題ないと言ったなら、問題ない

私たちが話した開発者のかなりの割合は、コードを書いたのと同じコーディングエージェントでコードレビューもしていました。専用のレビュー工程としてではありません。ツールがすでに開いていて、そのツールがコードを書いたので、そのままコードの確認も任せているのです。

私たちが懸念しているのは、エージェントが回答した後に起きることです。何も起きません。エージェントが判断を下し、開発者はそれを受け入れます。反論も、追加の質問も、掘り下げる余地もありません。やり取り全体が一方向に進んでしまいます。

その結果、判断はコード生成のために作られたツールへ委ねられます。プルリクエストについて対話するためのツールではありません。そして、その対話すらそこで止まってしまいます。

レビューは本来、やり取りを重ねるものです。そのまま受け取るだけなら、手元にあるのはおみくじのようなものです。

もっと安くて良いものを自分で作れる

次に出てくるのが、自社で作ろうとする開発者です。モデルはすぐそこにあり、APIは安い。どれほど難しいというのでしょうか。空いた1日を何度か使えば、専用ツールが請求する金額の一部で、自社スタックに合わせたレビュアーを作れるはずだ、と考えます。

これは簡単な作業ではありません。

ここで同じ話を一から繰り返すつもりはありません。すでに詳しく書いています。社内AIコードレビューツールのコストは、あなたが思っているより高いという記事です。要点だけ言うと、モデル呼び出しは安い部分です。高くつくのはその周辺すべてです。コンテキスト設計、diffのすべての行に指摘を出さないためのノイズ抑制、各種連携、メンテナンス、そして本来リリースすべきプロダクトではなくコードレビューツールに費やされるエンジニアの月単位の工数です。「コストの一部で済む」という計算は、人件費を入れない場合にしか成り立ちません。

自分で作ることは、難しいのはAIではなかったと学ぶための、最も高くつく方法です。

カンファレンスの開発者全員が同意したこと

ツールをめぐる議論を取り除くと、誰も反対しなかった考えが1つありました。

私たちは、手作業ですべてレビューするにはあまりにも多くのコードをリリースしています。もうその段階は過ぎており、以前のやり方には戻りません。

エージェントが生成するコード量は増え続けており、当面減る気配はありません。開発者が手で書くコードは減っている一方で、レビューするコードはこれまでになく増えています。今や、それが開発者の仕事です。そして、それは難しい仕事です。diffは大きくなり続け、ときには認知負荷が高くなります。それでも私たちは、AI生成コードではなく人間が生成したコードを前提に作られたプラットフォーム上で、コードレビューを続けています。

AIコードレビューは、チームが十分成熟したら導入する「あれば便利」なものではありません。今、ソフトウェアをリリースする方法を支える土台です。私たちが定義しようとしているのは、そのカテゴリです。そしてこれは、カンファレンスで話し終える前から、誰もがすでに同意している珍しいテーマでもあります。