GitHub Actions macOS Runner Groupsの設定方法は？2026年企業ガイド

先に結論です。GitHub Actions macOS Runner Groupsは、チームの信頼境界に沿ってグループを分け、リポジトリへのアクセスを設定してからワークフローを割り当ててください。代表的なパイプラインを検証するまでは、標準Runnerラベルを無効にしないでください。

本週の推奨アクション： 既存ワークフローの利用ラベルと、公開リポジトリ・外部貢献・リリース処理の実行範囲を先に一覧化します。ネットワーク設定が要件なら、Runner Groupsで実現できると想定せず、実行環境の適合性を別途確認してください。

GitHub組織・企業の管理者は、Runner Groupと標準Runnerの利用範囲を管理するときに役立ちます。
CI基盤の担当者は、macOSのジョブを特定のRunner Groupへルーティングする手順を確認できます。
技術責任者・セキュリティ担当者は、アクセス方針とネットワーク要件の適合性を判断する材料にできます。

最終更新：2026年11月4日。 GitHubの公式発表、Runner Groupのアクセス制御資料、ワークフロー構文、組織設定の文書を照合しています。アカウントごとの提供状況や画面表示は、導入時点の公式資料と管理画面で再確認してください。

導入前に適用範囲を確認

GitHub ActionsのmacOS Runner Groups設定では、最初に「GitHub-hosted macOS runnersを管理しているのか」「自分で管理するRunnerを扱っているのか」を分けます。両者では適用する管理手順や利用条件が異なるため、自主運用Runner向けの説明をそのまま当てはめないでください。

GitHubのmacOS Runnerを含むRunner Groupsの公式発表では、この機能の対象としてTeamとEnterpriseのプランが案内されています。同じ発表は、グループ単位の権限、並行実行の制御、ワークフロールーティングに触れる一方、macOS Runnerのネットワーク設定には対応していないとしています。契約プランや現在のアカウントで何が設定できるかは、Runner Groupsのアクセス制御に関する公式手順でも確認してください。

設定目的も分解しておきましょう。リポジトリの利用可否を管理したいのか、ワークフローの送信先を定めたいのか、並行実行を調整したいのかで、確認すべき設定が変わります。ネットワーク経路の分離は、Runner Groupのアクセス制御とは別の要件です。

信頼境界に沿ってグループを設計

グループを作る前に、リポジトリの所有者、担当チーム、ワークフローが扱う情報を見比べます。たとえば、社内ライブラリをビルドするジョブと、外部からの変更を確認するジョブ、署名やリリースに関わるジョブを、理由なく同じアクセス範囲に置かないことが重要です。

公開リポジトリや外部貢献を受けるワークフローでは、イベントの種類、使える認証情報、実行対象のコードをそれぞれ確認します。Runner Groupにアクセスを許可しただけで、これらのリスクが解消したり、ネットワークが分離されたりするわけではありません。Mac環境に関するデータの扱いも確認したい場合は、VPSMergeのプライバシーに関する案内も参照し、チームの社内規程と照らし合わせてください。

この表は設定方針を決めるための整理であり、特定の設定項目が全アカウントで利用できることを示すものではありません。利用可能な制御項目は、契約プランと現在の管理画面で確かめてください。

Runner Groupの作成とアクセス許可

組織設定でグループを作成するときは、名前だけでなく用途と責任者も記録します。アクセス設定では、対象リポジトリを選べるか、選択範囲が組織全体に及んでいないか、既定グループや既存Runnerに意図しない経路が残っていないかを確認してください。

GitHubのRunner Groupアクセス制御の公式資料を参照しながら、画面に表示される対象範囲と自分のアカウントで選択できる設定を突き合わせます。公式手順と画面の名称が異なる場合は、古い手順を前提に進めず、現在の公式資料を優先してください。

注意：グループを作っただけでは、すべてのワークフローがそのグループに切り替わるわけではありません。既存のラベル指定やグループ設定を確認し、許可対象外のリポジトリでも実行できてしまわないかを別途検証します。

確認は、許可するリポジトリと許可しないリポジトリの双方で行います。実行結果、確認した設定、担当者、変更日時を記録すれば、意図したアクセス範囲だったか後から追跡できます。組織全体のGitHub Actions利用制限も関係する場合は、組織でActionsを無効化または制限する公式資料をRunner Groupの設定と区別して確認してください。

ワークフロールーティングを検証

Runner Groupへのアクセス許可を設定したら、ワークフロー側でグループと利用可能なRunnerラベルを指定します。GitHub Actionsのワークフロー構文の公式リファレンスに記載された指定方法を使い、ラベル名は対象グループで実際に選択できるものと照合してください。

jobs:
  macos-build:
    runs-on:
      group: macos-ci
      labels: macos-latest
    steps:
      - run: echo "Runner Groupの割り当てを確認"

この例のグループ名とラベルは説明用です。実際の名称や利用可能なラベルに置き換え、アカウント上で選べることを確かめてください。ワークフローでグループを指定しても、グループ側のリポジトリアクセス許可を代替するわけではありません。

まず影響の小さいビルドで実行し、想定したRunner Groupへ割り当てられたことを確認します。次に、許可範囲外のリポジトリやジョブから利用できないことを検証します。ルーティングの書き方や受理される構文は、GitHub Actionsのワークフロー構文に従ってください。

標準ラベルの変更と段階的な移行

標準のGitHub-hosted Runnerラベルを無効にする変更は、移行完了後に検討します。変更前に、組織内のリポジトリ、定期実行、リリース関連のジョブを検索し、標準ラベルに依存するワークフローが残っていないかを確認してください。見落としがあると、実行先がなくなり、ジョブの失敗や待機につながる可能性があります。

Runner Groupに設定できる並行実行の制御についても、チームの実際のジョブ量と運用要件を基準にします。未確認の上限や処理能力を前提にせず、設定画面とRunner管理の公式資料で利用可能な制御を確かめてください。変更前の状態、検証結果、切り戻し手順、担当者を記録してから適用します。

移行判断は、次の条件で分けると進めやすくなります。

• 許可対象とワークフローの両方を確認でき、代表的なジョブが新しいグループで成功した場合： 対象を段階的に広げ、旧ラベルへの依存がなくなった後に標準ラベルの制限を検討します。
• 一部のリポジトリやジョブで割り当て先を確認できない場合： 制限は保留し、該当ワークフローのルーティングとアクセス範囲を修正します。
• ネットワーク設定が必須条件の場合： Runner Groupで満たせると判断せず、現行のmacOS Runnerの制約を確認したうえで、別の実行環境も含めて要件を評価します。
• 切り戻し担当や手順が決まっていない場合： 変更を進めず、運用責任と復旧方法を先に決めます。

場面例： 複数チームが同じ組織でiOSアプリをビルドしているなら、まずリリース関連のワークフローを含む対象範囲を棚卸しします。代表的なビルドだけでなく、許可外のリポジトリからの実行拒否も確認し、その記録を根拠に次の移行対象を決めます。

長所
- リポジトリごとの利用範囲を見直し、ワークフローの送信先を管理する単位を整理できます。
- 変更と検証の記録を残すことで、許可対象や運用責任を追跡しやすくなります。

注意点
- Runner Groupはネットワーク分離を提供する機能として扱えません。
- 標準ラベルへの依存を洗い出さず制限すると、移行漏れのジョブに影響します。

よくある質問

Runner Groupで利用できるリポジトリを限定する方法

組織設定で対象Runner Groupのアクセス範囲を確認し、業務上必要なリポジトリだけを許可する方針にします。設定できる範囲は契約プランや画面によって異なるため、公式のアクセス制御資料と実際の選択肢を照合してください。許可対象だけでなく、対象外のリポジトリで利用できないこともテストし、結果を変更記録に残します。

macOSワークフローを指定グループへ送る方法

ワークフローのruns-onでRunner Groupと、そのグループに対応するラベルを指定します。ラベルだけでグループへのアクセスが許可されるわけではないため、グループ側のアクセス制御も確認してください。まず低リスクのジョブで割り当て先を検証し、許可範囲外からの実行が拒否されることを別に確認します。

標準Runnerラベルを無効にする前の確認事項

既存ワークフローが標準ラベルを使っていないか、移行先グループとラベルを選べるか、代表的なビルドや定期実行が成功するかを確認します。特にリリース処理など、失敗時の影響が大きいジョブは個別に検証してください。切り戻し手順と担当者を決め、記録を残してから制限を適用します。

macOS Runner Groupでネットワークを分離できるか

Runner Groupの用途は、グループへのアクセスやワークフローの割り当てを管理することです。GitHubの公式発表では、macOS Runnerはネットワーク設定に対応していないとされています。そのため、Runner Groupをネットワーク分離の代替策として採用しないでください。接続経路に要件がある場合は、必要条件を明文化して実行環境そのものを比較します。

要件に合う実行環境を選ぶ

Runner Groupでアクセス範囲とルーティングを整理できても、ネットワーク設定の不足や、必要な実行環境を用意できない問題まで解決するわけではありません。GitHub-hosted macOS Runnerの制約が要件に合うなら、まずグループ設定と移行検証を進めるのが妥当です。ネットワーク要件などが満たせず別のMac環境を検討する場合も、GitHubとの連携が自動で成立すると想定せず、接続方法や運用手順を個別に確認してください。

恒常的に大きな負荷が続くなら、自社でMacを調達する方法も比較対象です。一方、短期の検証や期間限定のビルド環境が必要なら、購入後の保守や資産管理を抱えずに済むMacレンタルが選択肢になります。要件が合うか確かめたい場合は、VPSMergeのMac利用案内を確認し、必要な環境や利用条件を問い合わせてください。

よくある質問