利益:
- カテゴリと重大度タグを備えた初期レビュー フィルターとして AI を使用する機能
- 人間の思考で結果をフィルタリングして検証/偽陽性/適用する機能
- ビジネス ルール、アーキテクチャ、セキュリティ クリティカルな意思決定に対して人間の承認要件を強制する機能
コードレビューとは、開発者によって書かれた変更がマージされる前に他の人によってレビューされることです。良いレビュー;バグを早期に発見し、情報を共有し、コードベースの一貫性を保ちます。しかし、レビューは疲れるし、気が散りやすく、時間のプレッシャーがあると表面的なものになってしまいます。ここでは人工知能は 2 つのアシスタントです。レビューのために送信する自分のコードを事前にクリーンアップすることと、他の人の PR (プル リクエスト) をより鋭い目で検査することの両方を可能にします。
決定的な違いは、AI はレビューを高速化して強化しますが、承認の責任を引き継ぐことはできないということです。 「AI が見たところ、きれいでした」という文は推奨するものではありません。最終的な「マージ」の決定は、コードとコンテキストを理解しているエンジニアに任されています。
AI の良い点と悪い点のレビュー
用途: Null チェックのミス、リソース リーク (ファイル/リンクが開いたまま)、キャッチされなかった例外、明らかに間違った条件 (> ではなく >=)、名前変更の提案、読みやすさ、エッジ ケースの欠落、単純なセキュリティの匂い (SQL 文字列の連結など)、重複コードの検出。
弱点: ビジネス ルールに違反するものの、構文的に正しいロジック、アーキテクチャへの準拠、実際のパフォーマンスのボトルネック、同時実行エラーなど、コンテキストとタイミングが必要な深刻な欠陥。 AI はまた、偽陽性 (実際には問題ではないものを問題と誤認する) や偽陰性 (本当のバグを見逃す) も生成します。したがって、その出力は「注意リスト」であり、最終的な判断ではありません。
注意: AI が「問題なし」と言ったからといって、コードが正しいことは証明されません。偽陰性は沈黙します。最も危険な間違いは、レビューで決して言及されない間違いです。
体系的なレビュー手順
- コンテキストを教えてください。変更の目的、関連する問題、受け入れ基準がある場合は、それをプロンプトに追加します。目的のないレビューは目的のない解釈を生み出します。
- カテゴリに分けてみましょう。モデルに調査結果を「バグ/セキュリティ/パフォーマンス/読みやすさ/スタイル」として分類するよう依頼します。したがって、重要なものをノイズから分離します。
- 重大度ラベルを要求します。それぞれの結果を「高/中/低」で評価し、「原因」と「推奨される修正」を含めます。
- 自分の目で濾してみてください。それぞれの結果を評価します: それは本物か (検証)、誤検知か (正当性を書き込む)、何か欠けているものがないか (独自の知識を追加)。
- クリティカル パスを手動で確認します。 AI に頼らずに、お金、アイデンティティ、認可、データ削除に関わるルートを自分で読み取って実行します。
ミニケース3個
ケース 1 — サイレント null エラーが検出されました。あるチームは AI に 380 行の PR を事前レビューさせました。このモデルは、外部サービスの応答が null になる可能性がある方法でフラグを立てましたが、コード内ではこれに対するチェックが行われませんでした。人間のレビュー担当者がこのパスを検証し、null チェックを追加しました。前四半期にも同様のエラーにより、生産に 2 時間の中断が発生しました。
ケース 2 — 誤検知の排除。 AI はループ内で「パフォーマンスの問題の可能性」を警告しました。レビュー担当者は、ループが最大 5 つの要素でのみ機能する (列挙型をループする) ことを知っていたため、これを誤検知として閉じました。モデルは文脈を知らなかったが、警告した。文脈を知っている人は正しい決断をしました。
ケース 3 — AI がビジネス ルール エラーを見逃した。キャンペーン ルールによれば、アカウントの割引は最大 30% である必要がありますが、コードでは 50% が許可されていました。 AI はこの構文的に完璧な論理エラーに決して気づきませんでした。彼はルールを知らなかったからだ。このバグは、合格基準を知っている製品所有者によるレビューで発見されました。教訓: ビジネス ルールの検証は人間の仕事です。
4 つのコピー可能なテンプレート
目的指向で分類されたレビュー:
役割: 綿密なコードレビュー担当者。変更の目的: {{目的 / 問題}}この相違点を確認してください。 [バグ] [セキュリティ] [パフォーマンス] [読みやすさ] [スタイル] のカテゴリで調査結果を提供します。各検出結果: ファイル:行、重大度 (高/中/低)、原因、推奨される修正。よくわからない場合は「可能」にマークを付けてください。あなたはビジネスのルールを知りません。ルールが必要な場所について質問してください。{{diff}}
独自のコードをレビューする準備をするには:
PR を開く前に、この変更を確認してください。 null/バグチェックの欠落、リソース リーク、エッジ ケース、シークレット、未テストのブランチを探します。調査結果を優先順位に従ってリストします。それぞれに 1 行の修正を提案します。{{code}}
エッジケースハント:
この関数が壊れる可能性がある入力と状況をリストします: 空、null、大きすぎる、負、同時呼び出し、ネットワーク エラー、部分的なデータ。それぞれのケースについて、予想される動作と現在のコードが何を行うかを記述します。{{function}}
セキュリティ香りスキャン (事前スクリーニング):
このコードで一般的なセキュリティの匂いを探します: SQL/コマンドの連結、検証されていない入力、不変の埋め込みシークレット、安全でない逆シリアル化、権限チェックの欠如。調査結果を「確実・確からしい・知識」に分けます。これは予備審査です。これは最終的な判決ではありません。{{code}}
弱いプロンプト / 強いプロンプト
弱者：「このPRに間違いはありませんか？」
Strong: 「目的: カートの合計にクーポン割引を追加します (割引は 30% を超えてはなりません。このルールを自分で検証することはできません。コードが上限を課しているかどうか教えてください)。差分を調べます。カテゴリ + 重大度 + 提案された修正ごとに結果を示し、不明な場合は「可能」とマークします。[差分]"
強力なバージョンでは、AI の意図、ビジネス ルール、境界が明確に記載されています。したがって、有用な発見が得られ、モデルにとって未知の領域は明確なままになります。
検索タイプ
AIの信頼性
男の役割
Null/エラーチェックがありません
高い
確認して適用する
読みやすさ/スタイル
高い
好みで選ぶ
シンプルなセキュリティの匂い
中程度
仕上げ、車両でスキャン
ビジネスルールの遵守
低い
それは完全に人間です。
同時実行性/アーキテクチャ
低い
専門家のレビューが必要です
AI レビューは人間によるレビューに代わるものではありません
AI レビューを「最初のフィルター」、つまり安くて早くて疲れ知らずの予備パスとして位置づけます。このフィルターは、人間のレビュー担当者の注意を重要でない詳細 (スペース、名前) から解放し、ビジネス ルール、アーキテクチャ、セキュリティの結果など、本当に検討が必要な場所に注意を向けます。ただし、マージの承認はチーム内の責任者の署名です。安全性が重要な変更については、少なくとも 1 人の有能なエンジニアによる独立したレビューが必須です。
ヒント: AI が生成する調査結果のリストは、「やるべきこと」ではなく「確認すべきこと」として読んでください。各項目を検証して適用するか、合格した理由を一文で書き留めてください。このトレースにより、レビューが監査可能になります。
よくある間違い
- 「AIが見た、きれいだ」という意味です。これは、偽陰性による誤った自信です。
- 文脈を与えていない。目的と受け入れ基準がなければ、モデルは表面的なスタイルの解釈のみを生成します。
- 盲目的に誤検知を適用する。モデルのすべての警告を修正すると、実行中のコードが破損する可能性があります。
- モデルにビジネス ルールについて質問します。モデルはルールを知りません。それを検証するのは人間です。
- 暴力に対して差別をしないでください。重要なセキュリティの発見と名前の提案を同じ袋に入れると、重要なものが見えにくくなります。
要約すると
AI は、コード レビューにおける精力的な最初のフィルターです。Null/エラー ミス、エッジ ケース、および単純なセキュリティをうまくキャッチします。しかし、ビジネス ルール、アーキテクチャ、同時実行性などのコンテキストを必要とする欠陥には弱く、誤検知と誤検知の両方が発生します。カテゴリと重大度別に結果をリクエストし、人間の知能でそれぞれをフィルタリングし、クリティカル パスを手動で検証します。承認には常に責任あるエンジニアの署名が必要です。
アプリケーションタスク
実際のまたは最近の PR/差分を選択します。まずは「目的指向・カテゴリーレビュー」テンプレートでAIにレビューしてもらいます。結果を表にまとめ、それぞれについて、真 (私が検証した)、偽陽性 (これが私の推論です)、または実装するかを決定します。次に、自分でツアーに参加し、AI に欠けているもの (特にビジネス ルールやエッジ ケース) を少なくとも 1 つ見つけて書き留めてください。
チェックリスト
- [ ] 私は AI レビューを推奨ではなく、最初のフィルターとして使用します。
- [ ] 目的と承認基準をレビュープロンプトに追加します。
- [ ] ノイズからの発見をカテゴリごとに分けて、それらを強く望んでいます。
- [ ] 私は各結果を意識的にフィルタリングして、確認/偽陽性/適用します。
- [ ] 私は人間として、ビジネス ルールとアーキテクチャのコンプライアンスをチェックします。
- [ ] 安全性が重要な変更を行うには、資格のあるエンジニアの承認が必要です。