# プロビジョニングの仕組み

> GitHub でジョブがキューに入ってからランナーがピックアップするまでに何が起きるか: ウォームプール、ジャストインタイム登録によるコールドスタート、同時実行の上限、そしてジョブが待たされる理由。

Source: https://latchkey.dev/ja/documentation/runner-provisioning

## Summary

- キューに入ったジョブは、数秒でウォームランナーにピックアップされるか、新しいマシンが約 10 秒でジャストインタイム登録によりコールドスタートします。
- すべてのランナーはエフェメラルです: VM ごとに 1 ジョブ、単回使用の認証情報、ジョブ後にマシンは終了されます。
- 現在はすべてのプランが同じウォームのベースラインを受け取ります: `latchkey-small` 上の常時オンのウォームランナー 1 台とパーク済み容量です。それを超える需要はコールドスタートします。
- ワークスペースごとにデフォルトで 20 の同時ビジーランナー。アイドル状態のウォームランナーが上限にカウントされることは決してありません。

GitHub が `latchkey-*` ラベル付きのジョブをキューに入れると、Webhook が即座に Latchkey に伝え、Latchkey は 1 つの判断を下します: ジョブを既にウォームなランナーに渡すか、そのために新しいマシンを起動するか。あなたがその判断を目にすることはありませんが、それが数秒でのピックアップと約 10 秒でのピックアップの違いであり、このページで扱う内容の大半を説明するものです。

## ウォームピックアップ vs コールドスタート

**ウォームピックアップ** は、事前にプロビジョニングされたランナーがあなたのワークスペース向けに既にオンラインだったことを意味します: ジョブはそのままそのランナーに渡され、数秒以内に開始します。**コールドスタート** は、適合するウォームランナーがなかったことを意味します: そのジョブのためだけに新しいマシンが起動し、ジャストインタイムの単回使用構成で GitHub に登録し、約 10 秒であなたのステップを実行し始めます。どちらのパスも終わり方は同じです: ランナーは正確に 1 つのジョブを引き受け、ジョブが終了するとマシンは終了されます。

## ウォームプール

| プラン | ウォームプール |
| --- | --- |
| Developer | ウォームな `latchkey-small` ランナー 1 台とパーク済み容量 |
| Launch | 同じベースライン: ウォームランナー 1 台とパーク済み容量 |
| Scale | 同じベースライン: ウォームランナー 1 台とパーク済み容量 |

現在はすべてのプランが同じウォームのベースラインを受け取り、その対象は `latchkey-small` のみです: 常時オンのウォームランナー 1 台と、数秒で再開するパーク済みマシンです。それを超えるもの、およびより大きなサイズを要求するジョブは、約 10 秒でコールドスタートします。ウォーム容量はアイドル中に何のコストもかかりません。課金はジョブの分単位であり、アイドル状態のウォームランナーはジョブを実行していないからです。

## 常にエフェメラル

プロビジョニングがマシンを再利用することは決してありません。ウォームでもコールドでも、ランナーは正確に 1 つのジョブを引き受け、その後ディスクとともに終了されます。GitHub の実行ビューでランナー名が実行ごとに変わるのはこのためであり、ジョブがローカルディスクに書き込んだものがジョブ終了時に消えるのもこのためです。この設計のセキュリティ面、すなわちジャストインタイムの認証情報、プライベートネットワーキング、暗号化された単回使用ディスクについては、[セキュリティアーキテクチャ](/documentation/security-architecture) で扱います。

## 同時実行

ワークスペースはデフォルトで最大 **20 の同時ビジーランナー** を実行し、カウントされるのはビジーなランナーだけです: アイドル状態のウォームランナーがスロットを消費することは決してないため、ウォーム容量があなたの実際のジョブと競合することはありません。バーストが一度に 20 を超える場合、あふれたジョブはスロットが空くまでキューに留まり、その後自動的に開始します。何もエラーにならず、何も失われません。ピーク時に定期的にキュー待ちが発生するなら、より高い上限が利用可能です。[サポートに連絡してください](/support)。

## ハードな境界

- ジョブの上限は **4 時間** です。ジョブがまだ実行中でも、マシンは 4 時間で終了されます。
- ランナーは **x86_64 上の Ubuntu 24.04 LTS** のみです: Windows、macOS、arm64、GPU ホストはありません。
- ランナーは **AWS us-east-1** で実行されます。

ディスクサイズやプランごとのカスタム構成数を含む完全な表は、[上限と同時実行数](/documentation/runner-limits) にあります。

## ジョブが queued のまま留まる理由

プロビジョニングがランナーを起動できない、または起動しない場合、GitHub 側にエラーはありません。ジョブはただ待ちます。これは設計によるものです: `latchkey-*` ラベルを対象とするジョブは、エラーになるのではなく GitHub でキューに留まります。よくある原因:

- **ラベルのタイプミス**: どの構成もラベルに一致しないため、何もジョブをピックアップしません。
- **リポジトリが監視されていない**、またはランナーの **構成が無効になっている**。
- **課金またはトライアルのブロック**: 期限切れのトライアル、失効したサブスクリプション、またはカードなしトライアルで使い切った無料ティア。これが起きると "Managed runner blocked" 通知が、1 日に最大 1 回発火します。
- **カスタムランナーのイメージがまだビルド中**: そのラベルを対象とするジョブは、ビルドが完了するまで待ちます。
- ワークスペースが **20 ビジーランナーの上限** に達している: スロットが空き次第、ジョブは開始します。

各原因の確認方法を含む、症状ごとのウォークスルーは [トラブルシューティング](/documentation/troubleshooting) にあります。

### ジョブが queued のまま止まるのはなぜですか?

ウォームの基準容量を超えて待機している場合は、新しいマシンが約 10 秒でコールドスタートします。それ以外は何かがブロックしています。ラベル、監視設定、構成、請求、進行中のイメージビルド、同時実行の上限のいずれかを、この順で確認してください。

### ウォームピックアップとコールドスタートの違いは?

ウォームピックアップは既に稼働中のマシンに数秒でジョブを渡します。コールドスタートは Just-in-Time 登録で新しいマシンを用意し、約 10 秒かかります。現在はすべてのプランが同じウォーム基準を持ち、常時稼働のウォームランナー 1 台に加えて `latchkey-small` の待機容量が用意されます。

### アイドル状態のウォームランナーは同時実行の上限に数えられますか?

数えられません。既定のワークスペースあたり 20 台という上限はビジー状態のランナーのみを数えるため、仕事を待っているウォーム容量が上限を消費することはありません。

---

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