{"meta":{"title":"セルフホステッド ランナー リファレンス","intro":"セルフホステッド ランナーの設定と使用について説明します。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/ja/enterprise-cloud@latest/actions/reference","title":"リファレンス"},{"href":"/ja/enterprise-cloud@latest/actions/reference/runners","title":"ランナー"},{"href":"/ja/enterprise-cloud@latest/actions/reference/runners/self-hosted-runners","title":"セルフホステッド ランナー"}],"documentType":"article"},"body":"# セルフホステッド ランナー リファレンス\n\nセルフホステッド ランナーの設定と使用について説明します。\n\n## セルフホステッド ランナーマシンに対する要求\n\n以下の要求を満たしていれば、コンピューターをセルフホステッド ランナーとして使用できます。\n\n* マシン上にセルフホステッド ランナーアプリケーションをあなたがインストールして実行できること。 「[サポートされているオペレーティング システム](#supported-operating-systems)」および「[サポートされているプロセッサ アーキテクチャ](#supported-processor-architectures)」を参照してください。\n* マシンは GitHub Actionsと通信できます。\n* そのマシンが、実行しようとしている種類のワークフローに対して十分なハードウェアリソースを持っていること。 セルフホステッド ランナーアプリケーションそのものは、最小限のリソースしか必要としません。\n* Dockerコンテナアクションあるいはサービスコンテナを使うワークフローを実行したいなら、Linuxのマシンを使い、Dockerがインストールされていなければなりません。\n\n### サポートされるオペレーティング システム\n\n#### Linux\n\n* Red Hat Enterprise Linux 8 以降\n* CentOS 8 以降\n* Oracle Linux 8 以降\n* Fedora 29以降\n* Debian 10 以降\n* Ubuntu 20.04 以降\n* Linux Mint 20 以降\n* openSUSE 15.2 以降\n* SUSE Enterprise Linux (SLES) 15 SP2以降\n\n#### Windows\n\n* Windows 10 (64 ビット)\n* Windows 11 64 ビット\n* Windows Server 2016 64 ビット\n* Windows Server 2019 64 ビット\n* Windows Server 2022 64 ビット\n\n#### macOS\n\n* macOS 11.0 (Big Sur) 以降\n\n### サポートされているプロセッサ アーキテクチャ\n\n* `x64` – Linux、macOS、Windows。\n* `ARM64` - Linux、macOS、Windows (現在は パブリック プレビュー)、。\n* `ARM32` – Linux。\n\n## セルフホステッド ランナーのルーティングの優先順位\n\nセルフホステッド ランナーにジョブをルーティングする場合、 GitHub はジョブの `runs-on` ラベルとグループに一致するランナーを検索します。\n\n* GitHub が、ジョブの `runs-on` ラベルとグループに一致する、オンラインでアイドル状態のランナーを見つけた場合、そのジョブは当該ランナーに割り当てられ、送信されます。\n  * 割り当てられたジョブをランナーが 60 秒以内に取得しない場合、新しいランナーが受け入れることができるように、ジョブはキューに再格納されます。\n* GitHub が、ジョブの `runs-on` ラベルとグループに一致するオンラインかつアイドル状態のランナーを見つけられない場合、ランナーがオンラインになるまで、そのジョブはキューに残留します。\n* 24時間以上にわたってキューに残っていたジョブは失敗します。\n\n## 自動スケール\n\n自動スケールを使用すると、必要に応じてセルフホステッド ランナーの数を動的に調整できます。 これにより、リソース使用率を最適化し、ピーク時に十分なランナー容量を確保しながら、アクティビティが少ない期間中のコストを削減できます。 セルフホステッド ランナーの自動スケールを実装するには、複雑さ、信頼性、応答性の点でトレードオフが異なる複数の方法があります。\n\n### Actions Runner Controller\n\nGitHubホスト型ランナーは、必要に応じて自動的にスケールします。\nGitHubホステッド ランナーは、自動スケーリング ソリューションを開発または導入する代わりに、メンテナンスの負担が少なく、コスト効率の高い選択肢となります。 詳しくは、「[GitHub ホステッド ランナー](/ja/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners/about-github-hosted-runners)」をご覧ください。\n\nActions Runner Controller (ARC) は、 GitHubのスケール セット API の参照実装であり、セルフホステッド ランナーの自動スケーリングに推奨される Kubernetes ベースのソリューションです。 ARC は、Kubernetes 環境で GitHub Actions を実行しているチーム向けに、完全な運用対応の自動スケール ソリューションを提供します。\n\nGitHub では、Kubernetes インフラストラクチャを持つ組織と、Kubernetes の専門知識を持つチームに ARC が推奨されています。 ARC は、プロビジョニングからジョブの実行、クリーンアップまで、クラスター内のランナーの完全なライフサイクルを処理します。\n\n詳細については、「[アクション ランナー コントローラー](/ja/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-actions-runner-controller)」および「[Actions ランナー コントローラーのサポート](/ja/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners-with-actions-runner-controller/about-support-for-actions-runner-controller)」を参照してください。\n\n### GitHub Actions ランナー スケール セット クライアント\n\nGitHub Actions Runner Scale Set Client は、プラットフォーム チーム、インテグレーター、インフラストラクチャ プロバイダーが、vm、コンテナー、オンプレミス インフラストラクチャ、およびクラウド サービス全体のGitHub Actions ランナー用のカスタム自動スケール ソリューションを構築し、Windows、Linux、および macOS プラットフォームをサポートするスタンドアロンの Go ベースのモジュールです。\n\nクライアントは、インフラストラクチャのプロビジョニングはユーザー側で行いながら、スケール セットの GitHub API 呼び出しを統括します。 ランナーの作成方法、スケーリング方法、破棄方法を定義し、柔軟なジョブ ルーティングとターゲット設定のために複数のラベルを持つランナーを構成します。 これにより、組織はランナー のライフサイクル管理と、ジョブ実行のためのリアルタイム テレメトリをきめ細かく制御できます。\n\nクライアントは、基本的な構成ですぐに使用できるように設計されているため、チームは自動スケールをすばやく実装できます。 ただし、その真の力は柔軟性にあります。クライアントは、各組織の特定のインフラストラクチャ要件、コンプライアンスの制約、運用ワークフローを満たすように拡張およびカスタマイズされるように構築されています。 単純なスケーリング ロジックが必要な場合でも、複雑なマルチ環境プロビジョニング戦略が必要な場合でも、クライアントはニーズに適応します。\n\nGitHub Actions Runner Scale Set Client は、オープンソース プロジェクトです。\n[actions/scaleset リポジトリ](https://github.com/actions/scaleset)には、完全なソース コード、包括的なドキュメント、および開始に役立つ実用的な例が含まれています。 実装ガイド、さまざまなインフラストラクチャ シナリオのサンプル構成、およびクライアントをさまざまなプロビジョニング システムと統合する方法を示す参照アーキテクチャがあります。 リポジトリには、クライアントの拡張や自動スケール パターンのコミュニティとの共有に関心があるチーム向けの投稿ガイドラインも含まれています。\n\n> **メモ：** ランナー スケール セット クライアントは、 Actions Runner Controller (ARC) に代わるものではありません。これは、スケール セット API の参照実装であり、ランナーの自動スケールに推奨される Kubernetes ソリューションです。 代わりに、クライアントは、Kubernetes の外部でカスタム自動スケール ソリューションを構築するために、同じスケール セット API とやり取りするための補完的なツールです。\n\n### 自動スケール対象のエフェメラル ランナー\n\nGitHub エフェメラルセルフホステッド ランナーを使用して自動スケールを実装することをお勧めします。永続的なセルフホステッド ランナーを使用した自動スケールは推奨されません。 状況によって、GitHub は、シャットダウン中の永続ランナーにジョブが割り当てられないことを保証できません。 エフェメラル ランナーでは、 GitHub はランナーに 1 つのジョブしか割り当てないため、これを保証できます。\n\nこの方法では、オートメーションを使ってジョブごとにクリーンな環境を提供できるため、ランナーをエフェメラル システムとして管理できます。 これは、以前のジョブから機密リソースが公開されるのを制限する役に立ち、侵害されたランナーが新しいジョブを受け取るリスクを軽減するのにも役立ちます。\n\n> \\[!WARNING]エフェメラル ランナーのランナー アプリケーション ログ ファイルは、トラブルシューティングや診断のために外部ログ ストレージ ソリューションに転送する必要があります。 エフェメラル ランナーをデプロイする必要はありませんが、 GitHub では、運用環境にエフェメラル ランナー自動スケール ソリューションをデプロイする前に、ランナー ログが転送され、外部に保持されるようにすることをお勧めします。 詳しくは、「[自己ホストランナーのモニタリングとトラブルシューティング](/ja/enterprise-cloud@latest/actions/hosting-your-own-runners/managing-self-hosted-runners/monitoring-and-troubleshooting-self-hosted-runners#reviewing-the-self-hosted-runner-application-log-files)」をご覧ください。\n\n環境にエフェメラル ランナーを追加するには、`--ephemeral` を使ってランナーを登録するときに `config.sh` パラメーターを指定します。 次に例を示します。\n\n```shell\n./config.sh --url https://github.com/octo-org --token example-token --ephemeral\n```\n\nその後、 GitHub Actions サービスは、1 つのジョブを処理した後、ランナーの登録を自動的に解除します。 その場合、登録解除後にランナーをワイプする独自のオートメーションを作成できます。\n\n> \\[!NOTE]\n> ジョブに特定の種類のランナー用のラベルが付いていて、そのタイプに一致するものを使用できない場合、ジョブがキューに入れられてすぐに失敗することはありません。 そうではなく、24 時間のタイムアウト期間が切れるまで、ジョブはキューに残ります。\n\nあるいは、REST API を使用して、エフェメラルなジャストインタイム ランナーを作成することもできます。 詳しくは、「[セルフホステッド ランナーの REST API エンドポイント](/ja/enterprise-cloud@latest/rest/actions/self-hosted-runners)」をご覧ください。\n\n### セルフホステッド ランナーのランナー ソフトウェアの更新\n\n既定では、ランナー ソフトウェアの新しいバージョンが利用可能になると、セルフホステッド ランナーは自動的にソフトウェアの更新を実行します。 コンテナーでエフェメラル ランナーを使用している場合は、新しいランナー バージョンがリリースされたときに、ソフトウェアの更新が繰り返される可能性があります。 自動更新をオフにすると、コンテナー イメージのランナー バージョンを独自のスケジュールで直接更新できます。\n\nソフトウェアの自動更新をオフにして、ソフトウェアの更新プログラムを自分でインストールするには、`--disableupdate` を使ってランナーを登録するときに、`config.sh` フラグを指定します。 次に例を示します。\n\n```shell\n./config.sh --url https://github.com/YOUR-ORGANIZATION --token EXAMPLE-TOKEN --disableupdate\n```\n\n自動更新を無効にした場合でも、自分でランナーのバージョンを定期的に更新する必要があります。\nGitHub Actionsの新機能では、GitHub Actions サービス\\_と\\_ランナー ソフトウェアの両方を変更する必要があります。 ランナーは、ソフトウェア更新プログラムなしで GitHub Actions の新機能を利用するジョブを正しく処理できない場合があります。\n\n自動更新を無効にする場合は、ランナーの新しいバージョンが利用可能になってから 30 日以内に、バージョンを更新する必要があります。\n[\n`actions/runner` リポジトリ](https://github.com/actions/runner/releases)でリリースの通知にサブスクライブすることもできます。 詳しくは、「[通知を設定する](/ja/enterprise-cloud@latest/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications#about-custom-notifications)」をご覧ください。\n\nランナーの最新バージョンをインストールする方法については、[最新リリース](https://github.com/actions/runner/releases)のインストール手順をご覧ください。\n\n> \\[!WARNING] メジャー リリース、マイナー リリース、パッチ リリースなど、ソフトウェア用にリリースされた更新プログラムは、利用可能な更新プログラムと見なされます。 30 日以内にソフトウェアを更新しないと、GitHub Actions サービスはランナーへのジョブをキューに入れなくなります。 さらに、重要なセキュリティ更新プログラムが必要な場合、GitHub Actions サービスは、更新されるまで、ランナーへのジョブをキューに入れません。\n\n### 自動スケール用 Webhook\n\n[\n`workflow_job`\n](/ja/enterprise-cloud@latest/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job) Webhook から受信したペイロードを使って、独自の自動スケール環境を作成できます。 この Webhook は、リポジトリ、Organization、Enterprise のレベルで使用でき、このイベントのペイロードには、ワークフロー ジョブのライフサイクルのステージに対応する `action` キーが含まれています (たとえば、ジョブが `queued`、`in_progress`、`completed` のとき)。 その場合、これらの Webhook ペイロードに応答して独自のスケーリング オートメーションを作成する必要があります。\n\n* `workflow_job` Webhook の詳細については、「[Webhook のイベントとペイロード](/ja/enterprise-cloud@latest/webhooks-and-events/webhooks/webhook-events-and-payloads#workflow_job)」を参照してください。\n* Webhook の使用方法については、「[Webhook ドキュメント](/ja/enterprise-cloud@latest/webhooks)」を参照してください。\n\n> **メモ：** このアプローチは、スケーリングの決定を行うために Webhook 配信のタイムラインに依存します。これにより、遅延と信頼性の問題が発生する可能性があります。 大規模なボリューム自動スケール のシナリオでは、アクション コントローラーまたはスケール セット クライアントの使用を検討してください。\n\n### 認証の要件\n\n[API](/ja/enterprise-cloud@latest/rest/actions/self-hosted-runners) を使って、リポジトリと Organization のセルフホステッド ランナーを登録および削除できます。 API に対して認証を行うために、自動スケールの実装では、アクセス トークンまたは GitHub アプリを使用できます。\n\nアクセス トークンには、次のスコープが必要です。\n\n* プライベート リポジトリの場合は、[`repo` スコープ](/ja/enterprise-cloud@latest/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes)でアクセス トークンを使います。\n* パブリック リポジトリの場合は、[`public_repo` スコープ](/ja/enterprise-cloud@latest/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes)でアクセス トークンを使います。\n* Organizationは、[`admin:org` スコープ](/ja/enterprise-cloud@latest/apps/oauth-apps/building-oauth-apps/scopes-for-oauth-apps#available-scopes)でアクセス トークンを使います。\n\nGitHub アプリを使用して認証するには、次のアクセス許可が割り当てられている必要があります。\n\n* リポジトリの場合は、`administration` アクセス許可を割り当てます。\n* Organizationは、`organization_self_hosted_runners` アクセス許可を割り当てます。\n\n[API](/ja/enterprise-cloud@latest/rest/actions/self-hosted-runners) を使って、Enterprise のセルフホステッド ランナーを登録および削除できます。 自動スケーリングの実装で API の認証を行うには、アクセス トークンを使用できます。\n\nアクセス トークンには、`manage_runners:enterprise` スコープが必要です。\n\n## Communication\n\nセルフホステッド ランナーは、 GitHub に接続してジョブの割り当てを受け取り、ランナー アプリケーションの新しいバージョンをダウンロードします。\n\nGitHub Actionsランナーアプリケーションはオープンソースです。 [ランナー](https://github.com/actions/runner) リポジトリでイシューを投稿およびファイルできます。\n新しいバージョンがリリースされると、ランナー アプリケーションは、ジョブがランナーに割り当てられると自動的に更新されます。また、ランナーにジョブが割り当てられていない場合は、リリースから 1 週間以内に自動的に更新されます。\n\n### GitHubとの通信の要件\n\n* GitHub Actions ジョブを受け入れて実行するには、セルフホステッド ランナー アプリケーションがホスト コンピューター上で実行されている必要があります。\n* ホスト マシンには、アップロードとダウンロードの速度が 70 キロビット/秒以上である適切なネットワーク アクセスが必要です。\n* ホスト マシンは、ポート 443 経由で送信 HTTPS 接続ができる必要があります。\n* セルフホステッド ランナーに割り当てられているワークフローの機能に応じて、ホスト コンピューターは以下に示す GitHub ドメインと通信できる必要があります。\n\n### 機能別のアクセス可能なドメイン\n\n> \\[!NOTE]\n> 一覧表示されているドメインの一部は、`CNAME` レコードを使用して構成されます。 ファイアウォールによっては、すべての `CNAME` レコードに対して規則を再帰的に追加する必要がある場合があります。 `CNAME` レコードは今後変更される可能性があり、一覧表示されているドメインのみが一定のままであることに注意してください。\n\n> \\[!NOTE]\n> データ所在地付き GitHub Enterprise Cloudを使用する場合、ランナーは次に示すホスト名以外のホスト名と通信する必要があります。 完全なネットワーク要件については、 [GHE.com のネットワークの詳細](/ja/enterprise-cloud@latest/admin/data-residency/network-details-for-ghecom) を参照してください。\n\n**重要な操作に必要:**\n\n```shell copy\ngithub.com\napi.github.com\n*.actions.githubusercontent.com\n```\n\n**ダウンロード アクションに必要:**\n\n```shell copy\ncodeload.github.com\n```\n\n**ジョブ サマリー、ログ、ワークフロー アーティファクト、キャッシュのアップロード/ダウンロードに必要:**\n\n```shell copy\nresults-receiver.actions.githubusercontent.com\n*.blob.core.windows.net\n```\n\n**ランナーのバージョン更新に必要なもの:**\n\n```shell copy\nobjects.githubusercontent.com\nobjects-origin.githubusercontent.com\ngithub-releases.githubusercontent.com\ngithub-registry-files.githubusercontent.com\n```\n\n**OIDC トークンを取得するために必要:**\n\n```shell copy\n*.actions.githubusercontent.com\n```\n\n**パッケージまたはコンテナーを GitHub パッケージにダウンロードまたは発行するために必要:**\n\n```shell copy\n*.pkg.github.com\npkg-containers.githubusercontent.com\nghcr.io\n```\n\n**次の場合に必要です Git 大容量ファイルストレージ**\n\n```shell copy\ngithub-cloud.githubusercontent.com\ngithub-cloud.s3.amazonaws.com\n```\n\n**Dependabot updates のジョブに必要**\n\n```shell copy\ndependabot-actions.githubapp.com\n```\n\n**リリース資産のダウンロードに必要:**\n\n```shell copy\nrelease-assets.githubusercontent.com\n```\n\n**VNet に必要:**\n\n```shell copy\napi.snapcraft.io\n```\n\nさらに、ワークフローで他のネットワーク リソースへのアクセスが必要になる場合があります。\n\nGitHub組織またはエンタープライズ アカウントの IP アドレス許可リストを使用する場合は、セルフホステッド ランナーの IP アドレスを許可リストに追加する必要があります。\n[組織の許可された IP アドレスの管理](/ja/enterprise-cloud@latest/organizations/keeping-your-organization-secure/managing-allowed-ip-addresses-for-your-organization#using-github-actions-with-an-ip-allow-list)または[Enterprise でセキュリティ設定のポリシーを適用する](/ja/enterprise-cloud@latest/admin/policies/enforcing-policies-for-your-enterprise/enforcing-policies-for-security-settings-in-your-enterprise)."}