{"meta":{"title":"ワークフローを再利用する","intro":"既存のワークフローを再利用してワークフローを作成するときに重複を回避する方法について説明します。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/ja/enterprise-cloud@latest/actions/how-tos","title":"方法"},{"href":"/ja/enterprise-cloud@latest/actions/how-tos/reuse-automations","title":"自動化の再利用"},{"href":"/ja/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows","title":"ワークフローを再利用する"}],"documentType":"article"},"body":"# ワークフローを再利用する\n\n既存のワークフローを再利用してワークフローを作成するときに重複を回避する方法について説明します。\n\n## 再利用可能なワークフローの作成\n\n再利用可能なワークフローは、他のワークフロー ファイルとよく似た YAML 形式のファイルです。 他のワークフロー ファイルと同様に、再利用可能なワークフローは、リポジトリの `.github/workflows` ディレクトリ内にあります。\n`workflows` ディレクトリのサブディレクトリはサポートされていません。\n\n特定の再利用可能なワークフローのみを実行できるセルフホステッド ランナー グループを作成することで、デプロイを標準化できます。 詳細については、 [AUTOTITLE を](/ja/enterprise-cloud@latest/actions/how-tos/manage-runners/self-hosted-runners/manage-access)参照してください。\n\nワークフローを再利用可能にするには、 `on` の値に `workflow_call` を含める必要があります。\n\n```yaml\non:\n  workflow_call:\n```\n\n## 再利用可能なワークフローでの入力とシークレットの使用\n\n入力とシークレットを定義し、呼び出し元のワークフローから渡して、呼び出し先ワークフロー内で使用できます。 再利用可能なワークフローで入力またはシークレットを使用するには、3 つの段階があります。\n\n1. 再利用可能なワークフローで、`inputs` と `secrets` のキーワードを使用して、呼び出し元ワークフローから渡す入力またはシークレットを定義します。\n\n   ```yaml\n   on:\n     workflow_call:\n       inputs:\n         config-path:\n           required: true\n           type: string\n       secrets:\n         personal_access_token:\n           required: true\n   ```\n\n   入力とシークレットを定義するための構文の詳細については、 [`on.workflow_call.inputs`](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_callinputs) と [`on.workflow_call.secrets`](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_callsecrets)を参照してください。\n\n2. 再利用可能なワークフローで、前の手順で `on` キーに定義した入力またはシークレットを参照します。\n\n   > \\[!NOTE]\n   > 注: 呼び出し元ワークフローで `secrets: inherit` を使用してシークレットが継承されている場合は、`on` キーに明示的に定義されていない場合でも参照できます。 詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretsinherit)」をご覧ください。\n\n   ```yaml\n   jobs:\n     reusable_workflow_job:\n       runs-on: ubuntu-latest\n       steps:\n       - uses: actions/labeler@v6\n         with:\n           repo-token: ${{ secrets.personal_access_token }}\n           configuration-path: ${{ inputs.config-path }}\n   ```\n\n   上記の例では、 `personal_access_token` リポジトリまたは組織レベルで定義されているシークレットです。\n\n   > \\[!WARNING]\n   > `on.workflow_call` は `environment` キーワード (keyword) をサポートしていないため、呼び出し元のワークフローから環境シークレットを渡すことはできません。 `environment`再利用可能なワークフローにジョブ レベルで含める 場合、呼び出し元のワークフローから渡されたシークレットではなく、環境シークレットが使用されます。 詳細については、「[デプロイメント用の環境管理](/ja/enterprise-cloud@latest/actions/how-tos/deploy/configure-and-manage-deployments/manage-environments)」および「[GitHub Actions　のワークフロー構文](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_call)」を参照してください。\n\n3. 呼び出し元ワークフローから入力またはシークレットを渡します。\n\n   名前付き入力を呼び出されたワークフローに渡すには、ジョブで `with` キーワードを使用します。 `secrets` キーワードを使用して名前付きシークレットを渡します。 入力の場合、入力値のデータ型は、呼び出されたワークフローで指定された型 (ブール値、数値、または文字列) と一致する必要があります。\n\n   ```yaml\n   jobs:\n     call-workflow-passing-data:\n       uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n       with:\n         config-path: .github/labeler.yml\n       secrets:\n         personal_access_token: ${{ secrets.token }}\n   ```\n\n   同じ organization または Enterprise 内の再利用可能なワークフローを呼び出すワークフローでは、`inherit` キーワードを使ってシークレットを暗黙的に渡すことができます。\n\n   ```yaml\n   jobs:\n     call-workflow-passing-data:\n       uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n       with:\n         config-path: .github/labeler.yml\n       secrets: inherit\n   ```\n\n### 再利用可能なワークフローの例\n\nこの再利用可能な `workflow-B.yml` という名前のワークフロー ファイル (後述の[呼び出し元ワークフローの例](#example-caller-workflow)でこれを参照します) では、入力文字列とシークレットを呼び出し元ワークフローから受け取り、それらをアクションで使用します。\n\n```yaml copy\nname: Reusable workflow example\n\non:\n  workflow_call:\n    inputs:\n      config-path:\n        required: true\n        type: string\n    secrets:\n      token:\n        required: true\n\njobs:\n  triage:\n    runs-on: ubuntu-latest\n    steps:\n    - uses: actions/labeler@v6\n      with:\n        repo-token: ${{ secrets.token }}\n        configuration-path: ${{ inputs.config-path }}\n```\n\n## 再利用可能なワークフローの呼び出し\n\n`uses` キーワードを使用して、再利用可能なワークフローを呼び出します。 ワークフロー内でアクションを使用する場合とは異なり、ジョブ ステップ内からではなく、ジョブ内で再利用可能なワークフローを直接呼び出します。\n\n[`jobs.<job_id>.uses`](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_iduses)\n\n再利用可能なワークフロー ファイルを参照するには、次のいずれかの構文を使用します：\n\n* `$/.github/workflows/{filename}` 同じリポジトリ内の再利用可能なワークフローの場合。 これは、同じリポジトリ内の再利用可能なワークフローを参照するための推奨構文です。 この構文は、 GitHub Enterprise Serverでは使用できません。\n* `{owner}/{repo}/.github/workflows/{filename}@{ref}`\n  、パブリック リポジトリ、内部リポジトリ、プライベート リポジトリの再利用可能なワークフロー向け\n* `./.github/workflows/{filename}` 同じリポジトリ内の再利用可能なワークフロー用。\n\n`{owner}/{repo}`と`@{ref}`を使用して再利用可能なワークフローを参照する場合、`{ref}`には SHA、リリース タグ、またはブランチ名を指定できます。 リリース タグとブランチの名前が同じ場合は、リリース タグがブランチの名前よりも優先されます。 コミット SHA を使用することが、安定性とセキュリティにとって最も安全なオプションです。 詳しくは、「[セキュリティで保護された使用に関するリファレンス](/ja/enterprise-cloud@latest/actions/reference/security/secure-use#reusing-third-party-workflows)」をご覧ください。\n\n`$/`または`./` (`{owner}/{repo}`および`@{ref}`なし) を使用して同じリポジトリ内の再利用可能なワークフローを参照する場合、呼び出されたワークフローは呼び出し元ワークフローと同じコミットから取得されます。\n`$/`参照には`@{ref}`サフィックスを含めてはなりません。また、`$/`はGitHub Enterprise Serverで使用できません。\n`refs/heads` や `refs/tags` などの ref プレフィックスは使用できません。 このキーワード中では、コンテキストや式を使うことはできません。\n\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  # The `$/` syntax is not available in GitHub Enterprise Server.\n  call-workflow-in-same-repo-at-running-commit:\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### 呼び出し元ワークフローの例\n\nこのワークフロー ファイルでは、2 つのワークフロー ファイルを呼び出します。 このうち 2 つ目の `workflow-B.yml` ([再利用可能なワークフローの例](#example-reusable-workflow)に示されています) では、入力 (`config-path`) とシークレット (`token`) が渡されます。\n\n```yaml copy\nname: Call a reusable workflow\n\non:\n  pull_request:\n    branches:\n      - main\n\njobs:\n  call-workflow:\n    uses: octo-org/example-repo/.github/workflows/workflow-A.yml@v1\n\n  call-workflow-passing-data:\n    permissions:\n      contents: read\n      pull-requests: write\n    uses: octo-org/example-repo/.github/workflows/workflow-B.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets:\n      token: ${{ secrets.GITHUB_TOKEN }}\n```\n\n## 再利用可能なワークフローに入力とシークレットを渡す\n\n名前付き入力を呼び出されたワークフローに渡すには、ジョブで `with` キーワードを使用します。 `secrets` キーワードを使用して名前付きシークレットを渡します。 入力の場合、入力値のデータ型は、呼び出されたワークフローで指定された型 (ブール値、数値、または文字列) と一致する必要があります。\n\n```yaml\njobs:\n  call-workflow-passing-data:\n    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets:\n      personal_access_token: ${{ secrets.token }}\n```\n\n同じ organization または Enterprise 内の再利用可能なワークフローを呼び出すワークフローでは、`inherit` キーワードを使ってシークレットを暗黙的に渡すことができます。\n\n```yaml\njobs:\n  call-workflow-passing-data:\n    uses: octo-org/example-repo/.github/workflows/reusable-workflow.yml@main\n    with:\n      config-path: .github/labeler.yml\n    secrets: inherit\n```\n\n## 再利用可能なワークフローでのマトリックス戦略の使用\n\nマトリックス戦略を使用するジョブでは、再利用可能なワークフローを呼び出すことができます。\n\nマトリックス戦略を使用すると、1 つのジョブ定義で変数を使用して、変数の組み合わせに基づく複数のジョブ実行を自動的に作成できます。 たとえば、マトリックス戦略を使用して、再利用可能なワークフローに異なる入力を渡すことができます。 マトリックスの詳細については、「[ワークフローでのジョブのバリエーションの実行](/ja/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-what-workflows-do/run-job-variations)」を参照してください。\n\n次のジョブ例では、再利用可能なワークフローを呼び出し、値 `target` を使用して変数 `[dev, stage, prod]` を定義することによってマトリックス コンテキストを参照します。 変数の値ごとに 1 つずつ、3 つのジョブが実行されます。\n\n```yaml copy\njobs:\n  ReusableMatrixJobForDeployment:\n    strategy:\n      matrix:\n        target: [dev, stage, prod]\n    uses: octocat/octo-repo/.github/workflows/deployment.yml@main\n    with:\n      target: ${{ matrix.target }}\n```\n\n## 再利用可能なワークフローを入れ子にする\n\n最上位レベルの呼び出し元ワークフローと最大 9 レベルの再利用可能なワークフローなど、最大 レベルのワークフローを接続できます。 たとえば、*caller-workflow\\.yml* → *called-workflow-1.yml* → *called-workflow-2.yml* → *called-workflow-3.yml* → ... → *called-workflow-9.yml*。\n\nワークフロー ツリー内のループは許可されません。\n\n> \\[!NOTE] 入れ子になった再利用可能なワークフローでは、チェーン内のすべてのワークフローに呼び出し元がアクセスできる必要があります。アクセス許可は、チェーン全体を通して維持または降格されるだけであり、昇格されることはありません。 詳しくは、「[ワークフロー構成の再利用](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/reusing-workflow-configurations)」をご覧ください。\n\n再利用可能なワークフロー内から、別の再利用可能なワークフローを呼び出すことができます。\n\n```yaml copy\nname: Reusable workflow\n\non:\n  workflow_call:\n\njobs:\n  call-another-reusable:\n    uses: octo-org/example-repo/.github/workflows/another-reusable.yml@v1\n```\n\n## 入れ子になったワークフローにシークレットを渡す\n\n呼び出し元ワークフローで `jobs.<job_id>.secrets` を使用して、直接呼び出されたワークフローに名前付きシークレットを渡すことができます。 または、`jobs.<job_id>.secrets.inherit` を使用して、呼び出し元ワークフローのすべてのシークレットを直接呼び出されたワークフローに渡すことができます。 詳しくは、上記の「[ワークフローを再利用する](/ja/enterprise-cloud@latest/actions/how-tos/reuse-automations/reuse-workflows#passing-inputs-and-secrets-to-a-reusable-workflow)」セクションと、参照記事「[GitHub Actions　のワークフロー構文](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idsecretsinherit)」を参照してください。 シークレットは直接呼び出されたワークフローにのみ渡されるため、ワークフロー チェーン A > B > C、ワークフロー C では、A から B に、次に B から C に渡された場合にのみ A からシークレットを受け取ります。\n\n次の例では、ワークフロー A で `inherit` キーワードを使用してすべてのシークレットをワークフロー B に渡しますが、ワークフロー B ではワークフロー C に 1 つのシークレットのみを渡します。ワークフロー B に渡されるその他のシークレットはいずれもワークフロー C では使用できません。\n\n```yaml\njobs:\n  workflowA-calls-workflowB:\n    uses: octo-org/example-repo/.github/workflows/B.yml@main\n    secrets: inherit # pass all secrets\n```\n\n```yaml\njobs:\n  workflowB-calls-workflowC:\n    uses: different-org/example-repo/.github/workflows/C.yml@main\n    secrets:\n      repo-token: ${{ secrets.personal_access_token }} # pass just this secret\n```\n\n## 再利用可能なワークフローからの出力の使用\n\n再利用可能なワークフローでは、呼び出し元ワークフローで使用するデータが生成される場合があります。 これらの出力を使用するには、再利用可能なワークフローの出力として指定する必要があります。\n\n出力を設定する再利用可能なワークフローがマトリックス戦略で実行される場合、その出力は、実際に値を設定するマトリックスの最後の正常に完了した再利用可能なワークフローで設定された出力になります。\nつまり、最後の正常に完了した再利用可能なワークフローでその出力に空の文字列が設定され、最後から 2 番目の正常に完了した再利用可能なワークフローでその出力の実際の値が設定された場合、出力には最後から 2 番目の完了した再利用可能なワークフローの値が含まれます。\n\n次の再利用可能なワークフローには、2 つのステップを含む 1 つのジョブがあります。 これらの各ステップでは、\"hello\" と \"world\" という 1 つの単語を出力として設定します。 ジョブの `outputs` セクションでは、これらのステップの出力を、`output1` と `output2` というジョブ出力にマップします。 次に `on.workflow_call.outputs` セクションで、ワークフロー自体に対して 2 つの出力を定義します。1 つは `firstword` といい `output1` にマップされ、もう 1 つは `secondword` といい `output2` にマップされます。\n\n`value` は、呼び出されたワークフロー内のジョブ レベルの出力の値に設定する必要があります。 次に示すように、ステップ レベルの出力はまずジョブ レベルの出力にマップする必要があります。\n\n詳細については、「[ジョブ間で情報を渡す](/ja/enterprise-cloud@latest/actions/how-tos/write-workflows/choose-what-workflows-do/pass-job-outputs)」および「[GitHub Actions　のワークフロー構文](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#onworkflow_calloutputs)」を参照してください。\n\n```yaml copy\nname: Reusable workflow\n\non:\n  workflow_call:\n    # Map the workflow outputs to job outputs\n    outputs:\n      firstword:\n        description: \"The first output string\"\n        value: ${{ jobs.example_job.outputs.output1 }}\n      secondword:\n        description: \"The second output string\"\n        value: ${{ jobs.example_job.outputs.output2 }}\n\njobs:\n  example_job:\n    name: Generate output\n    runs-on: ubuntu-latest\n    # Map the job outputs to step outputs\n    outputs:\n      output1: ${{ steps.step1.outputs.firstword }}\n      output2: ${{ steps.step2.outputs.secondword }}\n    steps:\n      - id: step1\n        run: echo \"firstword=hello\" >> $GITHUB_OUTPUT\n      - id: step2\n        run: echo \"secondword=world\" >> $GITHUB_OUTPUT\n```\n\nこれで、同じワークフロー内のジョブからの出力を使用するのと同じ方法で、呼び出し元ワークフローの出力を使用できるようになりました。 再利用可能なワークフローのワークフロー レベルで定義した名前、`firstword` と `secondword` を使用して、出力を参照します。 このワークフローでは、`job1` によって再利用可能なワークフローが呼び出され、`job2` によって再利用可能なワークフローの出力 (\"hello world\") がワークフロー ログの標準出力に出力されます。\n\n```yaml copy\nname: Call a reusable workflow and use its outputs\n\non:\n  workflow_dispatch:\n\njobs:\n  job1:\n    uses: octo-org/example-repo/.github/workflows/called-workflow.yml@v1\n\n  job2:\n    runs-on: ubuntu-latest\n    needs: job1\n    steps:\n      - run: echo ${{ needs.job1.outputs.firstword }} ${{ needs.job1.outputs.secondword }}\n```\n\nジョブの出力の使用について詳しくは、「[GitHub Actions　のワークフロー構文](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idoutputs)」を参照してください。 ワークフロー間で変数以外の変数 (ビルド成果物など) を共有する場合は、「[ワークフロー成果物を使ったデータの格納と共有](/ja/enterprise-cloud@latest/actions/tutorials/store-and-share-data)」を参照してください。\n\n## 使用されているワークフローの監視\n\nGitHub REST API を使用して、再利用可能なワークフローがどのように使用されているかを監視できます。\n`prepared_workflow_job` 監査ログ アクションは、ワークフロー ジョブが開始されるとトリガーされます。 記録されるデータには次のものが含まれます。\n\n* `repo` - ワークフロー ジョブが配置されている Organization/リポジトリ。 別のワークフローを呼び出すジョブの場合、これは呼び出し元ワークフローの Organization/リポジトリです。\n* `@timestamp` - ジョブが開始された日時 (UNIX エポック形式)。\n* `job_name` - 実行されたジョブの名前。\n* `calling_workflow_refs` - このワークフロー ジョブに関係するすべての呼び出し元ワークフローのファイル パスの配列。 配列内の項目は、呼び出された逆の順序になります。 たとえば、ワークフロー A > B > C のチェーンでは、ワークフロー C 内のジョブのログを表示する場合、配列は `[\"octo-org/octo-repo/.github/workflows/B.yml\", \"octo-org/octo-repo/.github/workflows/A.yml\"]` になります。\n* `calling_workflow_shas` - このワークフロー ジョブに関係するすべての呼び出し元ワークフローの SHA の配列。 配列には、`calling_workflow_refs` 配列と同じ順序で同じ数の項目が含まれています。\n* `job_workflow_ref` - 使用されたワークフロー ファイル。形式は `{owner}/{repo}/{path}/{filename}@{ref}`。 別のワークフローを呼び出すジョブの場合、これは呼び出し先ワークフローを示します。\n\n詳しくは、「[あなたの組織の監査ログを確認する](/ja/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-security-settings-for-your-organization/reviewing-the-audit-log-for-your-organization#using-the-audit-log-api)」をご覧ください。\n\n> \\[!NOTE]\n> 注: `prepared_workflow_job` の監査データは、REST API を使用してのみ表示できます。 これは、 GitHub Web インターフェイスには表示されず、JSON/CSV エクスポートされた監査データにも含まれません。\n\n## 次のステップ\n\nワークフローの再利用の複雑さの詳細については、「[ワークフロー構成の再利用](/ja/enterprise-cloud@latest/actions/reference/workflows-and-actions/reusing-workflow-configurations)」を参照してください。"}