experiment-brainstorm

experiment-brainstorm

チームが過去に停止した実験を踏まえて、新しい実験のアイデアを提案します。まず履歴を確認し、実際に指標を動かした要素、ガードレールで問題が起きた箇所、十分に検証されていないタグやプロジェクトに基づいて提案してください。

すべての API 呼び出しには、同梱のヘルパーを使用します：${CLAUDE_PLUGIN_ROOT}/scripts/gb-call。GB_API_KEY が必要です。シェルで設定するか、/growthbook:gb-setup で ~/.config/growthbook/.env に書き込んでください。未設定または無効の場合、gb-call のエラーメッセージに /growthbook:gb-setup が案内されます。

ワークフロー

1. 実験の一覧を取得します。新しいものから順に並べます。

   gb-call GET '/api/v1/experiments?limit=50&status=stopped&sortBy=dateCreated&sortOrder=desc'
   

   1ページあたり最大50件の実験を返します（limit の上限は100です）。必ず sortBy=dateCreated&sortOrder=desc を指定してください。API のデフォルトの並び順は古いものが先頭です。履歴が複数ページにわたる組織で並べ替えずに取得すると、すべての提案が古い実験に基づいてしまいます。

   ユーザーがブレインストーミングの範囲を指定した場合（「チェックアウトのアイデア」「次に成長チームが検証すべきこと」など）、取得後に結果を捨てるのではなく、フィルターで対象を絞り込みます：&tag=checkout、&projectId=prj_abc123、&owner=<email>、&result=won,lost、&metricId=met_abc123、&implementationType=feature。tag、owner、result、metricId、implementationType はカンマ区切りの値を受け付けます（同じパラメーター内では OR 条件）。projectId はプロジェクト ID を1つだけ指定します。異なるパラメーター間は AND 条件になります。

   ユーザーがプロダクトテストの傾向を知りたい場合は、&bandits=false の追加を検討してください。バンディットの結果には勝敗の判定ではなくアームごとの確率が含まれるため、ステップ4の勝率集計が歪みます。

2. 停止した各実験の結果を取得します。停止した ID を順に処理します：

   gb-call GET /api/v1/experiments/<id>/results
   

   呼び出しの間隔を空けてください。API のレート制限は1分あたり60リクエストです。ユーザーが明示的に追加を希望している場合を除き、取得する実験は約20件までにしてください。パターンを見つけるには十分で、制限にも余裕があります。

3. パターンを読み取ります。 結果のペイロードから、提案を始める前に次の3点を特定してください：

   • うまくいっていること — テストのバリエーションが対照群を上回った実験に共通するテーマ（プロジェクト、対象領域、変更の種類）。
   • 停滞していること — 敗れた実験や結論が出なかった実験に共通するテーマ。
   • 十分に検証されていないこと — ほかと比べて実験が少ないプロジェクト、タグ、対象領域。

4. 簡単な集計情報を把握します。 ダッシュボード全体を提示する必要はありません。以下をおおまかに集計してください：

   • おおよその勝率（勝ち / 結果が確定した実験の合計）。
   • 主要指標の絶対リフトが大きい上位3件の勝者。
   • 絶対リフトが大きい上位3件の敗者。
   • SRM（サンプル比率の不一致）がフラグ付けされた実験。
   • プロジェクト / タグの分布。

5. 5〜7件のアイデアを提案します。 各提案には次の項目を含めます：

   • 仮説を1文で記載します：「Xを変更すれば、Yが改善します。なぜならZだからです。」
   • 根拠を1文で記載します。過去の特定の実験（展開する勝ちパターン、異なる方法で再試行する敗因、埋めるべき空白）とのつながりを説明します。実験名または ID を挙げてください。
   • 主要指標を1つ選びます。指標の種類（比例、平均、比率、分位点）と、その指標を選んだ理由を記載します。
   • 予想効果量は大まかな規模のみ記載します（「チェックアウトフローテストでの +3.2% のリフトに匹敵」など）。正確な数値は示しません。
   • 注意すべきリスクとして、ガードレール指標または悪化する可能性のある指標を1つ挙げます。

6. 構成を整えて提示します。 まず確認したパターンをそれぞれ1〜2行で示し、その後に提案を記載します。最後に、どの提案を掘り下げるかユーザーに尋ねてください。このスキル内で実験の設計や作成を始めてはいけません。ユーザーが選んだ提案については experiment-design に引き継ぎます。

ガードレール

• 停止済みの実験のみが対象です。 ドラフトと実行中の実験は、分析から除外してください。ユーザーがライブパイプラインについて尋ねた場合、それは別の質問です。代わりに flag-discovery または experiment-design を案内してください。
• result だけでは、停止済みであることを意味しません。 実験を停止すると結果が記録されますが、その後に再開されても結果は保持されるため、result=won で実行中の実験が返されることがあります。履歴の範囲を result に頼って絞り込まず、クエリには必ず status=stopped を含めてください。
• バンディットを絞り込むには type ではなく bandits を使います。 一覧エンドポイントには type パラメーターがありません。implementationType は、関連する変更の種類（feature ／ visualChange ／ redirect）を絞り込むものであり、レスポンスの type フィールド（standard ／ multi-armed-bandit）とは異なる軸です。type= を送信すると 400 が返されます。
• すべての提案に根拠を示してください。 参考にした具体的な過去の実験を挙げてください。一般的なベストプラクティスだけに基づく提案はしないでください。
• 敗北した実験を繰り返す場合は、その理由を明示してください。 最近敗北した実験を模倣する提案では、そのことを明言し、今回何が異なるのかを説明してください。
• 勝率の定義： won / (won + lost + inconclusive) です。別の計算式を作らないでください。
• 履歴内の SRM とガードレールの問題に注意してください。 多くの実験で SRM の失敗が見られる場合は、その点を伝え、別のプロダクトテストではなく、実験の品質向上を目的とするアイデアを少なくとも 1 つ提案してください。
• 提案はしても、作成はしないでください。 /api/v1/experiments に POST してはいけません。ユーザーは、提案のうち実施したいものを experiment-design に進めます。
• 指標を狙い撃ちする提案は避けてください。 各アイデアの目標指標は 1 つ（場合によっては 2 つ）です。指標が動くことを期待して 5 つの指標を設定するテストは提案しないでください。これは「目標指標が多すぎる」という落とし穴です。GrowthBook の意思決定フレームワークは最大 2 つの目標指標に対応していますが、それ以上では検出力が低下し、実施・中止の判断が曖昧になります。
• レート制限に注意してください。 実験 50 件と結果取得 20 件で約 21 回の呼び出しとなり、60 rpm の上限を大きく下回ります。ユーザーがさらに詳しい分析を希望する場合は、40 回を超える呼び出しを行う前に確認してください。

使用するエンドポイント

• GET /api/v1/experiments?limit=50&status=stopped&sortBy=dateCreated&sortOrder=desc — 停止済みの実験を新しい順に一覧表示します（limit の上限は 100 件）。任意の絞り込みフィルター：tag、owner、result、metricId、implementationType（カンマ区切りの値は、同一パラメーター内で OR 条件として扱われます）、projectId（単一のプロジェクト ID）、bandits（true ／ false）、archived。ソート可能なフィールド：dateCreated、dateUpdated、name。
• GET /api/v1/experiments/{id}/results — 対象範囲内の各停止済み実験について、全結果を取得します。停止済みの実験ごとに 1 回呼び出します。

出力テンプレート

## Patterns from your last N stopped experiments

- Working: <theme>
- Stalling: <theme>
- Under-explored: <theme>

## Proposed experiments

### 1. <short title>
- Hypothesis: …
- Grounded in: <past experiment + verdict>
- Primary metric: <name> (<type>)
- Expected effect: <order of magnitude>
- Risk: <guardrail>

…

Pick one or two and I'll hand off to `experiment-design` to scope it.