変更要約: AZ-400 第2章を深掘り（比較表・シナリオ・FAQ・ひっかけ・深掘り段落を各節に追加、図を日本語版に対応）
2.2プルリクエストとコードレビュー
品質ゲート——プルリクエスト（PR）、ブランチポリシー、必須レビュー/ビルド検証、作業項目リンク——を理解します。レビューと自動検証を通った変更だけを統合します。
統合前の品質ゲートが PR です。ブランチポリシーで必須レビューやビルド検証を強制し、不良な変更を防ぎます。
2.2.1PR とブランチポリシー
- プルリクエスト：変更をレビューしてから main へ統合する仕組み。
- ブランチポリシー：main を保護し、必須レビュー/ビルド検証/コメント解決などを強制。
- ビルド検証：PR トリガーで CI を実行し、テスト合格を統合の条件にする。
- 作業項目リンク：PR に作業項目をリンク必須にし、トレーサビリティを確保。
「main の保護＝ブランチポリシー」「マージ前の CI 実行＝ビルド検証」「必須レビュー担当者」「作業項目リンク必須」「コメント解決必須」 は AZ-400 で頻出です。直接 push を禁止し PR 経由を強制することで、品質とトレーサビリティを担保します。
CODEOWNERS（必須レビュー担当者）で重要パスのレビューを自動要求し、ドラフト PR で早期フィードバックを得られます。
AZ-400 は「main を保護し、自動検証と人のレビューで品質とトレーサビリティを担保する」設計を問います。ブランチポリシーは保護対象ブランチ（main など）に対し、複数の必須条件を組み合わせます：最低レビュー担当者数（自分の投票を無効化、新規プッシュで承認リセット）、必須レビュー担当者/パスベースの必須レビュー（特定ディレクトリは特定チームの承認を要求＝CODEOWNERS 相当）、ビルド検証（PR トリガーの CI が成功しないとマージ不可）、作業項目のリンク必須、コメント解決必須、マージ方法の制限（squash 強制など）。直接 push は禁止され、変更は必ず PR を通ります。ステータスチェックで外部の品質ゲート（SonarQube、脆弱性スキャン、署名検証など）も統合でき、自動完了で条件成立時に自動マージ、ドラフト PRで早期フィードバックを得られます。レビュー文化としては、小さな PR・明確な説明・自動化可能なチェックは機械に任せて人は設計/意図に集中する、が効率的です。これらは DORA の変更失敗率を下げつつ、作業項目リンクで要件→デプロイのトレーサビリティを確立します。設計の要は、「直接 push 禁止＋PR 必須＋ビルド検証＋必須レビュー＋作業項目リンク」を保護ブランチに敷くことです。
| ポリシー | 効果 | 要点 |
|---|---|---|
| 必須レビュー担当者 | 人による承認を強制 | 最低人数・パスベース（CODEOWNERS 相当） |
| ビルド検証 | CI 成功を統合条件に | PR トリガーでテスト実行 |
| 作業項目リンク必須 | トレーサビリティ確保 | 要件↔変更の紐付け |
| コメント解決/マージ方法 | レビュー完了と履歴整形 | 未解決を禁止・squash 強制等 |
シナリオ：本番ブランチに未レビュー・未テストのコードが直接入り、障害が頻発している。→ main にブランチポリシーを設定：直接 push を禁止し PR 必須、ビルド検証で CI（ビルド＋テスト）合格を必須、最低 2 名のレビュー承認と作業項目リンク必須、コメント解決必須。重要なインフラパスはパスベースの必須レビューで基盤チームの承認を要求。これで変更失敗率が下がり、各変更の要件も追跡できます。
FAQ：ビルド検証とリリースゲートの違いは？ ビルド検証は PR の段階で（統合前に）CI を走らせ、テスト合格をマージ条件にする「左側（シフトレフト）の品質ゲート」。リリースゲートはデプロイの段階で（リリースパイプライン内で）承認や外部条件（監視の健全性、変更管理など）を確認する「右側のゲート」です。PR にはビルド検証、本番デプロイ前にはリリースゲート、と段階が異なります。
ひっかけ：「main を保護したい」のにロール権限（RBAC）だけで対応しようとするのは不十分。push できる人を絞っても、レビューやテストの強制はできません。ブランチポリシー（必須レビュー＋ビルド検証＋作業項目リンク等）が正解です。また自分の PR を自分で承認できないよう、レビュー担当者ポリシーは「投票者の除外」を設定します。
2.2.2この節のまとめ
- 品質ゲート＝PR＋ブランチポリシー
- 統合条件＝ビルド検証＋必須レビュー＋作業項目リンク
進捗の記録にはログインが必要です。
理解度チェック
（軽い確認用）Q1. main ブランチへの直接 push を禁止し、必ず PR とレビューを経て統合させたい。何を使いますか？
Q2. PR をマージする前に、自動でビルドとテストを実行し合格を必須にしたい。何を設定しますか？
Q3. 各 PR に対応する作業項目を必ずリンクさせ、変更の理由を追跡可能にしたい。何を使いますか？