新卒エンジニアのプルリクエスト with AI駆動
はじめに
12月に開催されました「【AI駆動開発まつり】AI駆動開発 の現場テクニックを徹底紹介！(KennEjimaさん招待講演）」で登壇を行いました！
発表資料はこちらになります。「新卒エンジニアのプルリクエスト with AI駆動」
自分がエンジニアとしてスタートした際に、真っ先に感じた不安として、
- 自分の書くコードに自信が持てない
- 自分が先輩のコードをレビューした際に、尊敬ゆえに指摘すべきか判断に迷ってしまう
といったものがありました。
今回は、AIを味方につけて、自分の行いに自信を持てるようになるアプローチを、レビュイーとレビュアーの2つの視点から紹介します。
レビュイー：AIファーストでのレビュー
一つ目は、AIを「最初のレビュアー」として活用することです。
AI相手であれば、初歩的なミスを何度指摘されても恥ずかしくありませんし、修正と再レビューを何度繰り返しても誰かの時間を奪うことはありません。
もたらされる効果
- 「最低ライン」の担保: AIのチェックを通すことで、「少なくとも最低限の品質は満たしている」という安心感が生まれます。
- レビュアーの負荷軽減: 構文エラーや単純なロジックミスはAIが事前に潰してくれるため、ベテランエンジニアはアーキテクチャや設計思想など、より本質的で価値あるフィードバックに集中できます。
- 学習サイクルの高速化: 指摘を待つ時間が減り、「なぜこの実装がよくないのか」をその場で確認・修正できます。
具体例：AIにPRを事前レビューしてもらう
実際には、同じPRに対して複数のAIレビュー手段を使い分けることができます。目的は「どれが最強か」を決めることではなく、自分が人にレビューを依頼する前に、論点をできるだけ洗い出しておくことです。
GitHub CopilotによるPRレビュー
最も手軽なのが、普段の開発環境に近いところでGitHub Copilotを活用する方法です。
- PR全体の差分を見ながら、変更の意図に対して不自然な実装がないか確認できる
- 命名、重複処理、例外処理漏れ、テスト不足などの観点を素早く洗い出せる
- 修正後に再度確認を依頼しやすく、セルフレビューの反復がしやすい
「まず自分で見直す」「その後にCopilotでもう一段確認する」という流れを挟むだけでも、レビュー依頼時の安心感はかなり変わります。
GitHub AppsのClaudeによるレビュー
GitHub Appsとして組み込まれたClaude Code GitHub Actionsのレビューでは、PR上でよりレビュー体験に近い形でコメントを受け取れます。
- PRコメントの形で指摘を受けられるため、人間レビューに近い導線で確認しやすい
- 差分の一部だけでなく、変更全体の整合性や説明不足に気づきやすい
- 「この関数の責務は重すぎないか」「この条件分岐で抜け漏れはないか」といった、少し踏み込んだ観点の壁打ちに使いやすい
人に見せる前に、AIから“レビューコメント形式”で一度指摘を受けておくと、本番のレビューで何を聞かれそうかの予行演習にもなります。
ChatGPT Codex Connectorによるレビュー
ChatGPT Codex Connectorを使うと、PRの差分や周辺情報を渡しながら、対話形式でレビューを深掘りできます。
- 「このPRのリスクが高い箇所を優先順位付きで挙げてください」といった依頼がしやすい
- 「レビュー観点を5つに絞る」「初心者向けに厳しめに見る」など、依頼の仕方を柔軟に変えられる
- 単に指摘を受けるだけでなく、「どう直すべきか」「代替案は何か」まで会話を続けられる
特に、レビューコメントを受けても腹落ちしないときに、対話しながら背景を理解できるのが強みです。自分の中で納得感を持ってから修正できるため、学習効果も高まります。
AIレビューを使うときのポイント
AIレビューは便利ですが、出てきた指摘をそのまま鵜呑みにしないことも大切です。
- 指摘の採用理由を自分の言葉で説明できるか確認する
- 設計・仕様との整合性は最終的に人間が判断する
- 複数のAIで重なる指摘は、優先して見直す候補にする
AIを「正解をくれる存在」としてではなく、見落としを減らしてくれる最初の壁打ち相手として使うと、非常に相性がいいと感じています。
レビュアー：レビューのサポート
二つ目は、レビューをする際のテクニックです。
今回は、AIにGitHub CLIを使ってもらう一例をご紹介します。
CLI連携による「文脈」の強化
コーディングAgentは、GitHub CLIを通してPRの文脈を効率よく収集できます。
gh pr view: PRの概要や説明文をAIに読み込ませるgh pr diff: 具体的な変更差分をAIに解析させるgh api: 特定のレビューコメントや関連情報をAIに参照させる
これにより、AIは「どのファイルのどこが、どのような意図で変更されたか」という深い文脈（コンテキスト）を理解した上で、より的確なレビューが可能になります。
GitHub CLIのより詳細な使い方
実務では、単に差分を見るだけではなく、PRの概要・変更ファイル・レビュー履歴・CI結果までまとめて渡すことで、AIのレビュー精度が上がります。
1. PRの概要を取得する
まずはPR本文やタイトル、マージ先ブランチなどを確認します。
gh pr view 123
これによってAIに対して、
- 何のための変更なのか
- どのブランチに向けた変更なのか
- 誰がどんな意図でPRを書いたのか
を先に渡せます。差分だけを見せるよりも、レビューの前提が揃います。
2. 変更差分を取得する
差分全体を確認するには以下を使います。
gh pr diff 123
大きなPRでは、差分を丸ごと一度に見るのではなく、
- まずは全体のリスクを見てもらう
- 次に重要ファイルを重点的に見てもらう
- 最後にテスト不足や影響範囲を確認する
というように分割すると扱いやすくなります。
3. 変更ファイル一覧を把握する
PRでどのファイルが触られているかを一覧で確認すると、レビュー観点の抜け漏れを防げます。
gh pr view 123 --json files
これを見れば、
- アプリケーションコードだけでなくテストも更新されているか
- 設定ファイルやインフラ定義まで影響していないか
- ドキュメント更新が必要な変更か
といった観点をAIに渡しやすくなります。
4. レビューコメントや会話履歴を確認する
既に別のレビュアーがコメントしている場合、その内容を見た上でAIに追加観点を出してもらうのが有効です。
gh api repos/OWNER/REPO/pulls/123/comments
Issueコメント込みで見たい場合は、PRの会話全体を取得します。
gh api repos/OWNER/REPO/issues/123/comments
これにより、
- すでに指摘済みの論点を重複してレビューしない
- 未解決の懸念点だけに絞って確認する
- レビュアー間で論点が分かれている箇所を重点的に見る
といった使い方ができます。
5. CI結果やチェック状況を確認する
AIにレビューしてもらう前後で、CIや各種チェックの状態も合わせて見ると効果的です。
gh pr checks 123
テスト失敗やLintエラーがある場合は、それを前提にAIへ「失敗原因の推測」や「影響範囲の整理」を依頼できます。
6. 実際の依頼のしかた
GitHub CLIで集めた情報をそのまま投げるのではなく、AIへの依頼文に観点を入れると精度が上がります。たとえば以下のような形です。
- 「このPRの変更意図を踏まえて、設計上の懸念を3点挙げてください」
- 「バグになりそうな条件分岐、例外処理漏れ、テスト不足の観点でレビューしてください」
- 「既存コメントと重複しない観点だけを挙げてください」
- 「新人エンジニアにも伝わるように、指摘理由を平易に説明してください」
単に「レビューして」と頼むよりも、何を重視して見てほしいかを伝えることで、実務で使えるレビューになりやすいです。
中立的な視点の価値
人間同士のレビューでは、どうしても「先輩と後輩」という関係性やバイアスが働きますが、AIにはそれがありません。
- バイアスの軽減: 相手がベテランか新人かに関係なく、純粋にコードのロジックを客観的に分析します。
- 死角の発見: 人間が疲労で見逃しがちなエッジケースやケアレスミスを、機械的な精度で発見してくれます。
- 透明性の確保: AIの提案を採用した箇所や、AIとの対話内容はコメントなどで明記し、透明性を保ちやすくなります。
まとめ
私の体験からのまとめとしては、
- AIに事前レビューを依頼する: まずはAIに見せて、不安や単純ミスを解消する
- 自信を持ってPRを出す: 「最低ラインを超えている」という確信を持って、人間のレビュアーに依頼する
- レビュアー側もAIを活用する: GitHub CLIなどで文脈を整え、より本質的なレビューに集中する
という流れになります。
結局、どれだけAIを活用したとしても、完璧なコードを書くことはできませんし、ミスは残ります。しかし、「自分の書いたコードに自信を持つ」ための土台を作ることは、AIの活用によって十分に実現できると感じています。
ぜひ次のプルリクエストから、このAI駆動のアプローチを取り入れてみてください。
