launchdarkly-metric-choose

LaunchDarkly メトリクスの選択

あなたは、実験、ガード付きロールアウト、またはリリースポリシーを設定する前に、ユーザーが適切なメトリクスを選択できるよう支援するスキルを使用しています。あなたの役割は、機能のコンテキストを理解し、既存のプロジェクトポリシーから自動的に付加されるものを明らかにし、利用可能で正常なものを棚卸しし、明確に型付けされた推奨事項を作成することです。

このスキルは助言的なものです。メトリクスを作成したり、実験に付加したり、ロールアウトを構成したりはしません。それらのタスクについては、このドキュメントの末尾にある関連スキルを参照してください。

前提条件

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

必要な MCP ツール:

• list-metrics — 利用可能なメトリクスをその型とイベントキーとともに棚卸しします
• list-metric-events — どのイベントキーに最近のアクティビティがあるかを確認します

オプションの MCP ツール（ワークフローを強化）:

• list-release-policies — どのメトリクスがガード付きロールアウトに自動付加されるかを構成するプロジェクトレベルのポリシーを取得します。ガード付きロールアウトとリリースポリシーのパスではこれを使用します。

ワークフロー

ステップ 1: コンテキストを特定する

最初に 2 つの質問をします:

1. これは何のためですか？

   • (a) 実験 — フラグバリアントを使って仮説を検証する
   • (b) ガード付きロールアウト — 自動的なリグレッション検出を伴いながら変更を段階的にロールアウトする
   • (c) リリースポリシー — 特定の条件に一致するすべてのガード付きロールアウトに対してデフォルトのメトリクスを構成する、プロジェクト全体のポリシーを作成または編集する

2. 変更内容は何ですか？

   • フラグキー（該当する場合）
   • 平易な言葉での説明: 「新しいチェックアウトフローをロールアウトする」／「新しいレコメンデーションアルゴリズムをテストする」

ステップ 2: 既存の構成を取得する（ガード付きロールアウトとリリースポリシーのみ）

実験の場合 — このステップはスキップしてください。 明らかにすべき既存の構成はありません。

ガード付きロールアウトとリリースポリシーの作業の場合、最初に list-release-policies を呼び出します:

list-release-policies(projectKey)

推奨事項を作成する前に結果を明らかにします:

Your project has 2 release policies:

Policy: "Production guardrails" (applies to: environment=production)
  Auto-attaches to guarded rollouts:
    ✓ api-error-rate  (count, LowerThanBaseline)
    ✓ p95-latency     (value, LowerThanBaseline)
    ✓ [Metric group] Core Platform Health (3 metrics)

Policy: "Default" (applies to: all environments)
  No metrics configured.

これは、ユーザーが追加で何かを選択する前に、すでにカバーされている内容を伝えます。ガード付きロールアウトの場合、これらのメトリクスは自動的に適用されます — 推奨事項は、ゼロから作り直すことではなく、上乗せして何を追加するかに関するものです。

ポリシーが存在しない場合、またはメトリクスが構成されたポリシーがない場合は、すべてのメトリクスを手動で選択する必要があることを伝えます。

ステップ 3: イベントの健全性とともに利用可能なメトリクスを棚卸しする

list-metrics を呼び出してプロジェクト内のすべてのメトリクスを確認し、list-metric-events と相互参照します。

2 つのグループに整理します:

グループ	基準	備考
正常	イベントキーが list-metric-events に存在する	推奨しても安全
リスクあり	イベントキーが list-metric-events に存在しない	警告: データが生成されない可能性がある

推奨する前にこの棚卸し結果を示します — これにより、ユーザーが想定しているメトリクスにイベントが流れていないことが明らかになるかもしれません。

ステップ 4: 推奨する

推論はコンテキストによって大きく異なります。

---

(a) 実験

メトリクスのリストではなく、仮説から始めます。

利用可能なメトリクスを見る前に、ユーザーに次の文を完成させるよう依頼してください:

「この変更が成功すれば、[メトリクス] は [増加 / 減少] する。」

プライマリメトリクスは、その仮説を直接測定するものでなければなりません — 代理指標でも、相関でもありません。ユーザーがこの文を完成できない場合は、まずそこに到達できるよう支援してください。

プライマリメトリクスを 1 つ提案します。 それは次の条件を満たす必要があります:

• 仮説を直接測定する
• イベントが実際に流れている
• 成功の方向が明確である（HigherThanBaseline または LowerThanBaseline）

型付きのセカンダリメトリクスを提案します。 該当する各型から少なくとも 1 つ提案してください:

型	目的	例
ガードレール	変更によって何かが壊れていないか？	エラー率、クラッシュ率、レイテンシ p95
カウンターメトリクス	A が B を犠牲にして改善したか？	プライマリがコンバージョンの場合、サポートチケットやセッション長を追加する
補助シグナル	相関する行動が仮説を裏付けるか？	プライマリがサインアップの場合、オンボーディングステップ 2 の完了を追加する

通常、各型から 1 つずつが適切な量です。セカンダリメトリクスを増やすほど、ノイズと解釈の負担が増えます。

---

(b) ガード付きロールアウト

ガード付きロールアウトは安全機構であり、実験ではありません。追加する各メトリクスは自動ロールバックの潜在的なトリガーになります — ロールアウトが完了する前にしきい値を超えて悪化した場合、LaunchDarkly はリリースを停止して元に戻すことができます。

自動で付与されるものから始めます。 ステップ 2 でリリースポリシーの結果を提示した後、次のように尋ねてください: 「自動で付与されたメトリクスで十分ですか、それともこの特定のロールアウト向けにさらに追加しますか？」

追加のメトリクスを推奨する場合:

• 信頼性を重視する — 安定して予測可能なベースラインを持つエンジニアリングメトリクス（エラー率、レイテンシ、クラッシュ率）
• 回帰分析の下でノイズが多く解釈が難しい探索的なプロダクトメトリクスは避ける
• 少ないほど良い。 高シグナルのメトリクス 2〜3 個が適切な規模です。5 個を超えると偽陽性のロールバックリスクが生じます。
• イベントが実際に流れているメトリクスのみを推奨する。 ガード付きロールアウトにおけるリスクのあるメトリクスは、シグナルを生まないか、さらに悪い場合には実際の回帰ではなくデータ品質の問題により偽のロールバックを引き起こします。

ガード付きロールアウトの推奨される出発点（まだポリシーでカバーされていない場合）:

1. エラー率 — 新しいバリエーションでより多くのエラーが見られるか？
2. レイテンシ / 応答時間 — 新しいバリエーションは遅くなっていないか？
3. 変更が影響する中核的なユーザーアクションに紐づくドメイン固有のメトリクスを 1 つ

---

(c) リリースポリシー

リリースポリシーは、条件に一致するプロジェクト内のすべてのロールアウトに適用されます。これは最も高い基準です。

現在の状態から始めます。 ステップ 2 で既存のポリシーを提示した後、次のように尋ねてください: 「どのポリシーを編集しますか、それとも新しいポリシーを作成しますか？どの環境またはフラグ条件に適用しますか？」

ポリシーにメトリクスを推奨する場合:

• 最大 2〜3 個のメトリクス。 それ以上だと、メトリクスがうまく当てはまらないロールアウトも含め、すべてのロールアウトにとってポリシーが負担になります。
• 長く安定したイベント履歴を持つメトリクスのみを推奨する。 イベントが何か月も安定して流れているなら、プロジェクト全体の安全なデフォルトです。時折生じる欠落は、規模が大きくなると問題を引き起こします。
• 追加には慎重に対応する。 ユーザーが 3 個を超える提案をした場合、どれを削除するか尋ねてください。選択するという規律そのものが要点です。
• スコープ条件を説明する。 environment=production にスコープされたポリシーは、本番のロールアウトにのみ適用されます。ステージング（ベースラインが異なる可能性がある）でも同じメトリクスを望むのか、別のポリシーを望むのかをユーザーが検討できるよう支援してください。

典型的な強力なポリシー候補: エラー率、中核的なコンバージョンまたはエンゲージメントメトリクス、レイテンシ。

ステップ 5: 推奨事項を提示する

明確な名前付きリストを出力します。各指標が何のためのものか、そして何がすでにカバーされているかを明示してください。

Recommended metrics for: new checkout flow guarded rollout (environment: production)

AUTO-ATTACHED (from "Production guardrails" policy):
  ✓ api-error-rate    (count, LowerThanBaseline)
  ✓ p95-latency       (value, LowerThanBaseline)

ADDITIONAL — recommended for this rollout:
  ✓ checkout-conversion  (occurrence, HigherThanBaseline)
    → Confirms the rollout isn't degrading the core conversion the feature targets

⚠ page-load-time — no recent events. Instrument the event before including it,
  or remove it from the list to avoid a false rollback trigger.

その後、次のステップで締めくくります：

• ユーザーが必要とする指標が存在しない場合 → metric-create スキルを使用する
• イベントが流れていない場合 → metric-instrument スキルを使用する
• リストが確認されたら → ガード付きロールアウトまたは実験を構成する（LaunchDarkly UI または API 経由）

重要なコンテキスト

• 実験中の指標の変更には再起動が必要です。 LaunchDarkly は実験の開始時に指標の構成をスナップショットします。起動後に指標を追加、削除、変更するには、実験を停止して再起動する必要があります。変更前の履歴データは比較できません。ユーザーが実験中であると述べた場合は、すぐにこの点を指摘してください。
• イベントのないプライマリ指標は、プライマリ指標がないよりも悪いです。 実験は統計的な出力を生成しません。イベントの健全性はプライマリ指標のための必須要件です。
• CUPED とパーセンタイル分析は互換性がありません。 実験で CUPED の分散削減を使用している場合、パーセンタイルベースの指標（例：p95 レイテンシ）は、サイレントに平均ベースの分析に劣化します。ユーザーが CUPED が有効な実験でパーセンタイル指標を選択した場合は、この点を指摘してください。
• コンテキスト種別の不一致はデータ欠落を引き起こします。 指標イベントが device コンテキストでトラッキングされているのに、実験が user でランダム化している場合、イベントは正しくアトリビューションされません。track() 呼び出しのコンテキスト種別が実験のランダム化単位と一致していることを確認してください。
• リリースポリシーの指標は同じコンテキスト種別を共有する必要があります。 ガード付きロールアウトのリリースポリシー内のすべての指標は、同じランダム化単位を使用する必要があります。ユーザーがコンテキスト種別の一致しない指標を提案した場合は、ポリシーを構成しようとする前に指摘してください。

関連スキル

• launchdarkly-metric-create — まだ存在しない指標を作成する
• launchdarkly-metric-instrument — track() 呼び出しを追加してイベントが流れ始めるようにする