開発生産性を妨げる「3つのボトルネック」
セッションの冒頭中津川氏は、急速な盛り上がりを見せるAI支援開発の現状を俯瞰した。日本のGitHub利用者数は2024年から2025年の1年間で100万人増加し、450万人を突破した。公開コミットの4％がClaude Code経由のAI生成コードだという。さらにAIの登場により、エンジニア以外の職種がソフトウェアを開発する市民開発も急増している。一方で、セキュリティや品質面において、AI生成コードに対する懸念が高まっている点も無視できない。
AIによるコーディングが日常化する一方で、実際の開発生産性が向上しているかという疑問も生じている。中津川氏は、AI支援開発の現場で発生している課題として以下の3点を挙げた。
（1）コードレビュー
キッカケクリエイションの調査によると、コードレビュー担当者の約9割が、AI生成コードの普及による負担増加を実感している。レビューすべきコード量が激増しているにもかかわらず、レビューを担当するシニアエンジニアの人数が増えていないことが原因だ。コードレビューは単にコードを閲覧する作業ではない。プルリクエストに記載された業務要件や設計意図を読み込み、既存コードへの影響まで確認する必要があるため、認知負荷が極めて高い。その結果、コードの生産量が増えてもレビューがボトルネックとなり、開発スピードが向上しない事態に陥っている。
（2）AI活用スキルのばらつき
AI生成コードの品質は、スキルやエージェントの設定といったハーネスに大きく左右される。しかし、そのノウハウは個人内に閉じやすい。例えばシニアエンジニアであっても、ハーネスの設定が不十分であれば低品質なコードを出力してしまう。過去の実績からコードレビューも甘くなり、品質面のリスクがさらに高まる恐れがある。加えて、LLM特有の不確実性により、同一のモデルとハーネスを使用しても出力品質に揺らぎが生じることは避けられない。そのため、ハーネスに関する知見を組織内で共有し、チーム全体でコード品質を管理・制御する仕組みづくりが不可欠となる。
（3）AIに対するROI（投資対効果）の明確化
これまで現場の関心は、AI支援開発に着手すること自体にあった。そのため開発者各自が自由にAIを利用できる環境が整っていた。しかしマネージャー層の関心は、コードの生産量から「AIがもたらす実際の収益」へと移りつつある。中津川氏は、昨年まではAI予算を自由に活用できる段階であったが、今年後半からは本格的に投資対効果が問われるようになると予測する。
AI支援開発の本格化に伴い、様々な課題が顕在化している。開発生産性向上に対する疑念についても、それを裏付ける調査結果が出始めている。2025年のMETR[1]の調査によると、AI利用により24％の高速化が予測されていたにもかかわらず、実際には開発期間が19％増加していた。また別の研究では、コア開発者のレビュー負荷が6.5％増加したことで保守に工数を奪われ、コードの生産性が19％低下したと報告されている。
[1] METR（Model Evaluation and Threat Research）：アメリカの非営利研究機関。自律タスクを行う先端AIモデルの評価を通して、企業や社会におけるAIの潜在能力とリスクについて研究している。
開発生産性の本質とは？ AI運用の3原則
そもそも開発生産性とは何を指すのだろうか。中津川氏は、DORA[2]による開発生産性の定義を紹介した。
[2] DORA（DevOps Research and Assessment）：Google Cloud所属の研究組織。毎年、DevOpsの調査・研究レポートであるState of DevOpsを発行している。
開発生産性は「速度」「品質」「レビュー」「フロー」「体験」の5つのカテゴリーで構成される。
速度：リードタイムやデプロイ頻度など、開発プロセスのスループットを測る指標。
品質：本番障害件数やバグ再発率、変更失敗率など、成果物の信頼性を評価する。
レビュー：レビュー待ち時間やPRサイズ、差し戻し率といった、コードレビュープロセスの効率を可視化する指標。
フロー：会議時間やコンテキストスイッチ回数など、開発者が実装作業に集中できているかどうかを示す指標。
体験：開発者満足度や認知負荷をアンケートなどの定性的手法で測定する指標。
企業ごとに重視する軸は異なるが、これら5つのカテゴリーを組み合わせることで、開発生産性の実態を多角的に把握できる。中津川氏は、コードレビューツールを提供する立場から開発生産性を測る上でのレビューの重要性を強調した。GitHubのデータから算出可能なメトリクスも多いため、それらを分析することでAI導入による真の成果を可視化できると説明する。
この前提を踏まえて、中津川氏は開発組織でAIを効果的に活用するための3つの原則を提示した。
（1）AIに与えるコンテキストのガバナンス
AIに何を任せ、どのような情報をコンテキストとして与えるか、逆に与えてはならない情報は何かを定義する必要がある。人間が何を判断し、何に責任を持つかを組織として設計しなければならない。シャドーAI化を放置すれば、個人のAIツール経由で機密情報や顧客情報が流出する深刻なリスクが高まる。判断を個人任せにせず、組織としてポリシーを統一することが重要である。
（2）全員が見られる場所でAIを利用する
コーディングエージェントは基本的に個人のPC上で動作するため、AIとの対話で得られた知見やコンテキストは個人の中に閉じやすい。勉強会などで成功事例を共有しても、試行錯誤の過程が見えにくく、組織全体のスキルアップにはつながりにくい。そのため、コードを変更した原因や意図をチーム全員が閲覧できる場所に残すことが推奨される。
例えば、Issueとプルリクエストをリンクさせ、そこにAIとの作業履歴を記録すると効果的だ。特に新加入のメンバーにとって、過去の意思決定の意図が可視化されていることは、オンボーディングの質を大きく左右する。
（3）品質と安全性の担保
AIは強力な開発支援ツールであり、成功時の効果は絶大だが、暴走するリスクも伴う。例えばエラーからの復旧を試みる中で環境変数を勝手に探索するなど、危険な行動をとるケースがある。コードレビューやテスト、CI/CDといった適切な品質ゲートの設置は不可欠だ。しかし、それを人力だけで運用すればシニアエンジニアの負荷が際限なく増えてしまう。そのため、品質ゲート自体にAIを積極活用するフェーズへ移行すべきだと中津川氏は提言する。
CodeRabbitが実践するAI活用の具体的な開発フローとは？
続いて中津川氏は、CodeRabbitが自社で実践しているAI活用の具体例を「チャット」「Issue」「レビュー」の3点に分けて紹介した。
1つ目は、チャットにおけるSlackエージェント「CodeRabbit Agent」の活用である。CodeRabbit AgentはDatadog、Sentry、Salesforce、Notionなど多数のサービスと連携しており、Slack上で指示を出すだけで各種サービスの情報を横断的に調査できる。例えばVercelへのデプロイエラー調査を依頼すると、ログやアクセス権限を自動調査して原因を特定する。さらに顧客からの問い合わせを起点にコードを調査し、サポートエンジニアへの回答案作成やプルリクエストの作成まで自動で行える。日常的に使うSlack上で処理が完結するためツール間を移動する手間が省け、AIとの対話が可視化されて知見が蓄積する。一元管理により利用環境の個人差が生じない点も大きなメリットである。
2つ目はIssueにおける活用である。同社では、GitHub上のIssueを起点に実装計画を自動作成するサービス「CodeRabbit Plan」を活用している。現在のコードベースや過去のIssue、ドキュメントを参照して計画を生成し、AIコーディングエージェント用のプロンプトも出力するため、スムーズに実装へ着手できる。GitHub上でチーム全員が閲覧・コメントできるため、作業のブラックボックス化を防ぎ、適切なレビューやコンテキストの提供が可能になる。
3つ目はレビューにおける活用である。CodeRabbitのレビュー機能には、CLIやVS Codeで利用するローカルレビューと、プルリクエストレビューの2種類が存在する。
中津川氏が重視するのはレビュアー側の負荷軽減だ。多くのAIレビュー機能はレビュイー向け支援に偏っているが、開発生産性に直結するのはレビュアーが素早く内容を理解しマージ判断を下せるかどうかにあり、CodeRabbitは概要整理、変更ファイルのグループ化、シーケンス図の生成等により、レビュアーが短時間で全体像を把握できるよう支援し、レビュー工数の半減を目指している。
さらに中津川氏は、AI導入におけるROIの重要性に改めて言及した。CodeRabbitのダッシュボード機能は、マージまでの所要時間や品質指標、ナレッジベースの活用状況などを多角的に提示できるため、AI導入の効果を明確に可視化できる。これにより、マネージャー層に対して投資の妥当性を十分に示すことが可能となる。
中津川氏は、開発生産性向上の鍵はレビューの効率化にあると示し、CodeRabbitを活用したチームのAI開発生産性向上を呼びかけて講演を締めくくった。
CodeRabbitからのお知らせ
本セッションでご紹介したサービスにご興味を持たれた方は、ぜひ公式サイトをご覧ください。
