環境とシークレットの管理

環境を分離する理由

一般的なプロジェクトは開発(development)・ステージング(staging)・本番(production)のように複数の環境を使い分けます。開発中の実験的な変更が本番のユーザーに影響しないよう、 環境ごとにデータベースや外部サービスの接続先を分離するのが基本です。

環境変数による設定分離

データベース接続先やAPIのURLなど、環境ごとに異なる値は環境変数として外部化し、コードそのものは環境間で変えないようにします。

// ① config.ts: 環境変数から設定を読み込む
export const config = {
  apiBaseUrl: process.env.API_BASE_URL,
  databaseUrl: process.env.DATABASE_URL,
  environment: process.env.NODE_ENV ?? "development",
};

// ② .env.example: リポジトリにコミットするテンプレート(値は空/ダミー)
API_BASE_URL=
DATABASE_URL=
NODE_ENV=development

実際の値が入った.envファイルは.gitignoreに含め、絶対にコミットしないようにします。

シークレットの安全な管理

APIキーやデータベースのパスワードなどの機密情報(シークレット)は、 ソースコードに直接書かず、CI/CDプラットフォームが提供するシークレット管理機能を使います。

# ① .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Deploy to production
        env:
          API_KEY: ${{ secrets.PRODUCTION_API_KEY }}
          DATABASE_URL: ${{ secrets.PRODUCTION_DATABASE_URL }}
        run: npm run deploy

secrets.PRODUCTION_API_KEYのような値はGitHubのリポジトリ設定で暗号化されて保管され、 ログにも実際の値がそのまま出力されないよう保護されます。

よくある事故とその防止策

• • .envファイルを誤ってコミットしてしまう → .gitignoreへの登録とpre-commitフックでの検査
• • ステージング用のキーを本番のコードに書いたまま忘れる → 環境ごとにシークレットを完全に分ける
• • アクセス権限を必要以上に広く付与してしまう → 最小権限の原則で必要な範囲だけに絞る