ab-test-setup
作成者 coreyhaines31ab-test-setup は、チームの実験アイデアを Conversion 改善のための実行可能な A/B テスト計画に落とし込むためのスキルです。仮説の定義、A/B と A/B/n の選択、必要サンプル数と実施期間の見積もり、主要指標とガードレール指標の設定、さらに repo テンプレートを使った構造化テストブリーフの作成に役立ちます。
このスキルの評価は 78/100 で、A/B テストを構造的に設計したいユーザー向けのディレクトリ掲載候補として十分に有力です。リポジトリには明確なトリガー文言、実務に使いやすいワークフローガイダンス、有用な補足リファレンスが含まれており、汎用的なプロンプトよりもエージェントの応答品質向上が期待できます。一方で、これは実装を自動化するツール群ではなく、あくまで計画・設計を支援するスキルとして捉える必要があります。
- 高い起動しやすさ: 説明文に “A/B test”, “split test”, “which version is better”, “how long should I run this test” など、ユーザーが実際に使いそうな自然な表現が多く含まれています。
- 実務で使える内容: SKILL.md では仮説設計、テスト上の制約、実験の基本原則を扱っており、サンプルサイズの参考情報やテスト計画テンプレートへの導線もあります。
- evals による信頼性の裏づけ: product-marketing の文脈確認、指標定義、サンプルサイズへの対応、途中経過ののぞき見への注意喚起など、期待される挙動が evals で明示されています.
- 実装面の後押しは限定的: スクリプト、導入手順、ツール固有の実行方法は含まれていないため、計画を実務に落とし込むには依然としてエージェント側の判断が必要です。
- ワークフローの明示性はやや弱め: 構造シグナル上は workflow 0 となっており、段階的な実行手順の一部は明示ではなく推論に頼る可能性があります。
ab-test-setup スキルの概要
ab-test-setup は何に使うスキルか
ab-test-setup は、まだ曖昧な実験アイデアを、Conversion 改善で実際に走らせられるテスト計画へ落とし込むためのスキルです。特に、何をテストするか、どう設計するか、そして十分なトラフィックがあって学びを得られるかを判断したいマーケター、グロースチーム、プロダクトマーケター、PM に向いています。
ab-test-setup をインストールすべき人
次のような相談を定期的にするなら、ab-test-setup を入れておく価値があります。
- ヘッドラインや CTA の実験
- ランディングページや signup flow のテスト
- メッセージ変更やオファー変更のバリアント設計
- サンプルサイズ、実施期間、有意性に関する判断
- そもそもそのアイデアを A/B テストすべきかどうかの見極め
特に、チーム内にアイデア自体はあるものの、再現性のある実験ブリーフがない場合に有効です。
このスキルが本当に解決する仕事
テストが失敗する主因は、バリアントの発想が悪いことではありません。多くは設計の弱さです。仮説が曖昧、変更点が多すぎる、ベースラインがない、検出したい効果量が決まっていない、ガードレールもない。ab-test-setup skill は、そうした不足しがちな実験の基本を、公開前の段階で必ず押さえるように設計されています。
汎用プロンプトとの違い
汎用プロンプトでもテスト案は出せますが、ab-test-setup はより妥当な実験計画に寄せてくれます。
- 「とりあえず 2 案試す」ではなく、仮説から始める
- ベースライン CVR とトラフィックを確認する
- サンプルサイズとテスト期間を織り込む
- A/B、A/B/n、multivariate の違いを切り分ける
- peeking や検出力不足のリスクを警告する
- repo 内のテンプレートや sample-size 参照先に導く
向いているケース / 向いていないケース
向いているケース:
- どのページで、誰に、何を達成したいかがすでに明確
- 構造化されたテストブリーフを短時間で作りたい
- Conversion 実験用のプロンプト品質を上げたい
向いていないケース:
- まず instrumentation や event tracking の設計が必要
- テスト計画なしでページ改善の文案だけ欲しい
- トラフィックがかなり少なく、正式なテスト以外の打ち手を考える必要がある
ab-test-setup スキルの使い方
skills 環境に ab-test-setup をインストールする
ディレクトリ標準の install パターンに従って、以下を使います。
npx skills add https://github.com/coreyhaines31/marketingskills --skill ab-test-setup
インストール後は、次のファイルを開いてください。
skills/ab-test-setup/SKILL.mdskills/ab-test-setup/references/sample-size-guide.mdskills/ab-test-setup/references/test-templates.mdskills/ab-test-setup/evals/evals.json
この 4 つは、ざっと眺めるだけでは足りません。想定されている意思決定フロー、出力形式、求められる品質水準がここに出ています。
最初に読むべきファイル
ab-test-setup を使う前に 3 ファイルしか読めないなら、優先度は次の順です。
- トリガー条件と設計ロジックを確認する
SKILL.md - 実現可能性と期間判断を見る
references/sample-size-guide.md - モデルに出してほしい最終形を確認する
references/test-templates.md
そのうえで evals/evals.json を見ると、現実的なプロンプトに対してこのスキルがどんな回答を「良い」と見なしているかがわかります。
ab-test-setup に必要な入力
次の情報を渡すと、スキルの精度はかなり上がります。
- テスト対象のページまたは機能
- 主要な conversion event
- 現在のベースライン CVR
- 月間または週間のトラフィック量
- 予定している変更内容
- 対象オーディエンス
- ツールや実装の制約
- 期限や公開ウィンドウ
- false positive に対する許容度
ベースラインとトラフィックがないと、ab-test-setup usage はどうしても一般論寄りになり、意思決定に使える度合いが下がります。
可能なら product marketing context から始める
repo では、まず .agents/product-marketing-context.md または .claude/product-marketing-context.md を確認するよう明示されています。これは重要です。良い実験設計は、次の文脈に強く依存するからです。
- オーディエンス
- ポジショニング
- コアとなる訴求
- 現在のメッセージ戦略
- ファネル上の段階
もしそのファイルが環境内にあるなら、モデルが発見的な質問を何度も繰り返す前に、先に読ませておくのが得策です。
ラフなアイデアを、強い ab-test-setup プロンプトに変える
弱いプロンプト:
We want to test our homepage headline. What should we do?
より良いプロンプト:
Use
ab-test-setupto plan an A/B test for our homepage headline. Current headline: "The All-in-One Project Management Tool." Proposed direction: more benefit-focused messaging for SaaS team leads. Baseline signup rate is 3.2%. We get about 15,000 homepage visitors per month. Primary goal is signup rate. We can implement one variant only, 50/50 traffic split, in our existing testing tool. Please create a hypothesis, recommend test type, estimate sample needs and likely duration, define primary/secondary/guardrail metrics, and flag risks like peeking or low power.
後者のように書くと、単なるブレストではなく、実行可能な計画を出すのに十分な文脈を ab-test-setup に渡せます。
実際に必要な出力形式を指定する
参照ファイルには再利用しやすいテンプレートがあるので、次のような形式を指定すると便利です。
- 承認用の experiment brief
- launch checklist
- test plan template
- stakeholder update
- post-test readout shell
実用的なプロンプト例:
Use the test plan template format from
references/test-templates.mdand fill only fields we can support with the data provided. Mark missing assumptions clearly.
こうしておくと後処理が減り、足りない入力も早い段階で見えやすくなります。
アイデア出しだけでなく、意思決定に使う
最も実用的な ab-test-setup guide の使い方は、次の順番です。
- 提案中の変更を説明する
- ビジネス上の目標を明示する
- ベースラインとトラフィックを出す
- そのテストが成立するか確認する
- 必要な指標と実施条件を詰める
- そのあとで初めてバリアント案を求める
この順序には意味があります。十分なサンプルサイズに届かないテストに、先に工数をかけすぎるのを防げます。
ab-test-setup が守らせる中核ルールを理解する
ソース上で、このスキルが強く重視しているのは次の点です。
- 明確な仮説から始める
- 1 回のテストで 1 つのことを検証する
- primary / secondary / guardrail metrics を定義する
- サンプルサイズと最低実施期間を見積もる
- ノイズの多い初期勝ちで早期終了しない
組織内でこうした管理なしに「とりあえず quick test」を回しがちなら、このスキルの価値は大きいです。
Conversion 業務で ab-test-setup を使う方法
ab-test-setup for Conversion では、バリアント案だけでなく、ビジネス上の重みも一緒に渡してください。良い入力の例は次の通りです。
- 現在の conversion ボトルネック
- いまのページが伸びないと考える理由
- 何が変化のメカニズムになる想定か
- 実務上、意味があると見なせる最小リフト
- 悪化させてはいけないセグメント
例:
We think our pricing page CTA underperforms because it asks for commitment too early. Plan an A/B test comparing "Start Free Trial" vs "See Plans First." Baseline click-through is 6.8%, downstream trial-start rate is 2.1%, and pricing page traffic is 40,000 sessions/month. We care most about completed trial starts, not just button clicks. Include guardrails so a CTR lift does not hide lower-quality signups.
このような依頼のほうが、単にボタン色テストを頼むよりも、適切な指標設計につながります。
このスキルがあなたの案に待ったをかける場面
ab-test-setup が最も役立つのは、次のように“止めてくれる”ときです。
- これは multivariate にすべきではない
- 4 バリアントを回すにはトラフィックが足りない
- その MDE は現実的に小さすぎる
- primary metric が変更内容から遠すぎる
- 変更点を詰め込みすぎて因果的に学べない
この押し返しは摩擦ではなく、機能です。
repo に裏づけられた代表的なユースケース
スキル本文と evals を見る限り、相性が良い使い方は次の通りです。
- homepage headline の A/B テスト
- pricing / signup ページの CTA バリアントテスト
- A/B/n が現実的かどうかの判断
- トラフィックとベースラインからの期間設計
- 実験ローンチ向けの構造化ドキュメント作成
evals からは、「CTA の色を 4 パターン試すべき?」のような軽い相談でも、より筋の良い実験設計へ誘導することが期待されているとわかります。
ab-test-setup スキル FAQ
ab-test-setup は初心者にも向いている?
はい。少なくとも対象ページと目標が自分で把握できているなら有用です。初心者が抜かしがちな仮説、サンプルサイズの考え方、指標設計、実施期間の観点を補ってくれます。一方で、統計の基礎から学びたい人向けの入門教材そのものではありません。
普通のプロンプトより何が一番いい?
最大の利点は制約をかけてくれることです。ab-test-setup はバリアントを出すだけでなく、そのテストを実施する価値があるか、妥当な測定に何が必要かまで枠組み化します。多くの場合、単なるアイデア出しよりこちらのほうが時間短縮につながります。
トラフィックや CV データは正確でないとダメ?
正確なのが理想ですが、おおよその値でも使えます。ラフな見積もりしかない場合は、その前提を明記してください。スキルは計画のたたき台を作れますが、sample-size や期間の助言に対する確信度は下がります。
ab-test-setup は 2 案以上のバリアントにも対応できる?
できます。ただし、バリアント数が増えるほど必要サンプルも増える点は警告されるはずです。トラフィックがそこまで多くないなら、A/B/n や multivariate より、通常の A/B のほうが実務的なことは少なくありません。
ab-test-setup を使わないほうがいいのはどんなとき?
次のような場合、主力ツールとして使うのはおすすめしません。
- tracking がない、または信頼できない
- 意味のある推定ができるほどトラフィックがない
- 必要なのが test plan ではなく CRO rewrite
- 変更規模が大きく、真のボトルネックが実装可能性にある
- まず analytics instrumentation の設計が必要
このスキルは特定のテスト基盤に依存する?
そのような platform lock-in を示す記述は見当たりません。ab-test-setup は計画中心のスキルなので、traffic split、metrics、実装制約を明示できるなら、多くの experimentation tool で使えるはずです。
ab-test-setup はテスト後の分析にも役立つ?
ある程度は役立ちます。テンプレートには結果ドキュメントも含まれていますが、最も強い価値はやはり事前設計です。テスト開始前に「何を成功とみなすか」を定義する用途で使うのが中心です。
ab-test-setup スキルを改善する方法
バリアント依頼だけでなく、仮説を強くする
悪い入力:
Test this new copy against the old copy.
より良い入力:
Because users may not understand our current value proposition quickly, we believe replacing feature-led copy with outcome-led copy will increase signup starts among first-time visitors. We will measure signup rate as the primary metric and bounce rate plus demo-request rate as secondary checks.
この書き方なら、ab-test-setup は単に 2 つの文案を比べるのではなく、因果ストーリーのある検証計画として扱えます。
最低限必要な実験データを渡す
ab-test-setup の出力品質を上げたいなら、できるだけ次を含めてください。
- ベースライン CVR
- トラフィック量
- 意味のある最小リフト
- 正確な conversion event
- オーディエンス
- 実装上の制約
- 許容できるテスト期間
これらは sample-size ロジックと実現可能性判断を直接改善します。
ありがちな失敗パターンを避ける
出力が弱くなる原因は、たいてい次のどれかです。
- 変更点を 1 テストに詰め込みすぎている
- ベースライン指標がない
- vanity metric を primary KPI にしている
- トラフィックの現実を無視して有意性だけ求めている
- 本当のビジネス目標は下流にあるのに、上流の micro-metric を検証している
これらをプロンプト前に修正するだけで、スキルの実用性はかなり上がります。
悪化させてはいけない指標を伝える
より強い ab-test-setup skill のプロンプトには、次のような guardrail を入れておくと効果的です。
- lead quality
- refund rate
- bounce rate
- activation rate
- revenue per visitor
これにより、表面上のトップライン指標は伸びても、事業品質が落ちる“偽の勝ち”を防ぎやすくなります。
sample-size 参照を実現可能性フィルターとして使う
バリアントを考える前に、references/sample-size-guide.md を確認してください。ここで次の判断がしやすくなります。
- このテストは現実的な期間で終わるか
- 望んでいるリフトは小さすぎて検出困難ではないか
- バリアント数を減らしたほうが賢明ではないか
- 微調整ではなく、もっと大きな変更にしたほうがよいか
インストール判断の観点でも、このファイルは repo 内で特に価値の高いものの一つです。
フリーフォーム出力ではなくテンプレートを再利用する
references/test-templates.md は、チーム内に定着させる最短ルートです。モデルには次のようなテンプレートを埋めさせると運用しやすくなります。
- test plan
- prioritization scorecard
- stakeholder update
- hypothesis bank entry
自由形式の回答は出しやすい一方で、実務に載せるには整形コストがかかりがちです。
初稿のあとに 1 回は磨き込む
最初の ab-test-setup usage のあと、1 ラウンドだけでも再調整してください。
- 仮説を絞り込む
- 変数を 1 つに絞る
- あいまいな指標を運用可能な定義に置き換える
- traffic split と期間を確認する
- まだ欠けている前提が何かを確認する
この 2 回目の調整は、バリアント案をさらに増やすよりも、計画の質を大きく上げることがよくあります。
ab-test-setup と隣接スキルは役割を分けて使う
スキル自体が、近接する課題として次を挙げています。
- 測定設計がボトルネックなら
analytics-trackingを使う - 正式なテスト前にページ改善案が必要なら
page-croを使う
この切り分けは実務的です。ab-test-setup が最も力を発揮するのは、「何を評価したいか」は見えていて、あとは妥当な実験計画に落としたい段階です。
