AI エージェントを接続する (MCP)

Claude Code、Cursor、または MCP 対応の任意のエージェントに、CI の失敗への安全な読み取り専用アクセスを与え、エディタからトリアージと修正を行えるようにします。

API Keys 設定タブ — Settings, API Keys: キーを作成し、すぐに使える接続コマンドをコピーします。

Latchkey は MCP サーバー を提供します。AI コーディングエージェントは Latchkey の API キーで接続し、実際の CI 失敗コンテキスト (失敗した実行、ログ、診断バンドル) をエディタセッションに直接取り込めます。ログをチャットにコピー＆ペーストする代わりに、エージェントが Latchkey に直接問い合わせ、失敗を修正するために必要なものをすべて取得します。

これは自己修復の引き継ぎ側です。自己修復は実行中に環境の失敗を修正し、ソースには一切触れません。そのため、本当の問題がコードのバグである場合、ビルドは正直に失敗し、その失敗はエージェント向けのすぐ修正できるバンドルとしてここに届きます。

接続したエージェントができること#

toolCI 失敗のトリアージ監視対象リポジトリ全体で何が失敗しているかを調べ、優先順位を付けます。

tool失敗した実行の一覧最近の失敗したワークフロー実行を、主要なメタデータとともに列挙します。

tool失敗バンドルの取得1 つの失敗の完全なコンテキスト (ログ、診断、ワークフローの詳細) を取得します。

toolCI 失敗の修正特定の失敗について、エディタ内からガイド付きの修正を実行します。

これらのツールを名前で呼び出すことはありません。エージェントに平易な言葉で質問すると、エージェントがどの Latchkey ツールで答えるかを判断します。いくつかの対応例:

エージェントへの質問	エージェントが使うツール
「今、私たちのリポジトリ全体で何が失敗している?」	CI 失敗のトリアージ
「このリポジトリの最近の失敗した実行を見せて」	失敗した実行の一覧
「あの失敗した実行について持っている情報をすべて取得して」	失敗バンドルの取得
「失敗しているビルドを修正して」	CI 失敗の修正

セッションの様子#

2 つの例示的なセッションです。正確な言い回しやエージェントの実際の返答はエージェントによって異なります。重要なのはやり取りの形です。

エディタを開いて「私たちのリポジトリで何が失敗している?」と尋ねます。エージェントはトリアージツールを呼び出し、監視対象リポジトリ全体の失敗を優先順位付きで調べて返します。さらに「リリースにとって最も重要なのはどれ?」と絞り込むと、CI のタブを一度も開かずに、エージェントが同じデータをもとに推論します。

価値は、ループが 1 か所に留まることです。質問、コンテキスト、次の質問。そのすべてが、修正を行うことになるエディタセッションの中で完結します。

「最新の赤いビルドの失敗バンドルを取得して修正して」と尋ねます。エージェントは最近の失敗した実行を一覧して該当するものを見つけ、その完全なバンドル (ログ、診断、ワークフローの詳細) を取得し、エディタ内からガイド付きの修正を実行して、レビュー用の変更を提案します。

起きなかったことに注目してください。エージェントはそのキーを通じて Latchkey の設定にも GitHub にも一切触れていません。読み取ったのは失敗コンテキストだけで、コードの変更はあなたを経由しました。

失敗バンドルに含まれるもの#

失敗バンドルは、エージェントが本来手作業で再構築するものを渡します:

根本原因 を平易な言葉で。
失敗したステップの 終了コード と、エラーが表面化した正確なソースファイル。
失敗したステップの 完全な、省略されていないログ。GitHub がログビューアで隠す出力も含みます。ログが Latchkey を離れる前にシークレットは除去されます。
自己修復がすでに調査した内容 と、なぜ引き下がったか、加えてワークフロー定義。

セットアップ#

API キーを作成する

Settings, API Keys を開きます (キーの管理はオーナーと管理者が行います)。Create key をクリックし、設置場所にちなんだ名前を付け (例: 「私のノート PC の Cursor」)、有効期限を選びます: 30、60、90 日、1 年、または無期限。

キーをすぐにコピーする

完全なキー (lk_live_ で始まります) は作成時に 一度だけ 表示されます。その後、UI にはプレースホルダーしか表示されません。パスワードのように扱ってください。紛失した場合は取り消して新しいものを作成します。

エージェントを接続する

同じ設定タブの Connect an agent カードに、あなたのワークスペース向けの正確なコマンドが表示されます。Claude Code の場合は次のようになります:

terminal

$ claude mcp add --transport http latchkey \
    https://latchkey.dev/mcp \
    --header "Authorization: Bearer lk_live_YOUR_KEY"

使ってみる

失敗している CI についてエージェントに尋ねます (「私たちのリポジトリで何が失敗している?」「最新の赤いビルドの失敗バンドルを取得して修正して」)。ベアラーヘッダー付きの HTTP トランスポートに対応する MCP 互換クライアントであれば、どれも同じように動作します。

セキュリティモデル#

読み取り専用スコープ。 キーは CI の失敗データを読み取れますが、Latchkey や GitHub の何も変更できません。
ワークスペーススコープ。 ワークスペースはキー自体から導出されるため、キーは自分のワークスペースのデータしか見られません。
取り消し可能。 Settings, API Keys から任意のキーを即座に取り消せます。取り消したキーは監査用に一覧されます。

これら 3 つの性質が実際に何を意味するか。読み取り専用は漏洩時の影響範囲を限定します。盗まれたキーは CI の失敗データ (ログの抜粋を含む) を露出させるため、依然として保護すべきですが、PR を開いたり、設定を変更したり、あなたに代わって GitHub 上で操作したりはできません。ワークスペーススコープは、設定すべきものも間違えるものも何もないことを意味します。キー自体が見られる範囲を決め、他のワークスペースを見ることは決してできません。そして取り消しは即座で、取り消したキーは監査用に一覧され続けるため、少しでも疑わしければ取り消して再発行するのが安全な対応です。

これをきれいに保つ、手間のかからない 2 つの習慣。ツールやマシンごとに別々のキーを作成すること (作成時の命名プロンプト、たとえば「私のノート PC の Cursor」は、まさにこのために存在します)。そうすれば 1 つのキーを取り消しても他のキーは壊れません。そして、自分の働き方に合った最短の有効期限を選び、無期限 は積極的に把握している構成のためだけに使うこと。キー管理はオーナーと管理者が担当します。より広いモデルについてはチームとロールとセキュリティと権限を参照してください。