mcpField
A
ab-test-planner

ab-test-planner

github.com/mohitagw15856データ・データベース1.5k52 回インストール5 日前に更新
リポジトリ

ab-test-planner について

ab-test-plannerは、プロダクトチーム向けにA/Bテストを設計するスキルです。仮説、指標、サンプルサイズ、期間、結果の解釈を扱い、統計的な妥当性とガードレール指標、事前の判断基準を重視します。

主な機能

  1. 01方向性のある仮説の作成
  2. 02主指標とガードレール指標の選定
  3. 03必要サンプルサイズの算出
  4. 04テスト期間の見積もり
  5. 05結果解釈のガイド
  6. 06ロールバック条件の設定

活用シーン

  1. 01機能やUI変更のテスト計画
  2. 02有意差に必要なトラフィックの見積もり
  3. 03テスト結果への対応方針の事前合意

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/mohitagw15856/pm-claude-skills --skill ab-test-planner

インストール後、Claude Code で/ab-test-plannerを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

references/
test-validity-traps.md
worked-example.md
templates/
test-plan.md

詳細

A/B テストプランナースキル

方向性を示すだけでなく、信頼できる結果を生み出す実験を設計します。すべてのテスト結果には、仮説、成功指標、サンプルサイズ、期間、結果の解釈ガイドが含まれます。

必要な入力

与えられた情報をもとに作業してください。以下の項目に不足がある場合も、完全な出力を作成し、各不足を妥当な仮定で補って (仮定、要確認) と記し、最後に仮定を列挙してください。質問を先にするのは、中心となる題材自体が不足している場合(書く内容が何もない場合)に限ります。

  • テスト対象(機能、UI の変更、コピー、価格設定、オンボーディングのステップ)
  • 仮説(または、仮説の策定を依頼する)
  • 主要指標(コンバージョン率、クリック率、完了率など)
  • ベースライン率と最小検出可能効果(MDE)
  • 1 日あたりの対象ユーザー数(期間の算出に使用)

実験設計チェックリスト

テストを実施する前に、以下を確認してください。

  • 予測する方向が明確な仮説
  • 単一の主要指標(加えてガードレール指標は最大 2 つ)
  • 最小検出可能効果(MDE)が定義されている
  • サンプルサイズが算出されている
  • テスト期間が推定されている
  • セグメントが分離されている(他の実施中のテストと重複しない)
  • ロールバック計画が定義されている

仮説テンプレート

「[データまたはインサイトに基づく根拠] により、[変更] によって [ユーザーセグメント] の [主要指標] が [X%] [増加/減少] すると考えています。」

方向性を示す仮説なしにテストを実施しないでください。「とりあえず結果を見てみよう」は仮説ではありません。

サンプルサイズ計算ロジック

この計算式を使用してください(計算式ではなく、出力結果をユーザーに提示してください)。

  • ベースラインコンバージョン率: 主要指標の現在の率
  • MDE: 検出する価値のある最小の変化(ほとんどの機能では、相対的な上昇率 10~20% を推奨)
  • 検出力: 80%(標準)
  • 有意水準: 95%(p < 0.05)

一般的なシナリオについては、事前に計算した推定値を提示してください。

ベースライン率MDE(相対値)バリアントごとに必要なサンプル数
5%20%~19,000
10%15%~14,000
20%10%~15,000
40%10%~9,500
60%5%~42,000

必ず次の注意書きを添えてください。「これらは推定値です。正確な値を求めるには、Evan Miller の計算ツールや Statsig などを使用してください。」

テスト期間のガイダンス

最短:2 週間(曜日による季節性を捉えるため) 最長:4 週間(これを超えると新奇性効果によって結果が歪みます)

Duration = Required sample ÷ (Daily traffic × % exposed)

有意差を得るまでに 8 週間以上かかるほどトラフィックが少ない場合は、その旨を示し、別のアプローチ(例:ホールドアウトテスト、定性調査)を推奨してください。

出力形式

A/B テスト計画 — [テスト名] — [日付]

仮説:

[記入済みの仮説テンプレート]

バリアント:

  • コントロール(A):[現在のエクスペリエンス]
  • トリートメント(B):[変更後のエクスペリエンス — 具体的に記載]

主要指標: [指標名+測定方法] ガードレール指標: [悪化してはならない指標]

対象セグメント: [テストを表示する対象 — トラフィックに占める割合、ユーザータイプ] トラフィックの割り当て: [立ち上げ時の調整が必要でなければ 50/50 を推奨]

必要なサンプルサイズ: バリアントあたり約 [N] ユーザー 推定期間: [Y] 人の 1 日あたりの対象ユーザー数に基づき [X] 週間 有意水準: 信頼度 95%、検出力 80%

除外対象: [除外するユーザーセグメントとその理由]

ロールバックの条件: [ガードレール指標] が [X%] 悪化した場合、直ちにテストを停止します。

結果の解釈ガイド:

  • ✅ リリースする条件:トリートメントで主要指標が [X%] 以上向上し、信頼度 95% で有意であり、かつガードレール指標が安定している
  • 🔄 改善を続ける条件:方向性はプラスだが有意ではない — 期間の延長または設計の見直しを検討する
  • ❌ 却下する条件:有意水準において向上がない、またはマイナスの方向性が見られる
  • ⚠️ 結論が出ない場合:リリースしないでください。成功と判断しないでください。

ガイドライン

  • テストが計画したサンプルサイズに達する前に結果を確認しないよう、必ず推奨してください。pハッキングのリスクを説明してください
  • 複数のバリエーションをテストしたいというユーザーには、多重比較の問題を説明し、ボンフェローニ補正またはベイズ手法を推奨してください
  • トラフィックが非常に少ない場合(1日あたり1,000ユーザー未満)は、モデレーター付きテスト、5秒テスト、ユーザーインタビューなどの定性的な代替手段を推奨してください
  • ガードレール指標のないテストは決して承認しないでください。収益、継続率、またはコアエンゲージメントを必ず保護してください

アンチパターン

  • 方向性のある仮説なしにテストを実施しないでください。「どうなるか見てみましょう」では、結果を解釈できません
  • 事前に計画したサンプルサイズに達する前に勝者を決めないでください。結果を途中で確認すると、偽陽性率が上昇します
  • 1つのバリエーションに複数の独立した変更を含めてテストしないでください。どの変更が結果の原因なのか分からなくなります
  • 目標が収益や継続率の場合、エンゲージメント指標(クリック数、ページ滞在時間)を主要指標として使わないでください。代替指標は誤解を招きます
  • ガードレール指標を無視しないでください。サポート問い合わせが急増するコンバージョンの向上は、成功ではありません

詳細資料

このスキルには補助ファイルが付属しています。利用可能な場合は使用してください。

  • references/test-validity-traps.md — A/Bテストをひそかに無効にする妥当性の落とし穴です。出力の作成中に適用してください。上記の手法の概要で省略されている判断基準と調整方法が記載されています。
  • templates/test-plan.md — 品質ゲートが明記された、記入式の成果物テンプレートです。ユーザーが文書の生成を依頼するのではなく、自分で作成したい場合に提示してください。

スコアリング基準(0~40)

このスキルの出力は、引き渡す前にスコアリングしてください。32点以上が出荷品質です。

項目0510
統計的厳密さサンプルサイズが示されていない、または根拠となるベースラインやMDEが示されていない数値が示されているサンプルサイズは示されているが、MDEが推測値であるか、実際のベースラインを確認せずに参照表から転記されている。検出力や有意水準が示されていない明示されたベースラインとMDEに基づいて、検出力80%/信頼度95%でサンプルサイズが算出されている。実際の日次トラフィックと2~4週間の期間に照らして所要期間が確認され、条件を満たせない場合は低トラフィック時の代替手段が適用されている
仮説の規律「どうなるか見てみましょう」――方向性も効果量もなく、複数の変更が1つのバリエーションにまとめられている方向性のある仮説はあるが、効果量、セグメント、または根拠に基づく「なぜ」が不足している。バリエーションの純度も確認されていないテンプレートの全項目が記入されている(変更、指標、方向性、効果量、セグメント、データを根拠とする理由)。処置では変更を正確に1つだけ分離し、除外したアイデアを後続のテストとして明記している
ガードレールとロールバックガードレール指標がない、または閾値のないロールバック条件が示されているガードレールは示されているが、分母や定義が曖昧。ロールバックのトリガーも「状況が悪ければ」のように曖昧収益またはコアエンゲージメントを保護するガードレールが1~2個あり、事前に合意した定義と具体的なロールバック閾値が示されている。結果の途中確認と、被害を検知するための監視の違いも明示的に扱われている
意思決定の準備状況解釈の指針がなく、結果が出てから議論になる出荷/改善/却下は列挙されているが、閾値が曖昧。結論が出ない場合の扱いが抜けているか、実質的な成功として扱われている4つの結果(出荷/改善/却下/結論保留)すべてが、事前に合意した閾値に対応付けられている。結論保留のコストと、各結果によって次に何を変えるかも含まれている

品質チェック

  • 仮説に方向性がある(「どうなるか見てみる」ではなく、具体的な方向と効果量を予測している)
  • 主要指標が1つに絞られている(ガードレール指標は副次指標)
  • 実際のMDEとベースラインからサンプルサイズが算出されている(推測ではない)
  • テスト期間で週次の季節性を考慮している(最低2週間)
  • ガードレール指標が定義されている(収益またはコアエンゲージメントを保護する指標を少なくとも1つ含む)
  • 具体的な閾値を伴うロールバックのトリガーが指定されている

トリガーフレーズの例

  • 「実験を設定してください。」
  • 「A/B テストを設計してください。」
  • 「サンプルサイズを計算してください。」
  • 「テスト結果を解釈してください。」

コメント