GitHub Actions コンテキスト辞典：github／env／runner／secrets の使い分け最速理解

2025年10月27日

GitHub Actions

GitHub Actions コンテキスト辞典：github／env／runner／secrets の使い分け最速理解

GitHub Actions でワークフローを書いていると、github、env、runner、secrets といったコンテキストオブジェクトが頻繁に登場します。しかし、「どのコンテキストをどの場面で使えばいいのか」が分からず、混乱してしまうことはないでしょうか。

本記事では、GitHub Actions の主要な 4 つのコンテキスト（github、env、runner、secrets）について、それぞれの役割と使い分けを体系的に解説します。具体例や図解を交えながら、実務で迷わず使えるレベルまで理解を深めていきましょう。

背景

GitHub Actions のコンテキストとは

GitHub Actions では、ワークフロー実行時にさまざまな情報にアクセスできるよう、コンテキスト（Context） という仕組みが用意されています。コンテキストは、ワークフローの実行環境やイベント情報、設定した変数などを保持するオブジェクトで、${{ }} 構文でアクセスします。

コンテキストを使うことで、実行環境に応じた動的な処理や、機密情報の安全な取り扱いが可能になるのです。

主要な 4 つのコンテキスト

GitHub Actions には多数のコンテキストがありますが、特に重要なのが以下の 4 つです。

#	コンテキスト	主な用途
1	`github`	イベント情報、リポジトリ情報、実行環境のメタデータ
2	`env`	ユーザー定義の環境変数
3	`runner`	ランナー環境の情報（OS、一時ディレクトリなど）
4	`secrets`	機密情報（API キー、トークンなど）

これらのコンテキストを正しく使い分けることで、ワークフローの柔軟性とセキュリティが大幅に向上します。

コンテキストの全体像

以下の図は、GitHub Actions ワークフロー実行時に各コンテキストがどのように関連しているかを示したものです。

mermaidflowchart TB
  workflow["ワークフロー実行"]
  github["github<br/>イベント・リポジトリ情報"]
  env["env<br/>環境変数"]
  runner["runner<br/>ランナー環境情報"]
  secrets["secrets<br/>機密情報"]

  workflow --> github
  workflow --> env
  workflow --> runner
  workflow --> secrets

  github -->|イベント判定| condition["条件分岐"]
  env -->|変数展開| steps["ステップ実行"]
  runner -->|パス解決| steps
  secrets -->|認証| steps

図で理解できる要点:

各コンテキストはワークフロー実行時に独立した役割を持つ
github はイベント判定、env は変数管理、runner は環境情報、secrets は認証に使われる
すべてのコンテキストが協調してワークフローを構成する

課題

コンテキストの使い分けが難しい理由

GitHub Actions を学び始めたばかりのときは、以下のような疑問に直面します。

「環境変数は env で定義するのに、なぜ github.env というプロパティもあるのか」
「secrets と env はどう違うのか。どちらで管理すべきか」
「runner.os は何に使うのか。github コンテキストとの違いは」

これらの疑問が生じるのは、各コンテキストの 役割の境界 が曖昧に見えるためです。

よくある混乱パターン

実際の開発現場で見られる混乱を整理してみましょう。

#	混乱パターン	原因
1	`env` と `secrets` を混同	どちらも変数に見えるが、用途が異なる
2	`github.repository` と `runner.workspace` の違いが不明	どちらもパス情報だが、意味が異なる
3	`github.event` の構造が複雑	イベントごとに異なるプロパティがある
4	コンテキストが利用できないタイミング	ワークフロー構文のどこで使えるかが不明

これらの混乱を解消するには、各コンテキストの 設計意図 と 利用可能な場面 を理解することが重要です。

コンテキスト選択の判断フロー

どのコンテキストを使うべきかは、以下のような判断フローで考えると明確になります。

mermaidflowchart TD
  start["変数や情報にアクセスしたい"]
  q1{"機密情報?"}
  q2{"イベント情報?"}
  q3{"環境情報?"}
  q4{"ユーザー定義変数?"}

  start --> q1
  q1 -->|はい| secrets["secrets を使用"]
  q1 -->|いいえ| q2
  q2 -->|はい| github["github を使用"]
  q2 -->|いいえ| q3
  q3 -->|はい| runner["runner を使用"]
  q3 -->|いいえ| q4
  q4 -->|はい| env["env を使用"]
  q4 -->|いいえ| other["他のコンテキストを検討"]

図で理解できる要点:

機密情報は必ず secrets を使う
イベント情報は github、環境情報は runner
ユーザー定義変数は env で管理

解決策

1. `github` コンテキスト：イベントとメタデータの宝庫

github コンテキストは、ワークフローをトリガーしたイベント情報やリポジトリのメタデータにアクセスするためのコンテキストです。

主なプロパティ

#	プロパティ	説明	例
1	`github.event_name`	トリガーイベント名	`push`, `pull_request`
2	`github.repository`	リポジトリ名	`owner/repo-name`
3	`github.ref`	Git リファレンス	`refs/heads/main`
4	`github.sha`	コミット SHA	`abc123...`
5	`github.actor`	イベントを起こしたユーザー	`octocat`
6	`github.event`	イベントペイロード全体	オブジェクト

使用例：プルリクエストの情報を取得

yamlname: PR Info
on: pull_request

jobs:
  info:
    runs-on: ubuntu-latest
    steps:
      - name: PR 情報を表示
        run: |
          echo "PR番号: ${{ github.event.pull_request.number }}"
          echo "作成者: ${{ github.event.pull_request.user.login }}"
          echo "ブランチ: ${{ github.head_ref }}"

このように、github コンテキストを使うことで、プルリクエストの詳細情報に簡単にアクセスできます。

条件分岐での活用

yamljobs:
  deploy:
    runs-on: ubuntu-latest
    # main ブランチへの push のみデプロイ
    if: github.ref == 'refs/heads/main' && github.event_name == 'push'
    steps:
      - name: デプロイ実行
        run: echo "デプロイ中..."

if 条件で github コンテキストを使えば、特定のブランチやイベントでのみジョブを実行できるのです。

github コンテキストの使いどころ

イベントの種類やブランチによる条件分岐
コミット SHA やリポジトリ名をログに出力
プルリクエストの情報を取得して自動コメント
アクターごとに異なる処理を実行

2. `env` コンテキスト：ユーザー定義変数の管理

env コンテキストは、ワークフロー内で定義した環境変数にアクセスするためのコンテキストです。

環境変数の定義スコープ

環境変数は 3 つのレベルで定義できます。

#	スコープ	定義場所	アクセス方法
1	ワークフローレベル	`env:` (トップレベル)	すべてのジョブ・ステップ
2	ジョブレベル	`jobs.<job_id>.env`	そのジョブ内のステップ
3	ステップレベル	`steps.<step_id>.env`	そのステップ内のみ

使用例：スコープ別の定義

yamlname: Env Example

# ワークフローレベル
env:
  GLOBAL_VAR: '全ジョブで利用可能'

jobs:
  build:
    runs-on: ubuntu-latest
    # ジョブレベル
    env:
      JOB_VAR: 'このジョブ内で利用可能'

    steps:
      - name: 変数を出力
        # ステップレベル
        env:
          STEP_VAR: 'このステップのみ'
        run: |
          echo "グローバル: ${{ env.GLOBAL_VAR }}"
          echo "ジョブ: ${{ env.JOB_VAR }}"
          echo "ステップ: ${{ env.STEP_VAR }}"

スコープを適切に使い分けることで、変数の管理がシンプルになります。

動的な環境変数の設定

ステップの実行結果を環境変数として保存することもできます。

yamlsteps:
  - name: 環境変数を動的に設定
    run: echo "BUILD_TIME=$(date +%Y%m%d_%H%M%S)" >> $GITHUB_ENV

  - name: 設定した変数を使用
    run: echo "ビルド時刻: ${{ env.BUILD_TIME }}"

$GITHUB_ENV に書き込むことで、後続のステップで env コンテキスト経由でアクセスできるようになるのです。

env コンテキストの使いどころ

アプリケーションの設定値（API エンドポイント、環境名など）
ビルド設定やバージョン情報
ステップ間で共有する値
機密情報ではない変数全般

3. `runner` コンテキスト：実行環境の情報

runner コンテキストは、ワークフローが実行されているランナー（実行環境）の情報にアクセスするためのコンテキストです。

主なプロパティ

#	プロパティ	説明	例
1	`runner.os`	OS の種類	`Linux`, `Windows`, `macOS`
2	`runner.arch`	CPU アーキテクチャ	`X64`, `ARM64`
3	`runner.temp`	一時ディレクトリのパス	`/tmp`
4	`runner.tool_cache`	ツールキャッシュのパス	`/opt/hostedtoolcache`
5	`runner.workspace`	ワークスペースのパス	`/home/runner/work/repo`

使用例：OS ごとに異なるコマンドを実行

yamljobs:
  build:
    strategy:
      matrix:
        os: [ubuntu-latest, windows-latest, macos-latest]
    runs-on: ${{ matrix.os }}

    steps:
      - name: OS 情報を表示
        run: echo "実行 OS: ${{ runner.os }}"

      - name: OS 別のコマンド実行
        run: |
          if [ "${{ runner.os }}" == "Linux" ]; then
            echo "Linux 用の処理"
          elif [ "${{ runner.os }}" == "macOS" ]; then
            echo "macOS 用の処理"
          else
            echo "Windows 用の処理"
          fi
        shell: bash

runner.os を使うことで、クロスプラットフォーム対応のワークフローを簡単に書けます。

一時ファイルの保存

yamlsteps:
  - name: 一時ファイルを作成
    run: |
      echo "テストデータ" > ${{ runner.temp }}/test.txt
      cat ${{ runner.temp }}/test.txt

runner.temp を使えば、OS に依存しない一時ディレクトリのパスを取得できるのです。

runner コンテキストの使いどころ

OS やアーキテクチャによる条件分岐
一時ファイルやキャッシュの保存先指定
クロスプラットフォームビルドの実装
ランナー環境のデバッグ情報取得

4. `secrets` コンテキスト：機密情報の安全な管理

secrets コンテキストは、GitHub に登録した機密情報（シークレット）にアクセスするためのコンテキストです。

シークレットの登録方法

シークレットは以下の場所で登録できます。

#	レベル	登録場所	用途
1	リポジトリ	Settings → Secrets and variables → Actions	そのリポジトリ専用
2	Organization	Organization Settings → Secrets	組織内の複数リポジトリで共有
3	環境	Settings → Environments → Secrets	特定の環境（production など）専用

使用例：API キーを使った認証

yamljobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: API にリクエスト
        env:
          API_KEY: ${{ secrets.MY_API_KEY }}
        run: |
          curl -H "Authorization: Bearer $API_KEY" \
            https://api.example.com/deploy

シークレットは環境変数として展開することで、スクリプト内で安全に使用できます。

シークレットの注意点

シークレットには重要な制約があります。

ログに出力されない: シークレットの値は自動的にマスクされる
条件式では使えない: if: secrets.MY_SECRET == 'value' は動作しない
フォークからはアクセス不可: フォーク元のシークレットは読み取れない

シークレットとマスキング

yamlsteps:
  - name: シークレットのテスト
    run: |
      echo "シークレット: ${{ secrets.MY_SECRET }}"
      # ログには "シークレット: ***" と表示される

GitHub Actions は自動的にシークレットをマスクしてくれるため、誤って公開されるリスクが低減されるのです。

secrets コンテキストの使いどころ

API キーやトークンの管理
デプロイ先の認証情報
データベース接続文字列
サードパーティサービスの認証情報

コンテキスト間の連携パターン

実際のワークフローでは、複数のコンテキストを組み合わせて使用します。

mermaidflowchart LR
  github["github<br/>イベント判定"]
  secrets["secrets<br/>認証情報取得"]
  env["env<br/>変数展開"]
  runner["runner<br/>パス解決"]

  github -->|条件に応じて| secrets
  secrets -->|機密情報を| env
  env -->|変数を使って| runner
  runner -->|環境に応じた<br/>処理実行| result["ステップ実行"]

図で理解できる要点:

github で条件判定 → secrets で認証 → env で変数管理 → runner で環境対応という流れが一般的
各コンテキストは独立しているが、実際には連携して動作する

統合例：本番デプロイワークフロー

yamlname: Production Deploy

on:
  push:
    branches:
      - main

env:
  DEPLOY_ENV: production
  APP_NAME: my-application

jobs:
  deploy:
    runs-on: ubuntu-latest
    # main ブランチへの push のみ実行
    if: github.ref == 'refs/heads/main'

    steps:
      - name: チェックアウト
        uses: actions/checkout@v4

      - name: デプロイ情報を表示
        run: |
          echo "環境: ${{ env.DEPLOY_ENV }}"
          echo "アプリ名: ${{ env.APP_NAME }}"
          echo "実行 OS: ${{ runner.os }}"
          echo "コミット: ${{ github.sha }}"

      - name: 本番環境へデプロイ
        env:
          DEPLOY_TOKEN: ${{ secrets.PRODUCTION_DEPLOY_TOKEN }}
          DEPLOY_URL: https://api.example.com/deploy
        run: |
          curl -X POST "$DEPLOY_URL" \
            -H "Authorization: Bearer $DEPLOY_TOKEN" \
            -H "Content-Type: application/json" \
            -d '{
              "app": "${{ env.APP_NAME }}",
              "env": "${{ env.DEPLOY_ENV }}",
              "commit": "${{ github.sha }}",
              "actor": "${{ github.actor }}"
            }'

この例では、4 つのコンテキストすべてを活用しています。

github: ブランチ判定とコミット情報
env: アプリケーション設定
runner: 実行環境情報
secrets: デプロイトークン

具体例

ケース 1：マルチ環境デプロイ

開発環境、ステージング環境、本番環境へのデプロイを分岐させるワークフローを作成します。

yamlname: Multi Environment Deploy

on:
  push:
    branches:
      - develop
      - staging
      - main

env:
  APP_NAME: my-service

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - name: 環境判定
        id: env
        run: |
          if [[ "${{ github.ref }}" == "refs/heads/main" ]]; then
            echo "ENV_NAME=production" >> $GITHUB_ENV
            echo "API_URL=https://api.prod.example.com" >> $GITHUB_ENV
          elif [[ "${{ github.ref }}" == "refs/heads/staging" ]]; then
            echo "ENV_NAME=staging" >> $GITHUB_ENV
            echo "API_URL=https://api.stg.example.com" >> $GITHUB_ENV
          else
            echo "ENV_NAME=development" >> $GITHUB_ENV
            echo "API_URL=https://api.dev.example.com" >> $GITHUB_ENV
          fi

このステップでは、github.ref で現在のブランチを判定し、$GITHUB_ENV で環境変数を設定しています。

yaml- name: デプロイ実行
  env:
    DEPLOY_TOKEN: ${{ secrets.DEPLOY_TOKEN }}
  run: |
    echo "環境: ${{ env.ENV_NAME }}"
    echo "URL: ${{ env.API_URL }}"
    curl -X POST "${{ env.API_URL }}/deploy" \
      -H "Authorization: Bearer $DEPLOY_TOKEN" \
      -d "app=${{ env.APP_NAME }}&env=${{ env.ENV_NAME }}"

設定した環境変数は、後続のステップで env コンテキスト経由でアクセスできます。

ポイント:

github.ref で分岐判定
$GITHUB_ENV で動的に環境変数を設定
env コンテキストで変数を参照
secrets コンテキストで認証

ケース 2：クロスプラットフォームビルド

Windows、macOS、Linux でバイナリをビルドし、OS ごとに異なる処理を行います。

yamlname: Cross Platform Build

on:
  push:
    tags:
      - 'v*'

jobs:
  build:
    strategy:
      matrix:
        include:
          - os: ubuntu-latest
            target: x86_64-unknown-linux-gnu
          - os: macos-latest
            target: x86_64-apple-darwin
          - os: windows-latest
            target: x86_64-pc-windows-msvc

    runs-on: ${{ matrix.os }}

マトリックスビルドで複数の OS に対応します。

yamlsteps:
  - name: チェックアウト
    uses: actions/checkout@v4

  - name: ビルド環境情報
    run: |
      echo "OS: ${{ runner.os }}"
      echo "アーキテクチャ: ${{ runner.arch }}"
      echo "ターゲット: ${{ matrix.target }}"

  - name: ビルド実行
    env:
      BUILD_TARGET: ${{ matrix.target }}
    run: |
      if [ "${{ runner.os }}" == "Windows" ]; then
        echo "Windows ビルド"
        cargo build --release --target ${{ matrix.target }}
      else
        echo "Unix 系ビルド"
        cargo build --release --target ${{ matrix.target }}
      fi
    shell: bash

runner.os を使って、OS ごとに異なるビルドコマンドを実行しています。

yaml- name: アーティファクトをアップロード
  uses: actions/upload-artifact@v4
  with:
    name: binary-${{ runner.os }}
    path: |
      target/${{ matrix.target }}/release/my-app*

runner.os をアーティファクト名に含めることで、OS ごとのバイナリを識別できます。

ポイント:

runner.os で OS 判定
runner.arch でアーキテクチャ確認
マトリックス変数との組み合わせ
クロスプラットフォーム対応のシェル指定

ケース 3：プルリクエスト自動コメント

プルリクエストにビルド結果やテストカバレッジを自動コメントします。

yamlname: PR Comment

on:
  pull_request:
    types: [opened, synchronize]

jobs:
  test:
    runs-on: ubuntu-latest
    permissions:
      pull-requests: write

    steps:
      - name: チェックアウト
        uses: actions/checkout@v4

      - name: テスト実行
        id: test
        run: |
          npm test -- --coverage
          echo "COVERAGE=85%" >> $GITHUB_ENV

テスト実行後、カバレッジ情報を環境変数に保存します。

yaml- name: PR にコメント
  uses: actions/github-script@v7
  with:
    github-token: ${{ secrets.GITHUB_TOKEN }}
    script: |
      const prNumber = ${{ github.event.pull_request.number }};
      const coverage = "${{ env.COVERAGE }}";
      const comment = `## テスト結果

      ✅ テストが完了しました

      - カバレッジ: ${coverage}
      - コミット: \`${{ github.sha }}\`
      - 実行者: @${{ github.actor }}
      `;

      await github.rest.issues.createComment({
        owner: context.repo.owner,
        repo: context.repo.repo,
        issue_number: prNumber,
        body: comment
      });

github.event.pull_request でプルリクエストの情報を取得し、secrets.GITHUB_TOKEN で GitHub API にアクセスしています。

ポイント:

github.event.pull_request.number で PR 番号を取得
secrets.GITHUB_TOKEN で GitHub API 認証
env コンテキストで動的データを渡す
github.actor と github.sha で詳細情報を表示

ケース 4：条件付きジョブ実行

ファイル変更やラベルに応じて、特定のジョブのみを実行します。

yamlname: Conditional Jobs

on:
  pull_request:
    paths:
      - 'src/**'
      - 'tests/**'

env:
  NODE_VERSION: '20'

jobs:
  check-labels:
    runs-on: ubuntu-latest
    outputs:
      run-e2e: ${{ steps.check.outputs.run-e2e }}
    steps:
      - name: ラベルチェック
        id: check
        run: |
          if [[ "${{ contains(github.event.pull_request.labels.*.name, 'e2e-test') }}" == "true" ]]; then
            echo "run-e2e=true" >> $GITHUB_OUTPUT
          else
            echo "run-e2e=false" >> $GITHUB_OUTPUT
          fi

プルリクエストのラベルをチェックし、出力変数を設定しています。

yamlunit-test:
  runs-on: ubuntu-latest
  steps:
    - name: チェックアウト
      uses: actions/checkout@v4

    - name: Node.js セットアップ
      uses: actions/setup-node@v4
      with:
        node-version: ${{ env.NODE_VERSION }}

    - name: ユニットテスト
      run: npm test

e2e-test:
  needs: check-labels
  # e2e-test ラベルがある場合のみ実行
  if: needs.check-labels.outputs.run-e2e == 'true'
  runs-on: ubuntu-latest
  steps:
    - name: チェックアウト
      uses: actions/checkout@v4

    - name: Node.js セットアップ
      uses: actions/setup-node@v4
      with:
        node-version: ${{ env.NODE_VERSION }}

    - name: E2E テスト
      env:
        E2E_API_KEY: ${{ secrets.E2E_API_KEY }}
      run: npm run test:e2e

if 条件で前のジョブの出力を参照し、条件付きで E2E テストを実行しています。

ポイント:

github.event.pull_request.labels でラベル情報を取得
ジョブ間で出力変数を受け渡し
if 条件でジョブの実行を制御
secrets コンテキストで E2E テスト用の認証情報を管理

コンテキスト使い分けまとめ表

実際の開発で迷わないよう、使い分けの基準を表にまとめました。

#	コンテキスト	使うべき場面	使うべきでない場面
1	`github`	イベント情報、ブランチ判定、PR 情報	アプリケーション設定、機密情報
2	`env`	アプリケーション設定、ビルド設定	機密情報、実行環境情報
3	`runner`	OS 判定、パス解決、環境デバッグ	イベント情報、機密情報
4	`secrets`	API キー、トークン、パスワード	非機密の設定値、条件判定