AIコードレビューの手順 プルリクエストを3段階で確認する理由
要約： VAONの10ステップの開発フローを適用している案件では、すべてのプルリクエストを決まった順序で3段階レビューします。作成者自身の読み直し、プロジェクトの観点にもとづくAIレビュー、別のエンジニアによる承認の順で進め、マージはチームリーダーが判断します。メインブランチは保護され、レビュー記録はお客様もご覧いただけます。
目次
- プルリクエストの3段階レビューとは何か、なぜ順序が大切なのか
- なぜAIより先に、作成者が自分で読み直すのか
- AIレビューは何が得意で、なぜ最後の段階ではないのか
- 2人目のレビュアーとチームリーダーは何に責任を持つのか
- お客様はどのレビュー記録を確認できるのか
- 3段階のレビューでも足りない場合
- よくあるご質問
1. プルリクエストの3段階レビューとは何か、なぜ順序が大切なのか
VAONのプルリクエストの3段階レビューとは、同じ変更を、立場の違う3者が、それぞれ別の目的で読むことです。プルリクエスト（PR）は、コードの変更をメインブランチに取り込むための依頼です。
順序は、作成者のセルフレビュー、AIレビュー、2人目の人によるレビューです。文脈をいちばん理解している人から始め、時間がいちばん限られている人で終わります。前の段階が細かな指摘を片付けておくことで、最後の段階は「業務として正しいか」という最も難しい問いに集中できます。
| 段階 | 担当 | 得意なこと | 苦手なこと | 残る記録 |
|---|---|---|---|---|
| 1. セルフレビュー | PRの作成者 | タスクの目的を知っている、範囲外の変更に気づく | 自分の思い込み | PRの説明、変更理由 |
| 2. AIレビュー | Claude（プロジェクトの観点にもとづく） | すべての行を同じ注意力で読む、パターン化できる不備を拾う | 誤検知がある、見落としもある、業務の意図を知らない | PRに残る指摘一覧（人が取捨選択する） |
| 3. 2人目のレビュー | 別のエンジニア、マージ判断はチームリーダー | 仕様書との照合、設計の判断 | 時間に限りがある、大きなPRは流し読みになりやすい | レビューコメント、承認者名 |
3段階レビューは、Claude Codeを使った開発フローの一工程です。このフローは多くの案件で適用していますが、すべての案件ではまだありません。一方、メインブランチの保護と、お客様がご覧いただけるレビュー・テスト記録の保存は、すべての案件で行っています。
2. なぜAIより先に、作成者が自分で読み直すのか
作成者が最初にレビューするのは、その変更で何を実現したいのかを知っているのが作成者だけだからです。Claude Codeが書いたコードの場合、ここが「人が変更全体を初めて通して読む」場面になることも少なくありません。
この段階での問いは単純です。「すべての箇所を自分で説明できるか」。作成者が説明できない箇所は、次へ進めません。その状態でAIレビューにかけても、誰も理解していないコードに指摘が増えるだけです。
セルフレビューでは、AIがコードを書くときによく起きる「頼まれた以上に変更する」ことにも気づけます。たとえば、AIがついでに共通ファイルを「整理」してしまう場合です（説明のための例です）。タスクの範囲を知っている作成者なら、すぐに気づきます。
PRに含まれるテストも、この段階で読みます。AIが書いたテストをエンジニアがどう読むかは、プルリクエストに含めるAI生成テストでご紹介しています。
3. AIレビューは何が得意で、なぜ最後の段階ではないのか
AIレビューを2番目に置いているのは、AIが速く、むらなく読める一方で、具体的な観点を与えたときにしか役に立たないためです。VAONでは、「レビューして」という汎用の依頼ではなく、プロジェクトごとのレビュー観点にもとづいてClaudeが変更を読みます。
AIは、人が疲れているときに見落としやすい点を拾うのが得意です。例外を捕まえて何もせずに捨てている箇所、権限チェックのない新しいエンドポイント、存在しないAPIの呼び出しなどです。AIが書いたコードで人が確認すべき観点は、AIが書いたコードのレビュー手順にまとめています。
AIレビューを最後の段階にしない理由は二つあります。一つは誤検知があり、人が取捨選択する必要があることです。もう一つは見落としがあり得ることで、特に業務上の誤り、つまり技術的には正しくても仕様と違う動きをするコードは見逃しやすくなります。
AIを2人目のレビュアーより前に置くと、細かな不備が先に片付きます。レビュアーの時間を、人にしか判断できない部分に使えます。
4. 2人目のレビュアーとチームリーダーは何に責任を持つのか
2人目のレビュアーは変更を仕様書と照合する責任を持ち、チームリーダーはマージの判断に責任を持ちます。判断の背後に、名前のある担当者がいる段階です。
2人目のレビュアーはそのコードを書いていないため、作成者と同じ前提を持っていません。そのため、作成者とAIがともに見落とした点に気づきやすくなります。説明のための例を挙げます。仕様書では「配送後のキャンセルは一部返金」とされているのに、全額を返金するコードでも動作はします。テストがコードに合わせて書かれていれば、テストも通ります。仕様書を読んだ人でなければ、誤りに気づけません。
「承認がなければマージしない」という決まりは、各自の注意ではなく仕組みで守ります。GitHubでは、ブランチ保護の設定でマージ前に一定数の承認レビューを必須にすることができます。有効にすれば、急いでいるときでも承認なしにはマージできません。
5. お客様はどのレビュー記録を確認できるのか
VAONはすべての案件でレビューとテストの記録を保存しており、お客様にもご覧いただけます。プルリクエストごとに、次の内容を確認できます。
- 何を、なぜ変更したか（PRの説明）
- レビューでの指摘と、それぞれの対応
- 承認者とマージを判断した人
- 自動チェックの結果（シークレットスキャン、依存関係スキャン、静的解析）
2026年にお客様からいただいた質問で特に多かったものの一つが、「AIが書いたコードは誰が確認するのですか」でした。この質問には、ツールの名前ではお答えできないと私たちは考えています。お答えになるのは実際のプルリクエストです。開けば、誰が読み、誰が承認し、どの自動チェックが通ったかがわかります。CTOとテックリードはすべての案件に参加しているため、マージの判断を説明できる立場の者が必ずいます。
記録の形式は案件によって異なる場合があります。特定の形式が必要な場合は、キックオフの段階でお知らせください。なお、各バージョンはリリース前にもう一つ別の確認を通します。詳しくはAIが書いたコードのリリース前セキュリティチェックでご説明します。
6. 3段階のレビューでも足りない場合
3段階のレビューは不具合の流出を減らしますが、VAONはこれを「不具合ゼロの保証」とは考えていません。事前にお伝えしておきたいケースが三つあります。
- コードをAIに渡すことをご許可いただいていない場合。 AIレビューは実施しません。セルフレビュー、2人目のレビュー、自動チェックで確認します。
- プルリクエストが大きすぎる場合。 レビュアーが流し読みになります。変更を小さく分け、一つのPRを最後まで読める大きさにします。
- 仕様が確定していない場合。 2人目のレビュアーが照合する基準がなく、3段階目の価値の大半が失われます。
文言を1行直すような、ごく小さな変更では、前段の工程を簡略化します。それでもメインブランチの保護と自動チェックはそのままです。また、レビューは受入テストの代わりにはなりません。納品をお受けいただく前に、チェックリストでの確認をお願いしています。
7. よくあるご質問
AIレビューで、人のレビューを置き換えられますか。 置き換えられません。VAONでは、AIレビューは人のレビューを補う段階です。AIはプロジェクトの観点にもとづいて速く、むらなく読みますが、誤検知があり、特に業務ロジックの誤りは見落とすことがあります。そのため、AIの指摘は必ず人が取捨選択します。マージの判断は、別のエンジニアが承認したうえで、チームリーダーが行います。
コードをAIツールに渡したくない場合、レビューはどうなりますか。 ご許可をいただいていない場合、VAONはコードをAIツールに渡さず、AIレビューも実施しません。各プルリクエストは、作成者のセルフレビュー、別のエンジニアによる承認、チームリーダーによるマージ判断を経ます。PRごとの自動チェックとメインブランチの保護も、そのまま適用します。AIをどこまで使うかは、案件開始前に取り決めます。
レビュー記録はどこで確認できますか。 VAONはすべての案件でレビューとテストの記録を保存しており、お客様にご覧いただけます。コードは最初からお客様のリポジトリに置くこともできます。プルリクエストごとに、変更の説明、レビューでの指摘、承認者名、自動チェックの結果を確認いただけます。社内監査向けに特定の形式が必要な場合は、キックオフ時にお知らせください。
3段階のレビューで、開発は遅くなりませんか。 プルリクエストごとに読む時間は増えます。その代わり、不具合が小さな変更の中にあるうちに、ほかの作業と混ざる前に見つけられます。順序は無駄を減らすように決めています。作成者は自分で気づける点を、AIはパターン化できる不備を片付け、2人目は業務ロジックに集中します。時間短縮の具体的な数値はお約束していません。
3段階すべてをすり抜けた不具合の責任は、誰にありますか。 責任の範囲は、案件ごとの契約で定めます。VAONは、「AIが書いた」ことを理由に責任の範囲が変わるとは考えていません。AIが書いたコードも、人が書いたコードと同じレビューとテストを通します。問題が起きた際には、どの変更が原因か、誰が承認したか、どの自動チェックが通ったかを、レビュー記録で双方が確認できます。
今日からできることが一つあります。開発チームに、最近マージされたプルリクエストを一つ開いてもらい、三つの点を示してもらってください。誰が読み直したか、AIの指摘のうちどれを採用せず、その理由は何か、誰が承認したか。誰も示せないなら、そのレビューは記録ではなく記憶に頼っています。
3段階のレビューを貴社の案件に当てはめるとどうなるか、無料相談（60分）でご説明します。CEOが同席します。資料のご準備は不要で、ご契約を前提としたものではありません。
参考資料
- GitHub Docs「About protected branches」：https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches（2026年10月29日確認）
