テンプレート、チェック、CODEOWNERS、ルール、環境ゲートを使用して PR ガバナンスを実装する例

このユニットでは、次の内容について説明します。

• プル要求がエージェント実行のアーキテクチャ制御ポイントとして機能する方法

• 必須チェックステータスを活用してプランのバリデーションを強制する方法

• CODEOWNERS とレビューを使用して変更をルーティングおよび承認する方法

プル要求はアーキテクチャ制御ポイントです

プル要求は、GitHubでのエージェント実行の主要な制御メカニズムです。 適切に設計されたアーキテクチャでは、保護されたブランチに直接変更を許可する代わりに、プル要求を通じてエージェントの変更がルーティングされ、ポリシーを使用してマージ要件が適用されます。

一般的な安全なワークフローは次のようになります。

Agent creates branch

    ↓

Agent opens pull request (includes plan)

    ↓

Required reviews validate approach

    ↓

GitHub Actions run required checks

    ↓

All checks pass + approvals complete

    ↓

Pull request can be merged

この構造により、自動化と人間によるレビューの両方によって実行が制御されます。

実装: 構造化されたプランを必要とする PR テンプレート

プルリクエスト テンプレートを使用することで、すべてのエージェントPRにおいてプランと証拠のセクションを一貫して提供することができます。

<!-- File: .github/pull_request_template.md -->

## Plan (required)
- **Goal:**
- **Scope (paths/files):**
- **Steps:**
  1.
  2.
  3.
- **Success criteria (verifiable):**
  - [ ] Required checks pass
  - [ ] Security signals reviewed (as applicable)
- **Risks + mitigations:**
- **Rollback / escalation plan:**

## Evidence
- Workflow run(s):
- Scan results (if applicable):

## Review checklist
- [ ] Plan reviewed and approved
- [ ] Required reviews satisfied
- [ ] Required checks satisfied

必要なステータスチェックを使用してプラン検証を強制する

テンプレートに加えて、必要な状態チェックとしてプランゲーティングを適用できます。 これにより、プロセスの期待値 ("プランを含む") がシステム保証に変わります。

# File: .github/workflows/plan-gate.yml
name: Plan Gate

on:
  pull_request:
    branches: [ main ]

jobs:
  require-plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Require plan artifact
        run: |
          if [ ! -f "Github/pull_request_template.md" ]; then
            echo "Github/pull_request_template.md is required for this pull request."
            exit 1
          fi
          echo "Github/pull_request_template.md found."

実装に関する注意:

リポジトリ管理者は、ルールセット/ブランチ保護を使用して Plan Gate を必須の状態チェックとしてマークし、プランが存在しない限り PR をマージできないことを確認できます。

GitHubは、エージェントによって生成された変更に対してワークフローを実行する前に、明示的な承認を要求できます。

CODEOWNERS を使用した安全性の確保

CODEOWNERS を使用すると、機密性の高い領域に対する変更が適切なレビュー担当者に自動的に行われます。

# File: CODEOWNERS

/security/ @security-team
/.github/workflows/ @platform-team
/infra/ @platform-team
* @core-team

これにより、リスクの高いパスに影響を与える計画と変更セットを、適切な専門家からの可視性なしでマージすることはできません (必要なレビュー ポリシーと組み合わせた場合)。

検証なしで実行に注意する

エージェントがレビューなしで必要なチェックまたはマージをバイパスできる場合、アーキテクチャは主な安全性メカニズムを失います。 これはモデルの問題が少なく、ワークフロー設計の失敗です。

重要なポイント: プル要求は単なるコラボレーション ツールではなく、強制メカニズムです。

次に、タスクのリスクに基づいて、エージェントに必要な自律性の量を定義します。