launchdarkly-release-autopilot-settings

LaunchDarkly Release Autopilot の設定

LaunchDarkly MCP を通じて Release Autopilot（GitHub App によるコード自動化）を設定する、または PR が分類されなかった理由を説明するスキルを使用しています。Release Autopilot はプルリクエストを作成・変更（自動フラグ設定）したり、自動リリースを実行したりできます。すべての書き込み操作は、本番環境に影響を及ぼす可能性のある自動化として扱ってください。

前提条件

このスキルには、リモートでホストされている LaunchDarkly MCP サーバーが必要です。

必須の MCP ツール：

• get-automations：アカウント設定と、GitHub App にインストールされたリポジトリのページを返します。各リポジトリには mapped と有効な設定が含まれます。1 つのリポジトリを指定するには repo を渡し、絞り込むには mapped: true または mapped: false を渡します。
• update-automations：accountWide: true はアカウント設定を変更し、accountWide: false と repo の指定は、1 つのリポジトリをマッピングするか、その設定を上書きします。
• delete-automations-repo-settings：1 つのリポジトリのマッピングを解除します。

Automations への名称変更がまだ反映されていないサーバーでは、同じツールが get-release-autopilot、update-release-autopilot、delete-release-autopilot-repo-settings という名前になっています。同じ引数でこれらの名前を使用してください。呼び出しが「this tool has been removed from the server」というエラーで失敗した場合は、新しいツール名が読み込まれるように LaunchDarkly MCP サーバーを再接続するようユーザーに依頼してから、再試行してください。

これらのツールが見つからない場合は、そこで中止してください。REST 呼び出しや数値の GitHub ID をでっち上げたり、設定を推測して「修正」したりしないでください。

基盤となるエンドポイントには Release Autopilot アドオンが必要です。すべての Release Autopilot ツールが 404 を返す場合、アカウントでは Release Autopilot アドオンが有効になっていません。再試行したり REST に切り替えたりせず、ユーザーに「お使いのアカウントでは Release Autopilot アドオンが有効になっていません」と伝えてください。

基本原則

1. 安全側に失敗させます。 診断は読み取り専用です。現在の状態と変更案を確認した後でユーザーがその書き込みを明示的に承認しない限り、「分類を機能させる」ために設定を変更してはいけません。

2. 各リポジトリで実行する内容は、そのリポジトリ独自の設定で決まります。 プロジェクトの Automations 設定ページ（/projects/{projectKey}/settings/automations）を使用するアカウントでは、Release Autopilot はリポジトリの設定のみを読み取り、アカウント設定は読み取りません。その場合、リポジトリで有効にされていない機能は無効です。移行が完了するまではアカウント設定も使用するアカウントもあるため、アカウント用ツールは引き続き利用できます。そのようなアカウントでは：

   • アカウントで機能が有効になっており、リポジトリで無効にされていない場合に限り、そのリポジトリで機能が実行されます。
   • アカウントで機能を無効にすると、マッピングされているすべてのリポジトリで無効になります。
   • アカウントで機能を有効にすると、その機能を無効にしていない、マッピング済みのすべてのリポジトリで実行が開始されます。

   get-automations が返すリポジトリの有効値は、そのアカウントで適用されるルールに従います。リポジトリで何が実行されるかを判断するには、アカウント設定ではなく、その値を使用してください。

3. Release Autopilot に書き込む前に、毎回確認してください。 アカウントへの PATCH、マッピング、リポジトリのオーバーライド、マッピング解除では、すべて書き込み前に確認を使用します。ユーザーが指定したリポジトリのみを操作してください。

4. 最小権限を適用します。 ユーザーが自動リリースを明示的に依頼しない限り、自動リリースを有効にしてはいけません（コードがリリースされる可能性があります）。承認ゲートをなくすよう明示的に依頼されない限り、approvalRequired を無効にしてはいけません。ユーザーが指定していないリポジトリをマッピングまたはマッピング解除してはいけません。インストール一覧を順に処理して、すべてをマッピングしてはいけません。

5. 検出してからマッピングします。 owner/name を渡してください。数値の GitHub id を尋ねてはいけません。「このリポジトリ」／「この PR」と言われた場合は、現在のワークスペースの git remote を優先してください（フォークと上流リポジトリでリモートが異なる場合は、どちらかを確認します）。owner/name は GitHub App のインストール一覧との照合にのみ使われます。Release Autopilot は App を通じて動作するため、インストール対象外のリポジトリは解決も操作もできません。リポジトリがインストール対象外、または App がインストールされていないことを示す 404 が返された場合、それが回答です。別の表記で再試行したり、別の場所でリポジトリを検索したりしてはいけません。

6. 初回のマッピングでは projectKey が必要です。 マッピングの作成時には必須です。以降の更新では省略できます。

7. autoCleanup は省略します。 これはまだ Release Autopilot の設定に含まれていません。送信してはいけません。また、レスポンスから PATCH にコピーしてはいけません。

8. GitHub の接続はブラウザーリンクで行います。 get-automations が githubConnectUrl を返した場合は、その正確な URL をユーザーに提示し、完了したと言われるまで待ってください。その後、もう一度 get-automations を呼び出します。GitHub のインストールや認証を自分で行ってはいけません。flow=install は Install GitHub App です。flow=authorize は Authorize GitHub です。どちらもインテグレーションドロワーと同じページです。ユーザーはそのブラウザーで、あらかじめ LaunchDarkly にログインしている必要があります。

書き込み前に確認

停止してください。 このターンの提案にユーザーが「はい」と答えるまで、update-automations または delete-automations-repo-settings を呼び出さないでください。前のターンでの「はい」や、設定を明示していない曖昧な「直して」／「進めて」では不十分です。

1. まず現在の状態を読み取ります（変更がリポジトリ単位の場合は、repo を指定して get-automations を呼び出します）。
2. 現在の状態と提案する内容を、1〜2文で伝えます。影響範囲も含めてください。マップの場合は、そのリポジトリに適用される自動フラグ付けと自動リリースの両方を伝えます（まず get-automations から現在の状態を読み取ってください）。
3. 返答を待ちます。質問と同じツール呼び出しの一連の処理で書き込みをまとめて行わないでください。

アカウントの変更（accountWide: true を指定した update-automations。有効化を含むすべてのフィールドが対象です）。次の影響は、引き続きアカウント設定を使用しているアカウントに適用されます（基本原則を参照）。

このアカウントでは自動フラグ付けが ON です。マップ済みのすべてのリポジトリで OFF にしますか？自動フラグ付けのプルリクエストは、再び ON にするまで停止します。

このアカウントでは自動フラグ付けが OFF です。アカウントで ON にしますか？自動フラグ付けを OFF にしないマップ済みリポジトリで、自動フラグ付けのプルリクエストが作成され始める可能性があります。

自動フラグ付けの approvalRequired は ON です。OFF にしますか？自動フラグ付けの PR で、その承認ゲートが不要になります。

自動リリースについても同じ形式で確認し、自動リリースによってリリースが実行される可能性があることを伝えてください。

リポジトリをマップする、または変更する（accountWide: false を指定した update-automations）：

提案では常に両方の機能を明示し、新規マッピングでは両方を送信します：{ "enabled": true } または { "enabled": false }。リポジトリで設定されていない機能は、プロジェクトの Automations 設定を使用するアカウントでは OFF になり、引き続きアカウント設定を使用しているアカウントではアカウント設定に従います。自動フラグ付けだけに言及したマッピングは確認しないでください。

launchdarkly/gonfalon はマップされていません。プロジェクト default にマップし、自動フラグ付けを ON、自動リリースを OFF にしますか？Release Autopilot は、このリポジトリで自動フラグ付けの PR を分類して作成し始める可能性があります。自動リリースは OFF のままです。

launchdarkly/gonfalon はマップされていません。プロジェクト default にマップし、自動フラグ付けと自動リリースを ON にしますか？Release Autopilot は、このリポジトリで自動フラグ付けの PR を作成し始めるだけでなく、自動リリースも開始する可能性があり、リリースが実行されることがあります。

launchdarkly/gonfalon は、自動フラグ付けの有効な状態が ON、自動リリースの有効な状態が OFF で default にマップされています。このリポジトリだけで自動フラグ付けを OFF にするオーバーライドを設定しますか？自動リリースは現在の状態（OFF）のままです。

マップ解除（delete-automations-repo-settings）：

launchdarkly/gonfalon は、自動フラグ付けの有効な状態が ON、自動リリースの有効な状態が OFF でプロジェクト default にマップされています。マップ解除しますか？再びマップするまで、Release Autopilot はこのリポジトリの自動フラグ付けと自動リリースを停止します。

確認を得た後、提案に含まれるフィールドのみを適用します。その後、検証します（安全確認の代わりに検証を使わないでください）。

ワークフローを選択する

アカウントの状態ではなく、ユーザーの依頼内容に基づいて振り分けます。次の項目を上から順に確認してください。

• 「Release Autopilot が PR を分類／自動フラグ付けしなかったのはなぜですか？」（または同様の質問）→ PR が分類されなかったのはなぜですか？。何も設定されていないアカウントでも該当します。このワークフローでは設定を書き換えないでください。
• 初回設定（「Release Autopilot を設定して」「オンボーディングして」「始めたい」）→ launchdarkly-release-autopilot-onboarding。すべての決定事項を先に確認し、1つのプランとして承認を得ます。
• 設定／マップ／有効化／マップ解除 → 設定を構成する。

PR が分類されなかったのはなぜですか？

PR が分類されなかった、自動フラグ設定されなかった、または Release Autopilot が PR を無視した理由をユーザーが尋ねた場合に使用します。読み取り専用です。 次の順番で確認します。最初に問題が見つかった時点で確認を止め、修正方法を伝えます（修正を適用するよう求められた場合は、その後書き込み前に確認します）。自動フラグ設定がオフになっている、またはリポジトリがマッピングされていないことが原因で、まだ何も設定されていない場合は、設定方法として launchdarkly-release-autopilot-onboarding を案内してください。

PR の URL、git remote、またはユーザーが伝えた名前から GitHub リポジトリ（owner/name）を特定します。リポジトリを 1 つに特定できない場合は、ユーザーに確認してください。別のリポジトリを診断してはいけません。

1. このリポジトリはプロジェクトにマッピングされていますか？ repo: "owner/name" を指定して get-automations を実行し、返されたリポジトリの mapped を確認します。エラーまたは応答に githubConnectUrl が含まれている場合は、flow を確認します。

   • flow=install：GitHub App がインストールされていないため、Release Autopilot は PR を認識できません。これが原因です。ユーザーにリンクを伝えて終了します。
   • flow=authorize：このメンバーは GitHub を認証していないため、owner/name を照会できません。これは Release Autopilot が PR をスキップした理由ではありません。その旨を伝えてリンクを案内し、ユーザーが認証を完了したら、この手順から再開します。これを修正方法として報告してはいけません。

   インストール済みでもマッピングされていないリポジトリの場合は、原因が異なります。マッピングされていないインストール済みリポジトリでは Release Autopilot は実行されません。終了します。

2. このリポジトリでは自動フラグ設定が実質的に有効になっていますか？ リポジトリのペイロードで、自動フラグ設定の enabled が実効値です。これはアカウントで適用されるルールに基づきます（基本原則を参照）。値が false の場合、これが原因です。終了して、原因を伝えます。

   • enabledOverride が false：リポジトリで自動フラグ設定がオフになっています。
   • enabledOverride が true：リポジトリではオンになっているため、アカウント設定によってオフになっています。これは、アカウント設定をまだ使用しているアカウントでのみ発生します。
   • enabledOverride が存在しない：リポジトリでは自動フラグ設定が設定されていません。このリポジトリで自動フラグ設定をオンにする必要があります。account.autoFlagging.enabled が false の場合は、アカウント設定をまだ使用しているアカウントでも、自動フラグ設定をオンにする必要があると伝えてください。

両方に問題がない場合（リポジトリがマッピングされ、自動フラグ設定が実質的にオンの場合）：

• 「試しに」設定を切り替えてはいけません。
• Release Autopilot のランブックを案内してください。これらは社内向けの LaunchDarkly Confluence ページ（PD スペース）であり、公開ドキュメントの URL はまだありません。この MCP のインターフェースでは把握できない理由（GitHub App が別の組織にインストールされている、PR がインストール済みリポジトリにない、ワークフロー／アプリの権限、分類器のスキップルールなど）によって、分類が失敗することがあります。
  • Flag Classification (ODD) Runbook — 分類器自体について説明します。判定結果（not-suited、already-flagged）、エスカレーション、および PR にどの判定が下されたかを記録する PR ごとの台帳が含まれます。
  • GitHub App Runbook — PR イベントが Release Autopilot に届かない場合について説明します。インストールの適用範囲、権限、Webhook が対象です。
• 任意で確認：repo を指定して get-automations を実行し、リポジトリがインストール一覧に含まれていること（visibleOnInstall）を確認します。PR が作成されることを想定していて、実際に PR が存在するものの承認待ちになっている場合は、autoFlagging.approvalRequired も確認します。

設定を構成する

手順 1：現在の設定を読み取る

1. フィルターなしで get-automations を実行します。アカウント設定と、インストール済みリポジトリの最初のページが返されます（projectKey は任意です。インストールはアカウント全体に適用されます）。hasMore が true の間は、offset を使ってページを取得します。
2. ユーザーが指定した各リポジトリについて、repo: "owner/name" を指定して get-automations を実行します。

githubConnectUrl が存在する場合は、ユーザーにそのリンクを伝えて、このターンを終了します。後続の呼び出しで URL が表示されなくなるまで、マッピングしてはいけません。

ステップ 2：アカウントのデフォルト設定（必要な場合）

アカウントの PATCH が必要な場合は、書き込み前の確認に従い、確認済みのフィールドのみを指定して update-automations を実行します。パラメーターには accountWide: true と confirm: true を指定してください。

• autoFlagging.enabled / autoFlagging.approvalRequired（承認が有効なのはここだけです）。現在、エージェントのバックエンドは approvalRequired を読み取りません。いずれの場合も、自動フラグ付けの提案には @launchdarkly approve が必要です。承認をオフにしたいとユーザーが希望した場合は、変更を提案する前に、現時点では効果がないことを伝えてください。
• autoReleasing.enabled

autoCleanup は送信しないでください。アカウントの Release Autopilot 設定を更新する権限が必要です。

ステップ 3：リポジトリをマッピングまたは上書きする

ユーザーが指定したリポジトリに限ります。書き込み前の確認に従い、accountWide: false と confirm: true を指定して update-automations を実行します。

1. repo: "owner/name" を優先します。
2. マッピングを作成する場合は projectKey を含めます。
3. リポジトリレベルの autoFlagging / autoReleasing。新しいマッピングでは両方を送信します（1 つのリポジトリのマッピングまたは変更を参照）。アカウント設定を引き続き使用しているアカウントでは、リポジトリ側で、アカウント側でオフになっている機能を有効にすることはできません。

マッピング先のプロジェクトで Release Autopilot のリポジトリ設定を更新する権限が必要です。

ステップ 4：確認する（書き込みが確認された後）

• get-automations（リポジトリに適用する変更の場合は repo を指定）。
• 有効な enabled の設定が提案内容と一致している必要があります。アカウント設定を引き続き使用しているアカウントでは、アカウント側がオフの場合、リポジトリ側をオンにすることはできません。
• マッピング済みのリポジトリは、get-automations で mapped: true として表示されます。

マッピングを解除するには、書き込み前の確認に従い、repo と confirm: true を指定して delete-automations-repo-settings を実行します。

対象外

• 自動クリーンアップと自動アーカイブには、launchdarkly-automations-cleanup-settings と launchdarkly-automations-archival-settings を使用します。これらの設定の autoCleanup は、別の未使用フィールドです。
• ツール内での GitHub OAuth の完了。代わりに githubConnectUrl をユーザーに案内してください。
• Vega の推論と BYOK の設定、および環境リリース計画。どちらもオンボーディングスキルで案内しています。
• Observability MCP（github_repositories）— リポジトリのマッピングだけを目的に、別の MCP サーバーを必須にしないでください。
• このスキルを使用した分類ルール、GitHub App の権限、組織のインストール範囲の変更