pm-experimentation-ab

A/B テスト & 実験スキル

このスキルの動作 (最初にお読みください)

これは生成型のスキルです (実験計画を設計または改訂し、既存のテスト設定をレビューできます)。実験は、AI アシスタントのデフォルトが静かに間違っていて、自信に満ちた誤った結論を生み出す領域です。Claude は喜んで「A/B テストを設定」しますが、それはわずかなユーザー数で勝者を宣言し、p < 0.05 になった瞬間に覗き見して停止し、ガードレールなしで 1 つの指標を最適化して他の場所への悪影響を無視し、平日 3 日間だけ実行し、「B の勝ち」で終わり、セグメントも長期の読み取りも記録もありません。悪い実験は実験しないより悪い — 推測を「データ」に見せかけるのです。

そこでこのスキルはゲートを設け、そのゲートは統計的規律です:

1. コンテキストを確立する — ここで管理された実験がそもそも適切なツールなのか、それがどの単一の意思決定に情報を与えるのか、そしてリスクレベル (これらが信頼度、分割、期間を設定します)。
2. 常に真であるコアを適用する — 仮説と成功基準を事前登録し、実行する前にテストのサイズを見積もり、完全なサイクルを実行し、1 つの主要指標 + ガードレールを使い、過去の「勝った」を解釈し、学習ループを閉じます。
3. コンテキスト依存の意思決定を明らかにする (信頼度しきい値、トラフィック分割、A/B 対 多変量、指標タイプ、先行/長期指標、テストの優先順位付け) をトレードオフとともに示し、ユーザーに選ばせます。

その後、pm-okr-metric-validity-audit (選んだ指標は有効か、虚栄指標ではないか?) と pm-assumption-rigor-audit (仮説は最もリスクが高く、反証可能で、事前にコミットされたものか?) に引き継ぎます。

スコープとペアリング: このスキルは管理された実験の方法とその統計を担います。これは pm-assumption-testing とペアになり、そちらは何をテストするか、そしてそれをテストする最も安価な方法を担います — 質問が初期段階、低トラフィック、または定性的に答える方が良い場合は、A/B テストを強行するのではなく、assumption-testing に委ねます。広範な次に何を作るかのランキングは pm-prioritization に、指標の定義/OKR は pm-okrs-kpis に、高リスクのロールアウトの go/no-go は pm-decision-quality-audit に委ねます。

---

ステップ 0 — テストを設計する前にコンテキストを確立する

不明な場合は尋ねてください。回答なしで進める場合は仮定を述べてください:

• 管理された実験は適切なツールですか? A/B テストには、妥当な時間で有効なサンプルに到達するのに十分なトラフィック、行動に現れる変化、そして「どちらがより良く機能するか」という問い (「誰かこれが欲しいのか」ではなく) が必要です。トラフィックが薄い場合、アイデアが未検証の場合、または問いが「なぜ」である場合は、pm-assumption-testing にルーティングします (まずより安価な定性的または低忠実度のテスト)。プロダクトマーケットフィットを A/B テストで勝ち取ろうとしないでください。
• これはどの単一の意思決定に情報を与え、どのようなリスクがありますか? 実験ごとに 1 つの意思決定です。誤った場合のリスク/影響が信頼度しきい値とトラフィック分割を設定します (チェックアウトや価格設定の変更は、ボタンの色の変更ではありません)。
• ベースラインと、検出すべき最小効果 (MDE) は何ですか? 現在の指標値と、意味のある最小の改善が必要です — どちらもサンプルサイズの計算に使われます。ベースラインが小さいほど、MDE が小さいほど、より大きなサンプルが必要です。
• ビジネスサイクルは何ですか / 交絡要因はありますか? 平日対週末のパターン、季節性、ローンチ、プロモーション、競合の動き。これらが最小期間を設定し、偏ったウィンドウを排除します。

---

常に適用するコア (あらゆる管理された実験に当てはまる)

実行する前に事前登録する

• 推論を伴う反証可能な仮説を書く: 「もし私たちが[この変更を行う]なら、[この指標]が[大きさ]だけ[増加/減少]する。なぜなら[ユーザーインサイト]だからだ。」曖昧なもの(「大きなボタンが機能するか見てみよう」)は曖昧な結果を生みます。
• 確認するためではなく、反証するために設計する。 成功基準と失敗基準をあらかじめ設定し、どの結果なら自分の考えが変わるかを事前に決めておきます。すべてのテストが「勝つ」なら、間違ったものを測定しているか、後付けでストーリーを作っているのです。時には間違う必要があります。
• 意思決定のしきい値を事前に設定する。 ローンチ前に、どの結果がイテレーションか、ピボットか、継続かを決めます(例:「+20%未満 → ピボット、20〜40% → イテレーション、40%超 → 継続」)。事前のコミットメントが、後付けの合理化を防ぎます。

適切にサイズを決めて実行する

• まずサンプルサイズを計算し、それから期間を導き出す。 ベースライン、MDE、信頼度から、バリエーションごとのユーザー数を計算します。そうすれば、日次トラフィックから実行すべき期間がわかります。これを省略すると、テストが早すぎるタイミングで停止されたり、永遠に引き延ばされたりします。
• 本当の有意性に到達する — のぞき見しない。 信頼水準(デフォルトで95%/p<0.05)を用い、計画したサンプルと完全なビジネスサイクル(≥1〜2週間)までテストを実行させます。最初の緑のp値で停止すると、偽陽性が膨らみます。「100ユーザー後に有意」は勝利ではなく、セットアップのバグです。
• ランダムかつ持続的に割り当てる。両方のアームをQAする。 デフォルトで50/50、訪問を通じてユーザーごとに一貫させ、デバイス/ブラウザ上でトラッキングが正しく発火することを検証します。テストの途中で分割を変更しないでください — 結果が歪みます。

正直に測定する

• 主要指標1つ + ガードレール。 主要指標は仮説に紐づき、成功を決めます。ガードレール/ヘルス指標(例: 収益、解約率、注文額、サポート量、レイテンシ)を追加して、他の何かを静かに害する「勝利」を捕捉します。気分は良いが意思決定を促さない虚栄指標は捨てます。
• 「勝った」を超えて解釈する。 セグメント(モバイル/デスクトップ、新規/リピーター、地域、流入元 — 全体で+10%でもモバイルが−5%を隠しているかもしれません)を読み、二次的な影響を確認し、短期 vs. 長期を比較検討します(ホールドアウトグループは、短期的なリフトが持続するかどうかを明らかにします)。

ループを閉じる

• 文書化して意思決定する。 事前に書いた仮説、セットアップ、結果(失敗を含む)、そして事前に設定したしきい値に対するイテレーション/ピボット/継続の判断を記録します。結果を関連するOKRに反映します。組織が同じテストを再実行するのを止めるために、検索可能な学習リポジトリを構築します — 失敗した実験はしばしば最も価値のある警告を含んでおり、驚くべきユーザー行動(Twitterの「@username」、Airbnbのビジネス旅行者)にこそ突破口が隠れています。

---

文脈に依存する判断（表面化させ、自動適用しない）

それぞれについてトレードオフと Step 0 に紐づく推奨を提示し、ユーザーに選ばせます。すべての手法と指標タイプを一度に適用することが失敗パターンです。

判断	適用する場合	避ける／適応させる場合	デフォルトの推奨
信頼度しきい値	重要／不可逆なフロー（チェックアウト、価格設定）には 99%、低リスクで高速に反復する機能には 90%	些細な変更でも 95% を絶対視する、または影響範囲が大きい変更に 90% を使う	リスクに応じた段階制。デフォルトは 95%、重要なら引き上げ、安価で可逆な呼び出しに限り引き下げる
トラフィック分割	高速で低リスクな読み取りには 50/50	バリアントに実際の不利益がある場合（新価格、大規模なリデザイン）は 90/10（またはそれ以下の露出）	不利益リスクが露出を制限する正当な理由にならない限り 50/50。テスト途中では決して変更しない
A/B と多変量	1 つの変更をクリーンに切り分けるには A/B、要素間の交互作用効果を見つけるには多変量	トラフィックが不足しているのに多変量を実施 — N 要素 × バリエーションで必要なサンプルが倍増する（4 組み合わせ = 4 倍のトラフィック）	デフォルトは A/B。多変量はトラフィックの多い面に限る
標準指標とカスタム指標	実験間で比較できるよう標準指標（登録率、WAU）、特定の仮説にはカスタム指標（「初回タスク完了までの時間」）	標準指標のみ（機能の実際の効果を見逃す）、またはカスタムのみ（整合性を失う）	少数の標準セットに加えて仮説に紐づくカスタム指標を追跡する
先行指標と遅行指標／長期	目標がまれ／遅い場合に素早いシグナルを得るには先行指標（カート追加）、持続的な影響を見るにはホールドアウトグループ	短期指標だけで長期的な成功を判断する	早期の読み取りには先行指標を使い、持続性を確認するために一部をホールドアウトする
テストの優先順位付け	テストアイデアのバックログを順序付けるには PIE（Potential × Importance × Ease）または類似の手法	順位付けなしで多数のテストを同時に実行する、またはトラフィックの少ないページを先にテストする	アイデアを PIE でスコアリングする。ロードマップ全体の順位付けは pm-prioritization に委ねる

いくつかの文脈では、複数のデフォルトが一度に反転します。トラフィックが少ない／PMF 前のプロダクトは通常、A/B テストを実施すべきではありません（仮説検証へ回す）。高リスクで不可逆な変更には、99% の信頼度、保守的な分割、ガードレールの重視、およびロールアウト前の decision-quality チェックが求められます。

---

これを検証する（オーケストレーション）

ハンドオフでは、各レンズをインストール可能なスキルの name で指定します。そのスキルがインストールされている場合にのみ呼び出してください。インストールされていない場合、このスキル自体のコアにすでにこれらのルールが含まれているため、ブロックせずにそのまま進めてください。

成果物を作成または改訂した後は、完了と宣言するのではなく、監査レンズに引き渡してください。これらは候補のレンズです — 姿勢については docs/orchestration-policy.md に従うか、成果物全体を pm-product-review にルーティングしてください。ここでは assumption-rigor が常時実行されるレンズ（自動実行） であり、その他は成果物に実際に含まれる内容に応じて提示されるものです。ユーザーが特定の目的でこのスキルを呼び出した場合は、そのスコープを尊重してください。

• pm-assumption-rigor-audit (自動実行) — その仮説は最もリスクの高い前提であり、管理されたテストに値するもので、反証可能な形で表現され、実行前に成功基準が設定され、実行後に正直に（確証バイアスなしで）評価されているか？
• pm-okr-metric-validity-audit (提示 — 主要指標／ガードレール指標を挙げている場合) — 主要指標とガードレール指標は、その成果の有効な尺度（ページビューのような虚栄の指標ではない）であり、実際の目的と結びついているか？ 悪い指標を最適化する実験は、間違ったものをスケールさせてしまいます。
• pm-decision-quality-audit (提示 — ハイステークスで不可逆なロールアウトを推進する場合) — iterate／pivot／persevere の判断は、（事前設定された閾値、事前検死、プロセスと結果の分離といった）健全なプロセスに基づいていたか？ それとも幸運な数値の結果に基づいていたか？

組み合わせ（docs/orchestration-policy.md §9 に準拠）: このスキルは pm-assumption-testing とペアになります — これは何をテストするかと最も安価な手法を担うピアです（先送り）。A/B が適切なツールとなった時点で、このスキルが管理された実験を実行します。監査で矛盾が表面化した場合は、目的に向けて解決してください: 実験は信頼できる意思決定を生み出すために存在します — 有効なサンプルに到達できない、ガードレールがない、またはあなたの行動を変えないのであれば、A/B テストとして実行しないでください。

---

よくある do/don't パターン

❌ しない	✅ する
ごく小さなサンプルで勝者を宣言する	まずサンプルサイズを計算し、それに達するまで実行する
覗き見して最初の p < 0.05 で止める	信頼水準と完全なビジネスサイクルを事前設定し、早期に止めない
平日3日間だけ実行する	≥1〜2週間／完全なビジネスサイクルをカバーし、偏った期間を避ける
副作用を無視して1つの指標だけを最適化する	1つの主要指標＋ガードレール／ヘルス指標
虚栄の指標（ページビュー）を追いかける	指標を仮説と意思決定に結びつける
曖昧な「X をテストしよう」を書く	成功基準と失敗基準を備えた反証可能な「if/then/because」仮説
全体の数値だけを読む	セグメント（デバイス／新規・リピーター／地域）＋二次的＋長期的な読み取り
テスト中にトラフィック配分を変更する	配分を事前に固定し、割り当てをランダムかつ永続的に保つ
トラフィックがないのに多変量テスト	デフォルトは A/B。多変量は高トラフィックページのみ
検証されていない低トラフィックのアイデアを A/B テストする	早期／低トラフィック／定性的な問いは assumption-testing にルーティングする
「B が勝った」で止める	文書化し、事前設定された閾値で iterate／pivot／persevere を判断し、学びを蓄積する
テスト計画を未確認のまま出荷する	okr-metric-validity ＋ assumption-rigor（大規模ロールアウトではさらに decision-quality）に引き渡す

---

出典レッスン（Uxcel）

• A/B Testing & Experimentation
• A/B Testing
• Experimentation Metrics
• Learning from Your Launches