experiment-stop

experiment-stop

実行中の実験を停止します。必要に応じて勝者のバリエーションを宣言し、一時的なロールアウトを通じて対象となるすべてのトラフィックに適用できます。エンドポイントは POST /api/v1/experiments/<id>/stop です（汎用的な更新ではなく、専用のエンドポイントです）。すべてのバリエーション参照には、0 始まりの整数インデックスではなく、var_abc123 のようなバリエーション ID 文字列を使います。

すべての 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/<experiment-id>
   

   ユーザーが ID ではなく名前（「チェックアウトのテストを停止して」など）を指定した場合は、まず名前から特定します。q は名前、トラッキングキー、説明、仮説を照合し、status=running によって、このスキルで操作できる実験だけが候補になります。

   gb-call GET '/api/v1/experiments?q=checkout&status=running'
   

   該当する可能性のある実験が複数ある場合は、候補を提示してユーザーに選んでもらいます。推測で決めてはいけません。誤った実験を停止しても、完全には元に戻せません。

   status フィールドを確認します。このスキルで停止するのは running の実験のみです。status === "draft" の場合、実験はまだ開始されていません。ユーザーが望んでいるのは停止ではなく削除です（別の操作です）。status === "stopped" の場合、すでに完了しています。

   type フィールドも取得します。type === "multi-armed-bandit" の場合は処理を中止し、このスキルが対象とするのは標準的な A/B テストであることをユーザーに伝えます。バンディットには独自のライフサイクルがあり（停止操作は似ていますが、解釈やロールアウトが異なります）、スクリプトで操作する前に UI で確認するよう勧めてください。

2. バリエーションの表をユーザーに表示します。 API の記録どおりにバリエーションを示し、それぞれの variationId（var_treatment_a のような文字列 ID）と name を取得します。ユーザーはインデックスではなく、バリエーション ID 文字列で選択します。

   The experiment has these variations:
     var_control      0: Control       — <description>  (lift: baseline, users: N)
     var_treatment_a  1: Treatment A   — <description>  (lift: +2.3%, users: N)
     var_treatment_b  2: Treatment B   — <description>  (lift: -0.8%, users: N)
   
   Which variation should ship? Reply with the variation ID (e.g. var_treatment_a),
   or say "no winner" to stop without declaring.
   

   ユーザーがまだ experiment-analyze を実行していない場合は、情報に基づいて判断できるよう、先に実行することを提案します。

3. 一時的なロールアウトを行うか決めます。 勝者がいて、今すぐリリースしたい場合は、一時的なロールアウトの方法を提案します。

   「一時的なロールアウトも有効にしますか？これにより、この実験は SDK ペイロードに残り、対象となるトラフィックの 100% が <winnerVariationId> に割り当てられます。勝者をリリースする最もすっきりした方法です。リンクされたフィーチャーフラグのルールはそのままですが、全員が勝者に割り当てられます。後から modify-temporary-rollout で無効にするか、flag-targeting でルールを整理できます。」

   はいの場合、ペイロードで enableTemporaryRollout: true と releasedVariationId: <winner ID> を設定します。いいえの場合、実験は停止しますが、フラグには手を加えません。ユーザー自身で experiment-ref ルールを整理する必要があることを伝えてください。

4. 意図を確認します。 実行する操作を平易な言葉で言い直します。

   「実験『』を停止し、バリエーション var_treatment_a（Treatment A）を勝者と宣言して、一時的なロールアウトを有効にし、対象となるトラフィックの 100% に適用します。」

   送信する前に、明確な確認を得てください。停止自体は元に戻せます（再開できます）が、勝者の宣言とロールアウトの有効化は後続のシグナルを生むため、勘で実行してはいけません。

5. ペイロードを作成します。 ボディはフラットで、ネストされた resultSummary はありません。

   勝者を宣言せずに停止する場合：

   { "results": "inconclusive" }
   

   勝者を宣言して停止し、ロールアウトは行わない場合：

   {
     "results": "won",
     "winnerVariationId": "<winner variation ID>",
     "analysis": "<one-paragraph markdown summary of the decision>"
   }
   

   勝者を宣言して停止し、一時的なロールアウトでリリースする場合：

   {
     "results": "won",
     "winnerVariationId": "<winner variation ID>",
     "releasedVariationId": "<winner variation ID>",
     "enableTemporaryRollout": true,
     "analysis": "<one-paragraph markdown summary of the decision>"
   }
   

   フィールドリファレンス：

   • results — 必須です。"won"、"lost"、"inconclusive"、"dnf"（完了せず）のいずれかです。
   • winnerVariationId — 文字列のバリエーション ID（例：var_abc123）。results === "won" で、実験に複数のテストバリエーションがある場合に必須です。
   • releasedVariationId — 文字列のバリエーション ID。enableTemporaryRollout: true の場合に必須です。通常は winnerVariationId と同じです。
   • enableTemporaryRollout — ブール値です。停止した実験を SDK のペイロードに残し、トラフィックを releasedVariationId に強制的に振り分けます。
   • analysis — 実験結果ページに表示される Markdown の概要です。
   • reason — 最新フェーズのメタデータに保存される任意の理由テキストです。
   • dateEnded — 任意の ISO 日時です。デフォルトは現在時刻です。

6. 更新を送信します。

   echo '<payload-json>' | gb-call POST /api/v1/experiments/<experiment-id>/stop -
   

7. 次に何が起きるかを伝え、実験へのリンクを示します。 ユーザーに以下を伝えます。

   • 実験は停止しました。以降、実験に対するトラフィックは蓄積されません。
   • 勝者を宣言した場合は、「勝った」バリエーション ID。
   • 停止状態、記録された analysis、ロールアウトの状態を確認できる UI への直接リンク：

     <host>/experiment/<experiment-id>
     

     GB_API_URL の api. を app. に置き換えて <host> を導出します（experiment-launch の規則に準拠します。デフォルトのクラウドホストでは https://app.growthbook.io になります）。 フラグはどうなるか？ 送信内容に基づいて、フラグの状態を明確に伝えます。

   一時的なロールアウトあり（enableTemporaryRollout: true）： 勝者は適用中です。既存の実験参照ルールによって、トラフィックはすでに勝者に振り分けられています。チームがフラグを整理することを決めるまで、追加の操作は不要です（数日後、数週間後でもかまいません）。準備ができたら：

   • 恒久ルールに変換する： flag-rules で実験参照ルールを削除し、flag-targeting で勝者を適用する恒久的な強制ルールを追加します。
   • 完全にクリーンアップする： 機能をコードに直接埋め込む場合は、flag-cleanup を使ってコードのクリーンアップを進め、フラグをアーカイブまたは削除します。
   • ロールバックする： まず一時的なロールアウトをオフにし（echo '{"enableTemporaryRollout": false}' | gb-call POST /api/v1/experiments/<experiment-id>/modify-temporary-rollout -）、その後 flag-rules で実験参照ルールを削除します。

   一時的なロールアウトなし： 実験参照ルールはフラグに残り、停止した実験にトラフィックを振り分けています（ユーザーにはコントロール値が適用されます）。フラグの対応が必要です。

   • オプション A — 勝者をリリースする： flag-default-value で defaultValue を勝者の値に設定し、その後 flag-rules で実験参照ルールを削除します。または flag-targeting で勝者を適用する恒久的な強制ルールを追加し、その後、実験参照ルールを削除します。
   • オプション B — ロールバックする： フラグのデフォルト値ではすでにコントロールが適用されているため、flag-rules で実験参照ルールを削除するだけで、フラグは実験前の状態に戻ります。
   • オプション C — 完全にクリーンアップする： flag-cleanup を使って値をコードに直接埋め込み、フラグをアーカイブまたは削除します。

ガードレール

• winnerVariationId はバリエーション ID の 文字列（例：var_abc123）です。整数のインデックスでも、名前でも、バリエーションの key でもありません。 これを間違えると、リクエストが 400 エラーになるか、誤ったバリエーションが勝者として記録されます。
• エンドポイントは POST /api/v1/experiments/<id>/stop であり、POST /api/v1/experiments/<id> ではありません。 リクエストボディの形式はフラットで、resultSummary のラッパーはありません。汎用の更新エンドポイントもありますが、受け付けるフィールドが異なるため、ここでは専用の停止エンドポイントを使用してください。
• ユーザーが選んでいない勝者を決して宣言しないでください。 結果が明らかに見えても、ユーザーにバリエーション ID を選んでもらってください。結果は提示しますが、事前に入力してはいけません。これはスキル上の慣例であり、GrowthBook のポリシーではありません。API は任意のバリエーション ID を winnerVariationId として受け付けます。この安全策はサーバー側ではなく、ここで適用されます。
• ドラフトを停止しないでください。 draft の実験は実行中ではありません。その場合にユーザーが求めているのは DELETE /api/v1/experiments/<id> です（別のスキルであり、ここでは扱いません）。ドラフトの停止を求められた場合は、混同していることを伝えてください。
• すでに停止している実験を停止しないでください。 API はリクエストを受け付ける場合がありますが、実質的には何も起こりません。すでに停止済みであることをユーザーに伝えてください。停止済みの実験の結果メタデータを変更するには、新しい results ／ winnerVariationId ／ analysis を指定して再度投稿してください。
• バンディットは対象外です。 type === "multi-armed-bandit" の実験は異なる扱いが必要です。処理を中止して、その旨をユーザーに伝えてください。
• enableTemporaryRollout: true の場合、releasedVariationId は必須です。 これを指定しないと、API はこの組み合わせを拒否します。通常は winnerVariationId と同じですが、異なっていてもかまいません。たとえば、全員をコントロールに戻す「敗北」結果の場合は、results: "lost" とともに releasedVariationId: <control variation ID> を指定します。
• リンクされたフラグについて、必ず注意を促してください。 実験を停止しても、リンクされたフラグから experiment-ref ルールは削除されません。一時的なロールアウトを設定しない場合、ユーザーがルールを削除するまで、フラグは古い実験への振り分けを続けます。
• analysis には、判断の理由を平易な英語（Markdown）で説明してください。 将来これを読む人（未来の自分も含みます）には、その背景が必要です。勝者を宣言する際に空欄のままにしないでください。
• ユーザーがまだ実行していない場合は、先に experiment-analyze を実行してください。 ダッシュボードをざっと見ただけで停止を決めるのはよくある間違いです。途中経過の数値は変わる可能性があり、experiment-analyze のデータ品質チェックにより、結論が出たように見えても実際にはそうでない結果が検出されることがあります。
• q では否定や演算子を使うと 400 エラーになります。 一覧エンドポイントの q パラメーターはアプリの検索構文（status:running tag:checkout とフリーテキスト）を受け付けますが、!、~、^、>、<、= は拒否します。field:value 形式のトークンとフリーテキストだけを送信してください。
• 名前で検索する場合、type ではなく bandits でバンディットを除外してください。 レスポンスの type フィールド（standard ／ multi-armed-bandit）は一覧検索のクエリパラメーターではありません。type= を送ると 400 エラーになります。このスキルではバンディットを処理せず中止するため、候補一覧から除外するには bandits=false を追加してください。（implementationType は別の軸で、リンクされた変更の種類を示します。）

使用するエンドポイント

• GET /api/v1/experiments?q=<text>&status=running — ユーザーが名前またはキーワードだけを指定した場合に、実験 ID を特定します。q は名前、トラッキングキー、説明、仮説に一致します。
• GET /api/v1/experiments/<id> — 状態、バリエーション、type を取得します。
• POST /api/v1/experiments/<id>/stop — 実験を停止し、任意で勝者と一時的なロールアウトを宣言します。
• POST /api/v1/experiments/<id>/modify-temporary-rollout — このスキルを再実行せずに、停止後の一時的なロールアウトをオフ（またはオン）に切り替えます。

引き継ぎ

• experiment-analyze — 判断の前に結果を解釈したい場合は、最初に実行します。
• flag-rules — 停止後に実験参照ルールを削除します（最終的には必ず必要です）。
• flag-targeting — 勝者の値を提供する永続的な強制ルールを追加します（実験参照ルールを置き換えます）。
• flag-default-value — ターゲティングルールなしでリリースする場合、フラグのデフォルト値を勝者の値に設定します。
• flag-cleanup — 機能のリリースが完了し、コードからフラグを削除してアーカイブする場合に使用します。
• experiment-design と experiment-launch — 今回のテストを受けて次のテストを実施する場合に使用します。