BlacksmithからLatchkeyへの移行方法 (2026ガイド)
BlacksmithとLatchkeyはどちらも高速でドロップイン、より安価なGitHub Actions runnerです。チームが移行を検討する理由は通常、信頼性です: Latchkeyは自己修復を追加し、一時的な失敗が再実行になる代わりに自動的に回復します。
Blacksmithは強力な製品です。Blacksmithによると、GitHubホストrunnerの2倍高速なドロップイン置き換えです: runs-onタグを変更することで採用し、jobは3秒未満で起動するエフェメラルなFirecracker microVMで実行され、実行間でDockerレイヤーcacheを永続化します。CIがCPUバウンドなら、Blacksmithは本当に良い選択です。チームがLatchkeyを検討するのは、本当の痛みが生の速度ではなく、不安定で一時的な失敗とコストである場合です。Latchkeyもruns-on一行の入れ替えで、自己修復CIを追加し、メモリ不足によるkill、registryのタイムアウト、その他の一時的/機械的な失敗が自動的に検出・再試行されるようにし、GitHub Actionsより最大70%低い分単位コストで実行します。どちらも標準的なマネージドrunnerなので、両者間の移動は移行プロジェクトではなくラベルの変更です。
Blacksmith vs Latchkey 一目でわかる比較
| 機能 | Blacksmith | Latchkey |
|---|---|---|
| 採用 | runs-onタグを変更 | runs-onタグを変更 |
| GitHubホストより安価 | はい (Blacksmithは分単位約50%低いと述べる) | はい (分単位最大70%低い) |
| 分離 / boot | エフェメラルなFirecracker microVM、boot < 3s | マネージド、jobごとに分離 |
| 実行間のDockerレイヤーcache | はい (co-located cache、Blacksmithによる) | 組み込みcaching (deps + Dockerレイヤー) |
| 生のシングルコアCPU速度 | 本物の強み (Blacksmithによると、GitHubホストより50%+高いシングルコア) | 高速なマネージドrunner |
| 自己修復CI (一時的な失敗の自動再試行) | いいえ | はい |
| AI駆動のbuild最適化 | いいえ | はい |
| 最も知られている点 | 生の速度 + Dockerレイヤーcache | 自己修復による信頼性 + 低コスト |
Blacksmithとは何か、何が得意か
Blacksmithによると、GitHub Actionsを実行する最速の方法です: そのドキュメントが約2倍高速と記述する、GitHubホストrunnerのドロップイン置き換えです。RunnerはGitHubと同じイメージから同じプリインストール依存関係で起動するため、ほとんどのworkflowは変更なしで実行されます。文書化された強みは本物です: GitHubホストrunnerより50%+高いシングルコア性能のCPU、3秒未満で起動するエフェメラルなFirecracker microVM、そして約400 MB/sのco-located cacheスループットで永続化されるDockerレイヤーcache。buildがシングルスレッドのコンパイルや重いDocker buildに支配されているなら、その組み合わせは打ち負かすのが難しいです。
一部のチームがLatchkeyに移行する理由
速度は不安定さを直しません。パイプラインが依然として一時的な失敗 - メモリ不足によるkill、ディスクフルエラー、registryやネットワークのタイムアウト - で赤くなるなら、より高速なrunnerはより速く失敗するだけで、あなたは再実行のために支払います。Latchkeyは自己修復CIを中心に構築されています: それらの一時的および機械的な失敗を自動的に検出、診断、修正し、jobを再試行するため、不安定なbuildがパイプラインを失敗させなくなります。それを、GitHub Actionsより最大70%低い分単位コストとAI駆動のbuild最適化と組み合わせます。これはBlacksmithとは異なる軸です: 生のコアあたりの速度ではなく、信頼性とコストです。
ステップバイステップの移行
- すべてを一度に切り替えるのではなく、ノイズの多いまたは高価な1つのworkflowを選んで試しましょう。
- そのworkflowで、runs-onラベルをBlacksmith runnerタグからLatchkey runnerラベルに変更します。これはBlacksmithを採用したときに行ったのと同じ一行の変更です。
- jobが拾われるように、Latchkey GitHub Appをインストールしてrepoまたはorgへのアクセスを付与します (任意のマネージドrunnerと同じアクセスモデル)。
- パイプラインを実行し、Blacksmithのベースラインと比較します: 分単位コスト、実時間、そして一時的な失敗が手動の再実行を必要とする代わりにどれくらいの頻度で自己修復するか。
- runs-onの入れ替えを繰り返してより多くのworkflowに展開します。YAMLの他は何も変わらないため、runs-onをBlacksmithに戻すことで即座に元に戻せます。
Blacksmithに留まるべき場合
ボトルネックについて自分に正直になりましょう。CIが本当にCPUバウンドでDockerレイヤーcache中心であり、信頼性がすでに問題ないなら、Blacksmithはすでにその仕事に最適なツールかもしれず、切り替える理由はありません。Latchkeyは、不安定な失敗による再実行と分単位コストが実際に痛い場合により強い選択肢です。
結論
Blacksmithは高速でよく作られたドロップインrunnerであり、CPUバウンドでDocker中心のパイプラインには正しい選択です。あなたの痛みが生の速度ではなく不安定な再実行とコストなら、Latchkeyもruns-on一行の入れ替えです - 1つのworkflowで自己修復マネージドrunnerを試し、Blacksmithをフォールバックとして維持し、展開前に実際のbuildと比較しましょう。