はじめに

「この変更、どのくらい時間かかる？」
レビュー現場でよく聞かれるこの問いに、最近ではAIが答えようとしている。

Gitの差分やコードの意味から、作業量を自然言語で要約したり、テスト影響を示したり、時間まで見積もったり。
そんな便利そうなツールが続々と登場している。

でも、レビューアーとしては「本当にそれ、信じていいのか？」と一歩引いて見ておく必要がある。
この記事では、工数見積もりAIの実態と限界、そしてレビューにどう使えるかを整理していく。

工数見積もりAIって何してるの？

工数見積もりAIとは

コードの変更（たとえばGitの差分）をもとに、修正規模・作業範囲・テストへの影響などを推定して、「作業の重さ」を自然言語や数値で見積もるAIのこと。多くは大規模言語モデル（LLM）を利用している。

最近よく見るのは、以下のようなツールたち。

ツール名 主な機能 技術背景
MutableAI 差分の要約 + 工数推定 LLM + コード解析
CodeSquire 差分コメント + 難易度ラベルの付与 GPT系の生成モデル
Grit.io テスト影響・リファクタ分類・バグ予測 独自LLM + 静的解析

どれも「行数」だけでなく、意味的な変更（構成変更、テスト対象、依存モジュールなど）まで見ようとしているのがポイント。

出力例を見る：これ、信じていいの？

たとえばMutableAIの出力は、ざっくり言うとこんな感じ。

工数予測の出力例（抜粋） 
変更概要: HTTPクライアントモジュールにリトライ設定を追加。
影響範囲: 初期化処理、設定読み込み、リトライロジック。
工数推定: 実装とテスト含めて3〜5時間。

たしかに、短く要点を押さえていて便利そう。
でもレビューアーとしては、ここを鵜呑みにするのではなく、ちゃんと見ておきたいポイントがある。

  • 設定追加って言ってるけど、デフォルト動作変わってない？
  • リトライロジックが変わるなら、全APIの再テスト必要じゃない？
  • 「3〜5時間」ってあるけど、CIの遅さとか人のレビュー待ち時間含んでる？

このあたり、意外と見落とされやすい。

そもそも、なんでズレるのか？

AIが予測しているのは「コードから見た作業量」だけで
実際の作業って、それ以外のことにめちゃくちゃ時間かかることも多い。

たとえば：

  • レビューコメント対応：仕様の意図説明とか、再修正で2往復とか普通にある
  • ステークホルダーへの説明：実装よりもSlackでの調整の方が工数大きい場合も
  • 本番影響調査・データ検証：リリース前のチェックやシナリオテストも工数に含めたい

工数見積もりAIは「コード以外の作業」を見ていないことがほとんど。
だから、数値だけ見て「軽いな」と思うと痛い目にあう。

得意なこと／苦手なことを把握しておこう

レビューアーとしては、「このAI、何が得意で何が苦手か」を知っておくのが大事。
ざっくりまとめるとこんな感じ。

観点 得意 or 苦手 備考
差分の要約 得意 文脈を読み取って自然言語でまとめてくれる
テスト影響の分類 やや苦手 モジュール構造はわかっても意図は読めない
セキュリティ懸念 不得意 API漏れや認可ミスなどはまだ無理がある
数値での工数推定 苦手 根拠が曖昧。精度の高い例は少ない
周辺作業の考慮 非対応 ステークホルダー調整などは当然対象外

だからこそ「レビュー判断を丸投げするものじゃない」って意識が必要になる。

PRレビュー運用にどう活かせばいいのか

それでも、工夫次第でレビューを楽にする活用方法はたくさんある。

PRテンプレートにAI出力を書かせる

たとえば、こんなふうにテンプレを工夫する。

### AIによる変更要約と工数見積もり
- 要約: 認証処理のログ記録を外部に切り出し、設定ファイル対応
- 工数: 5時間（実装 + テスト含む）
### 補足・レビュー観点
- ログ出力形式の互換性に注意
- 設定ファイルが未テスト。手動確認要

レビュアーがあらかじめ「見ておくべきポイント」に集中しやすくなる。

CIの自動チェックに使う

PRの粒度をチェックして、レビュー体制を変えるのにも使える。

  • 工数が8時間以上 → チームで事前レビュー必須
  • テスト影響が広い → シニアレビュアーを割り当てる

こういうルールを運用設計で整えておくと便利。

補足コメントを人間が加える

AI見積もりに対する補足 
@Reviewer: 3時間とされているけど、外部API変更含むので追加テスト必要。実質は8h見ておくべき。

この一言があるだけで、判断ミスがぐっと減る。

リスクと注意点

工数見積もりAIが出した数字がそのままチーム判断に使われると、危ないケースもある。

たとえば：

  • 「2時間なら今日中に終わるよね？」→ テスト準備で1日かかる
  • 「マージしちゃっていい？」→ デフォルト挙動変わってたのを見落としてた

レビューアーが「その見積もり、現実と合ってる？」と立ち止まる姿勢が、チーム全体の品質を守る。

まとめ：AIとレビューアーの役割分担

工数予測AIは、うまく使えばレビュー判断を助けてくれるし、見積もりのブレを可視化する材料にもなる。

でも、それを使って「判断を丸投げする」のではなく、

  • 補足する
  • 確認する
  • ズレを説明する

というレビューアーの“編集者的”な動きが必要になる。

コードレビューにおいて、AIは“道具”ではあっても、“最終判断者”にはなれない。
その責任を持つのは、あくまでレビューアーなんだと思う。