AI駆動開発の コードレビュー地獄を なんとかしたい / code-review-with-ai

LT資料

Transcript

1. Fukui Tech LT #1 AI駆動開発の コードレビュー地獄を なんとかしたい 2026年2月20日 永和システムマネジメント Agile Studio 岡本 卓也 © 2026 ESM, Inc. 1
2. 岡本 卓也 EM@AgileStudio AIを使った開発手法の探求 Claude Code に夢中 X：@haraguro3 好きなものはアジャイルとモデリングとトムデマルコ。 自己紹介 © 2026 ESM, Inc. 2
3. 光: コーディング速度の飛躍的向上 AIがコードもドキュメントも高速に生成 1人の開発者が出せるアウトプット量が激増 影: ボトルネックの移動 コーディング → コードレビュー にボトルネックが移動 業界全体で認識されている課題 AI駆動開発の光と影 「速く書けるようになったのに、レビュー待ちで詰まる」 © 2026 ESM, Inc. 3
4. 実際のデータ: 実装量の変化 © 2026 ESM, Inc. 4
5. チームで起きていること 1回のPRで 大量のコード変更 + ドキュメント が出てくる レビュアーの負荷が急増 レビュー待ちの渋滞が発生 振り返りで出てきた声 「量が膨大できちんと見られているか 自信がない」 「もう全部読めないから 雰囲気でマージ してる」 レビュー地獄の実態 © 2026 ESM, Inc. 5
6. じゃあ、どうする？ AIの問題は、AIに解決させよう（チョット違うけど） © 2026 ESM, Inc. 6
7. コードを「読んで」レビューする 人間がコードを目で追い、品質を判断する AIの生成量に人間のレビュー速度が追いつかない 定量指標で「判断させる」 評価関数を設計し、AIに品質を判断させる 人間は「何をどう測るか」を設計する側に回る 発想の転換 AI時代のレビューは「コード」ではなく「評価関数」を見る © 2026 ESM, Inc. 7
8. 考え方 「テストコードを全部読む」のではなく「壊れにくいことを担保する」方向へ カバレッジを「ガードレール」として活用 カバレッジは十分条件ではない。でも「壊れにくさの最低ライン」は担保できる ガードレールを定義できれば、AIに自律的に改善させられる 仕組み AIが自律的に「計測 → 不足検出 → 補完」のループを回す カバレッジ測定 → テスト自動補完 © 2026 ESM, Inc. 8
9. カバレッジ測定 → テスト自動補完（実例） © 2026 ESM, Inc. 9
10. 考え方 「コード構造を全部読む」のではなく「複雑すぎないことを担保する」方向へ 循環的複雑度（CCN）をガードレールとして活用 CCNが低くても良い設計とは限らない。でも「複雑すぎない最低ライン」は担保できる ガードレールを定義できれば、AIに自律的に改善させられる 仕組み AIが「計測 → 改善 → 再計測」のループを回す 複雑度測定 → 自律的リファクタリング © 2026 ESM, Inc. 10
11. 複雑度測定 → 自律的リファクタリング（実例） © 2026 ESM, Inc. 11
12. 今回の実験で見えたこと 定量指標で測れる仕事 はAIに任せられる カバレッジ → テストの網羅性 循環的複雑度 → コード構造の品質 指標が「ガードレール」になり、AIが自律的に改善ループを回せる 正直なところ このアプローチが元の課題を直接解決できるかは、まだ分からない AI時代の開発の本質は、コードを書くことではなく 評価関数を設計すること かもしれない まとめ: 「何を任せるか」ではなく「どう判断させるか」 コードレビュー地獄、なんとかなりそうな気がしています © 2026 ESM, Inc. 12
13. ありがとうございました © 2026 ESM, Inc. 13