{"meta":{"title":"変数リファレンス","intro":"GitHub Actions ワークフローでサポートされている変数、名前付け規則、制限、コンテキストについて説明します。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/ja/enterprise-cloud@latest/actions/reference","title":"リファレンス"},{"href":"/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions","title":"ワークフローとアクション"},{"href":"/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/variables","title":"変数"}],"documentType":"article"},"body":"# 変数リファレンス\n\nGitHub Actions ワークフローでサポートされている変数、名前付け規則、制限、コンテキストについて説明します。\n\nこの記事では、サポートされている変数のうち、環境変数、構成変数、GitHub Actions に用意されている既定の変数など、GitHub ワークフローで使用できるものを一覧で紹介します。 ワークフローを構成する際には、このリファレンスを参考にして、変数名、名前付け規則、制限、サポートされているコンテキストを検索してください。\n\n変数の詳細については、「[変数](/ja/enterprise-cloud@latest/actions/concepts/workflows-and-actions/variables)」を参照してください。\n\n## 既定の環境変数\n\nGitHub が設定する既定の環境変数は、ワークフローのどのステップでも使用できます。\n\n既定の環境変数は GitHub によって設定され、ワークフローで定義されていないため、`env` コンテキストを介してアクセスすることはできません。 しかし、既定の変数のほとんどは、対応する、似た名前のコンテキスト プロパティを持ちます。 たとえば、`GITHUB_REF` コンテキスト プロパティを使用してワークフロー処理中に `$` 変数の値を読み取ることができます。\n\n`GITHUB_*` および `RUNNER_*` という名前の既定の環境変数の値を上書きすることはできません。 現時点では、`CI` 変数の値を上書きできます。 ただし、これが常に可能になることは保証されていません。環境変数の設定の詳細については、「[変数に情報を格納する](/ja/enterprise-cloud@latest/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/store-information-in-variables#defining-environment-variables-for-a-single-workflow)」と「[GitHub Actions のワークフロー コマンド](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable)」を参照してください。\n\nアクションでは、ファイルシステムにアクセスするとき、ハードコードされたファイル パスを使うのではなく変数を使用することを強くお勧めします。 GitHub は、すべてのランナー環境でアクションが使用する変数を設定します。\n\n| 変数 | 説明 |\n| --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |\n| `CI` | 常に `true` に設定します。 |\n| `GITHUB_ACTION` | 現在実行中のアクションの名前、またはステップの [`id`](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsid)。 たとえば、アクションの場合は `__repo-owner_name-of-action-repo`。
GitHub では特殊文字を削除し、現在のステップで `__run` なしでスクリプトを実行するときに `id` という名前を使用します。 同じジョブで同じスクリプトまたはアクションを複数回使用する場合、名前には、アンダースコアとシーケンス番号から成るサフィックスが含まれます。 たとえば、実行する最初のスクリプトの名前は `__run` で、2 番目のスクリプトの名前は `__run_2` となります。 同様に、`actions/checkout` の 2 番目の呼び出しは `actionscheckout2` になります。 |\n| `GITHUB_ACTION_PATH` | アクションが置かれているパス。 このプロパティは、複合アクションでのみサポートされます。 このパスを使用して、処置が存在する場所にディレクトリを移動し、同じリポジトリ内のその他のファイルにアクセスすることができます。 たとえば、`/home/runner/work/_actions/repo-owner/name-of-action-repo/v1` のようにします。 |\n| `GITHUB_ACTION_REPOSITORY` | アクションを実行するステップの場合、これはアクションの所有者とリポジトリの名前です。 たとえば、`actions/checkout` のようにします。 |\n| `GITHUB_ACTIONS` | GitHub Actions がワークフローを実行しているときは常に `true` に設定されます。 この変数は、テストがローカルで実行されているときと、GitHub Actionsによって実行されているときを区別するために利用できます。 |\n| `GITHUB_ACTOR` | ワークフローを開始するユーザまたはアプリの名前。 たとえば、`octocat` のようにします。 |\n| `GITHUB_ACTOR_ID` | 最初のワークフロー実行をトリガーしたユーザーまたはアプリのアカウント ID。 たとえば、`1234567` のようにします。 これはアクターのユーザー名とは異なることに注意してください。 |\n| `GITHUB_API_URL` | API URL を返します。 (例: `https://api.github.com`)。 |\n| `GITHUB_BASE_REF` | ワークフローの実行における base ref の名前または pull request のターゲット ブランチ。 これは、ワークフローの実行をトリガーするイベントが `pull_request` か `pull_request_target` である場合にのみ設定されます。 たとえば、`main` のようにします。 |\n| `GITHUB_ENV` | ワークフロー コマンドから変数を設定するファイルへのランナーのパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、`/home/runner/work/_temp/_runner_file_commands/set_env_87406d6e-4979-4d42-98e1-3dab1f48b13a` のようにします。 詳しくは、「[GitHub Actions のワークフロー コマンド](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#setting-an-environment-variable)」をご覧ください。 |\n| `GITHUB_EVENT_NAME` | ワークフローをトリガーしたイベントの名前。 たとえば、`workflow_dispatch` のようにします。 |\n| `GITHUB_EVENT_PATH` | 完全なイベント Webhook ペイロードを含むランナー上のファイルへのパス。 たとえば、`/github/workflow/event.json` のようにします。 |\n| `GITHUB_GRAPHQL_URL` | グラフ QL API の URL を返します。 (例: `https://api.github.com/graphql`)。 |\n| `GITHUB_HEAD_REF` | ワークフローの実行における head ref または pull request のソース ブランチ。 このプロパティは、ワークフローの実行をトリガーするイベントが `pull_request` か `pull_request_target` である場合にのみ設定されます。 たとえば、`feature-branch-1` のようにします。 |\n| `GITHUB_JOB` | 現在のジョブの [job\\_id](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_id)。 たとえば、`greeting_job` のようにします。 |\n| `GITHUB_OUTPUT` | ワークフロー コマンドからの現在のステップの出力を設定するファイルへのランナー上のパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、`/home/runner/work/_temp/_runner_file_commands/set_output_a50ef383-b063-46d9-9157-57953fc9f3f0` のようにします。 詳しくは、「[GitHub Actions のワークフロー コマンド](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#setting-an-output-parameter)」をご覧ください。 |\n| `GITHUB_PATH` | ワークフロー コマンドから `PATH` システム変数を設定するファイルへのランナーのパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、`/home/runner/work/_temp/_runner_file_commands/add_path_899b9445-ad4a-400c-aa89-249f18632cf5` のようにします。 詳しくは、「[GitHub Actions のワークフロー コマンド](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#adding-a-system-path)」をご覧ください。 |\n| `GITHUB_REF` | ワークフローの実行をトリガーしたブランチまたはタグの完全な形式のリファレンス。 |\n| `push` によってトリガーされるワークフローの場合、これはプッシュされたブランチまたはタグの参照です。 マージされなかった `pull_request` によってトリガーされるワークフローの場合、これは pull request マージ ブランチです。 もしpull requestがマージされた場合、その統合先のブランチはこれです。 | |\n| `release` によってトリガーされるワークフローの場合、これは作成されたリリース タグです。 その他のトリガーの場合、これはワークフロー実行をトリガーしたブランチまたはタグの参照です。 これは、イベントの種類に対してブランチまたはタグを使用できる場合にのみ設定されます。 このリファレンスは完全な形に整えられています。つまり、ブランチの場合の形式は`refs/heads/`となります。 マージされなかった `pull_request_target` を除く pull request イベントの場合は、 `refs/pull//merge`。 | |\n| `pull_request_target` イベントにはベース ブランチの `ref` があります。 タグの場合は `refs/tags/` です。 たとえば、 `refs/heads/feature-branch-1` です。 プルリクエストのマージブランチの詳細については、[pull requests について](/ja/enterprise-cloud@latest/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-pull-requests#pull-request-refs-and-merge-branches) を参照してください。 | |\n| `GITHUB_REF_NAME` | ワークフローの実行をトリガーしたブランチまたはタグの短い参照名。 この値は、GitHub に表示されるブランチまたはタグ名と一致します。 たとえば、`feature-branch-1` のようにします。
マージされなかったプル要求の場合、形式は `/merge`。 |\n| `GITHUB_REF_PROTECTED` | `true` 分岐保護または[ルールセット](/ja/enterprise-cloud@latest/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/managing-rulesets-for-a-repository)が、ワークフロー実行をトリガーした ref に対して構成されている場合。 |\n| `GITHUB_REF_TYPE` | ワークフローの実行をトリガーした ref の種類。 有効な値は `branch` または `tag`です。 |\n| `GITHUB_REPOSITORY` | 所有者およびリポジトリの名前。 たとえば、`octocat/Hello-World` のようにします。 |\n| `GITHUB_REPOSITORY_ID` | リポジトリの ID。 たとえば、「 `123456789` 」のように入力します。 これはリポジトリ名とは異なることに注意してください。 |\n| `GITHUB_REPOSITORY_OWNER` | リポジトリ所有者の名前。 たとえば、`octocat` のようにします。 |\n| `GITHUB_REPOSITORY_OWNER_ID` | リポジトリ所有者のアカウント ID。 たとえば、「 `1234567` 」のように入力します。 これは所有者名とは異なることに注意してください。 |\n| `GITHUB_RETENTION_DAYS` | ワークフロー実行ログと成果物が保持される日数。 たとえば、`90` のようにします。 |\n| `GITHUB_RUN_ATTEMPT` | リポジトリ内で実行される特定のワークフローの各試行に割り振られる一意の番号。 この番号は、ワークフロー実行の最初の試行時に 1 で始まり、再実行ごとに増加します。 たとえば、`3` のようにします。 |\n| `GITHUB_RUN_ID` | 各ワークフローの一意の番号は、リポジトリ内で実行されます。 この番号は、ワークフローの実行をやり直しても変化しません、 例えば、`1658821493`。 |\n| `GITHUB_RUN_NUMBER` | リポジトリ内の特定のワークフローの各実行に対するユニークな番号。 この番号は、ワークフローの最初の実行時に 1 から始まり、新しい実行ごとに増加します。 この番号は、ワークフローの実行をやり直しても変化しません、 たとえば、`3`。 |\n| `GITHUB_SERVER_URL` | GitHub サーバーの URL。 (例: `https://github.com`)。 |\n| `GITHUB_SHA` | ワークフローをトリガーしたコミット SHA。 このコミット SHA の値は、ワークフローをトリガーしたイベントによって異なります。 詳しくは、「[ワークフローをトリガーするイベント](/ja/enterprise-cloud@latest/actions/using-workflows/events-that-trigger-workflows)」をご覧ください。 たとえば、 `ffac537e6cbbf934b08745a378932722df287a53` です。 |\n| `GITHUB_STEP_SUMMARY` | ワークフロー コマンドからのジョブの概要を含むファイルへのランナー上のパス。 このファイルへのパスは現在のステップに固有であり、ジョブのステップごとに変更されます。 たとえば、`/home/runner/_layout/_work/_temp/_runner_file_commands/step_summary_1cb22d7f-5663-41a8-9ffc-13472605c76c` のようにします。 詳しくは、「[GitHub Actions のワークフロー コマンド](/ja/enterprise-cloud@latest/actions/using-workflows/workflow-commands-for-github-actions#adding-a-job-summary)」をご覧ください。 |\n| `GITHUB_TRIGGERING_ACTOR` | ワークフローの実行を開始したユーザーのユーザー名。 ワークフローの実行が再実行である場合、この値は `github.actor` と異なることがあります。 ワークフローのすべての再実行では、再実行を開始したアクター (`github.triggering_actor`) が異なる特権を持っている場合であっても、`github.actor` の特権が使われます。 |\n| `GITHUB_WORKFLOW` | ワークフローの名前です。 たとえば、`My test workflow` のようにします。 ワークフロー ファイルで `name` を指定していない場合、このプロパティの値は、リポジトリ内にあるワークフロー ファイルの完全なパスになります。 |\n| `GITHUB_WORKFLOW_REF` | ワークフローへの参照パス。 たとえば、「 `octocat/hello-world/.github/workflows/my-workflow.yml@refs/heads/my_branch` 」のように入力します。 |\n| `GITHUB_WORKFLOW_SHA` | ワークフロー ファイルのコミット SHA。 |\n| `GITHUB_WORKSPACE` | ステップのランナー上の既定の作業ディレクトリと、[`checkout`](https://github.com/actions/checkout) アクションを使用するときのリポジトリの既定の場所。 たとえば、`/home/runner/work/my-repo-name/my-repo-name` のようにします。 |\n| `RUNNER_ARCH` | ジョブを実行しているランナーのアーキテクチャ。 指定できる値は、`X86`、`X64`、`ARM`、および `ARM64` です。 |\n| `RUNNER_DEBUG` | これは、[デバッグ ログ](/ja/enterprise-cloud@latest/actions/how-tos/monitor-workflows/enable-debug-logging)が有効になっている場合にのみ設定され、値は常に `1` です。 独自のジョブ手順で追加のデバッグまたは詳細ログを有効にするためのインジケーターとして役に立ちます。 |\n| `RUNNER_ENVIRONMENT` | ジョブを実行しているランナーの環境。 使用可能な値は、GitHub によって提供される GitHub でホストされたランナーの場合は `github-hosted`、リポジトリのオーナーによって構成されたセルフホステッド ランナーの場合は `self-hosted` です。 |\n| `RUNNER_NAME` | ジョブを実行しているランナーの名前。 この名前は、リポジトリのランナーと組織レベルで同じ名前を使用できるため、ワークフロー実行で一意でない場合があります。 たとえば、`Hosted Agent` |\n| `RUNNER_OS` | ジョブを実行しているランナーのオペレーティングシステム。 設定可能な値は、`Linux`、`Windows`、または `macOS` です。 たとえば、`Windows` |\n| `RUNNER_TEMP` | ランナー上の一時ディレクトリへのパス。 このディレクトリは、各ジョブの開始及び終了時点で空になります。 ランナーのユーザアカウントが削除する権限を持っていない場合、ファイルは削除されないことに注意してください。 たとえば、`D:\\a\\_temp` |\n| `RUNNER_TOOL_CACHE` | GitHubホストランナー用のプレインストール済みツールを含むディレクトリへのパス。 詳しくは、「[GitHub ホステッド ランナー](/ja/enterprise-cloud@latest/actions/concepts/runners/github-hosted-runners#supported-software)」をご覧ください。 たとえば、`C:\\hostedtoolcache\\windows` |\n\n> \\[!NOTE]\n> ワークフローの実行の URL をジョブの中から使う必要がある場合は、次のように変数を組み合わせることができます: `$GITHUB_SERVER_URL/$GITHUB_REPOSITORY/actions/runs/$GITHUB_RUN_ID`\n\n## 構成変数の名前付け規則\n\n構成変数名には次の規則が適用されます。\n\n* 英数字 (`[a-z]`、`[A-Z]`、`[0-9]`) またはアンダースコア (`_`) のみを含めることができます。 スペースは使用できません。\n* `GITHUB_` プレフィックスで始めることはできません。\n* 最初を数字にすることはできません。\n* 参照されるとき、大文字と小文字が区別されません。 GitHub は、入力方法に関係なく、シークレット名を大文字として格納します。\n* 作成されたリポジトリ、organization、または Enterprise に固有のものにする必要があります。\n\n## 環境変数の命名規則\n\n環境変数を設定する場合、既定の環境変数名は使用できません。 既定の環境変数の完全な一覧については、以下の「[変数リファレンス](/ja/enterprise-cloud@latest/actions/reference/variables-reference#default-environment-variables)」を参照してください。 これらの既定の変数のいずれかの値をオーバーライドしようとすると、割り当ては無視されます。\n\n> \\[!NOTE]\n> ステップで `run: env` を使用して、ワークフロー ステップで使用できる環境変数のセット全体を一覧表示し、そのステップの出力を調べることができます。\n\n## 構成変数の優先順位\n\n複数のレベルで同じ名前の変数が存在する場合、最も低いレベルの変数が優先されます。 たとえば、organization レベルの変数名がリポジトリレベルの変数名と同じ場合、リポジトリレベルの変数が優先されます。 同様に、organization、リポジトリ、環境がすべて同じ名前の変数を持つ場合、環境レベルの変数が優先されます。\n\n> \\[!NOTE]\n> 環境変数は、ジョブの実行開始後にランナーでのみ使用できます。 つまり、環境レベルの変数は、 `env` および `vars` コンテキストの変数を上書きしません。\n\n再利用可能なワークフローの場合は、呼び出し元ワークフローのリポジトリの変数が使用されます。 呼び出されたワークフローを含むリポジトリの変数は、呼び出し元ワークフローでは使用できません。\n\n## 構成変数の制限\n\n個々の変数のサイズは最大 48 KB です。\n\n最大で 1,000 個の組織変数、リポジトリあたり 500 個の変数、および環境あたり 100 個の変数を格納できます。 組織変数とリポジトリ変数の合計サイズの上限は、ワークフローの実行あたり 256 KB です。\n\nリポジトリに作成されたワークフローは、次の数の変数にアクセスできます。\n\n* リポジトリ変数の合計サイズが 256 KB 未満の場合、リポジトリ変数は最大 500 個です。 リポジトリ変数の合計サイズが 256 KB を超える場合、(変数名でアルファベット順に並べ替えをして) 制限を超えないリポジトリ変数のみが使用できます。\n* リポジトリ変数と組織変数の合計サイズが 256 KB 未満の場合、組織変数は最大 1,000 個です。 組織変数とリポジトリ変数の合計サイズが 256 KB を超える場合は、(リポジトリ変数を処理した後、変数名でアルファベット順に並べ替えをして) その制限を超えない組織変数のみが使用できます。\n* 最大 100 個の環境レベル変数。\n\n> \\[!NOTE]\n> 環境レベル変数は、合計 256 KB のサイズ制限にはカウントされません。 リポジトリ変数と組織変数の合計サイズ制限を超えた場合でも、追加の変数が必要な場合は、環境を使い、その環境で追加の変数を定義できます。\n\n## サポートされているコンテキスト\n\nジョブがランナーに送信される前に処理されるワークフローの一部で、変数の値にアクセスするには、通常 `env` または `github` コンテキストを使用します。\n\n> \\[!WARNING]\n> `github` コンテキストをログに出力しないでください。 機密情報が含まれています。\n\n| Context | 使用事例 | 例 |\n| -------------------------------------------------------------------- | ----------------------------------- | - |\n| `env` | ワークフローで定義されているカスタム変数を参照します。 | |\n| `${{ env.MY_VARIABLE }}` | | |\n| `github` | ワークフローの実行とその実行をトリガーしたイベントの情報を参照します。 | |\n| `${{ github.repository }}` | | |"}