{"meta":{"title":"GITHUB_TOKEN","intro":"GITHUB_TOKENとは何か、そのしくみ、GitHub Actionsワークフローの安全な自動化にとって重要な理由について説明します。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/actions","title":"GitHub Actions"},{"href":"/ja/actions/concepts","title":"概念"},{"href":"/ja/actions/concepts/security","title":"セキュリティ"},{"href":"/ja/actions/concepts/security/github_token","title":"GITHUB_TOKEN"}],"documentType":"article"},"body":"# GITHUB_TOKEN\n\nGITHUB_TOKENとは何か、そのしくみ、GitHub Actionsワークフローの安全な自動化にとって重要な理由について説明します。\n\n## `GITHUB_TOKEN` について\n\n各ワークフロー ジョブの開始時 GitHub 、ワークフローで使用する一意の `GITHUB_TOKEN` シークレットが自動的に作成されます。\n`GITHUB_TOKEN` はワークフロー ジョブでの認証に使用できます。\n\nGitHub Actionsを有効にすると、GitHubはリポジトリにGitHub Appをインストールします。\n`GITHUB_TOKEN` シークレットは、GitHub Appインストール アクセス トークンです。 インストール アクセス トークンを使用して、リポジトリにインストールされている GitHub App に代わって認証できます。 このトークンの権限は、ワークフローを含むリポジトリに限定されます。 詳細については、「[GitHub Actions　のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#permissions)」を参照してください。\n\n各ジョブが開始される前に、 GitHub はジョブのインストール アクセス トークンをフェッチします。\n`GITHUB_TOKEN`は、ジョブが終了するか、最大有効期間が経過すると期限切れになります。\n\nトークンの有効な最大有効期間は、ランナーの種類によって異なります。\n\n* **GitHub-hosted runners** ジョブの最大実行時間は 6 時間であるため、 `GITHUB_TOKEN` は最大 6 時間有効です。\n* **セルフホステッド ランナー** ジョブの最大実行時間は 5 日です。 ただし、`GITHUB_TOKEN` はインストール access トークンであるため、更新できるのは最大 24 時間です。 ジョブの実行時間が 24 時間を超える場合は、代わりに personal access token またはその他の認証方法を使用します。\n\nトークンは、`github.token` コンテキストでも使用できます。 詳細については、「[コンテキスト リファレンス](/ja/actions/reference/workflows-and-actions/contexts#github-context)」を参照してください。\n\n## `GITHUB_TOKEN` がワークフローの実行をトリガーしたとき\n\nリポジトリの `GITHUB_TOKEN` を使用してタスクを実行する場合、 `GITHUB_TOKEN` によってトリガーされるイベントは新しいワークフロー実行を作成しません。ただし、次の例外があります。\n\n* `workflow_dispatch` と `repository_dispatch` イベントでは、常にワークフロー実行が作成されます。\n* `pull_request`\n  `opened`、`synchronize`、または`reopened`アクティビティの種類を含むイベント: `GITHUB_TOKEN`を使用するワークフローがプル要求を作成または更新すると、結果として得られる`pull_request` イベントによって、**承認が必要な**状態でワークフロー実行が作成されます。 プル要求にはマージ ボックスにバナーが表示され、リポジトリへの書き込みアクセス権を持つユーザーは、\\[実行するワークフローの承認] を選択して **実行を**開始できます。 その他の `pull_request` アクティビティの種類 ( `labeled`、 `edited`、 `closed`など) では、ワークフロー実行は作成されません。 これにより、自動化によって作成されたプル要求に対する CI ワークフローの実行を引き続き許可しながら、再帰ワークフローを実行できなくなります。 ワークフロー実行の承認の詳細については、「 [フォークからのワークフロー実行の承認](/ja/actions/how-tos/manage-workflow-runs/approve-runs-from-forks)」を参照してください。\n\nその他のすべてのイベントでは、この動作により、再帰的なワークフロー実行が誤って作成されるのを防ぐことができます。 たとえば、ワークフロー実行でリポジトリの `GITHUB_TOKEN` を使用してコードがプッシュされた場合、`push` イベントの発生時に実行するように構成されたワークフローがリポジトリに含まれている場合でも、新しいワークフローは実行されません。\n\n> \\[!NOTE]\n> ワークフローによって作成されたプル要求からワークフローを実行して承認を必要とせずに実行する必要がある場合は、プル要求の作成時または更新時にGitHub Appするのではなく、personal access tokenインストール アクセス トークンまたは`GITHUB_TOKEN`を使用します。\n\n`GITHUB_TOKEN` を使う GitHub Actions ワークフローによってプッシュされたコミットでは、GitHub Pages ビルドがトリガーされません。\n\n## 次のステップ\n\n* [ワークフローでの認証に GITHUB\\_TOKEN を使用する](/ja/actions/tutorials/authenticate-with-github_token)\n* [GitHub Actions　のワークフロー構文](/ja/actions/reference/workflows-and-actions/workflow-syntax#permissions)"}