Contents
GitHub Actionsで環境変数を設定する基本
GitHub Actionsでは、ワークフローの実行時に必要となる情報を管理するために環境変数の設定が不可欠です。特にenvキーワードを用いることで、シンプルかつ効率的に環境変数を定義できます。このセクションでは、envによる基本的な設定方法と具体的なコード例を紹介します。また、envキーワードのネスト構造や階層範囲について詳しく解説し、ワークフロー全体での定義方法にも焦点を当てます。
envキーワードの基本構文
GitHub Actionsのワークフローファイル（.github/workflows/xxx.yml）内で環境変数を定義するには、env:セクションを使用します。以下は簡単な例です：
|
1 2 3 4 5 6 7 8 9 10 |
jobs: build: runs-on: ubuntu-latest env: API_KEY: "your_api_key" ENV_TYPE: "production" steps: - name: 環境変数の出力 run: echo "**API_KEY**: ${{ env.API_KEY }}" |
この例では、env:以下のAPI_KEYとENV_TYPEがジョブ内で参照可能な環境変数として定義されています。envキーワードを使用することで、複数のステップで共有するパラメータを一括管理できます。
注意:
envセクションに定義された変数は、ワークフロー内の一連のジョブやステップで利用可能です。これにより、コードの保守性が向上します。
環境変数の階層構造とスコープ
envキーワードには、ワークフローレベルとジョブレベルの2つの定義方法があり、それぞれ異なるスコープを持ちます。これにより、共通の環境変数を全ジョブに適用するか、特定のジョブに限定して使用するかを選択できます。
ワークフローレベルでのenv
ワークフローレベルでenv:を定義すると、すべてのジョブがこの環境変数を共有できます。これは、共通の設定値（例えばデバッグ用フラグ）を統一管理する際に非常に有用です。
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
env: COMMON_ENV: "shared_value" jobs: job1: runs-on: ubuntu-latest steps: - run: echo "**COMMON_ENV**: ${{ env.COMMON_ENV }}" job2: runs-on: ubuntu-latest steps: - run: echo "**COMMON_ENV**: ${{ env.COMMON_ENV }}" |
ジョブレベルでのenv
一方で、あるジョブ内でのみ有効な環境変数を定義する場合は、jobs.job_name.env:に記述します。この場合、他のジョブでは参照できません。
|
1 2 3 4 5 6 7 8 |
jobs: job1: runs-on: ubuntu-latest env: JOB1_ENV: "value1" steps: - run: echo "**JOB1_ENV**: ${{ env.JOB1_ENV }}" |
| 定義範囲 | 共有対象 | 使用例 |
|---|---|---|
jobs.job.env |
ジョブ単位 | ジョブ固有の設定値 |
env: |
ワークフロー全体 | ジョブ間で共有する定数 |
環境変数の参照と利用
環境変数を参照する際には、$${{ env.VARIABLE }}という構文を使います。これはYAMLファイル内での展開形式です。
テンプレート構文の書き方
以下のように、ステップ内のコマンドで環境変数を呼び出します：
|
1 2 |
echo "**API_KEY**: ${{ env.API_KEY }}" |
また、env:で定義した値は、すべてのステップで参照可能です。
デバッグ時の確認手順
環境変数が正しく取得されているかを確認するには、以下の手順を実施してください：
echo "**VARIABLE**: ${{ env.VARIABLE }}"コマンドを追加- ワークフローを実行し、ログから出力された値を確認
- 予期せぬ値の場合は、ワークフローファイルとSecretsの設定に問題がある可能性あり
ヒント:
env:で定義した変数がsecrets:と競合する場合、優先順位はsecrets:が上になります。
セキュリティに配慮した環境変数の扱い方
機密情報（APIキーなど）は明文で設定しないことがセキュリティ上の基本です。GitHub Actionsでは、secrets:を使用して安全に管理できる仕組みが用意されています。
Secretsの利用シーン
以下のようなケースでは、必ずSecretsを活用することが推奨されます：
- APIキーやトークンなどの機密情報
- システム内部で使用するパスワード（DB認証など）
- プロダクション環境向けの設定値
GitHub側に秘密情報を保存し、ワークフローの中で${{ secrets.VARIABLE_NAME }}と参照することで、明文での記述リスクを回避できます。
明文設定のリスク
以下の理由から、機密情報は絶対に明文で定義しないようにしてください：
- ソースコードへのリーク: ワークフローYAMLファイルがリポジトリ内にあるため、アクセス権を持つ者が参照可能です。
- 誤った設定の可能性: たとえ一時的にでも公開されると、悪意ある第三者に悪用されるリスクがあります。
注意:
env:セクションにAPIキーなどを直接記述すると、リポジトリの履歴やログに残るため非常に危険です。Secretsで管理することが推奨されます。
複数ジョブ間での環境変数共有方法
GitHub Actionsでは、ワークフロー内の複数ジョブで環境変数を共有できる仕組みがあります。ただし、定義範囲によって利用可能かが異なります。
ワークフローレベルとジョブレベルの比較
以下にワークフローレベルとジョブレベルでのenv定義の違いを表にまとめました：
| 項目 | ワークフローレベル | ジョブレベル |
|---|---|---|
| 定義位置 | env: |
jobs.job_name.env: |
| 共有対象 | すべてのジョブ | 該当ジョブのみ |
| 使用例 | ジョブ間で共有する定数 | ローカル設定用変数 |
環境変数とSecretsの優先順位
env:に定義された環境変数が、secrets:と名前が重複した場合、secrets:の値が優先されます。これはセキュリティ上の仕様であり、意図的にSecretsを上書きする必要がある場合でも注意が必要です。
ベストプラクティスとよくある間違い
環境変数の管理には、プロジェクト全体にわたる一貫性が求められます。以下に実践的なガイドラインを紹介します。
環境変数の命名規則
一貫した命名ルールを確立することで、チーム内での誤解や混乱を防ぎます：
- 大文字とアンダースコアを使用（例:
API_KEY） - 複数の環境用に接尾語を付ける（例:
ENV_TYPE=production）
不要な定義の回避
以下のようなケースでは、意図せずに環境変数を定義してしまうことがあります：
- ジョブ内で一時的に使用する値
- 既存のシステム変数と重複する名前
例:
env:でHOMEなど、OSが自動で設定する変数を再定義すると、予期せぬ挙動を引き起こす可能性があります。
結論とまとめ
本記事では、GitHub Actionsでの環境変数の設定方法を以下のように解説しました：
envキーワードで基本的な環境変数を定義- Secretsを使って機密情報を安全に管理
- ワークフロー全体とジョブ単位での共有方法
- 環境変数の参照方法（
$${{ env.VARIABLE }}） - 命名規則や不要な定義の回避といったベストプラクティス
環境変数の適切な設定は、ワークフローの安定性とセキュリティを保つために不可欠です。記事内のコードサンプルを参考に、自身のGitHub Actionsワークフローで環境変数の設定を試してみましょう。