ab-test-setup

概要

ab-test-setup とは？

ab-test-setup は、本番公開前の段階で厳密な A/B テストや多変量テストを設計するためのスキルです。AIアシスタントが実験設計のスペシャリストとして動けるようにし、テストの目的整理、強い仮説の作成、適切な指標の選定、サンプルサイズと実施期間の計画までを、構造化されたリファレンスに沿ってガイドします。

いきなりスプリットテストを走らせるのではなく、ab-test-setup を使うことで、統計的に有意でビジネスに活かせる結果が得られる、堅実なテスト計画を事前に作成できます。単なる「ノイズ」で終わらない実験設計を支援します。

このスキルは誰向け？

以下のような方に ab-test-setup は適しています：

• ランディングページ、オンボーディングフロー、料金ページなどで実験を計画している グロース／プロダクトマーケティングチーム。
• 広告、キャンペーンクリエイティブ、ファネルを最適化する際に、統計的に信頼できるテストが必要な パフォーマンスマーケター。
• 重要ページで見出し、レイアウト、CTA などをテストしたい SEO・コンテンツチーム。
• 実験をサポートし、整った一貫性のある計画フレームワークを求める 開発者やプロダクトマネージャー。

テストせずにコピーやレイアウトのアイデアだけ欲しい場合は、このスキルはやりすぎです。その場合は、コンテンツ系や CRO 系のスキルを利用してください。

ab-test-setup はどんな課題を解決する？

このスキルは、ユーザーが次のようなことを言う状況を想定して設計されています：

• 「ホームページのヘッドラインで A/B テストをしたい。」
• 「この要素で多変量テストをしたほうがいい？」
• 「どのバージョンが良いのか、どうテストすればいい？」
• 「この実験はどのくらいの期間、実施すべき？」
• 「このトラフィック量でテストは成立する？」

ab-test-setup は次のようなポイントにフォーカスします：

• コンテキストの明確化：何を改善したいのか、現在のパフォーマンス、制約条件は何か。
• 構造化されたフレームワークで強い仮説を構築。
• トラフィックと目的に基づいて テストタイプ（A/B vs. A/B/n vs. multivariate）を選定。
• 同梱の sample-size guide を使った サンプルサイズとテスト期間の計画。
• ビジネス目標に直結する 指標の定義（主要指標、副次指標、ガードレール指標）。
• トラフィックが少ないのにバリエーションを増やし過ぎる、途中で結果を見て早期判断してしまう（“peeking”）などの よくある落とし穴の回避。

トラッキング実装には analytics-tracking スキルを、ページ単位の コンバージョン改善アイデアには page-cro を ab-test-setup と併用してください。

ab-test-setup が適している場面

このスキルは次のような場面に向いています：

• 複数のアプローチを比較し、どちらがより成果を出すか定量的に測りたいとき。
• 意味のある A/B テストを実施できるだけの 十分なトラフィックがある、または見込めるとき。
• 統計的有意性や「誤った勝ち」を避けることを重視するとき。
• 複数のステークホルダーに、わかりやすく文書化されたテスト計画を共有したいとき。

逆に、次のようなケースではあまり向いていません：

• 極端にトラフィックが少ないなど、現実的に有意な A/B テストが難しいとき。
• 計測する予定のない 単発のデザイン変更を行うだけのとき。
• 分析基盤のセットアップやイベント計測だけが必要なとき（その場合は analytics-tracking を使用）。

使い方

インストール

skills CLI を使って、エージェント環境に ab-test-setup をインストールします：

npx skills add https://github.com/coreyhaines31/marketingskills --skill ab-test-setup

インストール後は、次のステップに進みます：

1. エディタやファイルビューアで skills/ab-test-setup ディレクトリを開きます。
2. まずは SKILL.md を読んで、アシスタントがどのように A/B テスト計画に取り組むべきかを把握します。
3. references/ と evals/ フォルダを確認し、補助資料と期待される挙動を理解します。

主要ファイルとフォルダ

効率よく価値を得るには、次のファイルに重点的に目を通してください：

• SKILL.md – 中核となるインストラクションです。実験思考の考え方、初期ヒアリングの質問、仮説から始めること・一度に 1 つの変更に絞ることなどの基本原則を定義しています。
• references/sample-size-guide.md – サンプルサイズの計算・見積もりのガイドライン、Minimum Detectable Effect (MDE) の考え方、テスト期間の計画方法をまとめています。
• references/test-templates.md – テスト計画、結果ドキュメント、ステークホルダーへの共有に使えるテンプレート集です。
• evals/evals.json – 実際の利用シナリオにおいて、このスキルがどのように振る舞うべきかを示すサンプルプロンプトと期待アウトプットです。

これらをリファレンスとして、エージェントの設定や、社内の実験ドキュメントの構造を合わせる際に活用できます。

ab-test-setup を使った一般的なワークフロー

このスキルは、繰り返し使える実験ワークフローに基づいて設計されています。

1. コンテキストを収集する

ユーザーが A/B テストを依頼したら、まずエージェントは次の点を把握します：

• テストのコンテキスト – どのページ／機能／チャネルをテストするのか？どんな変更を検討しているのか？
• 現在の状態 – ベースラインのコンバージョン率や主要指標、現在のトラフィック量。
• 制約条件 – 技術的制限、実装の難易度、スケジュール、利用ツール（例：Optimizely、Google Optimize の代替、社内フレームワークなど）。

リポジトリにある product-marketing-context.md のような共通のプロダクトマーケティングコンテキストファイルがある場合、エージェントはまずそれを読み、足りない情報やテスト固有の情報だけを質問します。

2. 強い仮説を定義する

ab-test-setup では、evals/evals.json と references/test-templates.md で示されている、構造化された仮説フォーマットを推奨しています：

Because [observation], we believe [change] will cause [outcome], which we'll measure by [metric].

実際の運用では、エージェントは次のように動きます：

• 「ベネフィット訴求のヘッドラインを試す」などの曖昧なアイデアを、具体的な予測に落とし込みます。
• 各仮説を データや明確な観察結果（アナリティクス、リサーチ、ユーザーフィードバックなど）に結びつけます。
• 成果を 主要なビジネス指標（例：サインアップ率、Add to Cart率）に直接紐づけます。

3. 適切なテストデザインを選ぶ

SKILL.md の原則と evals/evals.json の例に基づき、エージェントは次のような判断を支援します：

• A/B vs. A/B/n vs. multivariate – 例えば、トラフィックが少ないのにボタン色 4 パターンを同時にテストしてテストパワーを落としてしまう、といったケースを避けるよう促します。
• 単変量にフォーカス – 結果を解釈しやすくするため、基本的には一度に 1 つの主要な変更に絞るよう推奨します。
• トラフィック配分 – シンプルな A/B なら一般的には 50/50 を推奨しつつ、テンプレートではより複雑な設計にも対応しています。

特に、あれもこれも同時に変えたくなるマーケティングや SEO チームにとって有用です。

4. サンプルサイズとテスト期間を計画する

references/sample-size-guide.md では、エージェントが次のような枠組みで説明・計画できるようになっています：

• ベースラインのコンバージョン率、MDE、有意水準、検出力（power） を概念的に説明。
• 早見表や計算式を用いて、各バリアントに必要な サンプルサイズ を見積もる。
• トラフィックに基づいて、必要なサンプルサイズから概算の テスト期間 を算出する。
• サンプルサイズが不十分なテストや、多数のバリアントを試す際の補正を無視してしまうなど、よくある誤り を指摘する。

例えば eval のプロンプトでは、月間 15,000 訪問・ベースライン 3.2% のケースで必要なサンプルサイズを概算し、現実的なテスト期間を提案することが求められています。

5. 指標とガードレールを定義する

test-templates.md のパターンに従って、エージェントは次のような設計を支援します：

• 主要な成果を表す Primary Metric（例：サインアップ率）を 1 つ決める。
• より深い理解のために Secondary Metrics（例：クリック率、マイクロコンバージョン）を追加する。
• 全体への悪影響を防ぐために Guardrail Metrics（例：直帰率、エラー率、訪問者あたり売上）を設定する。

これは特に、部分最適が全体のパフォーマンスを損なうリスクがある広告運用や SEO コンテンツの実験で役立ちます。

6. 構造化されたテスト計画を出力する

必要な情報が揃ったら、エージェントは references/test-templates.md のテンプレートを使って、次のような要素を含むテスト計画を書き出せます：

• 概要とオーナー情報。
• 仮説とその背景・根拠。
• テストデザインと実装に関するメモ。
• コントロールおよびチャレンジャーのバリアントの説明。
• 指標の定義とセグメンテーションの方針。

この計画は、そのまま実験ツールや社内ドキュメント、JIRA チケットなどに貼り付けて、テストを一貫性のある形で運用したりレビューしたりできます。

他のスキルとの連携

• analytics-tracking と併用する場合：ab-test-setup は「何を」「なぜ」テストするかを定義し、analytics-tracking はイベント・ゴール・コンバージョンを「どう」計測するかを定義します。
• page-cro と併用する場合：page-cro で「何を変えるか」のアイデアを出し、ab-test-setup で「どのアイデアから、どうテストするか」を決めます。

これらを組み合わせれば、アイデア創出 → 優先度付け → テスト設計 → 実装 → 分析まで、一連の実験ワークフローをカバーできます。

FAQ

ページをそのまま変えるのではなく、いつ ab-test-setup を使うべき？

次のような場合は ab-test-setup の利用がおすすめです：

• 変更が ビジネスインパクトの大きい領域（例：主要ファネル、トラフィックの多いページ）に関わるとき。
• ステークホルダーから「本当に効果があったのか？」と聞かれることが想定され、説得力のあるエビデンスが必要なとき。
• 継続的な マーケティングや SEO の改善 をしており、再現性のあるプロセスを持ちたいとき。

逆に、インパクトが小さい微修正や見た目だけの変更で、効果測定をする予定がないなら、フルセットの A/B テスト計画は不要です。

ab-test-setup はサンプルサイズを正確に計算してくれる？

このスキル自体に専用の計算ライブラリは含まれていません。その代わりに、references/sample-size-guide.md のロジックと例を用いて次のようなサポートをします：

• どんな入力値が必要かを説明する。
• 妥当なサンプルサイズの概算や、オンライン計算ツールへの誘導を行う。
• トラフィックが信頼できるテストには不足していそうな場合は、事前に警告する。

特に、ミッションクリティカルな領域や規制の厳しい領域では、最終的な計算はアナリティクスチームやデータサイエンティストによる確認を推奨します。

2つ以上のバリエーションにも ab-test-setup は使える？

はい。基本コンセプトは A/B テストですが、ドキュメントとテンプレートは A/B/n や multivariate な実験にも対応しています。また、バリアントを増やすほど必要なサンプルサイズとテスト期間が長くなる点についても、sample-size guide 内でしっかりと説明されています。

ab-test-setup は「peeking」や早期終了をどう扱う？

評価用プロンプトでは、エージェントに次の点が明示的に求められています：

• 結果を頻繁にチェックして早期にテストを止めてしまう peeking の問題 について注意喚起すること。
• 勝者を宣言する前に、固定のテスト期間またはサンプルの閾値 を推奨すること。

これにより、特に重要度の高いマーケティングやプロダクトの意思決定において、統計的な妥当性を維持しやすくなります。

ab-test-setup はウェブページ専用？

いいえ。以下のような幅広いケースに応用可能です：

• Webサイトおよびランディングページの実験。
• プロダクト内の in-app テスト。
• メールやライフサイクルジャーニーのテスト。
• 広告クリエイティブやメッセージの実験。

ユーザーをランダムにバリアントに割り当てて結果をトラッキングできる環境であれば、ab-test-setup は実験設計の助けになります。

A/B テストをするのに十分なトラフィックがあるかどうか、どう判断すればいい？

references/sample-size-guide.md のガイダンスを使って判断します：

• まず ベースラインのコンバージョン率 と 月間訪問者数 を把握する。
• 検出したい変化量である Minimum Detectable Effect（どのくらいの差が検出できれば十分か）を決める。
• 早見表や計算式を使って、各バリアントに必要な サンプルサイズ を見積もる。
• そのサンプルサイズが、手元のトラフィックで 現実的な期間 で集められるかどうかを比較する。

必要な期間が極端に長くなりそうな場合、エージェントは次のような代替案を提案することがあります：

• 類似ページやキャンペーンをまとめてテストし、サンプルサイズを増やす。
• よりインパクトの大きい変更（より大きな MDE）をテスト対象にする。
• A/B テストではなく、定性的リサーチやユーザーテストなど、別の調査手法を使う。

コピー案やデザイン案だけ欲しい場合はどうすればいい？

ab-test-setup は、どのバージョンが勝つかを 定量的に計測する前提 で設計されています。テストを走らせず、コピーやレイアウトのアイデアだけ欲しい場合は：

• page-cro などのコンテンツ／CRO 向けスキルを使ってアイデア出しを行う。
• その後、実際にテストで検証したくなったタイミングで ab-test-setup に戻る、といった使い分けができます。

このスキルの良いアウトプット例はどこで見られる？

ab-test-setup フォルダ内の evals/evals.json を確認してください。ホームページのヘッドラインやボタンカラーのテストなど、現実的なプロンプトが含まれており、エージェントの期待される応答内容として次の点が詳細に示されています：

• 仮説の構造。
• サンプルサイズとテスト期間の考え方。
• 指標選定。
• よくある落とし穴への注意喚起。

これらをベンチマークとして、自分の環境にスキルを組み込んだりカスタマイズしたりする際の参考にできます。