CodeRabbitがClaude Marketplaceに登場！Learn more
Atsushi Nakatsugawa
June 23, 2026
1 min read
Adopt agentic engineering without losing your review loopの意訳です。
コード生成が安価になったことで、これまでチームが前提にしてきた計算が崩れました。エンジニアがエージェントにより多くの差分を書かせるようになると、開発のスループットを左右するのは検証になります。Google Chromeの開発者体験を牽引したAddy Osmani氏は、これをコードレビューのボトルネックとして次のように述べています。
「ボトルネックは、コードを書くことから、コードが正しく動くと証明することへと移った」
エージェント型エンジニアリングとは、エンジニアが意図を示しながらAIエージェントに差分を生成させ、コードを書かせてリリースまで行わせる取り組みを大規模に進めることです。導入のアドバイスは、生産性の向上、オーケストレーションのパターン、個々の開発者が「レベルアップ」するための道筋に焦点を当てがちです。しかし、チーム単位の導入は、その後に生成されるコードの量とレビューできる量とのギャップでつまずきます。レビューを形だけのものにしないために、エージェント型エンジニアリングを広げるなら、リスクに応じたルーティング、すべての差分に対する独立した一次レビュー担当、そしてレビュー容量と見逃した欠陥を追う指標から始める必要があります。
生成が安価になると、かつてチームの健全さを支えていたレビューの前提が崩れます。この速度の非対称性は的を射ています。
「コードを書くコストが高かった時代には、シニアエンジニアは、ジュニアエンジニアが書くよりも速くレビューできました。AIによって状況は逆転し、ジュニアエンジニアは、シニアエンジニアが批判的に監査できるよりも速くコードを生成できるようになりました。レビューを意味あるものにしていた制約が、取り払われてしまったのです」
AIを活用した開発でも、同じようにレビュー負荷の急増が報告されています。こうしたワークフローでは、PRの量が増えると同時に、レビューにかかる時間も増えていきます。GitHubは2025年にPR件数の増加を記録し、公開リポジトリでマージされたPRは年間5億1870万件に達し、前年比29%増となりました。
Osmani氏は、このコストを「理解負債」と呼びました。理解負債とは、システムに存在するコードの量と、誰かが本当に理解しているコードの量との間に開くギャップのことです。理解負債は開発速度のグラフには表れず、オンコールの誰もデバッグできない深夜2時の障害になって初めて姿を現します。
生成された差分が、レビュー担当者の読む速さを上回って届くようになると、キューは決まったパターンで破綻します。1回あたりの変更量が大きくなり、承認は形式的な追認に変わり、システムを深く理解している少数の人にますます認知負荷が集中していきます。
大規模なエンジニアリング組織も、同じレビュー過負荷のパターンに直面しました。コード量が増え、PRが非常に大きくなり、レビューの遅延が四半期ごとに増えていきました。そこに、見過ごせないシグナルが現れます。「最も大きなPRのレビュー時間が頭打ちになり、場合によっては減少した。これは、レビュアーが変更内容に意味のある形で向き合っていないことを示していた」のです。キューは派手に壊れるのではなく、中身を確認しないまま追認されるようになっていきます。
大きなPRは、その始まりの一つです。レビューの有効性は、大規模なレビューに関する研究が示すとおり、触れるファイルが増えるほど下がる傾向があります。そして、AIが生成するコードは、まさにそうした大きなまとまりで届きがちです。開発者が機能をプロンプトで指示し、何百行ものコードを受け取り、ざっと目を通してPRを開きます。レビュアーに渡されるのは、丁寧に読むには大きすぎ、それでいて一見もっともらしく、疑いを差し挟みにくい差分です。
もっともらしいAIのコードはコンパイルが通り、Linterを通過し、さらに多くの場合テストも通りますが、論理的な誤りを潜ませていることがあります。レビュアーは、コードが意図に合っているかどうかを確かめなければなりません。なぜなら、妥当性の確認は、出力が流暢で自信ありげなときほど難しくなるからです。
State of AIレポートは、470件のオープンソースPRを調べて同じ傾向を見いだしました。AIと共同で作成したPRは平均10.83件の問題を抱え、人間のみのPRは平均6.45件でした。90パーセンタイルでは、AIと共同で作成したPRが26件、人間のみのPRが12.3件です。また、論理や正確性に関する指摘は、AIのPRで75%多く見られました。
検証負債とは、チームが処理できるよりも速く積み上がっていく、レビューも検証もされていないAI生成コードのバックログです。放置すれば新たな技術的負債になりますが、今度はバックログの中ではなく、本番環境の中に存在することになります。
freeeのエンジニアリングチームは、AIコーディングエージェントが人間の処理できる量を超えるPRを生成したことで、この壁にぶつかりました。最初の突破口は、PRがレビュアーに届く前に、手間のかからないレビュー作業を人間のレビュー担当者から切り離すことでした。CodeRabbitを導入した後、チームは6か月で32.8週間分のレビュー時間を節約しました。
freeeの突破口は、キューに届く前に手間のかからないレビュー作業を切り離すことでした。これはチーム単位の成果です。エージェント活用の成熟度は、チームのレビューという成果物に表れます。個々の習熟度を測る道筋では、委任への慣れを評価できますが、チームとしての準備度は、エンジニアがコード生成を委任した後に何が起きるかで決まります。エンジニアが差分を見なくなれば、十分にレビューされていない複数のパイプラインが、ひとつのパンク寸前のキューへと流れ込みます。
Microsoftの導入成熟度モデルは、エージェント活用の成熟度を組織の能力として捉えています。準備度も、同じように扱うべきです。拡大する前に、チームには、PRのサイズとリスクに応じた検証基準、セキュリティチェック、ひも付けたチケットの確認を含む、共有されたレビューのワークフローが必要です。
チーム単位の変化は構造的なものです。人間はコードを書く役割から、意図・アーキテクチャ・責任を担う役割へと移ります。エージェント型ソフトウェアエンジニアリングに関する研究では、エンジニアの役割が、コードの生成者から社会技術システムのオーケストレーターへ移行すると説明されています。人間は、意図を仕様に落とし込み、アーキテクチャの一貫性を保ち、結果に責任を負います。
オーケストレーションが機能するには、フィードバックループが速くなければなりません。レビューに丸1日かかるようでは、速いエージェントは速くミスを量産するだけです。
リスクに応じたルーティングは、レビュアーに渡す差分を絞り込み、より的確なものだけを届けます。レビュアーに無理して読み込ませることでは、この問題は解決しません。Google自身のコードベースの健全性に関する基準も、有益な変更を妨げるようなレビュー上の障壁には反対しています。「レビュアーが変更を取り込むことを過度に難しくすると、開発者は改善に手を出さなくなる」とされています。通常の変更はより速く通す一方で、リスクの高い変更は、それを判断できる文脈を持つ人間に届くようにすべきです。
Metaは、これを大規模に実装しました。2025年に導入した差分リスクスコアのシステムは、リスクのある差分に注意を向けることで、厳密さを保っています。
リスクの低い通常の差分は、人間の関与を最小限にして進められます。リスクの高い差分は、責任の所在が明確なレビュアーへ振り分けられます。同じ考え方は、もっとシンプルなチームのワークフローでも機能します。ピアレビューで機能性とエッジケースをカバーし、シニアエンジニアのレビューでは、アーキテクチャ、コアインフラ、リスクの高い経路、新しいパターンを扱うべきです。
Osmani氏は、AIによるセキュリティレビューについて次のようなルールを示しています。
「コードが認証、決済、シークレット、あるいは信頼できない入力に触れる場合は、AIを仕事の速いインターンとして扱い、マージ前に人間による脅威モデルのレビューとセキュリティツールの実行を必須にすべきだ」
このように段階を分けることで、上級レビュアーの限られた注意を結果を左右する箇所に振り向け、未使用のインポートといった細かな指摘は上流の自動化に任せられます。
アーキテクチャの決定、セキュリティポリシー、規制対象のリリース承認、ロードマップの優先度の判断、そして自律的なエージェントの動作に対する責任は、人間が担います。開発者は、引き続きマージの責任を負います。
ルーティングを行うとしても、独立性は欠かせません。コードを書いたAIは、コードベースに対する自分の解釈をそのままレビューにも持ち込み、その解釈に組み込まれた盲点を見落としてしまいます。2025年の自己修正の盲点に関する研究では、モデルが、他人の出力でなら検出できる誤りを、自分の出力では見落とすことが報告されています。
すべての変更には、人間のレビュアーが登場する前に、独立したレビュアーが必要です。一次レビューでは、先入観のない状態で差分を読み、手間のかからない層を処理し、上級エンジニアには、エージェントが開いたときよりもきれいなPRを渡すべきです。CodeRabbitは、人間のレビューの前に、こうした独立した一次レビューを実行できます。
マージの判断は、開発者と人間のレビュアーに委ねられます。CodeRabbitは、手間のかからない層を片付け、文脈を踏まえた問題を早い段階で指摘し、人間のレビューを、人間にしかできない判断に集中させます。コードグラフは一次レビューにリポジトリの文脈を与え、MCP接続やひも付けたIssueは、外部やチケットの文脈をレビューに持ち込みます。
パスおよびASTベースの指示は、対象となるファイルにチームのルールを適用します。40を超えるリンターと静的アプリケーションセキュリティテスト（SAST）ツールが、人間のレビュアーが差分を開く前に、構造上やセキュリティ上の問題を検出します。PRへのフィードバックはCodeRabbit Learningsとして蓄積され、リポジトリ固有のガイダンスを時間とともに改善していきます。その結果、上級エンジニアはよりきれいな差分から作業を始められ、レビューの時間を、人間にしかできない判断に充てられるようになります。
速度だけを見ていると、実態を見誤ります。品質のツケが2四半期後に表れるまでは、すべてが順調に見えるからです。では、リーダーは何を見ればよいのでしょうか。DORA（DevOps Research and Assessment）プログラムのDORA 2024のデータでは、AI活用が25%増えると、デリバリーの安定性が7.2%低下するという相関が示されました。DORAは、この監査作業を検証税と呼び、「書く時間として節約した分は、結局その多くが監査に費やされる」と述べています。
リーダーは、レビューのループが保たれているかどうかを、レビューの遅延、欠陥の見逃し率、形式的な追認の割合、レビュー担当者の時間という観点で追うべきです。
レビューの遅延は、PRの量が増えても、サイクルタイムが下がり続けているのか、横ばいなのかを追います。レビューの遅延が量とともに増えていくなら、キューは処理が追いつかないほど速く埋まっている状態です。Jellyfishはサイクルタイムを、変更のリードタイムを構成する指標として扱い、デプロイ頻度が落ちる前に問題を浮き彫りにします。
欠陥の見逃し率は、レビューで捕まえられずに本番へ流れたバグの割合を測ります。見逃した欠陥には、「本来は捕まえられたはず」のものと「本当に微妙なもの」を分けてタグを付けてください。そこにこそシグナルが残ります。「本来は捕まえられたはず」の割合が上がっていることは、形式的な追認が起きている有力な兆候です。
形式的な追認の割合は、キューのうちどれだけが実際に読まれ、どれだけがそのまま通されているかを示します。ここで主要な手がかりになるのがPRのサイズです。Jellyfishも、PRのサイズを診断のための指標として挙げています。500行を超える差分の承認が数分で返ってくるなら、そのキューはレビューではなく、ただの追認を生み出している状態です。DXのガイダンスにも注意してください。これらはチーム単位で追い、スループットを個人の評価に結び付けないようにしましょう。結び付けてしまうと、形だけのレビューを助長してしまいます。
レビュアーの時間は、ボトルネックが実際に消費しているものを測ります。レビューのダッシュボードでは、キューの深さ、レビューの遅延、チーム単位のパフォーマンス、レビュー品質の指標を追えます。導入がうまくいっているかどうかのシグナルは、生成されるコードの量が増えても、これらの数値が制御下に保たれていたかどうかです。
最初に直すべきはレビューです。AIコーディングエージェントを先に導入し、後からレビューを足したチームは、返済が追いつかない速さで検証負債を積み上げてしまいます。まずは量を吸収できるようレビューのループを強化し、その上にエージェントを増やしていきましょう。
Taskrabbitのエンジニアリングチームは、AIコーディングエージェントを導入する前にレビューのボトルネックを解消することで、この順序を明確に示しました。マージまでの時間を25%短縮し、10日から7日へと改善しています。
エージェント型エンジニアリングは、レビューのループにかかる重みを一段と高めます。より多くのバグをリリースすることなくエージェントを拡大できるチームは、検証を構造的な制約として扱い、リスクのある変更に人間の判断を向け、人間が差分を開く前に、各差分へ独立したレビュアーを配置しています。CodeRabbitはその独立したレビュアーを担い、マージの責任は開発者に残ります。エージェントの速さで進みながらも、一行一行がマージに値するものとして扱われるのです。
コードレビューの時間とバグを50%削減。CodeRabbitの14日間の無料トライアルを今すぐ始めましょう。
