# CIにおけるCold Start vs Warm Start: 待ち時間はどこから来るのか

> cold startはjob開始前に新しいrunnerをプロビジョニングし、warm startは準備済みのものを再利用します。なぜcold startがCIを遅くするのか、warm poolがどう役立つのかを学びましょう。

Source: https://latchkey.dev/ja/learn/ci-cd-concepts/cold-start-vs-warm-start-ci  
Updated: 2026-06-25

cold startとは、jobが始まる前にrunnerを作成して起動しなければならないことを意味し、warm startとは、すでに1つが待機していることを意味します。その違いは、どのstepが実行される前にも感じるキューから開始までの遅延です。

jobが1つのstepを実行する前に、runnerは存在し、起動し、登録され、割り当てられなければなりません。それがオンデマンド（cold）で行われるか、準備済みのpool（warm）から行われるかが、各jobの前にどれだけのアイドル待ち時間が置かれるかを決めます。

## cold startに含まれるもの

- 新しいインスタンスのプロビジョニング（VMの割り当て）。
- runner imageの起動とエージェントの開始。
- CIサービスへの登録とjobの割り当て。
- そこで初めて - そのときになってようやく - 最初のstepが始まります。

## warm startが省くもの

warm startは、あらかじめプロビジョニング、起動、登録されたrunnerのpoolから引き出します。jobはほぼ即座にそのうちの1つに引き渡され、プロビジョニングと起動の遅延を省きます。最初のstepは、jobを割り当てるのにかかる時間程度で始まります。

## トレードオフ

warm runnerは、仕事を待ってアイドルしている間もお金がかかります。cold startは各jobにレイテンシのコストがかかりますが、アイドル中は何もかかりません。マネージドrunnerプラットフォームは、需要に合わせてサイズを調整したwarm poolでこれをバランスします。通常の負荷を吸収できるだけの準備済みrunnerを用意し、あふれた分はcold startのプロビジョニングで対応します。

## コストと体感にとって重要な理由

cold startの時間は、依然として支払う可能性のあるデッドタイムであり（job内のセットアップは課金対象です）、特に短いjobが多いとCIを重く感じさせます。それを - warm poolと起動の速い無駄のないimageによって - 減らすことで、請求と開発者体験の両方が改善されます。長いキューの後の緑のチェックも、依然としてプロビジョニングの問題を隠しています。

## FAQ

### What is Cold start vs warm start in CI: where the wait comes from?

Before a job runs a single step, a runner must exist, boot, register, and be assigned. Whether that happens on demand (cold) or from a ready pool (warm) determines how much idle wait sits in front of every job.

### What a warm start skips?

A warm start draws from a pool of runners that were provisioned, booted, and registered ahead of time. The job is handed to one almost immediately, skipping the provisioning and boot delay. The first step starts in roughly the time it takes to assign the job.

### The trade-off?

Warm runners cost money while idle, waiting for work. Cold starts cost latency on each job but nothing while idle. Managed runner platforms balance this with a warm pool sized to demand: enough ready runners to absorb normal load, with cold-start provisioning for overflow.

### Why it matters for cost and feel?

Cold-start time is dead time you may still pay for (setup inside the job is billable) and it makes CI feel sluggish, especially with many short jobs. Reducing it - via warm pools and leaner images that boot faster - improves both the bill and developer experience. A green check after a long queue still hides a provisioning problem.

---

Latchkey runs CI/CD that repairs its own failures. Agent entry points: https://latchkey.dev/agent.txt, https://latchkey.dev/openapi.json, https://latchkey.dev/llms.txt