全PRの83%が AIレビューだけでマージできるようになった開発組織は その後どうなったか @2026/10

AI DevEx Conferenceのリバイバル公演 〜もう一度聴きたいあの登壇〜【D-Plus Tokyo #27】
での発表資料です

https://d-plus.connpass.com/event/406429/

Transcript

1. 全PRの83%が AIレビューだけでマージできるようになった開発組織は その後どうなったか @2026/10 株式会社カウシェ / 市島慎吾
2. ⾃⼰紹介 • 名前 ◦ 市島 慎吾 (Shingo Ichijima) • 会社 ◦ 富⼠ゼロックス (2016/04 ~ 2018/08) ◦ バイセルテクノロジーズ (2018/09 ~ 2019/12) ◦ ラクスル (2020/01 ~ 2023/01) ◦ カウシェ (2023/02 ~ ) • 役割 ◦ Engineering Manager (Backend) • アカウント ◦ X: @shinichiji ◦ GitHub: @a-thug
3. SNSのように 毎⽇開きたくなるECアプリ ダウンロード 累 計 800 万 突破 ※2026年10⽉時点 GMV DAU 35 倍 81 倍 ※FY23.8⽉→FY26.5⽉⽐較 ※FY23.8⽉→FY26.5⽉⽐較 売上総利益 売上総利益/⼈ 411 倍 1.6 億 ※FY23.8⽉→FY26.5⽉⽐較 ※FY26.5⽉速報値を年換算
4. ⽬次 • 01：AI DevEx Conferenceで話したこと • 02：話した時点からの差分 • 03：まとめ
5. 01 AI DevEx Conferenceで話したこと
6. 導⼊ 今年4⽉にZennにて以下の記事を書いたら、思ったより反響があった AIレビュー導⼊は珍しくないが、マージまで任せる組織はまだ少ない
7. 任せるマインドチェンジをどう進めていったか • エンジニア間でレビュー待ちが⼀番のボトルネックであるという共通認識 があった ◦ このボトルネックは解消しなければいけない、が...怖い • それでも任せられた理由は「AIの精度が上がってきた」もあるが、それは 主要因ではない ◦ 切り戻しがしやすい環境 ◦ ミッションクリティカルなサービスではない → 間違っても致命傷にはなりにくい • AIを信じて任せたというより、やらなければ勝てないから踏み切った
8. ボトルネックが解消され、PR数が5.5倍に増えた • • • • マージされたPRは5.5倍に増加（2025年6⽉→2026年5⽉） 同じ期間、開発メンバー数は2倍に増加 1⼈あたりがmain branchにmergeするPRは2.8倍に増加 ⼈が増えたことより、1⼈あたりが増えたことの⽅が⼤きい
9. システムの安定性 • revert率は下がった ◦ 3.8%→0.5〜0.9% ◦ revertの絶対数は増えた：5件→20件前後 ▪ revert全部が障害と関係しているものではない • 中規模以上の障害は月 1~6件で横ばいとなり、意外と変わらず • AIレビューの見落としによる障害は？ ◦ あった ▪ しかし、これを人間がレビューしていたとしても普通に見落としていた ような事象だった ◦ したがって、品質ゲートとしての AIレビューはちゃんと機能している
10. 次に詰まるのは『作る前』 • 実装〜レビューが速くなった分、詰まる場所が『作る前』へ移った ◦ 『作る前』= 何を作るか‧どう作るかを意思決定して、合意すること • ここさえ正確にできれば、⼈が介⼊せずに、エージェントが複数の施策を 並列で進められるのでは • そのために、「これが現時点でのベスト」とチームで合意する必要がある
11. ベストを模索し、説明可能にする仕事 • 最も変わったのは、仕事の抽象度が上がったこと ◦ 「どうあるべきか」を考える頻度が増えた • 合意に向けて、⼈がすることは2つ ◦ ⾃分なりにベストを模索し続けること ◦ それを他⼈でも理解できる「説明可能な状態」にすること
12. 02 話した時点からの差分
13. 開発の⾃動化はかなり進んでいる • 開発チームは1週間で867本のPRをマージするペースで、もうすぐ1000本/ 週にのるペース • 9⽉は、開発チームの全員に、1⽇10本以上PRを出した⽇があった ◦ 3⼈に1⼈が、⽉に10⽇以上そういう⽇がある • 1⽇あたりのPR数/⼈の⽉ごとの推移はこんな感じ
14. PR数はインフレしてきた • PR数はインフレ気味で、指標としての意味が薄れてきた ◦ ⾃動化が進むほど増え続ける ◦ 組織の開発⽣産性的な意味合いでの重要性は落ちていく • (余談) ちなみに予算を⽴てる上ではPR数をパラメータとしておいておくの は便利だったりする ◦ 予算は「⼈数×1⼈あたりのPR数×PR 1本あたりの単価」で組みやす くなる ◦ 過去の成⻑率を鑑みて、X⽉には1⼈あたりのPR数がこれぐらい、採⽤ 予定のヘッドカウントはこれぐらいで...みたいな感じ
15. 次、何を⾒ていくのがいいんだろうか • この時代に⽣産性の指標として良さげなものは、正直まだ⾒つけられてい ない ◦ 依然として4keysなどは有⽤ではあるが、AIコーディング登場前と⽐ べると、開発の実⼒値を⽰す代理指標としてはちょっと弱くなってき た感覚がある • ⼀旦カウシェの開発組織では以下を⾒ている ◦ 4 keys ◦ 1回の指⽰でいくつPRができるか ◦ 実装前と実装後でどれぐらい作ったものに乖離があったか
16. 1回の指⽰でいくつPRができるか • いまは「プロンプト効率」を⾒てみている ◦ 1つの指⽰から、何本のPRが作られたか ◦ 完成までに⼈が指⽰する回数を、減らせているかを⾒たい ▪ ≒ ⼈間が介在する回数を減らしたい • 理想は「これやっといて」で、勝⼿にPRが作られ続けて完成している状態 • 全体ではまだ、PR 1本に指⽰3〜4回 • ⼀部のメンバーでは、1回の指⽰で1本以上のPRが出るようになってきた
17. 1回の指⽰で作業をたくさんやってもらいたい • 1回の指⽰で任せ切るには、適切な粒度のスコープと、明確なゴールが要る ◦ 実際、具体的な作業の⽅が⼿戻りが少ない • カウシェではDesign Docの後に「実装計画」を作り、repo にコミットして いる ◦ その開発で作るPRと、各PRでやることまで書く • まずは実装計画と実際に作られたPRの乖離を⾒ている ◦ 本数の差だけでなく、計画になかった作業とその中⾝も分析している
18. 予実の乖離はゼロにできないが、やる意味はある • 計画外の作業の内訳を調べてみた ◦ 4割は、事前に確かめれば書けた作業（外部APIの挙動、エラー時の扱い） ◦ 4割は、仕様が決まっていなかったもの（この場合どうするか、画⾯の⼿直 し） • 乖離をゼロにするのは不可能 ◦ 多少の⼿戻りは覚悟の上、スピード重視で取り掛かることは普通にある ◦ 完成してから触って分かる違和感や、後から「ああしたい、こうしたい」も 出てくる • それでも、乖離をなくそうとして1本ずつ⾒ると、事前に分かったはずの作業や 仕様の漏れが⾒えてくる
19. 漏れていたことを次の計画に反映させていく • 判明した齟齬や漏れを、次の実装計画に反映させていく ◦ まずは⾃分たちでコントロールできる範囲を着実に改善する ◦ それと同時に、コントロールできる領域も広げていく ▪ 作る前から「ここはこうした⽅が顧客/事業にとって良いよね」と 判断できるように解像度を上げていく • 「これやっといて」で完成する状態に少しずつ近づけていく ◦ よりたくさん、顧客価値を提供できるように、⼈間の時間の使い⽅を 変えていく
20. 03 まとめ
21. まとめ • 01: AI DevEx Conferenceで話したこと ◦ AIレビューでマージまで任せ、PRは5.5倍、システムも安定している • 02: 話した時点からの差分 ◦ ⾃動化は進み、PR数はインフレしてきた ◦ 計画とのズレから漏れを⾒つけ、次の実装計画に反映させている
22. 告知 📣 採⽤中 📣 ◦ Backend、Mobile、Platform、ML/DS、Data、EM、VPoE、PdM、Designer … • meetupもやります！ ◦ https://kauche.notion.site/KAUCHE-MeetUp-2026-10-22-3e6dd1d8ae6c809daddfee3bc322 0687 •
23. ご清聴ありがとうございました