TL;DR
Google CloudのDORA（DevOps Research and Assessment）チームが発表した2025年版レポートState of AI Assisted Software Developmentは、約5,000人の調査回答に基づき、AIコーディングツールの普及がソフトウェア開発に与える影響を多角的に分析しています。調査対象の90%がすでに業務でAIを使用し、平均で勤務時間の約2時間をAIとの直接的なやり取りに費やしています。生産性や品質の向上を実感する開発者は多い一方で、AI採用度を高めるほどソフトウェアデリバリーの不安定性（変更失敗率・デプロイやり直し率）が増加するという構造的な課題が浮き彫りになりました。
CodeRabbitの独自分析でも、AIコーディングエージェントと人間が共同で作成したPRでは、致命的なバグが約40%増加していることが確認されています。コード生成の速度が上がった今、レビュー工程をボトルネックのまま放置すれば、品質低下とリリース速度の停滞を同時に招きます。AIが書いたコードをAI（コード生成とは独立したアーキテクチャで）でレビューするアプローチが、この問題に対する現実的な解のひとつとして提示されています。
本記事は、DORA Webinar: State of AI Assisted Coding in 2026 - YouTubeの日本語解説になります。DORA リサーチリードのNathan Harvey（Google Cloud）、CodeRabbit Senior Product ManagerのSahil、そしてClerk Senior Staff Software EngineerであるBrandon Romanoが、それぞれの視点からAI時代のコードレビューのあり方を議論しました。
DORAレポート2025：AIはソフトウェア開発の「増幅器」である（2:37〜）
DORAは10年以上にわたりソフトウェアデリバリーの能力と成果を研究してきたプログラムで、Google Cloud内にありつつもプラットフォーム非依存の調査を実施しています。2025年版では約5,000人の回答と100時間超の定性データを基に、AIがソフトウェア開発に与える影響を包括的に分析しました。レポートの核心は「AIは増幅器である」という結論です。AIは既存の組織システムの強みも弱みも増幅します。戦略的な基盤なしにAIを導入すると、局所的な生産性向上が下流の混乱に飲み込まれてしまいます。
調査から浮かび上がった数字は印象的です。回答者の約90%が業務でAIを使用しており、勤務時間にAIとやり取りした時間は約2時間となっています。8時間労働の約30%に相当し、ソフトウェアエンジニアがコーディングに費やす時間（業界調査で10〜30%）とほぼ一致します。つまり、コードを書いている時間のほぼすべてでAIを使っている計算になります。そして、70%以上の人たちが「生産性が向上した」と回答し、50%以上が「コード品質が改善した」と答えています。
しかし、信頼の問題は依然として残っています。AI生成物の品質を「あまり信頼しない」「まったく信頼しない」と答えた層が約30%存在します。Nathanはこの信頼レベルを健全であると評価しつつも、以下のように指摘しています。
信頼は使用量と比例する。使えば使うほど信頼が生まれ、信頼が使用をさらに促す好循環がある
そして注目すべきは、AIの利用タスクのランキングです。「コードを書く」が圧倒的に1位である一方、「コードレビュー」はリストの下半分に位置しています。「コードを書くためにAIを使うなら、そのコードをレビューするためにもAIを使うべきではないか」という問いかけが本ウェビナー全体を貫くテーマとなっています。
そしてDORAの中核指標であるソフトウェアデリバリーパフォーマンス（スループットと安定性）に対するAIの影響分析は、明確なトレードオフを示しています。AI採用度を上げるとスループット（リードタイム、デプロイ頻度）は向上しますが、同時に不安定性（変更失敗率、デプロイやり直し率）も増加します。2023年のDORA調査では「コードレビューが速いチームは、ソフトウェアデリバリーパフォーマンスが50%高い」という知見が得られており、レビュー工程の改善がこの不安定性の軽減に直結する可能性を示唆しています。
CodeRabbitのアプローチ：PRの差分をLLMに投げるだけではレビューにならない（18:30〜）
CodeRabbitはAIコードレビュー専業のスタートアップとして2023年に創業しました。共同創業者たちはエンジニアリングリーダーとして、Copilot導入後にPR数は増えたがリリース速度は上がっていない現象を目の当たりにしたことが起業の動機です。CodeRabbitの独自調査では、AIコーディングエージェントと人間の共同作成PRにおいて致命的なバグが40%増加しており、DORAの知見と整合する結果が得られています。
CodeRabbitのアーキテクチャは、単にPRの差分をLLMに渡して終わりという設計ではありません。以下のような多層的なコンテキスト構築と検証プロセスを採用しています。
- リアルタイムコードグラフ解析：PR内の変更がリポジトリ全体の関数呼び出し依存関係にどう影響するかを分析します。PR差分の外にある下流の破壊を検出できます。
- 外部コンテキスト統合：MCP（Model Context Protocol）クライアントを通じてJira、Linear、Notion、Sentryなどの外部ツールと接続し、要件チケットやPRD、ドキュメントをレビューの文脈として取り込みます。
- コーディングガイドラインの検証：Cursor RulesやGitHub Copilot Instructionsなど、コーディングエージェントに指定したルールを二次チェックし、実際にルールが守られているかを確認します。
- 独立した検証エージェント：LLMの出力を鵜呑みにせず、別の検証エージェントがレビューコメントの妥当性を検証します。「このAPI呼び出しを更新すべき」という指摘に対し、そのAPIが実際に存在するかどうかを確認し、ハルシネーションを除去します。
- リアルタイムWeb検索：新しいセキュリティパッチや脆弱性情報など、LLMの学習データに含まれない最新情報を取り込みます。
Sahilが繰り返し強調したのは「セルフレビューは機能しない」という原則です。手動レビューの時代にも、自分のコードは自分ではなくシニアの同僚がレビューしていました。AIの時代になっても、コード生成エージェントが自分の書いたコードをレビューすべきではありません。アーキテクチャ上独立したエンティティがコーディングエージェントの出力を評価することで、バイアスのないレビューが実現します。たとえば、Copilotでコードを書き、CodeRabbitでそのコードをレビューするという分業が重要です。
導入効果として、手動レビューからの移行で初回レビューまでの時間が大幅に短縮されること、従来2人のシニア開発者で行っていたレビューが1人＋CodeRabbitで完結するようになること、そしてGrouponの事例ではPRマージ数が36%増加したことが紹介されました。
Clerkの実践：AIコードレビューが「非開発者の貢献」を可能にした（35:43〜）
ClerkはAuthentication & User Management Platformを提供する企業で、開発者体験を重視したフロントエンドSDKを展開しています。Brandon Romanoは同社のSenior Staff Software Engineerとして、AIツールの積極的な導入を推進してきました。Clerkの開発チームはCursor、Claude、Codexなどのコーディングエージェントに加え、LinearやSlackからエージェントを起動する運用も行っています。コードレビューにはCodeRabbitを採用しています。
Clerkの事業特性として、ダウンタイム許容度がほぼゼロであること、認証プロバイダーとしてセキュリティが最優先事項であることが挙げられます。この制約の中で特に興味深いのは、AIコーディングツールの普及により「非開発者やバックエンド専門外のエンジニアがコードベースに貢献できる範囲が広がった」という現象です。しかし、それは同時にセキュリティリスクの増大を意味します。そうした課題の中で、CodeRabbitのセキュリティ検出感度を高くチューニングすることで、コア開発者以外でも安全にコードを提出できるという安全性を実現しました。これは組織としての開発能力の拡張に直結する話でしょう。
Brandonが示した具体例は、実践的で説得力があります。nullポインタ参照の検出は、内部APIの深い理解が必要で人間のレビューでは見落としやすいケースです。正規表現の意図と実装の不一致（コメントでは「31文字以上」だが、正規表現は「ちょうど31文字」）は、テストやAPI仕様から文脈を横断的に参照できるAIならではの指摘です。存在しないファイルをDockerfileで参照していた件では、ローカルテストを省略したことによるビルド失敗を事前に防ぎ、40分以上のサイクルロスを回避できました。
Brandonの発言で印象的だったのは、CodeRabbitとの意見の相違も価値があるという指摘です。CodeRabbitの指摘が誤りだった場合にフィードバックを返すと、それがLearningsとして蓄積され、以降の同種の指摘が抑制されます。このインターフェースはまさに「人間のレビュアーとのやり取りと同じ感覚」で利用でき、チームへの浸透を後押ししています。さらに、直接アクションにつながらないコメントであっても「なぜAIがこの部分で混乱したのか？」と自問するきっかけになり、ドキュメント不足やコードの不明瞭さを改善するトリガーになっているそうです。
ディスカッション：計画フェーズの重要性と、コードレビューの目的の再定義（54:10〜）
ウェビナー終盤のQ&Aセッションでは、「AIアシスト開発におけるコードレビューは今後1〜2年でどう進化するか」という質問が取り上げられました。
Sahilは「1〜2年は予測困難だが、3〜6ヶ月の範囲で言えば、コーディングの前に計画に時間をかけることの重要性が急速に認識されつつある」と回答しました。プロジェクトやタスクの計画を綿密に立て、その計画をコーディングエージェントに渡し、さらにその計画をレビュー時にも参照します。「計画→生成→計画に基づくレビュー」というサイクルが定着すれば、バグのリリースは大幅に減るはずです。次回のDORAレポートでこの傾向がデータとして現れる可能性は高いでしょう、とのことです。
Nathanの見解はさらに本質的でした。「コードレビューの理想形は、実はペアプログラミングだ。つまり、レビューの必要性自体を排除すること」だといいます。多くの組織ではコンプライアンス上の理由でペアプログラミングは採用しにくいですが、AIがレビューの品質保証を担えるようになると、コードレビューの目的そのものを再考する余地が生まれます。従来、コードレビューにはバグ検出と知識共有という2つの目的がありました。バグ検出をAIに委ねられるなら、人間のレビューは知識共有と属人性排除に集中できます。そうなれば「コードレビューは本番デプロイをブロックしていないか？」という問いすら現実味を帯びてきます。
CopilotとCodeRabbitの違いについても議論がありました。Copilotは優れたコーディングアシスタントですが、自分の書いたコードを自分でレビューすべきではないという見解が挙げられいます。これは、AI以前から存在する原則の延長線上にあります。Brandonも「個人的な経験から言えば、CodeRabbitはCopilotやCursorのレビュー機能よりも精度が高く、ミスが少ない」と述べ、専業ツールの優位性を裏付けました。
まとめ：AIが書いたコードを、AIがレビューする時代の設計原則
本ウェビナーから得られる知見を整理すると、以下の構造が見えてきます。
DORAの大規模調査が示したのは、AIコーディングツールの採用はスループットを確実に向上させるが、同時にソフトウェアデリバリーの不安定性も増加させるというトレードオフです。この不安定性を抑制する鍵がコードレビュー工程にあります。2023年のDORA調査で「コードレビューの速いチームは、デリバリーパフォーマンスが50%高い」と示されたように、レビューの速度と品質は組織の開発能力に直結します。
CodeRabbitのアプローチは、AIコードレビューを「PR差分をLLMに投げるだけ」から脱却させ、コードグラフ解析、外部コンテキスト統合、独立した検証エージェント、リアルタイムWeb検索などの多層的なアーキテクチャで品質を担保するものです。Clerkの実践事例は、このアプローチが認証基盤のようなミッションクリティカルな領域でも機能し、さらに非開発者の貢献範囲拡大という副次的効果も生むことを示しました。
今後のアクションとして検討すべきことは、以下の通りです。
- DORAレポートを読む
自組織のプラクティスをDORAのベンチマークと比較し、ギャップを特定する（2025 DORA State of AI Assisted Software Development | Google Cloudからダウンロード可能です） - コードレビューのボトルネックを可視化
PR作成からレビュー完了までの時間、レビュー待ちのキュー長を計測 - コーディングエージェントとレビューエージェントを分離
セルフレビューに依存しない、アーキテクチャ上独立したレビュー体制を構築 - 計画フェーズに投資する
コーディングエージェントに渡す計画の質がアウトプットの質を決めるので、計画をレビュー時にも参照可能にする - レビューの目的を再定義する
バグ検出をAIに任せ、人間のレビューは知識共有と設計判断に集中させる方向を検討
AIが書いたコードは今後も増え続けます。その流れを止めることはできませんし、止める必要もありません。重要なのは、その増大するコードの品質をどう担保するかです。コードレビューは、AIコーディング時代においてむしろ以前より重要になっています。
Discussion