GitHub Actions macOS Runnerの選び方：ホステッドかセルフホステッドか（2026）

GitHub ActionsのmacOS Runnerは、ビルド頻度が低く環境管理を減らしたいならホステッドRunnerを優先してください。独自のツールチェーンを維持したい、同じMac環境を継続して使いたい、実行方法を管理したい場合は、セルフホステッドRunnerを検討します。自分で管理するMacは、手元の実機に限りません。遠隔Mac環境も選択肢です。

• iOSのビルドを時々実行し、Runnerの保守をできるだけ避けたい個人開発者。
• 固定したmacOSやXcode環境を必要とする開発者。
• 個人の自動ビルドを継続的なリリース工程に広げたい小規模チーム。

ビルド負荷と並列性

最初に見るのは、Runnerの種類ではなく、ワークフローがどれくらいの頻度で、どの程度の並列性を必要とするかです。ビルド数、待ち時間への許容度、同時に動くテストやブランチの数を記録します。一般的な待ち時間や性能差を決めつけず、自分のリポジトリの実行履歴を判断材料にしてください。

GitHub Actionsには実行上限があります。GitHub Actions利用制限の公式説明では、ジョブの実行時間上限は6時間、ワークフロー全体の実行期間上限は35日、マトリックスジョブ数の上限は256とされています。これは上限値であり、通常のビルド目標時間や同時実行の保証ではありません。現在の制限と、自分のリポジトリに適用される条件を移行前に確認してください。

• 低頻度で短時間のビルド：まずホステッドRunnerを試します。Runnerの準備や稼働監視を自分で持たずに始めやすい構成です。
• 実行が集中するワークフロー：ビルド数と待ち時間を記録し、ホステッドRunnerの利用条件や並列実行の設定を確認します。自前のMacに切り替えても、同時実行できる台数が自動的に増えるわけではありません。
• 毎回同じ準備を繰り返すビルド：キャッシュや依存関係の管理方法を先に確認します。Runnerの種類を変える前に、準備時間の内訳を分けると、移行で解決する問題か判断しやすくなります。

ケース：週に数回のiOSビルド

リリース候補を作るときだけビルドし、標準的な依存関係で足りる個人プロジェクトなら、ホステッドRunnerから始めるのが合理的です。Runner用Macを継続して管理する負担を増やさずに、ワークフローそのものを整えられます。

一方、ビルドのたびに特殊な依存環境を準備し直している、または同じMac環境を日々の作業で繰り返し使いたいなら、セルフホステッドRunnerを評価してください。採用前に、実際のジョブ時間と環境準備の手間を記録します。

環境制御とツールチェーン

ホステッドRunnerは、GitHubが提供するRunnerの種類やラベルを選んでジョブを実行する方法です。利用可能なOSや環境は更新されるため、ワークフローの記述だけを見て利用可否を判断しないでください。GitHubホステッドRunnerの現行リファレンスで、必要なmacOS環境やラベルを確認します。

セルフホステッドRunnerでは、管理するMacに必要なツールを導入し、ワークフローから選択できるようRunnerのラベルを設定できます。だからといって、環境が自動で正しく保たれるわけではありません。macOS、Xcode、署名関連ツール、パッケージ管理ツールなどを誰が更新し、いつ変更を検証するか決めてください。Runnerの選択条件とラベルの書き方は、ジョブの実行先を選ぶ公式ガイドで確認できます。

ホステッドRunnerの利点
- MacのOSやRunner基盤を自分で運用せずに済みます。
- ワークフローの実行環境をGitHubが提供する選択肢から選べます。
- ビルド環境を細かく変更する必要がなければ、保守作業を抑えやすい構成です。

セルフホステッドRunnerの利点と負担
- Xcodeや依存ツールを含む環境を自分の要件に合わせて管理できます。
- 同じ構成を継続して使う運用に向きます。
- OS更新、ディスクの整理、Runnerの稼働確認、ジョブ後のファイル処理を自分で行います。

GitHubはホステッドRunnerとセルフホステッドRunnerの管理範囲を分けて説明しています。選択肢ごとの違いは、セルフホステッドRunnerの公式リファレンスとGitHubホステッドRunnerの現行リファレンスで照合してください。Runnerのラベルや利用条件は変わり得るため、ワークフロー作成時と移行時に現行情報を再確認します。

運用負担と継続稼働

セルフホステッドRunnerは「設定すればあとは放置できるMac」ではありません。Macが停止した場合、Runnerがオフラインになった場合、ディスクが不足した場合、ツール更新でビルドが失敗した場合に、誰が検知して復旧するかを決める必要があります。継続稼働を期待するなら、監視方法と復旧手順もRunner選定の一部です。

GitHubのセルフホステッドRunner運用とトラブルシューティングを参照し、ログ確認、Runnerの状態確認、復旧担当を決めてください。Runnerを設置したMacがオンラインでも、ジョブが必ず実行される保証にはなりません。依存先の障害やワークフロー設定も切り分け対象です。

コストは、ホステッドRunnerの課金や利用条件だけでなく、自前のMacを維持する費用と運用時間を含めて比較します。金額を一律に置くのではなく、次の項目を同じ期間で見積もってください。

• 実際のビルド時間と利用条件に基づくRunner費用。
• Macの調達またはレンタル、保守、必要に応じた通信環境の費用。
• 更新、障害対応、ディスク整理に使う担当者の時間。
• Runnerの停止中にリリースが遅れるリスクと、代替手段の用意。

自前Macの管理を担当する人がいない場合、費用だけでなく、停止時に作業が集中するリスクも比較対象です。反対に、長期にわたって継続利用し、管理作業を安定して担当できるなら、環境を固定する価値が上回る場合があります。

認証情報とアクセス境界

iOSの署名情報やApp Store Connect用の秘密情報を扱うジョブでは、Runnerがどのリポジトリ、ネットワーク、ファイルにアクセスできるかを確認します。セルフホステッドRunnerは管理下に置ける範囲が広い一方、許可したジョブが触れられる環境も慎重に制限する必要があります。

特に、外部からのプルリクエストを処理するワークフローと、署名や公開に必要な秘密情報を使うワークフローを分けてください。pull_request_targetを安全に使うための公式説明を読み、信頼できないコードと特権を持つ処理を同じ実行環境に置かないよう設計します。

実行権限を狭くするには、Runnerグループへのアクセスを必要なリポジトリに限定します。セルフホステッドRunnerグループのアクセス管理で設定を確認し、ジョブの権限もワークフロー構文の公式リファレンスに沿って必要最小限にします。ジョブ終了後の作業ファイルや認証情報の扱いも、実際の設定で確認してください。MangoVMのデータ保護に関する案内も確認し、利用する環境の情報管理方針が自分の要件に合うか照合してください。

移行の手順と選定条件

一括移行ではなく、影響の小さいジョブから試します。iOSの自動ビルド環境として使う場合も、署名や公開処理を最初に移さず、まずビルド環境とジョブの再現性を確かめます。

• ワークフローごとに、実行頻度、ビルド時間、同時実行の必要性、待ち時間への許容度を記録します。
• 使用中のmacOS、Xcode、依存ツール、キャッシュ、署名情報を一覧にします。必要な環境がホステッドRunnerの現行選択肢にあるか確認します。
• 保守担当を決めます。セルフホステッドなら、更新、ディスク整理、Runnerの停止、ログ確認、復旧の担当と手順を定めます。
• リリースに関係しないテストやビルドを新しいRunnerで実行します。成果物、依存関係、キャッシュ、ジョブ後のファイル状態を比較します。
• 権限と秘密情報を見直し、信頼できない変更が署名情報や公開処理へ到達しないことを確認してから、対象ジョブを段階的に移します。
• 移行後も実行時間、失敗原因、運用に使った時間を見直します。改善しない場合は、ワークフロー単位でホステッドRunnerへ戻せるようにします。

判断は次の条件で分けられます。

• ビルド頻度が低く、標準環境で足りるなら、ホステッドRunnerを選びます。保守を減らし、実行履歴を集めてください。
• Xcodeや依存環境の固定が必要なら、セルフホステッドMacを評価します。環境更新と復旧の担当を決められない場合は、ホステッドRunnerに戻します。
• 一部のジョブだけ特殊な環境を必要とするなら、全ワークフローを移さず、該当ジョブだけを分けます。
• 秘密情報や社内リソースへのアクセスを細かく管理したいなら、Runner単体ではなく、リポジトリ権限、Runnerグループ、ジョブ権限、作業後の清掃まで含めて設計します。必要な隔離を実現できない場合は、そのRunnerで公開処理を行わないでください。

よくある質問

ホステッドRunnerとセルフホステッドRunnerの違い

ホステッドRunnerではGitHubが提供する環境でジョブを実行し、基盤の管理を任せられます。セルフホステッドRunnerは自分が管理するMacなどに設定するため、環境を細かく制御できます。その代わり、更新や稼働確認、容量管理、アクセス権限、障害対応を自分で行います。

個人のiOSプロジェクトにセルフホステッドMacは必要か

標準的な環境で時々ビルドするだけなら、ホステッドRunnerから始めて問題ありません。特定のXcodeや依存環境を繰り返し利用したい場合、あるいは実行方法をより管理したい場合は、セルフホステッドMacを比較します。Macの維持と運用を担えるかも、採用条件に含めてください。

セルフホステッドRunnerで管理するもの

macOSやXcodeの更新、Runnerの稼働状態、ディスク容量、ログ、ジョブ後に残るファイル、アクセス権限が主な管理対象です。署名情報を扱うワークフローでは、秘密情報を利用できるジョブを絞り、外部の変更を受け取る処理と公開処理を分離します。管理項目を担当者と手順に落とし込んでから運用します。

遠隔Macへの移行を検討する時期

標準環境では足りない、同じツールチェーンを継続して使いたい、ビルド機の管理範囲を自分で決めたい、という要件が固まった段階で検討します。まず公開を伴わないビルドジョブで環境と権限を確認し、その後に署名や公開処理を移してください。ワークフロー全体ではなく、必要なジョブだけを移す選択もできます。

MangoVMを含めた遠隔Macの比較

ホステッドRunnerは始めやすい一方で、環境を細かく維持しにくい場合があり、利用条件や実行場所も自分のMacのようには管理できません。遠隔Macは環境を継続して整えやすい反面、Xcode更新、Runner管理、権限設計、障害時の対応が不要になるわけではありません。どちらが合うかは、実行頻度だけでなく、その作業を誰が担うかで判断します。

セルフホステッドに傾いているなら、契約前に必要なmacOS、ツールチェーン、接続方法、継続利用の条件を確認してください。MangoVMの遠隔Macサービス案内で利用条件を確認し、既存のワークフローに合うかを照合できます。短期の検証環境が必要な場合にはレンタルも選択肢ですが、長期の常時稼働や物理ポートが必須なら、自前のMacを含めて比較するのが適切です。

よくある質問