「main にマージしても、人間が承認するまで本番デプロイは走らせたくない」——CI/CD を組むと必ず欲しくなる仕組みです。GitHub には環境（Environments）の 必須承認レビュアー という純正機能があり、これを使えば「マージ → 自動で停止 → 承認ボタンで再開」という理想的なゲートが作れます。

ところが、プライベートリポジトリでは思わぬ落とし穴があります。

落とし穴: 承認レビュアーは Pro でも private では使えない

環境の必須承認レビュアーや待機タイマーといった「デプロイ保護規則」は、GitHub Free / Pro / Team ではパブリックリポジトリでしか使えません。プライベートリポジトリで使うには GitHub Enterprise が必要です。

つまり GitHub Pro を契約していても、プライベートリポジトリに承認レビュアーを設定しようとすると API はこう返します。

HTTP 422: Failed to create the environment protection rule.
Please ensure the billing plan supports the required reviewers protection rule.

これは課金トラブルではなく プランの仕様です。環境（Environment）そのものは Pro の private でも作れますが、その上の「承認レビュアー」ルールだけは別枠、という点が紛らわしいところです。

解決策: workflow_dispatch を承認ゲートとして使う

純正ゲートが使えないなら、デプロイを手動実行（workflow_dispatch）にするのが確実です。

name: Deploy
on:
  # 手動実行 = 人間による「デプロイ承認」ゲート。
  # main にマージしただけでは走らず、Run workflow を押した時だけ実行される。
  workflow_dispatch:

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: production
    steps:
      - uses: actions/checkout@v4
      - name: 本番デプロイ
        run: echo "デプロイを実行"

こうすると main へのマージでは何も起きず、担当者が GitHub の Actions → Deploy → Run workflow を押したときだけデプロイが走ります。ボタンを押す行為そのものが承認に相当するわけです。

どちらを選ぶか

• プライベートのまま運用したい → workflow_dispatch の手動ゲートが恒久解。追加コストゼロ。
• 純正の「自動停止 → 承認」UI が欲しい → リポジトリを public にするか、Enterprise にアップグレードするかの二択。

小さなチームや個人開発なら、まず手動ゲートで十分です。実際のデプロイ先（Vercel / Cloudflare など）は多くの場合それ自身にプロモーション承認の仕組みを持つので、GitHub 側のゲートに固執する必要もありません。

まとめ

• 環境の承認レビュアーは Free/Pro/Team では public 限定。private は Enterprise が必要。
• 代替として workflow_dispatch の手動デプロイが、無料・private で確実に動く承認ゲートになる。
• 「マージ ≠ デプロイ」を明示的に分離できれば、仕組みは何であれ目的は達成できる。