NamespaceからLatchkeyへの移行: 率直な比較 + 手順
NamespaceとLatchkeyは、どちらもruns-onの入れ替えでアクセスできるドロップインのGitHub Actions runnerを提供します。率直な違いは重点の置き方です。Namespaceは生のbuild速度と幅広いcache/buildプラットフォームに最適化し、Latchkeyは自己修復による信頼性と1分あたりのコストに最適化します。
Namespaceのドキュメントによれば、Namespaceはruns-on labelを変更することで採用するドロップインのGitHub Actions runner（例: nscloud-ubuntu-22.04-amd64-8x16 や namespace-profile-<name>）を提供し、buildを高速化するCache Volumesと幅広いtoolchainのcacheを備えています。Latchkeyも1行のruns-on入れ替えでマネージドrunnerを接続しますが、その焦点は自己修復CIです。一時的・機械的な失敗（メモリ不足によるkill、ディスクフルのエラー、registryのタイムアウト）が自動的に検出・修正・リトライされます。このページは、信頼性とコストを優先する場合の公平な比較と実践的な移行の道筋です。
NamespaceとLatchkeyをひと目で
| 機能 | Namespace | Latchkey |
|---|---|---|
| runs-on入れ替えによるドロップイン | あり（nscloud-* または namespace-profile-*） | あり（1行のruns-on入れ替え） |
| GitHubホストより安い | あり（Namespaceの料金による） | あり（1分あたり最大70%低い） |
| 組み込みcache | あり（Cache Volumes、幅広いtoolchainのcache） | あり（依存関係 + Dockerレイヤー） |
| macOS / arm64 runner | あり（Namespaceのドキュメントによる） | Latchkeyの最新ドキュメントを確認 |
| 自己修復CI（一時的な失敗の自動修正 + リトライ） | なし | あり |
| 得意分野 | 高速runner + 幅広いbuild/cacheプラットフォーム | 自己修復による信頼性 + 低コスト |
Namespaceが本当に得意なこと
Namespace自身のページによれば、Namespaceはworkflowを「2x-10x高速化」するドロップインrunnerを打ち出しており、Cache Volumes（局所性が保証された高スループットのNVMe cache）と、Bazel、Nix、Turbo、Gradle、Pants、sccacheといった人気のtoolchain向けの組み込みcacheに支えられています。ドキュメントには、Linux amd64/arm64、Windows、macOSのrunner形状も列挙されています。生のbuild加速と幅広いcache/buildプラットフォームが優先事項なら、それは本物の強みです。
Latchkeyが代わりに重視すること
Latchkeyは自己修復CIを中心に構築されています。そのマネージドrunnerでは、一時的・機械的な失敗が自動的に検出・診断・リトライされるため、不安定なbuildがpipelineを失敗させることがなくなり、手動の再実行にお金を払わずに済みます。それをAIによるbuild最適化、ゼロのキュー待ち時間、GitHubホストより最大70%低い1分あたりのコストと組み合わせています。差別化のポイントは信頼性とコストであり、生の最速runnerであるという主張ではありません。
移行手順（NamespaceからLatchkeyへ）
- 現在Namespaceのlabelを使っている箇所を棚卸しします。workflowでnscloud- または namespace-profile- で始まるruns-onの値を検索してください。
- LatchkeyをGitHub組織に接続し、使っていたNamespaceの形状に合うrunnerサイズ（例: 8 vCPU / 16 GBの形状）を選びます。
- 1つの重要でないworkflowのruns-on labelをLatchkeyのlabelに入れ替え、残りはNamespaceのままにします。
- Namespace Cache Volumesやnscloud-cache-actionに依存していた場合は、それらをLatchkeyの組み込みcacheに対応付けるか、変更不要なGitHub Actions Cacheを維持します。
- pipelineを数回実行し、実時間、1分あたりのコスト、不安定なステップの挙動を比較してから、段階的にロールアウトします。
Namespaceに残すべきもの
特定のworkflowがNamespace固有の機能（例: チューニングされたBazelやNixのCache Volume、macOS Apple-Siliconの形状、Devboxes）に依存している場合、移すためだけに移す必要はありません。どちらも標準のruns-on labelを使うので、両者を並行して動かし、自己修復とコストが最も重要なworkflowだけを移行できます。
結論
生の最速runnerに加えて幅広いcache/buildプラットフォームが欲しいなら、Namespaceは強力な選択肢であり、そうしたワークロードには維持する価値があります。本当の悩みが不安定な再実行と1分あたりのコストなら、Latchkeyは同じ1行のruns-on入れ替えで、GitHubホストより最大70%低いコストのマネージドrunnerに自己修復を追加します。Namespaceの最新の料金はnamespace.so/pricingで確認し、その後1つのworkflowでLatchkeyをパイロットして実際のbuildと比較してください。