AIが作るPRのマージ条件｜レビューと必須チェックを省略しない運用

AIツールへの「テストを通してからPRを作る」という指示は、作業手順を整えるためのものです。リポジトリがマージを拒否できる境界は、保護ルールで設定します。AIがチェック結果を要約し、人がその文章を読んだとしても、必要な承認や検査が実際に完了したかは別に判定します。

2026年9月21日時点のGitHub公式ドキュメントでは、保護ブランチに対し、マージ前の承認レビューを必須にできます。書き込み権限を持つ人、または指定したコードオーナーからの承認を要件にする仕組みです。必須ステータスチェックを有効にした場合は、指定されたチェックがsuccessful、skipped、neutralのいずれかになるまでマージできず、期待する送信元として特定のGitHub Appを選ぶこともできます。

したがって実務上の出発点は、AIが作成したPRも人が作成したPRも同じ境界へ入れることです。必須レビュー、最新変更の再確認、必須ステータスチェックが満たされるまでマージ不可とします。これはGitHubの機能仕様を組み合わせた運用提案であり、GitHubやNISTが定める義務ではありません。AIを使った変更の流れ全体を整理する場合は、AI駆動開発のワークフロー設計もあわせて確認できます。

レビューを必須にするだけでは、どの知識を持つ人が何を確認するかという判断が残ります。READMEの表記修正と認証処理の変更を同じ一行で扱えば、軽い変更には過剰な手続きが残り、重要な変更では確認観点が抜けます。分類軸は、変更種別と失敗したときの影響範囲です。

次の3行は、パス別のオーナー指定とリスクに応じた調整という一次情報の一般原則から組み立てた台帳例です。分類、検査名、承認方法は公式仕様ではなく、実務へ落とすための提案です。自社の構成、検査環境、リスク許容度に合わせて名称と役割を置き換えます。

**文書・表示｜担当：文書または画面のオーナー｜検査：リンク、表記、ビルドなど再現可能な検査｜例外：当該領域の責任者**。挙動変更が一つでも混じれば、文書扱いのまま通さず「アプリ挙動・依存関係」の条件へ引き上げます。

**アプリ挙動・依存関係｜担当：変更領域のコードオーナー｜検査：対象領域のテスト、ビルド、依存関係についてチームが定めた検査｜例外：開発責任者**。例外時は、通らなかった検査と事後対応を記録し、変更担当者だけでは承認を完結させません。

**認証・権限・CI/CD・リリース設定｜担当：コードオーナーと、セキュリティまたはリリース境界の責任者｜検査：関連テストと設定検証｜例外：通常のレビュー担当から分離した責任者**。複数の種別をまたぐPRには、最も軽い行ではなく、該当する各行の条件を合わせて適用します。

条件の強さはファイル名の印象では決まりません。失敗時の影響が大きいほど、必要な専門性、機械検査、例外を引き受ける役割を厚くする。この判定を先に合意しておけば、AIが「小さな修正」と要約しても分類を変えずに済みます。

台帳を実際の境界にするには、リポジトリの設定との接続が必要です。2026年9月21日時点のGitHub公式ドキュメントによると、CODEOWNERSではファイルパターンごとに個人またはチームをコードオーナーとして指定できます。さらに保護ルールの「Require review from Code Owners」を有効にすると、変更されたファイルのオーナーによるレビューをマージ要件にできます。

たとえば、文書、アプリ本体、認証設定、ワークフロー定義を別のパターンに分け、それぞれ台帳のレビュー担当へ結び付けます。PRが複数種別をまたぐなら、軽い側へ寄せず、変更された各パスに必要な担当者と検査を満たす扱いにします。これはCODEOWNERSのパス指定を基にした運用提案で、GitHub所定の分類ではありません。

必須検査も台帳の行からブランチ保護のステータスチェックへ対応付けます。表示名だけが似た別の結果を誤って受け入れないよう、利用環境で可能なら期待する送信元も指定します。設定後は「台帳の条件」「CODEOWNERSのパターン」「保護ルールのチェック名」の対応を変更レビューの対象にします。こうすれば、文章上の原則と実際のマージ可否が離れにくくなります。

一度承認されたPRへ、AIがレビュー指摘への修正を追加する場面があります。最初の承認だけを条件にすると、承認者が見ていない差分が残り得ます。「AIが小さな修正だと説明した」という理由で再確認は省けません。変更種別は最終的な差分と対象パスから判定します。

2026年9月21日時点でGitHubの保護ブランチには、差分へ影響する新しいコミットが追加された際に古い承認を破棄する設定があります。また、直近のレビュー可能なpushについて、そのpushを行った本人以外の承認を求める設定も用意されています。どちらを採用するかはチームの運用に合わせますが、少なくとも最終差分を作った主体だけで完結させない条件を、リポジトリ側で表現します。

台帳には「承認後の更新時」という欄を設け、再承認が必要になる条件を記します。AIが生成した追記、人による手直し、競合解消を別扱いせず、マージ対象の差分が変わった事実で判断します。誰が書いたかではなく、承認後に何が変わったかを条件にするためです。この欄は公式機能を利用した実務提案であり、GitHubまたはNISTが指定する台帳項目ではありません。

緊急時の例外を用意しても、条件をいつでも外せる運用にはしません。例外の入口が広いと、AIが作った変更だから速く通す、担当者が不在だから通す、といった個別判断が通常運用へ入り込みます。誰が不足を引き受け、何を後で解消するかを記録する手続きとして設計します。

例外記録には、対象PR、未充足の条件、例外が必要な理由、承認者、事後対応を残します。承認できる役割は限定し、変更種別台帳の各行に明記します。この記録項目と役割分離は、出典のバイパス境界とリスクベース調整を基にした記事の実務提案で、GitHubやNISTが定める分類・義務ではありません。

文書・表示では、表示領域の責任者が例外を承認し、挙動変更を含まないことを差分で確認します。アプリ挙動・依存関係では、開発責任者が未充足の検査と事後対応を確認し、担当者本人だけで判断を完結させません。認証・権限・CI/CD・リリース設定では、限定した責任者へ引き上げ、通常のコードレビュー承認と例外承認を分けます。

この分け方なら、軽い変更の復旧を妨げず、影響の大きい変更ほど例外の責任を明確にできます。例外が繰り返される条件は個別処理で済ませず、台帳または検査環境の見直し対象にします。

2026年9月21日時点のGitHub公式ドキュメントでは、ブランチ保護は既定でリポジトリ管理者と「bypass branch protections」権限を持つカスタムロールには適用されません。一方、「Do not allow bypassing the above settings」を使うと、それらの管理者やロールにも制約を適用できます。つまり、レビューと検査を厳密に定めても、バイパスできる役割を放置すれば境界は別の場所に残ります。

通常は管理者を含めて保護を適用し、例外承認者と実際にバイパス操作を行える役割を必要な範囲へ限定する、というのが実務上の提案です。ただし、リポジトリの可用性や復旧手順との調整は組織ごとに必要です。NIST SSDFも、2026年9月21日時点の公式ページで、セキュア開発活動を事業要件、リスク許容度、資源に合わせて優先付けする成果ベースの枠組みと説明しています。実践・タスク・実装例は各組織が調整して使う出発点です。

AIツールに渡す権限や利用時の注意点は、マージ境界とは分けて管理します。Claude Codeを安全に使うためのセキュリティ設計で入力・権限側を確認しつつ、最終的な統合可否はリポジトリのルールで止める、という二つの境界を混同しないことが重要です。

まず、リポジトリ内の変更を、文書・表示、アプリ挙動・依存関係、認証・権限・CI/CD・リリース設定など実態に合う種別へ分けます。各種別について「対象パス／レビュー担当／必須検査／承認後の更新条件／例外承認者／事後対応」を一行で決定します。その一行をCODEOWNERS、必須レビュー、必須ステータスチェック、古い承認の扱い、バイパス制限へ対応付けます。この手順は一次情報の一般原則を基にした実務提案で、原典所定の分類や義務ではありません。

運用開始前には、対象パスから適切なレビュー担当が選ばれるか、指定した検査結果だけが受理されるか、承認後の更新で再確認が働くか、権限を持つ人が意図せず迂回できないかを、実際の設定で確かめます。台帳に名前を書いただけでは、マージ条件にならないからです。

マージ時に見るのは、必要な知識を持つ担当者の承認、指定した検査結果、最新差分の再確認、例外責任の記録です。一つでも欠けるPRは、作成者がAIでも人でもマージできない。文書・表示、アプリ挙動、認証やリリース境界で担当・検査・例外承認を分け、その違いをリポジトリ設定が強制できて初めて、自社で実行できる条件になります。