AI コーディングエージェントの CI：ループのたびに GitHub Actions を 20 分待つとき

AI コーディングエージェントのループは、push、CI 待ち、失敗を読む、直す、また push です。20 分の CI は、5 回の修正で 100 分の待ちになります。しかもエージェントは人より多く push します。Anthropic の CI のジョブ数は、6 か月で 25 倍になりました。待ちはこの順に縮めます。lint、型チェック、影響するユニットテストを、push の前にエージェントに走らせる。新しい push が来たら、同じプルリクエストの古い実行を取り消す。速いチェックを別のジョブにして、失敗が 1〜2 分で返るようにする。変更が影響するテストだけを動かす。そして、新しい VM でジョブのたびに繰り返すセットアップをなくします。Docker のレイヤー、パッケージのキャッシュ、ビルドの成果物をジョブのあとも残すマシンでは、astro の CI のジョブが GitHub の 528 秒から Skipbox の 30 秒になりました。

Skipbox は、アカウント専用のマシンでジョブを動かし、その状態がジョブのあとも残ります。runs-on: skipbox の 1行を書き換えるだけで、月 6,000 円の定額、実行時間は無制限です。エージェントが午後に 20 回 push しても請求は増えず、GitHub の予算でジョブが止まることもありません。

エージェントのループで CI がボトルネックになる理由

Anthropic のテスト影響分析の拡張についての記事によれば、「CI のジョブ数は 6 か月で 25 倍になった」。理由として挙げているのは 2 つで、Claude が「小さく細かいプルリクエストを好む」こと、そしてエージェントが「夜も週末も push する」ことです。人は修正をまとめますが、エージェントは修正ごとに push して待ちます。CI の 1分は、ループのたびに払うことになります。

1. push の前に捕まえられるものは捕まえる

いちばん速い CI の実行は、落ちない実行です。CI と同じ lint、型チェック、ユニットテストのコマンドをエージェントに渡し、変えたファイルについて push の前に毎回走らせます。タイプミスは手元の数秒で済み、20 分の往復になりません。

2. 新しい push で置き換わる実行を取り消す

前の実行がまだ動いているうちにエージェントが修正を push すると、同じプルリクエストに実行が 2 つ残ります。古いほうを取り消します（同時実行の制御）。

concurrency:
  group: ${{ github.workflow }}-${{ github.head_ref || github.run_id }}
  cancel-in-progress: true

github.head_ref はプルリクエストにしかないので、main への push はそれぞれ別のグループになり、取り消されません。

3. 速いチェックを先に返す

lint と型チェックは、前に needs: を置かない別のジョブにし、遅いテストは別のジョブにします。エージェントは E2E のジョブを待たずに、最初の失敗をすぐに読めます。

4. 変更が影響するものだけを動かす

25 倍への Anthropic の答えは、「変更ごとにどのテストを動かすかを決める」テスト影響分析のサービスでした。たいていのリポジトリは、もっと小さく始められます。Turborepo なら turbo run test --affected（Turborepo の CI のガイド）、1 つのディレクトリにしか関係しないワークフローにはパスのフィルター、そして選び漏れを捕まえるために、マージ後の main ではすべて動かします。

5. ループのたびに同じ状態を作り直さない

GitHub ホストランナーでは、ジョブは毎回新しい VM で始まります。ツールを入れ直し、依存パッケージのキャッシュをダウンロードして展開し、Docker のレイヤーを pull するか作り直し、ビルドはゼロからです。エージェントのループが 1 日に 100 回あれば、待ちのほとんどはこのセットアップです。ディスクをジョブのあとも残すランナーなら、それは最初からそこにあります。

実際のプロジェクトを動かした結果から。ワークフローは変えていません。

6. 実行時間だけでなく、同時に動くジョブの数も見る

何体かのエージェントがそれぞれマトリックス付きのプルリクエストを push すると、GitHub の標準ランナーの同時実行の上限に届きます。GitHub Free で 20、Pro で 40、Team で 60、Enterprise で 500 です（上限）。超えたジョブは待ちます。分課金なら、そのジョブも 1 つずつ課金されます。上限に達した予算は、「The job was not started because recent account payments have failed or your spending limit needs to be increased」でジョブを止めます（対処）。

Skipbox がエージェントの CI にすること

プランごとに、アカウント専用のマシンが付き、ジョブのあとも残ります。

• 状態が残ります。 Docker のイメージ、レイヤー、ビルドキャッシュ。~/.npm、pnpm のストア、~/.cache、Go・Gradle・Maven・Cargo のキャッシュ。setup-* で入れたツール。ビルドを残す設定なら、チェックアウトと Cargo の target/、turbo 2 のプロジェクトならいちばん上の .turbo も。
• 実行時間は無制限です。 GitHub の予算や支出の上限で、Skipbox のジョブが止まることはありません。
• 同時に動くジョブは、プランの vCPU の分です。 アカウントが持つプランの vCPU に収まるあいだはジョブが同時に動き、残りは順番を待ちます。待っている数と時間はアカウントのページに出ます。S 1 つなら、4 vCPU のジョブが 1 つずつ動きます。プランはどんな組み合わせでも足せます。
• エージェント自身のジョブもそこで動きます。 runs-on を skipbox にするだけです。

4 vCPU で月 20,000分なら、GitHub の請求は 約 35,120 円参考値：2026年11月10日の為替レート・1ドル＝158.22円。米ドルの料金を、このレートで円に換算した概算です。、Skipbox の S は 6,000 円です。月 30,000分なら 約 54,110 円参考値：2026年11月10日の為替レート・1ドル＝158.22円。米ドルの料金を、このレートで円に換算した概算です。です。

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

jobs:
  checks:
    runs-on: skipbox # ubuntu-latest から書き換える

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

セキュリティ

• マシンはアカウントごとの専用です。ほかの会社のジョブと同じマシンで動くことはありません。
• ジョブが終わるたびに、ランナーの認証情報、プロセスとコンテナを消し、残したチェックアウトからも git の認証情報と追跡していないファイルを消します。「毎回クリーン」なら、ジョブごとに新しいマシンで動きます。
• 書き込み権限のない人のコード（フォークからのプルリクエストなど）は、使い捨ての VM で動きます。キャッシュは読めますが、書き換えられません。

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

エージェントが待っているジョブで試す

カード不要で、7日間かジョブの合計 3,000分まで無料です。エージェントが待っているジョブを runs-on: skipbox にし、エージェントに 2 回 push させて、2 回目の実行を GitHub と比べてください。

2026年11月13日 更新