Atsushi Nakatsugawa
June 26, 2026
2 min read
What we got wrong about code reviewの意訳です。
コードレビューについて、私たちは大きなことをひとつ誤解していました。課題はスピードだと思い込んでいたのです。AIがチームのコード作成を速くしてくれれば、レビューはこれまでと同じく、マージ前にバグ、スタイル、エッジケースを確認する最後のチェックであり続ける、と考えていました。
その前提を疑う人はいませんでした。だからこそ、コードがより速く、より大量に届くようになると、レビューは気づかないうちにボトルネックになりました。そして、その解消は、たまたま問題に気づいた誰かに委ねられることになりました。誰もその状況を想定していなかったからです。
その考え方は、人間が今もコードの主な作り手である世界のものです。しかし、もはやそれは成り立ちません。MicrosoftのSatya Nadella氏は、現在では同社のコードの最大30%をAIが書いていると述べています。また、GoogleのSundar Pichai氏も、同社の新しいコードの30%超をAIが生成していると述べています。
企業やオープンソースプロジェクト全体で、これは新しい当たり前になっています。低コストでコードを生成できることは魅力的ですが、AIエージェントはいまや、誰もレビューしきれないほどの速度でコードを書いています。ましてや、それを十分に信頼するのは、さらに難しい状況です。
人間のレビュアーはその量についていけません。そして、生成されたコードが主張どおりに動くかを検証するためのツールは、コードを書くモデルほど急速には成熟していません。その結果、誰も十分に理解していないコードがリリースされる機会が増えています。
CodeRabbitは創業以来、コードレビューの自動化と、AI生成コードに対するより優れた意図分析の提示を重視してきました。レビューの本質は変わっていません。チームが理解、信頼、認識合わせを築く場であることに変わりはありません。変わったのは、人がそこに割ける時間の量です。
AI生成コードを単なる最後のチェックポイントとして扱うには、リスクが大きすぎます。CodeRabbitは、チームがより速く問題を見つけられるようにする自動コードレビューツールとして始まりました。しかし、AI生成コードの量が増えるにつれて、より難しい課題がはっきりしてきました。レビューはスピードだけの問題ではなく、開発者が自分たちのリリースするものを理解し、信頼できているかどうかの問題でもあります。
だからこそ私たちは、単に自動レビューを速くするだけでなく、レビューを行う人たちを支援する方向へ進んでいます。開発者が手動レビューをより速く進めながら、そのプロセスが守るべき理解と信頼を失わないようにしたいのです。
私たちは、エージェント型SDLCに合わせてコードレビューインターフェースを再設計しました。コードを書いたのがAIエージェントであっても人であっても、開発者が何が変わるのか、なぜそれが重要なのか、どこにリスクがあるのか、そしてこれから何がリリースされようとしているのかを把握できるようにするためです。
この2年間、業界は最も目に見えやすいブレイクスルーであるコード生成を最適化してきました。その取り組みがどこに向けられてきたかを見れば分かります。ベンチマークはコーディングタスクを中心に作られました。新世代のモデルが登場するたびに、AIエージェントがより複雑な問題を解けるようにすることが追求されました。
そこに注力するのは自然なことでした。変化が劇的で、すぐに分かるものだったからです。それが本当にチームの生産性を高めているかは、今も明確には捉えにくいままです。しかし、リリース速度が変わったことは明らかです。1人の開発者が、同じ時間で以前よりはるかに多くのものをリリースできる可能性が出てきました。Stack Overflowの2025年開発者調査によると、現在84%の開発者が開発プロセスでAIツールを使用している、または使用する予定があると回答しています。これは、AI支援によるコーディングがもはや一部の特殊なワークフローではないことを示す明確な兆候です。
しかし同じ調査では、46%がAI出力の正確性を信頼しておらず、45%がAI生成コードのデバッグには時間がかかると回答しています。市場があまりにも早く通り過ぎてしまったのは、この部分です。OpenAIやAnthropicのような企業はコード生成を変えましたが、リリースされるコードを理解する仕組みは同じ速さでは追いついていません。
そのギャップは、コーディング速度だけでなく、ソフトウェアライフサイクル全体に目を向けるとさらに明確になります。Atlassianの2025年開発者体験調査によると、99%の開発者がAIツールによる時間短縮を実感しており、68%は週に10時間以上を節約しています。一方で、50%は組織上の非効率によって毎週10時間以上を失っています。
エンジニアリングチームを最も引き止めているのは、情報を探すこと、新しい技術への適応、そしてツール間のコンテキストスイッチです。だからこそ、「AIによってエンジニアが速くなった」という話だけでは不十分です。AIは、チームが無理なく理解できる量を超えた作業を生み出しやすくもしたのです。
CodeRabbitのデータからも、そのトレードオフがプルリクエスト内でどのように現れるかが分かります。実世界のオープンソースPR470件を分析したAIと人間によるコード生成の現状レポートでは、AI生成PRには人間が書いたPRと比べて平均で約1.7倍の問題が含まれていました。ロジックと正確性に関する問題は75%増え、セキュリティ脆弱性は1.5〜2倍、可読性の問題は3倍超でした。ここから得られる最大の示唆は、コードは本当に信頼できるようになるずっと前から、もっともらしく見えてしまうということです。
生成されるコードの量が増え、レビュアーが変更を検証するだけでなく、その背景まで再構築しなければならなくなると、このモデルは破綻し始めます。現場で問われるべきことは、もはやコードが検査を通るかどうかだけではありません。チームの誰かが、その変更が何をしているのか、なぜその方法で作られたのか、どこにリスクがあるのかを理解しているかどうかです。
信頼の問題によって、レビューは狭いチェックポイントから、はるかに広い役割へと変わります。Google Cloudの2024年DORAレポートによると、回答者の75%超が少なくとも1つの日常業務でAIに頼っています。一方で、39%はAI生成コードをほとんど、またはまったく信頼していないと回答しています。チームが出力をそのまま信頼できないのであれば、レビューはソフトウェアを前に進める前に、意図、品質、確信を作り直す場になります。
現在のレビューには、チームが差分全体をリバースエンジニアリングしなくても何が変わったのかを理解できるように、説明可能性を生み出すことが求められます。レビュアーが実装と示された意図が一致しているかを判断できるように、信頼を生み出すことも必要です。さらに、関連する課題、下流システム、セキュリティ上の懸念、フォローアップ作業が、コードとそれをめぐる会話の間で埋もれないように、連携を生み出さなければなりません。
ライフサイクル全体の摩擦に関するAtlassianの調査と、AI生成PRにおける欠陥率に関するCodeRabbitの調査結果は、どちらも同じ結論を示しています。制約になっているのは、アウトプットを増やすことではなく、理解を深めることです。
ここでエージェント型SDLCは、曖昧な言葉ではなく有用な説明になります。ライフサイクルはもはや、チケットからコード、レビュー、マージへと人間だけが受け渡していく単純な流れではありません。エージェント型のライフサイクル全体がエージェントによって形作られるようになると、レビューは最後のゲートではなくなります。チームが意図を取り戻し、本当にリリースの準備ができているものを判断する共有の場になるのです。
コードレビューは、ソフトウェア開発を少なくともある程度は共同作業にするための強制力でした。しかし、AIエージェントが生成するコードは、LLMに対して人々がすでに不信感を抱いている特徴と同じものを持つことが少なくありません。自信満々の幻覚、しつこい誤り、説明不足、そして共有コンテキストへの理解の欠如です。
CodeRabbitは、エージェント時代のために作られた協調型AIプラットフォームです。私たちのコンテキストエンジンは、コードベース、規約、チームの過去の意思決定を理解します。そのためレビューは、汎用的なモデルの振る舞いではなく、あなたのチームがソフトウェアを作る方法に基づいたものになります。
この基盤は、次の3つの場面に表れます。
違いを体感したいなら、シンプルなプロンプトをひとつ試してみてください。コーディングエージェントに「協力して」と伝えるのです。次のPRでCodeRabbit Reviewを試してみてください。すべてのCodeRabbitユーザーが期間限定で無料で利用できます。CodeRabbitのPRサマリーコメントにあるReview Change Stackをクリックすると見つけられます。
