# 上限と同時実行数

> ジョブの実行時間の上限、同時実行数、アーキテクチャのサポート、ディスクサイズ、そしてプランごとのカスタムランナー構成の上限。

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

## Summary

- ジョブの最大実行時間は 4 時間。ワークスペースあたりデフォルトで 20 のビジーなランナーが同時実行可能。
- Linux x86_64 のみ: 現在 Windows、macOS、arm64、GPU ホストのランナーはありません。
- ランナーは単回使用です。出力はアーティファクトとキャッシュで永続化してください。

## 数値

| 上限 | 値 |
| --- | --- |
| 最大ジョブ実行時間 | ランナーあたり 4 時間。ジョブがまだ実行中でも 4 時間でマシンは終了されます |
| 同時ジョブ | ワークスペースあたりデフォルトで 20 のビジーなランナー (アイドルのウォームランナーはカウントされません)。より高い上限も利用可能 |
| オペレーティングシステム | Ubuntu 24.04 LTS のみ (Windows や macOS のランナーはありません) |
| アーキテクチャ | x86_64 (amd64) のみ。arm64 ホストランナーはありません (arm イメージは docker buildx でクロスビルド可能) |
| ディスク | 100 GB (small、medium、large)、200 GB (xlarge)、カスタム構成では 100 から 500 GB |
| カスタムランナー構成 | Developer と Launch: 2、Scale: 10、Enterprise: 無制限 |
| リージョン | ランナーは AWS us-east-1 で実行されます |

## 上限に達したときの対処

これらの数値は、どれかが実際に効いてくる日にのみ問題になります。そうなったときにあなた側で変えること:

- **ジョブが 4 時間に近づく** ジョブの途中でも 4 時間でマシンは終了するため、この上限は予算ではなく厳格な天井として扱ってください。作業を並列ジョブに分割する (各ジョブが独自のランナーを得ます) か、同じ作業をより早く終わらせるために 1 サイズ上げてください。
- **ピーク時にジョブがキューに入る** デフォルトはワークスペースあたり 20 のビジーなランナーで、アイドルのウォームランナーはそれにカウントされません。上限を超えたジョブは、ビジーなランナーが終わるまでキューで待ちます。ピークが定期的にキューに入るなら、より高い上限が利用可能です。
- **Windows、macOS、または arm64 が必要** それらの特定のジョブは GitHub ホステッドや他のランナーに留め、同じワークフロー内で自由に混在させてください。arm64 のコンテナイメージは docker buildx でクロスビルドします。QEMU はイメージに事前構成されています。
- **ジョブがディスクを満杯にする** 自己修復はジョブの途中でディスクが満杯になるとキャッシュを削除しますが、ジョブが日常的にそのサイズの提供以上の容量を必要とするなら、恒久的な修正は最大 500 GB のカスタム構成です。

このうち 2 つには理由があります。4 時間の上限は、[自己修復](/documentation/self-healing) の再試行が請求額を膨らませないようにするのと同じセーフティネットです: ハングしたジョブがマシンや請求書を無期限に押さえられないことを保証します。そして同時実行の上限は **ビジーな** ランナーのみをカウントします。これは誤読しやすい点です: アイドルで待機しているウォームプールは 20 枠のどれも消費しないため、ウォーム容量が実際のジョブと競合することは決してありません。

## カスタムランナー構成

**Runners** ページから、独自の `latchkey-<name>` ラベルを持つカスタム構成を作成し、CPU/メモリの形状とディスクサイズを選べます。**AI Scan** フローはワークフローを分析して適切な構成を提案します。そのイメージは自動でビルドされ、ランナーが使用可能になると通知されます。イメージビルドが完了するまで、そのラベルを狙ったジョブはキューで待機します。

カスタム形状がプリセットに勝る場合やそのコストを含む完全な判断ガイドは、[AI Scan によるカスタムランナー](/documentation/custom-runners) にあります。

## 知っておくとよいこと

- ランナーは単回使用です: マシンあたり 1 ジョブで、その後破棄されます。ローカルディスクに書き込んだものはジョブが終わると消えます。永続化にはアーティファクトまたはキャッシュを使ってください。
- GitHub ホステッドランナーのラベル (`ubuntu-latest` など) は並行して機能し続けます。一度に 1 ジョブずつ移行できます。
- GPU、Windows、macOS、arm64 ホストが必要な場合は、当面それらの特定のジョブを GitHub ホステッドや他のランナーに留め、同じワークフロー内で自由に混在させてください。

### Latchkey ランナーのジョブ最大実行時間は?

4 時間です。それ以上必要なジョブは、アーティファクト経由で処理を受け渡す複数のジョブに分割してください。上限に近づく単一ジョブは、たいてい並列実行できる処理を含んでいます。

### 同時に実行できるジョブ数は?

既定でワークスペースあたり同時実行 20 台です。この上限で頻繁に待ちが発生する場合は引き上げ可能です。ダッシュボードで同時使用数を確認でき、待ち行列と処理の遅さを区別できます。

### Latchkey ランナーは Windows、macOS、ARM に対応していますか?

現時点では対応していません。Latchkey ランナーは Linux x86_64 のみで、Windows、macOS、arm64、GPU ホストはありません。それらのジョブは GitHub ホスト型などのランナーに残したまま同じワークフロー内で併用できるため、パイプラインの他の部分の導入は妨げられません。

---

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