AIにレビューとマージを任せる仕組みのつくり方 / how to build a system that lets AI handle code review and merging

Transcript

1. AIにレビューとマージを任せる 仕組みのつくり方 株式会社kickflow / 森本 勝哉 「AIを"使う"から"組み込む"へ」 2026-09-14
2. 自己紹介 © kickflow, Inc. 森本 勝哉 kickflow 開発チーム エンジニアリングマネージ ャー バックエンドを中心に、フルスタック・フルサイ クルで開発も エンタープライズ向けの汎用ワークフローSaaS 「kickflow」を開発 2
3. 前提 少人数（当時） 開発チーム ＋ EM 1名 モノレポ Rails + Nuxt 高頻度リリース GitHub CodeRabbit Claude / Codex コード管理・CI/CD © kickflow, Inc. AIレビュー ほぼ毎営業日 AIコーディング 3
4. きっかけと課題
5. きっかけは、生産性2倍という目標 目標 AIを活用して 生産性2倍 → 逆算 2倍になったとき 詰まるのは レビューだと考えた 選択 人の努力に頼らない → AIと仕組みに任せる 全部AIに任せるのは違う（レビューはドメイン知識共有の場） とはいえ全部人間は限界 → その中間を、仕組みで解決する © kickflow, Inc. 5
6. どういう仕組みにしたか
7. AIに任せる範囲を決め、それを支える2層構造 非決定論的な AI判定 を、決定論的な 土台 でカバーする 判定：非決定論的仕組み（同じ入力でも揺らぐ） A. 影響度ラベル判定 ↑ 土台でカバー ↑ 土台：決定論的仕組み（同じ入力に同じ出力） C. CODEOWNERS © kickflow, Inc. D. Branch Protection B. AIレビュー E. オートマージ機構 7
8. 影響度ラベルで、AIに任せる範囲を決めた XS S typo / コメント 設定値変更 AIレビュー i18n / テスト追加 小規模バグ修正 AIレビュー M 単一機能の 追加・改修 AIレビュー ＋人のレビュー L 複数機能・DB API仕様変更 AIレビュー ＋人のレビュー XL 認証 不可逆な設計 AIレビュー ＋人のレビュー PRごとに変更の影響度を XS〜XL の5段階でAIが自動付与。pushのたびに再評価、自 己申告は不要 参考: GMOペパボ「PRのレビューが追いつかない！もう人間がボトルネックなので、気合いではなく仕組みで少 しずつなんとかしていく」 https://zenn.dev/pepabo/articles/ai-pr-review-bottleneck © kickflow, Inc. 8
9. 判定：非決定論的な仕組み A 影響度ラベル判定 AIが差分を読んで XS〜XL を 付与。pushのたびに再評価、 自己申告は不要。このラベル で「AIに任せる範囲」が決ま る B AIレビュー（2本立て） ① CodeRabbit 規約を教え込んだ網羅レビ ュー。全PRで実行。XS・S は Approve がマージ条件 ② GPT CI上で走る第2のレビュア ー。指摘だけの参考扱いで マージは止めない。月 3,000回超 AIレビューは2本立て。マージを止めるのは CodeRabbit だけ © kickflow, Inc. 9
10. 土台：決定論的な仕組み C CODEOWNERS DBマイグレーション・設 定・CI/CD・AIが読むルール など高リスクパスは人の Approve 必須。AIが誤判定 してもここで止まる D Branch Protection 1 Approve 必須・直接 push 禁止などのルールを設 定できる。ラベルの付け忘れ や Bot の見落としもここで 止まる E オートマージ機構（自前） CI完了をフックし、実行され た全ジョブの成功＋ CodeRabbit Approve を確 認してマージ。標準の必須ジ ョブは動的なジョブ構成に合 わないため自作。変数1つで 停止 GitHub標準の2つ＋自前の1つ。AIが間違っても、ここで止まる © kickflow, Inc. 10
11. 仕組みを作っていく過程で、想定外だったこと GitHub の Branch Protection が使えない 1 必須ジョブは静的指定のみで、変更ファイルでジョブが変わる kickflow では全指定で も未指定でも破綻 → 実行された全ジョブを動的に判定するオートマージ機構（自前）を用意 Renovate 標準のオートマージも使えない 2 原因は ① と同じ（ライブラリごとに走るテストが変わる）→ オートマージ機構（自 前）に統合 リリース戦略が、オートマージ機構と相性が悪い 3 develop が更新されるたびにE2E実行環境にデプロイされる → 進行中のリリースPR のE2Eがやり直し → release ブランチ方式へ © kickflow, Inc. 11
12. どのように導入したか
13. 影響度ラベル判定ロジックを分離し、試算してから広げた Skillsに分離 判定ロジックはスキルファイル だけ YAMLもBotも触らない 手元で試す 過去PRで試算 本番に出す前に過去PRで検証 → Claude Codeから同じ判定を → 実行 基準変更のたびに再実行 CIなしで試行錯誤 過去PRの試算で XS＋S は 65%。運用後、直近3か月の実績も 67% XS 27% ← AIに任せる（67%） S 40% M 23% L XL 9% 2% 人間が見る（33%）→ 実績: 2026-06〜08 の人間起票マージPR N=716（bot除く）／試算: 過去PR N=1,255 © kickflow, Inc. 13
14. 効果
15. 効果：小さなPRが、放置されず流れる 同じ小さなPR（XS・S、QAなし）がマージされるまで（営業時間 換算・中央値） 約5時間 → 26分 オートマージ導入前 オートマージ導入後 参考: LinearB（DORA の Four Keys などの開発生産性指標を計測するツール）のPRベンチマ ーク（810万PR）では、PR公開→マージはEliteなチームでも4時間未満。kickflowの数字は impact/XS・S限定でスコープは異なる（2026-07時点） © kickflow, Inc. 15
16. 減らした「作業」が、生産量に変わった 91% AIコーディング率 （Co-Authored-By 基準） 2.1倍 チームのマージPR （前年同期比） 3,000+ AIレビューの実行数／月 2026-06〜08 の実績。AIレビュー実行数は GPT レビューのワークフロー実行回数（202608: 3,180回）。CodeRabbit は別途全PRで実行 © kickflow, Inc. 16
17. まとめ
18. 私たちの仕組みの「つくり方」 1. 人に残す判断を決め、残りは作業から任せる 2. 提案 → 承認 → 自動化と、段階的に上げる 3. 止め方をセットで設計する 4. 計測して確認し、ルール自体を育てる © kickflow, Inc. 18
19. ご清聴ありがとうございました