よくある質問

Claude Code、Cursor、Codex、そしてその他の任意の MCP クライアントです。それぞれ、ダッシュボードの Settings > API keys and agents で発行した Latchkey API キー 1 つで接続します。エージェントは npm install -g @latchkeydev/cli の後、シェルから CLI を呼び出すこともできます。latchkey run はローカルの作業ツリーを使って新しい Linux VM 上でコマンドを実行し、ログをライブで表示して実際の終了コードを返します。

はい。自己修復で修正できなかった失敗は、Latchkey がエージェント向けの failure bundle にまとめます。根本原因、失敗したファイル、取得したログが含まれ、シークレットは除去されます。Settings > API keys and agents で API キー (lk_live_) を発行し、Claude Code、Cursor、または任意の MCP クライアントに MCP サーバーを追加すると、エージェントは failure bundle の取得、実行ステータスの確認、完了したジョブのログの読み取りができます。キーはデフォルトで読み取り専用のため、エージェントはそのコンテキストを読めても、コードやアカウントを変更することはできません。操作はキーごとのオプトインです。Dispatch のアクセスを選ぶと GitHub Actions のワークフローを開始でき、CLI runner のアクセスを選ぶと新しい VM 上でコマンドを実行できます。料金は他のジョブと同じく分単位です。

17 個のツールです。list_failed_runs、get_failure_bundle、get_run_status、tail_run_logs で、エージェントは CI の失敗を見つけて読み取れます。dispatch_workflow は GitHub Actions のワークフローを開始します。run_job、list_jobs、get_job_status、get_job_logs、cancel_job で、新しい VM 上でコマンドを実行し、その進行を追い、結果を読み取り、またはキャンセルできます。set_batch_budget は、ジョブのバッチの予算を設定または引き下げ、get_batch は 1 つのバッチの予算、支出、ジョブを読み取ります。plan_migration、apply_migration、get_migration で、リポジトリの Latchkey CI への移行を計画し、アドバイザリーモードのリポジトリにはそのワークフローファイルを追加するプルリクエストを開き、その状況を確認できます。list_latchkey_steps は、ワークフローファイルで指定できる Latchkey のステップを、各バージョンの入力とそのルールとともに一覧表示します。list_environments は、リポジトリの各環境が受け付けるブランチを読み取ります。dispatch_workflow、7 つのジョブツール、list_environments、apply_migration は、それらの権限を付けて発行したキーでのみ動作します。

自己修復が診断したものの修正できなかった CI の失敗をポーリングし、新しい失敗をそれぞれコーディングエージェントに引き渡します。デフォルトは Claude Code で、任意のエージェントコマンドを指定することもできます。watch の開始時点ですでに発生していた失敗は引き渡されず、新しい失敗はそれぞれ 1 回だけ引き渡されます。すべてのキーが持つ mcp:read スコープで読み取るため、どの API キーでも実行できます。

実行したサイズの分単価で、分単位で課金されます。無料分数は Latchkey CI や Latchkey on GH のジョブと共通です。CLI と MCP サーバーはすべてのプランに含まれ、追加料金はありません。利用には有効なサブスクリプションまたはトライアルが必要です。バッチ予算を使うとエージェントのジョブのグループが使える金額に上限を設けられ、API キーはその予算を引き下げることはできても、引き上げることはできません。

キーは Settings > API keys and agents で作成し、それぞれ発行時に選んだスコープだけを持ちます。すべてのキーは mcp:read を持ち、エージェントは失敗を読み取れます。ジョブの実行には jobs:run、ジョブのステータスとログの読み取りには jobs:read が必要で、ワークフローのディスパッチは別途オプトインです。既存のキーにスコープを追加することはできず、どのキーも失効させられます。Latchkey が保存するのは各キーのハッシュだけです。各ジョブは専用の VM 上で実行され、ジョブの終了時に破棄されます。

自己修復は、失敗した CI ステップを直す Latchkey の修復ループです。ステップが一時的な理由で失敗すると、Latchkey はジョブの実行中にそれを検出し、原因を診断してマシン上で修復し、ジョブは人手を介さずに続行します。Latchkey CI でも Latchkey on GH でも同じように動作します。

一時的な障害や環境起因の障害: ネットワークの問題 (レジストリのタイムアウトや npm、Yarn、PyPI、Docker、Terraform からの 5XX)、メモリエラー (OOM kill、SIGKILL)、ディスク満杯エラー (ENOSPC)、ツールの不足 (command-not-found、検証済みの allowlist からインストール)、環境や設定のドリフト (変数の欠落、toolchain のバージョン不一致、ファイルハンドル制限) などです。テストの失敗やコンパイルエラーのようなコード内の本当のバグは、明示的に修復されず、元のログとともに失敗します。

すべての Latchkey CI ジョブとすべての Latchkey on GH ジョブで、すべてのサイズで、セットアップなしに動作します。フォークからのプルリクエストでは自己修復は動作しません。Latchkey CI では、advisory: skip と書いたステップ、公開できて advisory: を書いていないステップ、そして advisory: hold と書いたジョブ、または環境を指定して advisory: を書いていないジョブのすべてのステップでも動作しません。そのようなステップをもう一度実行すると、そのステップが行ったことが繰り返されるためです。

はい、新しいワークスペースではデフォルトで有効です。owner と admin は Settings > Self-healing でワークスペース全体に対して無効にできます。

別途料金はかかりません。自己修復はジョブの中で実行されるため、追加された時間はジョブの他の部分と同じ分単価で課金されます。

段階的に動作します。まず、失敗したステップの終了コードとログを既知の失敗パターンと照合し、単純なケースはその場で再試行または修復します。それで対応できないものは AI エージェントに渡されます。このエージェントが取れるのは、システムパッケージのインストール、ディスクの解放、環境変数の設定、バックオフ付きの再試行など、決められた範囲のアクションだけで、時間制限もあります。失敗したステップの再実行はデフォルトで最大 3 回です。

エージェントは、障害について推論できるように、stderr、stdout、exit code、および厳選されたマニフェストファイル一式 (例: package.json、requirements.txt) を受け取ります。ソースコードは送信されません。エージェントのアクションは検証済みの allowlist に限定されており、任意のコマンドを実行したりコードを変更したりすることはできません。

はい、修復用の pull request を通じて可能です。修復の成功が、ワークフローに不足しているセットアップステップやジョブのタイムアウトが低すぎるといった構造的な原因にさかのぼれる場合、Latchkey は恒久的な修正を含む pull request を作成し、レビューしてマージできるようにします。恒久的な変更は必ずレビュー可能な PR として届き、自己修復が実行中にコードを変更することは決してありません。

はい。実行ページでは修復された各ステップに Healed の印が付き、ジョブの Open the heal から修復の完全なレポートを開けます。判定結果、何が問題だったか、実行されたアクション、そして AI エージェントによる修復の場合はエージェントの完全なトランスクリプトが表示されます。

コーディングエージェントのために作られた、スタンドアロンの CI/CD プラットフォームです。ワークフローファイルをコミットすると、Latchkey がそれをキューに入れ、各ジョブを新しい Linux VM で実行し、一時的な失敗を実行中に修復し、ログと実行ページを保持して、結果をチェックとしてプルリクエストに返します。コーディングエージェントは CLI と MCP サーバーから同じ CI を操作できます。GitHub Actions のワークフローをそのまま使いたいチームは、GitHub Actions 向けのマネージドランナーである Latchkey on GH を利用できます。

サインアップし、アカウントまたは組織に Latchkey GitHub App をインストールして、ダッシュボードでリポジトリを有効にします。次に .latchkey/workflows/ci.yml のようなワークフローファイルをコミットしてプッシュします。Latchkey はプッシュとプルリクエストのたびにそれを実行し、結果を GitHub のチェックとして返します。Latchkey は実行の結果を、Latchkey / plan はワークフローファイルをコンパイルできたかどうかを示します。各チェックからは、ライブログ付きの実行ページを開けます。

すでにご存じの GitHub Actions のワークフローの形式を使い、各ステップは run: か Latchkey のステップ (uses: latchkey/<name>@<version>) で書きます。jobs、needs、include と exclude を含む matrix、services、env、secrets、environment、if、timeout-minutes に対応し、push、pull_request、スケジュールで実行されます。各ジョブは runs-on: にサイズ (small、medium、large、xlarge) を指定します。チェックアウトは自動で、Node、Python、Go、Rust、Java はイメージに含まれています。environment を指定したジョブは、承認不要に設定された環境でない限り、owner または admin が実行を承認するまで待機します。Latchkey が対応していないキーは、その名前と行番号を示して拒否されます。

GitHub のアクションを uses: で呼び出すステップです。Latchkey が実行するのは uses: latchkey/<name>@<version> と書いた自身のステップだけなので、それ以外のステップは run: で書いてください。Latchkey は Marketplace のアクション、コンポジットアクション、再利用可能なワークフローを実行しません。手動実行のトリガー、Git LFS、コンテナ、permissions もまだ対応していません。また、Latchkey は実行中のジョブを途中で止めないため、concurrency: に cancel-in-progress: true は書けません。キャッシュには latchkey/cache-restore と latchkey/cache-save のステップを使うか、ステップで CLI をインストール (npm install -g @latchkeydev/cli) してから latchkey cache restore と latchkey cache save を実行します。これらが必要なワークフローは、Latchkey on GH を使って GitHub Actions のまま実行できます。

Latchkey ダッシュボードの実行ページで確認できます。すべての GitHub チェックからこのページにリンクしています。各ジョブの needs とスキップ、matrix の各組み合わせ、services、修復されたステップに加え、ジョブの実行中にライブで更新される検索可能なステップごとのログが表示されます。失敗したものだけを GitHub の Re-run ボタンまたはダッシュボードから再実行でき、成功したジョブは、再実行されるジョブに依存していない限り、再実行も再課金もされません。ジョブのログは 7 日間保持され、エージェントは latchkey logs または MCP サーバーで同じログを読み取れます。

Latchkey CI では、コードではなく Latchkey が実行を止めた場合、Latchkey チェックは neutral で終了し、その理由を示します。こちら側のエラーで止まった場合は、見落とされないよう Latchkey / plan チェックが赤になります。GitHub またはダッシュボードから再実行できます。

Latchkey on GH は GitHub Actions 向けのマネージドランナーで、.github/workflows のファイルはそのまま使えます。runs-on: latchkey-small (または latchkey-medium、latchkey-large、latchkey-xlarge) を指定すると、同じ自己修復 VM が GitHub Actions のジョブをアクションも含めて実行します。GitHub の組織が必要です。すべてのプランで、これらのジョブ向けに稼働中の latchkey-small ランナー 1 台と待機中のランナー 3 台が用意され、より大きいサイズは必要に応じて起動します。AI Scan を使うと、リポジトリ専用のカスタムランナーを作成することもできます。

Latchkey CI の場合は、ダッシュボードの Migrate にある Move CI to Latchkey が、パイプラインごとに計画を立て、シークレットを転送し、ファイルを追加するプルリクエストを開いたうえで、切り替えるまで両方を並べて実行します。エージェントも plan_migration ツールで同じ移行を計画できます。このツールはパイプラインごとに .latchkey/workflows のファイルを提案し、人の判断が必要な箇所に印を付けます。apply_migration でファイルを追加するプルリクエストを開くには、リポジトリがアドバイザリーモードである必要があります。手作業の場合は、ジョブを .latchkey/workflows/<name>.yml にコピーし、runs-on: に small などのサイズを指定して、uses: のステップをそれぞれ run: か Latchkey のステップ (uses: latchkey/<name>@<version>) で書き直します。Latchkey は未対応のキーを 1 つずつ名前と行番号で示して拒否するため、順番に修正できます。Latchkey on GH の場合は、ワークフローはそのままで runs-on: ubuntu-latest を runs-on: latchkey-small に置き換えます。

Latchkey on GH では可能です。Runners ページの Migrate Runners ツールは、リポジトリごとにレビュー可能な pull request を 1 件作成し、一度に最大 20 リポジトリまで対応します。変更されるのは runs-on の行だけで、各ファイルの他のすべての行はバイト単位で同一のまま保たれ、Windows と macOS のジョブはそのまま残されます。チームがマージするまで何も変わりません。多数のリポジトリを Latchkey CI のワークフローファイルに移す作業は、まだ自動化されていません。

はい。ワークフローが GitHub Actions で動いている場合、最も手早いのは Latchkey on GH です。runs-on: の行を Latchkey のラベルに向け、ワークフローの残りはそのままにします。依存関係のキャッシュ、Docker レイヤーのキャッシュ、自分で管理していたマシンに依存していたステップには個別の変更が必要な場合があり、以下の移行ガイドでプロバイダーごとに説明しています。パイプライン自体を Latchkey に実行させるには、同じジョブを Latchkey CI のワークフローファイルとしてコミットします。

AWS の us-east-1 にある x86_64 の Ubuntu 24.04 で、small (2 vCPU、8 GB)、medium (4 vCPU、16 GB)、large (8 vCPU、32 GB)、xlarge (16 vCPU、64 GB) の 4 サイズがあり、一般的な toolchain がプリインストールされています。各ジョブには専用の VM が割り当てられ、ジョブの終了時に破棄されます。Windows、macOS、arm64、GPU のマシンは提供しておらず、Migrate Runners は Windows と macOS のジョブを現在の場所に残します。

はい。各ジョブは受信アクセスのないプライベートネットワーク内の専用の新しい VM で実行され、VM とそのディスクはジョブの終了時に破棄されます。そのため、永続的なセルフホストランナーのように、あるジョブから次のジョブへ何かが引き継がれることはありません。Latchkey CI では、VM はそのリポジトリだけに限定された短期間有効なトークンでリポジトリをクローンし、GitHub には何も登録しません。

各ジョブは専用の VM で実行されます。Latchkey CI のジョブは timeout-minutes を最大 180 (デフォルトは 30) まで設定でき、CLI のジョブは最大 3 時間、Latchkey on GH のジョブは最大 4 時間 (4 時間の時点でまだ実行中なら最大 8 時間) 実行できます。ワークスペースが同時に実行できるジョブ数はプランごとに決まります (Developer は 20、Launch は 40、Scale は 80。トライアル中は Launch の数値が適用され、上限を超えたジョブはキューで待機します)。Enterprise の上限は契約で定められます。チームがさらに高い同時実行数を必要とする場合は、サポートまでお問い合わせください。

ジョブはサイズごとに分単位で課金され、ジョブごとに切り上げられます。アイドル料金はなく、Latchkey CI、Latchkey on GH、エージェントのジョブで共通です。small (2 vCPU / 8 GB) は 1 分あたり $0.0025、medium (4 vCPU / 16 GB) は $0.005、large (8 vCPU / 32 GB) は $0.01、xlarge (16 vCPU / 64 GB) は $0.02 です。カスタムランナーは xlarge の料金で課金されます。GitHub の定価と比べると、GitHub ホストランナーより 1 分あたり 52 から 58% 安くなります。すべてのプランには毎月の無料分数が含まれ (Developer は 2,000、Launch は 4,000、Scale は 6,000)、含まれる分数を超えた使用分は分単位の料金で課金されます。無料ランナー時間は small 換算の単位で計算されます。latchkey-small の 1 分は 1、medium は 2、large は 4、xlarge とカスタムランナーは 8 として数えられ、各プランに含まれる無料枠の量は変わりません。

はい。Latchkey CI では、latchkey/cache-restore と latchkey/cache-save のステップを追加するか、ステップで CLI をインストール (npm install -g @latchkeydev/cli) してから latchkey cache restore と latchkey cache save を実行します。キャッシュはリポジトリとブランチごとに分けられ、他のブランチはデフォルトブランチのキャッシュを読み取れます。キャッシュミスやキャッシュプロキシのエラーによってジョブが失敗することはありません。Latchkey on GH では、依存関係のキャッシュに latchkey-dev/cache-action@v1、Docker レイヤーに latchkey-dev/docker-cache-action@v1 を使います。ストレージと認証情報は事前に用意され、ランナーと同じリージョンにあります。依存関係のキャッシュは 14 日間保持されます。Docker レイヤーのキャッシュは現在のキャッシュイメージを保持し、置き換えられたレイヤーは push から 7 日後に削除されます。

Insight は Latchkey が実行するジョブを分析し、サイズが大きすぎるランナー、失敗したジョブに費やされた分数、不安定なジョブ、バージョンが固定されていないアクションなど、コスト、信頼性、セキュリティの改善点を見つけます。各検出結果には、実際の実行から算出した金額または時間が示され、短い説明は AI モデルが書きます。修正がある検出結果を承認すると、その変更がプルリクエストとして作成されます。

いいえ。Latchkey が行うリポジトリへのすべての変更は、最適化インサイト、heal による修正、runner の移行のいずれであっても、レビューしてマージする pull request として届きます。あなたの承認なしにリポジトリに反映されるものは何もありません。

4 つのプランがあります。Developer は月額 $5 (リポジトリ 1 件、無料分数 2,000 (small 換算)、seat 1)、Launch は月額 $19 (リポジトリ最大 10 件、無料分数 4,000 (small 換算)、seat 3 を含み、追加 seat は月額 $5)、Scale は月額 $49 (リポジトリ最大 40 件、無料分数 6,000 (small 換算)、seat 5 を含む)、そして Enterprise はカスタム料金です。新しいワークスペースはすべて Launch プランで始まり、各ユーザーの最初のワークスペースではその 30 日間トライアルが付きます。

いいえ。新しいワークスペースは、すべての機能を使える Launch プランの 30 日間トライアルから始まり、カードは不要です。無料トライアルはおひとりにつき 1 回、最初のワークスペースで利用できます。

ダッシュボードで有効にした各リポジトリが、プランのリポジトリ枠を 1 つ使います (Developer は 1、Launch は 10、Scale は 40)。Latchkey CI と Latchkey on GH は同じ枠を共有します。有効にしていないリポジトリは数えられず、無効にすると枠が空きます。

いいえ。実行、ワークフロー、チェックごとの料金はありません。従量課金されるのは分数だけです。すべてのプランに毎月の無料分数が含まれ、それを超えた利用は使用したサイズの分単価で課金されます。

各プランには seat が含まれます。Developer はチームメンバーなしの単一 seat、Launch は seat 3、Scale は seat 5 を含みます。Launch と Scale では 1 seat あたり $5/month で seat を追加でき、エンジニアリングチーム全体がダッシュボードとインサイトにアクセスできます。

プランの上限を超えてリポジトリを有効にするには、ダッシュボードの請求ページから上位のプランにアップグレードし、新しいリポジトリを有効にします。アップグレードはいつでも可能です。

無料分数は各暦月の初日にリセットされ、small 換算の単位で計算されるため、大きいランナーでの 1 分は latchkey-small での 1 分より多くの無料枠を消費します。使い切ると、追加の runner 分数は使用する runner サイズの分単位の料金で従量課金されます。カードなしのトライアル中の場合、支払い方法を追加するまで新しい runner ジョブはブロックされます。

支払い方法が登録されている場合、サブスクリプションは選択したプランに自動的に切り替わり、請求は Stripe を通じて安全に処理されます。カードなしで開始した場合、Latchkey がサブスクリプションを促します。ダッシュボードから任意のプランを選び、中断したところから続けられます。いずれの場合もデータは保持されます。

リポジトリを無効化すると、そのデータは削除されるのではなくアーカイブされます。サブスクリプションを解約してもデータは保持されるため、再開した際に中断したところから続けられます。また、いつでも全データの削除を請求できます。

パブリックリポジトリでは無料です。標準の GitHub ホスト型ランナーは分数制限なしで無料で、セルフホスト型ランナーはどのリポジトリでも無料です。プライベートリポジトリには月間の無料枠があり、超過分は従量課金になるため、「無料かどうか」はコードが公開されているかで決まります。Latchkey はどのリポジトリでも分単位の課金で、プランに応じて月 2,000 から 6,000 分 (small 換算) が無料です。

GitHub が公表しているプライベートリポジトリ向けの月間無料枠は、Free で 2,000 分、Pro と Team で 3,000 分、Enterprise Cloud で 50,000 分です。あわせてプランに応じて 500 MB 〜 50 GB のアーティファクトストレージと、全プラン共通でリポジトリあたり 10 GB の Actions キャッシュが含まれます。パブリックリポジトリは計測対象外です。数値は GitHub の課金ドキュメントに基づきます。

GitHub が公表している標準的な Linux 2 コア x64 ランナーの定価は 1 分あたり $0.006 で、プランの無料枠を使い切ったプライベートリポジトリにのみ課金されます。より大きなランナーや他の OS はさらに高くなります。Latchkey の small のジョブは、同等の 2 vCPU / 8 GB の Linux VM で 1 分あたり $0.0025 です。

GitHub はセルフホスト型ランナーに課金しないため、分単位の請求はなくなり、コストはクラウド料金とエンジニアの工数に移ります。ジョブ間のアイドルインスタンス、AMI のパッチ適用、オートスケーラーの調整、そしてソースコードを取得するマシンのセキュリティレビューです。インスタンス時間だけでなくエンジニアの工数も見積もってください。マネージド CI プラットフォームが比較されるのはその合計であり、GitHub の請求書上のゼロではありません。

はい。プランの無料枠を使い切ると、GitHub は設定した支出上限の範囲で、公表されている分単価に基づき追加分を課金します。ビルドが止まるのではなく、請求が使用量に応じて増えていきます。別の方法として、それらのジョブを 1 分 $0.0025 からの Latchkey で実行することもできます。Latchkey CI のワークフローファイルとしてコミットするか、Latchkey on GH でワークフローはそのままに runs-on: の行を変更します。

はい、Latchkey CI で利用できます。個人アカウントを接続し、ダッシュボードでリポジトリを選択して、ワークフローファイルを .latchkey/workflows/ の下にコミットしてプッシュしてください。Latchkey on GH (GitHub Actions で動く Latchkey のマネージドランナー) には、リポジトリを所有する GitHub organization が必要です。

コードは実行のために Latchkey を通過し、その一部は一定期間保持されます。Latchkey CI では、各ジョブが専用の VM にリポジトリをクローンし、その VM はジョブの終了時に破棄されます。latchkey run は作業ツリーをジョブのコンテキストとしてアップロードし、ジョブの終了時に削除します。その削除に失敗した場合は、2 日での失効により削除されます。ジョブが保存したキャッシュエントリは 14 日間、ジョブが latchkey artifact でアップロードしたアーティファクトはアップロードから 7 日間保持されます。ジョブのログは 7 日間保持されます。自己修復が失敗したステップについて修復の記録を残した場合、その記録はそのステップの出力と、ファイルのうち自己修復が読み取った部分を 90 日間保持します。提案された修正のファイル内容は 365 日間保持されます。GitHub App がリポジトリに書き込むのは、レビューしてマージするプルリクエストだけです。

Latchkey CI では、フォークからのプルリクエストは、作成者がすでに書き込み権限を持っている場合を除き、メンテナーがチェックまたは実行ページからそのコミットを承認するまで待機します。承認後は、GitHub と主要なパッケージレジストリにしか接続できないサンドボックスで、シークレット、トークン、キャッシュ、自己修復なしで実行されます。ワークフローファイルはフォークではなくあなたのリポジトリから読み込まれ、プライベートリポジトリのフォークは実行されません。Latchkey on GH では、フォークからのプルリクエストは GitHub 自体のルールに従います。

Latchkey CI では、ダッシュボードの Settings > Secrets で、ワークスペース全体、1 つのリポジトリ、またはリポジトリの 1 つの環境にシークレットを追加します。環境の値はリポジトリの値より、リポジトリの値はワークスペースの値より優先されます。シークレットはワークスペースごとの鍵で暗号化され、ログではマスクされます。ステップでは env: の中で ${{ secrets.NAME }} として読み取ります。環境のシークレットをジョブが読み取れるのは、その実行がその環境について承認された後か、承認不要の環境ではそのブランチ上の実行だけです。フォークからのプルリクエストには渡されません。Latchkey on GH では、GitHub Actions のシークレットがこれまでどおり使えます。

はい、Latchkey は GitHub.com 上のパブリックリポジトリとプライベートリポジトリの両方に対応しています。ただし、オンプレミスの GitHub Enterprise Server インスタンスは現在サポートされていません。

Latchkey ダッシュボードは現時点ではデスクトップ専用です。Slack とブラウザのプッシュ通知により、席を離れていても情報を受け取れますが、ダッシュボード自体はデスクトップブラウザ向けに作られています。

まだ対応していません。Latchkey はパイプラインを自ら実行し、最初に連携するコードホストが GitHub です。コードとプルリクエストはそのままの場所に置いたまま、Latchkey が結果を返します。他のコードホストへの対応はロードマップにあります。