Pull Request、AIレビューだけでマージしてOK？

プロダクト開発、AIに丸ごと任せられるのか？Meet up！ AI時代のレビュー、どこまでどう任す？ のLT資料です
https://findy-aiplus.connpass.com/event/397873/

Transcript

1. Pull Request AIレビューだけでマージしてOK？ 2026/07/02 プロダクト開発、AIに丸ごと任せられるのか？Meet up！ 株式会社TOKIUM Webエンジニア 坂上 晴信
2. 坂上 晴信 Harunobu Sakaue 経歴 1995年生まれ。東京の離島・伊豆大島出身。 エンジニア → DevHR（= 開発組織専任の人事）→ エンジニア 2016年 3月 東京高専 情報工学科卒 2016年 4月 株式会社TOKIUM 入社 Android/Webエンジニア 2023年 1月 DevHRにロールチェンジ 育成・組織づくり・採用広報 2025年12月 再びエンジニアにロールチェンジ Webエンジニア NOW! 自己紹介 / リアルのすがた ⚫︎ ⚫︎ ⚫︎ ⚫︎ ⚫︎ 2
3. にしこりさぶろ〜 @subroh_0508 好きなもの Kotlin / アイドルマスター / ラブライブ！ Kotlin本体へのContribute経験、Kotlin Festへの複数回の 登壇経験アリ。DevHR時代も趣味でKotlinを書き続け、 "200名収容の会場で技術登壇をした人事"になった。 プライベートでは、アイマスPとライブライバーを兼任。 『シャニマス』三峰結華と『蓮ノ空』村野さやかが 人生のロールモデル。 自己紹介 / インターネットのすがた 3
4. 僕がリードする新規開発PJで、最近 「Pull Requestに対する人間の承認の要否基準」 を策定 なぜ作ったのか？ どのような基準か？ AI駆動開発で意識しているポイント 今日話すこと 4
5. コードレビューにまつわるスキルが複数存在し、特に使われるのが以下の3つ code-review 30超の観点で Pull Request を SubAgent立てて並列レビュー 指摘は重要度を3段階に分類 review-respond 投稿された指摘から 修正計画を立案 → 指摘を反映 スコープを広げる指摘は Jira 起票で後回し提案もする pr-merge-gate マージ可能かを最終判定 致命バグ・仕様乖離がないか 不可逆変更がAIレビュー のみで通過してないか etc. 現状: 3つのレビュースキル PJスタートから半年、悪戦苦闘の末に到達した3スキル 今のところ めちゃめちゃイイ感じで回っている 5
6. Merge Blocker 0件 = 品質は閾値をクリアしたと言える しかしマージボタンを押そうとした時、 そこはかとない不安や迷い が生まれる 現状: AIレビュースキルの品質が上がると… Merge Blocker 0件です！ 一方で、軽微な懸念もN個あり〜 （訳: 軽微な懸念、ちゃんと読んでね！） ブロッカーないなら、ノールックで マージしてもええか…？ Merge Blocker 0件です！ ただ、◯◯は人間の判断をはさみたく〜 ブロッカーないけど、何となく不安！ ✕✕ さんレビューお願いします！ AIがブロッカーないと言ってるのに、 何をレビューすれば…？ 6
7. コード品質の直接的な担保だけが、コードレビューの目的でないから！ Google Engineering Practices Documentation - The Standard of Code Review zenn.dev/baleenstudio - コードレビューとはなにか なぜ不安や迷いを感じるのか？ The primary purpose of code review is to make sure that the overall code health of Google's code base is improving over time. （訳）コードレビューの主な目的は、Googleのコードベース全体の健全性が時間とともに向上している ことを確認することです。 “ コードレビューとは、このメンタルモデルをチームで共有する行為と言える。 レビュアーはコードを読むことで書き手のメンタルモデルに触れ、自らのモデルと照合する。 設計の意図、トレードオフの判断、変更の影響範囲。これらの共有こそがレビューの核心である。 “ 品質指摘 & 修正だけのAIレビューでは、メンタルモデルのチーム共有 は実現できない 7
8. じゃあ全部レビューしよう！ 8
9. 2月下旬〜3月上旬、1日9〜11件（中央値）のPull Requestを捌いていた時のスタッツ 本当に死にかけた じゃあ全部レビューしよう！…とはならない AIが作ったPull Requestの全件レビュー これは現実的に不可能！ 9
10. Pull Request を2種類に分類 分類基準として4つの軸を言語化 解決策 10
11. 「変更のマージに議論・FB・承認が必要か否か」 で、Pull Requestを分類 Ask チーム内での議論・FBを通し、明示的な 承認がなければマージがブロックされる Show CI/CDとAIレビューが通ったらマージOK、 議論・FBは必要に応じて非同期に実施 martinfowler.com - Ship / Show / Ask 解決策: Pull Requestを2種類に分類 Ship/Show/Ask is a branching strategy that combines the features of Pull Requests with the ability to keep shipping changes. （訳） 「Ship/Show/Ask」は、プルリクエストの機能と、変更を継続してリリースし続ける能力を 組み合わせたブランチ戦略です。 “ 11
12. 軸A 変更リスク DBスキーマ/移行、外部連携I/F、認証/認可/署名/ 秘密情報、課金・決済、破壊的変更 軸B AI判断信頼度 AIレビューが人間判断必須と判定した場合、 または意図ドリフト検出 軸C 規模・複雑度 実ロジック差分が大（目安 ≧ 約500行） 、 または多レイヤ横断 軸D 新規の意図・意思決定 新規ADR、新規ユースケース仕様の初版、 ハーネス/スキル設計の方針変更 いずれか1つでも当てはまれば Ask → 人間の承認が必要 全て当てはまらなければ Show → AIレビューのみでマージOK 解決策: Ask判定のための4つの軸 12
13. ADRを作ってチームに導入したところ、手応えはバッチリ！ マージ加速 AIレビューのみでマージ完了できる Pull Requestが早速生まれた 納得感のあるレビュー Ask判定にも明確な理由があり、 納得感をもってレビューに臨めるように AI指摘への対応モチベ Showに近づけたい意思が働きやすく、 AIレビューの指摘を真剣に読み込むように ※ハック防止の仕組みが別途必要 早速使ってみた 13
14. AIが提出するPull Requestはこれからも増え続ける ので、 AIレビューだけでマージできるPull Requestは増やさねばならない AIに何かを委譲したくなったら、 意思決定・評価の基準を 作りにいく と良さげ 意思決定・評価の基準は "いま、この瞬間の正解" として扱う "絶対の正解" を追わない まとめ 14
15. 資料公開＆技術発信は公式Xから 本日のスライドは公式Xで公開！ 開発チームの技術やイベント情報を 発信中、フォローお願いします！ @TOKIUM_Dev 情報発信中！ 15