{"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/manage-runners","title":"ランナーを管理する"},{"href":"/ja/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners","title":"より大きなランナー"},{"href":"/ja/enterprise-cloud@latest/actions/how-tos/manage-runners/larger-runners/control-access","title":"アクセスの制御"}],"documentType":"article"},"body":"# より大きなランナーへのアクセスの制御\n\nポリシーを使用して、組織または企業に追加された より大きなランナーへのアクセスを制限できます。\n\n## 大規模ランナーへのアクセスを管理する\n\n> \\[!NOTE]\n> ワークフローでジョブを より大きなランナーに送信するには、まずランナー グループのアクセス許可を構成する必要があります。 詳しくは、以下のセクションをご覧ください。\n\nランナー グループは、 より大きなランナーでジョブを実行できるリポジトリを制御するために使用されます。\nより大きなランナーを定義した場所に応じて、管理階層の各レベルからグループへのアクセスを管理する必要があります。\n\n* \\*\\*エンタープライズ レベルのランナー:\\*\\*既定では、Organization 内のリポジトリは Enterprise レベルのランナー グループにアクセスできません。 リポジトリに Enterprise ランナー グループへのアクセス権を付与するには、Organization の所有者が各 Enterprise ランナー グループを構成し、アクセスできるリポジトリを選ぶ必要があります。\n* \\*\\*組織レベルのランナー:\\*\\*既定では、Organization 内のすべてのリポジトリに、Organization レベルのランナー グループへのアクセス権が付与されます。 アクセスできるリポジトリを制限するには、Organization の所有者と \"Organization ランナーとランナー グループの管理\" アクセス許可を持つユーザーが Organization ランナー グループを構成し、アクセスできるリポジトリを選ぶ必要があります。\n\nたとえば、次の図には、Enterprise レベルに `grp-ubuntu-24.04-16core` という名前のランナー グループがあります。\n`octo-repo` という名前のリポジトリがグループ内のランナーを使用できるようにするには、まず、`octo-org` 組織へのアクセスを許可するようにエンタープライズ レベルでグループを構成する必要があります。 次に、`octo-repo` へのアクセスを許可するように組織レベルでグループを構成する必要があります。\n\n![Enterprise レベルで定義されたランナー グループと、2 つのリポジトリへのアクセスを許可する Organization 構成を示す図。](/assets/images/help/actions/hosted-runner-mgmt.png)\n\n## 組織のランナーチームを作成する\n\n> \\[!WARNING]\n> 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。\n\n> \\[!NOTE]\n> ランナー グループを作成するときは、ランナー グループにアクセスできるリポジトリ ワークフロー を定義するポリシーを選択する必要があります。 どのリポジトリとワークフローがランナー グループにアクセスできるかを変更するには、組織の所有者と、\"Manage organization runners and runner groups\" 権限を持つユーザーが、組織のポリシーを設定できます。 詳しくは、「[グループを使用してセルフホストランナーへのアクセスを管理する](/ja/enterprise-cloud@latest/actions/how-tos/manage-runners/self-hosted-runners/manage-access#changing-which-repositories-can-access-a-runner-group)」をご覧ください。\n\nすべての Organization には、単一の既定のランナー グループがあります。\n組織の所有者および \"組織ランナーとランナー グループの管理\" アクセス許可を持つユーザーは追加の組織レベルのランナー グループを作成できます。\nカスタム組織の役割の詳細については、「 [カスタム組織ロールの権限](/ja/enterprise-cloud@latest/organizations/managing-peoples-access-to-your-organization-with-roles/permissions-of-custom-organization-roles)」を参照してください。\n\n登録プロセスでグループを指定しなかった場合、ランナーは自動的に既定のグループに追加されます。 後で、ランナーを既定のグループからカスタム グループに移動することができます。\n\nREST API を使ってランナー グループを作成する方法については、「[GitHub Actionsの REST API エンドポイント](/ja/enterprise-cloud@latest/rest/actions#self-hosted-runner-groups)」を参照してください。\n\n1. GitHub で、organization のメイン ページに移動します。\n\n2. Organization 名の下で、**\\[ Settings]** をクリックします。 \\[設定] タブが表示されない場合は、 **\\[]** ドロップダウン メニューを選び、 **\\[設定]** をクリックします。\n\n ![組織のプロファイルのタブのスクリーンショット。 \\[設定\\] タブが濃いオレンジ色の枠線で囲まれています。](/assets/images/help/discussions/org-settings-global-nav-update.png)\n\n3. 左側のサイドバーで、** \\[Actions]** をクリックしてから **\\[Runner groups]** をクリックします。\n\n4. \"ランナー グループ\" セクションで、 **\\[新しいランナー グループ]** をクリックします。\n\n5. ランナー グループの名前を入力します。\n\n6. リポジトリ アクセスのポリシーを割り当てます。\n\n ランナー グループは、特定のリストのリポジトリまたは組織のすべてのリポジトリにアクセスできるように構成できます。 既定では、ランナー グループのランナーにアクセスできるのはプライベート リポジトリのみですが、これはオーバーライドできます。 エンタープライズによって共有された組織のランナー グループを構成する場合、この設定をオーバーライドすることはできません。\n\n7. ワークフロー アクセス用のポリシーを割り当てます。\n\n 特定のワークフローの一覧またはすべてのワークフローからアクセスできるようにランナー グループを構成できます。 エンタープライズによって共有された組織のランナー グループを構成している場合、この設定をオーバーライドできません。 ランナー グループにアクセスできるワークフローを指定する場合は、リポジトリ名と所有者を含むワークフローへの完全なパスを使用します。 再利用可能でないワークフローをブランチにピン留めする。 再利用可能なワークフローをブランチ、タグ、または完全な SHA にピン留めします。 (例: `octo-org/octo-repo/.github/workflows/build.yml@refs/tags/v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@refs/heads/main`)。\n\n 曖昧な参照は完全修飾することがベストプラクティスです。 たとえば、参照として `main` を指定するのではなく、`refs/heads/main` を指定します。\n\n 選択したワークフロー内で直接定義されたジョブのみがランナー グループにアクセスできます。 組織所有のランナー グループは、企業内の別の組織のワークフローにアクセスできません。代わりに、エンタープライズ所有のランナー グループを作成する必要があります。\n\n8. **\\[グループの作成]** をクリックしてグループを作成し、ポリシーを適用します。\n\n## 企業向けのランナーグループを作成する\n\n> \\[!WARNING]\n> 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。\n\nEnterprise を使うと、ランナーがグループに追加されて、アクセス管理を行うことができます。 Enterprise は、Enterprise アカウント内の特定の organization、または特定のワークフローにアクセスできるランナーのグループを作成できます。 Organization 所有者は、追加の詳細なリポジトリまたはワークフロー アクセス ポリシーを Enterprise ランナー グループに割り当てることができます。 REST API を使ってランナー グループを作成する方法については、[GitHub Actions REST API](/ja/enterprise-cloud@latest/rest/actions#self-hosted-runner-groups) の Enterprise エンドポイントをご覧ください。\n\n登録プロセスでグループを指定しなかった場合、ランナーは自動的に既定のグループに追加されます。 後で、ランナーを既定のグループからカスタム グループに移動することができます。\n\nグループを作成するときは、ランナーグループにアクセスできる Organization を定義するポリシーを選択する必要があります。\n\n1. 企業ページに移動してください。 たとえば、GitHub.com の [\\[Enterprise\\]](https://github.com/settings/enterprises?ref_product=ghec\\&ref_type=engagement\\&ref_style=text) ページから。\n2. ページの上部にある \\[**ポリシーの**] をクリックします。\n3. \\[ Policies] で、**\\[Actions]** をクリックします。\n4. **\\[ランナー グループ]** タブをクリックします。\n5. **\\[New runner group]\\(新しいランナー グループ)** をクリックします。\n6. \\[グループ名] に、ランナー グループの名前を入力します。1. Organization アクセスのポリシーを選ぶには、 **\\[Organization のアクセス]** ドロップダウン メニューを選び、\\[ポリシー] をクリックします。 組織の特定のリストまたはエンタープライズ内のすべての組織にアクセス可能なランナー グループを設定できます。\n7. ワークフロー アクセス用のポリシーを割り当てます。\n\n 特定のワークフローの一覧またはすべてのワークフローからアクセスできるようにランナー グループを構成できます。 エンタープライズによって共有された組織のランナー グループを構成している場合、この設定をオーバーライドできません。 ランナー グループにアクセスできるワークフローを指定する場合は、リポジトリ名と所有者を含むワークフローへの完全なパスを使用します。 再利用可能でないワークフローをブランチにピン留めする。 再利用可能なワークフローをブランチ、タグ、または完全な SHA にピン留めします。 (例: `octo-org/octo-repo/.github/workflows/build.yml@refs/tags/v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@refs/heads/main`)。\n\n 曖昧な参照は完全修飾することがベストプラクティスです。 たとえば、参照として `main` を指定するのではなく、`refs/heads/main` を指定します。\n\n 選択したワークフロー内で直接定義されたジョブのみがランナー グループにアクセスできます。\n8. **\\[グループの保存]** をクリックしてグループを作成し、ポリシーを適用します。\n\n## ランナー グループに一意の名前を使用する\n\nGitHub Actions では、ランナー グループ名が Organization レベルで一意である必要があります。 つまり、Organization は、Enterprise 内のランナー グループと同じ名前を持つものを作成できなくなります。 さらに、ユーザーには、Enterprise 内のグループと同じ名前を共有するすべてのランナー グループに、Organization グループの名前を変更することを提案する警告バナーが表示されます。\n\nあいまいさを回避するために、Organization と Enterprise に重複するランナー グループがある場合、ワークフローは失敗します。 これに対処するには、Organization 内または Enterprise のいずれかのランナー グループの名前を変更するか、ワークフロー ファイルを更新してランナー グループ名にプレフィックスを追加します。\n\n* `org/` または `organization/`\n* `ent/` または `enterprise/`\n\n### 例: プレフィックスを使用してランナー グループを区別する\n\nたとえば、Organization 内に `my-group` という名前のランナー グループがあり、Enterprise 内に `my-group` という名前のランナー グループがある場合は、ワークフロー ファイルを更新して、`org/my-group` または `ent/my-group` を使用して 2 つを区別できます。\n\n`org/`の使用\n\n```yaml\nruns-on:\n group: org/my-group\n labels: [ self-hosted, label-1 ]\n```\n\n`ent/`の使用\n\n```yaml\nruns-on:\n group: ent/my-group\n labels: [ self-hosted, label-1 ]\n```\n\n## ランナー グループにアクセスできる組織を変更する\n\n> \\[!WARNING]\n> 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。\n\nエンタープライズのランナー グループの場合、エンタープライズ内のどの組織がランナー グループにアクセスできるかを変更できます。\n\n1. 企業ページに移動してください。 たとえば、GitHub.com の [\\[Enterprise\\]](https://github.com/settings/enterprises?ref_product=ghec\\&ref_type=engagement\\&ref_style=text) ページから。\n\n2. ページの上部にある \\[**ポリシーの**] をクリックします。\n\n3. \\[ Policies] で、**\\[Actions]** をクリックします。\n\n4. **\\[ランナー グループ]** タブをクリックします。\n\n5. \\[Organization アクセス] で、ドロップダウン メニューを使用して \\[選択した Organization **] をクリックします**。\n 1. ドロップダウン メニューの右側にある をクリックします。\n 2. ポップアップで、チェックボックスを使って、このランナー グループを使用できる Organization を選択します。\n\n6. **\\[グループの保存]** をクリックします。\n\n## ランナー グループにアクセスできるリポジトリを変更する\n\n> \\[!WARNING]\n> 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。\n\n組織のランナー グループの場合、組織内のどのリポジトリがランナー グループにアクセスできるかを変更できます。\n\n1. ランナー グループが配置されている組織のメイン ページに移動します。\n2. ** \\[Settings]** をクリックします。\n3. 左側のサイドバーで、** \\[Actions]** をクリックしてから **\\[Runner groups]** をクリックします。\n4. グループのリストで、構成するランナー グループをクリックします。\n5. 「リポジトリ アクセス」で、ドロップダウン メニューを使って **\\[選択したリポジトリ]** をクリックします。\n 1. ドロップダウン メニューの右側にある をクリックします。\n 2. ポップアップで、チェックボックスを使って、このランナー グループにアクセスできるリポジトリを選択します。\n6. **\\[グループの保存]** をクリックします。\n\n## ランナー グループにアクセスできるワークフローを変更する\n\n> \\[!WARNING]\n> 固定 IP 範囲を使っている場合、プライベート リポジトリには より大きなランナー のみを使うことをお勧めします。 ワークフロー内でコードを実行する pull request を作成することで、リポジトリのフォークによって、より大きなランナー 上で危険なコードが実行される可能性があります。\n\n選択したワークフローまたはすべてのワークフローを実行するようにランナー グループを構成できます。 たとえば、この設定を使って、ランナーに格納されているシークレットを保護したり、ランナー グループが特定の再利用可能なワークフローのみを実行するように制限してデプロイ ワークフローを標準化したりすることができます。 エンタープライズによって共有された組織のランナー グループを構成している場合、この設定をオーバーライドできません。\n\n* [組織のランナー グループにアクセスできるワークフローを変更する](#changing-which-workflows-can-access-an-organization-runner-group)\n* [エンタープライズのランナー グループにアクセスできるワークフローを変更する](#changing-which-workflows-can-access-an-enterprise-runner-group)\n\n### 組織のランナー グループにアクセスできるワークフローを変更する\n\n1. ランナー グループが配置されている組織のメイン ページに移動します。\n\n2. ** \\[Settings]** をクリックします。\n\n3. 左側のサイドバーで、** \\[Actions]** をクリックしてから **\\[Runner groups]** をクリックします。\n\n4. グループのリストで、構成するランナー グループをクリックします。\n\n5. **\\[ワークフロー アクセス]** で、ドロップダウン メニューを選択し、 **\\[選択したワークフロー]** をクリックします。\n\n6. をクリックします。\n\n7. ランナー グループにアクセスできるワークフローのコンマ区切りの一覧を入力します。 リポジトリ名と所有者を含む完全なパスを使用します。 再利用可能でないワークフローをブランチにピン留めする。 再利用可能なワークフローをブランチ、タグ、または完全な SHA にピン留めします。 (例: `octo-org/octo-repo/.github/workflows/build.yml@v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@main`)。\n\n 選択したワークフロー内で直接定義されたジョブのみがランナー グループにアクセスできます。\n\n 組織所有のランナー グループは、エンタープライズ内の別の組織からワークフローにアクセスできません。代わりに、エンタープライズ所有のランナー グループを作成する必要があります。\n\n8. **\\[保存]** をクリックします。\n\n### エンタープライズのランナー グループにアクセスできるワークフローを変更する\n\n1. 企業ページに移動してください。 たとえば、GitHub.com の [\\[Enterprise\\]](https://github.com/settings/enterprises?ref_product=ghec\\&ref_type=engagement\\&ref_style=text) ページから。\n\n2. ページの上部にある \\[**ポリシーの**] をクリックします。\n\n3. \\[ Policies] で、**\\[Actions]** をクリックします。\n\n4. **\\[ランナー グループ]** タブをクリックします。\n\n5. グループのリストで、構成するランナー グループをクリックします。\n\n6. **\\[ワークフロー アクセス]** で、ドロップダウン メニューを選択し、 **\\[選択したワークフロー]** をクリックします。\n\n7. をクリックします。\n\n8. ランナー グループにアクセスできるワークフローのコンマ区切りの一覧を入力します。 リポジトリ名と所有者を含む完全なパスを使用します。 再利用可能でないワークフローをブランチにピン留めする。 再利用可能なワークフローをブランチ、タグ、または完全な SHA にピン留めします。 (例: `octo-org/octo-repo/.github/workflows/build.yml@v2, octo-org/octo-repo/.github/workflows/deploy.yml@d6dc6c96df4f32fa27b039f2084f576ed2c5c2a5, monalisa/octo-test/.github/workflows/test.yml@main`)。\n\n 選択したワークフロー内で直接定義されたジョブのみがランナー グループにアクセスできます。\n\n 組織所有のランナー グループは、エンタープライズ内の別の組織からワークフローにアクセスできません。代わりに、エンタープライズ所有のランナー グループを作成する必要があります。\n\n9. **\\[保存]** をクリックします。\n\n## より大きなランナーのプライベート ネットワーク アクセスの構成\n\nAzure VNET での GitHub ホストランナーを使用できます。 これにより、ランナーのネットワーク ポリシーを完全に制御しながら、CI/CD の GitHub マネージド インフラストラクチャを利用することができます。 Azure VNET の詳細については、Azure ドキュメントの「[Azure Virtual Network とは](https://learn.microsoft.com/en-us/azure/virtual-network/virtual-networks-overview)」を参照してください。\n\nAzure VNET に接続するように enterprise または organization を構成している場合は、ランナー グループに仮想ネットワークへのアクセス権を付与できます。 詳しくは、「[GitHubホストランナーを使用したプライベート ネットワーク](/ja/enterprise-cloud@latest/actions/concepts/runners/private-networking#using-an-azure-virtual-network-vnet)」をご覧ください。\n\nネットワーク構成を持つランナー グループに macOS より大きなランナーを割り当てることはできません。 同様に、macOS より大きなランナーを含むランナー グループにネットワーク構成を追加することはできません。\n\n## ランナー グループの名前を変更する\n\nランナー グループの名前は、エンタープライズ レベルと組織レベルで変更できます。\n\n* [組織ランナー グループの名前を変更する](#changing-the-name-of-an-organization-runner-group)\n* [エンタープライズ ランナー グループの名前を変更する](#changing-the-name-of-an-enterprise-runner-group)\n\n### 組織ランナー グループの名前を変更する\n\n1. ランナー グループが配置されている組織のメイン ページに移動します。\n2. ** \\[Settings]** をクリックします。\n3. 左側のサイドバーで、** \\[Actions]** をクリックしてから **\\[Runner groups]** をクリックします。\n4. グループのリストで、構成するランナー グループをクリックします。\n5. \\[グループ名] のテキスト フィールドに新しいランナー グループ名を入力します。\n6. **\\[保存]** をクリックします。\n\n### エンタープライズ ランナー グループの名前を変更する\n\n1. 企業ページに移動してください。 たとえば、GitHub.com の [\\[Enterprise\\]](https://github.com/settings/enterprises?ref_product=ghec\\&ref_type=engagement\\&ref_style=text) ページから。\n2. ページの上部にある \\[**ポリシーの**] をクリックします。\n3. \\[ Policies] で、**\\[Actions]** をクリックします。\n4. **\\[ランナー グループ]** タブをクリックします。\n5. グループのリストで、構成するランナー グループをクリックします。\n6. \\[グループ名] のテキスト フィールドに新しいランナー グループ名を入力します。\n7. **\\[保存]** をクリックします。\n\n## ランナーをグループに移動する\n\n登録プロセス中にランナー グループを指定しない場合、新しいランナーは、自動的に既定のグループに割り当てられ、その後別のグループへの移動が可能となります。\n\n* [組織ランナーをグループに移動する](#moving-an-organization-runner-to-a-group)\n* [エンタープライズ ランナーをグループに移動する](#moving-an-enterprise-runner-to-a-group)\n\n### 組織のランナーをグループに移動する\n\n1. GitHub で、organization のメイン ページに移動します。\n2. Organization 名の下で、**\\[ Settings]** をクリックします。 \\[設定] タブが表示されない場合は、 **\\[]** ドロップダウン メニューを選び、 **\\[設定]** をクリックします。\n\n ![組織のプロファイルのタブのスクリーンショット。 \\[設定\\] タブが濃いオレンジ色の枠線で囲まれています。](/assets/images/help/discussions/org-settings-global-nav-update.png)\n3. 左側のサイドバーで、** \\[Actions]** をクリックしてから **\\[Runners]** をクリックします。\n4. \"ランナー\" の一覧で、構成するランナーをクリックします。\n5. **\\[ランナー グループ]** ドロップダウンを選択します。\n6. \"ランナーをグループに移動\" で、ランナーの移動先グループを選択します。\n\n### エンタープライズ ランナーをグループに移動する\n\n1. 企業ページに移動してください。 たとえば、GitHub.com の [\\[Enterprise\\]](https://github.com/settings/enterprises?ref_product=ghec\\&ref_type=engagement\\&ref_style=text) ページから。\n2. ページの上部にある \\[**ポリシーの**] をクリックします。\n3. \\[ Policies] で、**\\[Actions]** をクリックします。\n4. **\\[Runners]\\(ランナー)** タブをクリックします。\n5. \"ランナー\" の一覧で、構成するランナーをクリックします。\n6. **\\[ランナー グループ]** ドロップダウンを選択します。\n7. \"ランナーをグループに移動\" で、ランナーの移動先グループを選択します。\n\n## ランナー グループを削除する\n\nランナー グループを削除するには、まず、グループからすべてのランナーを移動するか削除する必要があります。\n\n* [組織からランナーグループを削除する](#removing-a-runner-group-from-an-organization)\n* [エンタープライズからランナーグループを削除する](#removing-a-runner-group-from-an-enterprise)\n\n### 組織からランナーグループを削除する\n\n1. ランナー グループが配置されている組織のメイン ページに移動します。\n2. ** \\[Settings]** をクリックします。\n3. 左側のサイドバーで、** \\[Actions]** をクリックしてから **\\[Runner groups]** をクリックします。\n4. グループの一覧で、削除するグループの右側にある をクリックします。\n5. グループを削除するには、 **\\[グループの削除]** をクリックします。\n6. 確認プロンプトを確認し、 **\\[Remove this runner group]\\(このランナー グループの削除)** をクリックします。\n\n### エンタープライズからランナーグループを削除する\n\n1. 企業ページに移動してください。 たとえば、GitHub.com の [\\[Enterprise\\]](https://github.com/settings/enterprises?ref_product=ghec\\&ref_type=engagement\\&ref_style=text) ページから。\n2. ページの上部にある \\[**ポリシーの**] をクリックします。\n3. \\[ Policies] で、**\\[Actions]** をクリックします。\n4. **\\[ランナー グループ]** タブをクリックします。\n5. グループの一覧で、削除するグループの右側にある をクリックします。\n6. グループを削除するには、 **\\[グループの削除]** をクリックします。\n7. 確認プロンプトを確認し、 **\\[Remove this runner group]\\(このランナー グループの削除)** をクリックします。"}