この記事では、サポートされている変数のうち、環境変数、構成変数、GitHub に用意されている既定の変数など、GitHub Actions ワークフローで使用できるものを一覧で紹介します。 ワークフローを構成する際には、このリファレンスを参考にして、変数名、名前付け規則、制限、サポートされているコンテキストを検索してください。

変数の詳細については、「変数」を参照してください。

既定の環境変数

GitHub が設定する既定の環境変数は、ワークフローのどのステップでも使用できます。

既定の環境変数は GitHub によって設定され、ワークフローで定義されていないため、env コンテキストを介してアクセスすることはできません。 しかし、既定の変数のほとんどは、対応する、似た名前のコンテキスト プロパティを持ちます。 たとえば、${{ github.ref }} コンテキスト プロパティを使用してワークフロー処理中に GITHUB_REF 変数の値を読み取ることができます。

GITHUB_* および RUNNER_* という名前の既定の環境変数の値を上書きすることはできません。 現時点では、CI 変数の値を上書きできます。 ただし、これが常に可能になることは保証されていません。環境変数の設定の詳細については、「変数に情報を格納する」と「GitHub Actions のワークフロー コマンド」を参照してください。

アクションでは、ファイルシステムにアクセスするとき、ハードコードされたファイル パスを使うのではなく変数を使用することを強くお勧めします。 GitHub は、すべてのランナー環境でアクションが使用する変数を設定します。

変数	説明
CI	常に true に設定します。
GITHUB_ACTION	現在実行中のアクションの名前、またはステップの id。 たとえば、アクションの場合は __repo-owner_name-of-action-repo。 GitHub では特殊文字を削除し、現在のステップで id なしでスクリプトを実行するときに __run という名前を使用します。 同じジョブで同じスクリプトまたはアクションを複数回使用する場合、名前には、アンダースコアとシーケンス番号から成るサフィックスが含まれます。 たとえば、実行する最初のスクリプトの名前は __run で、2 番目のスクリプトの名前は __run_2 となります。 同様に、actions/checkout の 2 番目の呼び出しは actionscheckout2 になります。
GITHUB_ACTION_PATH	アクションが置かれているパス。 このプロパティは、複合アクションでのみサポートされます。 このパスを使用して、処置が同じリポジトリにあり、その他ファイルにアクセスできるディレクトリを変更できます。 たとえば、/home/runner/work/_actions/repo-owner/name-of-action-repo/v1 のようにします。
GITHUB_ACTION_REPOSITORY	アクションを実行するステップの場合、これはアクションの所有者とリポジトリの名前です。 たとえば、actions/checkout のようにします。
GITHUB_ACTIONS	GitHub Actions がワークフローを実行しているときは常に true に設定されます。 この変数は、テストがローカルで実行されているときと、GitHub Actionsによって実行されているときを区別するために利用できます。
GITHUB_ACTOR	ワークフローを開始するユーザまたはアプリの名前。 たとえば、octocat のようにします。
GITHUB_ACTOR_ID	最初のワークフロー実行をトリガーしたユーザーまたはアプリのアカウント ID。 たとえば、1234567 のようにします。 これはアクターのユーザー名とは異なることに注意してください。
GITHUB_API_URL	API URL を返します。 (例: https://api.github.com)。
GITHUB_BASE_REF	ワークフローの実行における base ref の名前または pull request のターゲット ブランチ。 これは、ワークフローの実行をトリガーするイベントが pull_request か pull_request_target である場合にのみ設定されます。 たとえば、main のようにします。
GITHUB_ENV	ワークフロー コマンドから変数を設定するファイルへのランナーのパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、/home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a のようにします。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。
GITHUB_EVENT_NAME	ワークフローをトリガーしたイベントの名前。 たとえば、workflow_dispatch のようにします。
GITHUB_EVENT_PATH	完全なイベント Webhook ペイロードを含むランナー上のファイルへのパス。 たとえば、/github/workflow/event.json のようにします。
GITHUB_GRAPHQL_URL	グラフ QL API の URL を返します。 (例: https://api.github.com/graphql)。
GITHUB_HEAD_REF	ワークフローの実行における head ref または pull request のソース ブランチ。 このプロパティは、ワークフローの実行をトリガーするイベントが pull_request か pull_request_target である場合にのみ設定されます。 たとえば、feature-branch-1 のようにします。
GITHUB_JOB	現在のジョブの job_id。 たとえば、greeting_job のようにします。
GITHUB_OUTPUT	ワークフロー コマンドからの現在のステップの出力を設定するファイルへのランナー上のパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、/home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0 のようにします。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。
GITHUB_PATH	ワークフロー コマンドから PATH システム変数を設定するファイルへのランナーのパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、/home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5 のようにします。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。
GITHUB_REF	ワークフローの実行をトリガーしたブランチまたはタグの完全な形式の参照。 push によってトリガーされるワークフローの場合、これはプッシュされたブランチまたはタグの参照です。 pull_request によってトリガーされるワークフローの場合、これは pull request のマージ ブランチです。 release によってトリガーされるワークフローの場合、これは作成されたリリース タグです。 その他のトリガーの場合、これはワークフロー実行をトリガーしたブランチまたはタグの参照です。 これは、イベントの種類に対してブランチまたはタグを使用できる場合にのみ設定されます。 この参照は完全な形式です。つまり、ブランチの場合の形式は refs/heads/<branch_name> です。 pull_request_target 以外の pull request イベントの場合は refs/pull/<pr_number>/merge です。 pull_request_target イベントにはベース ブランチの ref があります。 タグの場合は refs/tags/<tag_name> です。 たとえば、 refs/heads/feature-branch-1 です。
GITHUB_REF_NAME	ワークフローの実行をトリガーしたブランチまたはタグの短い参照名。 この値は、GitHub に表示されるブランチまたはタグ名と一致します。 たとえば、feature-branch-1 のようにします。 pull request の場合、形式は <pr_number>/merge。
GITHUB_REF_PROTECTED	true 分岐保護またはルールセットが、ワークフロー実行をトリガーした ref に対して構成されている場合。
GITHUB_REF_TYPE	ワークフローの実行をトリガーした ref の種類。 有効な値は branch または tagです。
GITHUB_REPOSITORY	所有者およびリポジトリの名前。 たとえば、octocat/Hello-World のようにします。
GITHUB_REPOSITORY_ID	リポジトリの ID。 たとえば、「 123456789 」のように入力します。 これはリポジトリ名とは異なることに注意してください。
GITHUB_REPOSITORY_OWNER	リポジトリ所有者の名前。 たとえば、octocat のようにします。
GITHUB_REPOSITORY_OWNER_ID	リポジトリ所有者のアカウント ID。 たとえば、「 1234567 」のように入力します。 これは所有者名とは異なることに注意してください。
GITHUB_RETENTION_DAYS	ワークフロー実行ログと成果物が保持される日数。 たとえば、90 のようにします。
GITHUB_RUN_ATTEMPT	リポジトリ内で実行される特定のワークフローの各試行に割り振られる一意の番号。 この番号は、ワークフロー実行の最初の試行時に 1 で始まり、再実行ごとに増加します。 たとえば、3 のようにします。
GITHUB_RUN_ID	各ワークフローの一意の番号は、リポジトリ内で実行されます。 この番号は、ワークフローの実行をやり直しても変化しません、 たとえば、1658821493。
GITHUB_RUN_NUMBER	リポジトリ内の特定のワークフローの各実行に対するユニークな番号。 この番号は、ワークフローの最初の実行時に 1 から始まり、新しい実行ごとに増加します。 この番号は、ワークフローの実行をやり直しても変化しません、 たとえば、3。
GITHUB_SERVER_URL	GitHub サーバーの URL。 (例: https://github.com)。
GITHUB_SHA	ワークフローをトリガーしたコミット SHA。 このコミット SHA の値は、ワークフローをトリガーしたイベントによって異なります。 詳しくは、「ワークフローをトリガーするイベント」をご覧ください。 たとえば、 ffac537e6cbbf934b08745a378932722df287a53 です。
GITHUB_STEP_SUMMARY	ワークフロー コマンドからのジョブの概要を含むファイルへのランナー上のパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、/home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c のようにします。 詳しくは、「GitHub Actions のワークフロー コマンド」をご覧ください。
GITHUB_TRIGGERING_ACTOR	ワークフローの実行を開始したユーザーのユーザー名。 ワークフローの実行が再実行である場合、この値は github.actor と異なることがあります。 ワークフローのすべての再実行では、再実行を開始したアクター (github.triggering_actor) が異なる特権を持っている場合であっても、github.actor の特権が使われます。
GITHUB_WORKFLOW	ワークフローの名前です。 たとえば、My test workflow のようにします。 ワークフロー ファイルで name を指定していない場合、このプロパティの値は、リポジトリ内にあるワークフロー ファイルの完全なパスになります。
GITHUB_WORKFLOW_REF	ワークフローへの参照パス。 たとえば、「 octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch 」のように入力します。
GITHUB_WORKFLOW_SHA	ワークフロー ファイルのコミット SHA。
GITHUB_WORKSPACE	ステップのランナー上の既定の作業ディレクトリと、checkout アクションを使用するときのリポジトリの既定の場所。 たとえば、/home/runner/work/my-repo-name/my-repo-name のようにします。
RUNNER_ARCH	ジョブを実行しているランナーのアーキテクチャ。 指定できる値は、X86、X64、ARM、および ARM64 です。
RUNNER_DEBUG	これは、デバッグ ログが有効になっている場合にのみ設定され、値は常に 1 です。 独自のジョブ手順で追加のデバッグまたは詳細ログを有効にするためのインジケーターとして役に立ちます。
RUNNER_ENVIRONMENT	ジョブを実行しているランナーの環境。 使用可能な値は、GitHub によって提供される GitHub でホストされたランナーの場合は github-hosted、リポジトリのオーナーによって構成されたセルフホステッド ランナーの場合は self-hosted です。
RUNNER_NAME	ジョブを実行しているランナーの名前。 この名前は、リポジトリのランナーと組織レベルで同じ名前を使用できるため、ワークフロー実行で一意でない場合があります。 たとえば、Hosted Agent
RUNNER_OS	ジョブを実行しているランナーのオペレーティングシステム。 設定可能な値は、Linux、Windows、または macOS です。 たとえば、Windows
RUNNER_TEMP	ランナー上の一時ディレクトリへのパス。 このディレクトリは、各ジョブの開始及び終了時点で空になります。 ランナーのユーザアカウントが削除する権限を持っていない場合、ファイルは削除されないことに注意してください。 たとえば、D:\a\_temp
RUNNER_TOOL_CACHE	GitHubホストランナーにプレインストールされているツールを含むディレクトリへのパス。 詳しくは、「GitHub ホステッド ランナー」をご覧ください。 たとえば、C:\hostedtoolcache\windows

構成変数の名前付け規則

構成変数名には次の規則が適用されます。

• 英数字 ([a-z]、[A-Z]、[0-9]) またはアンダースコア (_) のみを含めることができます。 スペースは使用できません。
• GITHUB_ プレフィックスで始めることはできません。
• 最初を数字にすることはできません。
• 参照されるとき、大文字と小文字が区別されません。 GitHub は、入力方法に関係なく、シークレット名を大文字として格納します。
• 作成されたリポジトリ、organization、または Enterprise に固有のものにする必要があります。

環境変数の命名規則

環境変数を設定する場合、既定の環境変数名は使用できません。 既定の環境変数の完全な一覧については、以下の「変数リファレンス」を参照してください。 これらの既定の変数のいずれかの値をオーバーライドしようとすると、割り当ては無視されます。

構成変数の優先順位

複数のレベルで同じ名前の変数が存在する場合、最も低いレベルの変数が優先されます。 たとえば、organization レベルの変数名がリポジトリレベルの変数名と同じ場合、リポジトリレベルの変数が優先されます。 同様に、organization、リポジトリ、環境がすべて同じ名前の変数を持つ場合、環境レベルの変数が優先されます。

再利用可能なワークフローの場合は、呼び出し元ワークフローのリポジトリの変数が使用されます。 呼び出されたワークフローを含むリポジトリの変数は、呼び出し元ワークフローでは使用できません。

構成変数の制限

個々の変数のサイズは最大 48 KB です。

最大で 1,000 個の組織変数、リポジトリあたり 500 個の変数、および環境あたり 100 個の変数を格納できます。 組織変数とリポジトリ変数の合計サイズの上限は、ワークフローの実行あたり 256 KB です。

リポジトリに作成されたワークフローは、次の数の変数にアクセスできます。

• リポジトリ変数の合計サイズが 256 KB 未満の場合、リポジトリ変数は最大 500 個です。 リポジトリ変数の合計サイズが 256 KB を超える場合、(変数名でアルファベット順に並べ替えをして) 制限を超えないリポジトリ変数のみが使用できます。
• リポジトリ変数と組織変数の合計サイズが 256 KB 未満の場合、組織変数は最大 1,000 個です。 組織変数とリポジトリ変数の合計サイズが 256 KB を超える場合は、(リポジトリ変数を処理した後、変数名でアルファベット順に並べ替えをして) その制限を超えない組織変数のみが使用できます。
• 最大 100 個の環境レベル変数。

サポートされているコンテキスト

ジョブがランナーに送信される前に処理されるワークフローの一部で、変数の値にアクセスするには、通常 env または github コンテキストを使用します。

Context	使用事例	例
env	ワークフローで定義されているカスタム変数を参照します。	${{ env.MY_VARIABLE }}
github	ワークフローの実行とその実行をトリガーしたイベントの情報を参照します。	${{ github.repository }}