GitHub Actions のジョブが「Waiting for a runner」のまま始まらない：原因と対処法

「Waiting for a runner to pick up this job」は、そのジョブの runs-on のラベルをすべて持つ空きランナーがない、という意味です。原因は 3つのどれかです。ラベルがどのランナーにも合っていない。セルフホストランナーがオフラインか、ほかのジョブで使用中。アカウントの同時実行数の上限に達している。まず runs-on の行を、次に Settings → Actions → Runners を見てください。

毎週のようにセルフホストのマシンが落ちて待たされているなら、直すのはランナーの持ち方です。Skipbox は、いつでもそこにいる GitHub Actions のランナーです。アカウント専用のマシンを、ヘルスチェックと復旧まで Skipbox が面倒を見ます。料金は月 6,000 円の定額で、実行時間は無制限。移行は runs-on: skipbox の 1行です。

ジョブが待たされる理由

ジョブは、runs-on のラベルをすべて持つランナーで動きます。多い順に並べると、原因はこうです。

セルフホストランナーを待っているジョブは、24時間でキャンセルされます。ラベルを間違えると、丸 1日、実行が開いたままになります。上限の数と増やし方は、同時実行数の上限のガイドにまとめました。

セルフホストランナーのジョブが queued のまま動かないとき

GitHub のセルフホストランナーの監視とトラブルシューティングのページ（2026年11月14日に確認）に、状態とログの見方があります。確かめる順はこうです。

1. 状態を見る。 Settings → Actions → Runners に、ランナーの名前、ラベル、状態が並びます。Idle は GitHub につながって待機中、Active はジョブを実行中、Offline は GitHub につながっていません。
2. Offline なら、マシンとサービス。 マシンが落ちているか、ランナーのアプリケーションが動いていないか、GitHub に届いていないかです。Linux なら sudo journalctl -u actions.runner.<org>-<repo>.<runnerName>.service -f でサービスのログを追えます。アプリケーションのログは、インストール先の _diag にあります。
3. Idle なのに取らないなら、ラベルとグループ。 runs-on に書いたラベルを、そのランナーがすべて持っているか。Organization のランナーなら、ランナーグループがそのリポジトリを許可しているか。
4. ランナーのバージョン。 ランナーのアプリケーションが古くなりすぎると、ジョブを処理できなくなります。自動更新を止めているなら、ここを疑います。

待ち時間は、人の時間

待たされるのは人です。プルリクエストが 20分キューに入っていれば、レビューが 20分遅れます。夜のうちにセルフホストランナーが落ちれば、だれかが起動し直すまで、朝のマージがすべて止まります。その「だれか」は、自分の仕事を止めて CI のマシンの面倒を見るエンジニアです。

セルフホストランナーを動かし続けるのは、終わらない仕事です。マシン、OS のパッチ、ランナーのアプリケーションの更新、Docker のイメージで埋まるディスク、前のジョブが次のジョブを壊さないための後片付け。

GitHub ホストランナーに戻せば、その仕事は分課金の請求に変わります。

GitHub の額は、GitHub Team に含まれる無料分を引いたあとの請求です。自分のチームの分数で計算するなら、トップページの料金計算に入れてください。

そして、実行が増えるほどどちらも悪くなります。AI のコーディングエージェントは時間を選ばずに push するので、ジョブが重なり、だれもランナーを見ていない時間に届きます。請求を抑えるために GitHub の予算を設定すれば、月の途中でジョブが止まります。これも待ち時間です。

Skipbox が引き受けること

落ちないランナー。 プランごとに、アカウント専用のマシンが付きます。マシンの用意、イメージの更新、ジョブごとの後片付け（ランナーの認証情報、プロセス、コンテナを消します）、ヘルスチェック、通らなかったときのクリーンなイメージからの作り直しまで、Skipbox が行います。チームのだれも、何も起動し直しません。2026年11月13日からは、チェックアウトしたコードと Cargo のビルド結果（target/）を専用のマシンに残し、次のジョブで使います。「毎回クリーン」なら、ジョブごとに新しいマシンで動きます。

同時に動かす数は自分で決める。 GitHub から見ると Skipbox のジョブはセルフホストランナーのジョブなので、GitHub ホストの同時実行数の上限には数えられません。Skipbox で同時に動く数は、プランの vCPU で決まります。収まらないジョブは順番を待ち、前のジョブが終わるとすぐ始まります。待っているジョブの数と時間は、アカウントのページに出ます。もっと同時に動かすなら、プランを足します。

ジョブが短くなり、待ちも短くなる。 マシンには Docker のレイヤー、パッケージのキャッシュ、ツールがジョブのあとも残ります。準備にかかる時間が減り、ランナーが早く空きます。

予算で止まらない。 実行時間は無制限です。Skipbox のジョブは GitHub の分数を使わないので、GitHub の予算で止まることもありません。

移行は runs-on を 1行書き換えるだけ

jobs:
  build:
    runs-on: skipbox # ubuntu-latest や self-hosted から書き換える
    steps:
      - uses: actions/checkout@v4
      - run: npm ci && npm test

1. Skipbox に GitHub でログインする
2. Skipbox の GitHub アプリを入れて、使うリポジトリを選ぶ
3. runs-on を書き換えて push する

Skipbox のジョブが始まらないときは、アカウントのページに、待っているジョブとして出るか、動かさなかった理由が出ます。ページにないジョブは、Skipbox に届いていません。ラベルのつづりと、アプリがそのリポジトリを使えるかを確かめてください。全部の場合はジョブが待機中のままにあります。

セキュリティ

• マシンはアカウントごとの専用です。ほかの会社のジョブと同じマシンで動くことはありません。
• ジョブが終わるたびに、ランナーの認証情報、プロセスとコンテナを消します。2026年11月13日からは、チェックアウトしたコードと Cargo のビルド結果（target/）を専用のマシンに残し、次のジョブで使います。「毎回クリーン」なら、ジョブごとに新しいマシンで動きます。
• 書き込み権限のない人のコード（フォークからのプルリクエストなど）は、使い捨ての新しいマシンで動きます。

くわしくはジョブの分離のしくみにあります。

まず、いちばん待たされるジョブで試す

カード不要で、7日間かジョブの合計 3,000分まで無料です。いちばんよく待たされるジョブを runs-on: skipbox に替えて push してください。

2026年11月14日 更新