A/B テスト設定

1️⃣ 目的とスコープ

すべての A/B テストが有効で厳密で安全であることを、コード作成前に確認します。

• 「途中確認」を防止
• 統計的パワーを強制
• 無効な仮説をブロック

---

2️⃣ 前提条件

以下が必要です：

• 明確なユーザー課題
• 分析ソースへのアクセス
• 大まかなトラフィック量の推定

仮説品質チェックリスト

有効な仮説には以下が含まれます：

• 観察または証拠
• 単一で具体的な変更
• 方向性のある予想
• 定義されたオーディエンス
• 測定可能な成功基準

---

3️⃣ 仮説ロック（ハード ゲート）

バリアントやメトリクスを設計する前に、以下が必須です：

• 最終仮説を提示
• 以下を指定：
  • ターゲット オーディエンス
  • プライマリ メトリクス
  • 予想される効果の方向
  • 最小検出可能効果（MDE）

明示的に質問してください：

「これはこのテストにコミットする最終仮説ですか？」

確認されるまで進まないでください。

---

4️⃣ 仮説と妥当性チェック（必須）

以下について明示的に仮説をリストアップしてください：

• トラフィックの安定性
• ユーザーの独立性
• メトリクスの信頼性
• ランダム化の質
• 外的要因（季節性、キャンペーン、リリース）

仮説が弱いまたは違反している場合：

• ユーザーに警告
• テストの遅延または再設計を推奨

---

5️⃣ テスト タイプの選択

最もシンプルな有効なテストを選択してください：

• A/B テスト – 単一の変更、2 つのバリアント
• A/B/n テスト – 複数のバリアント、高いトラフィック必須
• 多変量テスト（MVT） – 相互作用効果、非常に高いトラフィック必須
• 分割 URL テスト – 大規模な構造変更

明確な理由がない限りA/B テストをデフォルトにしてください。

---

6️⃣ メトリクスの定義

プライマリ メトリクス（必須）

• 成功を評価するために使用される単一のメトリクス
• 仮説に直接関連
• ローンチ前に事前定義で凍結

セカンダリ メトリクス

• コンテキストを提供
• 結果が発生した理由を説明
• プライマリ メトリクスをオーバーライドしてはいけません

ガードレール メトリクス

• 低下してはならないメトリクス
• 有害な勝利を防ぐために使用
• 著しく負の場合、テスト停止をトリガー

---

7️⃣ サンプル サイズと期間

事前に定義してください：

• ベースライン レート
• MDE
• 有意水準（通常は 95%）
• 統計的パワー（通常は 80%）

推定してください：

• バリアントあたりの必要なサンプル サイズ
• 予想テスト期間

現実的なサンプル サイズ推定なしで進まないでください。

---

8️⃣ 実行準備ゲート（ハード ストップ）

以下がすべて true の場合のみ実装に進むことができます：

• 仮説がロックされている
• プライマリ メトリクスが凍結されている
• サンプル サイズが計算されている
• テスト期間が定義されている
• ガードレールが設定されている
• トラッキングが検証されている

いずれかが欠けている場合は、停止して解決してください。

---

テストの実行

テスト実行中

すること：

• 技術的なヘルスを監視
• 外的要因を文書化

しないこと：

• 「良さそう」な結果により早期停止
• テスト途中でバリアントを変更
• 新しいトラフィック ソースを追加
• 成功基準を再定義

---

結果の分析

分析の規律

結果を解釈する際：

• テストされた母集団を超えて一般化しない
• テストされた変更を超えて因果関係を主張しない
• ガードレール障害をオーバーライドしない
• 統計的有意性とビジネス判断を分離する

解釈の成果

結果	アクション
有意な正の結果	ロールアウトを検討
有意な負の結果	バリアントを拒否、学びを文書化
決定的でない結果	より多くのトラフィックまたはより大胆な変更を検討
ガードレール障害	プライマリが勝っても出荷しない

---

ドキュメンテーションと学習

テスト レコード（必須）

文書化してください：

• 仮説
• バリアント
• メトリクス
• 達成したサンプル サイズ対予測
• 結果
• 決定
• 学び
• フォローアップのアイデア

記録は共有の検索可能な場所に保存して、繰り返しの失敗を避けてください。

---

拒否条件（安全性）

以下の場合は進むことを拒否してください：

• ベースライン レートが不明で推定できない
• トラフィックが MDE を検出するには不十分
• プライマリ メトリクスが未定義
• 複数の変数が適切な設計なしで変更されている
• 仮説が明確に述べられない

理由を説明し、次のステップを推奨してください。

---

主要原則（非交渉的）

• テストごとに 1 つの仮説
• 1 つのプライマリ メトリクス
• ローンチ前にコミット
• 途中確認なし
• 勝利よりも学習
• 統計的厳密性を第一に

---

最終リマインダー

A/B テストは、アイデアが正しいことを証明することではありません。 それは自信を持って真実を学ぶことについてです。

急ぐ、単純化、「試しに実行」する誘惑を感じたら — それはスローダウンして設計を再確認する信号です。

使用時期

このスキルは、概要に記載されているワークフローまたはアクションを実行する際に適用できます。

制限事項

• このスキルは上記に説明されているスコープが明確に一致する場合にのみ使用してください。
• 出力を環境固有の検証、テスト、または専門家レビューの代替として扱わないでください。
• 必要な入力、権限、安全性の境界、または成功基準が欠けている場合は停止して明確化を求めてください。