2026年、GitHub Actions iOS CIにはどのMacを使う？ホスト型RunnerかクラウドMacか

GitHub Actionsのconcurrencyでは、同じグループ内に実行中のジョブがある場合、待機中として保持されるジョブは1件で、新しい待機ジョブが来ると置き換えられることがあります。GitHubの並列実行ルールを踏まえると、低頻度のiOS CIはまずホスト型macOS Runnerを試し、待ち時間や環境制御が実際の課題になった段階でクラウドMacを比較するのが堅実です。単発のビルド時間だけでなく、待機、実行、保守、ノードの清掃まで同じ条件で確認してください。

個人開発者：ときどきiOSアプリをビルドし、CIのためにMacを常時管理したくない方。
小規模チーム：複数リポジトリで使うmacOS実行環境を選定したい方。
技術責任者：ホスト型Runnerと自主管理ノードの運用境界を比較したい方。

GitHub Actions iOS CIの判断軸を、まず既存の実績から決める

「iOS CIだから自前のMacが必要」とは限りません。Xcodeを使う工程でmacOSが必要かどうかと、そのmacOS環境を誰が管理するかは別の判断です。ビルド頻度、実際のキュー待ち、利用するXcodeやツールの固定要件、担当者が引き受けられる保守作業を、今のワークフローから確認します。

ビルドが少なく、環境を細かく変更する要件もないなら、GitHub Actionsのホスト型Runnerを基準にします。定期的なジョブや複数リポジトリの実行が増えても、最初からMacを増やすのではなく、まず待っている時間と実際に処理している時間を分けて測ります。構築数だけでは、Runner不足が原因かどうかは分かりません。

Xcodeと依存ツールの固定範囲を比べる

Xcodeの対応OSや利用可能なバージョンは、開発環境を決める前に確認が必要です。AppleのXcodeシステム要件とバージョン表を参照し、プロジェクトが必要とするXcodeをホスト型Runnerで選べるか、または自主管理環境で維持する必要があるかを整理します。

ホスト型Runnerでは、GitHubが提供するラベルから実行環境を選びます。利用できるイメージやプリインストール済みツールは変更される可能性があるため、指定したイメージだけで必要なツールの状態を永久に固定できるとは限りません。GitHubのホスト型Runnerの仕様で選択肢を確認し、Xcodeのバージョンや依存ツールをワークフロー内で明示できるか試してください。

自主管理のMacなら、必要なツールや環境変数を揃えやすくなります。その代わり、OS・Xcodeの更新、証明書や依存ツールの整備、キャッシュの削除、Runner更新後の動作確認がチーム側の仕事になります。キャッシュも環境の再現性を自動で保証する機能ではありません。キーの設計や復元条件を確認し、GitHubの依存関係キャッシュの仕様に沿って、キャッシュがない状態でもビルドできることを確かめます。

同じ条件で再実行できるワークフローを用意する

まず、代表的なリポジトリでビルドとテストを行うジョブを一つ選びます。ブランチ、コミット、依存関係の取得方法、テスト対象を揃え、Runnerの指定以外は同じワークフローで動かします。

jobs:
  ios-build:
    runs-on: ${{ vars.IOS_RUNNER_LABEL }}
    steps:
      - uses: actions/checkout@v4
      - name: Xcodeと依存ツールの確認
        run: |
          xcodebuild -version
          swift --version
      - name: ビルドとテスト
        run: xcodebuild test -scheme "$SCHEME" -destination "$DESTINATION"

IOS_RUNNER_LABELには、試すホスト型または自主管理Runnerのラベルを設定します。リポジトリ内に必要なバージョンや設定を記録し、実行ログにもXcodeとSwiftのバージョンを残します。ワークフローの書き方やジョブ間の依存関係は、GitHub Actionsのワークフロー構文を確認してください。

待ち時間と並列実行の制約を実測する

Actionsの画面で、ジョブがキューに入った時刻、実行を開始した時刻、終了した時刻を記録します。キュー待ち時間と実行時間を混ぜると、「ビルドが遅い」のか「Runnerを待っている」のかを区別できません。同じワークフローでも、初回とキャッシュ利用時の差、テストの失敗理由、時間帯による待ち方を記録すると、ボトルネックの説明が具体的になります。

並列数を増やす前に、ジョブが同じconcurrencyグループに入っていないかも見直します。キャンセルや待機ジョブの置換が設定に影響しているなら、Macの台数を増やしても解決しない場合があります。逆に、ジョブが実行ノードを待つ状態が繰り返し確認でき、処理を分割しても支障が残るなら、自主管理ノードを試す根拠になります。

Runnerの権限と清掃を運用要件に含める

自主管理Runnerでは、ラベルでジョブの割り当て先を示し、必要に応じてRunnerグループで利用できるリポジトリを制限します。ラベルの適用方法とRunnerグループのアクセス制御を確認し、どのリポジトリのジョブがどのノードを使えるかを明文化します。

公開リポジトリでは、外部からのPull Requestを自主管理Runnerで実行する設計に特に注意してください。ワークフローの内容を信頼できない人が変更できる場合、Runner上のファイルや認証情報に影響を及ぼす可能性があります。GitHubは自主管理Runnerの保護に関する注意点を示しているため、Runner追加時のセキュリティガイダンスとActionsの安全な利用に関するガイドを踏まえ、外部PRを信頼済みジョブと同じノードで処理しない構成を検討してください。

自主管理Macは、ジョブが終わっても環境が自動で初期状態に戻るとは限りません。ビルド成果物、作業ディレクトリ、認証情報、キャッシュをどう消去し、Runnerをどのタイミングで更新するかまで、導入前に担当を決めます。

構築とテストを同じ条件で試す

選定は、小規模な試走から始めます。既存ワークフローの中からビルドとテストの代表例を選び、同じコミットをホスト型Runnerと候補のクラウドMacで動かします。比較対象の環境ではRunnerラベル、Xcode、依存関係、キャッシュの条件を記録し、条件の違いを結果の違いと混同しないようにします。

成功率だけでなく、失敗時に再実行が必要になったか、環境差を調べる時間がどれほどかかったか、ノードの清掃や更新作業が発生したかも残します。チーム内で同じ方法で測定できるよう、記録項目と成功条件を先に決めることが大切です。

長尾の疑問を選定条件に置き換える

iOSアプリのActions実行でmacOSが必要な範囲

Xcodeを使うビルドやシミュレーターのテストではmacOSが必要ですが、すべての処理をMac上で行う必要はありません。依存関係の確認やOSに依存しない静的解析などを別ジョブに分ければ、macOS Runnerを使う工程を限定できます。ワークフローを分ける前に、各工程が本当にmacOSを要件としているか確認してください。

ホスト型と自主管理型の分岐点

ホスト型から始め、環境を維持する作業や実測された待ち時間が問題になったとき、自主管理型を比較します。独自ツールを固定しやすい点だけを見るのではなく、更新、アクセス制御、清掃、障害対応を誰が担うかも評価します。必要な制御が明確でなければ、ホスト型を継続する判断も合理的です。

自前のMacを継続運用する場面

チームが特定のツール構成を継続して再現する必要があり、実行ノードの管理者と安全な運用手順を確保できるなら、自主管理Macの価値が高まります。一方、ビルドがまれで、環境の細かな変更も必要ないなら、CI専用のMacを保守し続ける負担が便益を上回る可能性があります。要件が一時的か継続的かを分けて考えます。

比較時に残す実行データ

キューに入った時刻、実行開始と終了の時刻、成否、Xcodeと依存ツールのバージョン、キャッシュの状態、環境差による失敗、清掃・更新にかかった作業を記録します。待ち時間と実行時間を別々にすれば、ノードの混雑とビルドそのものの遅さを切り分けられます。同じコミットとワークフローを使うことも、比較の前提です。

記録した指標から、移行先と範囲を決める

次の条件分岐で、試走結果を選択に結び付けます。条件が曖昧な場合は、全リポジトリを一度に移行せず、ホスト型Runnerを維持したまま代表的な一つで検証します。

• 構築頻度が低く、標準的なXcode環境で再現でき、キュー待ちも業務上の問題になっていない場合： ホスト型macOS Runnerを選びます。保守責任を増やす理由がデータで確認できるまでは、自主管理Macの導入を急ぎません。
• 特定のツールや環境を継続して固定する必要があり、環境差による失敗も確認できている場合： クラウドMacを試します。実行環境の固定だけでなく、更新担当、権限、清掃手順も運用計画に入れます。
• 待ち時間が課題に見えるものの、同じconcurrencyグループやワークフロー設定が原因か判別できていない場合： 先に設定と待機記録を見直します。ノードの追加は、Runner待ちが原因だと確認してから判断します。
• 一部のリポジトリだけに固有要件がある場合： 全体を移行せず、そのリポジトリだけ自主管理Runnerで実行する案を比較します。要件のないリポジトリはホスト型のままにし、権限境界も分けます。

CIのために専用Macを手元で維持すると、購入や設置だけでなく、OS更新、Xcode更新、稼働確認、故障時の対応も継続的に必要です。一方、ホスト型Runnerは環境変更や実行枠を自分で細かく制御できない場合があり、固定環境が必要なチームには制約になります。まず自分たちのキュー待ちと保守記録で必要性を確かめ、自主管理の実行ノードが妥当なら、Kvmkitの日本向けMacレンタル情報で現在の提供条件を確認してください。あわせてKvmkitのサービス案内も参照し、実際の要件に合う選択肢を検討できます。恒常的な高負荷や物理ポートへの接続が必要な場合は、レンタルと購入を含めて運用要件に合う方法を選びます。

よくある質問