GitHub Actions macOS Runnerの待ち時間が長い場合は？2026年の増強判断

まずジョブが実行ステップに入ったかを確認し、並列実行やラベルの不一致、自前Runnerの停止、GitHub側の状況を切り分けてください。自分のワークフローが継続的にmacOSの処理待ちを生む場合は、セルフホストMac Runnerを並行運用の候補にできますが、GitHub側の調度障害は解消できません。

iOSの構築・公開ジョブが待機し、リリースやマージに影響している独立開発者・小規模チーム向けです。
セルフホストRunnerを管理していて、タスクの受信やラベルの一致を確認したい開発者にも役立ちます。

最終更新：2026年11月11日。GitHubの公式制限・Runner関連資料、ステータス情報、Communityのユーザー報告を確認しています。(公式制限資料、GitHub Status、Communityの投稿)

GitHub Actions macOS Runnerの待ち時間は、状態とログで見分けます

「遅い」という印象だけでは、Runnerの割り当て待ちか、構築処理の遅さか判断できません。ジョブの状態とタイムラインを確認し、最後に完了した処理がRunnerへの割り当てなのか、初期化なのか、ワークフロー内のステップなのかを特定します。

GitHub-hosted macOS Runnerでは、ジョブがステップを一つも開始していないまま止まっているのか、Runnerの起動やジョブの初期化で失敗したのかを分けます。ステップのログがすでに出ていれば、依存関係の取得、Xcodeの選択、テストや署名など、実行段階の問題として調べます。全体の実行時間だけで原因を決めないことが重要です。

macOSのジョブがQueuedのままなら、何から確認しますか。
まず対象ジョブの詳細画面で状態とタイムラインを見て、どのステップまで進んだかを確かめます。ステップが一度も開始していなければ、Runnerの割り当てやGitHubの稼働状況を確認します。すでにログがあれば、そのログの最後のエラーを起点に調べます。

GitHub CLIが利用できる場合は、実行IDを指定してジョブの状態を取得できます。

gh run view "$RUN_ID" --json status,conclusion,jobs

出力の例です。実際の値は対象の実行ごとに異なります。

{
  "status": "in_progress",
  "jobs": [
    {
      "name": "ios-build",
      "steps": []
    }
  ]
}

ステップ欄や実行ログがない状態と、ステップ開始後の失敗は別の経路で調査します。ログ上のエラーを調べる方法は、GitHub公式のワークフロー障害調査手順も参照できます。

ホステッドRunnerの容量問題と、自前の待ち行列は確認先が異なります

macOSジョブだけが待つ場合でも、直ちにGitHub側の障害とは限りません。実行前にキャンセルされたか、Runner取得に失敗したか、対象Runnerがそもそもジョブを受け取れていないかを整理してから、公式ステータスと設定を照合します。

ステップ開始前にキャンセルされた場合は、何を先に確認しますか。
キャンセル表示だけで原因を断定せず、ジョブのタイムライン、イベント、利用可能なログを保存します。Runner取得の失敗や容量に関する表示があれば、GitHub Statusと公式の制限情報を確認します。特定の日のユーザー投稿は手掛かりにはなりますが、すべてのアカウントに共通する障害や原因の証明にはなりません。

GitHub Communityでは、2026年11月3日から9日にかけて、macOS arm64のジョブが容量に関する表示に遭遇した、またはステップ開始前に失敗したというユーザー報告がありました。これは個々の投稿であり、公式の障害発表や原因・修正の確定情報として扱うべきではありません。(該当するCommunityのユーザー報告)

一方、セルフホストMac Runnerが仕事を受け取らないなら、オンライン状態、実行中のジョブの有無、ワークフローで要求するラベルとRunner groupの一致を確かめます。マシンがオフラインなのか、空いているのに条件不一致で割り当てられないのか、受信後の起動に失敗したのかでは対処が異なります。GitHub公式のセルフホストRunner監視・トラブルシューティングとラベルやRunnerの条件に関する説明を照合してください。

「キャンセルされた」という表示だけを根拠にRunnerを増やすのは避けてください。ジョブの履歴やログを保存し、キャンセルの主体と発生段階を確認してから再実行や設定変更を判断します。

並列実行の待ちと、GitHub側の処理待ちは分けて考えます

複数のイベントが同じワークフローを起動していれば、macOSジョブの列はプロジェクト自身の構成から生まれている可能性があります。ブランチへの連続プッシュ、Pull Request更新、行列実行、同じコードに対する重複検証を見直し、不要なmacOS実行がないか確かめます。

並列実行の設定が待ち時間を生んでいるかは、どう判定しますか。
同じconcurrencyグループに属する実行がどのように処理されているか、ワークフロー設定と実行履歴を照合します。古い実行がキャンセルされたり、同じグループの実行が順番待ちになったりしていれば、まずconcurrency設定と起動イベントを見直します。GitHubにはワークフローのconcurrencyを制御する仕組みがありますが、設定変更がホステッドRunnerの容量不足を解消する保証はありません。(公式のconcurrency設定ガイド)

判断の目安は次のとおりです。

GitHub公式資料では、ジョブはキューに最大24時間置かれた後に失敗し、GitHub-hosted Runnerのジョブ実行時間上限は6時間とされています。行列ジョブの上限は1ワークフロー実行あたり256件です。これらは利用可能な処理能力や待ち時間を保証する数値ではなく、設定・運用上の上限です。(GitHub Actionsの制限一覧)

待機・設定変更・Mac追加は、原因に合わせて選びます

原因を確認した後は、同じ再実行を繰り返すより、該当する分岐だけを処理します。GitHub Statusで問題が確認できるならログを保存して公式情報の更新を待ち、解消後に再実行します。セルフホスト側の問題なら、オンライン状態やラベルを修正してからテストジョブを流します。

1. 対象ジョブの状態を記録します。 実行ID、失敗時刻、状態、最後に見えたタイムラインを残します。
2. ステップが始まったか確認します。 未開始なら割り当て・初期化を、開始後なら該当ステップのログを調べます。
3. GitHub側の情報を照合します。 Statusと公式制限資料を確認し、投稿や観測を公式発表と混同しません。
4. セルフホストなら受け入れ状態を確認します。 Runnerのオンライン状況、占有状態、ラベル、Runner group、サービスログを調べます。
5. ワークフローの重複を確認します。 起動イベント、行列、concurrencyを見て、同じ変更に対する不要なmacOSジョブを減らせるか判断します。
6. 変更を一つずつ適用して再検証します。 原因候補を同時にいくつも変えると、改善の理由を判別できません。

macOS以外で完結する静的検査やコード確認を先に行い、iOS専用の処理だけを後段に分ける方法もあります。ただし、ワークフローの整理は自分の処理待ちを減らすための工夫であり、GitHub側の割り当て問題を直すものではありません。

iOSの実ジョブでRunnerを検収してから、追加を決めます

セルフホストMac Runnerを候補にする場合は、マシンがオンライン表示になるだけで採用を決めず、実際のiOS GitHub Actions構築で受信から成果物までを確認します。特定のXcodeを選べること、対象のビルドまたはテストが成功すること、成果物を必要な工程へ渡せることを検収記録に残します。

セルフホストMac Runnerは、iOS構築の待ち時間を減らせますか。
チーム自身のRunnerが継続してジョブを受け取れる状態なら、GitHub-hosted Runnerとは別の実行先として使える可能性があります。導入前に、ワークフローのラベルルーティング、Runner group、ジョブの受信、選択するXcode、対象タスクの結果を確認してください。GitHub側の調度障害が原因の場合、追加したRunnerがその障害を解消するとは限りません。

検収では、ジョブが意図したRunnerに割り当てられた記録、選択したXcode環境、ビルドやテストの結果、生成物の有無を残します。ここで確かめるのは自分のプロジェクトに必要な条件です。個別のMac環境について、実測記録なしに処理速度や利用可能性を前提にすることはできません。

GitHub-hosted Runnerを使い続ける方法はマシン管理が不要な一方、割り当てや容量を自分で制御できません。自前のMacを常時稼働させる方法には、ハードウェアの購入・保守と継続的な運用が伴います。臨時の検証環境やiOSビルド用Macが必要なら、購入前にリモートMacの利用方法とMac miniのレンタル料金を比較し、自分のワークフローでRunnerの接続と構築結果を確かめてから選ぶのが適切です。