Share
Embed
Slide 1
Slide 1 text
全PRの83%が
AIレビューだけでマージできるようになった開発組織は
その後どうなったか
株式会社カウシェ / 市島慎吾
Slide 2
Slide 2 text
⾃⼰紹介
● 名前
○
市島 慎吾 (Shingo Ichijima)
● 会社
○
富⼠ゼロックス (2016/04 ~ 2018/08)
○
バイセルテクノロジーズ (2018/09 ~
2019/12)
○
ラクスル (2020/01 ~ 2023/01)
○
カウシェ (2023/02 ~ )
● 役割
○
Engineering Manager (Backend)
● アカウント
○
X: @shinichiji
○
GitHub: @a-thug
Slide 3
Slide 3 text
サービス紹介
Slide 4
Slide 4 text
SNSのように
毎⽇開きたくなるECアプリ
ダウンロード
累
計
700
万 突破
※2026年7⽉時点
GMV
DAU
35 倍
81 倍
※FY23.8⽉→FY26.5⽉⽐較
※FY23.8⽉→FY26.5⽉⽐較
売上総利益
売上総利益/⼈
411 倍
1.6 億
※FY23.8⽉→FY26.5⽉⽐較
※FY26.5⽉速報値を年換算
Slide 5
Slide 5 text
導⼊
今年4⽉にZennにて以下の記事を書いたら、思ったより反響があった
Slide 6
Slide 6 text
どうしてか、を想像してみた
● AIレビューを導⼊している企業は増えてきている
○ github copilot review, coderabbit, bugbot, etc
● しかしAIレビューをmerge gateとして置けている企業は少ないのでは
○ 阻害要因
■ レビュー品質、レビューに必要なコンテクスト、マインドチェン
ジ、etc
● PRをAIにレビューさせることと、AIレビューだけでPRをmergeするま
ではかなり距離がありそう
Slide 7
Slide 7 text
今回話すのは『作り⽅』と『どうなったか』
前半はPRの⼤半がAIレビューによってmergeされる状態の作り⽅について
後半はその状態になったら、コードベース‧組織‧ビジネスに何が起きたか
Slide 8
Slide 8 text
⽬次
• 01：どうやって83%まで上げたか
• 02：その後、開発のやり⽅と組織で何が起きたか
• 03：次のボトルネック
Slide 9
Slide 9 text
01
どうやって83%まで上げたか
Slide 10
Slide 10 text
前提条件が整っていた
カウシェは以下の3つの前提があったため、⼈/AIに関わらず、レビューによる
実装の妥当性が確認しやすい環境だった
● APIごとの外部仕様の明確化、およびその仕様を満たすE2Eテストの原則化
● 事前に細かく、何をどういった順番で実装するかをリストアップして、実
装レビューをする⼈と擦り合わせる開発プロセス
● 明⽂化されたコーディング規約
○ レイヤー構造‧命名‧エラーの扱いなどを、ドキュメントで管理
○ 何がGoodな書き⽅か、MUST NOTな事項などを明⽂化していた
この環境の上に⼈の代わりとなるようにAIレビューを載せただけだったりする
Slide 11
Slide 11 text
振る舞いが担保されている重要性
• カウシェではprotoファイルのgRPCエンドポイントごとに仕様を書くよ
うにしている
○ 書かれたgRPCエンドポイントの仕様ごとに正常系‧異常系をステータ
スコード別に検証
○ そもそも書かれている仕様を満たしているか、をレビューでまず
チェックしている
○ 仕様に書かれているがテストケースがない、はAIでのコーディングが
活発になる前からレビューでかなりチェックしてきていた
• テストが通る＝デグレしていない、をAIが確かめられる
• このガードレールが無ければ、AIにApproveは任せられなかった
Slide 12
Slide 12 text
細かく刻んで、擦り合わせる
● 実装計画を、チームでレビューする
● 実装に⼊る前に何をやるか合意している状態なため、レビュワーも合意し
た内容が実装されているかをチェックすればいいだけ
● カウシェにおける実装計画とは
○ PRごとに、触るファイル‧追加するメソッドまでしっかり書き出す
○ これをコードを書く前に、チームでレビューしてからGitHubに⼊れる
○ 実装計画のチームレビューが通ってから、コードを書き始める
Slide 13
Slide 13 text
ここまで刻むと
● PRに「適切なコンテクスト」と「⼩さいスコープ」が揃う。
● 学⽣のテストでいうところの、⾃由記述より⽳埋め式や選択式に近い感じ
○ ⾃由記述は採点(判断)が要るが、選択式は丸付け(○か×)で済む
○ レビューも同じで、曖昧さが減るほど、AIの判断の余地が減る
● ただし丸付けできるのは「決めた通りに作れてるか」まで
○ 「そもそも、この作り⽅がベストか？」は、AIには判断させていない
○ あえてスコープを絞って、その判断は作る前に済ませるようにしたから
● 詳しくは別記事『制約が開発を速くする』にて
○ https://zenn.dev/kauche/articles/44ae321438f0ff
Slide 14
Slide 14 text
明⽂化されたコーディング規約
● 外に出せる程度にはコーディング規約の明⽂化ができていた
● レイヤー構造‧命名‧エラーの扱いなどを、ドキュメントで管理
● 何がGoodな書き⽅か、MUST NOTな事項などを明⽂化していた
○ 急いで何かを決めたり、決めるプロセスを作り出す、みたいなことは
不要だった
Slide 15
Slide 15 text
却下すべき理由が無ければ、Approveする
• ⽌めるのは『直さないと壊れる』ものだけ
○ ランタイムエラー、データ不整合、権限チェック漏れのようなセキュ
リティの⽳、Nullになりうる参照、トランザクション境界の誤りなど
明確なバグ
○ 不可逆‧変更コストの⼤きい命名など、後から直しにくいもの
• 通すもの＝マージは⽌めず、コメントで残す
○ 可逆な命名の好み、設計の好み、より速い書き⽅、過度な最適化など
○ とはいえ積もると良くないので、フォローアップを週次でチェック
Slide 16
Slide 16 text
着⽬するポイントを限定してレビューの質を上げる
• 好み‧流儀は、lintとformatter、コード規約で最初に揃えた
○ 好み‧流儀は、AIレビューで差し⽌める対象にしない
○ 好み‧流儀の話が出たら、都度コード規約に蒸留していく
• AIに任せたのは『仕様に沿った実装がされているか』とバグ検出が中⼼
○ 観点を⾜すほど精度が上がる、という思い込みを捨てた
• 指摘すべきものを絞ったため、本当に対応すべきものだけが残った
Slide 17
Slide 17 text
⼈間に渡すのは、戻せないか‧直すコストが⾼い領域
• DBスキーマの変更は⼈間に渡す
○ データは⽣存期間が⻑くなりがちなのと、⼀度変更すると戻すのが難しい
場⾯が多い
• Proto定義の変更も⼈間が⾒る
○ 他サービスへ影響が波及するのを防ぐ
• 認証‧決済フローも⼈間が⾒る
◦ 何かあった場合にビジネス的なインパクトが⼤きい部分の責任は⼈間が持つ
◦ 設計のトレードオフやビジネス上の妥当性は、最終的に⼈間が引き受ける
Slide 18
Slide 18 text
判定の材料‧コンテクスト
● ハザードマップ
○ コードベースのドメインやファイルをcritical / high / medium / low
の4段階で⾊分けしている
● DBスキーマ危険度
○ ある時点のテーブルのレコード数やバイト数、どの変更がどこに影響
するかなどが書かれている
● ドメイン知識
○ 決済‧本⼈確認‧購⼊のためのルールなどの業務ルールを照合に使う
● 検出ルール集
○ 過去の⾒逃しから⽣まれたパターンを蓄積する
Slide 19
Slide 19 text
ハザードマップの作り⽅‧管理⽅法
• まずは⼈が⾒て区分をつけた
○ サービスの特性や、過去のインシデントを分析して、⼿で⾊分け
■ ビジネスロジック上、重要な領域
■ ホットスポット
■ 呼ばれる頻度が多く、落ちたり負荷が⾼まるとまずい領域
■ etc...
• そのあとは、改善ループを回しつつ、たまに⼈が⾒てチェック
○ DBの危険度（テーブルの⾏数‧サイズ）も同じやり⽅で最新化
• ⼈が⾻格を作り、メインはAI、たまに⼈がチェックして鮮度を保つ
Slide 20
Slide 20 text
適⽤する場所を限定する
• ハザードマップはかなり重要
○ そこがどれだけ重要なのかはAIには分からない
• AIレビューが⾃動で判断してmergeまでしているのは、戻せる‧直しやす
い‧壊れても影響が⼤きくない領域だけ
Slide 21
Slide 21 text
品質‧設計‧インフラを、3⼈の専⾨家が並列で⾒る
• シニアGoエンジニア：コード品質、規約準拠、テストカバレッジ
• シニアアーキテクト：設計整合、セキュリティ、ドメイン知識との照合
◦ セキュリティは認証バイパス‧情報漏洩‧インジェクションを具体に⾒
る
• GCP専⾨家：DBクエリ効率、インフラ影響、⾮同期処理が何度実⾏しても
壊れないか
• 3つのエージェントが同じPRを並列で⾒て、観点ごとに指摘を出す
○ 前スライドの判定の物差しやコンテクストを踏まえて、総合的に判断
する
Slide 22
Slide 22 text
毎晩、5つのエージェントがルールを改善する
● Measure
○ PR統計を集計する
○ 承認率、誤判定数、ルールの発⽕率
● Explore
○ リポジトリとインフラを巡回し、詰まりや未知のパターンを探す
● Improve
○ 検出ルールとパターン集を、実際に編集する
● Reflect
○ 翌⽇の優先順位を決め、各エージェントへの指⽰を⽣成する
● Audit
○ 全変更を検証し、改善が逆効果になっていないかをチェックする
Slide 23
Slide 23 text
ジャーナルで、昨⽇まで考えたことを引き継ぐ
• 各エージェントは、改善アクションをするにあたって考えたことを残すよ
うにしている
○ 前回までの判断記録である思考ジャーナルを毎回読み込んでから動く
○ 昨⽇なぜそう判断したかを引き継ぐので、毎晩ゼロから考え直さない
• ⼀度きりのブレと、繰り返し起きる本物の変化を、ジャーナルを⼿がかり
に⾒分ける
○ 本当に対応が必要な事柄に集中させる
Slide 24
Slide 24 text
効いていないルールを⾃動でアーカイブする
• 効きの薄いものを⾒分けるため、ルールごとの効き⽬をスコア化す
る
○ スコアの低いルールは、⾃動でアーカイブして外す
• ルール数には上限を設けて、増やしっぱなしにしない
○ ⾜すだけでなく捨てる仕組みがないと、ノイズが増えて精度が落
ちる
Slide 25
Slide 25 text
⾒逃しも拾ってルールに加えていく
● メインのAIレビューの⾒逃しに備え、外部のレビューツールも並⾏で動か
している
○ 外部のレビューツールがした良い指摘や漏れを取り込んでいく
● Measure Agentが、その指摘や漏れを記録する
● Improve Agentが、似た漏れや指摘が応⽤できる箇所が他にないか
を横断で分析する
○ そして新しい検出ルールを⾃動で⽣成する
● いろんな情報を⾷わせつつ、取捨選択させて育成をしている
○ これを毎⽇⾏う
Slide 26
Slide 26 text
どうやって投⼊していったか
• 過去数万件のPRをローカルAIで精査し、ルールとナレッジの初期データと
して投⼊した
• 最初の数週間はAIレビューはコメント投稿のみ⾏い、⾃動マージまではし
ないようにした
○ あまりにも厳しい判定が多い、と感じたので却下すべき理由がなけれ
ばApproveという考え⽅に⾄った
• そしてAIレビューbotがApproveするようになり、その後は⼈にチェック
をされることなく⾃動マージするようになった
○ ⾃動マージが少し怖かったのは事実
○ エンジニア全体としてのマインドチェンジは必要だった
Slide 27
Slide 27 text
マインドチェンジをどう進めていったか
• エンジニア間でレビュー待ちが⼀番のボトルネックであるという共通認識
があった
○ このボトルネックは解消しなければいけない、が...怖い
• 怖さを乗り越えられたのは「AIの精度が上がってきた」もあるが、それは
主要因ではない
○ 切り戻しがしやすい環境
○ ミッションクリティカルなサービスではない
→ 間違っても致命傷にはなりにくい
Slide 28
Slide 28 text
なぜApproveで⽌めずMergeまで⾏っているか
• mergeの遅れは後続のPRに芋づる式に伝播していく
○ スピードで戦うスタートアップには致命的
○ もし1⽇早くリリースできれば、1⽇分早く情報が⼿に⼊り、1⽇分早
く軌道修正できる
• 前提としてカウシェはtrunk-based developmentで開発している
○ いつ本番に出てもいい
○ Approveできる品質のものを、わざわざ⼿前で⽌めておく理由が無い
Slide 29
Slide 29 text
その安⼼‧安全は何を守るか、何の価値を産むか
● つい「安⼼」「安全」の⽅に倒したくなる
● でも「具体的に何が困るのか」を⾔ってみると、意外と出てこなかったりす
る
● 「本番に何が⼊っているか分からない」も突き詰めたら「なんとなく怖い」
● 本当に危険な箇所（ハザードマップ）は具体で⾔える
○ ⾔語化できない不安は切り捨てずに⼩さく試す
○ 怖いから、で⽌まらない
● 他と同じようなことをやっても同じような結果しか出ない
○ どこで差をつけるか
○ 少⼈数のスタートアップだからこそ取れるリスク
Slide 30
Slide 30 text
02
その後、開発のやり方と組織で何が起きたか
Slide 31
Slide 31 text
ボトルネックが解消され、PR数が5.5倍に増えた
• マージされたPRは5.5倍に増加（2025年6⽉→2026年5⽉）
• 同じ期間、開発メンバー数は2倍に増加
• 1⼈あたりがmain branchにmergeするPRは2.8倍に増加
Slide 32
Slide 32 text
事業には効いていそう
● 明確に事業は伸びた
○ 直近⽉ベースの年換算で売上⾼約71億円、売上総利益約62億円ペース
■ 1人あたりの売上総利益が約 1.6億円
■ GMV35倍、売上総利益411倍 (※FY23.8⽉→FY26.5⽉⽐較)
■ DAU81倍、APIトラフィック565倍 (※FY23.8⽉→FY26.5⽉⽐較)
● いろんな要因があるため相関関係をハッキリと特定することはできない
が、スループットの向上は⼀因ではありそう
● 代表note
○ https://note.com/kempei_monna/n/nc2e8417de104
Slide 33
Slide 33 text
なぜそう⾔えるのか？
• カウシェのtoCという事業ドメイン
○ AI x EC x ソーシャル という、不確実性の⾼い領域で事業を⾏っている
○ toBのSaaSみたく「これを作ると売上が⽴ちそう」みたいなものが少ない
• ディスカバリーの頻度を⾼め、インサイトを集め、より打率を上げていくこと
が重要
○ もちろん顧客インタビューなども⾏っているが、結局は想像でしかない
■ めちゃくちゃ考えたけどやってみなくちゃ分からないことはある
○ 試⾏回数を増やして、短いイテレーションで改善していくことが⾮常に重
要なフェーズ
■ その試⾏回数に効いた、と⾔える
Slide 34
Slide 34 text
⼈の⽬を介したコードのチェックは5件に1件へ
● 以前は、ほぼ全部のPRを⼈間が⾒ていた
○ 今は、⼈間が関与するのはおよそ5件に1件ほど
● 残りはAIレビューが⾒て、CIが通れば⾃動でマージされる
● ⼈によるレビューが無くなったわけではない
○ むしろ簡単にレビューできるもの、はなくなった
Slide 35
Slide 35 text
レビューの濃淡を、暗黙から⾔語化へ
• 以前はほぼ全PRを、広く浅く⾒ていた
○ というよりも濃淡を付けて、重要なものはしっかり⾒ていた
• 今は全部を⾒るをやめて、⾒るべき対象を選んだ
○ 結局は濃淡を⾔語化して、深く⾒るものを識別するようになった
○ ノールックLGTM的なPRはほぼ無くなった
■ 開発者の1件あたりのレビュー負荷は上がった
Slide 36
Slide 36 text
深く⾒るのは⾮機能要件と異常系
• 正常系はAIとテストでだいたい担保できる
• ⼈がしっかり⾒るのは、AIが想像しにくい以下の領域
○ 異常系
○ ⾮機能要件(件数‧スケール等)
• 特に効果的なのは、経験でしか知らない過去の地雷
○ 例えば、連携する外部SaaSが過去こういう障害を起こした
■ その挙動を踏まえた実装にする
• 明⽂化されていないと、AIには気づきにくい。
○ だから⼈がルールを⾒つける
Slide 37
Slide 37 text
同じ指摘をされないようにする
• 命名の揺れやレイヤー構造の逸脱は規約に⾜して、次からはlint‧実装
‧AIレビューの段階で弾く
• 過去の経験に根差した落とし⽳はナレッジや検出ルール集に残して、次か
ら⼈もAIも参照できるようにする
○ 例えば、連携する外部SaaSの過去障害を踏まえた防御など
• 指摘をその場限りにせず資産に変える
○ 同じ議論を⼆度しない
○ レビューの精度が積み上がる
○ ⼈は新しい観点に集中できる
Slide 38
Slide 38 text
アウトプットは5.5倍、判断を伴う仕事は1.5倍
● マージされたPRは5.5倍に増えた
● ⼈間がレビューに関与したPRは約1.5倍に増加
○ 判断を伴う仕事を1.5倍に抑えたまま、全体のアウトプットは5.5倍に
できた
○ しかし同じ期間に開発メンバー数は2倍になった
● 1⼈が判断するPRの件数は⽉25%削減したため、むしろ減っている
○ 作る量は増えたが、1⼈が下す判断の数は減った
● 判断の難しさ、理解すべき物事の総量は増加した
○ しっかり⾒るPRだけになってしまった
Slide 39
Slide 39 text
システムの安定性
● revert率は下がった
○ 3.8%→0.5〜0.9%
○ revertの絶対数は増えた：5件→20件前後
■ revert全部が障害と関係しているものではない
● 中規模以上の障害は月 1~6件で横ばいとなり、意外と変わらず
● AIレビューの見落としによる障害は？
○ あった
■ しかし、これを人間がレビューしていたとしても普通に見落としていた
ような事象だった
○ したがって、品質ゲートとしての AIレビューはちゃんと機能している
Slide 40
Slide 40 text
New comerの育成は？
• 仕組みとして、新規加⼊者にはAIレビューによるmergeまではさせないよ
うにしている
○ 意図は以下で、加⼊後3ヶ⽉はAIレビューのコメントのみにしている。
■ ⾃分が作ったものを正しく説明する経験を積ませたい
■ New comerと既存チームメンバーとの接触回数を増やしたい
■ ⾔語化できていない開発メンタルモデルの共有をしたい
■ コードをチームのものにしていく、という儀式をやりたい
• ⼀定これでなんとかなっているように⾒えている
○ (AIが出てくる前より) ⾃分が提出したコードが説明できるようになっ
たか、は正直なところ不明
■ 個⼈差ありそうだな、とは思っている
Slide 41
Slide 41 text
コードベースの品質は？
• 当初は「命名のばらつき」や「⾒通しの悪い構造」になっていくことを危
惧していた
○ 半年ほど経つが、意外とそこまで⼤きな問題にはならなかった
• 事前に「機能開発とは別に、コード品質の改善だけを⽬的としたPRを⽇
常的に出す活動」を開始していた
○ 活動に名前をつけ、毎週ちゃんと改善がなされているかをフォロー
アップする活動もしている
Slide 42
Slide 42 text
コードベースの品質は？
• むしろ組織拡⼤やビジネスドメインの拡張における、マイクロサービスや
依存関係の諸問題には直⾯している
○ レビュー云々関係なく、対処すべき問題は依然として存在する
• AIによっていろんな物事がスピードアップして、問題に直⾯するタイミン
グが⼿前になった(かもしれない)
Slide 43
Slide 43 text
03
次のボトルネック
Slide 44
Slide 44 text
次に詰まるのは『作る前』
• 実装 ~ レビューが早くなった分、詰まる箇所が『作る前』へと移った
○ 『作る前』= 何を作るか‧どう作るかを意思決定して、合意すること
○ AI云々関係なく、元から⼤事だった部分
• ⼭ほどある情報から、何を取捨選択して判断していくかがボトルネックに
なりうる
○ 判断の軸を⾔語化しないと、その⼈‧プロセスがボトルネックになっ
てしまう
Slide 45
Slide 45 text
開発⽂脈におけるボトルネック
• かつては設計、実装、PRを出す、レビューを待つ、指摘を直す、マージ、
QA、リリース
○ 今や実装 ~ マージまでが⼀瞬になってしまった
• QA⼯程もボトルネックではあるが、カウシェでは設計部分のボトルネック
の⽅が詰まっている
○ ここさえ正確にできれば、あとは⼈が介⼊することなくコーディング
エージェントが複数の開発施策を並列でやれるようになるのでは、と
考えている
Slide 46
Slide 46 text
それって設計して誰かに委託と同じでは...？
● Yesでもあり、Noでもある
○ ただ、今や実装に数ヶ⽉かかるような時代ではない
■ 数ヶ⽉経って出てきたものが想定していたものと全然違う、みたい
な世界ではなくなった
■ 委託先が爆速かつ⾃分にとってかなりコントローラブルになった
○ できるだけ最初からベストな設計をして、あとはよろしく〜がもし可
能なら、それがベストなのではないか
Slide 47
Slide 47 text
実装してみなくちゃ分からない、で⽌まらない
● 実装して初めて分かることや、よりベターな選択肢は出てくる
● しかしそれは最善を模索しない理由にはならない
■ 最善を考えるコストを、後の実装フェーズまで持ち越す必要はない
● 今や考えるコスト⾃体も安くなっている
○ 誰かに時間かけて実装してもらうのではないのだから、後から良い案
が浮かべば変更すれば良い
■ 変更コストも安くなっている
Slide 48
Slide 48 text
ベストであることを合意する、というボトルネック
• 『なんでこれをやるんだっけ、なぜこの⽅法にするんだっけ？』の妥当性
をチームで合意する
○ 本当に現時点でのベストか？の検証フェーズ
○ コードの1⾏ずつではなく、なぜそうしたかという意思決定に責任を持
てるようにする
• 他の⼈にこれが現時点でのベストであることを合意してもらうのはタフな
作業である
○ まずは⾃分⾃⾝、他の⼈に説明できるように理解する必要がある
○ これをサボったツケが理解負債というものになる
Slide 49
Slide 49 text
結局最も変わったのはなんだったのか
Slide 50
Slide 50 text
仕事の抽象度が⼤きく上がった
「書く‧読む‧判断する」から、「どうあるべきか」を考える頻度が増えた
Slide 51
Slide 51 text
ベストを模索し、説明可能にする仕事
• コードの⼤半はAIが書けてしまう
○ しかし⾃分なりにベストを模索して、最適解を模索し続ける責務は
残っている
• そして、それを他⼈でも理解できるように「説明可能な状態」にすること
○ これは合意を得るための「作業」ではない
• 説明できるようにするまでの過程でこそ、理解そのものが磨かれ、そこか
らさらに最適なものが浮かび上がってくる
○ ただし⼈間の理解できる量には限界があるので、全部を理解し続ける
のはどこかで破綻する
○ 理解しなくていい領域を仕組みで広げ、理解は本当に必要なものへ集
中させる
Slide 52
Slide 52 text
まとめ
• 01: どうやって83%まで上げたか
○ 仕様‧実装計画‧規約の前提の上にAIレビューを載せて、毎⽇改善さ
れる仕組みを作った。
• 02: その後、開発のやり⽅と組織で何が起きたか
○ PRは5.5倍。⼈間のレビュー負荷は上がった。
• 03: 次のボトルネック
○ 実装よりも合意。仕事の抽象度が上がった。
Slide 53
Slide 53 text
告知
●
📣 採⽤中 📣
○ Backend、Mobile、Platform、ML/DS、Data、EM、VPoE、PdM、Designer …
●
📣 7/24(⾦曜) 1930〜 渋⾕カウシェオフィスにてMeetUpを開催 📣
○ 「カウシェって実際どんな感じなのか」
○ 「中の⼈に直接はなしを聞いてみたいな」
Slide 54
Slide 54 text
ご清聴ありがとうございました