コードレビューのボトルネックを"する側"と"される側"の両面から解消する

2026/09/30
コードレビューどうしてる？ ボトルネックに向き合う仕組み化Tips共有会 @ファインディ／Findy
https://findy.connpass.com/event/406145/

Transcript

1. コードレビューのボトルネックを "する側"と"される側"の両面から解消する 鈴木 雄大（yub0n） 2026.09.30
2. 自己紹介 ・atama plus プロダクトエンジニア − 2022年 atama plus 入社 − 塾向けSaaS事業、フロントエンド刷新を経験 − いまは従業員教育事業で「Sketto」を開発 − 開発プロセスとレビューの仕組みづくりも担当 鈴木 雄大 @yub0n 業務習得AIシステム「Sketto」のAIロープレ画面 2
3. atama plusとは：事業内容 AI教材「atama＋」を開発・提供しています。 atama＋は、AIが一人ひとりの 得意、苦手、伸び、つまずき、 忘却度などの情報を収集・分析して、 一人ひとりに合った 「自分専用カリキュラム」を提供します 3
4. AIエージェントは どんどんPRを作ってくれる。 けれど、人間のレビューが追いつかない。 レビュー待ちのPRが、目に見えて溜まっていく。 © atama plus Inc. 4
5. ボトルネック 詰まっていたのは一か所ではなかった レビュイー側 AIの出力を見きれないまま出し、 PRの品質にばらつきが出る 品質が不十分なPRほど、 レビューが重くなる レビュアー側 レビュー待ちが溜まり、 「誰が見る？」のお見合いになる レビュアー側だけ直しても、品質の低いPRがまた溜まっていく © atama plus Inc. 5
6. 考え方のポイント レビュー待ちのPRは レビュアー側だけ直しても減らない。 1. PRを出す前 2. PRを見るとき 3. PRをマージしたあと この3か所すべてに手を入れる リードタイムは1/3に縮み、マージされたPRは2.7倍に増えた 2025年11月 → 2026年3月の比較 © atama plus Inc. 6
7. 1. PRを出す前 人に頼む前にAIレビューで指摘を解消しておく ・PRの作成とpushのたびに自動レビュー 人が見る前に、機械的な指摘は片付く ・観点ごとにサブエージェントを分業 全観点を1つに積むと、注意が薄まる ・確信度スコアで報告を絞る 閾値は観点ごとに変える ・ にしてから人に頼む、が習慣になった 緑にならないPRは、レビューに出さない ・PRの変更規模も自動で判定 かつ規模が小さいときだけ自動Approve © atama plus Inc. 結論は3段階： マージ可能 / 軽微修正後 / 要修正 Approve まで自動。マージは人が押す 7
8. 2. PRを見るとき 毎朝の名指しでお見合いをなくす ・毎朝のチームミーティングで、 「本日のレビュー担当者」を名指しする ・技術的には新しくないが一番効いた ・溜まる原因の多くは 「誰かがやるだろう」 だった © atama plus Inc. 朝会で話す事項を投稿するスレッド。 必ず見る場所なので、スレ元に レビュー待ちPRの一覧へのリンクを置く 8
9. 3. PRをマージしたあと 不具合がすり抜けていないか定期的に巡回する ・人が見ていない分を後から見直す 小さなPRは自動Approveでマージされる ・月・水・金の朝8時に自動起動 直近3日にマージされたPRを再点検する ・見つけたものは2つに分ける − A：明らかな不具合 → 修正PRを自動作成 − B：不具合の疑い → Slackで人が判断 ・「確信がなければ必ずBに倒す」 偽陽性で乱立すると、誰も見なくなる © atama plus Inc. Devin が Slack に投げる巡回レポート 9
10. 補足 ここまでの仕組みは記事に詳しく書いています ・AIコードレビューの構成 − GitHub Actions の YAML − 観点ごとの確信度の閾値 − 初回と再レビューの切り替え ・日次の担当アサインの運用 ・マージ後の定期巡回 − Devin の Playbook ・AI向けのルールとスキルの置き方 © atama plus Inc. 10
11. 運用を続けながら改善したこと 2026年4月 → 2026年9月（5か月）
12. 運用を続けながら改善したこと 人の指摘と不具合の修正から学習のループを回す その場で直して終わりにすると、同じ指摘がまた来る 学ぶ元 PRの指摘コメント 不具合の修正PR 定期的に自動で抽出 反映は人が承認する 上流の層に書き足す ルール テスト レビュー観点 次の実装とAIレビューに効く。それでも残った指摘が、また学ぶ元になる © atama plus Inc. 12
13. 運用を続けながら改善したこと レビューの指摘を止めるべき層に戻す レビュー用のAIに覚えさせるだけでは、同じミスは作られ続ける 1 実装 2 機械チェック 3 AIレビュー 4 人間レビュー 作り込ませない / ルール・スキル・ガイドライン 決定論的に弾く / テスト・lint・型チェック・CI 検出する / レビュー観点の追加 判断が要るものを見る / 設計・仕様の妥当性 上の層ほど 早く・安く止まる 下の層ほど 遅く・高くつく 指摘ごとに、次はどの層で止めるかを決めて戻す。 反映は必ず人間が承認する。AIが勝手に書き足すと、誰も知らないルールが増える。 © atama plus Inc. 13
14. 運用を続けながら改善したこと 決定論的に検知できるものはリンターへ移す AIレビューは確率的。同じPRでも毎回同じ指摘が出るとは限らない リンターへ移せる規約の例 この場所ではこのライブラリを使わない エラーの握りつぶし（空の catch など） 色は直接書かず、デザイントークンを使う 決めたレイヤー構造に反する参照 検知の手段 lint の設定1行 構文で検索する（ast-grep） 正規表現 依存関係の解析 毎回同じ答えになるものはリンターへ。 判断が要るものはAIと人に残す。 AIのトークンを使わずに済み、レビューを待たずに出す側が自分で直せる。 © atama plus Inc. 14
15. 運用を続けながら改善したこと その他の細かい改善 ・AI関連のコストが爆発した。当初はpushのたびに再レビューが走っていた → 自動実行は初回だけにし、再レビューはPRコメントで明示的に依頼する ・再レビューで毎回全体を見直すと、範囲が広がって精度が下がり、トークンも食う → 再レビューは前回レビュー以降の差分だけに絞る ・誤指摘が積み上がると、AIのレビュー自体が読まれなくなる → AIが指摘をPRに書き込む前に、検証専任のエージェントを1段挟む © atama plus Inc. 15
16. まとめ 持ち帰っていただきたい2つ 1. レビュー待ちのPRはレビュアー側だけ直しても減らない 出す側のPRの品質がばらつくと、見る側のレビューが重くなり、レビュー待ちが溜まる。 出す前・見るとき・マージしたあとの3か所すべてに手を入れる 2. 指摘はより上流で決定論的に止める レビューの指摘は使い捨てにせず、生まれる手前の層に戻す。 確率的なAIレビューに頼る部分を減らし、リンターやテストで必ず止まるものを増やす © atama plus Inc. 16
17. ともに “Wow students.” を届ける仲間を募集しています！ 「atamaplus 採用」 @atamaplus_dev
18. ご清聴ありがとうございました