公式スキル · プロダクト

A/Bテストの実験計画

v1.0.0・2026年11月4日更新

仮説、主要指標とガードレール指標、MDE、計算つきのサンプルサイズと期間、停止ルール、事前に決めた判定ルールをまとめたA/Bテストの計画書を書く。

Claude・ChatGPT・コーディング用の AI で使えます。TeamとBusiness では、Pod に入れた公式スキルが改善のたびに自動で最新版になります。

使う場面

• ページ、導線、メール、価格のA/Bテストを始める前
• テストを何週間回すか、何人必要かを聞かれた

AI に渡すもの

• テストする変更とその理由
• 主要指標のベースライン
• テストに入る週あたりのトラフィック

できあがるもの

仮説、指標の表、サンプルサイズの計算、期間、停止ルール、リリースするかどうかの判定ルール、リスクをまとめた1枚の実験計画。

手順

1. 反証できる仮説を書く 「[根拠]から、[対象]に[変更]をすると[主要指標]が上がると考える。[指標]が[MDE]以上上がれば正しいと判断する」。根拠がなければ、そう書く。その場合、テストは探索的なものになる。
2. 主要指標を一つ、ガードレールを1〜3個選ぶ テストの勝ち負けは主要指標で決める。ガードレールは悪化してはいけない指標で、返金、配信停止、ページの読み込み時間、問い合わせ件数など。主要指標には、テスト期間中にその変更が動かせる成果にいちばん近いものを選ぶ。
3. 最小検出効果を決める MDEは、テストが確実に見つけられる最小の変化。事業の側から、リリースする価値のある最小の改善幅で決める。MDEを小さくすると、必要なサンプルはずっと大きくなる。
4. サンプルサイズと期間を見積もり、計算方法を示す 既定値は有意水準（α）5%、検出力80%。Statsigなどのツールでよく使われる設定である。コンバージョン率なら、Evan Millerの目安の式で、1パターンあたり n = 16 × p(1 − p) ÷ δ²。pはベースライン、δは絶対値でのMDE。期間 =（n × パターン数）÷ テストに入る週あたりのユーザー数。すべての曜日が入るよう、週単位に切り上げる。始める前に計算ツールで確かめ、そのツール名を書く。
5. 停止ルールを書く 有意に見えたからといって早めに止めない。何度も途中経過を見ると偽陽性が増えることを、Evan Millerが示している。早めに止めるのは害があるときだけ。今のうちに決めた閾値をガードレールが超えたとき、または体験が壊れているとき。結果を読む前に、カイ二乗検定でサンプル比率の不一致（観測された割り振りが計画と違うこと）を確かめる。Microsoftの実験チームは、どのテストにもまずこのチェックを通ることを求めている。
6. 判定ルールを始める前に書く 結果ごとに何をするかを書く。主要指標がMDEを上回り、どのガードレールも超えていなければリリースする。ガードレールを超えたらリリースしない。結論が出なければ現状を維持し、わかったことを記録する。だれが判断するかも書く。
7. リスクと結果の読み出し日を挙げる 目新しさの効果、季節性、ほかのテストとの重なり、計測の抜け。読み出し日は会議の予定からではなく、期間から決める。

SKILL.md の全文

AI が読むファイルそのものです。 ダウンロード

---
name: experiment-plan
description: A/Bテストを始める前に実験計画書を書く。反証できる仮説、主要指標一つとガードレール指標、最小検出効果（MDE）、計算方法を示したサンプルサイズと期間の見積もり、サンプル比率の不一致（SRM）のチェック、停止ルール、事前に決めた判定ルールをまとめる。ページ、料金、オンボーディング、メールのA/Bテスト・スプリットテスト・実験を計画していて、テスト計画、仮説、サンプルサイズ、何週間回すかを聞かれたときに使う。
---

# 実験計画

実験は、どんな結果が出たら何を変えるのかを、始める前にチームが書き残してこそ回す価値がある。サンプルサイズと判定ルールは前もって決めておく。数字を見てから決めると、ただの誤差が「勝ち」に化ける。ほかの人がこの計画でテストを回しても、同じ判断にたどり着けるようにする。

## 使う場面

- ページ、導線、メール、価格、機能のA/Bテストを始める前。
- 「何週間回せばいい？」「何人必要？」と聞かれた。
- 以前のテストを早めに打ち切ってしまい、もっと厳密に進めたい。
- 計画なしに終わったテストの結果を読むことには使わない。定性調査には使わない（interview-guide を使う）。

## 用意するもの

- テストする変更と、それが効くとチームが考える理由。
- 主要指標と、その現在のベースライン（例：登録率4.0%）。ベースラインがなければ一度だけ聞く。ないとテストの規模を見積もれないので、サンプルサイズは「[未定: ベースラインが必要]」とする。
- テストに入る週あたりのトラフィックかユーザー数。なければ期間を「[未定]」とする。
- 任意：動く価値のある最小の改善幅と、悪化してはいけない指標。

## 手順

1. **反証できる仮説を書く。** 「[根拠]から、[対象]に[変更]をすると[主要指標]が上がると考える。[指標]が[MDE]以上上がれば正しいと判断する」。根拠がなければ、そう書く。その場合、テストは探索的なものになる。
2. **主要指標を一つ、ガードレールを1〜3個選ぶ。** テストの勝ち負けは主要指標で決める。ガードレールは悪化してはいけない指標で、返金、配信停止、ページの読み込み時間、問い合わせ件数など。主要指標には、テスト期間中にその変更が動かせる成果にいちばん近いものを選ぶ。
3. **最小検出効果を決める。** MDEは、テストが確実に見つけられる最小の変化。事業の側から、リリースする価値のある最小の改善幅で決める。MDEを小さくすると、必要なサンプルはずっと大きくなる。
4. **サンプルサイズと期間を見積もり、計算方法を示す。** 既定値は有意水準（α）5%、検出力80%。Statsigなどのツールでよく使われる設定である。コンバージョン率なら、Evan Millerの目安の式で、1パターンあたり n = 16 × p(1 − p) ÷ δ²。pはベースライン、δは絶対値でのMDE。期間 =（n × パターン数）÷ テストに入る週あたりのユーザー数。すべての曜日が入るよう、週単位に切り上げる。始める前に計算ツールで確かめ、そのツール名を書く。
5. **停止ルールを書く。** 有意に見えたからといって早めに止めない。何度も途中経過を見ると偽陽性が増えることを、Evan Millerが示している。早めに止めるのは害があるときだけ。今のうちに決めた閾値をガードレールが超えたとき、または体験が壊れているとき。結果を読む前に、カイ二乗検定でサンプル比率の不一致（観測された割り振りが計画と違うこと）を確かめる。Microsoftの実験チームは、どのテストにもまずこのチェックを通ることを求めている。
6. **判定ルールを始める前に書く。** 結果ごとに何をするかを書く。主要指標がMDEを上回り、どのガードレールも超えていなければリリースする。ガードレールを超えたらリリースしない。結論が出なければ現状を維持し、わかったことを記録する。だれが判断するかも書く。
7. **リスクと結果の読み出し日を挙げる。** 目新しさの効果、季節性、ほかのテストとの重なり、計測の抜け。読み出し日は会議の予定からではなく、期間から決める。

## 出力の形式

```markdown
# 実験計画：[名前]

**担当：** [氏名] · **判断する人：** [氏名] · **開始：** [日付] · **読み出し：** [日付]

## 仮説
[根拠]から、[対象]に[変更]をすると[指標]が上がると考える。[指標]が[MDE]以上上がれば正しいと判断する。

## パターン
- **対照（A）：** [現在の体験]
- **パターンB：** [変更]
- **割り振り：** [例：50/50] · **対象：** [だれが入り、だれを除くか]

## 指標
| 指標 | 役割 | ベースライン | 閾値 |
|---|---|---|---|
| [指標] | 主要 | [率] | MDE：[絶対値と相対値] |
| [指標] | ガードレール | [率] | [値]より悪化したら停止 |

## サンプルサイズと期間
- α = [0.05] · 検出力 = [80%] · ベースライン p = [率] · 絶対値でのMDE δ = [値]
- 見積もり：n = 16 × p(1 − p) ÷ δ² = [計算] ≈ 1パターンあたり[n]
- テストに入る週あたりのユーザー数：[n] → 期間：[n]週間
- 確認に使ったツール：[計算ツール名、または「確認予定」]

## 停止ルール
- よい結果が出ても早めに止めない。
- 害があれば停止：[ガードレールの閾値]または[体験が壊れている]。
- サンプル比率のチェック：結果を読む前に、割り振り数にカイ二乗検定をかける。通らなければ、分析の前に原因を調べる。

## 判定ルール
- **リリースする：** [条件]
- **リリースしない：** [条件]
- **結論が出ない：** [どうするか]

## リスク
- [リスク] — [対策]
```

## 例

**入力：** 「登録フォームを短くするテストをしたい（7項目から3項目に）。登録率は料金ページの訪問者の4%。訪問者は週に約6,000人。1ポイント上がればリリースする。」

**出力：**

```markdown
# 実験計画：短い登録フォーム

**担当：** [氏名] · **判断する人：** [氏名] · **開始：** [日付] · **読み出し：** 開始から3週間後

## 仮説
[要確認: 根拠。例：フォーム分析で4項目目の離脱が多い]から、料金ページの訪問者に3項目の登録フォームを出すと登録率が上がると考える。登録率が1ポイント以上（4%から5%に）上がれば正しいと判断する。

## パターン
- **対照（A）：** 7項目のフォーム
- **パターンB：** 3項目のフォーム（メールアドレス、パスワード、会社名 [確認予定]）
- **割り振り：** 50/50 · **対象：** 料金ページの新規訪問者。ログイン中のユーザーは除く

## 指標
| 指標 | 役割 | ベースライン | 閾値 |
|---|---|---|---|
| 登録率 | 主要 | 4.0% | MDE：+1.0ポイント（相対25%） |
| 登録から7日以内のアクティベーション | ガードレール | [未定: ベースライン] | 対照より[値]を超えて下回ったら停止 |
| スパム登録 | ガードレール | [未定: ベースライン] | 2倍になったら停止 |

## サンプルサイズと期間
- α = 0.05 · 検出力 = 80% · ベースライン p = 0.04 · 絶対値でのMDE δ = 0.01
- 見積もり：n = 16 × 0.04 × 0.96 ÷ 0.01² = 1パターンあたり6,144
- テストに入る週あたりのユーザー数：6,000 → 12,288 ÷ 6,000 = 2.05週間 → 3週間
- 確認に使ったツール：始める前にサンプルサイズの計算ツールで確認予定

## 停止ルール
- よい結果が出ても早めに止めない。
- 害があれば停止：スパム登録が2倍になる、またはフォームが送信できない。
- 結果を読む前にサンプル比率をチェックする。

## 判定ルール
- **リリースする：** 登録率が1ポイント以上高く、統計的に有意で、どのガードレールも超えていない。
- **リリースしない：** 登録が増えても、アクティベーションが閾値を超えて下がった。
- **結論が出ない：** 7項目のフォームを残す。次は項目を一つずつ減らすテストをする。

## リスク
- 項目が減ると、営業のフォローに使えるデータが減るかもしれない — どの項目を使っているか営業責任者が確認する。
- 期間中に連休があるとトラフィックが偏る — 開始前にカレンダーを確かめる。
```

## 送る前のチェック

- [ ] 仮説に、変更、対象、指標、MDEが入っている。
- [ ] 主要指標がちょうど一つで、停止の閾値つきのガードレールが一つ以上ある。
- [ ] サンプルサイズの計算が、使った入力とともに示してある。足りない入力は未定と書いてある。
- [ ] 期間が週単位に切り上げてある。
- [ ] 判定ルールが、リリースする・しない・結論が出ないの3つを扱い、判断する人を書いている。
- [ ] ユーザーが出していないベースライン、トラフィック、根拠が入っていない。

## よくある失敗

- トラフィックを見てから、1週間で終わるようにMDEを決める。リリースする価値のある幅でMDEを決め、その期間を受け入れる。
- トラフィックが足りず、検出力が出ないテストを回す。期間がおよそ8週間（このスキルの既定値）を超えるなら、もっと大きな変更をテストするか、ベースラインの高い指標を使う。
- 結果が出てからガードレールを足す。ガードレールは始める前に計画に入れておく。

チームで使う

AI Skill Pod に追加すると、業務委託の方も含めてチーム全員が、自分の AI から同じ版を使えます。 AI スキルをチームで共有する方法を読む

チームのPodに追加

変更履歴

• v1.0.0 · 2026年11月4日 · First release.