experiments

実験

GrowthBook の実験と、そこから抽出された永続的な学びを扱うドメインルーターです。各ワークフローは references/ 内のリファレンスファイルにあります。このルーターを読み、ユーザーの状況に合ったワークフローを選び、そのファイルを読んで手順に従ってください。

実験では v1 API（/api/v1/experiments）を使用します。ワークフローでフィーチャーフラグも扱う場合、フラグの呼び出しには v2 を使用します。どちらを使うかはリファレンスファイルに記載されています。

すべての API 呼び出しは、同梱のヘルパーを経由します。Claude Code プラグインをインストールしている場合は ${CLAUDE_PLUGIN_ROOT}/scripts/gb-call（プラグインのルート）にあります。npx skills install を使用している場合は、このスキルのディレクトリを基準にした scripts/gb-call にあります。そのパスを一度解決し、リファレンスの例で gb-call と記載されている箇所では、毎回そのパスに置き換えてください。gb-call が PATH にあるとは想定しないでください。ヘルパーはまず環境変数から GB_API_KEY を読み込み、次に ~/.config/growthbook/.env（gb-setup が作成）を参照します。環境変数が優先されます。

ワークフローで GrowthBook の UI リンクを提示する必要がある場合、シェルを使用できるランタイムでは、会話ごとに一度 gb-call app-origin を呼び出し、返された信頼できるオリジンをワークフロー間およびドメイン間の引き継ぎにわたって保持し、リファレンスファイル内のルート相対 UI パスの先頭に付けてください。オリジンがすでにコンテキストにある場合は再利用し、リンクごとにコマンドを呼び出さないでください。信頼できるアプリのオリジンをすでに把握している埋め込みアダプターまたは MCP アダプターでは、同じパスを直接解決できます。GB_API_URL からアプリのオリジンを決して導出しないでください。セルフホスト構成が不完全なために app-origin が拒否された場合は、gb-setup に案内してください。

ワークフローを選ぶ

実験のライフサイクルは、ブレインストーミング → 設計 → 開始 → 分析 → 停止です。learnings は、過去の知見を確認する場合は設計の前に、分析後に永続的な結論を裏付ける証拠がある場合は分析の後に行います。

これらのワークフローは type: "standard" の実験を対象としています。GrowthBook の REST API はマルチアームド・バンディット実験と、別個の Enterprise ベータ版 Contextual Bandit リソースにも対応していますが、ここではどちらのライフサイクルも実装されていません。バンディットのいずれかについて依頼された場合は、その種類を正確に特定し、GrowthBook UI を案内してください。標準実験のワークフローを適用しないでください。

読むファイル	ユーザーの要望
references/experiment-brainstorm.md	過去に停止した実験を根拠に、テストするアイデアを得る（提案のみ）
references/experiment-design.md	アイデアを開始可能な仕様にまとめる — 仮説、バリエーション、指標、サンプルサイズ（書き込みなし）
references/experiment-launch.md	実験を作成し、フラグを準備または再利用し、experiment-ref ルールを設定して開始する
references/experiment-analyze.md	結果を確認する — 古い場合はスナップショットを更新してから解釈する（読み取り専用）
references/experiment-stop.md	実行中の実験を停止し、必要に応じて勝者を宣言して展開する
references/learnings.md	過去の結論を検索して読む。または、実験をまたいで厳選された学びを作成、更新、削除する

ユーザーにアイデアはあるものの仮説がない場合は、experiment-design から始めてください。アイデアに根拠を持たせる必要がある場合は、そこから experiment-brainstorm に案内されます。ユーザーが ID ではなく名前を提示した場合、experiment-analyze と experiment-stop のどちらも、名前から解決する手順で始まります。

方法論の基準

references/experiment-launch.md は GrowthBook のデータサイエンス責任者が直接執筆したもので、統計的な枠組み、仮説の立て方、目標指標の数、ガードレール要件についての基準となる見解です。別のリファレンスファイルの方法論がこれと異なるように見える場合は、experiment-launch に従い、相違を指摘してください。一般的な A/B テストの直感から判断して、このような食い違いを解決しないでください。GrowthBook のデフォルトは独自のものであり、デフォルトではベイズ方式、ガードレールに対する多重比較補正なし、逐次検定では区間が広がる、となっています。

このルーターには、意図的に独自の統計的ガイダンスを記載していません。解釈のルールはリファレンスファイルに記載されています。

共通規則

• メトリクスは事前に存在している必要があります。 ここで紹介するワークフローでは、メトリクスは作成されません。メトリクスがない場合は、まずユーザーがGrowthBookのUIで作成します。参照ファイルに作成場所が記載されています。
• メトリクスは実験のデータソースに属している必要があります。 そうでない場合、実験のPOSTは失敗します。
• 作成時にtemplateIdとdatasourceId／assignmentQueryIdを併用しないでください。
• winnerVariationIdはバリエーションIDの文字列です（例：var_abc123）。整数のインデックスでも、バリエーション名でもありません。
• 名前による検索ではqを使用します。 名前、トラッキングキー、説明、仮説が一致対象になります。!、~、^、>、<、=を含むと400エラーになります。プレーンなfield:value形式のトークンとフリーテキストを送信してください。バンディットの絞り込みにはtypeではなくbanditsを使用してください（typeはリスト用パラメーターではなく、implementationTypeは別の軸です）。
• resultは記録された結果で、再起動後も保持されます。 そのため、result=wonで実行中の実験が返される場合があります。status=stoppedと組み合わせてください。
• 実験一覧のlimitの上限は100です。
• ユーザーには実験名を表示し、UIパス/experiment/<id>へのリンクを付けてください。 生のIDだけを表示しないでください。
• UIリンクはルート相対パスです。 GB_API_URLからGrowthBookのUIのオリジンを推測してはいけません。APIとUIで同じホスト名を共有しているとは限りません。信頼できるアプリのオリジンがある実行環境では、そのパスを解決できます。それ以外の場合は推測せず、ルート相対パスを表示してください。
• Learningコーパスが空でも、実験記録が空とは限りません。 チームに過去のエビデンスがないと結論づける前に、停止済み実験の履歴を確認してください。

読み取り専用と書き込み

experiment-brainstorm、experiment-design、experiment-analyzeは書き込みを行いません。ブレインストーミングと設計は提案のみであり、実験を作成するためにPOSTしてはいけません。また、分析で実験を停止したり変更したりしてはいけません。experiment-launchとexperiment-stopは実験の状態を書き込みます。learningsの検索／一覧表示の各パスは読み取り専用です。作成、更新、削除の各パスでは、書き込みの直前に明示的な確認が必要です。

負荷制限

GrowthBookのレート制限は毎分60リクエストです。experiment-brainstormはページ分割された履歴を複数回取得し、experiment-analyzeは明示的に設定された試行回数の上限内で、ポーリングの間にsleepを挟みながらスナップショットの完了を待ちます。どちらの上限も維持してください。これにより、利用の多い組織がレート制限に達するのを防げます。

引き継ぎ先

• feature-flagsスキル — フラグ自体に関すること：作成、ターゲティングルール、ロールアウト、ドラフトの公開、テストのリリース後のクリーンアップ。
• analyticsスキル — 設計前にカタログからメトリクスを選ぶことや、実験の結果表示ではないプロダクトデータをグラフ化すること。
• gb-setup — gb-callがGB_API_KEYの欠落または無効を報告した場合。