launchdarkly-flag-targeting

LaunchDarkly のフラグターゲティングとロールアウト

あなたは、機能フラグについて誰が何を見るかを変更する手順を案内するスキルを使用しています。あなたの役割は、フラグの現在の状態を理解し、ユーザーが望む内容に対して適切なターゲティング方法を判断し、安全に変更を加え、その結果の状態を検証することです。

前提条件

このスキルでは、リモートでホストされている LaunchDarkly MCP サーバーが環境内に構成されている必要があります。

必要な MCP ツール:

• get-flag: 変更を加える前に現在の状態を把握します
• toggle-flag: 環境内のフラグに対してターゲティングをオンまたはオフにします
• update-rollout: デフォルトルール (フォールスルー) のバリエーションまたはパーセンテージロールアウトを変更します
• update-targeting-rules: カスタムターゲティングルールを追加、削除、または変更します
• update-individual-targets: 個別ターゲティングから特定のユーザー/コンテキストを追加または削除します

オプションの MCP ツール:

• copy-flag-config: ある環境から別の環境へターゲティング構成をコピーします
• create-approval-request: 直接変更がブロックされている場合に承認リクエストを作成します
• list-approval-requests: フラグの保留中の承認リクエストを確認します
• apply-approval-request: すでに承認された承認リクエストを適用します

中心となる概念: 評価順序

ターゲティングを変更する前に、LaunchDarkly がフラグをどのように評価するかを理解してください。これにより、あなたの変更が実際に何を行うかが決まります:

1. フラグが OFF -> 全員に offVariation を配信します。それ以外は関係ありません。
2. 個別ターゲット -> コンテキストが特定のターゲットリストに一致する場合、そのバリエーションを配信します。最優先です。
3. カスタムルール -> ルールを上から下へ評価します。最初に一致したルールが優先されます。
4. デフォルトルール (フォールスルー) -> 他に何も一致しなかった場合、このバリエーションまたはロールアウトを配信します。

つまり: ターゲティングルールを追加してもフラグが OFF の場合、誰もその変更を目にしません。デフォルトルールにパーセンテージロールアウトを設定しても個別ターゲットがある場合、そのターゲットされたユーザーはロールアウトを迂回します。

ワークフロー

ステップ 1: 現在の状態を理解する

何かを変更する前に、すでに構成されている内容を確認してください。

1. 環境を確認します。 環境を指定しない「オンにして」は曖昧です。ユーザーがどの環境を意味しているかを必ず確認してください。推測するのではなく、尋ねることをデフォルトとします。
2. フラグを取得します。 対象の環境を指定して get-flag を使用し、以下を確認します:
   • on: ターゲティングは現在有効ですか?
   • fallthrough: デフォルトルールは何ですか? (バリエーションまたはパーセンテージロールアウト)
   • offVariation: フラグがオフのときに何が配信されますか?
   • rules: カスタムターゲティングルールはありますか?
   • targets: 個別にターゲットされたユーザー/コンテキストはありますか?
   • prerequisites: これが依存するフラグはありますか?
3. 複雑さを評価します。 ルールも個別ターゲットもないフラグは単純です。複数のルール、ターゲット、前提条件があるフラグには、より慎重な対応が必要です。

ステップ 2: 適切なアプローチを決定する

ユーザーが何を求めているか、そして何を見つけたかに基づいて、適切なツールと戦略を選択します。完全なリファレンスについては、ターゲティングパターンを参照してください。

一般的なシナリオ:

ユーザーの要望	ツール	備考
「オンにする」	on: true を指定した toggle-flag	最もシンプルな変更
「オフにする」	on: false を指定した toggle-flag	全員に offVariation を配信します
「X% にロールアウトする」	rolloutType: "percentage" を指定した update-rollout	重みの合計は 100 でなければなりません
「ベータユーザーに対して有効にする」	update-targeting-rules: 句を含むルールを追加	ルールは内部で AND、ルール間で OR されます
「特定のユーザーを追加する」	update-individual-targets	最優先され、すべてのルールを上書きします

ルール、個別ターゲット、またはパーセンテージロールアウトを作成する前に、コンテキストがそれをサポートしていることを確認してください。 フラグの評価が持たないコンテキストの種類や属性を指定したルールは、黙って一切マッチしません。個別ターゲットは、email のような属性ではなく、コンテキストの key にマッチします。また、ロールアウトは、フラグが読み取られる場所に存在する種類によってのみバケット化できます。実際に発火するコンテキストを選ぶには、コンテキストの可用性を参照してください。 | 「完全なロールアウト」 | rolloutType: "variation" を指定した update-rollout | 1 つのバリエーションを全員に配信します | | 「staging からコピーする」 | copy-flag-config | テスト済みの構成を本番環境に昇格させます |

ステップ 3: 安全チェックリストを実行する

変更を適用する前に、特に本番環境では、安全チェックリストを確認してください。主なチェック項目:

1. 正しい環境ですか? 意図した環境をターゲットにしていることを再確認してください。
2. 承認が必要ですか? 一部の環境では承認ワークフローが必要です。いずれかの変更ツールが requiresApproval: true を返した場合:
   • この環境では承認が必要であることをユーザーに伝えます。
   • 提供されている場合は approvalUrl を共有します。
   • 同じ指示(レスポンスの instructions フィールドで返されます)を指定して create-approval-request を使い、承認リクエストを作成することを提案します。
   • 承認をバイパスしたり、自動承認したりしないでください。
   • 完全なプロセスについては、承認ワークフローを参照してください。
3. 前提条件となるフラグがありますか? このフラグに前提条件がある場合、ターゲティングが期待どおりに機能する前にそれらを満たす必要があります。
4. ルールの順序の影響は? ルールを追加する場合は、評価順序のどこに入るかを考慮してください。ルールは上から下へ評価され、最初にマッチしたものが優先されます。
5. コメントを含めてください。 常に監査証跡のコメントを追加してください。特に本番環境の変更では重要です。

ステップ 4: 変更を適用する

変更には適切なツールを使用します。主な注意点:

• toggle-flag: on: true または on: false、env、および comment を指定します。
• update-rollout: 合計が 100 になる人間にわかりやすい重み(例: 80% なら 80)を指定した rolloutType: "percentage"、または variationIndex を指定した rolloutType: "variation" を使用します。
• update-targeting-rules: 指示は addRule、removeRule、updateRuleVariationOrRollout、addClauses、removeClauses、reorderRules をサポートします。
• update-individual-targets: 指示は addTargets、removeTargets、addContextTargets、removeContextTargets、replaceTargets をサポートします。

詳細な指示の例については、ターゲティングパターンを参照してください。

ステップ 5: 検証する

変更を適用した後、結果を確認します:

1. 更新されたフラグを取得します。 get-flag を再度使用して、新しい状態を検証します。
2. ユーザーが期待する内容を確認します。 結果として得られるターゲティングを平易な言葉で説明します:
   • 「フラグは本番環境で ON になり、ユーザーの 25% に true、75% に false を配信しています。」
   • 「ベータユーザーはバリエーション A を見るようになりました。それ以外の全員はデフォルト(バリエーション B)を受け取ります。」
3. 副作用を確認します。 ルールまたは個別ターゲットがある場合は、変更がそれらと正しく相互作用することを確認してください。

承認が必要な環境の扱い

いずれかのミューテーションツールが requiresApproval: true を返した場合、その環境では承認が必要なため、直接の変更はブロックされています。承認ワークフロー リファレンスに従って、次の手順を実行してください。

1. ブロックされたレスポンスの instructions を使用して、create-approval-request で承認リクエストを作成します
2. 保留中の承認についてユーザーに通知し、承認リクエストの詳細を共有します
3. 必要に応じて、後で list-approval-requests を使って承認ステータスを確認します
4. レビュアーが承認したら（reviewStatus が "approved"）、apply-approval-request でリクエストを適用します
5. 適用後に get-flag で結果を検証します

重要なコンテキスト

• update-rollout は人間にわかりやすいパーセンテージを使用します。 80% の場合は 80000 ではなく 80 を渡してください。内部の重み変換はツールが処理します。
• 重みの合計は 100 にする必要があります。 パーセンテージロールアウトでは、すべてのバリエーションの重みの合計がちょうど 100 になる必要があります。
• ルールの順序は重要です。 ルールは上から下へ評価されます。ルールの順序を並べ替えると、個々のルールを変更しなくても動作が変わる可能性があります。
• 個別ターゲットが最優先です。 個別ターゲットはすべてのルールとデフォルトを上書きします。誰かを個別ターゲットとして追加すると、その人にはルールが適用されません。
• 「launched」フラグも依然として ON です。 ステータスが "launched" のフラグは、全員に単一のバリエーションを配信しています。フラグを削除したい場合は、ターゲティングの変更ではなく、cleanup スキル を使用してください。

リファレンス

• ターゲティングパターン: ロールアウト戦略、ルールの構築、個別ターゲティング、環境間のコピー
• コンテキストの可用性: ルール、ターゲット、ロールアウトが使用できるコンテキストの種類／属性 — フラグが読み取られるサーフェスに種類を一致させる方法、キーと属性、ロールアウトのバケット分け
• 安全性チェックリスト: 変更前の検証、承認ワークフロー、環境の認識
• 承認ワークフロー: 承認リクエストの作成、確認、適用