よくある質問

自己修復は Latchkey runner の機能で、ジョブの実行中に失敗した CI/CD ビルドステップを自動的に検出、診断、修正します。これにより、人手を介さずにパイプラインを進め続けることができます。

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

すべての Latchkey runner です。warm-pool の runner と cold-start の runner の両方で、追加のセットアップなしに動作します。

はい。すべての Latchkey 組織では、すべての runner で自己修復がデフォルトで有効になっています。owner と admin は Settings > Self-Healing で組織全体に対して無効にできるほか、特定の runner だけ無効にしたい場合は runner ごとの設定で切り替えることもできます。

別途料金はかかりません。自己修復はワークフロー中にインラインで実行されるため、追加される実行時間は、そのステップが使用している runner の標準的な分単位の料金で請求されます。これは、その runner 上の他の CI 分と同じ料金です。

ステップが失敗すると、Latchkey は原因を診断し、適切な修正を数秒で適用します。単純な一時的障害はすぐに再試行され、より複雑な障害は、限定されたアクションの範囲内で動作する AI エージェントによって解決されます。いずれの場合も、人手を介さずにビルドは進み続けます。

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

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

はい。ダッシュボードの Recent Heals ビューには、判定結果、原因のカテゴリ、実行されたアクション、そして (AI エージェントによる修復の場合は) エージェントの完全なトランスクリプトとコストが表示されます。

Latchkey Runners は高性能で ephemeral な GitHub Actions runner であり、ワークフローの YAML を 1 行変更するだけで導入できます (例: runs-on: latchkey-medium)。4 つのプリセットサイズ (small、medium、large、extra large) が用意されており、AI Scan Runners はリポジトリに合わせて調整された runner を生成できます。各ジョブは新しく分離された環境で実行され、約 10 秒で cold-start します。GitHub ホストの runner は通常 30 から 60 秒かかり、warm runner は数秒でジョブを取得します。runner は既存の GitHub Actions ワークフローと完全に互換性があります。

導入は簡単です。ワークフローの YAML ファイルにある既存の runs-on の値 (例: runs-on: ubuntu-latest) を、お好みの Latchkey runner ラベル (latchkey-small、latchkey-medium、latchkey-large、latchkey-xlarge) に置き換えるだけです。他の変更は必要ありません。ワークフロー、action、step はこれまでとまったく同じように動作しますが、ジョブは Latchkey のより高速な専用インフラで実行されます。

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

Latchkey Runners は x86_64 上で Ubuntu 24.04 を実行します。Windows、macOS、arm64、GPU の runner は現在提供されておらず、移行ツールはこれらのジョブを意図的に現在の実行場所のまま残します。

はい。すべてのジョブは新しい ephemeral な runner インスタンスで実行され、ジョブの完了後に破棄されます。データ、アーティファクト、状態がジョブ間で保持されることはありません。これによりワークフロー実行間の強力な分離が実現し、永続的な self-hosted runner で発生しうるジョブ間の汚染や認証情報の漏洩のリスクが排除されます。

各 runner はちょうど 1 つのジョブを実行し、その後破棄されます。ジョブは最大 4 時間まで実行でき、組織はデフォルトで最大 20 件の同時ジョブを実行できます。チームがさらに高い同時実行数を必要とする場合は、サポートまでお問い合わせください。

runner の分数はサイズごとに請求されます。latchkey-small (2 vCPU / 8 GB) は 1 分あたり $0.0025、latchkey-medium (4 vCPU / 16 GB) は $0.005、latchkey-large (8 vCPU / 32 GB) は $0.01、latchkey-xlarge (16 vCPU / 64 GB) は $0.02 です。カスタム runner は xlarge の料金で請求されます。これは GitHub ホストの runner よりも 1 分あたり最大 70% 安価です。すべてのプランには毎月無料の runner 分数が含まれ (Developer は 2,000、Launch は 4,000、Scale は 6,000)、含まれる分数を超えた使用分は分単位の料金で請求されます。

はい。Latchkey には 2 つの組み込みキャッシュ action が付属しています。依存関係キャッシュ用の latchkey-dev/cache-action@v1 と、Docker レイヤー用の latchkey-dev/docker-cache-action@v1 です。ストレージと認証情報が事前にプロビジョニングされているため、どちらも Latchkey runner 上で設定なしに動作し、各 save や restore は runner と同じリージョンにあるストレージへの単一のストリーミングリクエストで行われます。

Latchkey Runners は、パフォーマンスとコストのデータを直接 Latchkey ダッシュボードに送ります。runner の起動レイテンシ、キュー待ち時間、ジョブの実行時間、分単位のコストをリアルタイムで可視化できます。Latchkey の AI 最適化エンジンは、ワークフローデータとともに runner の使用パターンを分析し、runner リソースの適正化やキャッシュの改善といった推奨事項を提示することで、CI/CD パイプライン全体の統合されたビューを提供します。

Latchkey の AI は GitHub Actions ワークフローを分析し、依存関係キャッシュの追加、runner の適正化、action のピン留めといった具体的な推奨事項を提示します。それぞれに信頼度スコアと、月あたりのドル単位および実行あたりの時間で見積もった削減効果が付きます。提案された各変更を YAML の diff としてレビューし、1 つずつ承認またはスキップでき、承認された変更は Latchkey が作成する 1 つの pull request として提供されます。

はい。Latchkey には MCP サーバーが付属しており、障害の完全なコンテキスト (根本原因、失敗したファイルそのもの、完全なログ) をコーディングエージェントに提供します。Settings > API Keys で読み取り専用の API key (lk_live_) を生成し、そのサーバーを Claude Code、Cursor、または MCP 対応の任意のエージェントに追加すると、障害バンドルを直接取得できます。key は読み取り専用のため、エージェントは障害コンテキストを読み取れますが、リポジトリやアカウント内のものを変更することは決してできません。

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

4 つのプランがあります。Developer は $5/month (リポジトリ 1 件、無料 runner 分数 2,000、seat 1)、Launch は $19/month (リポジトリ最大 10 件、無料分数 4,000、seat 1 含む、追加 seat は $5/month)、Scale は $49/month (リポジトリ最大 40 件、無料分数 6,000、seat 5 含む)、そして Enterprise はカスタム料金です。すべてのプランは 30 日間の無料トライアルから始まります。

Developer と Launch では不要です。プランを選ぶと、すべての機能にアクセスできる 30 日間の無料期間が得られ、カードは必要ありません。各ワークスペースにつきトライアルは 1 回です。

monitored repository とは、分析対象として Latchkey のオンボーディングやダッシュボードで明示的に選択した GitHub リポジトリを指します。GitHub アカウント内の休止中、アーカイブ済み、未選択のリポジトリに対して料金は発生しません。特定のリポジトリの監視のオン/オフを自由に切り替えて、プランの上限内に収めることができます。

いいえ。分析とモニタリングは、プランのリポジトリ上限内で無制限です。1 日に 10 回のビルドを実行しても 10,000 回実行しても、モニタリングの費用は同じです。従量課金の対象となるのは runner の分数だけで、すべてのプランには毎月無料分数が含まれ、それを超えた使用分は runner の分単位の料金で請求されます。

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

現在のプランで許可されている数より多くのリポジトリを監視する必要がある場合は、それらの追加リポジトリをダッシュボードに含めるために上位プランへアップグレードする必要があります。ダッシュボードの請求メニューからいつでもプランをアップグレードでき、監視する新しいリポジトリを追加することもできます。

無料分数は毎月の請求期間の開始時にリセットされます。使い切ると、追加の runner 分数は使用する runner サイズの分単位の料金で従量課金されます。カードなしのトライアル中の場合、支払い方法を追加するまで新しい runner ジョブはブロックされます。

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

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

いいえ。Latchkey は GitHub の organization アカウントのみに対応しています。GitHub App のインストールには、監視したいリポジトリを所有する GitHub organization が必要です。個人アカウントへのインストールは自動的に拒否され、削除されます。

いいえ。Latchkey の GitHub App は、ワークフローの実行、ジョブの結果、およびワークフローの YAML ファイルを読み取ります。ソースコード、secret、環境の値を読み取ることは決してなく、リポジトリに対して行える書き込みは、レビューしてマージする pull request のみです。

分析と最適化については、オンボーディングは 5 分未満で完了します。Latchkey の GitHub App をインストールし、監視するリポジトリを選択すれば完了です。YAML の編集は不要です。Latchkey Runners も使用したい場合、必要な変更はワークフローファイル内の runs-on を Latchkey runner ラベル (例: latchkey-medium) に更新するだけです。分析は完全に agentless で、runner はその 1 行の変更だけで済みます。

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

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

現在、Latchkey は GitHub Actions に高度に最適化されています。私たちはまず GitHub エコシステムに対して可能な限り深いインサイトを提供することに全力を注いでいます。他の CI/CD プロバイダーへの対応はロードマップに含まれています。