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

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

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

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

入り口は 2 つあります。Settings, API Keys で自分でキーを作成するか (以下のセットアップ)、AI Insight ページに任せるかです。自分のコーディングエージェントで修正する方がよい検出結果には、エージェントに貼り付けられる既製のプロンプト Copy prompt と、coding-agent という名前のキーを作成して正確な接続コマンドを表示する Set up MCP ショートカットが用意されています。

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

サーバーは 7 つの機能を公開します。エージェントがデータと操作のために呼び出す 5 つの ツール と、タスク全体をオーケストレーションする 2 つの プロンプトフロー です:

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

セッションの様子#

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

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

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

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

セットアップ#

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

修正後にワークフローを再実行する (オプトイン)#

デフォルトではキーは読み取り専用です。ループを閉じたい場合 (エージェントがコードを修正し、プッシュし、CI を再実行し、グリーンになるのを見届ける)、Allow workflow dispatch にチェックを入れてキーを作成します。そのキーは追加で mcp:dispatch スコープを持ち、エージェントは監視対象リポジトリで workflow_dispatch 実行をトリガーし、実行ステータスツールでポーリングし、完了後にログを読めるようになります。グリーンの実行も読み取れるため、エージェントは失敗を観察するだけでなく、修正を確認できます。

• ディスパッチは、ワークスペースが監視しているリポジトリでのみ、かつ workflow_dispatch トリガーを宣言しているワークフローに対してのみ機能します。
• 既存のキーが遡ってディスパッチ権限を得ることはありません。チェックボックスを有効にして新しいキーを作成してください。
• 再実行は、ディスパッチ先のブランチにあるものをそのまま実行します。まず修正をプッシュしてから、ディスパッチしてください。

セキュリティモデル#

• デフォルトで読み取り専用。 キーは CI の失敗と実行のデータを読み取れます。Latchkey や GitHub の変更はデフォルトで無効です。キーが作成時にオプトインできる唯一の書き込みはワークフローのディスパッチ (mcp:dispatch) で、Latchkey の設定や任意の GitHub 操作に及ぶことはありません。
• ワークスペーススコープ。 ワークスペースはキー自体から導出されるため、キーは自分のワークスペースのデータしか見られません。
• 取り消し可能。 Settings, API Keys から任意のキーを即座に取り消せます。取り消したキーは監査用に一覧されます。

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

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