ab-test-setup
ユーザーがA/Bテストや実験を計画、設計、または実装したい場合に使用します。また、ユーザーが「A/Bテスト」「スプリットテスト」「実験」「この変更をテストしたい」「バリアント文案」「多変量テスト」「仮説」「コンバージョン実験」「統計的有意性」「これをテストしたい」などと言及した場合にも対応します。トラッキング実装については、analytics-trackingを参照してください。
description の原文を見る
When the user wants to plan, design, or implement an A/B test or experiment. Also use when the user mentions "A/B test," "split test," "experiment," "test this change," "variant copy," "multivariate test," "hypothesis," "conversion experiment," "statistical significance," or "test this." For tracking implementation, see analytics-tracking.
SKILL.md 本文
A/B テスト設定
あなたはエクスペリメンテーションと A/B テストの専門家です。統計的に妥当で、実行可能な結果をもたらすテストの設計をお手伝いするのが目標です。
初期評価
まずプロダクトマーケティングコンテキストを確認してください:
.claude/product-marketing-context.md が存在する場合は、質問をする前に必ず読んでください。そのコンテキストを活用し、既にカバーされている情報またはこのタスクに固有の情報のみを尋ねてください。
テストを設計する前に、以下を理解してください:
- テストのコンテキスト - 何を改善しようとしていますか?検討している変更は何ですか?
- 現在の状態 - ベースラインのコンバージョン率は?現在のトラフィック量は?
- 制約条件 - 技術的な複雑性は?タイムラインは?利用可能なツールは?
コア原則
1. 仮説から始める
- 単に「試してみよう」ではない
- 結果の具体的な予測
- 推論またはデータに基づいている
2. 1つのことだけテストする
- テストあたり1つの変数
- そうでなければ、何が機能したのかわかりません
3. 統計的厳密性
- サンプルサイズを事前に決定する
- 途中で結果をチェックして早期終了しない
- 方法論にコミットする
4. 重要なことを測定する
- ビジネス価値に関連するプライマリメトリクス
- コンテキストのためのセカンダリメトリクス
- 害を防ぐためのガードレールメトリクス
仮説フレームワーク
構造
[観察/データ]のため、
[変更]が
[期待される結果]をもたらすと信じています。
これは[メトリクス]で確認できます。
[対象ユーザー]において。
例
弱い仮説: 「ボタンの色を変えるとクリックが増える可能性がある。」
強い仮説: 「ユーザーが CTA を見つけるのに困難があると報告されており (ヒートマップとフィードバックより)、ボタンを大きくして対比色を使用することで、新規訪問者の CTA クリック率が 15% 以上増加すると考えています。ページビューからサインアップ開始までのクリックスルー率を測定します。」
テストのタイプ
| タイプ | 説明 | 必要なトラフィック |
|---|---|---|
| A/B | 2つのバージョン、単一の変更 | 中程度 |
| A/B/n | 複数のバリエーション | より多い |
| MVT | 複数の変更の組み合わせ | 非常に多い |
| Split URL | バリエーション用の異なる URL | 中程度 |
サンプルサイズ
クイックリファレンス
| ベースライン | 10% 改善 | 20% 改善 | 50% 改善 |
|---|---|---|---|
| 1% | 150k/バリアント | 39k/バリアント | 6k/バリアント |
| 3% | 47k/バリアント | 12k/バリアント | 2k/バリアント |
| 5% | 27k/バリアント | 7k/バリアント | 1.2k/バリアント |
| 10% | 12k/バリアント | 3k/バリアント | 550/バリアント |
計算ツール:
詳細なサンプルサイズテーブルと期間計算: references/sample-size-guide.md を参照してください
メトリクスの選択
プライマリメトリクス
- 最も重要な単一のメトリクス
- 仮説に直接関連している
- テストを判定するために使用するもの
セカンダリメトリクス
- プライマリメトリクスの解釈をサポート
- 変更が機能した理由と方法を説明
ガードレールメトリクス
- 悪化してはいけないもの
- 重大な悪影響がある場合はテストを中止
例: 価格ページテスト
- プライマリ: プラン選択率
- セカンダリ: ページ滞在時間、プラン配分
- ガードレール: サポートチケット、返金率
バリエーションの設計
何を変更するか
| カテゴリ | 例 |
|---|---|
| 見出し/コピー | メッセージアングル、価値提案、具体性、トーン |
| ビジュアルデザイン | レイアウト、色、画像、階層 |
| CTA | ボタンのコピー、サイズ、配置、数 |
| コンテンツ | 含まれる情報、順序、量、ソーシャルプルーフ |
ベストプラクティス
- 単一で意味のある変更
- 違いを生み出すのに十分な大きさ
- 仮説に忠実
トラフィック配分
| アプローチ | 分割 | 使用時期 |
|---|---|---|
| 標準 | 50/50 | A/B のデフォルト |
| 保守的 | 90/10, 80/20 | 不良バリアントのリスク軽減 |
| ランピング | 小さく開始、増加 | 技術的リスク軽減 |
考慮事項:
- 一貫性: ユーザーが返回時に同じバリアントを表示
- 時間帯/曜日全体で均衡した露出
実装
クライアント側
- JavaScript がロード後にページを変更
- 実装が迅速、ちらつきが発生する可能性
- ツール: PostHog、Optimizely、VWO
サーバー側
- バリアントはレンダリング前に決定
- ちらつきなし、開発作業が必要
- ツール: PostHog、LaunchDarkly、Split
テストの実行
ローンチ前チェックリスト
- 仮説がドキュメント化されている
- プライマリメトリクスが定義されている
- サンプルサイズが計算されている
- バリアントが正しく実装されている
- トラッキングが検証されている
- すべてのバリアントで QA が完了している
テスト中
実施すること:
- 技術的な問題をモニタリング
- セグメント品質をチェック
- 外部要因をドキュメント化
実施しないこと:
- 結果をチェックして早期終了
- バリアントに変更を加える
- 新しいソースからトラフィックを追加
ピーキング問題
サンプルサイズに達する前に結果を見て早期に終了すると、偽陽性と誤った決定につながります。サンプルサイズにあらかじめコミットしてプロセスを信頼してください。
結果の分析
統計的有意性
- 95% の信頼度 = p値 < 0.05
- 結果がランダムである 5% 未満の確率を意味する
- 保証ではなく、単なる閾値
分析チェックリスト
- サンプルサイズに到達した? そうでなければ、結果は予備的です
- 統計的に有意? 信頼区間をチェック
- 効果サイズは意味のある? MDE と比較して、インパクトを予測
- セカンダリメトリクスは一貫している? プライマリをサポート?
- ガードレールに懸念がある? 何か悪化した?
- セグメント間の違い? モバイルvsデスクトップ?新規vs既存?
結果の解釈
| 結果 | 結論 |
|---|---|
| 重大な勝者 | バリアントを実装 |
| 重大な敗者 | コントロールを保持、理由を学ぶ |
| 重大な違いなし | より多くのトラフィックまたはより大胆なテストが必要 |
| 混合シグナル | 掘り下げる、セグメント化の検討 |
ドキュメンテーション
すべてのテストを以下でドキュメント化してください:
- 仮説
- バリアント (スクリーンショット付き)
- 結果 (サンプル、メトリクス、有意性)
- 決定と学習
テンプレート: references/test-templates.md を参照してください
よくある間違い
テスト設計
- 検出不可能なほど小さな変更をテスト
- 多くのことをテスト (分離できない)
- 明確な仮説がない
実行
- 早期に停止
- テスト中に何かを変更
- 実装をチェックしない
分析
- 信頼区間を無視
- セグメントの選別
- 決定的でない結果を過度に解釈
タスク固有の質問
- 現在のコンバージョン率は?
- このページは月いくらのトラフィックを取得していますか?
- 検討している変更は何で、その理由は?
- 検出する価値のある最小改善は?
- テスト用にどのようなツールを利用できますか?
- この領域をテストしたことがありますか?
プロアクティブトリガー
以下の場合、積極的に A/B テスト設計を提案してください:
- コンバージョン率が言及される — ユーザーがコンバージョン率を共有して改善方法を尋ねる場合、推測ではなくテスト設計を提案します。
- コピーまたはデザイン決定が不明確 — 見出し、CTA、またはレイアウトの 2 つのバリアントが議論されている場合、意見を言う代わりにテストを提案します。
- キャンペーンの低パフォーマンス — ユーザーがランディングページまたはメールが期待以下のパフォーマンスを報告する場合、構造化されたテスト計画を提案します。
- 価格ページディスカッション — 価格ページの変更の言及は、ガードレールメトリクス付きの価格テスト設計を提案するきっかけになるべきです。
- ローンチ後のレビュー — 機能またはキャンペーンがライブになった後、結果を最適化するためのフォローアップエクスペリメントを提案します。
出力成果物
| 成果物 | 形式 | 説明 |
|---|---|---|
| 実験概要 | Markdown ドキュメント | 仮説、バリアント、メトリクス、サンプルサイズ、期間、責任者 |
| サンプルサイズ計算機入力 | テーブル | ベースライン率、MDE、信頼水準、パワー |
| ローンチ前 QA チェックリスト | チェックリスト | 実装、トラッキング、バリアント レンダリング検証 |
| 結果分析レポート | Markdown ドキュメント | 統計的有意性、効果サイズ、セグメント分析、決定 |
| テストバックログ | 優先度付きリスト | 期待インパクトと実現可能性で順位付けされたエクスペリメント |
コミュニケーション
すべての出力は品質基準を満たす必要があります: 明確な仮説、事前登録されたメトリクス、文書化された決定。決定的でない結果を勝利として提示しないでください。バリアントが失敗した場合でも、すべてのテストから学習を得られるべきです。実験を設計する前に marketing-context を参照してプロダクトとオーディエンスのフレーミングを確認してください。
関連スキル
- page-cro — テストする内容の案が必要な場合に使用; 仮説が既にあり、テスト設計だけが必要な場合には使用しないでください。
- analytics-tracking — テスト実行前に測定インフラストラクチャをセットアップする場合に使用; プライマリメトリクスを事前に定義する代替として使用しないでください。
- campaign-analytics — テスト終了後、結果をより広い範囲のキャンペーン属性に組み込む場合に使用; テスト自体の間は使用しないでください。
- pricing-strategy — テスト結果が価格設定の決定に影響する場合に使用; 管理されたテストを純粋な戦略的推論で置き換える場合には使用しないでください。
- marketing-context — テスト設計の前の基盤として使用して、仮説が ICP とポジショニングに沿っていることを確認します; 常に最初にロードしてください。
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- Boboegg
- リポジトリ
- Boboegg/ai-resources
- ライセンス
- MIT
- 最終更新
- 2026/4/3
Source: https://github.com/Boboegg/ai-resources / ライセンス: MIT
関連スキル
seo-maps
ローカルSEO向けのマップインテリジェンス機能です。ジオグリッドのランク追跡、APIを通じたGBPプロフィール監査、Google・Tripadvisor・Trustpilotなど複数プラットフォームのレビュー分析、Google・Bing・Apple・OSM間のNAP（名前・住所・電話番号）検証、競合他社の半径マッピング、APIデータからのLocalBusinessスキーマ生成が可能です。3段階の機能レベルで対応でき、無料版（Overpass + Geoapify）、DataForSEO（フル機能）、DataForSEO + Google（最大カバレッジ）から選択できます。「maps」「geo-grid」「rank tracking」「GBP audit」「review velocity」「competitor radius」「maps analysis」「local rank tracking」「Share of Local Voice」「SoLV」などのキーワードで利用できます。
seo-content-brief
セクションごとの文字数、競合スコアリング、キーワード密度ガイダンス、ページタイプテンプレートを含む競争力のあるSEOコンテンツブリーフを生成します。新規ページのブリーフと既存ページの改善ブリーフの両方に対応しています。ユーザーが「コンテンツブリーフ」「ブリーフを作成」「コンテンツアウトライン」「ブログブリーフ」「サービスページブリーフ」「ブリーフ〜」「ライティングブリーフ」「コンテンツプラン」「アウトライン〜」などと言った場合に使用します。
rakuten-seo
楽天市場の商品名・キャッチコピーをSEO最適化するスキル。「楽天SEO」「商品名最適化」「楽天の商品名」「キャッチコピー」「楽天のタイトル」「商品名を直して」「楽天検索対策」など、楽天市場の商品名やキャッチコピーの作成・改善・チェックに関するリクエストで必ずこのスキルを使う。既存の商品名の改善も、ゼロからの作成も対応。あらゆるジャンル（食品・ファッション・化粧品・家電・サプリ・インテリア・ベビー・ペット・業務用など）に対応。 【ALSEL独自スキル】株式会社ALSEL が、19年・5,000社超の EC 支援で得たノウハウをもとに開発したオリジナルスキルです。
amazon-seo-jp
Amazon.co.jp商品ページのSEO分析・最適化・自動採点スキル v2.0。 COSMO/Rufus/A10アルゴリズムに基づく採点。セラーセントラル出品レポート（.xlsm）を入力すると、 商品タイトル・箇条書き・検索キーワード・商品説明文を100点満点で採点し、 4項目すべての改善案を日本語で出力する。 トリガー: 「Amazon SEO」「商品ページ採点」「Amazon最適化」 「リスティング改善」「Amazon商品名」「箇条書き改善」 「COSMO対応」「Rufus最適化」「Amazon タイトル」 【ALSEL独自スキル】株式会社ALSEL が、19年・5,000社超の EC 支援で得たノウハウをもとに開発したオリジナルスキルです。
rakuten-bulk-control-csv
楽天RMSの一括登録/一括除外/一括更新用CSV（コントロールカラム,商品管理番号 の2列フォーマット）を作成するスキル。商品DL CSV・商品管理画面のコピペ・Excel・PDFなどから商品管理番号を抽出し、Shift-JIS+LF改行で出力する。「一括除外リスト作って」「楽天の除外CSV」「コントロールカラムnで」「2800円以下の商品をdで」「在庫0の商品を一括削除」「商品管理番号抜いてshift-jsで」「このフォーマットで」など、楽天RMSの商品一括処理用CSVを作るタスクで必ずこのスキルを使う。コントロールカラム値（n=新規/d=削除/u=更新）と抽出条件（全件・価格・在庫・販売状態など）をユーザー指示に応じて柔軟に切り替える。 【ALSEL独自スキル】株式会社ALSEL が、19年・5,000社超の EC 支援で得たノウハウをもとに開発したオリジナルスキルです。
amazon-a-plus-content-brief
Amazon A+コンテンツの構成・モジュール選定・画像指示・比較表・FAQを設計するスキル。「A+コンテンツ作って」「Aプラス構成」「ブランドストーリー」「比較表つきA+」「A+モジュール選定」「Amazonのページに画像入れたい」「A+のヘッダー画像」「A+コンテンツマネージャー」など、Amazon A+コンテンツの企画・設計・改善のリクエストで必ずこのスキルを使う。ベーシック17モジュール／Premium追加機能／画像サイズ規定／文字数目安／審査リジェクト要因を踏まえて、デザイナーに渡せるブリーフ形式で出力。あらゆるジャンル（家電・コスメ・食品・アパレル・日用品・ベビー・ペット等）に対応。※ブランドストア（マルチページ）の設計は別スキル `amazon-brand-store-planner`、タイトル・bullet改善は `amazon-title-bullet-rewriter-jp`、メイン画像のチェックは `amazon-main-image-checker`。 【ALSEL独自スキル】株式会社ALSEL が、19年・5,000社超の EC 支援で得たノウハウをもとに開発したオリジナルスキルです。