導入：なぜ環境変数保護が必要なのか
チーム開発において、Staging環境とProduction環境で同じデプロイパイプラインを共有しているケースは多いでしょう。しかし、開発用のブランチから誤って本番用のデータベース接続情報やAPIキーを参照してしまうと、重大なインシデントに直結します。GitHub Actionsの「Environments」機能を使うことで、特定のブランチやタグからしかシークレットにアクセスできないように制限し、さらにデプロイ前に人的な承認プロセス（Approval Flow）を挟むことが可能になります。これにより、CI/CDの安全性と統制を飛躍的に高めることができます。
基礎知識：GitHub Environmentsとは
GitHub Environmentsは、リポジトリの設定で定義できる「実行環境」の単位です。各環境（production, stagingなど）に対して個別に「環境シークレット（Environment Secrets）」を設定できます。
重要な点は、特定のブランチのみデプロイを許可する「Deployment branches」設定と、実行前に手動承認を求める「Required reviewers」設定が備わっていることです。これらを組み合わせることで、意図しないタイミングや不正なブランチからのデプロイをシステムレベルで遮断します。
実装：Environmentsの構築手順
1. GitHubリポジトリの「Settings」>「Environments」へ移動し、「New environment」から「production」を作成します。
2. 作成した環境の設定画面で、「Required reviewers」にチェックを入れ、承認権限を持つユーザーやチームを指定します。
3. 同画面の「Environment secrets」に、本番環境用のシークレット（DB_PASSWORDなど）を登録します。
4. 最後に、Workflowファイル（YAML）で `environment: production` を指定します。
サンプルプログラム：承認フロー付きデプロイワークフロー
このワークフローは、mainブランチからのpush時にのみ実行され、production環境のシークレットを使用し、かつ手動承認を待機する設定です。
name: Deploy to Production
on:
push:
branches: [ main ] # mainブランチのみを対象にする
jobs:
deploy:
runs-on: ubuntu-latest
# ここで事前に作成したEnvironmentを指定
environment:
name: production
url: https://your-production-app.com
steps:
- name: Checkout code
uses: actions/checkout@v4
- name: Deploy to Production
# この環境に登録されたシークレットは、承認が完了した後にのみ参照可能
env:
DB_PASSWORD: ${{ secrets.DB_PASSWORD }}
run: |
echo “本番環境へのデプロイを開始します…”
# 実際にはここにデプロイスクリプトを記述
./deploy.sh –password $DB_PASSWORD
応用・注意点：現場で陥りやすいバグの回避策
1. シークレットのスコープを意識する：リポジトリ全体レベルのシークレットと、環境レベルのシークレットが重複した場合、環境レベルのものが優先されます。紛らわしさを避けるため、環境固有の機密情報は必ずEnvironment側に集約しましょう。
2. 承認者の不在リスク：承認者を個人で設定すると、その人が休暇の際にデプロイが止まるリスクがあります。現場では、GitHub Team（グループ）を承認者に指定することで、特定の個人に依存しない運用体制を構築するのが定石です。
3. デバッグ時の注意：ワークフローの実行状況はGitHub上の「Actions」タブから確認できます。承認待ちの状態（Waiting for review）になるとジョブは一時停止します。承認ボタンが見当たらない場合は、権限設定を確認してください。
コメント