要約

このai コードレビュー ツールは、変更行数・変更ファイル数・変更種別・レビューの深さからPRのレビュー時間を見積もります。根拠はCiscoとSmartBearの共同ピアレビュー研究で、効果的なレビュー速度は1時間あたり200〜400行に収まり、1時間を超えるセッションでは欠陥の見落としが増えるという結果です。数値を入力すると、推定レビュー時間（分）、集中力の指標、PRを分割すべきかAIの一次レビューを挟むべきかの判定が表示されます。入力内容がブラウザの外に送信されることはありません。

そのPull Request、レビューに何分かかる？

この無料のai コードレビュー ツールは、変更行数・変更ファイル数・レビューの深さを入力するだけで所要時間を見積もります。5分で終わる差分なのか、人が開く前にAIの一次レビューを挟むべき差分なのか、これで判断できます。

レビュー時間を見積もる
深夜、2台のモニターで赤と緑のコード差分を含むプルリクエストをレビューする開発者

レビュー時間 見積もりツール

変更の規模と種類を入力してください。入力するたびに見積もりが更新され、入力内容がブラウザの外に送信されることはありません。

-- 分（推定）

    結果の読み方

    見積もり結果の読み方

    1. 1

      差分の形を入力する

      変更行数、変更ファイル数、変更の種類、そして今回のレビューにどれだけの深さが必要かを入力します。

    2. 2

      推定時間を確認する

      分数は、基本レビュー速度に変更種別のリスク係数を掛け、ファイル間のコンテキストスイッチによる小さなペナルティを加えて算出されます。

    3. 3

      バッジを確認する

      集中力の目安、PRを分割すべきか、そして人が開く前にAIの一次レビューを走らせる価値があるかどうかが表示されます。

    4. 4

      スケジュールを決める

      5分で終わる確認なら会議の合間にできます。130分かかるレビューには、カレンダー上にまとまった時間を確保するか、PRを小さくする必要があります。

    仕組み

    見積もりの根拠

    「なんとなく」ではなく行数で判断

    基本レートは、CiscoとSmartBearのピアレビュー研究で示された範囲、1時間あたり200〜400行に基づいています。これより速いペースになると欠陥の検出率が下がります。あなたの差分のサイズは、このレートに直接当てはめられます。

    変更種別ごとのリスク係数

    行数が同じでも、バグ修正とインフラ変更は同じレビューではありません。設定・インフラの変更には1.4倍、リファクタリングには1.3倍、機能追加には1.15倍の時間係数がかかります。差分が小さくても影響範囲が広いためです。

    AIを先に使うべきタイミングの合図

    およそ400行、あるいは推定レビュー時間90分を超えると、人の注意力は測定可能なレベルで低下します。このツールはその閾値を検知し、人が最初から最後まで読む前にAIの一次レビューを走らせるよう知らせます。

    なぜ見積もるのか

    「どれくらい時間がかかるか」は、始める前に答える価値がある

    多くのチームは、レビュー時間を明示的に見積もっていません。プルリクエストが届き、誰かが会議の合間に開き、レビューは駆け足で終わるか、2日間放置されるかのどちらかになりがちです。どちらも良い状態ではありません。駆け足のレビューは、第三者の目があるからこそ拾えるはずのものを見逃しますし、放置されたPRはチーム全体の速度を落とします。 上記の見積もりは、分単位で正確であることを目指したものではありません。差分を開く前に、一つの問いに答えるためのものです。5分で済むざっと確認なのか、それともまとまった集中時間が必要なのか。この判断が、スケジュールの立て方や、機械的な問題を先に洗い出すためにAIの一次レビューを走らせる価値があるかどうかを変えます。そうすることで、人のレビュアーは「このアプローチは正しいか」「アーキテクチャに合っているか」「半年後にも意味が通るか」といった判断そのものに集中できます。

    • 公開されている研究では、およそ400行を超えるレビューは欠陥検出率が測定可能なレベルで下がることが示されています
    • 設定・インフラの変更は、同じサイズの機能追加コードよりも1行あたりのリスクが高くなります
    • 差分に対するAIの一次レビューは、人のレビュアーを構文チェックから解放し、判断が必要な部分に集中させます
    ノートパソコンでプルリクエストのコード差分を指し示す2人のエンジニア

    よくある質問

    これは本当にai コードレビュー ツールなのですか？ただのタイマーでは？
    これは、人であれAIであれ、すでに使っているレビュー手段の手前に置く計画ツールです。コードの中身を読んだり評価したりはしません。変更にどれくらいの時間をかけるべきかを見積もり、人が差分を開く前にAIの一次レビューを走らせる価値があるかどうかを教えてくれます。
    1時間あたり200〜400行という数字はどこから来ているのですか？
    CiscoとSmartBearによる研究『Best Kept Secrets of Peer Code Review』が根拠です。Cisco Systems社内の約2,500件のレビューを分析したもので、効果的なレビュー速度はこの範囲に収まり、1時間あたり約500行を超えるとバグを見落とし始めることが分かっています。
    自分のコードがブラウザの外に送信されることはありますか？
    ありません。この計算機は、入力された数値（変更行数と変更ファイル数）を読み取り、JavaScriptでブラウザ内だけで見積もりを計算します。コードを貼り付ける欄自体が存在せず、どこにもアップロードされません。
    同じ行数でも、なぜconfig変更のほうが機能追加より重く扱われるのですか？
    影響範囲が行数に比例しないからです。5行のインフラ変更がデプロイパイプライン全体を止めることもありますが、5行の機能修正でそこまでの影響が出ることは通常ありません。configとinfraに1.4倍の係数がかかっているのは、機能単位ではなく行単位で余分な注意が必要だという判断です。
    400行を超えるプルリクエストは、本当にすべて分割すべきですか？
    基本的には、はい。変更を機能単位で分割しても壊れないなら分割してください。例外は、依存パッケージの一括更新やファイル横断のリネームのような機械的・自動生成的な差分で、行数は多くても必要なレビューの深さは低いケースです。ツールが閾値を示すだけで、最終判断は人が行います。
    「集中力：低」という判定は、コードの品質が悪いという意味ですか？
    いいえ。これはレビューという行為そのものを測っているのであって、コードの品質ではありません。900行のリファクタリングがきれいなコードであっても、集中力低下の警告は出ます。誰も3時間ぶっ通しで完全な集中を保てないからです。コード自体の品質を評価したい場合は、別途コード品質チェックと組み合わせてください。
    この見積もりは、レビュー開始時点でCIがすでにグリーンであることを前提にしていますか？
    はい。この計算式は、リントとテストをすでに通過した差分を人またはAIが読む時間を見積もっています。CIがまだ赤い場合はバッファを追加してください。本来PRを開く前に検出されているべき失敗を追いかける時間は、この見積もりに含まれていません。

    差分を開く前に、中身を理解する

    codebasechatは、あなたのコードベースについての質問に平易な言葉で答えます。プルリクエストを開く頃には、何がなぜ変わったのかをすでに理解しているので、レビュー自体も速く進みます。

    codebasechatを無料で試す