GitHub Actions macOS Runnerはホステッドかセルフホステッドか？2026年の選定

ビルド負荷に波があり、Runnerの保守まで手が回らない状態ですか？
不規則な負荷にはGitHubホステッド、継続的なビルドや環境制御にはセルフホステッドMac、両方あるなら混合構成を候補にし、実績と総運用コストで確かめます。

この記事は、iOSプロジェクトのGitHub Actions環境を選ぶIT責任者や技術責任者向けです。
長期費用を見積もる購買担当者や、複数のリポジトリを管理するプラットフォームエンジニアも、比較指標と試行方法を確認できます。

最初に決めるのは負荷の割り当て

GitHub Actions macOS Runnerの選定では、単価だけでなく、環境を誰が管理するか、負荷の波にどう対応するかを合わせて判断します。まずはホステッドとセルフホステッドの違いを整理し、混合構成も候補に残します。

ここでいう比較対象は、GitHubが管理するmacOS Runnerと、チームが管理するMac Runnerです。別のCIサービスとの比較ではありません。Runnerの基本的な役割はGitHubのRunner概念説明でも確認できます。

iOS CI/CD構築コストは項目を分けて積み上げる

GitHubホステッドRunnerでは、利用時間に応じた請求と、プランに応じた利用条件を確認します。セルフホステッドRunnerはGitHub ActionsのRunner利用分が請求されない場合でも、マシンの調達費や運用工数がなくなるわけではありません。GitHub Actionsの公式課金説明で、導入時点の課金対象とプラン条件を確かめてください。

表の空欄は、チーム自身の請求記録、見積書、作業時間で埋めます。金額が未確認のまま「自前なら安い」と決めず、Runnerの請求と人件費を別々に記録してから合算してください。無料枠もプランや利用条件に左右されるため、恒久的な割引として扱わないのが安全です。

注意：料金、無料枠、利用条件は変更されることがあります。比較表を作る時点で公式の課金説明を再確認し、過去の請求額を現在の条件にそのまま当てはめないでください。

環境制御は代表的なワークフローで確かめる

GitHubホステッドRunnerはGitHub側が提供する環境を使い、セルフホステッドRunnerはチームがマシンやソフトウェアを管理します。GitHubはホステッドRunnerの仕様とセルフホステッドRunnerの管理責任をそれぞれ公開していますが、どちらが個別のプロジェクトで速い、または安定するとは、公開情報だけでは判断できません。ホステッドRunnerの仕様とセルフホステッドRunnerの管理説明を照らし合わせ、実際のワークフローで確認します。

代表的なビルドを選び、環境初期化に要した時間、依存関係のインストール結果、ビルドの成否を両方式で記録します。OSやツールの更新後にも同じ処理を実行し、再現性や追加の保守作業がどちらに生じるかを比べます。

チームで固定したい依存関係が多い場合は、バージョン指定や初期化処理を管理する負担も評価対象です。内部ネットワークへの接続が必須なら、必要な通信経路と管理責任を先に確認し、接続できるという前提だけで選ばないようにします。

弾力性はピークと待ち時間の実績で見る

Runnerの選択を左右するのは、平均的な実行回数だけではありません。リリース前にビルドが集中するか、複数リポジトリの処理が重なるか、待ち時間がどのワークフローに偏るかを履歴から確認します。

GitHub ActionsにはプランやRunner種別に応じた同時実行の制限があります。チームの実際の処理能力は公開上限だけでは決められないため、公式の同時実行制限を参照しつつ、待ち時間と並行実行の記録を照合してください。大規模なホステッドRunnerを検討する場合は、通常のRunnerと条件が異なる可能性があるため、大型ホステッドRunnerの説明も確認します。

チームの実行状況を把握するには、組織単位の指標も役立ちます。GitHub Actionsの組織指標を確認し、利用状況の傾向を把握したうえで、自社の請求・待ち時間データと突き合わせます。公開上限からチームのビルド速度を推定するのではなく、実際のワークフローで検証します。

運用責任と試行の節目

セルフホステッドMacでは、OSやビルドツールの更新、マシンの異常、Runnerの復旧を誰が担当するかを事前に決めます。ビルド失敗時に、ワークフローの変更、依存関係、ホスト環境のどこから調査するかも整理してください。ホステッドRunnerでも、ワークフローや依存関係の保守は残ります。マシンの管理が軽くなることと、CI運用全体が不要になることは別です。

試行は次の節目で進めます。専任の保守担当者がいない場合は、セルフホステッドの管理工数を推測でゼロにせず、試行の作業記録に残します。

• 対象選定： 代表的なiOSまたはmacOSワークフローを選び、実行頻度、集中するタイミング、現状の待ち時間を記録します。
• 費用整理： GitHubの請求記録、マシンの見積もり、保守に使う時間、稼働していない時間を別項目にします。
• 環境比較： 同じビルドを両方式で実行し、初期化、依存関係、成功・失敗、調査工数を記録します。
• ピーク確認： 実際に処理が集中した期間の待ちと並行実行を確認し、公式の制限と照合します。
• 割り当て決定： 継続的な処理、環境制御、保守能力、ピークの性質に応じ、方式ごとの担当ワークフローを定めます。
• 見直し： 請求、待ち時間、保守工数、失敗の傾向が変わったら、実行先の分け方を再評価します。

組織の実行状況と合わせて比較を進める際は、NowMiniの日本語ガイド一覧も確認できます。

よくある判断上の疑問

セルフホステッドならGitHubへの費用は発生しませんか？

Runnerの利用時間に対する課金と、GitHub Actionsに関連するすべての費用は同じではありません。保存容量など、別の請求対象が適用される場合もあるため、現行の課金説明で該当条件を確認してください。Macの費用や担当者の作業時間も含めて比べると、実際の運用コストを見落としにくくなります。

GitHubホステッドRunnerに残すビルドをどう決めますか？

環境を固定する必要性、実行頻度、内部ネットワークへの依存、管理担当者の有無を一緒に確認します。機械の管理負担を抑えたい不規則なビルドは候補になりますが、適合性はワークフローの実行記録で判断してください。初期化時間や待ち時間を含めた比較が必要です。

ホステッドとセルフホステッドを同じチームで使えますか？

使えます。定常的なワークフローとピーク時のワークフローを分けるなど、処理の性質に合わせて割り当てます。実行先ごとに請求、待ち、失敗、保守工数を記録し、混合構成が実際に運用を複雑にしすぎていないかも確かめてください。

記録を埋めてからMac環境を選ぶ

まずチームの構築記録を使って、負荷の変動、環境制御の必要性、待ち時間、保守工数を比較表に記入します。負荷が不規則でマシンの維持を減らしたいならGitHubホステッドを優先し、ビルドが継続的で環境管理や内部接続が重要ならセルフホステッドMacを評価します。定常処理とピークの両方がある場合は、混合構成を小さく試します。

自前のMacでは、調達や保守に加えて、遊休時間と障害対応が負担になることがあります。一方、ホステッドRunnerは利用条件や環境の選択肢を確認する必要があり、チームが必要とする制御を満たすとは限りません。セルフホステッドが記録上の候補になった場合は、NowMiniの接続・利用案内で遠隔Mac環境と提供方法を確認し、実際の要件に合うかを確かめてから試行に進んでください。

よくある質問