{"meta":{"title":"GitHub Actions　のワークフロー構文","intro":"ワークフローは、1 つ以上のジョブからなる設定可能な自動化プロセスです。 ワークフローの設定を定義するには、YAMLファイルを作成しなければなりません。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/reference","title":"リファレンス"},{"href":"/ja/actions/reference/workflows-and-actions","title":"ワークフローとアクション"},{"href":"/ja/actions/reference/workflows-and-actions/workflow-syntax","title":"ワークフロー構文"}],"documentType":"article"},"body":"# GitHub Actions　のワークフロー構文\n\nワークフローは、1 つ以上のジョブからなる設定可能な自動化プロセスです。 ワークフローの設定を定義するには、YAMLファイルを作成しなければなりません。\n\n## ワークフロー用のYAML構文について\n\nワークフロー ファイルでは YAML 構文が使用され、ファイル拡張子 `.yml` または `.yaml` が必要です。 YAML の初心者で詳しく学びたい場合は、「[Learn YAML in Y minutes](https://learnxinyminutes.com/docs/yaml/)」(YAML を Y 分で学ぶ) を参照してください。\n\nワークフロー ファイルは、リポジトリの `.github/workflows` ディレクトリに保存する必要があります。\n\n## `name`\n\nワークフローの名前です。 GitHub では、ワークフローの名前がリポジトリの \\[アクション] タブに表示されます。`name` を省略すると、GitHub は、リポジトリのルートに対して相対的なワークフロー ファイル パスを表示します。\n\n## `run-name`\n\nワークフローから生成されたワークフロー実行の名前。\nGitHub は、リポジトリの \\[アクション] タブにあるワークフロー実行の一覧にワークフロー実行名を表示します。 `run-name` を省略した場合、または空白のみである場合、実行名はワークフロー実行のイベント固有の情報に設定されます。 たとえば、`push` または `pull_request` イベントによってトリガーされるワークフローの場合、コミット メッセージまたは pull request のタイトルとして設定されます。\n\nこの値には式を含めることができ、[`github`](/ja/actions/learn-github-actions/contexts#github-context) および [`inputs`](/ja/actions/learn-github-actions/contexts#inputs-context) コンテキストを参照することもできます。\n\n###\n\n```\n          `run-name` の例\n```\n\n```yaml\nrun-name: Deploy to ${{ inputs.deploy_target }} by @${{ github.actor }}\n```\n\n## `on`\n\nワークフローを自動的にトリガーするには、`on` を使用してワークフローを実行する原因となるイベントを定義します。 使用できるイベントの一覧については、「[ワークフローをトリガーするイベント](/ja/actions/using-workflows/events-that-trigger-workflows)」を参照してください。\n\nワークフローをトリガーできる 1 つまたは複数のイベントを定義することも、時間スケジュールを設定することもできます。 また、特定のファイル、タグ、またはブランチの変更に対してのみワークフローが実行されるよう制限することもできます。 以降のセクションでは、これらのオプションについて説明します。\n\n### 単一のイベントを使用する\n\nたとえば、次の `on` の値を持つワークフローは、ワークフローのリポジトリ内の任意のブランチにプッシュが行われるときに実行されます。\n\n```yaml\non: push\n```\n\n### 複数のイベントを使用する\n\n1 つのイベントまたは複数のイベントを指定できます。 たとえば、次の `on` の値を持つワークフローは、ワークフローのリポジトリ内の任意のブランチにプッシュが行われるとき、または誰かがリポジトリをフォークしたときに実行されます。\n\n```yaml\non: [push, fork]\n```\n\n複数のイベントを指定する場合、ワークフローをトリガーするために必要なイベントは 1 つだけです。 ワークフローの複数のトリガー イベントが同時に発生した場合、複数のワークフロー実行がトリガーされます。\n\n### アクティビティの種類を使用する\n\n一部のイベントには、ワークフローを実行するタイミングをより細かく制御できるアクティビティの種類があります。 `on.<event_name>.types` を使用して、ワークフロー実行をトリガーするイベント アクティビティの種類を定義します。\n\nたとえば、`issue_comment` イベントには、`created`、`edited`、`deleted` のアクティビティの種類があります。 `label` イベントでワークフローがトリガーされる場合、ラベルが作成、編集、または削除されるたびにワークフローが実行されます。 `label` イベントに `created` アクティビティの種類を指定すると、ワークフローはラベルの作成時に実行されますが、ラベルの編集または削除時には実行されません。\n\n```yaml\non:\n  label:\n    types:\n      - created\n```\n\n複数のアクティビティの種類を指定した場合、ワークフローをトリガーするために発生する必要があるのは、それらのイベント アクティビティの種類のうちの 1 つだけです。 ワークフローの複数のトリガー イベント アクティビティの種類が同時に発生した場合、複数のワークフロー実行がトリガーされます。 たとえば、次のワークフローは、Issue がオープンされた場合またはラベル付けされた場合にトリガーされます。 2 つのラベルを持つ Issue がオープンされると、3 つのワークフロー実行 (1 つは Issue がオープンされたイベント用、2 つは Issue のラベルが付いたイベント用) が開始されます。\n\n```yaml\non:\n  issues:\n    types:\n      - opened\n      - labeled\n```\n\n各イベントとそのアクティビティの種類の詳細については、「[ワークフローをトリガーするイベント](/ja/actions/using-workflows/events-that-trigger-workflows)」を参照してください。\n\n### フィルターを使用する\n\n一部のイベントには、ワークフローを実行するタイミングをより細かく制御できるフィルターがあります。\n\nたとえば、`push` イベントの `branches` フィルターでは、プッシュが発生したときではなく、`branches` フィルターと同じブランチに対してプッシュが発生したときのみ、ワークフローを実行できます。\n\n```yaml\non:\n  push:\n    branches:\n      - main\n      - 'releases/**'\n```\n\n### アクティビティの種類とフィルターを複数のイベントと共に使用する\n\nイベントにアクティビティの種類やフィルターを指定し、ワークフローが複数のイベントでトリガーされる場合、各イベントを個別に構成する必要があります。 構成しないイベントも含め、すべてのイベントにはコロン (`:`) を追加する必要があります。\n\nたとえば、以下の `on` の値を持つワークフローは、次のような場合に実行されます。\n\n* ラベルが作成されたとき\n* リポジトリ内の `main` ブランチにプッシュされたとき\n* GitHub Pages 対応のブランチにプッシュされたとき\n\n```yaml\non:\n  label:\n    types:\n      - created\n  push:\n    branches:\n      - main\n  page_build:\n```\n\n## `on.<event_name>.types`\n\n`on.<event_name>.types` を使用して、ワークフロー実行をトリガーするアクティビティの種類を定義します。 ほとんどの GitHub イベントは、2 つ以上のアクティビティタイプからトリガーされます。 たとえば、`label` は、ラベルが `created`、`edited`、または `deleted`にトリガーされます。 `types` キーワードを使用すると、ワークフローを実行させるアクティビティの範囲を狭くすることができます。 Webhook イベントをトリガーするアクティビティの種類が 1 つのみの場合、`types` キーワードは不要です。\n\nイベント `types` の配列を使用できます。 各イベントとそのアクティビティの種類の詳細については、「[ワークフローをトリガーするイベント](/ja/actions/using-workflows/events-that-trigger-workflows#available-events)」を参照してください。\n\n```yaml\non:\n  label:\n    types: [created, edited]\n```\n\n## `on.<pull_request|pull_request_target>.<branches|branches-ignore>`\n\n`pull_request` イベントと `pull_request_target` イベントを使用する場合は、特定のブランチを対象とする pull request に対してのみ実行するようにワークフローを構成できます。\n\nブランチ名パターンを包含する場合、またはブランチ名パターンの包含と除外の両方を行う場合は、`branches` フィルターを使用します。 ブランチ名パターンの除外のみを行う場合は、`branches-ignore` フィルターを使用します。 `branches` と `branches-ignore` のフィルターの両方をワークフロー内の同じイベントで使うことはできません。\n\n`branches`/`branches-ignore` と [`paths`/`paths-ignore`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) の両方を定義すると、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。\n\n`branches` と `branches-ignore` のキーワードは、複数のブランチ名に一致する文字 (`*`、`**`、`+`、`?`、`!` など) を使用する glob パターンを受け入れます。 名前にこれらの文字のいずれかが含まれており、リテラルの一致が必要な場合は、`\\` でこれらの各特殊文字をエスケープする必要があります。 glob パターンの詳細については、[GitHub Actions　のワークフロー構文](/ja/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet) を参照してください。\n\n### 例: ブランチの包含\n\n`branches` で定義されているパターンは、Git ref の名前に対して評価されます。 たとえば、次のワークフローは、pull request の対象となる `pull_request` イベントが発生するたびに実行されます。\n\n* `main` という名前のブランチ (`refs/heads/main`)\n* `mona/octocat` という名前のブランチ (`refs/heads/mona/octocat`)\n* `releases/10` のように名前が `releases/` で始まるブランチ (`refs/heads/releases/10`)\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n```\n\nブランチ フィルター、[パス フィルター](/ja/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore)、または [コミット メッセージ](/ja/actions/managing-workflow-runs/skipping-workflow-runs)のためにワークフローがスキップされる場合、そのワークフローに関連付けられているチェックは \"保留中\" 状態のままになります。 これらのチェックを成功させる必要がある pull request は、マージが禁止されます。\n\n### 例: ブランチの除外\n\nパターンが `branches-ignore` パターンと一致する場合、ワークフローは実行されません。\n`branches-ignore` で定義されているパターンは、Git ref の名前に対して評価されます。 たとえば、次のワークフローは、pull request の対象とならない限り、`pull_request` イベントが発生するたびに実行されます。\n\n* `mona/octocat` という名前のブランチ (`refs/heads/mona/octocat`)\n* 名前が `releases/**-alpha` のように `releases/beta/3-alpha` と一致する ブランチ (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n```\n\n### 例: パスの包含および除外\n\n1 つのワークフローで同じイベントのフィルター処理をするために `branches` と `branches-ignore` を使用することはできません。 1 つのイベントに対して分岐パターンの適用と除外の両方を行う場合は、`branches` フィルターと `!` 文字を使用して、除外する分岐を指定します。\n\n```\n          `!` 文字を含むブランチを定義する場合は、`!` 文字を含まないブランチも 1 つ以上定義する必要があります。 ブランチの除外のみを行いたい場合は、代わりに `branches-ignore` を使用します。\n```\n\nパターンを定義する順序により、結果に違いが生じます。\n\n* 肯定のマッチング パターンの後に否定のマッチング パターン (`!` のプレフィックスが付く) を定義すると、Git ref が除外されます。\n* 否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、Git ref を再び含めます。\n\n次のワークフローは、否定のパターン `pull_request` が肯定のパターンの後に続くため、`releases/10` または `releases/beta/mona` を対象とする pull request の `releases/10-alpha` イベントで実行されますが、`releases/beta/3-alpha` または `!releases/**-alpha` を対象とする pull request では実行されません。 <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  pull_request:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## `on.push.<branches|tags|branches-ignore|tags-ignore>`\n\n`push` イベントを使用する場合は、特定のブランチまたはタグで実行するワークフローを構成できます。\n\nブランチ名パターンを含める場合、またはブランチ名パターンを含める/除外の両方を行う場合は、`branches` フィルターを使用します。 ブランチ名パターンの除外のみを行う場合は、`branches-ignore` フィルターを使用します。 `branches` と `branches-ignore` のフィルターの両方をワークフロー内の同じイベントで使うことはできません。\n\nタグ名パターンを含める場合、またはタグ名パターンを含める/除外の両方を行う場合は、`tags` フィルターを使用します。 タグ名パターンの除外のみを行う場合は、`tags-ignore` フィルターを使用します。 `tags` と `tags-ignore` のフィルターの両方をワークフロー内の同じイベントで使うことはできません。\n\n`tags`/`tags-ignore` のみ、または `branches`/`branches-ignore` のみを定義した場合、定義されていない Git ref に影響を与えるイベントに対してワークフローは実行されません。`tags`/`tags-ignore` も `branches`/`branches-ignore` も定義していない場合、ワークフローはブランチまたはタグに影響を与えるイベントに対して実行されます。 `branches`/`branches-ignore` と [`paths`/`paths-ignore`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#onpushpull_requestpull_request_targetpathspaths-ignore) の両方を定義すると、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。\n\n`branches`、`branches-ignore`、`tags`、および `tags-ignore` のキーワードは、複数のブランチまたはタグ名に一致する文字 (`*`、`**`、`+`、`?`、`!` など) を使用する glob パターンを許容します。 名前にこれらの文字のいずれかが含まれており、リテラルの一致が必要な場合は、`\\` でこれらの各特殊文字を\\_エスケープ\\_する必要があります。 glob パターンの詳細については、[GitHub Actions　のワークフロー構文](/ja/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet) を参照してください。\n\n### ブランチとタグを含める例\n\n`branches` と `tags` で定義されているパターンは、Git ref の名前に対して評価されます。 たとえば、次のワークフローは、`push` イベントが発生するたびに実行されます。\n\n* `main` という名前のブランチ (`refs/heads/main`)\n* `mona/octocat` という名前のブランチ (`refs/heads/mona/octocat`)\n* `releases/10` のように名前が `releases/` で始まるブランチ (`refs/heads/releases/10`)\n* `v2` という名前のタグ (`refs/tags/v2`)\n* `v1.9.1` のように名前が `v1.` で始まるタグ (`refs/tags/v1.9.1`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches:\n      - main\n      - 'mona/octocat'\n      - 'releases/**'\n    # Sequence of patterns matched against refs/tags\n    tags:\n      - v2\n      - v1.*\n```\n\n### ブランチやタグを除外する例\n\nパターンが `branches-ignore` または `tags-ignore` パターンと一致する場合、ワークフローは実行されません。\n`branches` と `tags` で定義されているパターンは、Git ref の名前に対して評価されます。 たとえば、次のワークフローは、`push` イベントがない限り、`push` イベントが発生するたびに実行されます。\n\n* `mona/octocat` という名前のブランチ (`refs/heads/mona/octocat`)\n* `releases/**-alpha` のように名前が `releases/beta/3-alpha` と一致する ブランチ (`refs/heads/releases/beta/3-alpha`) <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n* `v2` という名前のタグ (`refs/tags/v2`)\n* `v1.` のように名前が `v1.9` で始まるタグ (`refs/tags/v1.9`)\n\n```yaml\non:\n  push:\n    # Sequence of patterns matched against refs/heads\n    branches-ignore:\n      - 'mona/octocat'\n      - 'releases/**-alpha'\n    # Sequence of patterns matched against refs/tags\n    tags-ignore:\n      - v2\n      - v1.*\n```\n\n### ブランチやタグを含めたり除外したりする例\n\n1 つのワークフローで同じイベントをフィルターするために `branches` と `branches-ignore` を使用することはできません。 同様に、1 つのワークフローで同じイベントをフィルターするために `tags` と `tags-ignore` を使用することはできません。 1 つのイベントに対してブランチまたはタグ パターンを含める/除外の両方を行う場合は、`branches` または `tags` フィルターと `!` 文字を使用して、除外するブランチまたはタグを指定します。\n\n```\n          `!` 文字を含むブランチを定義する場合は、`!` 文字を含まないブランチも 1 つ以上定義する必要があります。 ブランチの除外のみを行いたい場合は、代わりに `branches-ignore` を使用します。 同様に、`!` 文字を含むタグを定義する場合は、`!` 文字を含まないタグも 1 つ以上定義する必要があります。 タグの除外のみを行いたい場合は、代わりに `tags-ignore` を使用します。\n```\n\nパターンを定義する順序により、結果に違いが生じます。\n\n* 肯定のマッチング パターンの後に否定のマッチング パターン (`!` のプレフィックスが付く) を定義すると、Git ref が除外されます。\n* 否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、Git ref を再び含めます。\n\n次のワークフローは、否定パターン `releases/10` が肯定パターンに従うため、`releases/beta/mona` または `releases/10-alpha` へのプッシュで実行され、`releases/beta/3-alpha` または `!releases/**-alpha` では実行されません。 <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  push:\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## `on.<push|pull_request|pull_request_target>.<paths|paths-ignore>`\n\n`push` と `pull_request` のイベントを使用すると、変更されるファイル パスに基づいて実行するワークフローを構成できます。 タグのプッシュに対して、パスのフィルターは評価されません。\n\nファイル パス パターンを包含する場合、またはファイル パス パターンの包含と除外の両方を行う場合は、`paths` フィルターを使用します。 ファイル パス パターンの除外のみを行う場合は、`paths-ignore` フィルターを使用します。 `paths` と `paths-ignore` のフィルターの両方をワークフロー内の同じイベントで使うことはできません。 1 つのイベントに対してパス パターンの包含と除外の両方を行う場合は、除外するパスを示すために`!` 文字を接頭辞にした`paths`フィルタを使用します。\n\n> \\[!NOTE]\n> `paths`パターンを定義する順序により、結果に違いが生じます:\n>\n> * 肯定のマッチング パターンの後に否定のマッチング パターン（`!` のプレフィックスが付く） を定義すると、パスを除外します。\n> * 否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、パスを再び含めます。\n\n`branches`/`branches-ignore` と `paths`/`paths-ignore` の両方を定義すると、ワークフローは両方のフィルターが満たされた場合にのみ実行されます。\n\n`paths` と `paths-ignore` のキーワードは、複数のパス名と一致するために `*` と `**` のワイルドカード文字を使用する glob パターンを受け入れます。 詳細については、「[GitHub Actions　のワークフロー構文](/ja/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet)」を参照してください。\n\n### 例: パスの包含\n\n`paths` フィルターにパターンにマッチするパスが 1 つでもあれば、ワークフローは実行されます。 たとえば、次のワークフローは、JavaScript ファイル (`.js`) をプッシュするたびに実行されます。\n\n```yaml\non:\n  push:\n    paths:\n      - '**.js'\n```\n\nパス フィルター、[ブランチ フィルター](/ja/actions/using-workflows/workflow-syntax-for-github-actions#onpull_requestpull_request_targetbranchesbranches-ignore)、または[コミット メッセージ](/ja/actions/managing-workflow-runs/skipping-workflow-runs)のためにワークフローがスキップされる場合、そのワークフローに関連付けられているチェックは \"保留中\" 状態のままになります。 これらのチェックを成功させる必要がある pull request は、マージが禁止されます。\n\n### 例: パスの除外\n\nすべてのパス名が `paths-ignore` のパターンと一致する場合、ワークフローは実行されません。 パス名が `paths-ignore` のパターンと一致しない場合は、一部のパス名がパターンと一致する場合でも、ワークフローが実行されます。\n\n以下のパスのフィルターを持つワークフローは、リポジトリのルートにある `docs` ディレクトリ外のファイルを少なくとも 1 つ含む `push` イベントでのみ実行されます。\n\n```yaml\non:\n  push:\n    paths-ignore:\n      - 'docs/**'\n```\n\n### 例: パスの包含および除外\n\n1 つのワークフローで同じイベントのフィルター処理をするために `paths` と `paths-ignore` を使用することはできません。 1 つのイベントに対してパス パターンの包含と除外の両方を行う場合は、除外するパスを示すために`!` 文字を接頭辞にした`paths`フィルタを使用します。\n\n`!` 文字を含むパスを定義する場合は、`!` 文字を含まないパスも 1 つ以上定義する必要があります。 パスの除外のみを行いたい場合は、代わりに `paths-ignore` を使用します。\n\n`paths`パターンを定義する順序により、結果に違いが生じます:\n\n* 肯定のマッチング パターンの後に否定のマッチング パターン（`!` のプレフィックスが付く） を定義すると、パスを除外します。\n* 否定のマッチングパターンの後に肯定のマッチングパターンを定義すると、パスを再び含めます。\n\nファイルが `sub-project/docs` ディレクトリに存在しない限り、`push` イベントが `sub-project` ディレクトリまたはそのサブディレクトリのファイルを含む場合は、この例はいつでも実行されます。 たとえば、`sub-project/index.js` または `sub-project/src/index.js` を変更するプッシュはワークフローの実行をトリガーしますが、`sub-project/docs/readme.md` のみを変更するプッシュはワークフローの実行をトリガーしません。\n\n```yaml\non:\n  push:\n    paths:\n      - 'sub-project/**'\n      - '!sub-project/docs/**'\n```\n\n### Git diffの比較\n\n> \\[!NOTE]\n> 1,000 以上のコミットをプッシュする場合、あるいは GitHub がタイムアウトのために diff を生成できない場合、そのワークフローは常に実行されます。\n\nフィルターは、変更されたファイルを評価し、`paths-ignore` または `paths` のリストに対してファイルを実行することで、ワークフローを実行すべきか判断します。 ファイルが変更されていない場合、ワークフローは実行されません。\n\nGitHubはプッシュに対してはツードットdiff、Pull Requestに対してはスリードットdiffを使って変更されたファイルのリストを生成します。\n\n* **pull request:** スリードット diff は、トピック ブランチの最新バージョンとトピック ブランチがベース ブランチと最後に同期されたコミットとの比較です。\n* **既存のブランチへのプッシュ:** ツードット diff は、ヘッド SHA とベース SHA を互いに直接比較します。\n* **新しいブランチへのプッシュ:** プッシュされた最も深いコミットの先祖の親に対するツードット diff です。\n\n> \\[!NOTE]\n> diff は 300 個のファイルに制限されます。 フィルターによって返された最初の 300 個のファイルに一致しないファイルが変更された場合、ワークフローは実行されません。 ワークフローが自動的に実行されるように、より具体的なフィルターを作成する必要がある場合があります。\n\n詳しくは、「[プルリクエスト中でのブランチの比較について](/ja/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/about-comparing-branches-in-pull-requests)」をご覧ください。\n\n## `on.schedule`\n\n```\n          `on.schedule` を使用すると、ワークフローの時間スケジュールを定義できます。\n```\n\n[POSIX cron 構文](https://pubs.opengroup.org/onlinepubs/9699919799/utilities/crontab.html#tag_20_25_07)を使用して、特定の時刻に実行するようにワークフローをスケジュールします。 既定では、スケジュールされたワークフローは UTC で実行されます。 必要に応じて、タイムゾーン対応のスケジュール設定に [IANA タイムゾーン文字列](https://en.wikipedia.org/wiki/List_of_tz_database_time_zones) を使用してタイムゾーンを指定できます。 スケジュールされたワークフローは、既定のブランチの最新のコミットに対して実行されます。 スケジュールされたワークフローを実行できる最短の間隔は、5 分ごとに 1 回です。\n\n> \\[!NOTE]\n> 夏時間 (DST) が適用されるタイムゾーンに `timezone` を設定するスケジュールの場合、春の時間進み (spring-forward) 切り替え中に、スキップされた時間のスケジュールされたワークフローは次の適切な時間に進みます。 たとえば、午前 2 時 30 分のスケジュールは午前 3 時に進みます。\n\nクーロン構文では、スペースで分けられた 5 つのフィールドがあり、各フィールドは時間の単位を表わします。\n\n```text\n┌───────────── minute (0 - 59)\n│ ┌───────────── hour (0 - 23)\n│ │ ┌───────────── day of the month (1 - 31)\n│ │ │ ┌───────────── month (1 - 12 or JAN-DEC)\n│ │ │ │ ┌───────────── day of the week (0 - 6 or SUN-SAT)\n│ │ │ │ │\n* * * * *\n```\n\n5 つのフィールドいずれにおいても、以下の演算子を使用できます:\n\n| 演算子 | 説明   | 例 |\n| --- | ---- | - |\n| \\*  | 任意の値 |   |\n\n```\n          `15 * * * *` は、毎日、毎時の15分に実行します。 |\n```\n\n\\| , | 値リストの区切り文字 |\n`2,10 4,5 * * *`は、毎日4時台および5時台の2分および10分に実行します。 |\n\\| - | 値の範囲 |\n`30 4-6 * * *` は、開始から4時間目、5時間目、6時間目の30分に実行されます。 |\n\\| / | ステップ値 |\n`20/15 * * * *` は、20分から59分までの間、15分ごとに実行されます（20分、35分、50分）。 |\n\nこの例では、毎週月曜日から金曜日のアメリカ/New\\_Yorkタイムゾーンで午前 5 時 30 分にワークフローを実行するようにトリガーします。\n\n```yaml\non:\n  schedule:\n    - cron: '30 5 * * 1-5'\n      timezone: \"America/New_York\"\n```\n\n1 つのワークフローを、複数の `schedule` イベントでトリガーできます。\n`schedule` コンテキストを通じて、ワークフローをトリガーした `github.event.schedule` イベントにアクセスします。 この例では、月曜日から木曜日までの 5:30 UTC および火曜日と木曜日の 17:30 UTC にワークフローの実行がトリガーされますが、月曜日と水曜日には `Not on Monday or Wednesday` ステップはスキップされます。\n\n```yaml\non:\n  schedule:\n    - cron: '30 5 * * 1,3'\n    - cron: '30 5,17 * * 2,4'\n\njobs:\n  test_schedule:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Not on Monday or Wednesday\n        if: github.event.schedule != '30 5 * * 1,3'\n        run: echo \"This step will be skipped on Monday and Wednesday\"\n      - name: Every time\n        run: echo \"This step will always run\"\n```\n\n```\n          `schedule` イベントについて詳しくは、「[AUTOTITLE](/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule)」を参照してください。\n```\n\n## `on.workflow_call`\n\n```\n          `on.workflow_call` は、再利用可能なワークフローの入力と出力を定義するために使います。 呼び出し対象のワークフローで使用できるシークレットをマップすることもできます。 再利用可能なワークフローについて詳しくは、「[AUTOTITLE](/actions/using-workflows/reusing-workflows)」をご覧ください。\n```\n\n## `on.workflow_call.inputs`\n\n```\n          `workflow_call` キーワードを使う場合は、必要に応じて、呼び出し元ワークフローから呼び出し対象のワークフローに渡される入力を指定できます。 \n          `workflow_call` キーワードについて詳しくは、「[AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#workflow-reuse-events)」をご覧ください。\n\n          `on.workflow_call.inputs` には、使用可能な標準入力パラメーターに加えて `type` パラメーターが必要です。 詳細については、「[`on.workflow_call.inputs.<input_id>.type`](#onworkflow_callinputsinput_idtype)」を参照してください。\n\n          `default` パラメーターが設定されていない場合、入力の既定値は `false` (ブール値の場合)、`0` (数値の場合)、`\"\"` (文字列の場合) です。\n```\n\n呼び出し対象のワークフロー内で `inputs` コンテキストを使って入力を参照できます。 詳しくは、「[コンテキスト リファレンス](/ja/actions/learn-github-actions/contexts#inputs-context)」をご覧ください。\n\n呼び出し対象のワークフローで指定されていない入力が呼び出し元ワークフローによって渡されると、エラーが発生します。\n\n###\n\n```\n          `on.workflow_call.inputs` の例\n```\n\n```yaml\non:\n  workflow_call:\n    inputs:\n      username:\n        description: 'A username passed from the caller workflow'\n        default: 'john-doe'\n        required: false\n        type: string\n\njobs:\n  print-username:\n    runs-on: ubuntu-latest\n\n    steps:\n      - name: Print the input name to STDOUT\n        run: echo The username is ${{ inputs.username }}\n```\n\n詳しくは、「[ワークフローを再利用する](/ja/actions/using-workflows/reusing-workflows)」をご覧ください。\n\n## `on.workflow_call.inputs.<input_id>.type`\n\n```\n          `on.workflow_call` キーワードに対して入力が定義されている場合は必須です。 このパラメーターの値は、入力のデータ型を指定する文字列です。 これは、`boolean`、`number`、または `string` のいずれかである必要があります。\n```\n\n## `on.workflow_call.outputs`\n\n呼び出し対象のワークフローの出力のマップ。 呼び出し対象のワークフロー出力は、呼び出し元ワークフロー内のすべてのダウンストリーム ジョブで使用できます。 各出力には、識別子、省略可能な `description,`、`value.` があります。呼び出し対象のワークフロー内のジョブからの出力の値には `value` を設定する必要があります。\n\n次の例では、この再利用可能なワークフローに対して 2 つの出力 `workflow_output1` と `workflow_output2` が定義されています。 これらは、どちらも `job_output1` というジョブから `job_output2` と `my_job` という出力にマップされます。\n\n###\n\n```\n          `on.workflow_call.outputs` の例\n```\n\n```yaml\non:\n  workflow_call:\n    # Map the workflow outputs to job outputs\n    outputs:\n      workflow_output1:\n        description: \"The first job output\"\n        value: ${{ jobs.my_job.outputs.job_output1 }}\n      workflow_output2:\n        description: \"The second job output\"\n        value: ${{ jobs.my_job.outputs.job_output2 }}\n```\n\nジョブ出力を参照する方法については、[`jobs.<job_id>.outputs`](#jobsjob_idoutputs) を参照してください。 詳しくは、「[ワークフローを再利用する](/ja/actions/using-workflows/reusing-workflows)」をご覧ください。\n\n## `on.workflow_call.secrets`\n\n呼び出し対象のワークフローで使用できるシークレットのマップ。\n\n呼び出し対象のワークフロー内で `secrets` コンテキストを使ってシークレットを参照できます。\n\n> \\[!NOTE]\n> 入れ子になった再利用可能なワークフローにシークレットを渡している場合、シークレットを渡すには、もう一度 [`jobs.<job_id>.secrets`](#jobsjob_idsecrets) を使う必要があります。 詳しくは、「[ワークフローを再利用する](/ja/actions/using-workflows/reusing-workflows#passing-secrets-to-nested-workflows)」をご覧ください。\n\n呼び出し対象のワークフローで指定されていないシークレットが呼び出し元ワークフローによって渡されると、エラーが発生します。\n\n###\n\n```\n          `on.workflow_call.secrets` の例\n```\n\n```yaml\non:\n  workflow_call:\n    secrets:\n      access-token:\n        description: 'A token passed from the caller workflow'\n        required: false\n\njobs:\n\n  pass-secret-to-action:\n    runs-on: ubuntu-latest\n    steps:\n    # passing the secret to an action\n      - name: Pass the received secret to an action\n        uses: ./.github/actions/my-action\n        with:\n          token: ${{ secrets.access-token }}\n\n  # passing the secret to a nested reusable workflow\n  pass-secret-to-workflow:\n    uses: ./.github/workflows/my-workflow\n    secrets:\n       token: ${{ secrets.access-token }}\n```\n\n## `on.workflow_call.secrets.<secret_id>`\n\nシークレットに関連付ける文字列識別子。\n\n## `on.workflow_call.secrets.<secret_id>.required`\n\nシークレットを指定する必要があるかどうかを指定するブール値。\n\n## `on.workflow_run.<branches|branches-ignore>`\n\n`workflow_run` イベントを使用する場合は、ワークフローをトリガーするためにトリガーするワークフローが稼働する必要があるブランチを指定できます。\n\n```\n          `branches` フィルターと `branches-ignore` フィルターは、複数のブランチ名に一致する文字 (`*`、`**`、`+`、`?` など) を使用する glob パターンを受け入れます。`!` 名前にこれらの文字のいずれかが含まれており、リテラルの一致が必要な場合は、__ でこれらの各特殊文字を`\\`する必要があります。 glob パターンの詳細については、[AUTOTITLE](/actions/using-workflows/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet) を参照してください。\n```\n\nたとえば、次のトリガーを持つワークフローは、名前が `Build` で始まるブランチで `releases/` という名前のワークフローが稼働している場合にのみ実行されます。\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n```\n\n次のトリガーを持つワークフローは、名前が `Build` でないブランチで `canary` という名前のワークフローが稼働している場合にのみ実行されます。\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches-ignore:\n      - \"canary\"\n```\n\n```\n          `branches` と `branches-ignore` のフィルターの両方をワークフロー内の同じイベントで使うことはできません。 1 つのイベントに対して分岐パターンの適用と除外の両方を行う場合は、`branches` フィルターと `!` 文字を使用して、除外する分岐を指定します。\n```\n\nパターンを定義する順序により、結果に違いが生じます。\n\n* 肯定のマッチング パターンの後に否定のマッチング パターン（`!` のプレフィックスが付く） を定義すると、ブランチを除外します。\n* 否定のマッチング パターンの後に肯定のマッチング パターンを定義すると、ブランチを再び含めます。\n\nたとえば、次のトリガーを持つワークフローは、名前が `Build` または `releases/10` で始まるブランチで `releases/beta/mona` という名前のワークフローが稼働している場合にのみ実行されますが、`releases/10-alpha`、`releases/beta/3-alpha` または `main` という名前のブランチでは実行されません。 <!-- markdownlint-disable-line outdated-release-phase-terminology -->\n\n```yaml\non:\n  workflow_run:\n    workflows: [\"Build\"]\n    types: [requested]\n    branches:\n      - 'releases/**'\n      - '!releases/**-alpha'\n```\n\n## `on.workflow_dispatch`\n\n`workflow_dispatch` イベントを使用すると、必要に応じてワークフローに渡される入力を指定できます。\n\nこのトリガーは、ワークフロー ファイルが既定のブランチにある場合に限りイベントを受信します。\n\n## `on.workflow_dispatch.inputs`\n\nトリガーされたワークフローは、`inputs` コンテキスト内の入力を受け取ります。 詳細については、「[コンテキスト](/ja/actions/learn-github-actions/contexts#inputs-context)」を参照してください。\n\n> \\[!NOTE]\n>\n> * ワークフローは、`github.event.inputs` コンテキスト内の入力も受け取ります。\n>   `inputs` コンテキストと `github.event.inputs` コンテキストの情報ですが、`inputs` コンテキストではブール値が文字列に変換されず、ブール値として保持されます。\n>   `choice` 型は文字列に解決され、1 つの選択可能なオプションです。\n> *\n\n```\n          `inputs`の最上位のプロパティの最大数は、25  です。 \n```\n\n> *\n\n```\n          `inputs` のペイロードの最大数は 65,535 文字です。\n```\n\n###\n\n```\n          `on.workflow_dispatch.inputs` の例\n```\n\n```yaml\non:\n  workflow_dispatch:\n    inputs:\n      logLevel:\n        description: 'Log level'\n        required: true\n        default: 'warning'\n        type: choice\n        options:\n          - info\n          - warning\n          - debug\n      print_tags:\n        description: 'True to print to STDOUT'\n        required: true\n        type: boolean\n      tags:\n        description: 'Test scenario tags'\n        required: true\n        type: string\n      environment:\n        description: 'Environment to run tests against'\n        type: environment\n        required: true\n\njobs:\n  print-tag:\n    runs-on: ubuntu-latest\n    if: ${{ inputs.print_tags }} \n    steps:\n      - name: Print the input tag to STDOUT\n        run: echo  The tags are ${{ inputs.tags }} \n```\n\n## `on.workflow_dispatch.inputs.<input_id>.required`\n\n入力を指定する必要があるかどうかを指定するブール値。\n\n## `on.workflow_dispatch.inputs.<input_id>.type`\n\nこのパラメーターの値は、入力のデータ型を指定する文字列です。 これは、`boolean`、`choice`、`number`、`environment`または`string`. のいずれかである必要があります。\n\n## `permissions`\n\n`permissions` を使用して `GITHUB_TOKEN` に付与された既定のアクセス許可を変更し、必要に応じてアクセスを追加または削除することで、必要最小限のアクセスのみを許可することができます。 詳しくは、「[ワークフローでの認証に GITHUB\\_TOKEN を使用する](/ja/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)」をご覧ください。\n\n```\n          `permissions` は、最上位のキーとして、ワークフロー内のすべてのジョブに適用するか、または特定のジョブ内で使用できます。 特定のジョブ内に `permissions` キーを追加すると、`GITHUB_TOKEN` を使用するそのジョブ内のすべてのアクションと実行コマンドが、指定したアクセス権を取得します。 詳細については、「[`jobs.<job_id>.permissions`](/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idpermissions)」を参照してください。\n```\n\nOrganization の所有者は、リポジトリ レベルで `GITHUB_TOKEN` の書き込みアクセスを制限できます。 詳細については、「[組織のGitHub Actionsの無効化または制限](/ja/organizations/managing-organization-settings/disabling-or-limiting-github-actions-for-your-organization#setting-the-permissions-of-the-github_token-for-your-organization)」を参照してください。\n\n```\n          [\n          `pull_request_target`\n          ](/actions/using-workflows/events-that-trigger-workflows#pull_request_target) イベントによってワークフローがトリガーされると、パブリック フォークからトリガーされた場合でも、`GITHUB_TOKEN` にはリポジトリの読み取り/書き込みアクセス許可が付与されます。 詳しくは、「[AUTOTITLE](/actions/using-workflows/events-that-trigger-workflows#pull_request_target)」をご覧ください。\n```\n\n以下の表に示すように、使用可能なアクセス許可ごとに、`read` (該当する場合)、`write`、または `none` のいずれかのアクセス レベルを割り当てることができます。\n`write` には `read` が含まれます。 これらのアクセス許可のいずれかにアクセスを指定すると、指定されていないすべてのアクセス許可が `none` に設定されます。\n\n使用可能なアクセス許可と、それぞれがアクションに実行を許可する内容の詳細:\n\n\\| 権限 |\n`GITHUB_TOKEN` を使ってアクションに許可する内容 |\n\\| --- | --- |\n\\|  `actions` | GitHub Actions を操作します。 たとえば、`actions: write` は、アクションによるワークフロー実行の取り消しを許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions)」をご覧ください。 |\n\\|  |\n\\|  `artifact-metadata` | 成果物メタデータを操作します。 たとえば、 `artifact-metadata: write` は、ビルド成果物に代わってストレージ レコードを作成するアクションを許可します。 詳しくは、「[アーティファクト メタデータの REST API エンドポイント](/ja/rest/orgs/artifact-metadata?apiVersion=2022-11-28)」をご覧ください。 |\n\\|  |\n\\|  |\n\\|  `attestations` | 構成証明の認証作業 たとえば、 `attestations: write` ビルドの成果物構成証明を生成するアクションが許可されます。 詳細については、「[アーティファクトの構成証明を使用してビルドの出所を確立する](/ja/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)」を参照してください |\n\\|  |\n\\|  `checks` | チェック実行とチェック スイートを操作します。 たとえば、`checks: write` は、アクションによるチェック実行の作成を許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks)」をご覧ください。 |\n\\|  `contents` | リポジトリの内容を操作します。 たとえば、`contents: read` はアクションによるコミットの一覧表示を許可し、`contents: write` はアクションによるリリースの作成を許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents)」をご覧ください。 |\n\\|  `deployments` | デプロイを操作します。 たとえば、`deployments: write` は、アクションによる新しいデプロイの作成アクションを許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments)」をご覧ください。 |\n\\|  `discussions` | GitHub ディスカッションで作業します。 たとえば、`discussions: write` は、アクションがディスカッションを閉じるか削除することを許可します。 詳しくは、「[ディスカッションでのGraphQL APIの利用](/ja/graphql/guides/using-the-graphql-api-for-discussions)」をご覧ください。 |\n\\|  |\n\\|  `id-token` | OpenID Connect (OIDC) トークンをフェッチします。 これには `id-token: write` が必要です。 詳細については、「[OpenID Connect](/ja/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc)」を参照してください |\n\\|  |\n\\|  `issues` | 問題に取り組みます。 たとえば、`issues: write` は、アクションがイシューにコメントを追加することを許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues)」をご覧ください。 |\n\\|  |\n\\|  `models`  | GitHub Models を使用して AI 推論応答を生成します。 たとえば、`models: read` は、GitHub Models 推論 API を使用するアクションを許可します。 「[AI モデルを使用したプロトタイプ作成](/ja/github-models/prototyping-with-ai-models)」を参照してください。 |\n\\|  |\n\\|  `packages` | GitHub Packages を操作します。 たとえば、`packages: write` は、アクションによる GitHub Packages でのパッケージのアップロードと発行を許可します。 詳しくは、「[GitHub Packagesの権限について](/ja/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries)」をご覧ください。 |\n\\|  `pages` | GitHub Pages を操作します。 たとえば、`pages: write` は、アクションによる GitHub Pages のビルドの要求を許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages)」をご覧ください。 |\n\\|  `pull-requests` | pull request を操作します。 たとえば、`pull-requests: write` は、アクションによる pull request へのラベルの追加を許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests)」をご覧ください。 |\n\\|  |\n\\|  `security-events` | GitHub のコード スキャン アラートを操作します。 たとえば、`security-events: read` を指定すると、アクションでリポジトリ内のコード スキャン アラートを一覧表示できるようになります。また、`security-events: write` を指定すると、アクションでコード スキャン アラートの状態を更新できるようになります。 詳細については、「[\"コード スキャン アラート\" に関するリポジトリのアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)」を参照してください。 <br><br> このアクセス許可では、Dependabot およびシークレット スキャン アラートを読み取ることができないため、GitHub App または personal access token が必要です。 詳細については、「GitHub Apps に必要なアクセス許可」の「[\"Dependabot アラート\" に関するリポジトリのアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts)」と「[\"シークレット スキャン アラート\" に関するリポジトリのアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts)」を参照してください。 |\n\\| `statuses` | コミットの状態を操作します。 たとえば、`statuses:read` は、アクションが特定の参照のコミット状態を一覧表示することを許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses)」をご覧ください。 |\n\n###\n\n```\n          `GITHUB_TOKEN` スコープのアクセスの定義\n```\n\n`GITHUB_TOKEN` キー内で使用可能なアクセス許可の値として `read`、`write`、または `none` を指定することで、`permissions` が許可するアクセスを定義できます。\n\n```yaml\npermissions:\n  actions: read|write|none\n  artifact-metadata: read|write|none\n  attestations: read|write|none\n  checks: read|write|none\n  contents: read|write|none\n  deployments: read|write|none\n  id-token: write|none\n  issues: read|write|none\n  models: read|none\n  discussions: read|write|none\n  packages: read|write|none\n  pages: read|write|none\n  pull-requests: read|write|none\n  security-events: read|write|none\n  statuses: read|write|none\n```\n\nこれらのアクセス許可のいずれかにアクセスを指定すると、指定されていないすべてのアクセス許可が `none` に設定されます。\n\n利用可能なすべてのアクセス許可に対して `read-all` または `write-all` どちらかのアクセスを定義するには、以下の構文が使えます。\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\n次の構文を使用して、使用可能なすべてのアクセス許可のアクセス許可を無効にすることができます。\n\n```yaml\npermissions: {}\n```\n\n#### フォークされたリポジトリのアクセス許可を変更する\n\n`permissions` キーを使用して、フォークされたリポジトリの読み取り権限を追加および削除できますが、通常は書き込みアクセス権を付与することはできません。 この動作の例外としては、管理者ユーザーが GitHub Actions の設定で **\\[Send write tokens to workflows from pull requests]\\(pull request からワークフローに書き込みトークンを送信する)** を選択している場合があります。 詳しくは、「[リポジトリのGitHub Actions設定の管理](/ja/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks)」をご覧ください。\n\n## ワークフロー ジョブのアクセス許可の計算方法\n\n```\n          `GITHUB_TOKEN` のアクセス許可は最初に、エンタープライズ、組織、またはリポジトリの既定値に設定されます。 デフォルトがこれらのレベルのいずれかで制限付きの権限に設定されている場合、これは関連するリポジトリに適用されます。 たとえば、Organization レベルで制限付きのデフォルトを選択した場合、その Organization 内のすべてのリポジトリは、制限付きの権限をデフォルトとして使用します。 次に、ワークフローファイル内の構成に基づいて、最初にワークフローレベルで、次にジョブレベルで権限が調整されます。 最後に、フォークされたリポジトリからの `pull_request_target` 以外のプル要求イベントによってワークフローがトリガーされ、[ **pull requests からワークフローに書き込みトークンを送信** する] 設定が選択されていない場合、読み取り専用の書き込みアクセス許可を変更するようにアクセス許可が調整されます。\n```\n\n### ワークフロー内のすべてのジョブの `GITHUB_TOKEN` アクセス許可の設定\n\n設定がワークフロー内のすべてのジョブに適用されるように、ワークフローの最上位レベルで `permissions` を指定できます。\n\n#### 例: ワークフロー全体の `GITHUB_TOKEN` アクセス許可の設定\n\nこの例では、ワークフロー内のすべてのジョブに適用される `GITHUB_TOKEN` に設定されているアクセス許可を示しています。 すべての権限に読み取りアクセスが付与されます。\n\n```yaml\nname: \"My workflow\"\n\non: [ push ]\n\npermissions: read-all\n\njobs:\n  ...\n```\n\n### フォークされたリポジトリに対する `permissions` キーの使用\n\n```\n          `permissions` キーを使って、フォークされたリポジトリの `read` アクセス許可を追加および削除できますが、通常、`write` アクセス権を付与することはできません。 この動作の例外は、管理者ユーザーが**** 設定の GitHub Actionsするオプションを選択している場合です。 詳しくは、「[AUTOTITLE](/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks)」をご覧ください。\n```\n\n###\n\n```\n          Dependabot\n```\n\nによってトリガーされるワークフロー実行のアクセス権\n\nDependabot pull request によってトリガーされるワークフロー実行は、フォークされたリポジトリからのものであるかのように実行されるため、読み取り専用の `GITHUB_TOKEN` を使用します。 それらのワークフローの実行は、シークレットにはアクセスできません。 これらのワークフローをセキュリティで保護するための戦略については、「[セキュリティで保護された使用に関するリファレンス](/ja/actions/security-guides/security-hardening-for-github-actions)」を参照してください。\n\n## `env`\n\nワークフロー中のすべてのジョブのステップで使うことができる変数の `map` です。 1 つのジョブのステップか 1 つのステップでしか使うことができない変数を設定することもできます。 詳細については、[`jobs.<job_id>.env`](#jobsjob_idenv) および [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv) を参照してください。\n\n```\n          `env` マップ内の変数は、マップ内の他の変数の観点からは定義できません。\n```\n\n同じ名前で複数の環境変数が定義されている場合、GitHub では最も具体的な変数を使用します。 たとえば、ステップ中で定義された環境変数は、ジョブやワークフローの同じ名前の環境変数をステップの実行の間オーバーライドします。 ジョブで定義された環境変数は、そのジョブの実行の間はワークフローの同じ名前の変数をオーバーライドします。\n\n###\n\n```\n          `env` の例\n```\n\n```yaml\nenv:\n  SERVER: production\n```\n\n## `defaults`\n\n`defaults` を使用して、デフォルト設定の `map` を作成します。これは、ワークフロー内のすべてのジョブに適用されます。 1つのジョブだけで利用できるデフォルト設定を設定することもできます。 詳細については、「[`jobs.<job_id>.defaults`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaults)」を参照してください。\n\n同じ名前で複数のデフォルトの設定が定義されている場合、GitHubは最も具体的なデフォルト設定を使用します。 たとえば、ジョブで定義されたデフォルト設定は、同じ名前を持つワークフローで定義されたデフォルト設定をオーバーライドします。\n\n## `defaults.run`\n\n`defaults.run` を使用すると、ワークフロー内のすべての [`run`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) ステップに、デフォルトの `shell` オプションと `working-directory` オプションを指定できます。 1 つのジョブにのみ利用できる `run` に対して、デフォルト設定を設定することもできます。 詳細については、「[`jobs.<job_id>.defaults.run`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun)」を参照してください。 このキーワード中では、コンテキストや式を使うことはできません。\n\n同じ名前で複数のデフォルトの設定が定義されている場合、GitHubは最も具体的なデフォルト設定を使用します。 たとえば、ジョブで定義されたデフォルト設定は、同じ名前を持つワークフローで定義されたデフォルト設定をオーバーライドします。\n\n### 例: デフォルトのシェルと作業ディレクトリを設定する\n\n```yaml\ndefaults:\n  run:\n    shell: bash\n    working-directory: ./scripts\n```\n\n## `defaults.run.shell`\n\n`shell` を使用してステップの `shell` を定義します。 このキーワードは、複数のコンテキストを参照できます。 詳細については、「[コンテキスト](/ja/actions/learn-github-actions/contexts#context-availability)」を参照してください。\n\n| サポートされているプラットフォーム | `shell` パラメーター | 説明                                                                                                                                                                               | 内部で実行されるコマンド                                    |\n| ----------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux/macOS       | unspecified    | Windows 以外のプラットフォームの既定のシェル。 これにより、`bash` を明示的に指定した場合とは異なるコマンドが実行されることに注意してください。 `bash` がパスに見つからない場合、これは `sh` のように扱われます。                                                          | `bash -e {0}`                                   |\n| すべて               | `bash`         | `sh` へのフォールバックが設定された、Windows 以外のプラットフォームの既定のシェル。 Windowsでbashシェルを指定すると、Windows用Gitに含まれるbashシェルが使用されます。                                                                           | `bash --noprofile --norc -eo pipefail {0}`      |\n| すべて               | `pwsh`         | PowerShell Coreです。 GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。                                                                                                                         | `pwsh -command \". '{0}'\"`                       |\n| すべて               | `python`       | Pythonのコマンドを実行します。                                                                                                                                                               | `python {0}`                                    |\n| Linux/macOS       | `sh`           | Windows 以外のプラットフォームにおいて、シェルが提供されておらず、パスで `bash` が見つからなかった場合のフォールバック動作。                                                                                                           | `sh -e {0}`                                     |\n| Windows           | `cmd`          | GitHub によってスクリプト名に拡張子 `.cmd` が追加され、`{0}` が置き換えられます。                                                                                                                              | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows           | `pwsh`         | これはWindowsで使われるデフォルトのシェルです。 PowerShell Coreです。 GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。 セルフホステッド Windows ランナーに *PowerShell Core* がインストールされていない場合は、代わりに *PowerShell Desktop* が使われます。 | `pwsh -command \". '{0}'\"`.                      |\n| Windows           | `powershell`   | PowerShell Desktop. GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。                                                                                                                        | `powershell -command \". '{0}'\"`.                |\n\n同じ名前で複数のデフォルトの設定が定義されている場合、GitHubは最も具体的なデフォルト設定を使用します。 たとえば、ジョブで定義されたデフォルト設定は、同じ名前を持つワークフローで定義されたデフォルト設定をオーバーライドします。\n\n## `defaults.run.working-directory`\n\n`working-directory` を使用してステップの `shell` の作業ディレクトリを定義します。 このキーワードは、複数のコンテキストを参照できます。 詳細については、「[コンテキスト](/ja/actions/learn-github-actions/contexts#context-availability)」を参照してください。\n\n> \\[!TIP]\n> その中でシェルを実行する前に、割り当てる `working-directory` がランナーに存在することを確認してください。同じ名前で複数のデフォルトの設定が定義されている場合、GitHubは最も具体的なデフォルト設定を使用します。 たとえば、ジョブで定義されたデフォルト設定は、同じ名前を持つワークフローで定義されたデフォルト設定をオーバーライドします。\n\n## `concurrency`\n\n同じコンカレンシー グループを使うジョブまたはワークフローを一度に 1 つだけ実行するには、`concurrency` を使います。 並行処理グループには、任意の文字列または式を使用できます。 この式に使用できるコンテキストは、[`github`](/ja/actions/learn-github-actions/contexts#github-context)、[`inputs`](/ja/actions/learn-github-actions/contexts#inputs-context)、[`vars`](/ja/actions/learn-github-actions/contexts#vars-context) のみです。 式の詳細については、「[ワークフロー内とアクション内で式を評価する](/ja/actions/learn-github-actions/expressions)」を参照してください。\n\nジョブ レベルで `concurrency` を指定することもできます。 詳細については、「[`jobs.<job_id>.concurrency`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idconcurrency)」を参照してください。\n\nつまり、コンカレンシー グループには、最大 1 つの実行ジョブと 1 つの保留中のジョブが存在できることを意味します。 並行ジョブかワークフローがキューに入っている場合、リポジトリ内の同じ並行グループを使う他のジョブかワークフローが進行中だと、キューイングされたジョブかワークフローは `pending` になります。 同じコンカレンシー グループ内の既存の `pending` ジョブまたはワークフロー (存在する場合) は取り消され、キューに登録された新規ジョブまたはワークフローがその代わりに使用されます。\n\n同じコンカレンシー グループ内の現在実行中のジョブかワークフローもキャンセルするには、`cancel-in-progress: true` を指定します。 同じコンカレンシー グループ内で現在実行中のジョブまたはワークフローを条件付きで取り消すには、許可されている式コンテキストのいずれかを含む式として `cancel-in-progress` を指定 できます。\n\n> \\[!NOTE]\n>\n> * コンカレンシー グループ名では大文字と小文字が区別されません。 たとえば、`prod` と `Prod` は同じコンカレンシー グループとして扱われます。\n> * コンカレンシー グループを使用したジョブまたはワークフローでは、実行の順序付けは保証されません。 同じコンカレンシー グループ内のジョブまたはワークフローは、任意の順序で処理されます。\n\n### 例：コンカレンシーとデフォルトビヘイビアーの使用\n\nGitHub Actions のデフォルトビヘイビアーでは、複数のジョブまたはワークフロー実行を同時開催で実行できます。 `concurrency` キーワード を使用すると、ワークフロー実行のコンカレンシーを制御できます。\n\nたとえば、トリガー条件が定義された直後に`concurrency`キーワード を使用して、特定のブランチに対するワークフロー実行全体のコンカレンシーを制限できます：\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\nジョブ レベルで`concurrency`キーワード を使用して、ワークフロー内のジョブのコンカレンシーを制限することもできます：\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: example-group\n      cancel-in-progress: true\n```\n\n### 例: コンカレンシー グループ\n\nコンカレンシー グループは、同じコンカレンシー 鍵を共有するワークフロー実行またはジョブの実行を管理および制限する方法を提供します。\n\n`concurrency` 鍵は、ワークフローまたはジョブをまとめてコンカレンシー グループにグループ化するために使用されます。 `concurrency`鍵を定義すると、GitHub Actions によって、その鍵を持つワークフローまたはジョブが常に 1 つだけ実行されるようになります。 新しいワークフローの実行またはジョブが同じ `concurrency` 鍵で開始された場合、GitHub Actions はその鍵で既に実行されているワークフローまたはジョブをキャンセルします。 `concurrency`鍵は 、ハードコーディングされた文字列にすることも、コンテキスト変数を含む動的な式にすることもできます。\n\nワークフローまたはジョブがコンカレンシー グループの一部になるように、ワークフローでコンカレンシー条件を定義できます。\n\nつまり、ワークフローの実行またはジョブが開始されると、GitHub は、同じコンカレンシー グループで既に進行状況にあるワークフローの実行またはジョブをキャンセルします。 これは、競合を引き起こしたり、必要以上に多くのリソースを消費したりする可能性のある処置を防ぐために、ステージング環境への展開に使用されるワークフローやジョブの特定のセットに対する並列実行を防ぐ場合に便利です。\n\nこの例では、 `job-1`は、`staging_environment`と名付けられたコンカレンシー グループの一部です。 つまり、新しい`job-1` の実行がトリガーされると、既に進行状況の `staging_environment`コンカレンシー グループ内の同じジョブの実行はすべてキャンセルされます。\n\n```yaml\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: staging_environment\n      cancel-in-progress: true\n```\n\nまたは、ワークフロー内などの `concurrency: ci-${{ github.ref }}`のような 動的な式を使用すると、ワークフローまたはジョブは、ワークフローをトリガーしたブランチまたはタグのリファレンスに続く `ci-`と名付けられたコンカレンシー グループの一部になります。 この例では、前の実行の進行中に新しいコミットが メイン ブランチにプッシュされた場合、前の実行はキャンセルされ、新しいコミットが開始されます：\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ci-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### 並行性を使って進行中のジョブもしくは実行をキャンセルする例\n\nコンカレンシーを使用して進行状況のジョブをキャンセルするか、GitHub Actions で実行するには、`concurrency`鍵を使用でき、次の`cancel-in-progress`オプションを`true`に設定します：\n\n```yaml\nconcurrency:\n  group: ${{ github.ref }}\n  cancel-in-progress: true\n```\n\nこの例では、特定のコンカレンシー グループを定義せずに、GitHub Actions はジョブまたはワークフローの\\_どんな\\_進行状況の実行もキャンセルします。\n\n### 例: フォールバック値の使用\n\n特定のイベントにのみ定義されるプロパティでグループ名を作成する場合、フォールバック値を使用できます。 たとえば、`github.head_ref` は `pull_request` イベントにのみ定義されます。 ワークフローが `pull_request` イベントに加えて他のイベントにも応答する場合、構文エラーを回避するためにフォールバックを指定する必要があります。 次のコンカレンシー グループは、`pull_request` イベントで進行中のジョブか実行のみを取り消します。`github.head_ref` が未定義の場合、コンカレンシー グループは実行 ID にフォールバックします。これは、一意であり、実行に対して定義されていることが保証されています。\n\n```yaml\nconcurrency:\n  group: ${{ github.head_ref || github.run_id }}\n  cancel-in-progress: true\n```\n\n### 例: 現在のワークフローで進行中のジョブまたは実行のみを取り消します\n\n同じリポジトリに複数のワークフローがある場合、他のワークフローの進行中のジョブまたは実行が取り消されないように、コンカレンシー グループ名はワークフロー間で一意である必要があります。 そうでない場合、ワークフローに関係なく、以前に進行中または保留中のジョブが取り消されます。\n\n同じワークフローの進行中の実行だけを取り消すには、`github.workflow` プロパティを使ってコンカレンシー グループを構築します。\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### 例: 特定のブランチで進行中のジョブのみを取り消す\n\n特定のブランチで進行中のジョブを取り消したいが、他のブランチでは取り消さない場合は、`cancel-in-progress` で条件式を使用できます。 たとえば、開発ブランチでは進行中のジョブを取り消したいが、リリース ブランチでは取り消さない場合に、これを行うことができます。\n\nリリース ブランチで実行されていない場合に、同じワークフローの進行中の実行のみを取り消すには、`cancel-in-progress` を次のような式に設定します。\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nこの例では、`release/1.2.3` ブランチへの複数のプッシュは進行中の実行を取り消しません。 `main` などの別のブランチにプッシュすると、進行中の実行が取り消されます。\n\n## `jobs`\n\nワークフロー実行は、既定で並列実行される 1 つ以上の `jobs` で構成されます。 ジョブを順番に実行するには、`jobs.<job_id>.needs` キーワードを使用して他のジョブへの依存関係を定義できます。\n\n各ジョブは、`runs-on` で指定されたランナー環境で実行されます。\n\nワークフローの利用限度内であれば、実行するジョブ数に限度はありません。 詳細情報が必要な場合、GitHub ホスト ランナーについては「[課金と使用](/ja/actions/learn-github-actions/usage-limits-billing-and-administration)」を、自己ホストランナーの使用制限については「[アクションの制限](/ja/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners)」を参照してください。\n\nワークフロー実行で実行中のジョブの一意識別子を確認する必要がある場合は、GitHub API を使用できます。 詳しくは、「[GitHub Actionsの REST API エンドポイント](/ja/rest/actions#workflow-jobs)」をご覧ください。\n\n## `jobs.<job_id>`\n\nジョブへの一意の識別子の指定には、`jobs.<job_id>` を使います。 `job_id` キーは文字列で、その値はジョブの設定データのマップです。 `<job_id>` は、`jobs` オブジェクトに固有の文字列に置き換える必要があります。 `<job_id>` は文字または `_` で始まり、英数字、`-`、あるいは `_` のみを含める必要があります。\n\n### 例: ジョブを作成する\n\nこの例では、`job_id` 値が `my_first_job` と `my_second_job` の 2 つのジョブが作成されました。\n\n```yaml\njobs:\n  my_first_job:\n    name: My first job\n  my_second_job:\n    name: My second job\n```\n\n## `jobs.<job_id>.name`\n\nGitHub UI に表示されるジョブの名前の設定に `jobs.<job_id>.name` を使用します。\n\n## `jobs.<job_id>.permissions`\n\n特定のジョブについて、`jobs.<job_id>.permissions` を使用して `GITHUB_TOKEN` に付与された既定のアクセス許可を変更し、必要に応じてアクセスを追加または削除することで、必要最小限のアクセスのみを許可することができます。 詳しくは、「[ワークフローでの認証に GITHUB\\_TOKEN を使用する](/ja/actions/security-guides/automatic-token-authentication#modifying-the-permissions-for-the-github_token)」をご覧ください。\n\nジョブ定義内で権限を指定することで、必要に応じて、ジョブごとに `GITHUB_TOKEN` に異なる権限のセットを構成できます。 または、ワークフロー内のすべてのジョブの権限を指定することもできます。 ワークフロー レベルでのアクセス許可の定義については、[`permissions`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#permissions) を参照してください。\n\n以下の表に示すように、使用可能なアクセス許可ごとに、`read` (該当する場合)、`write`、または `none` のいずれかのアクセス レベルを割り当てることができます。\n`write` には `read` が含まれます。 これらのアクセス許可のいずれかにアクセスを指定すると、指定されていないすべてのアクセス許可が `none` に設定されます。\n\n使用可能なアクセス許可と、それぞれがアクションに実行を許可する内容の詳細:\n\n\\| 権限 |\n`GITHUB_TOKEN` を使ってアクションに許可する内容 |\n\\| --- | --- |\n\\|  `actions` | GitHub Actions を操作します。 たとえば、`actions: write` は、アクションによるワークフロー実行の取り消しを許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-actions)」をご覧ください。 |\n\\|  |\n\\|  `artifact-metadata` | 成果物メタデータを操作します。 たとえば、 `artifact-metadata: write` は、ビルド成果物に代わってストレージ レコードを作成するアクションを許可します。 詳しくは、「[アーティファクト メタデータの REST API エンドポイント](/ja/rest/orgs/artifact-metadata?apiVersion=2022-11-28)」をご覧ください。 |\n\\|  |\n\\|  |\n\\|  `attestations` | 構成証明の認証作業 たとえば、 `attestations: write` ビルドの成果物構成証明を生成するアクションが許可されます。 詳細については、「[アーティファクトの構成証明を使用してビルドの出所を確立する](/ja/actions/security-guides/using-artifact-attestations-to-establish-provenance-for-builds)」を参照してください |\n\\|  |\n\\|  `checks` | チェック実行とチェック スイートを操作します。 たとえば、`checks: write` は、アクションによるチェック実行の作成を許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-checks)」をご覧ください。 |\n\\|  `contents` | リポジトリの内容を操作します。 たとえば、`contents: read` はアクションによるコミットの一覧表示を許可し、`contents: write` はアクションによるリリースの作成を許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-contents)」をご覧ください。 |\n\\|  `deployments` | デプロイを操作します。 たとえば、`deployments: write` は、アクションによる新しいデプロイの作成アクションを許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-deployments)」をご覧ください。 |\n\\|  `discussions` | GitHub ディスカッションで作業します。 たとえば、`discussions: write` は、アクションがディスカッションを閉じるか削除することを許可します。 詳しくは、「[ディスカッションでのGraphQL APIの利用](/ja/graphql/guides/using-the-graphql-api-for-discussions)」をご覧ください。 |\n\\|  |\n\\|  `id-token` | OpenID Connect (OIDC) トークンをフェッチします。 これには `id-token: write` が必要です。 詳細については、「[OpenID Connect](/ja/actions/deployment/security-hardening-your-deployments/about-security-hardening-with-openid-connect#updating-your-actions-for-oidc)」を参照してください |\n\\|  |\n\\|  `issues` | 問題に取り組みます。 たとえば、`issues: write` は、アクションがイシューにコメントを追加することを許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-issues)」をご覧ください。 |\n\\|  |\n\\|  `models`  | GitHub Models を使用して AI 推論応答を生成します。 たとえば、`models: read` は、GitHub Models 推論 API を使用するアクションを許可します。 「[AI モデルを使用したプロトタイプ作成](/ja/github-models/prototyping-with-ai-models)」を参照してください。 |\n\\|  |\n\\|  `packages` | GitHub Packages を操作します。 たとえば、`packages: write` は、アクションによる GitHub Packages でのパッケージのアップロードと発行を許可します。 詳しくは、「[GitHub Packagesの権限について](/ja/packages/learn-github-packages/about-permissions-for-github-packages#about-scopes-and-permissions-for-package-registries)」をご覧ください。 |\n\\|  `pages` | GitHub Pages を操作します。 たとえば、`pages: write` は、アクションによる GitHub Pages のビルドの要求を許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pages)」をご覧ください。 |\n\\|  `pull-requests` | pull request を操作します。 たとえば、`pull-requests: write` は、アクションによる pull request へのラベルの追加を許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-pull-requests)」をご覧ください。 |\n\\|  |\n\\|  `security-events` | GitHub のコード スキャン アラートを操作します。 たとえば、`security-events: read` を指定すると、アクションでリポジトリ内のコード スキャン アラートを一覧表示できるようになります。また、`security-events: write` を指定すると、アクションでコード スキャン アラートの状態を更新できるようになります。 詳細については、「[\"コード スキャン アラート\" に関するリポジトリのアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-code-scanning-alerts)」を参照してください。 <br><br> このアクセス許可では、Dependabot およびシークレット スキャン アラートを読み取ることができないため、GitHub App または personal access token が必要です。 詳細については、「GitHub Apps に必要なアクセス許可」の「[\"Dependabot アラート\" に関するリポジトリのアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-dependabot-alerts)」と「[\"シークレット スキャン アラート\" に関するリポジトリのアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-secret-scanning-alerts)」を参照してください。 |\n\\| `statuses` | コミットの状態を操作します。 たとえば、`statuses:read` は、アクションが特定の参照のコミット状態を一覧表示することを許可します。 詳しくは、「[GitHub Apps に必要なアクセス許可](/ja/rest/overview/permissions-required-for-github-apps?apiVersion=2022-11-28#repository-permissions-for-commit-statuses)」をご覧ください。 |\n\n###\n\n```\n          `GITHUB_TOKEN` スコープのアクセスの定義\n```\n\n`GITHUB_TOKEN` キー内で使用可能なアクセス許可の値として `read`、`write`、または `none` を指定することで、`permissions` が許可するアクセスを定義できます。\n\n```yaml\npermissions:\n  actions: read|write|none\n  artifact-metadata: read|write|none\n  attestations: read|write|none\n  checks: read|write|none\n  contents: read|write|none\n  deployments: read|write|none\n  id-token: write|none\n  issues: read|write|none\n  models: read|none\n  discussions: read|write|none\n  packages: read|write|none\n  pages: read|write|none\n  pull-requests: read|write|none\n  security-events: read|write|none\n  statuses: read|write|none\n```\n\nこれらのアクセス許可のいずれかにアクセスを指定すると、指定されていないすべてのアクセス許可が `none` に設定されます。\n\n利用可能なすべてのアクセス許可に対して `read-all` または `write-all` どちらかのアクセスを定義するには、以下の構文が使えます。\n\n```yaml\npermissions: read-all\n```\n\n```yaml\npermissions: write-all\n```\n\n次の構文を使用して、使用可能なすべてのアクセス許可のアクセス許可を無効にすることができます。\n\n```yaml\npermissions: {}\n```\n\n#### フォークされたリポジトリのアクセス許可を変更する\n\n`permissions` キーを使用して、フォークされたリポジトリの読み取り権限を追加および削除できますが、通常は書き込みアクセス権を付与することはできません。 この動作の例外としては、管理者ユーザーが GitHub Actions の設定で **\\[Send write tokens to workflows from pull requests]\\(pull request からワークフローに書き込みトークンを送信する)** を選択している場合があります。 詳しくは、「[リポジトリのGitHub Actions設定の管理](/ja/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#enabling-workflows-for-private-repository-forks)」をご覧ください。\n\n#### 例: ワークフロー内の 1 つのジョブに対する `GITHUB_TOKEN` アクセス許可の設定\n\nこの例は、`stale` という名前のジョブにのみ適用される `GITHUB_TOKEN` に設定されているアクセス許可を示しています。 書き込みアクセス権限は、`issues` アクセス許可と `pull-requests` アクセス許可に対して付与されます。 その他のすべてのアクセス許可にはアクセスが付与されません。\n\n```yaml\njobs:\n  stale:\n    runs-on: ubuntu-latest\n\n    permissions:\n      issues: write\n      pull-requests: write\n\n    steps:\n      - uses: actions/stale@v10\n```\n\n## `jobs.<job_id>.needs`\n\n`jobs.<job_id>.needs` を使って、このジョブの実行前に正常に完了する必要があるジョブを示します。 文字列型または文字列の配列です。 ジョブが失敗またはスキップされた場合、そのジョブを必要とするすべてのジョブは、そのジョブが継続する条件式を使っていない限り、スキップされます。 互いに必要とする一連のジョブが実行に含まれている場合、失敗またはスキップの時点から、依存関係チェーン内のすべてのジョブに失敗またはスキップが適用されます。 依存しているジョブが成功しなかった場合でもジョブを実行する場合は、`jobs.<job_id>.if` の`always()` 条件式を使用します。\n\n### 例: 依存ジョブの成功が必要である\n\n```yaml\njobs:\n  job1:\n  job2:\n    needs: job1\n  job3:\n    needs: [job1, job2]\n```\n\nこの例では、`job1` が正常に完了してから `job2` が始まる必要があり、`job3` では `job1` と `job2` の両方が完了するまで待機します。\n\nつまり、この例のジョブは逐次実行されるということです。\n\n1. `job1`\n2. `job2`\n3. `job3`\n\n### 例: 依存ジョブの成功は必要ではない\n\n```yaml\njobs:\n  job1:\n  job2:\n    needs: job1\n  job3:\n    if: ${{ always() }}\n    needs: [job1, job2]\n```\n\nこの例では、`job3` では条件式 `always()` を使っているので、`job1` と `job2` が成功したかどうかに関係なく、完了後に常に実行されます。 詳しくは、「[ワークフロー内とアクション内で式を評価する](/ja/actions/learn-github-actions/expressions#status-check-functions)」をご覧ください。\n\n## `jobs.<job_id>.if`\n\n`jobs.<job_id>.if` 条件文を使って、条件が満たされなければジョブを実行しないようにできます。 条件文を作成するには、サポートされている任意のコンテキストや式が使えます。 このキーでサポートされているコンテキストの詳細については、「[コンテキスト リファレンス](/ja/actions/learn-github-actions/contexts#context-availability)」を参照してください。\n\n> \\[!NOTE]\n> `jobs.<job_id>.if` 条件は、[`jobs.<job_id>.strategy.matrix`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategymatrix) が適用される前に評価されます。\n\n`if` 条件の中で式を使う際には、任意で式構文 `${{ }}` を省略できます。これは、GitHub Actions が `if` 条件を式として自動的に評価するためです。 ただし、この例外はどこでも適用されるわけではありません。\n\n`!` は YAML 形式で予約された表記であるため、必ず`${{ }}` 構文の式を使用するか、式が `!` で始まる場合は `''`、`\"\"`、または `()` でエスケープする必要があります。 次に例を示します。\n\n```yaml\nif: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n```\n\n詳しくは、「[ワークフロー内とアクション内で式を評価する](/ja/actions/learn-github-actions/expressions)」をご覧ください。\n\n### 例: 特定のリポジトリに対してのみジョブを実行する\n\nこの例では `if` を使って `production-deploy` ジョブを実行できるタイミングを制御しています。 リポジトリが `octo-repo-prod` という名前で、`octo-org` という組織内にある場合のみ実行されます。 それ以外の場合、ジョブはスキップ済みとしてマーク *されます*。\n\n```yaml copy\nname: example-workflow\non: [push]\njobs:\n  production-deploy:\n    if: github.repository == 'octo-org/octo-repo-prod'\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v5\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '14'\n      - run: npm install -g bats\n```\n\n## `jobs.<job_id>.runs-on`\n\n`jobs.<job_id>.runs-on` を使って、ジョブを実行するマシンの種類を定義します。\n\n* 宛先マシンには [、GitHubホステッド ランナー](#choosing-github-hosted-runners)、[より大きなランナー](#choosing-runners-in-a-group)、または[セルフホステッド ランナー](#choosing-self-hosted-runners)のいずれかを指定できます。\n\n- ランナーに割り当てられたラベル、グループ メンバーシップ、またはこれらの組み合わせに基づいてランナーをターゲットにすることができます。\n\n- `runs-on` は次として指定できます。\n  * 1 つの文字列\n  * 文字列を含む 1 つの変数\n  * 文字列の配列、文字列を含む変数、または両方の組み合わせ\n  * `group` または `labels` キーを使用する `key: value` ペア\n\n- 文字列または変数の配列を指定すると、指定された `runs-on` 値の全部に一致するランナー上でワークフローが実行されます。 たとえば、ここでは、ラベル `linux`、`x64`、`gpu` が付いているセルフホステッド ランナー上でのみジョブが実行されます。\n\n  ```yaml\n  runs-on: [self-hosted, linux, x64, gpu]\n  ```\n\n  詳細については、[自己ホストランナーの選択](#choosing-self-hosted-runners)に関する記事を参照してください。\n\n- 配列内で文字列と変数を混在させることができます。 次に例を示します。\n\n  ```yaml\n  on:\n    workflow_dispatch:\n      inputs:\n        chosen-os:\n          required: true\n          type: choice\n          options:\n          - Ubuntu\n          - macOS\n\n  jobs:\n    test:\n      runs-on: [self-hosted, \"${{ inputs.chosen-os }}\"]\n      steps:\n      - run: echo Hello world!\n  ```\n\n- 複数のマシンでワークフローを実行する場合は、[`jobs.<job_id>.strategy`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstrategy) を使います。\n\n> \\[!NOTE]\n> 引用符は、`self-hosted` のような単純な文字列には必要ありませんが、`\"${{ inputs.chosen-os }}\"` のような式には必要です。\n\n### GitHubホストランナーの選択\n\nGitHub ホステッド ランナーを使うと、各ジョブは `runs-on` で指定したランナー イメージの新しいインスタンスで実行されます。\n\nGitHub ホステッド ランナーを使用している場合の runs-on の値は、ランナー ラベルまたはランナー グループの名前が指定されます。 標準の GitHub ホステッド ランナーのラベルを次の表に示します。\n\n詳しくは、「[GitHub ホステッド ランナー](/ja/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners)」をご覧ください。\n\n### パブリック リポジトリ向けの標準 GitHub がホストするランナー\n\nパブリック リポジトリの場合、次の表に示すワークフロー ラベルを使用するジョブは、関連する仕様で実行されます。 単一CPUランナーを除き、各GitHubホストランナーは、GitHub によってホストされる新しい仮想マシン（VM）です。 Single-CPUランナーは、共有VM上のコンテナー内でホストされます。[GitHub ホステッド ランナー リファレンス](/ja/actions/reference/runners/github-hosted-runners#single-cpu-runners)を参照してください。 標準 GitHub がホストするランナーは、パブリック リポジトリでは無料で無制限です。\n\n<table style=\"width:100%\">\n  <thead>\n    <tr>\n      <th scope=\"col\">\n              <b>仮想マシン/コンテナー</b></th>\n      <th scope=\"col\">\n              <b>プロセッサ (CPU)</b></th>\n      <th scope=\"col\">\n              <b>メモリ (RAM)</b></th>\n      <th scope=\"col\">\n              <b>ストレージ (SSD)</b></th>\n      <th scope=\"col\">\n              <b>Architecture</b></th>\n      <th scope=\"col\">\n              <b>ワークフロー ラベル</b></th>\n    </tr>\n  </thead>\n  <tbody>\n    <tr>\n          <td>Linux</td>\n          <td>1</td>\n          <td>5 GB</td>\n          <td>14 GB</td>\n          <td> x64 </td>\n          <td>\n            <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu-slim/ubuntu-slim-Readme.md\">ubuntu-slim</a></code>\n          </td>\n        </tr>\n    <tr>\n      <td><tr>\n      <td>Linux</td>\n      <td>1</td>\n      <td>5 GB</td>\n      <td>14 GB</td>\n      <td> x64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu-slim/ubuntu-slim-Readme.md\">ubuntu-slim</a></code>\n      </td>\n    </tr></td>\n      <td>Linux</td>\n      <td>4</td>\n      <td>16 GB</td>\n      <td> 14 GB </td>\n      <td>x64</td>\n    </tr>\n    <tr>\n      <td>\n\n```\n    <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md\">ubuntu-latest</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md\">ubuntu-24.04</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md\">ubuntu-22.04</a></code></td>\n  <td>Windows</td>\n  <td>4</td>\n  <td>16 GB</td>\n  <td> 14 GB </td>\n  <td>x64</td>\n</tr>\n<tr>\n  <td>\n          \n    <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md\">windows-latest</a></code>、<code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md\">windows-2025</a></code>、<code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-VS2026-Readme.md\">windows-2025-vs2026</a></code> (パブリック プレビュー) <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md\">windows-2022</a></code></td>\n  <td>Linux</td>\n  <td>4</td>\n  <td>16 GB</td>\n  <td> 14 GB </td>\n  <td>arm64</td>\n</tr>\n<tr>\n  <td>\n          \n    <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md\">ubuntu-24.04-arm</a></code>, <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-22-image.md\">ubuntu-22.04-arm</a></code></td>\n  <td>Windows</td>\n  <td>4</td>\n  <td>16 GB</td>\n  <td>14 GB</td>\n  <td>\n    <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-windows-11-image.md\">windows-11-arm</a></code>\n  </td>\n</tr>\n<tr>\n  <td>arm64</td>\n  <td>macOS</td>\n  <td>4</td>\n  <td>14 GB</td>\n  <td> 14 GB </td>\n  <td>Intel</td>\n</tr>\n<tr>\n  <td>\n          \n    <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md\">macos-15-intel</a></code>, <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-26-Readme.md\">macos-26-intel</a></code></td>\n  <td>macOS</td>\n  <td>3 (M1)</td>\n  <td>7 GB</td>\n  <td> 14 GB </td>\n  <td>arm64</td>\n</tr>\n```\n\n  </tbody>\n\n</table>\n\n###\n\n```\n    <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md\">macos-latest</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-14-arm64-Readme.md\">macos-14</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-arm64-Readme.md\">macos-15</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-26-arm64-Readme.md\">macos-26</a></code>\n```\n\nプライベート リポジトリの標準の GitHub でホストされたランナー  プライベート リポジトリの場合、以下のテーブルに表示されるワークフロー ラベルを使用するジョブは、関連する仕様に沿った仮想マシンで実行されます。 これらのランナーは、GitHub アカウントの無料の分の割り当てを使用し、分単位の料金で課金されます。\n\n<table style=\"width:100%\">\n  <thead>\n    <tr>\n      <th scope=\"col\">「[AUTOTITLE](/billing/reference/actions-minute-multipliers)」を参照してください。</th>\n      <th scope=\"col\">\n              <b>仮想マシン</b></th>\n      <th scope=\"col\">\n              <b>プロセッサ (CPU)</b></th>\n      <th scope=\"col\">\n              <b>メモリ (RAM)</b></th>\n      <th scope=\"col\">\n              <b>ストレージ (SSD)</b></th>\n      <th scope=\"col\">\n              <b>Architecture</b></th>\n    </tr>\n  </thead>\n  <tbody>\n    <tr>\n          <td>Linux</td>\n          <td>1</td>\n          <td>5 GB</td>\n          <td>14 GB</td>\n          <td> x64 </td>\n          <td>\n            <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu-slim/ubuntu-slim-Readme.md\">ubuntu-slim</a></code>\n          </td>\n        </tr>\n    <tr>\n      <td>\n              <b>ワークフロー ラベル</b></td>\n      <td><tr>\n      <td>Linux</td>\n      <td>1</td>\n      <td>5 GB</td>\n      <td>14 GB</td>\n      <td> x64 </td>\n      <td>\n        <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu-slim/ubuntu-slim-Readme.md\">ubuntu-slim</a></code>\n      </td>\n    </tr></td>\n      <td>Linux</td>\n      <td>2</td>\n      <td> 8 GB </td>\n      <td>14 GB</td>\n    </tr>\n    <tr>\n      <td>x64</td>\n      <td>\n\n```\n    <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md\">ubuntu-latest</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2404-Readme.md\">ubuntu-24.04</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/ubuntu/Ubuntu2204-Readme.md\">ubuntu-22.04</a></code></td>\n  <td>Windows</td>\n  <td>2</td>\n  <td> 8 GB </td>\n  <td>14 GB</td>\n</tr>\n<tr>\n  <td>x64</td>\n  <td>\n          \n    <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md\">windows-latest</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2025-Readme.md\">windows-2025</a></code>、 <code><a href=\"https://github.com/actions/runner-images/blob/main/images/windows/Windows2022-Readme.md\">windows-2022</a></code></td>\n  <td>Linux</td>\n  <td>2</td>\n  <td> 8 GB </td>\n  <td>14 GB</td>\n</tr>\n<tr>\n  <td>arm64</td>\n  <td>\n          \n    <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-24-image.md\">ubuntu-24.04-arm</a></code>, <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-ubuntu-22-image.md\">ubuntu-22.04-arm</a></code></td>\n  <td>Windows</td>\n  <td>2</td>\n  <td> 8 GB </td>\n  <td>\n    <code><a href=\"https://github.com/actions/partner-runner-images/blob/main/images/arm-windows-11-image.md\">windows-11-arm</a></code>\n  </td>\n</tr>\n<tr>\n  <td>14 GB</td>\n  <td>arm64</td>\n  <td>macOS</td>\n  <td>4</td>\n  <td> 14 GB </td>\n  <td>14 GB</td>\n</tr>\n<tr>\n  <td>Intel</td>\n  <td>\n          \n    <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-15-Readme.md\">macos-15-intel</a></code>, <code><a href=\"https://github.com/actions/runner-images/blob/main/images/macos/macos-26-Readme.md\">macos-26-intel</a></code></td>\n  <td>macOS</td>\n  <td>3 (M1)</td>\n  <td> 7 GB </td>\n  <td>14 GB</td>\n</tr>\n```\n\n  </tbody>\n</table>\n\n標準の GitHub ホステッド ランナーに加えて、GitHub では、GitHub Team プランとGitHub Enterprise Cloud プランのお客様に、より多くのコアとディスク領域、GPU 搭載マシン、ARM 搭載マシンなどの高度な機能を備えたさまざまなマネージド仮想マシンを用意しています。 詳しくは、「[より大きなランナー](/ja/actions/using-github-hosted-runners/about-larger-runners/about-larger-runners)」をご覧ください。\n\n> \\[!NOTE]\n> `-latest` ランナー イメージは、GitHub が提供する最新の安定したイメージであり、オペレーティング システム ベンダーから入手できるオペレーティング システムの最新バージョンではない可能性があります。\n\n> \\[!WARNING]\n> ベータ版および非推奨のイメージは、\"現状のまま\"、\"保証なし\"、\"利用可能な状態\" で提供され、サービス レベル アグリーメントと保証から除外されます。 ベータ版のイメージは、カスタマー サポートでカバーされない場合があります。\n\n#### 例: オペレーティング システムの指定\n\n```yaml\nruns-on: ubuntu-latest\n```\n\n詳しくは、「[GitHub ホステッド ランナー](/ja/actions/using-github-hosted-runners/about-github-hosted-runners)」をご覧ください。\n\n### セルフホステッド ランナーの選択\n\nジョブにセルフホステッド ランナーを指定するには、ワークフロー ファイルでセルフホステッド ランナーのラベルを使って `runs-on` を設定します。\n\nセルフホステッド ランナーには `self-hosted` ラベルが付いている場合があります。 セルフホステッド ランナーを設定すると、既定では `self-hosted` ラベルが付与されます。\n`--no-default-labels` フラグを渡すことでセルフホステッド ラベルが適用されないように設定できます。 ラベルを使用すると、オペレーティング システムやアーキテクチャなど、特定のランナーを探すオプションを作成できます。`self-hosted` で始まり (リストの最初にこれを示す必要があります)、必要に応じて追加のラベルを含むラベルの配列を指定することをお勧めします。 ラベルの配列を指定すると、指定したラベルをすべて持つランナーのキューにジョブが配置されます。\n\n> \\[!NOTE] Actions Runner Controller は、 `self-hosted` ラベルをサポートしていません。\n\n#### 例: ランナー選択のためのラベルの使用\n\n```yaml\nruns-on: [self-hosted, linux]\n```\n\n詳細については、「[セルフホステッド ランナー](/ja/actions/hosting-your-own-runners/managing-self-hosted-runners/about-self-hosted-runners)」および「[ワークフローでのセルフホステッド ランナーの利用](/ja/actions/hosting-your-own-runners/managing-self-hosted-runners/using-self-hosted-runners-in-a-workflow)」を参照してください。\n\n### グループ内のランナーを選ぶ\n\n`runs-on` を使用してランナー グループをターゲットにして、そのグループのメンバーである任意のランナーでジョブが実行されるようにすることができます。 よりきめ細かく制御するには、ランナー グループとラベルを組み合わせることもできます。\n\nランナー グループは、[より大きなランナー](/ja/actions/using-github-hosted-runners/using-larger-runners/about-larger-runners) または[セルフホステッド ランナー](/ja/actions/how-tos/managing-self-hosted-runners)のみをメンバーとして持つことができます。\n\n#### 例: グループを使用してジョブの実行場所を制御する\n\nこの例では、Ubuntu ランナーが `ubuntu-runners` というグループに追加されています。 `runs-on` キーは、`ubuntu-runners` グループ内の使用可能なランナーにジョブを送信します。\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n  check-bats-version:\n    runs-on: \n      group: ubuntu-runners\n    steps:\n      - uses: actions/checkout@v5\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '14'\n      - run: npm install -g bats\n      - run: bats -v\n```\n\n#### 例: グループとラベルの組み合わせ\n\nグループとラベルを組み合わせる場合、ランナーはジョブを実行する資格を得るために両方の要件を満たす必要があります。\n\nこの例では、`ubuntu-runners` というランナー グループに、ラベル `ubuntu-24.04-16core` も割り当てられている Ubuntu ランナーが設定されています。\n`runs-on` キーは `group` と `labels` を組み合わせて、ラベルが一致するグループ内の使用可能な任意のランナーにジョブがルーティングされるようにします。\n\n```yaml\nname: learn-github-actions\non: [push]\njobs:\n  check-bats-version:\n    runs-on:\n      group: ubuntu-runners\n      labels: ubuntu-24.04-16core\n    steps:\n      - uses: actions/checkout@v5\n      - uses: actions/setup-node@v4\n        with:\n          node-version: '14'\n      - run: npm install -g bats\n      - run: bats -v\n```\n\n## `jobs.<job_id>.snapshot`\n\n`jobs.<job_id>.snapshot`を使用してカスタム イメージを生成できます。\n\n```\n          [「カスタム イメージの生成](/actions/how-tos/manage-runners/larger-runners/use-custom-images#generating-a-custom-image)」に示すように、文字列構文またはマッピング構文を使用して、スナップショット キーワードをジョブに追加します。\n```\n\nスナップショット キーワードを含む各ジョブは、個別のイメージを作成します。 1 つのイメージまたはイメージ バージョンのみを生成するには、すべてのワークフロー ステップを 1 つのジョブに含めます。 スナップショット キーワードを含むジョブが正常に実行されるたびに、そのイメージの新しいバージョンが作成されます。\n\n詳しくは、「[カスタム イメージの使用](/ja/actions/how-tos/manage-runners/larger-runners/use-custom-images)」をご覧ください。\n\n## `jobs.<job_id>.environment`\n\nジョブが参照する環境を定義するには、`jobs.<job_id>.environment` を使います。\n\n環境 `name` のみ、または `name` と `url` を含む環境オブジェクトという形式で環境を指定できます。 URL はデプロイ API の `environment_url` にマップされます。 配置 API の詳細については、「[リポジトリの REST API エンドポイント](/ja/rest/repos#deployments)」を参照してください。\n\n> \\[!NOTE]\n> 環境を参照するジョブがランナーに送られる前に、その環境のすべてのデプロイ保護ルールをパスしなければなりません。 詳しくは、「[デプロイメント用の環境管理](/ja/actions/deployment/targeting-different-environments/managing-environments-for-deployment)」をご覧ください。\n\n### 例: 1 つの環境名を使う\n\n```yaml\nenvironment: staging_environment\n```\n\n### 例: 環境名と URL を使う\n\n```yaml\nenvironment:\n  name: production_environment\n  url: https://github.com\n```\n\n`url` の値には式を指定できます。 使用できる式コンテキスト: [`github`](/ja/actions/learn-github-actions/contexts#github-context)、[`inputs`](/ja/actions/learn-github-actions/contexts#inputs-context)、[`vars`](/ja/actions/learn-github-actions/contexts#vars-context)、[`needs`](/ja/actions/learn-github-actions/contexts#needs-context)、[`strategy`](/ja/actions/learn-github-actions/contexts#strategy-context)、[`matrix`](/ja/actions/learn-github-actions/contexts#matrix-context)、[`job`](/ja/actions/learn-github-actions/contexts#job-context)、[`runner`](/ja/actions/learn-github-actions/contexts#runner-context)、[`env`](/ja/actions/learn-github-actions/contexts#env-context)、および [`steps`](/ja/actions/learn-github-actions/contexts#steps-context)。 式の詳細については、「[ワークフロー内とアクション内で式を評価する](/ja/actions/learn-github-actions/expressions)」を参照してください。\n\n### 例: 出力を URL として使う\n\n```yaml\nenvironment:\n  name: production_environment\n  url: ${{ steps.step_id.outputs.url_output }}\n```\n\n`name` の値には式を指定できます。 使用できる式コンテキスト: [`github`](/ja/actions/learn-github-actions/contexts#github-context)、[`inputs`](/ja/actions/learn-github-actions/contexts#inputs-context)、[`vars`](/ja/actions/learn-github-actions/contexts#vars-context)、[`needs`](/ja/actions/learn-github-actions/contexts#needs-context)、[`strategy`](/ja/actions/learn-github-actions/contexts#strategy-context)、[`matrix`](/ja/actions/learn-github-actions/contexts#matrix-context)。 式の詳細については、「[ワークフロー内とアクション内で式を評価する](/ja/actions/learn-github-actions/expressions)」を参照してください。\n\n### 例: 環境名として式を使用する\n\n```yaml\nenvironment:\n  name: ${{ github.ref_name }}\n```\n\n## `jobs.<job_id>.concurrency`\n\n同じコンカレンシー グループを使うジョブまたはワークフローを一度に 1 つだけ実行するには、`jobs.<job_id>.concurrency` を使います。 並行処理グループには、任意の文字列または式を使用できます。 使用できる式コンテキスト: [`github`](/ja/actions/learn-github-actions/contexts#github-context)、[`inputs`](/ja/actions/learn-github-actions/contexts#inputs-context)、[`vars`](/ja/actions/learn-github-actions/contexts#vars-context)、[`needs`](/ja/actions/learn-github-actions/contexts#needs-context)、[`strategy`](/ja/actions/learn-github-actions/contexts#strategy-context)、[`matrix`](/ja/actions/learn-github-actions/contexts#matrix-context)。 式の詳細については、「[ワークフロー内とアクション内で式を評価する](/ja/actions/learn-github-actions/expressions)」を参照してください。\n\nワークフロー レベルで `concurrency` を指定することもできます。 詳細については、「[`concurrency`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#concurrency)」を参照してください。\n\nつまり、コンカレンシー グループには、最大 1 つの実行ジョブと 1 つの保留中のジョブが存在できることを意味します。 並行ジョブかワークフローがキューに入っている場合、リポジトリ内の同じ並行グループを使う他のジョブかワークフローが進行中だと、キューイングされたジョブかワークフローは `pending` になります。 同じコンカレンシー グループ内の既存の `pending` ジョブまたはワークフロー (存在する場合) は取り消され、キューに登録された新規ジョブまたはワークフローがその代わりに使用されます。\n\n同じコンカレンシー グループ内の現在実行中のジョブかワークフローもキャンセルするには、`cancel-in-progress: true` を指定します。 同じコンカレンシー グループ内で現在実行中のジョブまたはワークフローを条件付きで取り消すには、許可されている式コンテキストのいずれかを含む式として `cancel-in-progress` を指定 できます。\n\n> \\[!NOTE]\n>\n> * コンカレンシー グループ名では大文字と小文字が区別されません。 たとえば、`prod` と `Prod` は同じコンカレンシー グループとして扱われます。\n> * コンカレンシー グループを使用したジョブまたはワークフローでは、実行の順序付けは保証されません。 同じコンカレンシー グループ内のジョブまたはワークフローは、任意の順序で処理されます。\n\n### 例：コンカレンシーとデフォルトビヘイビアーの使用\n\nGitHub Actions のデフォルトビヘイビアーでは、複数のジョブまたはワークフロー実行を同時開催で実行できます。 `concurrency` キーワード を使用すると、ワークフロー実行のコンカレンシーを制御できます。\n\nたとえば、トリガー条件が定義された直後に`concurrency`キーワード を使用して、特定のブランチに対するワークフロー実行全体のコンカレンシーを制限できます：\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\nジョブ レベルで`concurrency`キーワード を使用して、ワークフロー内のジョブのコンカレンシーを制限することもできます：\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: example-group\n      cancel-in-progress: true\n```\n\n### 例: コンカレンシー グループ\n\nコンカレンシー グループは、同じコンカレンシー 鍵を共有するワークフロー実行またはジョブの実行を管理および制限する方法を提供します。\n\n`concurrency` 鍵は、ワークフローまたはジョブをまとめてコンカレンシー グループにグループ化するために使用されます。 `concurrency`鍵を定義すると、GitHub Actions によって、その鍵を持つワークフローまたはジョブが常に 1 つだけ実行されるようになります。 新しいワークフローの実行またはジョブが同じ `concurrency` 鍵で開始された場合、GitHub Actions はその鍵で既に実行されているワークフローまたはジョブをキャンセルします。 `concurrency`鍵は 、ハードコーディングされた文字列にすることも、コンテキスト変数を含む動的な式にすることもできます。\n\nワークフローまたはジョブがコンカレンシー グループの一部になるように、ワークフローでコンカレンシー条件を定義できます。\n\nつまり、ワークフローの実行またはジョブが開始されると、GitHub は、同じコンカレンシー グループで既に進行状況にあるワークフローの実行またはジョブをキャンセルします。 これは、競合を引き起こしたり、必要以上に多くのリソースを消費したりする可能性のある処置を防ぐために、ステージング環境への展開に使用されるワークフローやジョブの特定のセットに対する並列実行を防ぐ場合に便利です。\n\nこの例では、 `job-1`は、`staging_environment`と名付けられたコンカレンシー グループの一部です。 つまり、新しい`job-1` の実行がトリガーされると、既に進行状況の `staging_environment`コンカレンシー グループ内の同じジョブの実行はすべてキャンセルされます。\n\n```yaml\njobs:\n  job-1:\n    runs-on: ubuntu-latest\n    concurrency:\n      group: staging_environment\n      cancel-in-progress: true\n```\n\nまたは、ワークフロー内などの `concurrency: ci-${{ github.ref }}`のような 動的な式を使用すると、ワークフローまたはジョブは、ワークフローをトリガーしたブランチまたはタグのリファレンスに続く `ci-`と名付けられたコンカレンシー グループの一部になります。 この例では、前の実行の進行中に新しいコミットが メイン ブランチにプッシュされた場合、前の実行はキャンセルされ、新しいコミットが開始されます：\n\n```yaml\non:\n  push:\n    branches:\n      - main\n\nconcurrency:\n  group: ci-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### 並行性を使って進行中のジョブもしくは実行をキャンセルする例\n\nコンカレンシーを使用して進行状況のジョブをキャンセルするか、GitHub Actions で実行するには、`concurrency`鍵を使用でき、次の`cancel-in-progress`オプションを`true`に設定します：\n\n```yaml\nconcurrency:\n  group: ${{ github.ref }}\n  cancel-in-progress: true\n```\n\nこの例では、特定のコンカレンシー グループを定義せずに、GitHub Actions はジョブまたはワークフローの\\_どんな\\_進行状況の実行もキャンセルします。\n\n### 例: フォールバック値の使用\n\n特定のイベントにのみ定義されるプロパティでグループ名を作成する場合、フォールバック値を使用できます。 たとえば、`github.head_ref` は `pull_request` イベントにのみ定義されます。 ワークフローが `pull_request` イベントに加えて他のイベントにも応答する場合、構文エラーを回避するためにフォールバックを指定する必要があります。 次のコンカレンシー グループは、`pull_request` イベントで進行中のジョブか実行のみを取り消します。`github.head_ref` が未定義の場合、コンカレンシー グループは実行 ID にフォールバックします。これは、一意であり、実行に対して定義されていることが保証されています。\n\n```yaml\nconcurrency:\n  group: ${{ github.head_ref || github.run_id }}\n  cancel-in-progress: true\n```\n\n### 例: 現在のワークフローで進行中のジョブまたは実行のみを取り消します\n\n同じリポジトリに複数のワークフローがある場合、他のワークフローの進行中のジョブまたは実行が取り消されないように、コンカレンシー グループ名はワークフロー間で一意である必要があります。 そうでない場合、ワークフローに関係なく、以前に進行中または保留中のジョブが取り消されます。\n\n同じワークフローの進行中の実行だけを取り消すには、`github.workflow` プロパティを使ってコンカレンシー グループを構築します。\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: true\n```\n\n### 例: 特定のブランチで進行中のジョブのみを取り消す\n\n特定のブランチで進行中のジョブを取り消したいが、他のブランチでは取り消さない場合は、`cancel-in-progress` で条件式を使用できます。 たとえば、開発ブランチでは進行中のジョブを取り消したいが、リリース ブランチでは取り消さない場合に、これを行うことができます。\n\nリリース ブランチで実行されていない場合に、同じワークフローの進行中の実行のみを取り消すには、`cancel-in-progress` を次のような式に設定します。\n\n```yaml\nconcurrency:\n  group: ${{ github.workflow }}-${{ github.ref }}\n  cancel-in-progress: ${{ !contains(github.ref, 'release/')}}\n```\n\nこの例では、`release/1.2.3` ブランチへの複数のプッシュは進行中の実行を取り消しません。 `main` などの別のブランチにプッシュすると、進行中の実行が取り消されます。\n\n## `jobs.<job_id>.outputs`\n\n`jobs.<job_id>.outputs` を使って、ジョブの出力の `map` を作成できます。 ジョブの出力は、そのジョブに依存しているすべての下流のジョブから利用できます。 ジョブ依存関係の定義の詳細については、「[`jobs.<job_id>.needs`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds)」を参照してください。\n\n出力は、1 つのジョブにつき最大 1 MB です。 ワークフロー実行内のすべての出力の合計は、最大 50 MB です。 サイズは UTF-16 エンコードに基づいて概算されます。\n\n表現が含まれているジョブの出力は、各ジョブの終了時にランナー上で評価されます。 シークレットを含む出力はランナー上で編集され、GitHub Actionsには送られません。\n\n出力に秘密情報が含まれる可能性があるためスキップされた場合、「秘密情報が含まれる可能性があるため出力`{output.Key}`をスキップする」という警告メッセージが表示されます。 秘密情報の取り扱い方法の詳細については、「[例:ジョブまたはワークフロー間で秘密情報をマスクおよび受け渡しする方法](/ja/actions/writing-workflows/choosing-what-your-workflow-does/workflow-commands-for-github-actions#example-masking-and-passing-a-secret-between-jobs-or-workflows)」を参照してください。\n\n依存するジョブでジョブ出力を使うには、`needs` コンテキストを使用できます。 詳しくは、「[コンテキスト リファレンス](/ja/actions/learn-github-actions/contexts#needs-context)」をご覧ください。\n\n### 例: ジョブの出力の定義\n\n```yaml\njobs:\n  job1:\n    runs-on: ubuntu-latest\n    # Map a step output to a job output\n    outputs:\n      output1: ${{ steps.step1.outputs.test }}\n      output2: ${{ steps.step2.outputs.test }}\n    steps:\n      - id: step1\n        run: echo \"test=hello\" >> \"$GITHUB_OUTPUT\"\n      - id: step2\n        run: echo \"test=world\" >> \"$GITHUB_OUTPUT\"\n  job2:\n    runs-on: ubuntu-latest\n    needs: job1\n    steps:\n      - env:\n          OUTPUT1: ${{needs.job1.outputs.output1}}\n          OUTPUT2: ${{needs.job1.outputs.output2}}\n        run: echo \"$OUTPUT1 $OUTPUT2\"\n```\n\n### マトリックス ジョブでのジョブ出力の使用\n\nマトリックスを使用して、異なる名前の複数の出力を生成できます。 マトリックスを使用する場合、ジョブ出力はマトリックス内のすべてのジョブから結合されます。\n\n```yaml\njobs:\n  job1:\n    runs-on: ubuntu-latest\n    outputs:\n      output_1: ${{ steps.gen_output.outputs.output_1 }}\n      output_2: ${{ steps.gen_output.outputs.output_2 }}\n      output_3: ${{ steps.gen_output.outputs.output_3 }}\n    strategy:\n      matrix:\n        version: [1, 2, 3]\n    steps:\n      - name: Generate output\n        id: gen_output\n        run: |\n          version=\"${{ matrix.version }}\"\n          echo \"output_${version}=${version}\" >> \"$GITHUB_OUTPUT\"\n  job2:\n    runs-on: ubuntu-latest\n    needs: [job1]\n    steps:\n      # Will show\n      # {\n      #   \"output_1\": \"1\",\n      #   \"output_2\": \"2\",\n      #   \"output_3\": \"3\"\n      # }\n      - run: echo '${{ toJSON(needs.job1.outputs) }}'\n```\n\n> \\[!WARNING]\n> アクションは、マトリックス ジョブの実行順序を保証するものではありません。 出力名が一意であることを確認します。一意でない場合、実行する最後のマトリックス ジョブによって出力値がオーバーライドされます。\n\n## `jobs.<job_id>.env`\n\nジョブ中のすべてのステップで使うことができる変数の `map` です。 ワークフロー全体または個々のステップの変数を設定できます。 詳細については、[`env`](#env) および [`jobs.<job_id>.steps[*].env`](#jobsjob_idstepsenv) を参照してください。\n\n同じ名前で複数の環境変数が定義されている場合、GitHub では最も具体的な変数を使用します。 たとえば、ステップ中で定義された環境変数は、ジョブやワークフローの同じ名前の環境変数をステップの実行の間オーバーライドします。 ジョブで定義された環境変数は、そのジョブの実行の間はワークフローの同じ名前の変数をオーバーライドします。\n\n###\n\n```\n          `jobs.<job_id>.env` の例\n```\n\n```yaml\njobs:\n  job1:\n    env:\n      FIRST_NAME: Mona\n```\n\n## `jobs.<job_id>.defaults`\n\n`jobs.<job_id>.defaults` を使用して、デフォルト設定の `map` を作成します。これは、ジョブ内のすべてのシェルに適用されます。 ワークフロー全体に対してデフォルト設定を設定することもできます。 詳細については、「[`defaults`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#defaults)」を参照してください。\n\n同じ名前で複数のデフォルトの設定が定義されている場合、GitHubは最も具体的なデフォルト設定を使用します。 たとえば、ジョブで定義されたデフォルト設定は、同じ名前を持つワークフローで定義されたデフォルト設定をオーバーライドします。\n\n## `jobs.<job_id>.defaults.run`\n\n`jobs.<job_id>.defaults.run` を使用して、ジョブ内のすべての `run` ステップに既定の `shell` と `working-directory` を指定します。\n\nジョブ内のすべての [`run`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsrun) ステップに既定の `shell` と `working-directory` のオプションを指定できます。 また、ワークフロー全体の `run` に既定の設定を設定することもできます。 詳細については、「[`defaults.run`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrun)」を参照してください。\n\nこれらは、`jobs.<job_id>.defaults.run` と `jobs.<job_id>.steps[*].run` のレベルでオーバーライドできます。\n\n同じ名前で複数のデフォルトの設定が定義されている場合、GitHubは最も具体的なデフォルト設定を使用します。 たとえば、ジョブで定義されたデフォルト設定は、同じ名前を持つワークフローで定義されたデフォルト設定をオーバーライドします。\n\n## `jobs.<job_id>.defaults.run.shell`\n\n`shell` を使用してステップの `shell` を定義します。 このキーワードは、複数のコンテキストを参照できます。 詳細については、「[コンテキスト](/ja/actions/learn-github-actions/contexts#context-availability)」を参照してください。\n\n| サポートされているプラットフォーム | `shell` パラメーター | 説明                                                                                                                                                                               | 内部で実行されるコマンド                                    |\n| ----------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux/macOS       | unspecified    | Windows 以外のプラットフォームの既定のシェル。 これにより、`bash` を明示的に指定した場合とは異なるコマンドが実行されることに注意してください。 `bash` がパスに見つからない場合、これは `sh` のように扱われます。                                                          | `bash -e {0}`                                   |\n| すべて               | `bash`         | `sh` へのフォールバックが設定された、Windows 以外のプラットフォームの既定のシェル。 Windowsでbashシェルを指定すると、Windows用Gitに含まれるbashシェルが使用されます。                                                                           | `bash --noprofile --norc -eo pipefail {0}`      |\n| すべて               | `pwsh`         | PowerShell Coreです。 GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。                                                                                                                         | `pwsh -command \". '{0}'\"`                       |\n| すべて               | `python`       | Pythonのコマンドを実行します。                                                                                                                                                               | `python {0}`                                    |\n| Linux/macOS       | `sh`           | Windows 以外のプラットフォームにおいて、シェルが提供されておらず、パスで `bash` が見つからなかった場合のフォールバック動作。                                                                                                           | `sh -e {0}`                                     |\n| Windows           | `cmd`          | GitHub によってスクリプト名に拡張子 `.cmd` が追加され、`{0}` が置き換えられます。                                                                                                                              | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows           | `pwsh`         | これはWindowsで使われるデフォルトのシェルです。 PowerShell Coreです。 GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。 セルフホステッド Windows ランナーに *PowerShell Core* がインストールされていない場合は、代わりに *PowerShell Desktop* が使われます。 | `pwsh -command \". '{0}'\"`.                      |\n| Windows           | `powershell`   | PowerShell Desktop. GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。                                                                                                                        | `powershell -command \". '{0}'\"`.                |\n\n同じ名前で複数のデフォルトの設定が定義されている場合、GitHubは最も具体的なデフォルト設定を使用します。 たとえば、ジョブで定義されたデフォルト設定は、同じ名前を持つワークフローで定義されたデフォルト設定をオーバーライドします。\n\n## `jobs.<job_id>.defaults.run.working-directory`\n\n`working-directory` を使用してステップの `shell` の作業ディレクトリを定義します。 このキーワードは、複数のコンテキストを参照できます。 詳細については、「[コンテキスト](/ja/actions/learn-github-actions/contexts#context-availability)」を参照してください。\n\n> \\[!TIP]\n> その中でシェルを実行する前に、割り当てる `working-directory` がランナーに存在することを確認してください。同じ名前で複数のデフォルトの設定が定義されている場合、GitHubは最も具体的なデフォルト設定を使用します。 たとえば、ジョブで定義されたデフォルト設定は、同じ名前を持つワークフローで定義されたデフォルト設定をオーバーライドします。\n\n### 例: ジョブの既定の `run` ステップ オプションの設定\n\n```yaml\njobs:\n  job1:\n    runs-on: ubuntu-latest\n    defaults:\n      run:\n        shell: bash\n        working-directory: ./scripts\n```\n\n## `jobs.<job_id>.steps`\n\n1 つのジョブには、`steps` と呼ばれる一連のタスクがあります。 ステップでは、コマンドを実行する、設定タスクを実行する、あるいはリポジトリやパブリックリポジトリ、Dockerレジストリで公開されたアクションを実行することができます。 すべてのステップでアクションを実行するとは限りませんが、すべてのアクションはステップとして実行されます。 各ステップは、ランナー環境のそれ自体のプロセスで実行され、ワークスペースとファイルシステムにアクセスします。 ステップはそれ自体のプロセスで実行されるため、環境変数を変更しても、ステップ間では反映されません。\nGitHub には、ジョブを設定して完了するための組み込みの手順が用意されています。\n\n```\n          GitHub 最初の 1,000 個のチェックのみが表示されますが、ワークフローの使用制限内であれば、無制限の数のステップを実行できます。 詳細については、[](/actions/learn-github-actions/usage-limits-billing-and-administration)ホストランナーの GitHub とセルフホステッド ランナーの使用制限に関する [AUTOTITLE](/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) を参照してください。\n```\n\n###\n\n```\n          `jobs.<job_id>.steps` の例\n```\n\n```yaml\nname: Greeting from Mona\n\non: push\n\njobs:\n  my-job:\n    name: My Job\n    runs-on: ubuntu-latest\n    steps:\n      - name: Print a greeting\n        env:\n          MY_VAR: Hi there! My name is\n          FIRST_NAME: Mona\n          MIDDLE_NAME: The\n          LAST_NAME: Octocat\n        run: |\n          echo $MY_VAR $FIRST_NAME $MIDDLE_NAME $LAST_NAME.\n```\n\n## `jobs.<job_id>.steps[*].id`\n\nステップの一意の識別子。\n`id` を使って、コンテキストのステップを参照することができます。 詳しくは、「[コンテキスト リファレンス](/ja/actions/learn-github-actions/contexts)」をご覧ください。\n\n## `jobs.<job_id>.steps[*].if`\n\n````\n          `if` 条件文を使って、条件が満たされなければ、ステップを実行しないようにすることができます。 条件文を作成するには、サポートされている任意のコンテキストや式が使えます。 このキーでサポートされているコンテキストの詳細については、「[AUTOTITLE](/actions/learn-github-actions/contexts#context-availability)」を参照してください。\n\n          `if` 条件の中で式を使う際には、任意で式構文 `${{ }}` を省略できます。これは、GitHub Actions が `if` 条件を式として自動的に評価するためです。 ただし、この例外はどこでも適用されるわけではありません。\n          \n          `!` は YAML 形式で予約された表記であるため、必ず`${{ }}` 構文の式を使用するか、式が `!` で始まる場合は `''`、`\"\"`、または `()` でエスケープする必要があります。 次に例を示します。\n          \n          \n          \n          ```yaml\n          if: ${{ ! startsWith(github.ref, 'refs/tags/') }}\n          ```\n          \n           詳細については、 [AUTOTITLE を](/actions/learn-github-actions/expressions)参照してください。\n````\n\n### 例: コンテキストの使用\n\nこのステップは、イベントの種類が `pull_request` で、イベント アクションが `unassigned` である場合にのみ実行されます。\n\n```yaml\nsteps:\n  - name: My first step\n    if: ${{ github.event_name == 'pull_request' && github.event.action == 'unassigned' }}\n    run: echo This event is a pull request that had an assignee removed.\n```\n\n### 例: ステータス チェック関数の使用\n\n```\n          `my backup step` は、ジョブの前のステップが失敗した場合にのみ実行されます。 詳しくは、「[AUTOTITLE](/actions/learn-github-actions/expressions#status-check-functions)」をご覧ください。\n```\n\n```yaml\nsteps:\n  - name: My first step\n    uses: octo-org/action-name@main\n  - name: My backup step\n    if: ${{ failure() }}\n    uses: actions/heroku@1.0.0\n```\n\n### 例: シークレットの使用\n\n```\n          `if:` 条件文でシークレットを直接参照することはできません。 代わりに、シークレットをジョブ レベルの環境変数として設定し、ジョブのステップを条件付きで実行するために環境変数を参照することを検討してください。\n```\n\nシークレットが設定されていない場合、シークレットを参照する式の戻り値 (例では `${{ secrets.SuperSecret }}` など) は空の文字列になります。\n\n```yaml\nname: Run a step if a secret has been set\non: push\njobs:\n  my-jobname:\n    runs-on: ubuntu-latest\n    env:\n      super_secret: ${{ secrets.SuperSecret }}\n    steps:\n      - if: ${{ env.super_secret != '' }}\n        run: echo 'This step will only run if the secret has a value set.'\n      - if: ${{ env.super_secret == '' }}\n        run: echo 'This step will only run if the secret does not have a value set.'\n```\n\n詳細については、「[コンテキスト リファレンス](/ja/actions/learn-github-actions/contexts#context-availability)」および「[GitHub Actions でのシークレットの使用](/ja/actions/security-guides/using-secrets-in-github-actions)」を参照してください。\n\n## `jobs.<job_id>.steps[*].name`\n\n```\n          GitHubに表示されるステップの名前。\n```\n\n## `jobs.<job_id>.steps[*].uses`\n\nジョブでステップの一部として実行されるアクションを選択します。 アクションとは、再利用可能なコードの単位です。 ワークフローと同じリポジトリ、パブリック リポジトリ、または[公開されている Docker コンテナー イメージ](https://hub.docker.com/)で定義されているアクションを使用できます。\n\nGit ref、SHA、または Docker タグを指定することで、使っているアクションのバージョンを含めることを、強く推奨しています。 バージョンを指定しないと、アクションのオーナーがアップデートを公開したときに、ワークフローが中断したり、予期せぬ動作をしたりすることがあります。\n\n* リリースされたアクションバージョンのコミットSHAを使用するのが、安定性とセキュリティのうえで最も安全です。\n* アクションでメジャー バージョン タグが発行される場合は、互換性を維持しながら、重要な修正プログラムとセキュリティ パッチを受け取ることを予期する必要があります。 この動作は、アクションの作成者が判断するものであることに注意してください。\n* アクションのデフォルトブランチを使用すると便利なこともありますが、別のユーザが破壊的変更を加えた新しいメジャーバージョンをリリースすると、ワークフローが動作しなくなる場合があります。\n\n一部のアクションでは、[`with`](#jobsjob_idstepswith) キーワードを使用して設定する必要がある入力が必要です。 必要な入力を判断するには、アクションのREADMEファイルをお読みください。\n\nアクションは、JavaScriptのファイルもしくはDockerコンテナです。 使用するアクションがDockerコンテナの場合、ジョブはLinux環境で実行する必要があります。 詳細については、[`runs-on`](#jobsjob_idruns-on) を参照してください。\n\n### 例: バージョン管理されたアクションの使用\n\n```yaml\nsteps:\n  # Reference a specific commit\n  - uses: actions/checkout@8f4b7f84864484a7bf31766abe9204da3cbe65b3\n  # Reference the major version of a release\n  - uses: actions/checkout@v5\n  # Reference a specific version\n  - uses: actions/checkout@v5.2.0\n  # Reference a branch\n  - uses: actions/checkout@main\n```\n\n### 例: パブリック アクションの使用\n\n`{owner}/{repo}@{ref}`\n\nパブリック GitHub リポジトリには、ブランチ、ref、または SHA を指定できます。\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        # Uses the default branch of a public repository\n        uses: actions/heroku@main\n      - name: My second step\n        # Uses a specific version tag of a public repository\n        uses: actions/aws@v2.0.1\n```\n\n### 例: サブディレクトリのパブリック アクションの使用\n\n`{owner}/{repo}/{path}@{ref}`\n\n特定のブランチ、ref、または SHA にあるパブリック GitHub リポジトリ内のサブディレクトリ。\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: actions/aws/ec2@main\n```\n\n### 例: ワークフローと同じリポジトリにあるアクションの使用\n\n`./path/to/dir`\n\nワークフローのリポジトリにあるアクションを含むディレクトリのパス。 アクションを使用する前にリポジトリをチェックアウトする必要があります。\n\nリポジトリ ファイル構造の例:\n\n```shell\n|-- hello-world (repository)\n|   |__ .github\n|       └── workflows\n|           └── my-first-workflow.yml\n|       └── actions\n|           |__ hello-world-action\n|               └── action.yml\n```\n\nパスはデフォルトの作業ディレクトリ (`github.workspace`、`$GITHUB_WORKSPACE`) に対する相対パス (`./`) です。 アクションがワークフローとは異なる場所にリポジトリをチェックアウトする場合は、ローカル アクションに使用される相対パスを更新する必要があります。\n\nワークフロー ファイルの例:\n\n```yaml\njobs:\n  my_first_job:\n    runs-on: ubuntu-latest\n    steps:\n      # This step checks out a copy of your repository.\n      - name: My first step - check out repository\n        uses: actions/checkout@v5\n      # This step references the directory that contains the action.\n      - name: Use local hello-world-action\n        uses: ./.github/actions/hello-world-action\n```\n\n### 例: Docker Hub アクションの使用\n\n`docker://{image}:{tag}`\n\n```\n          [Docker Hub](https://hub.docker.com/) で公開されている Docker イメージ。\n```\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: docker://alpine:3.8\n```\n\n### 例: GitHub PackagesContainer registry\n\n`docker://{host}/{image}:{tag}`\n\n```\n          GitHub Packages\n          Container registry内のパブリック Docker イメージ。\n```\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: docker://ghcr.io/OWNER/IMAGE_NAME\n```\n\n### 例: Docker パブリック レジストリ アクションの使用\n\n`docker://{host}/{image}:{tag}`\n\nパブリックレジストリのDockerイメージ。 この例では、`gcr.io` にある Google Container Registry を使っています。\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: docker://gcr.io/cloud-builders/gradle\n```\n\n### 例: ワークフローとは異なるプライベート リポジトリ内でのアクションの使用\n\nワークフローはプライベートリポジトリをチェックアウトし、アクションをローカルで参照する必要があります。\npersonal access tokenを生成し、シークレットとしてトークンを追加します。 詳細については、「[個人用アクセス トークンを管理する](/ja/authentication/keeping-your-account-and-data-secure/creating-a-personal-access-token)」および「[GitHub Actions でのシークレットの使用](/ja/actions/security-guides/using-secrets-in-github-actions)」を参照してください。\n\nこの例の `PERSONAL_ACCESS_TOKEN` をシークレットの名前に置き換えます。\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: Check out repository\n        uses: actions/checkout@v5\n        with:\n          repository: octocat/my-private-repo\n          ref: v1.0\n          token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n          path: ./.github/actions/my-private-repo\n      - name: Run my action\n        uses: ./.github/actions/my-private-repo/my-action\n```\n\nまたは、GitHub Appではなくpersonal access tokenを使用して、personal access token所有者が離れる場合でもワークフローが引き続き実行されるようにします。 詳しくは、「[GitHub Actions ワークフローでGitHub アプリを使用して認証済み API 要求を作成する](/ja/apps/creating-github-apps/guides/making-authenticated-api-requests-with-a-github-app-in-a-github-actions-workflow)」をご覧ください。\n\n## `jobs.<job_id>.steps[*].run`\n\nオペレーティング システムのシェルを使用して、21,000 文字を超えないコマンド ライン プログラムを実行します。\n`name` を指定しない場合、ステップ名は既定では `run` コマンドで指定されたテキストになります。\n\nコマンドは、デフォルトでは非ログインシェルを使用して実行されます。 別のシェルを選択して、コマンドを実行するシェルをカスタマイズできます。 詳細については、「[`jobs.<job_id>.steps[*].shell`](#jobsjob_idstepsshell)」を参照してください。\n\n```\n          `run` キーワードは、それぞれがランナー環境での新しいプロセスとシェルを表します。 複数行のコマンドを指定すると、各行が同じシェルで実行されます。 次に例を示します。\n```\n\n* 1行のコマンド：\n\n  ```yaml\n  - name: Install Dependencies\n    run: npm install\n  ```\n\n* 複数行のコマンド：\n\n  ```yaml\n  - name: Clean install dependencies and build\n    run: |\n      npm ci\n      npm run build\n  ```\n\n## `jobs.<job_id>.steps[*].working-directory`\n\n```\n          `working-directory` キーワードを使えば、コマンドが実行される作業ディレクトリを指定できます。\n```\n\n```yaml\n- name: Clean temp directory\n  run: rm -rf *\n  working-directory: ./temp\n```\n\nまたは、ジョブ内のすべての`run`ステップまたはワークフロー全体のすべての`run`ステップに既定の作業ディレクトリを指定することもできます。 詳細については、[`defaults.run.working-directory`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunworking-directory) および [`jobs.<job_id>.defaults.run.working-directory`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunworking-directory) を参照してください。\n\n```\n          `run`ステップを使用してスクリプトを実行することもできます。 詳しくは、「[AUTOTITLE](/actions/writing-workflows/choosing-what-your-workflow-does/adding-scripts-to-your-workflow)」をご覧ください。\n```\n\n## `jobs.<job_id>.steps[*].shell`\n\n```\n          `shell` キーワードを使用して、ランナーのオペレーティング システムのデフォルト シェル設定とジョブのデフォルトをオーバーライドできます。 組み込みの `shell` キーワードを使いことも、カスタム セットのシェル オプションを定義することもできます。 内部で実行されるシェル コマンドによって、`run` キーワードで指定されたコマンドを含む一時ファイルが実行されます。\n```\n\n| サポートされているプラットフォーム | `shell` パラメーター | 説明                                                                                                                                                                               | 内部で実行されるコマンド                                    |\n| ----------------- | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------- |\n| Linux/macOS       | unspecified    | Windows 以外のプラットフォームの既定のシェル。 これにより、`bash` を明示的に指定した場合とは異なるコマンドが実行されることに注意してください。 `bash` がパスに見つからない場合、これは `sh` のように扱われます。                                                          | `bash -e {0}`                                   |\n| すべて               | `bash`         | `sh` へのフォールバックが設定された、Windows 以外のプラットフォームの既定のシェル。 Windowsでbashシェルを指定すると、Windows用Gitに含まれるbashシェルが使用されます。                                                                           | `bash --noprofile --norc -eo pipefail {0}`      |\n| すべて               | `pwsh`         | PowerShell Coreです。 GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。                                                                                                                         | `pwsh -command \". '{0}'\"`                       |\n| すべて               | `python`       | Pythonのコマンドを実行します。                                                                                                                                                               | `python {0}`                                    |\n| Linux/macOS       | `sh`           | Windows 以外のプラットフォームにおいて、シェルが提供されておらず、パスで `bash` が見つからなかった場合のフォールバック動作。                                                                                                           | `sh -e {0}`                                     |\n| Windows           | `cmd`          | GitHub によってスクリプト名に拡張子 `.cmd` が追加され、`{0}` が置き換えられます。                                                                                                                              | `%ComSpec% /D /E:ON /V:OFF /S /C \"CALL \"{0}\"\"`. |\n| Windows           | `pwsh`         | これはWindowsで使われるデフォルトのシェルです。 PowerShell Coreです。 GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。 セルフホステッド Windows ランナーに *PowerShell Core* がインストールされていない場合は、代わりに *PowerShell Desktop* が使われます。 | `pwsh -command \". '{0}'\"`.                      |\n| Windows           | `powershell`   | PowerShell Desktop. GitHub によってスクリプト名に拡張子 `.ps1` が追加されます。                                                                                                                        | `powershell -command \". '{0}'\"`.                |\n\nまたは、ジョブのすべての `run` ステップまたはワークフロー全体のすべての `run` ステップにデフォルト シェルを指定することもできます。 詳細については、[`defaults.run.shell`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#defaultsrunshell) および [`jobs.<job_id>.defaults.run.shell`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrunshell) を参照してください。\n\n### 例: Bash を使ったコマンドの実行\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: bash\n    run: echo $PATH\n```\n\n### 例: Windows `cmd` を使ったコマンドの実行\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: cmd\n    run: echo %PATH%\n```\n\n### 例: PowerShell Core を使ったコマンドの実行\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: pwsh\n    run: echo ${env:PATH}\n```\n\n### PowerShell Desktopを使用してコマンドを実行する例\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: powershell\n    run: echo ${env:PATH}\n```\n\n### 例: インライン Python スクリプトの実行\n\n```yaml\nsteps:\n  - name: Display the path\n    shell: python\n    run: |\n      import os\n      print(os.environ['PATH'])\n```\n\n### カスタムシェル\n\n```\n          `shell` を使って、テンプレート文字列に `command [options] {0} [more_options]` 値を設定できます。 \n          GitHub は、文字列の最初の空白で区切られた単語をコマンドとして解釈し、一時スクリプトのファイル名を `{0}`に挿入します。\n```\n\n次に例を示します。\n\n```yaml\nsteps:\n  - name: Display the environment variables and their values\n    shell: perl {0}\n    run: |\n      print %ENV\n```\n\n使われるコマンド (この例では `perl`) は、ランナーにインストールされている必要があります。\n\nGitHub でホストされるランナーに含まれるソフトウェアの詳細については、 [GitHub ホステッド ランナー](/ja/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software) を参照してください。\n\n### 終了コードとエラーアクションの環境設定\n\n組み込みのシェル キーワードの場合、 GitHubホストランナーによって実行される次の既定値が提供されます。 シェルスクリプトを実行する際には、以下のガイドラインを使ってください。\n\n* `bash`\n  /\n  `sh`:\n  * 既定では、フェイルファスト動作は、`set -e` と `sh` の両方に `bash` を使用して強制されます。\n    `shell: bash` が指定されている場合、ゼロ以外の終了ステータスを生成するパイプラインからの早期終了を強制するために `-o pipefail` も適用されます。\n  * シェル オプションにテンプレート文字列を指定することで、シェル パラメーターを完全に制御できます。 たとえば、`bash {0}` のようにします。\n  * ```\n          `sh` ライクのシェルは、スクリプトで実行された最後のコマンドの終了コードで終了します。これは、アクションの既定の動作でもあります。 runnerは、この終了コードに基づいてステップのステータスを失敗/成功としてレポートします。\n    ```\n\n* `powershell`/`pwsh`\n  * 可能な場合のフェイルファースト動作。\n    `pwsh` と `powershell` の組み込みのシェルでは、スクリプトの内容の前に `$ErrorActionPreference = 'stop'` を追加します。\n  * PowerShell スクリプトに `if ((Test-Path -LiteralPath variable:\\LASTEXITCODE)) { exit $LASTEXITCODE }` を追加して、アクションの状態にスクリプトの最後の終了コードが反映されるようにします。\n  * ユーザーは、組み込みのシェルを使わずに、必要に応じて `pwsh -File {0}` や `powershell -Command \"& '{0}'\"` のようなカスタム シェル オプションを指定するといつでもオプトアウトできます。\n\n* `cmd`\n  * 各エラーコードをチェックしてそれぞれに対応するスクリプトを書く以外、フェイルファースト動作を完全にオプトインする方法はないようです。 デフォルトでその動作を指定することはできないため、この動作はスクリプトに記述する必要があります。\n  * ```\n          `cmd.exe` は実行した最後のプログラムのエラー レベルで終了し、ランナーにエラー コードが返されます。 この動作は、内部的には前の `sh` と `pwsh` の既定の動作と一致しており、`cmd.exe` の既定であるため、この動作は変更されません。\n    ```\n\n## `jobs.<job_id>.steps[*].with`\n\n入力パラメーターの`map` はアクションによって定義されています。 各入力パラメータはキー/値ペアです。 入力パラメータは環境変数として設定されます。 変数の前には `INPUT_` が付けられ、大文字に変換されます。\n\nDocker コンテナーに定義された入力パラメーターは `args` を使用する必要があります。 詳細については、「[`jobs.<job_id>.steps[*].with.args`](#jobsjob_idstepswithargs)」を参照してください。\n\n###\n\n```\n          `jobs.<job_id>.steps[*].with` の例\n\n          `first_name` アクションによって定義される 3 つの入力パラメーター (`middle_name`、`last_name`、`hello_world`) を定義します。 これらの入力変数には、`hello-world`、`INPUT_FIRST_NAME`、`INPUT_MIDDLE_NAME` の環境変数として `INPUT_LAST_NAME` アクションからアクセスできます。\n```\n\n```yaml\njobs:\n  my_first_job:\n    steps:\n      - name: My first step\n        uses: actions/hello_world@main\n        with:\n          first_name: Mona\n          middle_name: The\n          last_name: Octocat\n```\n\n## `jobs.<job_id>.steps[*].with.args`\n\nDocker コンテナーの入力を定義する `string`。\nGitHubは、コンテナーの起動時にコンテナーの`args`に`ENTRYPOINT`を渡します。\n`array of strings` はこのパラメーターではサポートされていません。 スペースを含む 1 つの引数は、二重引用符 `\"\"` で囲む必要があります。\n\n###\n\n```\n          `jobs.<job_id>.steps[*].with.args` の例\n```\n\n```yaml\nsteps:\n  - name: Explain why this job ran\n    uses: octo-org/action-name@main\n    with:\n      entrypoint: /bin/echo\n      args: The ${{ github.event_name }} event triggered this step.\n```\n\n```\n          `args` は、`CMD` 内の `Dockerfile` 命令の代わりに使用されます。 ご自分の `CMD` で `Dockerfile` を使用する場合は、以下の優先順のガイドラインを使用してください。\n```\n\n1. アクションの README 中で必須の引数をドキュメント化し、`CMD` 命令から除外します。\n2. ```\n          `args` を指定せずにアクションを利用できるよう、既定値を使用します。\n   ```\n3. アクションによって `--help` フラグなどが公開される場合、アクションを自己文書化するための既定としてこれを使います。\n\n## `jobs.<job_id>.steps[*].with.entrypoint`\n\n```\n          `ENTRYPOINT` 内の Docker の `Dockerfile` をオーバーライドするか、まだ指定されていない場合は設定します。 shell や exec 形式を持つ Docker の `ENTRYPOINT` 命令とは異なり、`entrypoint` キーワードでは、実行する実行可能ファイルを定義する単一の文字列だけを受け付けます。\n```\n\n###\n\n```\n          `jobs.<job_id>.steps[*].with.entrypoint` の例\n```\n\n```yaml\nsteps:\n  - name: Run a custom command\n    uses: octo-org/action-name@main\n    with:\n      entrypoint: /a/different/executable\n```\n\n```\n          `entrypoint` キーワードは Docker コンテナー アクションで使われることを意図したものですが、入力を定義しない JavaScript のアクションでも使うことができます。\n```\n\n## `jobs.<job_id>.steps[*].env`\n\nランナー環境で使うステップの変数を設定します。 ワークフロー全体またはジョブの変数を設定することもできます。 詳細については、[`env`](#env) および [`jobs.<job_id>.env`](#jobsjob_idenv) を参照してください。\n\n同じ名前で複数の環境変数が定義されている場合、GitHub では最も具体的な変数を使用します。 たとえば、ステップ中で定義された環境変数は、ジョブやワークフローの同じ名前の環境変数をステップの実行の間オーバーライドします。 ジョブで定義された環境変数は、そのジョブの実行の間はワークフローの同じ名前の変数をオーバーライドします。\n\nパブリックなアクションを実行すると、README ファイル内で想定されている変数が指定されることがあります。 シークレットまたは機密性の高い値 (パスワードやトークンなど) を設定している場合は、`secrets` コンテキストを使ってシークレットを設定する必要があります。 詳しくは、「[コンテキスト リファレンス](/ja/actions/learn-github-actions/contexts)」をご覧ください。\n\n###\n\n```\n          `jobs.<job_id>.steps[*].env` の例\n```\n\n```yaml\nsteps:\n  - name: My first action\n    env:\n      GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}\n      FIRST_NAME: Mona\n      LAST_NAME: Octocat\n```\n\n## `jobs.<job_id>.steps[*].continue-on-error`\n\nステップが失敗してもジョブが失敗にならないようにします。\n`true` に設定すれば、このステップが失敗した場合にジョブを成功させることができます。\n\n## `jobs.<job_id>.steps[*].timeout-minutes`\n\nプロセスがkillされるまでにステップが実行できる最大の分数。 最大: GitHubホストランナーとセルフホステッド ランナーの両方に対して 360。\n\n小数値はサポートされていません。\n`timeout-minutes` は、正の整数にする必要があります。\n\n## `jobs.<job_id>.timeout-minutes`\n\n実行したジョブがGitHub自動的に取り消されるまでの最大分数を設定します。 デフォルト: 360\n\nタイムアウトがランナーのジョブ実行の制限時間を超えた場合、代わりに、実行の制限時間に達したときにジョブが取り消されます。 ジョブの実行時間制限の詳細については、[](/ja/actions/learn-github-actions/usage-limits-billing-and-administration#usage-limits)ホストランナーの GitHub とセルフホステッド ランナーの使用制限に関する [アクションの制限](/ja/actions/hosting-your-own-runners/managing-self-hosted-runners/usage-limits-for-self-hosted-runners) を参照してください。\n\n> \\[!NOTE]\n\n```\n          ジョブが終了するか最大 24 時間後に、`GITHUB_TOKEN` の有効期限が切れます。 セルフホステッド ランナーの場合、ジョブのタイムアウトが 24 時間を超える場合、トークンが制限要因になる可能性があります。 \n```\n\n```\n          `GITHUB_TOKEN` について詳しくは、「[AUTOTITLE](/actions/security-guides/automatic-token-authentication#about-the-github_token-secret)」をご覧ください。\n```\n\n## `jobs.<job_id>.strategy`\n\nジョブにマトリックス戦略を使うには、`jobs.<job_id>.strategy` を使用します。\nマトリックス戦略を使用すると、1 つのジョブ定義で変数を使用して、変数の組み合わせに基づく複数のジョブ実行を自動的に作成できます。 たとえば、マトリックス戦略を使用して、複数バージョンの言語または複数のオペレーティング システムでコードをテストできます。 詳細については、 [AUTOTITLE を](/ja/actions/using-jobs/using-a-matrix-for-your-jobs)参照してください。\n\n## `jobs.<job_id>.strategy.matrix`\n\n```\n          `jobs.<job_id>.strategy.matrix` を使用して、さまざまなジョブの設定のマトリックスを定義します。 詳しくは、「[AUTOTITLE](/actions/how-tos/writing-workflows/choosing-what-your-workflow-does/running-variations-of-jobs-in-a-workflow)」をご覧ください。\n```\n\nこのマトリックスでは、ワークフローの実行ごとに最大で 256 のジョブが生成されます。 この制限は、 GitHubホストランナーとセルフホステッド ランナーの両方に適用されます。\n\n定義した変数は、`matrix` のコンテキストでのプロパティとなり、ワークフロー ファイルの他のエリア内のプロパティを参照できます。 この例では、`matrix.version` および `matrix.os` を使用して、ジョブが使用している `version` および `os` の現在の値にアクセスできます。 詳しくは、「[コンテキスト リファレンス](/ja/actions/learn-github-actions/contexts)」をご覧ください。\n\n既定では、 GitHub はランナーの可用性に応じて、並列で実行されるジョブの数を最大化します。 マトリックス内の変数の順序によって、ジョブが作成される順序が決まります。 定義する最初の変数は、ワークフローの実行で最初に作成されるジョブになります。\n\n### 1 次元マトリックスの使用\n\n次のワークフローでは、変数 `version` に値 `[10, 12, 14]` を定義しています。 このワークフローでは、変数の値ごとに 1 つずつ、3 つのジョブが実行されます。 各ジョブは、`version` コンテキストを通して `matrix.version` 値にアクセスし、`node-version` として `actions/setup-node` アクションにその値を渡します。\n\n```yaml\njobs:\n  example_matrix:\n    strategy:\n      matrix:\n        version: [10, 12, 14]\n    steps:\n      - uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.version }}\n```\n\n### 多次元マトリックスの使用\n\n多次元マトリックスを作成するには、複数の変数を指定します。 ジョブは、変数の可能な組み合わせごとに実行されます。\n\nたとえば、次のワークフローでは 2 つの変数を指定しています。\n\n* `os` 変数で指定された 2 つのオペレーティング システム\n* `version` 変数で指定された 3 つの Node.js バージョン\n\nこのワークフローでは、`os` と `version` 変数の組み合わせごとに 1 つずつ、計 6 つのジョブが実行されます。 各ジョブは、`runs-on` の値を現在の `os` の値に設定し、現在の `version` の値を `actions/setup-node` アクションに渡します。\n\n```yaml\njobs:\n  example_matrix:\n    strategy:\n      matrix:\n        os: [ubuntu-22.04, ubuntu-24.04]\n        version: [10, 12, 14]\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.version }}\n```\n\nマトリックス内の変数構成は、`array` の `object` として表現されることがあります。 たとえば、次のマトリックスでは、対応するコンテキストで 4 つのジョブが生成されます。\n\n```yaml\nmatrix:\n  os:\n    - ubuntu-latest\n    - macos-latest\n  node:\n    - version: 14\n    - version: 20\n      env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\n次に示すように、マトリックス内の各ジョブは、`os` と `node` の値の独自の組み合わせを持ちます。\n\n```yaml\n- matrix.os: ubuntu-latest\n  matrix.node.version: 14\n- matrix.os: ubuntu-latest\n  matrix.node.version: 20\n  matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n- matrix.os: macos-latest\n  matrix.node.version: 14\n- matrix.os: macos-latest\n  matrix.node.version: 20\n  matrix.node.env: NODE_OPTIONS=--openssl-legacy-provider\n```\n\n## `jobs.<job_id>.strategy.matrix.include`\n\n```\n          `include` リスト内の各オブジェクトに対して、キーと値のペアのいずれも元のマトリックス値を上書きしない場合、オブジェクト内のキーと値のペアが各マトリックスの組み合わせに追加されます。 オブジェクトをどのマトリックスの組み合わせにも追加できない場合は、代わりに新しいマトリックスの組み合わせが作成されます。 元のマトリックス値は上書きされませんが、追加されたマトリックス値は上書きできます。\n```\n\n### 例: 構成の展開\n\nたとえば、次のワークフローでは、`os` と `node` の組み合わせごとに 1 つずつ、計 4 つのジョブが実行されます。 `os` の値が `windows-latest` で `node` の値が `16` のジョブが実行されると、`6` の値を持つ `npm` という追加の変数がジョブに含まれます。\n\n```yaml\njobs:\n  example_matrix:\n    strategy:\n      matrix:\n        os: [windows-latest, ubuntu-latest]\n        node: [14, 16]\n        include:\n          - os: windows-latest\n            node: 16\n            npm: 6\n    runs-on: ${{ matrix.os }}\n    steps:\n      - uses: actions/setup-node@v4\n        with:\n          node-version: ${{ matrix.node }}\n      - if: ${{ matrix.npm }}\n        run: npm install -g npm@${{ matrix.npm }}\n      - run: npm --version\n```\n\n### 例: 構成の追加\n\nたとえば、このマトリックスでは 10 個のジョブが実行されます。マトリックス内の `os` と `version` の組み合わせごとに 1 つと、`windows-latest` の `os` 値と `17` の `version` 値のジョブです。\n\n```yaml\njobs:\n  example_matrix:\n    strategy:\n      matrix:\n        os: [macos-latest, windows-latest, ubuntu-latest]\n        version: [12, 14, 16]\n        include:\n          - os: windows-latest\n            version: 17\n```\n\nマトリックス変数を指定しない場合は、`include` の下のすべての構成が実行されます。 たとえば、次のワークフローでは、`include` エントリごとに 1 つずつ、2 つのジョブが実行されます。 これにより、マトリックスを完全に設定しなくても、マトリックス戦略を利用できます。\n\n```yaml\njobs:\n  includes_only:\n    runs-on: ubuntu-latest\n    strategy:\n      matrix:\n        include:\n          - site: \"production\"\n            datacenter: \"site-a\"\n          - site: \"staging\"\n            datacenter: \"site-b\"\n```\n\n## `jobs.<job_id>.strategy.matrix.exclude`\n\n除外対象とするには、構成が部分一致していれば十分です。\n\n```\n          `include` のすべての組み合わせが、`exclude` の後で処理されます。 このため、`include` を使って以前に除外された組み合わせを追加し直すことができます。\n```\n\n## `jobs.<job_id>.strategy.fail-fast`\n\n`jobs.<job_id>.strategy.fail-fast` と `jobs.<job_id>.continue-on-error` を使用して、ジョブ エラーの処理方法制御できます。\n\n`jobs.<job_id>.strategy.fail-fast` はマトリックス全体に適用されます。 `jobs.<job_id>.strategy.fail-fast` が `true` に設定されているか、その式が `true` と評価されている場合、マトリックス内のいずれかのジョブが失敗すると、進行中およびキューに入れられたすべてのジョブは GitHub によって取り消されます。 このプロパティでは、既定値が `true` に設定されます。\n\n`jobs.<job_id>.continue-on-error` は 1 つのジョブに適用されます。 `jobs.<job_id>.continue-on-error` が `true`、`jobs.<job_id>.continue-on-error: true` が失敗するジョブであっても、マトリックス内の他のジョブは引き続き実行されます。\n\n`jobs.<job_id>.strategy.fail-fast` と `jobs.<job_id>.continue-on-error` は一緒に使用できます。 たとえば、次のワークフローは 4 つのジョブを開始します。 ジョブごとに、`continue-on-error` は `matrix.experimental` の値によって決定されます。 `continue-on-error: false` のいずれかのジョブが失敗すると、進行中またはキューに入っているすべてのジョブがキャンセルされます。 `continue-on-error: true` のジョブが失敗した場合、他のジョブは影響を受けません。\n\n```yaml\njobs:\n  test:\n    runs-on: ubuntu-latest\n    continue-on-error: ${{ matrix.experimental }}\n    strategy:\n      fail-fast: true\n      matrix:\n        version: [6, 7, 8]\n        experimental: [false]\n        include:\n          - version: 9\n            experimental: true\n```\n\n## `jobs.<job_id>.strategy.max-parallel`\n\n既定では、 GitHub はランナーの可用性に応じて、並列で実行されるジョブの数を最大化します。\n\n## `jobs.<job_id>.continue-on-error`\n\n```\n          `jobs.<job_id>.continue-on-error` は 1 つのジョブに適用されます。 \n          `jobs.<job_id>.continue-on-error` が `true`、`jobs.<job_id>.continue-on-error: true` が失敗するジョブであっても、マトリックス内の他のジョブは引き続き実行されます。\n```\n\nジョブが失敗しても、ワークフローの実行が失敗とならないようにします。\n`true` に設定すれば、このジョブが失敗したときにワークフローの実行を成功させることができます。\n\n### 例: 失敗した特定のマトリックス ジョブがワークフローの実行を失敗させないようにする\n\nジョブマトリックス中の特定のジョブが失敗しても、ワークフローの実行が失敗にならないようにすることができます。 たとえば、`node` が `15` に設定された実験的なジョブが失敗しても、ワークフローの実行を失敗させないようにしたいとしましょう。\n\n```yaml\nruns-on: ${{ matrix.os }}\ncontinue-on-error: ${{ matrix.experimental }}\nstrategy:\n  fail-fast: false\n  matrix:\n    node: [13, 14]\n    os: [macos-latest, ubuntu-latest]\n    experimental: [false]\n    include:\n      - node: 15\n        os: ubuntu-latest\n        experimental: true\n```\n\n## `jobs.<job_id>.container`\n\n> \\[!NOTE]\n> ワークフローで Docker コンテナー アクション、ジョブ コンテナー、またはサービス コンテナーが使われる場合は、Linux ランナーを使う必要があります。\n>\n> * GitHubホストランナーを使うなら、Ubuntuランナーを使わなければなりません。\n> * セルフホストランナーを使っているなら、ランナーとしてLinuxマシンを使い、Dockerをインストールしておかなければなりません。\n\n`jobs.<job_id>.container` を使用して、コンテナーを作成し、コンテナーをまだ指定していないジョブのステップを実行します。 スクリプトアクションとコンテナアクションの両方を使うステップがある場合、コンテナアクションは同じボリュームマウントを使用して、同じネットワーク上にある兄弟コンテナとして実行されます。\n\n`container` を設定しない場合、ステップがコンテナーで実行するように構成されたアクションを参照しない限り、すべてのステップは `runs-on` で指定されたホスト上で直接実行されます。\n\n> \\[!NOTE]\n> コンテナー内の `run` ステップの既定のシェルは、`bash` ではなく `sh` です。 これは、[`jobs.<job_id>.defaults.run`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_iddefaultsrun) でも [`jobs.<job_id>.steps[*].shell`](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idstepsshell) でもオーバーライドできます。\n\n### 例: コンテナー内でジョブを実行する\n\n```yaml copy\nname: CI\non:\n  push:\n    branches: [ main ]\njobs:\n  container-test-job:\n    runs-on: ubuntu-latest\n    container:\n      image: node:18\n      env:\n        NODE_ENV: development\n      ports:\n        - 80\n      volumes:\n        - my_docker_volume:/volume_mount\n      options: --cpus 1\n    steps:\n      - name: Check for dockerenv file\n        run: (ls /.dockerenv && echo Found dockerenv) || (echo No dockerenv)\n```\n\nコンテナー イメージのみを指定する場合は、`image` キーワードを省略できます。\n\n```yaml\njobs:\n  container-test-job:\n    runs-on: ubuntu-latest\n    container: node:18\n```\n\n## `jobs.<job_id>.container.image`\n\n`jobs.<job_id>.container.image` を使用して、アクションを実行するコンテナーとして使用する Docker イメージを定義します。 値には、Docker Hub イメージ名またはレジストリ名を指定できます。\n\n> \\[!NOTE]\n> 通常、Docker Hub により、プッシュ操作とプル操作の両方にレート制限が課せられます。これは、セルフホステッド ランナーのジョブに影響します。 ただし、GitHub と Docker の間の同意に基づくこれらの制限は、GitHub ホステッド ランナーには適用されません。\n\n## `jobs.<job_id>.container.credentials`\n\nイメージのコンテナー レジストリでイメージをプルするための認証が必要な場合は、`jobs.<job_id>.container.credentials` を使って `username` と `password` の `map` を設定できます。 資格情報は、[`docker login`](https://docs.docker.com/engine/reference/commandline/login/) コマンドに指定するのと同じ値です。\n\n### 例: コンテナー レジストリの資格情報の定義\n\n```yaml\ncontainer:\n  image: ghcr.io/owner/image\n  credentials:\n     username: ${{ github.actor }}\n     password: ${{ secrets.github_token }}\n```\n\n## `jobs.<job_id>.container.env`\n\n`jobs.<job_id>.container.env` を使用して、コンテナー内の環境変数の `map` を設定します。\n\n## `jobs.<job_id>.container.ports`\n\n`jobs.<job_id>.container.ports` を使用して、コンテナーで公開するポートの `array` を設定します。\n\n## `jobs.<job_id>.container.volumes`\n\n`jobs.<job_id>.container.volumes` を使用して、コンテナーで使用するボリュームの `array` を設定します。 volumes (ボリューム) を使用すると、サービス間で、または1つのジョブのステップ間でデータを共有できます。 指定できるのは、名前付きDockerボリューム、匿名Dockerボリューム、またはホスト上のバインドマウントです。\n\nボリュームを指定するには、次のソースパスとターゲットパスを指定してください。\n\n`<source>:<destinationPath>`.\n\n`<source>` は、ホスト マシン上のボリューム名または絶対パスであり、`<destinationPath>` は、コンテナー内の絶対パスです。\n\n### 例: コンテナーにボリュームをマウントする\n\n```yaml\nvolumes:\n  - my_docker_volume:/volume_mount\n  - /data/my_data\n  - /source/directory:/destination/directory\n```\n\n## `jobs.<job_id>.container.options`\n\n`jobs.<job_id>.container.options` を使用して、追加の Docker コンテナー リソース オプションを構成します。 オプションの一覧については、[`docker create` のオプション](https://docs.docker.com/engine/reference/commandline/create/#options)に関するページを参照してください。\n\n> \\[!WARNING]\n> `--network` と `--entrypoint` オプションはサポートされていません。\n\n## `jobs.<job_id>.services`\n\n> \\[!NOTE]\n> ワークフローで Docker コンテナー アクション、ジョブ コンテナー、またはサービス コンテナーが使われる場合は、Linux ランナーを使う必要があります。\n>\n> * GitHubホストランナーを使うなら、Ubuntuランナーを使わなければなりません。\n> * セルフホストランナーを使っているなら、ランナーとしてLinuxマシンを使い、Dockerをインストールしておかなければなりません。\n\nワークフロー中のジョブのためのサービスコンテナをホストするために使われます。 サービスコンテナは、データベースやRedisのようなキャッシュサービスの作成に役立ちます。 ランナーは自動的にDockerネットワークを作成し、サービスコンテナのライフサイクルを管理します。\n\nコンテナを実行するようにジョブを設定した場合、あるいはステップがコンテナアクションを使う場合は、サービスもしくはアクションにアクセスするためにポートをマップする必要はありません。 Dockerは自動的に、同じDockerのユーザ定義ブリッジネットワーク上のコンテナ間のすべてのポートを公開します。 サービスコンテナは、ホスト名で直接参照できます。 ホスト名は自動的に、ワークフロー中のサービスに設定したラベル名にマップされます。\n\nランナーマシン上で直接実行されるようにジョブを設定し、ステップがコンテナアクションを使わないのであれば、必要なDockerサービスコンテナのポートはDockerホスト（ランナーマシン）にマップしなければなりません サービスコンテナには、localhostとマップされたポートを使ってアクセスできます。\n\nネットワーク サービス コンテナー間の違いについて詳しくは、「[Docker サービス コンテナーとの通信](/ja/actions/using-containerized-services/about-service-containers)」をご覧ください。\n\n### 例: localhost の使用\n\nこの例では、nginxとredisという2つのサービスを作成します。 コンテナー ポートを指定したがホスト ポートを指定しなかった場合、コンテナー ポートはホスト上の空きポートにランダムに割り当てられます。\nGitHub は、 `${{job.services.<service_name>.ports}}` コンテキストで割り当てられたホスト ポートを設定します。 この例では、 `${{ job.services.nginx.ports['80'] }}` と `${{ job.services.redis.ports['6379'] }}` コンテキストを使用して、サービス ホスト ポートにアクセスできます。\n\n```yaml\nservices:\n  nginx:\n    image: nginx\n    # Map port 8080 on the Docker host to port 80 on the nginx container\n    ports:\n      - 8080:80\n  redis:\n    image: redis\n    # Map random free TCP port on Docker host to port 6379 on redis container\n    ports:\n      - 6379/tcp\nsteps:\n  - run: |\n      echo \"Redis available on 127.0.0.1:${{ job.services.redis.ports['6379'] }}\"\n      echo \"Nginx available on 127.0.0.1:${{ job.services.nginx.ports['80'] }}\"\n```\n\n## `jobs.<job_id>.services.<service_id>.image`\n\nアクションを実行するサービスコンテナとして使用するDockerイメージ。 値には、Docker Hub イメージ名またはレジストリ名を指定できます。\n\n```\n          `jobs.<job_id>.services.<service_id>.image` に空の文字列が割り当てられている場合、サービスが開始されません。 これを使用して次の例と同様な条件付きサービスを設定できます。\n```\n\n```yaml\nservices:\n  nginx:\n    image: ${{ options.nginx == true && 'nginx' || '' }}\n```\n\n## `jobs.<job_id>.services.<service_id>.credentials`\n\nイメージのコンテナー レジストリでイメージをプルするための認証が必要な場合は、`jobs.<job_id>.container.credentials` を使って `username` と `password` の `map` を設定できます。 資格情報は、[`docker login`](https://docs.docker.com/engine/reference/commandline/login/) コマンドに指定するのと同じ値です。\n\n###\n\n```\n          `jobs.<job_id>.services.<service_id>.credentials` の例\n```\n\n```yaml\nservices:\n  myservice1:\n    image: ghcr.io/owner/myservice1\n    credentials:\n      username: ${{ github.actor }}\n      password: ${{ secrets.github_token }}\n  myservice2:\n    image: dockerhub_org/myservice2\n    credentials:\n      username: ${{ secrets.DOCKER_USER }}\n      password: ${{ secrets.DOCKER_PASSWORD }}\n```\n\n## `jobs.<job_id>.services.<service_id>.env`\n\nサービス コンテナーで環境変数の `map` を設定します。\n\n## `jobs.<job_id>.services.<service_id>.ports`\n\nサービス コンテナーで公開するポートの `array` を設定します。\n\n## `jobs.<job_id>.services.<service_id>.volumes`\n\n使うサービス コンテナーにボリュームの `array` を設定します。 volumes (ボリューム) を使用すると、サービス間で、または1つのジョブのステップ間でデータを共有できます。 指定できるのは、名前付きDockerボリューム、匿名Dockerボリューム、またはホスト上のバインドマウントです。\n\nボリュームを指定するには、次のソースパスとターゲットパスを指定してください。\n\n```\n          `<source>:<destinationPath>`。\n\n          `<source>` は、ホスト マシン上のボリューム名または絶対パスであり、`<destinationPath>` は、コンテナー内の絶対パスです。\n```\n\n###\n\n```\n          `jobs.<job_id>.services.<service_id>.volumes` の例\n```\n\n```yaml\nvolumes:\n  - my_docker_volume:/volume_mount\n  - /data/my_data\n  - /source/directory:/destination/directory\n```\n\n## `jobs.<job_id>.services.<service_id>.options`\n\n追加のDockerコンテナリソースのオプション。 オプションの一覧については、[`docker create` のオプション](https://docs.docker.com/engine/reference/commandline/create/#options)に関するページを参照してください。\n\n> \\[!WARNING]\n\n```\n          `--network` オプションはサポートされていません。\n```\n\n## `jobs.<job_id>.services.<service_id>.command`\n\nDocker イメージの既定のコマンド (`CMD`) をオーバーライドします。 値は、 `docker create` コマンドのイメージ名の後に引数として渡されます。\n`entrypoint`も指定した場合、`command`はそのエントリ ポイントに引数を提供します。\n\n###\n\n```\n          `jobs.<job_id>.services.<service_id>.command` の例\n```\n\n```yaml\nservices:\n  mysql:\n    image: mysql:8\n    command: --sql_mode=STRICT_TRANS_TABLES --max_allowed_packet=512M\n    env:\n      MYSQL_ROOT_PASSWORD: test\n    ports:\n      - 3306:3306\n```\n\n## `jobs.<job_id>.services.<service_id>.entrypoint`\n\nDocker イメージの既定の `ENTRYPOINT`をオーバーライドします。 この値は、実行する実行可能ファイルを定義する 1 つの文字列です。 これは、イメージのエントリポイントを完全に置き換える必要がある場合に使用します。\n`entrypoint`と`command`を組み合わせて、カスタム エントリポイントに引数を渡すことができます。\n\n###\n\n```\n          `jobs.<job_id>.services.<service_id>.entrypoint` の例\n```\n\n```yaml\nservices:\n  etcd:\n    image: quay.io/coreos/etcd:v3.5.17\n    entrypoint: etcd\n    command: >-\n      --listen-client-urls http://0.0.0.0:2379\n      --advertise-client-urls http://0.0.0.0:2379\n    ports:\n      - 2379:2379\n```\n\n## `jobs.<job_id>.uses`\n\nジョブとして実行する再利用可能なワークフロー ファイルの場所とバージョン。 次のいずれかの構文を使用します。\n\n* パブリックとプライベート リポジトリの再利用可能ワークフローの `{owner}/{repo}/.github/workflows/{filename}@{ref}`。\n* 同じリポジトリ内の再利用可能なワークフローの `./.github/workflows/{filename}`。\n\n最初のオプションで、`{ref}` には、SHA、リリース タグ、またはブランチ名を指定できます。 リリース タグとブランチの名前が同じ場合は、リリース タグがブランチの名前よりも優先されます。 コミット SHA を使用することが、安定性とセキュリティにとって最も安全なオプションです。 詳しくは、「[セキュリティで保護された使用に関するリファレンス](/ja/actions/security-guides/security-hardening-for-github-actions#reusing-third-party-workflows)」をご覧ください。\n\n2 番目の構文オプションを (`{owner}/{repo}` および `@{ref}` なしで) 使用する場合、呼び出されたワークフローは呼び出し元ワークフローと同じコミットから取得されます。 `refs/heads` や `refs/tags` などの ref プレフィックスは使用できません。 このキーワード中では、コンテキストや式を使うことはできません。\n\n###\n\n```\n          `jobs.<job_id>.uses` の例\n```\n\n```yaml\njobs:\n  call-workflow-1-in-local-repo:\n    uses: octo-org/this-repo/.github/workflows/workflow-1.yml@172239021f7ba04fe7327647b213799853a9eb89\n  call-workflow-2-in-local-repo:\n    uses: ./.github/workflows/workflow-2.yml\n  call-workflow-in-another-repo:\n    uses: octo-org/another-repo/.github/workflows/workflow.yml@v1\n```\n\n詳しくは、「[ワークフローを再利用する](/ja/actions/using-workflows/reusing-workflows)」をご覧ください。\n\n## `jobs.<job_id>.with`\n\nジョブを使って再利用可能なワークフローを呼び出す場合は、`with` を使って、呼び出し対象のワークフローに渡される入力のマップを指定することができます。\n\n渡す入力は、呼び出し対象のワークフローで定義されている入力仕様と一致する必要があります。\n\n```\n          [\n          `jobs.<job_id>.steps[*].with`\n          ](#jobsjob_idstepswith)とは異なり、`jobs.<job_id>.with`で渡した入力は、呼び出されたワークフローでは環境変数として利用できません。 代わりに、`inputs` コンテキストを使って入力を参照できます。\n```\n\n###\n\n```\n          `jobs.<job_id>.with` の例\n```\n\n```yaml\njobs:\n  call-workflow:\n    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n    with:\n      username: mona\n```\n\n## `jobs.<job_id>.with.<input_id>`\n\n入力の文字列識別子と入力の値で構成されるペア。 識別子は、呼び出し対象のワークフローで [`on.workflow_call.inputs.<inputs_id>`](/ja/actions/creating-actions/metadata-syntax-for-github-actions#inputsinput_id) によって定義された入力の名前と一致する必要があります。 値のデータ型は、呼び出し対象のワークフローで [`on.workflow_call.inputs.<input_id>.type`](#onworkflow_callinputsinput_idtype) によって定義された型と一致する必要があります。\n\n使用できる式コンテキスト: `github` と `needs`。\n\n## `jobs.<job_id>.secrets`\n\nジョブを使って再利用可能なワークフローを呼び出す場合は、`secrets` を使用して、呼び出し対象のワークフローに渡されるシークレットのマップを指定することができます。\n\n渡すシークレットは、呼び出し対象のワークフローで定義されている名前と一致する必要があります。\n\n###\n\n```\n          `jobs.<job_id>.secrets` の例\n```\n\n```yaml\njobs:\n  call-workflow:\n    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@main\n    secrets:\n      access-token: ${{ secrets.PERSONAL_ACCESS_TOKEN }}\n```\n\n## `jobs.<job_id>.secrets.inherit`\n\n```\n          `inherit` キーワードは、呼び出し元ワークフローのすべてのシークレットを呼び出し対象のワークフローに渡すために使います。 これには、呼び出し元ワークフローからアクセスできるすべてのシークレット (つまりOrganization、リポジトリ、環境のシークレット) が含まれます。 \n          `inherit` キーワードを使って、同じ Organization 内のリポジトリ間、または同じ Enterprise 内の Organization 間でシークレットを渡すことができます。\n```\n\n###\n\n```\n          `jobs.<job_id>.secrets.inherit` の例\n```\n\n```yaml\non:\n  workflow_dispatch:\n\njobs:\n  pass-secrets-to-workflow:\n    uses: ./.github/workflows/called-workflow.yml\n    secrets: inherit\n```\n\n```yaml\non:\n  workflow_call:\n\njobs:\n  pass-secret-to-action:\n    runs-on: ubuntu-latest\n    steps:\n      - name: Use a repo or org secret from the calling workflow.\n        run: echo ${{ secrets.CALLING_WORKFLOW_SECRET }}\n```\n\n## `jobs.<job_id>.secrets.<secret_id>`\n\nシークレットの文字列識別子とシークレットの値で構成されるペア。 識別子は、呼び出し対象のワークフローで [`on.workflow_call.secrets.<secret_id>`](#onworkflow_callsecretssecret_id) によって定義されたシークレットの名前と一致する必要があります。\n\n使用できる式コンテキスト: `github`、`needs`、`secrets`。\n\n## フィルター パターンの早見表\n\n特別なキャラクタをパス、ブランチ、タグフィルタで利用できます。\n\n* `*`: 0 個以上の文字と一致しますが、`/` 文字とは一致しません。 たとえば、`Octo*` は `Octocat` と一致します。\n* `**`: 0 個以上の任意の文字と一致します。\n* `?`: 直前の文字と0個または1個一致します。\n* `+`: 1 個以上の直前の文字と一致します。\n* `[]` 括弧内に一覧表示されているか、範囲に含まれている 1 つの英数字と一致します。 範囲には、`a-z`、`A-Z`、`0-9` のみを含めることができます。 たとえば、範囲 `[0-9a-z]` は任意の数字または小文字と一致します。 たとえば、`[CB]at` は `Cat` または`Bat` と、`[1-2]00` は `100` および `200` と一致します。\n* `!`: パターンの先頭に置くと、前の肯定のパターンを否定にします。 先頭のキャラクタではない場合は、特別な意味を持ちません。\n\n文字 `*`、`[`、`!` は YAML の特殊文字です。 パターンを `*`、`[`、`!` で開始する場合は、パターンを引用符で囲む必要があります。 また、使用する[フロー シーケンス](https://yaml.org/spec/1.2.2/#flow-sequences)に `[` と `]` の一方または両方を含むパターンがある場合は、パターンを引用符で囲む必要があります。\n\n```yaml\n# Valid\npaths:\n  - '**/README.md'\n\n# Invalid - creates a parse error that\n# prevents your workflow from running.\npaths:\n  - **/README.md\n\n# Valid\nbranches: [ main, 'release/v[0-9].[0-9]' ]\n\n# Invalid - creates a parse error\nbranches: [ main, release/v[0-9].[0-9] ]\n```\n\nブランチ、タグ、パスのフィルター構文について詳しくは、「[`on.<push>.<branches|tags>`](#onpushbranchestagsbranches-ignoretags-ignore)」、「[`on.<pull_request>.<branches|tags>`](#onpull_requestpull_request_targetbranchesbranches-ignore)」、「[`on.<push|pull_request>.paths`](#onpushpull_requestpull_request_targetpathspaths-ignore)」をご覧ください。\n\n### ブランチやタグにマッチするパターン\n\n| パターン                                        | 説明                                                    | マッチ例                                                                                          |\n| ------------------------------------------- | ----------------------------------------------------- | --------------------------------------------------------------------------------------------- |\n| `feature/*`                                 | ワイルドカード `*` は任意の文字と一致しますが、スラッシュ (`/`) とは一致しません。       | `feature/my-branch`<br/><br/>`feature/your-branch`                                            |\n| `feature/**`                                | ワイルドカード `**` は、ブランチおよびタグ名のスラッシュ (`/`) を含む任意の文字と一致します。 | `feature/beta-a/my-branch`<br/><br/>`feature/your-branch`<br/><br/>`feature/mona/the/octocat` |\n| `main`<br/><br/>`releases/mona-the-octocat` | ブランチあるいはタグ名に完全に一致したときにマッチします。                         | `main`<br/><br/>`releases/mona-the-octocat`                                                   |\n| `'*'`                                       | スラッシュ (`/`) を含まないすべてのブランチおよびタグ名と一致します。                |                                                                                               |\n\n```\n          `*` 文字は YAML の特殊文字です。 パターンを `*` で開始する場合は、引用符を使う必要があります。 | `main`<br/><br/>`releases`                                                                    |\n```\n\n\\| `'**'`                                      | すべてのブランチ及びタグ名にマッチします。 これは、`branches` または `tags` フィルターを使わない場合の既定の動作です。                                                             | `all/the/branches`<br/><br/>`every/tag`                                                       |\n\\| `'*feature'`                                |\n`*` 文字は YAML の特殊文字です。 パターンを `*` で開始する場合は、引用符を使う必要があります。                                                                    | `mona-feature`<br/><br/>`feature`<br/><br/>`ver-10-feature`                                   |\n\\| `v2*`                                       |\n`v2` で始まるブランチおよびタグ名と一致します。                                                                                                                           | `v2`<br/><br/>`v2.0`<br/><br/>`v2.9`                                                          |\n\\| `v[12].[0-9]+.[0-9]+`                       | メジャー バージョンが 1 または 2 のすべてのセマンティック バージョニング ブランチおよびタグと一致します。                                                                                                 | `v1.10.1`<br/><br/>`v2.0.0`                                                                   |\n\n### ファイルパスにマッチするパターン\n\nパスパターンはパス全体にマッチしなければならず、リポジトリのルートを出発点とします。\n\n| パターン  | マッチの説明                                          | マッチ例 |\n| ----- | ----------------------------------------------- | ---- |\n| `'*'` | ワイルドカード `*` は任意の文字と一致しますが、スラッシュ (`/`) とは一致しません。 |      |\n\n```\n          `*` 文字は YAML の特殊文字です。 パターンを `*` で開始する場合は、引用符を使う必要があります。             | `README.md`<br/><br/>`server.rb`                                                        |\n```\n\n\\| `'*.jsx?'`                                          |\n`?` 文字は 0 個または 1 個の直前の文字と一致します。                                                                                                                             | `page.js`<br/><br/>`page.jsx`                                                           |\n\\| `'**'`                                              | ワイルドカード `**` は、スラッシュ (`/`) を含む任意の文字と一致します。 これは、`path` フィルターを使わない場合の既定の動作です。                                                               | `all/the/files.md`                                                                      |\n\\| `'*.js'`                                            | ワイルドカード `*` は任意の文字と一致しますが、スラッシュ (`/`) とは一致しません。 リポジトリのルートにあるすべての `.js` ファイルと一致します。                                                                | `app.js`<br/><br/>`index.js`                                                            |\n\\| `'**.js'`                                           | リポジトリにあるすべての `.js` ファイルと一致します。                                                                                                                                                    | `index.js`<br/><br/>`js/index.js`<br/><br/>`src/js/app.js`                              |\n\\| `docs/*`                                            | リポジトリのルートにある `docs` ディレクトリのルート内のすべてのファイルのみ。                                                                                                             | `docs/README.md`<br/><br/>`docs/file.txt`                                               |\n\\| `docs/**`                                           | リポジトリのルートにある `docs` ディレクトリとそのサブディレクトリ内の任意のファイル。                                                                                                                             | `docs/README.md`<br/><br/>`docs/mona/octocat.txt`                                       |\n\\| `docs/**/*.md`                                      |\n`.md` ディレクトリ内の任意の場所にある `docs` サフィックスが付いたファイル。                                                                                                                                  | `docs/README.md`<br/><br/>`docs/mona/hello-world.md`<br/><br/>`docs/a/markdown/file.md` |\n\\| `'**/docs/**'`                                      | リポジトリの任意の場所にある `docs` ディレクトリ内の任意のファイル。                                                                                                                                   | `docs/hello.md`<br/><br/>`dir/docs/my-file.txt`<br/><br/>`space/docs/plan/space.doc`    |\n\\| `'**/README.md'`                                    | リポジトリ内のどこにでもあるREADME.mdファイル。                                                                                                                                                  | `README.md`<br/><br/>`js/README.md`                                                     |\n\\| `'**/*src/**'`                                      | リポジトリの任意の場所にある `src` サフィックスが付いたフォルダ内の任意のファイル。                                                                                                                          | `a/src/app.js`<br/><br/>`my-src/code/js/app.js`                                         |\n\\| `'**/*-post.md'`                                    | リポジトリの任意の場所にあるサフィックス `-post.md` が付いたファイル。                                                                                                                                 | `my-post.md`<br/><br/>`path/their-post.md`                                              |\n\\| `'**/migrate-*.sql'`                                | リポジトリの任意の場所にあるプレフィックス `migrate-` とサフィックス `.sql` が付いたファイル。                                                                                                               | `migrate-10909.sql`<br/><br/>`db/migrate-v1.0.sql`<br/><br/>`db/sept/migrate-v1.sql`    |\n\\| `'*.md'`<br/><br/>`'!README.md'`                    | 感嘆符 (`!`) をパターンの前で使うと否定になります。 あるファイルがあるパターンにマッチし、ファイル中でその後に定義されている否定パターンにマッチした場合、そのファイルは含まれません。 | `hello.md`<br/><br/>\n*一致しない*<br/><br/>`README.md`<br/><br/>`docs/hello.md`      |\n\\| `'*.md'`<br/><br/>`'!README.md'`<br/><br/>`README*` | パターンは順番にチェックされます。 先行するパターンを否定するパターンで、ファイルパスが再度含まれるようになります。                                                                                      | `hello.md`<br/><br/>`README.md`<br/><br/>`README.doc`                                   |"}