BuildJetからLatchkeyへ移行: GitHub Actionsランナー
BuildJet for GitHub Actionsが終了するため、BuildJetのworkflowは新しい居場所が必要です。BuildJetはドロップインランナーなので、移行はほとんどが1行のruns-on変更とキャッシュの判断です。
BuildJet上でGitHub Actionsを実行しているなら、計画が必要です。BuildJetの終了アナウンスによると、2026年2月6日をもって新規サインアップが停止され、BuildJetは2026年3月31日にjobの実行を停止し、ユーザーをGitHubホストのランナーに戻すよう案内しています。良いニュースは、BuildJetがruns-onラベルで到達するドロップインなマネージドランナーだったため、移行が低摩擦であることです。このページでは、何を変えるべきか、そしてホストより安価なランナーを維持し自己修復を追加したい場合にLatchkeyがどう適合するかを扱います。切り替えを計画する前に、BuildJetの現在の日付を同社のサイトで確認してください。
移行時に何が変わるか
| 関心事 | BuildJetでは | Latchkeyでは |
|---|---|---|
| runs-onラベル | 例: buildjet-4vcpu-ubuntu-2204 | 1行のruns-onラベル変更 |
| ランナーのサイズ | 2〜32 vCPUのティア（BuildJetによる） | マネージドサイズ、運用するインフラなし |
| GitHubホストより安価 | はい（BuildJet本来の売り） | はい（分単価が最大約70%低い） |
| キャッシュ | buildjet/cache action | 組み込みの依存 + Dockerレイヤー |
| 自己修復CI | なし | あり（一時的障害の自動リトライ） |
ステップ1: BuildJetのラベルを棚卸しする
workflowでruns-on: buildjet-を検索し、BuildJet上のすべてのjobを見つけます。BuildJetのドキュメントによればラベル形式はbuildjet-<vcpu>-<os>-<version>、例えばbuildjet-4vcpu-ubuntu-2204なので、.github/workflows全体をgrepすれば、ARMのバリアントを含めてすべてを捕捉できます。
grep -rn "runs-on:.*buildjet" .github/workflowsステップ2: 代替ランナーを選ぶ
BuildJet自身のガイダンスは、GitHubホストのランナー（ubuntu-latest、ARMならubuntu-24.04-arm）に戻すことです。それは機能しますが、BuildJetを選んだ理由であるホストより安価な価格を手放します。Latchkeyのようなマネージドランナーは、同じ1行の変更でその低コストを維持し、さらに自己修復を追加します。
ステップ3: キャッシュに対処する
buildjet/cacheを使っている場合、BuildJetの移行ガイダンスは標準のactions/cache@v4に移ることです。Latchkeyでは依存関係とDockerレイヤーのキャッシュが組み込まれているため、ほとんどのパイプラインは別のキャッシュactionをまったく必要としません。
同等の置き換えを超えてLatchkeyが追加するもの
Latchkeyは自己修復CIを中心に構築されています。メモリ不足によるkill、ディスクフルエラー、registryのタイムアウトが自動的に検出・リトライされるため、不安定なjobがパイプラインを失敗させなくなります。これを、GitHub Actionsより分単価が最大約70%低いマネージドランナーと、無駄な分を削るAIによるbuild最適化と組み合わせます。
結論
終了により、すべてのBuildJetのjobに移行先が必要です。GitHubホストへの単純な復帰で問題ないなら、BuildJetがその経路を文書化しています。より安価なランナーを維持し、不安定な障害から自動的に回復するパイプラインを追加したいなら、Latchkeyは検討に値します。1つのworkflowで試験導入し、切り替え前に比較できます。
よくある質問
BuildJetからの移行はどれくらい難しいですか？
runs-on変更とキャッシュの判断です。BuildJetとLatchkeyはどちらもマネージドランナーを標準のGitHub Actionsに接続するためです。ベンダーの日付は変わり得るため、BuildJetの現在の終了スケジュールを同社のサイトで確認してください。