AIレビューはどこまで任せられるのか？自動化と人が背負うレビューの境界

■ イベント
レビュー、どこまでAIに任せられる？ — AIコードレビューツールの選択肢と実践
https://techplay.jp/event/997847

■登壇概要
タイトル：AIレビューはどこまで任せられるのか？自動化と人が背負うレビューの境界
登壇者：技術本部 Bill One Engineering Unit 小木 大嗣

■ 技術本部 採用情報
https://media.sansan-engineering.com

Transcript

1. AIレビュー どこまで任せられる か 自動化と人が背負うレビュー 境界 Bill One Engineering Unit 小木 大嗣
2. 会社概要 1 本社 神山ラボ Sansan Innovation Lab 社　名 Sansan株式会社 所在地 本社 東京都渋谷区桜丘町1-1 渋谷サクラステージ 28F グループ 会社 Sansan Global Pte. Ltd.（シンガポール） Sansan Global Development Center, Inc.（フィリピン） Sansan Global (Thailand) Co., Ltd.（タイ） ナインアウト株式会社 株式会社言語理解研究所 Eightキャリア株式会社 従業員数 2,077名（2026年5月31日時点） 2007年6月11日 設　立 支店：関西支店、福岡支店、中部支店 サテライトオフィス：Sansan神山ラボ、Sansan Innovation Lab、Sansan 長岡ラボ 拠　点 寺田 親弘 代表者
3. 小木 大嗣 Sansan株式会社 技術本部 Bill One Engineering Unit 普通 エンジニアです AI駆動開発ギルド ギルドマスターをやっています > BillOneで メイン タスク以外を行う時に有志を集めて横串チーム を作る時があります。誰でもチームを作ったり、チームに入ったりできま す。それがギルドです 今日 スライド Geminiにきれいにしてもらいました🐤
4. 今日お話すること 01 Qodo導入で何が変わったか 02 AIに任せやすいレビュー / 人に残すレビュー 03 導入後、社内でどう学習可能なループを構築したか
5. じめに今日 結論から AIレビュー 、人間レビューを消す仕組みで ない AIが拾える指摘を前段に移し、 人間が責任を持つべき判断を明確にする仕組みである
6. AIで増える 完成品で なく変更案 AIで くなる 「変更案」 生成 実装案・テスト案・レビュー観点 生成など、 AI 多量 「案」 を高 に出力する 具体例: 実装案、テスト案、PR説明、レビュー指摘、修正候補など 安全に める「受け止め」 仕組みが必要 組織として安全性を担保しつつ加 するに 、 AI案を適切に 扱う仕組みが不可欠 具体例: AI案 採用判断、仕様判断、リリース判断、失敗時 戻し方など AI アウトプット量を増やすが、それ そ まま価値に直結しない レビュー、テスト、リリース判断という各種ゲートを通って初めて組織成果となる
7. Qodo導入で何が変わったか
8. Qodoを何として使っているか Qodo Merge 、PR上でAIによる一次レビューを行うため ツール 今回 発表で 、単なる便利ツールで なく、レビュー運用に組み込むゲートとして扱う 観点 Qodoに担わせたこと PRフロー接続 PR上で一次レビューを自動実行 指摘 ケアレスミス、既知パターン、テスト観点、 best practice 人間と 関係 AI指摘を見たうえで、人が仕様・設計・影響を判断 運用・ナレッジ 指摘内容を調整し、採用率や品質改善につなげる rules / Knowledge DB へ社内知見を戻す 内製でも同じ構 を作れるなら成立する。 専用ツール 価値 、PRフロー・可視性・運用・計測 を組織としてまとめて載せやすいこと。
9. Qodo導入でまず分かったこと Qodo Merge導入後、Findy Team+でBefore / Afterを検証 リードタイム、スループット、 ROIなど データで「効いた」と説明可能に リードタイム 35.7 h ▼45% 19.6 h スループット 0.028 PR/h ▲82% 0.051 PR/h 年間ROI 545% 感覚で なく データで「効いた」と証 明！ 参考: AIツール 本当に効く か ? Findyで検証するQodo Merge導入効果
10. 本当に変わった レビュー 役割だった 数字以上に大きかった変化 、レビューを人が全部見る状態から、 AIが一次観点を出し、人が本質的な判断をする役割分担が生まれたこと Before 人が全部見る 人が差分を見て、細かい指摘も本質 判断も全部やる  After (AIと 役割分担 ) 🤖 AIが一次レビュー 󰞵 人が仕様・設計・影響範囲を見て責任を持って判 断する リードタイム短縮 結果であり、構 的に レビュー 前段に AIが入り、 人間 レビュー対象が変わった ことが本質的な変化
11. AIに任せやすいレビュー / 人に残すレビュー
12. AI一次レビュー → 人による判断：役割 分担と統合 Qodo レビュー代替で なく、レビュー前段 「ゲート」として機能する 🤖 AIに任せやすい (一次レビュー ) • 表記・規約・命名 チェック • 重複・漏れ・境界条件 検証 • 既知 バグパターン・ミス検出 • テスト追加候補 提案 • ベストプラクティス違反 指摘 󰞵 人に残す (最終的な判断 ) • 要件・仕様・設計意図と 妥当性 • 顧客・業務へ 影響範囲 考慮 • セキュリティ・権限・課金 責任判断 • ど リスクを許容するか 意思決定 • 最終的なマージ・リリース可否判断 AI 見るべき観点を増やし技術的見落としを減らす一方で、 「なぜそ 変更を行うか」「最終的な責任」 常に人間に残る
13. 導入後、社内でどう学習可能な ループを構築したか
14. 2024 導入・チューニング 効果測定 2025 ポストモーテム連携 指摘採用率分析 CodeRabbitなど他ツール分析 AI指摘確認Bot 2026 ポストモーテム構 化 Qodo V2 / Knowledge DB 検証 AIナレッジ化 そ 後、社内で 何を育てたか
15. 効果測定 リードタイムから指摘採用率へ • 導入初期：リードタイム・スループット・ ROIを観測 • 導入後：AI 指摘が実際に開発フローに採用されたか（指摘採用率）へ変化 Qodo Merge 指摘採用率 例 Frontend: 27.76% Backend: 24.57% AI利用が当たり前になると生産性へ 寄与 切り分け困難になるた め、指摘そ も が採用されたか を見る方向にシフトしていく 次 問い：ど リポジトリで効く？ど 指摘が採用される？なぜ採用されない？
16. ポストモーテムを AIで活用する 最終目標：半自動品質学習ループ 構築 01 インシデント発 生 02 ポストモーテ ム 03 原因・再発防 止策を構 化 04 rules / Knowledge DB追加 05 AIが利用 06 失敗を減らす せっかく書いたポストモーテムが 誰も読まない資料で終わらせない仕組み を作る
17. AI導入で組織が設計すべきも 設計すべきな ツールやそ 使い方そ も で なく、 運用 構 • 判断 ために何を観測する必要があるか • AI ど 提案を採用したか • ど 判断を人間に残すか • ど 失敗をナレッジ化するか • ど ツールが生き残っても回る形にするか 本質 ツールをどう日々 組織運用に接続するか ツールが変わっても、観測・判断・学習 構 が残ることが重要
18. AI 、成熟した開発組織にも、初期スタートアップ ような変更圧を持ち込む。 規律が弱い場合 • 変更量だけが増え、レビュー・テスト・リリース判断が追いつか ない。 • 組織ステージと開発運用 段階にギャップが生まれる。 規律がある場合 • AI 変更圧を受け止めながら、探索 度を上げられる。 • 安全性を保ちつつ、スタートアップ的な試行回数を取り戻せ る。 AI時代 差 、コードを書く さで なく、 増えた変更量を受け止める規律 に出る。 最後に少し余談： AI 変更圧を増幅する話
19. AIレビュー 人間を代替するも で ない AIが拾える指摘 前段に移し、人間が責任を持つ判断を明確にするも Qodo導入で見えたこと 1. AIレビュー リードタイム短縮に効く 2. ただし価値 、レビュー分業 再設計にある 3. 指摘採用率を見ると、AI 効き方が見えてくる 4. ポストモーテムを用いて、品質学習ループにする AIレビュー 個人ツールから組織学習ループを回す部品 一つへ まとめ
20. 参考リンク Vol. 05【Qodo Merge（旧PR-Agent）】Bill Oneで AIコードレビュー 取り組みと得られた結果 https://buildersbox.corp-sansan.com/entry/2024/12/11/000000 リードタイム 45%短縮・スループット 82%向上。Sansanが Findy Team+で証明した 「AIレビュー 投資対効果」 https://jp.findy-team.io/blog/ai-casestudy/ai_effectiveness_verification_sansan/
21. Sansan 技術本部 募集ポジション紹介 https://media.sansan-engineering.com/
22. 1. リードタイム短縮やスループット向上 、本当に Qodo 効果？ • 厳密な因果効果として言い切れないが、導入前後 PRデータ比較で統計的な改善傾向を確認。効果 根拠となる材料に なった。 2. ROI 545%という数字 前提 ？ • レビュー時間削減を人件費換算し Qodo利用料と比較した試算。会計上 厳密な効果で なく、意思決定 ため 概算。 3. Before / After比較だと、期間要因や慣れも混ざる で ？ • Yes。理想 比較実験だが現実的に 困難なため、継続的なデータ観測を重視している。 4. AI利用普及でリードタイム測定が難しくなる理由 ？ • 複数 AIツール（Claude Code, Codex等）が工程に混在し、個別 寄与分を切り分ける が困難になるため。 5. 指摘採用率と ？ • AI 指摘が実際に修正に取り込まれた割合。開発フローへ 浸透度を見る指標だが、完璧で なく継続観測用。 6. 指摘採用率 20〜30% 妥当？ • 高すぎるとAI以前 問題、低すぎると AI 有用性に疑問。 20〜30% AI指摘が適切に判断材料になっていると見ている。 7. 採用率だけで 重要指摘 無視を見落とさないか？ • Yes。不採用指摘 中身や、実際 障害・ポストモーテムと 関連性も併せて確認する必要がある。 8. AIレビューで人間レビュー 減らせる？ • 削減可能だが、「人間が注力すべき対象を変化させる」という捉え方が正確。 想定問答集 1
23. 9. AIに仕様や設計判断まで任せる 難しい？ • AI 仕様書や設計ドキュメントを参照して矛盾やリスクを指摘すること できて、非常に便利だが、「こ 仕様で顧客に出してよいか」「こ リスクを許容するか」「こ 設計を チーム 方針として採用するか」など 、組織やチーム 責任判断になる。 10. AIレビューで逆にコメントが増えて、ノイズになる？ • なる可能性 ある。よって導入後 チューニングが重要。 AIレビュー 入れて終わりで なく、指摘 質と量を継続的に調整する必要がある。 11. Qodo、CodeRabbit他ツール 違い どう見る？ • 機能表だけで 判断しづらい。実際 フローに入れたときに、開発者が使うか、指摘が採用されるか、ノイズが多すぎないか、社内ルールやポストモーテム 学びを反映可 能かなどを見て判断すべきと考える。 QodoとCodeRabbit 実際に使った個人的印象 、 Qodo ルールベースが強く、 CodeRabbit ベストプラクティスに従う傾向にあり、狭 く深く見るならQodo、広く浅くならCodeRabbitが良い印象。企業統制を考えるとポータルサイトでルールを管理できる Qodoが強い印象 12. 内製AIレビューで なく、専用ツールを使う理由 ？ • 内製 自由度が高い一方、運用コストも高くなる。有志ギルドで 手を出しにくく、組織規模次第でおそらく専用チームが必要になる。専用ツール フローへ 組み込み、 UI、権限、運用、継続改善 面で楽。 13. ポストモーテムをAIに読ませるだけで ダメ？ • ポストモーテム そ ままだと AIに ノイズが多い。重要な 、原因、再発防止策、レビュー観点、対象領域、 trigger条件を構 化することだと考えている。「こ 種 変更 、こ 観点を確認する」という形式まで詰めないと、必要な場面で AIが使えない。 14. ポストモーテム 学びをAIレビューに戻すと、どういう効果が？ • ポストモーテム 書いた直後 学びになるが、時間が経つと読まれなくなりがちで横展開もされにくい。 AIに接続できれ 、過去 失敗パターンがレビューや開発時に観点と して出て、障害対応 学びを人間 記憶に閉じず開発フローへ戻せる可能性がある。 15. 品質学習ループ もう完成した？ • No。手動作業を含めたパイプライン 構築したが、まだまだ構 化や Knowledge DB連携を検証している段階。重要な 完成形を一気に作ることで なく、ポストモーテ ム 学びをAIが使える形に変換する流れを構築することだと考えている。 想定問答集 2
24. 16. 開発者がAIレビューを無視しないようにするに ？ • 指摘がノイズだらけだと見られない でまず クオリティを上げること。そ うえで、 AI 指摘確認を促す botや運用ルールを入れるとよいと思う。開発者 行動に接続するよ う設計する必要がある。 17. AIレビューでレビュー待ち 減った？ • 単純にYesと 言えない。AIで細かい指摘や既知 ミス 拾いやすくなり、人間 仕様・設計・影響範囲 ような判断に集中できる役割分担が発生する。レビュー待ちを完全 に消すも で なく、責任範囲が明確になることで高リスクな変更 丁寧に見る必要性が生まれる。 18. 小規模チームでもAIレビュー 必要？ • 小規模 場合、レビュー体制が薄かったり、レビュー観点が属人化しやすい傾向があると思うが、 AIレビューによる観点補助やケアレスミス 検出 有効活用できると思う。 19. AIレビューに頼りすぎるリスクや、若手 レビュー力が育たなくなる可能性 ？ • AI コメントがあるとレビューした気になってしまうリスク ある。あくまでレビュー観点 追加として扱うべきで、仕様判断や設計判断、最終的なリリース判断など人間が責任 を持つも 明確に分ける必要がある。一方で、 AIレビュー 良い点 観点が可視化されること。なぜこ 指摘が出た か、ど パターンに反応している かを見れ 、若手 レビュー観点 学習にも使える。 20. Claude CodeやSkillsで内製すれ 足りる で ？ • 足りるケースもある。しかし、重要な AIに指摘させることだけでなく、開発フローへ 組み込み、指摘 可視性、ルール管理、採用率 計測、ナレッジ 更新、運用まで 含めて回せるか。専用ツール 運用を早く立ち上げやすい点に価値があるが、内製で同じ構 を維持できるなら選択肢に入ると思う。 21. セキュリティや機密情報 観点で不安 ？ • ある。AIツール コードや PR情報を扱うため、セキュリティ・コンプライアンス観点 重要。 AIを組織運用に入れるなら、セキュリティや権限設計も含めて考えるべき。 想定問答集 3