# ワークフローで事前に作成されたビルディング ブロックを使用する
あらかじめ記述されたアクションを使用およびカスタマイズして、ワークフローを強化できます。
## ワークフローエディタで Marketplace アクションを参照する
リポジトリのワークフローエディタで、直接アクションを検索し、ブラウズできます。 サイドバーから特定のアクションを検索し、注目のアクションを見て、注目のカテゴリをブラウズできます。 また、アクションがGitHubコミュニティから受けたStarの数も見ることができます。
1. リポジトリで、編集したいワークフローファイルにアクセスします。
2. ファイル ビューの右上隅の をクリックして、ワークフロー エディターを開きます。
1. エディタの右側でGitHub Marketplaceサイドバーを使ってアクションをブラウズしてください。 バッジを持つアクションは、 GitHub がパートナー組織としてアクションの作成者を検証したことを示します。
## ワークフローにアクションを追加する
ワークフロー ファイル内のアクションを参照することで、ワークフローにアクションを追加できます。 ワークフローで使用するアクションは、以下の場所で定義できます。
* ワークフロー ファイルと同じリポジトリ
* すべてのパブリック リポジトリ
* Docker Hubに公開されたDockerコンテナイメージ
GitHub Actions ワークフローで参照されているアクションは、ワークフローを含むリポジトリの依存関係グラフで依存関係として表示できます。 詳細については、「[依存関係グラフについて](/ja/code-security/supply-chain-security/understanding-your-software-supply-chain/about-the-dependency-graph)」を参照してください。
> \[!NOTE]
> セキュリティを強化するため、GitHub Actions はアクションまたは再利用可能なワークフローのリダイレクトをサポートしません。 つまり、所有者、アクションのリポジトリの名前、またはアクションの名前が変更されると、そのアクションを以前の名前で使用するすべてのワークフローは失敗します。
### GitHub Marketplace からのアクションの追加
アクションのリストのページには、アクションのバージョンと、そのアクションを利用するために必要なワークフローの構文が含まれています。 アクションが更新された場合でもワークフローを安定させるために、ワークフローファイルで Git または Docker タグ番号を指定することにより、使用するアクションのバージョンを参照できます。
1. ワークフローで使いたいアクションにアクセスしてください。
2. クリックすると、マーケットプレースに登録されているそのアクションの完全な情報を参照できます。
3. \[インストール] の下で、 をクリックしてワークフローの構文をコピーします。
![マーケットプレースに登録されているそのアクションの完全な情報のスクリーンショット。 そのアクションの \[クリップボードにコピー\] アイコンが濃いオレンジ色の輪郭で強調表示されています。](/assets/images/help/repository/actions-sidebar-detailed-view.png)
1. この構文をワークフロー中に新しいステップとして貼り付けてください。 詳しくは、「[GitHub Actions のワークフロー構文](/ja/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idsteps)」をご覧ください。
2. アクションで入力が必要な場合は、ワークフローで設定します。 アクションで必要な可能性がある入力については、「[ワークフローで事前に作成されたビルディング ブロックを使用する](/ja/actions/learn-github-actions/finding-and-customizing-actions#using-inputs-and-outputs-with-an-action)」をご覧ください。
ワークフローに追加したアクションに対してDependabot version updatesを有効化することもできます。 詳しくは、「[Dependabot でアクションを最新に保つ](/ja/code-security/dependabot/working-with-dependabot/keeping-your-actions-up-to-date-with-dependabot)」をご覧ください。
### 同じリポジトリからのアクションの追加
ワークフロー ファイルがアクションを使用するのと同じリポジトリでアクションが定義されている場合、そのアクションはワークフロー ファイル内の `{owner}/{repo}@{ref}` または `./path/to/dir` 構文を使用して参照できます。
リポジトリ ファイル構造の例:
```shell
|-- hello-world (repository)
| |__ .github
| └── workflows
| └── my-first-workflow.yml
| └── actions
| |__ hello-world-action
| └── action.yml
```
パスはデフォルトの作業ディレクトリ (`github.workspace`、`$GITHUB_WORKSPACE`) に対する相対パス (`./`) です。 アクションがワークフローとは異なる場所にリポジトリをチェックアウトする場合は、ローカル アクションに使用される相対パスを更新する必要があります。
ワークフロー ファイルの例:
```yaml
jobs:
my_first_job:
runs-on: ubuntu-latest
steps:
# This step checks out a copy of your repository.
- name: My first step - check out repository
uses: actions/checkout@v6
# This step references the directory that contains the action.
- name: Use local hello-world-action
uses: ./.github/actions/hello-world-action
```
この `action.yml` ファイルは、アクションのメタデータを提供するために使用されます。 このファイルの内容については、「[メタデータ構文リファレンス](/ja/actions/creating-actions/metadata-syntax-for-github-actions)」をご覧ください。
### 別のリポジトリからのアクションの追加
アクションがワークフロー ファイルとは異なるリポジトリで定義されている場合は、ワークフロー ファイル内で `{owner}/{repo}@{ref}` 構文を使用してアクションを参照できます。
アクションはパブリック リポジトリに格納する必要があります。。
```yaml
jobs:
my_first_job:
steps:
- name: My first step
uses: actions/setup-node@v4
```
### Docker Hubでのコンテナーの参照
Docker Hubの発行済み Docker コンテナー イメージでアクションが定義されている場合は、ワークフロー ファイルで `docker://{image}:{tag}` 構文を使用してアクションを参照する必要があります。 コードとデータを保護するには、ワークフローで使用する前に、Docker コンテナー イメージの整合性をDocker Hubから確認することを強くお勧めします。
```yaml
jobs:
my_first_job:
steps:
- name: My first step
uses: docker://alpine:3.8
```
Docker アクションの例については、[Docker-image.yml ワークフロー](https://github.com/actions/starter-workflows/blob/main/ci/docker-image.yml)と「[Docker コンテナーのアクションを作成する](/ja/actions/creating-actions/creating-a-docker-container-action)」をご覧ください。
### ワークフローでアクションを使用するためのセキュリティ強化
GitHubは、ワークフローのセキュリティを強化するために使用できるセキュリティ機能が用意されています。 GitHubのビルトイン機能を使用し、実行するアクションの脆弱性に関する通知を受け取ったり、ワークフロー内のアクションを最新の状態に保つプロセスを自動化したりできます。 詳しくは、「[セキュリティで保護された使用に関するリファレンス](/ja/actions/security-guides/using-githubs-security-features-to-secure-your-use-of-github-actions)」をご覧ください。
## カスタムアクションにリリース管理を使用する
コミュニティアクションの作者は、タグ、ブランチ、または SHA 値を使用してアクションのリリースを管理するオプションがあります。 他の依存関係と同様に、アクションの更新を自動的に受け入れる際のお好みに応じて、使用するアクションのバージョンを指定する必要があります。
ワークフローファイルでアクションのバージョンを指定します。 リリース管理へのアプローチに関する情報、および使用するタグ、ブランチ、または SHA 値を確認するには、アクションのドキュメントを確認してください。
> \[!NOTE]
> サードパーティのアクションを使用する場合は、SHA 値を使用することをお勧めします。 ただし、Dependabot では、セマンティック バージョン管理を使用する脆弱な Dependabot alerts に対してのみ GitHub Actions が作成されることに注意してください。 詳細については、「[セキュリティで保護された使用に関するリファレンス](/ja/actions/security-guides/security-hardening-for-github-actions#using-third-party-actions)」および「[Dependabot alerts](/ja/code-security/dependabot/dependabot-alerts/about-dependabot-alerts)」を参照してください。
### タグの使用
タグは、メジャーバージョンとマイナーバージョンの切り替えタイミングを決定するときに役立ちますが、これらはより一過性のものであり、メンテナから移動または削除される可能性があります。 この例では、`v1.0.1` としてタグ付けされたアクションをターゲットにする方法を示しています。
```yaml
steps:
- uses: actions/javascript-action@v1.0.1
```
### SHA の使用
より信頼性の高いバージョン管理が必要な場合は、アクションのバージョンに関連付けられた SHA 値を使用する必要があります。 SHA は不変であるため、タグやブランチよりも信頼性が高くなります。 ただし、このアプローチは、重要なバグ修正やセキュリティ更新プログラムなどのアクションの更新を自動的に受信しないことを意味します。 短縮された値ではなく、コミットの完全な SHA 値を使う必要があります。 SHA を選択するときは、アクションのリポジトリからであり、リポジトリ フォークではないことを確認してください。 この例では、アクションの SHA をターゲットにしています。
```yaml
steps:
- uses: actions/javascript-action@a824008085750b8e136effc585c3cd6082bd575f
```
### ブランチの使用
アクションのターゲットブランチを指定すると、そのブランチに現在あるバージョンが常に実行されます。 ブランチの更新に重大な変更が含まれている場合、このアプローチは問題を引き起こす可能性があります。 この例では、`@main` という名前のブランチを対象とします。
```yaml
steps:
- uses: actions/javascript-action@main
```
詳しくは、「[カスタム アクションについて](/ja/actions/creating-actions/about-custom-actions#using-release-management-for-actions)」をご覧ください。
## アクションで入力と出力を使用する
多くの場合、アクションは入力を受け入れたり要求したりして、使用できる出力を生成します。 たとえば、アクションでは、ファイルへのパス、ラベルの名前、またはアクション処理の一部として使用するその他のデータを指定する必要がある場合があります。
アクションの入力と出力を確認するには、リポジトリのルート ディレクトリの `action.yml` を確認します。
この `action.yml` の例では、`inputs` キーワードによって `file-path` という名前の必須の入力が定義され、何も指定されていない場合に使用される既定値が含まれています。
`outputs` キーワードは、結果を配置する場所を示す `results-file` という名前の出力を定義します。
```yaml
name: "Example"
description: "Receives file and generates output"
inputs:
file-path: # id of input
description: "Path to test script"
required: true
default: "test-file.js"
outputs:
results-file: # id of output
description: "Path to results file"
```