AI PRをマージするための5つの質問
AIコーディングエージェントが作ったPRを、AI作成という理由だけで簡単にマージしたり、一律に拒否したりしてはいけません。
基本条件は作成者にかかわらず同じです。重要なブランチを保護し、現在のRevisionに対する必須検査を通し、影響を理解する人が責任を持って承認します。AIが関与した場合は、Agentの権限、作業の由来、レビュー可能性の証拠を加えます。
マージ判断は次の5つの質問で構成します。
- 変更は保護ブランチの通常PR経路を通ったか？
- マージする現在のRevisionに必要な検査をすべて実行したか？
- 変更種別に合う人が最新Diffを承認したか？
- 誰がどの条件で変更を作ったか追跡できるか？
- 例外には理由・責任者・事後レビュー日程が残るか？
NIST SSDFはセキュリティ検査基準の定義、承認・拒否・例外の記録、Code Review・分析・実行可能Codeのテスト結果を開発フローに残すことを勧めています。SLSA Source Trackも保護ブランチ、技術統制、Source Provenance、人が理解できる変更表示を保証要素としています。作成者が人かAgentかはこの構造の一入力であり、方針全体の代わりにはなりません。[6]
AI専用規則より先に保護ブランチを整える
AI PRを管理しようと、専用ラベルやチェックリストから作るチームがあります。しかし既定ブランチへ直接Pushでき、失敗検査が警告だけで、管理者が無記録で迂回できるなら、専用チェックリストの実効性は低いものです。
GitHub、GitLab、Bitbucket、Azure Reposは名称や実装こそ違いますが、保護ブランチ、PR/MR経路、必須検査、承認、直接Push制限を提供します。共通の基本線は、この統制を実際のマージ条件として強制することです。[7]
共有の既定・Releaseブランチには、少なくとも次を適用します。
· 直接PushとForce Pushを原則として防ぎます。
· すべての変更をPR経由にします。
· 必須検査が失敗または未実行ならマージできなくします。
· 新Commit追加後は最新変更の承認を再確認します。
· 迂回権限は少数の指定Roleだけに与えます。
重要なのは緑の表示ではなく、どのシステムがどのRevisionの結果を作ったかです。GitHub RulesetはWrite権限のある人やIntegrationがStatusを設定できることを前提に、必要なら特定GitHub Appを想定発行者として指定できます。自作検査にも同じ原則を適用します。検査名・実行主体・対象Commit・結果Artifactが結ばれなければ、緑の表示だけでは不十分です。[7]
要件から承認までつながる根拠 — 要件、テスト、不具合対応、承認記録をつなぎ、共通の基準で品質を判断します。
Required Checksは検査の存在ではなく必要な証拠を意味する
全PRに同じ検査を適用すると管理は容易でも、リスクには合わない場合があります。文書の誤字とIAM Policy変更に同じ検査では、前者に過剰で後者に不足します。
この記事では検査を4層に分けます。
基本整合性検査はBuild、静的検査、必須テストで、Repositoryの基本品質条件を壊していないか確認します。
セキュリティ検査はSecret、脆弱なCodeパターン、Policy違反を探します。
Dependency検査はManifestとLockfileの直接・間接依存、脆弱性、License、供給元の変化を確認します。
変更種別別の検査はIaC Plan、権限Diff、Workflow Permission、生成物の再現など、特定変更だけに必要な証拠を作ります。
具体的なテスト選択は影響と回帰リスクによって変わり、別の回帰範囲設計の問題です。ここで定めるのは、選択した検査をマージ前に実行し、結果を現在のHead Revisionに結ぶ条件です。
未実行や評価不能なセキュリティ検査を成功扱いにしてはいけません。GitLabの承認方針は、Scanner結果がない、またはPolicyを評価できない場合に追加承認を求めるFail-closedを支援します。SLSAも技術統制が継続適用された証拠を求めます。特に権限・Secret・配布経路では「結果なし」と「問題なし」を分けます。[8]
AI Reviewは補助証拠であり、人の責任を自動代替しない
AI Code Reviewは反復パターン、見落としの可能性、Code説明を素早く提供できます。ただし、その結果だけで人の承認要件を満たしたとは見なせません。
現在のGitHub Copilot Code ReviewはApproveやRequest changesではなくCommentを残し、Required Approval数に含まれず、自らマージを止めません。Atlassian Rovo Devも、大きなPRではCommentを残さない場合があり、Dependency LockfileやBinaryなどを自動で除外すると明記しています。[9]
これらの例が全AI Reviewに同じ限界を定めるわけではありません。ただし次の原則は明確です。
AI Reviewを使うなら、何を検査し何を見なかったかを確認できる必要があります。
結果は必須検査や人のレビューの補助証拠にできます。しかし未実行や一部除外があるのに、単にAIレビュー完了と表示してはいけません。
人の承認が必須の変更
共有の既定ブランチでは通常、作成者とは別の承認者が必要です。Agentが作成した場合、指示して結果を提出した人と、実際のDiffを独立して承認する人を分ける方が安全です。
現在のGitHub Copilot Agentフローでも、作業を割り当てた人の承認がRequired Approvalに数えられず、別Reviewerが必要な場合があります。GitHubとAzure Reposは、最新Pushを行った人とは別の承認者を要求する統制も提供します。[10]
以下の変更は、少なくとも該当領域の責任者による人の承認を必須にします。
SecretとCredential
実際のAPI Key、Token、Password、Private KeyをSource CodeやPR説明に入れてはいけません。ScannerがCredentialを検出したらレビュー項目に回すだけでなく、まずマージを止め値を除きます。遠隔RepositoryへPush済みなら失効・交換も確認します。[11]
Secret Scan合格はSecret不在の証明ではありません。GitLab Secret Push Protectionも遅延と誤検知を減らすため高信頼Patternを使い、独自PrefixのTokenを検出できない場合があると説明しています。参照経路、環境変数、Vault接続、Token Scope、Signing Key使用の変更は、PlatformかSecurity責任者が直接確認します。[12]
Permission・IAM・認証・認可
Role、Policy、Service Account、OAuth Scope、Repository App権限、認証・認可ロジックの変更は、少ない行数でも影響が大きくなります。
承認者は変更前後に誰がどのResourceへアクセスできるかを確認します。ワイルドカード権限、管理者Role追加、Tenant境界変更には理由と影響Identity一覧が必要です。NIST SSDFとSP 800-204Dは、Source CodeとConfiguration-as-CodeをLeast Privilegeで保護し、Commit・Build・Artifact作業の権限を細分化するよう勧めています。[6]
DependencyとLockfile
Dependency変更には直接追加したPackageだけでなく、Lockfile経由で変わる間接依存も含みます。GitHub Dependency ReviewはManifestとLockfileの直接・間接変更や既知の脆弱性をPR単位で比較し、Required Checkにもできます。[13]
新Package RegistryやGit Source、Major Version更新、Build PluginやPost-install Scriptの導入では、人が供給元と実行権限を確認します。NIST SSDFもCommercial・Open Sourceを含む第三者Componentをライフサイクル全体で検証するよう求めています。[6]
事前に供給元と範囲を定めた自動Patch Updateまで、常に複数人が承認すべきという意味ではありません。狭いTrusted Automation、脆弱性・License・Build検査、明示的Auto-merge方針を組み合わせた限定例外を設けられます。Bot Identityと変更範囲が固定され、方針適用時点を監査できることが条件です。SLSA Source Trackも高い保証水準で、明示的に定義したTrusted Robotの例外を認めています。[14]
CI Workflow・Build・マージ規則
CI WorkflowとBuild Scriptは検査自体を定義します。変更PRが自身の必須検査を消し、任意に成功扱いにし、広いSecretやRepository権限を得られるなら、一般Codeより強いレビューが必要です。
GitHubはAgentが変えたWorkflowの実行前に人が内容を確認する基本統制を設け、機密Secretへアクセスできる点も警告しています。NISTもCI/CDのSigning Key、Cloud Credential、Environment Secretを悪性Codeに奪われないよう、Clientと実行環境の保護を求めています。[10]
次のファイルにはPlatform・Repository管理者またはSecurity Ownerを自動Reviewerとして指定します。
· CI/CD Workflowと共通Pipeline Template
· Branch RulesetとMerge Policy
· CODEOWNERSまたはRequired Reviewer設定
· Build・Packaging・Signing Script
· Repository AppとAction Permission
· Secretを使うWorkflow定義
Infrastructure・Deployment Configuration
IaC、Kubernetes Manifest、Deployment Workflow、Runtime ConfigurationはCodeに見えても、実環境のNetwork、Compute、Identity、Data Store、配布権限を変えます。
マージ前にはSyntax合格より実行結果に近いPlanやDiffが必要です。適用環境、Resourceの作成・削除、Public Exposure・IAM・Stateの変化を確認できなければなりません。Azure ReposもDeployment・Infrastructure CodeとShared Pipeline Templateを、指定Reviewerが必要な機密経路の例としています。[15]
Change Type × Merge Requirement Matrix
Matrixは特定製品の機能表ではなく、公式文書と標準から再構成したチーム運用の推奨案です。実際の検査と承認数はRepositoryのリスク、規制、チーム規模に合わせます。
AI作成だけを理由に承認を一律強化しているわけではありません。人のIAM変更にも強い承認が必要で、AIが直した誤字は狭い方針で処理できます。判断単位は作成者ではなく、変更影響と統制失敗時の結果です。
Change Type | Required Checks | Human Approval | マージ前の追加証拠 |
|---|---|---|---|
| 文書・コメント・非実行Metadata | 文書Build、Link・Format検査、基本Secret Scan | 通常は独立Reviewer 1名。範囲の固定されたTrusted Automationは事前承認方針で例外可能 | 実行Code・Configuration・権限に影響しないことの確認 |
| 一般Application Code | 基本Build・静的検査・選択したテスト・セキュリティ検査。すべて現在のHead Revisionが対象 | 変更作成者とは別のReviewer | 変更目的、影響Component、検査結果リンク |
| Test-only変更 | 変更したTest Suiteと基本検査。Snapshot大量更新ではDiff検証 | Assertion削除・緩和、Coverage低下、大量Snapshot変更はDomain Owner必須 | 製品動作の変更か、Test期待値だけの変更かを説明 |
| Dependency・Manifest・Lockfile | 直接・間接Dependency Diff、脆弱性、License、Build | 新しい供給元、Major Version、Build Plugin、Post-install Scriptは人の承認必須 | Package供給元、ManifestとLockfileの関係、新しい実行権限 |
| Secret・Credential参照 | Push Protection、Secret Scan、Configuration検証 | SecurityまたはPlatform Owner必須 | 実Secret値を含まないこと、露出時の失効・交換記録、Scopeの前後比較 |
| Permission・IAM・認証・認可 | Policy検査、権限Diff、関連セキュリティ検査 | Domain Ownerと独立承認者必須 | 変更前後のRole・Principal・Resource・Tenant境界 |
| CI/CD・Build・Signing Workflow | Workflow検証、Permission・SecretアクセスDiff、想定Check発行者の確認 | PlatformまたはRepository管理者必須。作成者単独承認は禁止 | 使用Token・Secret・Environment、検査の削除・緩和の有無 |
| Ruleset・Branch Policy・CODEOWNERS | Policy-as-Code検査または設定Diff、管理者Audit | Repository管理者と独立したSecurity・Platform責任者 | Bypass対象、Required Check・Approvalの変更前後 |
| IaC・Deployment・Runtime Configuration | Validate、Plan、Policy Check、環境別セキュリティ検査 | Platform Ownerまたは該当Service Owner必須 | 適用環境、Resource・Network・IAM・Stateの変化 |
| Generated Code・Generated Artifact | Build・再生成検査、Hash・Provenance、原SourceとGeneratorの検証 | 機能影響を説明できるDomain Reviewer | Generator・Version・入力Source・Base/Head Revision・生成経路 |
| 大規模Refactor・レビュー不能な変更 | 関連検査をすべて実行するが、合格だけでマージしない | 影響領域別Owner。必要なら2人目の独立Reviewer | PR分割計画、Review Map、生成ファイルと手動変更の区別 |
| Emergency Hotfix | 時間内に可能な検査を行い、省略検査を明記 | 事前指定したOverride AuthorityとRisk Owner | Incident ID、迂回理由、Control、期限、事後レビュー期限 |
Generated CodeのProvenanceに何を残すか
Agent生成Codeの由来を残すために、Prompt全体やモデルの内部推論をRepositoryへコピーする必要はありません。PromptにはCredential、顧客情報、内部Architectureが含まれ得て、自然言語の説明も正しさを証明しません。
代わりに、Policy判断に使える観察可能な記録を残します。
SLSA Source v1.2は、Revisionを作ったProcess・Contributor、由来となるParent Revisionを示す情報をSource Provenanceと定義します。人がPlain-text変更を理解できるDiffと、技術統制・Actor IdentityをRevisionへ結ぶことも求めています。[14]
GitHubの現在のAgentフローのように、CommitからSession Logへ移れる実装もあります。固有のSession機能がなくても、Task、Agent Identity、Base/Head Revision、検査、人の承認者を結べば基本的な監査構造を作れます。[16]
ProvenanceがあってもCodeが正しいとは限りません。作られ方と通過した統制を示すもので、正しさと安全性は別のReviewや検査で判断します。
フィールド | 記録する値 |
|---|---|
| agent_identity | "" |
| agent_provider_or_service | "" |
| human_requester | "" |
| task_or_issue | "" |
| repository | "" |
| target_branch | "" |
| base_revision | "" |
| head_revision | "" |
| generated_or_modified_paths | [] |
| generator_or_tool_versions | [] |
| external_tools_or_context_used | [] |
| required_checks | |
| required_checks[].name | "" |
| required_checks[].issuer | "" |
| required_checks[].revision | "" |
| required_checks[].result | "" |
| required_checks[].evidence | "" |
| human_approver | "" |
| merge_actor | "" |
| merged_at | "" |
大きすぎるPRは検査に通ってもマージできない場合がある
Reviewerが理解できない変更は、レビューが完了した変更ではありません。
Agentは多くのファイルを素早く変え、機能追加、Refactor、Dependency Update、生成ファイル、Formattingを一つのPRに混ぜがちです。全検査に通っても、意図と影響が分かれていなければ問題発見や後の原因追跡が難しくなります。
AI ReviewにもCoverage限界があります。Rovo Devは1万行超のPRにCommentを残さない場合があり、Lockfile・Binary・Snapshotなども自動除外します。全チーム共通の行数上限ではありませんが、AIが見たから大きなPRもレビュー済みと考えてはいけない根拠になります。[17]
固定行数だけでなく、次の信号を合わせて見ます。
· 異なる目的の変更が一つのPRに混ざっていないか
· ReviewerがDiffを説明できるか
· 生成ファイルと人が修正したSourceが分かれているか
· Dependency・IAM・Deployment変更が一般Codeに埋もれていないか
· ツールが見ていないディレクトリや形式はないか
· 検査失敗を特定変更へ絞り込めるか
範囲を超えたら機能・リスク・Dependency単位で分けます。分割不能なMigrationや機械的大規模変換なら、Source PR、生成結果、再生成Command、標本レビュー範囲、Integrity Checkを別証拠として残します。
Audit TrailはMerge操作の記録だけでは足りない
マージ記録には次の答えが必要です。
· 変更意図を承認した責任者は誰か
· 実Actorは人・App・Service Accountのどれか
· どのBaseからどのHead Revisionを作ったか
· どのIdentityがどの検査を実行したか
· ReviewerはどのRevisionを承認したか
· どの規則が適用され、どれが迂回されたか
· 最終マージActorと時刻は何か
Agentの権限モデルは製品で異なります。Copilot Cloud AgentのようにApp Identityと特定Branchに制限される場合、GitLabのようにService Accountを使う場合、ユーザー権限を委任される場合があります。AI使用とだけ記すのではなく、実IdentityとScopeを残します。[18]
標準Audit Logを永久台帳と考えてもいけません。現在GitHub Organizationは直近180日、Azure DevOps Audit Eventは基本90日を保存します。長期保存にはExportやAudit Streamingなど別の保持方針が必要です。[19]
Emergency Overrideは保護規則を無効にする行為ではない
障害や重大なセキュリティ問題では通常検査と承認を待てない場合があります。それでもBranch Protectionを一時無効にしたり、管理者で無言の直接Pushをしたりすると、緊急変更が最も追跡しにくくなります。
Emergency Overrideは通常条件を消すのではなく、誰が何の理由で未検証リスクを一時受容したかを記録する別経路にします。
権限は事前指定した少数に限定し、可能なら直接Pushより既存PRの特定条件を迂回します。GitLabはユーザー・Role・Service Accountへの限定、UIやPush Optionでの理由要求、Audit記録を支援します。GitHubもBypass RequestとRule Insightで申請者、承認者、状態、失敗・迂回規則を確認できます。[8]
永久Exemptionは緊急迂回とは別です。GitHubは通常Bypassを明示的Break-glassとAudit Signalを残す動作とし、exemptは静かに統制を飛ばす別設定にしています。広い永久例外を与えると、後から通常自動化と異常な迂回を分けにくくなります。[20]
事後レビューでは省略検査を実マージRevisionに再実行し、Domain OwnerがDiffを確認して問題を後続PR・Issueへ結びます。Overrideが続くなら個人判断だけでなく、検査時間、Ownership、Runbook、Policy構造の問題も調べます。
フィールド | 記録する値 |
|---|---|
| override_id | "" |
| pull_request | "" |
| head_revision | "" |
| incident_or_change_id | "" |
| reason | "" |
| risk_owner | "" |
| bypassed_controls | |
| bypassed_controls[].control | "" |
| bypassed_controls[].reason | "" |
| override_approver | "" |
| merge_actor | "" |
| approved_at | "" |
| expires_at | "" |
| post_review_due_at | "" |
| post_review_result | "" |
| follow_up_issues | [] |
マージ可とリリース可は同じ判定ではない
Merge Gateの通過は、変更を保護ブランチの次の状態として受け入れられるという意味です。本番配布やユーザーへのリリースも自動的に許可するわけではありません。
リリース判断には複数変更の結合結果、未解決欠陥、運用準備、観測性、復旧可能性、残存リスクも必要です。この全体判断は、テスト結果以外に何を確認してリリースを決めるかを扱う上位記事が担当します。
要求とCode・テストの関係は追跡性設計、回帰範囲はリスクベース回帰戦略、自動化対象はテスト自動化ポートフォリオが扱います。この記事は、それらをマージ前に検証可能な証拠として提出し、適切な人が責任を持って承認するGateを設計します。
