experiment-design

実験設計

信頼できる意思決定につながる実験を実施するための、シニアプロダクトマネージャーのプレイブックです。

多くの企業では、実験はずさんな状態から始まります。PM は曖昧な仮説でテストを実施し、結果を早く見すぎ、ガードレールを無視し、ノイズを細分化し、測定誤差による上昇効果がほとんどの機能をリリースします。その代償は現実のものです。間違ったものをリリースし、正しいものを打ち切り、誤った教訓を得て、同じことを繰り返すことになります。

このスキルは、そうした失敗の大半を防ぐための規律です。実験プラットフォーム（Statsig、PostHog、GrowthBook、Optimizely、Amplitude、Eppo、Kameleoon。原則において、どのプラットフォームを使うかは重要ではありません）が稼働していることを前提としています。また、実際に処置を変更できるプロダクトデザインとエンジニアリングのパイプラインがあることも前提です。難しいのは考え方であり、ここではその方法を説明します。

このスキルを使うタイミング：実験を設計したり、結果を解釈したりする際はいつでもお使いください。テストの実施後ではなく、開始前に該当するセクションを読んでください。

---

このスキルで扱う内容

このスキルでは、実験のライフサイクル全体を扱います。実験前の準備（そもそもテストする価値があるのか）。仮説の設計（原因、結果、規模、メカニズム）。サンプルサイズと最小検出可能効果（学びを得るのに十分なトラフィックがあるか）。期間（どれくらいの長さが必要か、サイクルによって結果に偏りが生じるタイミング）。実施上の規律（途中で結果を確認しない、ガードレール、逐次検定）。解釈（3つの分類と結論が出ない場合）。意思決定（事前に決めたルールに結果を照らし合わせる）。

このスキルでは、機能フラグの運用上の仕組みは扱いません。フラグの分類、環境管理、古くなったフラグの整理といった内容は、別の規律を扱う feature-flagging スキルを参照してください。統計分析の詳細も扱いません。デルタ法、CUPED のような分散削減手法、ベイズ法の代替手法については、experimentation-analytics スキルを参照してください。プラットフォーム固有のツールも扱いません。MCP コマンド、認証モデル、プラットフォーム固有の設定については、選択したプラットフォームの公式ドキュメントを参照してください。このスキルは実験設計を作成し、プラットフォームがそれを実装します。

どの実験をどの順番で、どの頻度で実施するかという、その上位のオーケストレーションレイヤーについては、今後公開予定の experimentation-platform-orchestrator スキルを参照してください。このスキルがスケジュールを管理し、こちらのスキルが設計を行います。

---

フレームワーク：信頼できる実験結果のための12の考慮事項

妥当性を説明できる実験設計は、12の考慮事項が交わるところにあります。それぞれについて、以下の各セクションで詳しく説明します。

1. 仮説を厳密に立てる。 原因、結果、規模、メカニズムを明確にします。仮説では、何を検証し、何がどの程度変化し、その理由は何かを示します。
2. サンプルサイズと最小検出効果（MDE）。 選択した検出力で効果を検出するのに十分なトラフィックがあるかを確認します。検出力が不足しているテストは実施しません。
3. テスト期間。 サンプルサイズに達するまでの期間と、週の全サイクルを含む期間のうち、長い方を採用します。UI/UX の変更では、いずれの場合も少なくとも14日間が必要です。
4. A/Bテストを行わないもの。 UX のバグ、法令上必須の変更、ブランド哲学に関する問い、すでに決定済みの判断、クリーンなランダム化ができないデザインです。
5. セグメント分析。 事前登録したセグメントはエビデンスですが、事後的に見つけたセグメントはノイズの掘り起こしです。多重比較の問題は実際に存在します。
6. 交互作用効果。 同じ領域で同時に実施するテストは、互いに干渉する可能性があります。ミューテックスによる制御、または調整が必要です。
7. 比率指標と分散推定。 比率に対する単純な分散推定量は、不確実性を過小評価します。プラットフォームで比率を考慮した推定量が使われていることを確認してください。
8. ネットワーク効果と両面市場。 干渉により、処置が対照群に波及することがあります。必要に応じて、クラスターランダム化、スイッチバック、または地域的な隔離を行います。
9. 逐次検定と結果を繰り返し確認する問題。 毎日結果を確認すると、偽陽性率が上がります。利用できる場合は逐次検定の手法を使い、そうでなければ事前に方針を決めてください。
10. 事前のコミットメントと p-hacking。 開始前に、主要指標、MDE、期間、セグメント、判断ルールを書き留めます。結果が出たら、機械的に適用します。
11. 結果を読み、判断する。 結果は、明確な勝ち、明確な負け、結論が出ない、の3つに分けます。結論が出ない区分には理由があります。それでもリリースしたいという気持ちに抗ってください。
12. よくある失敗と対処法。 すぐに参照できるパターン集です。詳細はreferences/common-failures.mdで説明しています。

以下のセクションでは、各考慮事項を順に取り上げます。実験を実施する前に、該当するセクションを読んでください。実験の後ではありません。

---

仮説の立て方

このスキルで最も重要なセクションです。実験の失敗の大半は、曖昧な仮説に起因します。

本当の仮説には、原因、効果、規模、メカニズムの4つの要素があります。原因は、実施する変更です。効果は、変化すると予想する指標です。規模は、どの程度の変化を、どのベースラインから見込むかです。メカニズムは、この変更がその効果をもたらすと考える理由です。

悪い仮説のよくある例：「新しい料金ページでコンバージョンが増えると考えています。」問題点は、規模（どの程度か）もメカニズム（なぜか）もなく、指標も明確な定義のある特定のイベントではなく「コンバージョン」となっていることです。チームはこのテストを実施して結果を見たあと、何を成功と見なすかを議論することになります。事前の合意は不可能です。何も合意されていないからです。

良い仮説の例（同じ領域）：「3段階の料金比較を、推奨プラン1つに置き換えることで、登録から有料プランへの移行率を8％高める（現在12％、目標13％）。すでに加入する意思があるユーザーの選択に伴う負担を減らせるためです。」原因はプランの置き換えです。効果は、ユーザーがペイウォールに到達してから7日以内に支払いを完了した場合と定義する、登録から有料プランへの移行率です。規模は、12％から13％への8％の相対的な上昇です。メカニズムは、選択に伴う負担の軽減です。これでチームは、検証する対象、達成すべき数値、そして反証可能な説明を得られます。

主要指標とガードレール。主要指標は、変化させようとしている指標です。ガードレールは、悪化させてはならない指標です。たとえば、収益、継続率、サポートチケット件数、ページの読み込み時間、エラー率などです。主要指標は必ず1つだけ選んでください。ガードレールは3～5つ選びます。主要指標を複数にすると、結果が出たときに都合のよいものを選べるため、規律が損なわれます。

反証可能性のテスト。実験を開始する前に、何が起きたらこの変更をリリースしないのかを書き出してください。答えが「何があっても、この変更を実施することに変わりはない」なら、その仮説は本物ではなく、実験は見せかけです。テストを省略し、エンジニアリングの時間を節約して、そのまま変更をリリースしてください。

方向性と規模の違い。変更によって指標が動くことが分かっても、その変化が重要といえるほど大きいかどうかは別の話です。登録コンバージョンの絶対値で0.3％の上昇は、十分なトラフィックがあれば統計的に有意になる可能性がありますが、それでも変更の維持にかかるエンジニアリングコストを正当化できないことがあります。方向性と同じくらい規模も重要です。仮説には、リリースを正当化できる規模を明記します。

一般的な指標のテンプレートと実例については、references/hypothesis-templates.mdを参照してください。

---

サンプルサイズと最小検出可能効果

サンプルサイズは、検出したい効果の逆二乗に比例して増加します。1％の上昇を検出するには、10％の上昇を検出する場合のおよそ100倍のサンプルが必要です。ほとんどの PM はこれを過小評価しています。

基本的な判断基準は次のとおりです。現在のトラフィックと妥当なテスト期間での最小検出可能効果（MDE）が絶対値で5％を超える場合は、MDE の設定が大きすぎる可能性があります。検出に膨大なサンプルが必要な小さな変更は、そもそもリリースする価値がないことがほとんどです。変更が小さいのは、根底にある仕組みが弱いか、実装が控えめすぎるかのどちらかです。仕組みが弱いなら、リリースする価値はありません。実装が控えめなら、テストの前にもっと大胆にするべきです。

「トラフィックが足りない」という落とし穴。ごく小規模なプロダクトでは現実的な話です。それ以外では怠慢です。週に1万人のユーザーがいて、絶対値で0.5％の上昇を検出しようとしているなら、実験ではなくノイズをサンプリングしているだけです。トラフィック量で検出できるほど、期待される効果の大きい変更を選びましょう。変更が本当に小さいなら、テストせずにリリースする（上振れも小さく、下振れも小さく、コストも低い）か、まったくリリースしないでください。

検出力。実際に存在する効果をテストで検出できる能力です。一般的な最低基準は80％です。これを下回ると、運任せになります。テストでは実際の効果を頻繁に見逃すことになります。検出力を高めるには、より多くのサンプルが必要です。ほとんどのプラットフォームではデフォルトが80％です。変更する場合は、その理由を記録してください。

片側検定と両側検定。別の主張をしたくなる場合もありますが、PM が行うテストのほとんどは両側検定です。片側検定は、「正の方向だけが重要で、変更によって結果が悪化しても検出する必要はない」とするものです。これはめったに当てはまりません。新しい料金ページでコンバージョン率が急落したら、それを知りたいはずです。原則として両側検定を使いましょう。本当に片側検定を使いたい場合は、実施前にその非対称性を記録してください。

一般的なコンバージョン率のベースラインと MDE に対応した、事前計算済みサンプルサイズ表については、references/sample-size-tables.md を参照してください。この表は出発点であり、実際のトラフィックと指標に基づいて計算する代わりにはなりません。

---

テスト期間

最短期間は、2つの制約のうち長いほうです。1つ目の制約は、サンプルサイズが計算上必要な数に達することです。2つ目の制約は、テストを少なくとも週次サイクル全体にわたって実施することです。月曜日から水曜日までしかテストしないと、ほとんどの消費者向け製品では平日と大きく異なる週末の動きを見逃します。

新奇性効果。新しいものは注目を集めます。成功しているテストでも、最初の数日間はリフトを過大評価しがちです。ユーザーは変更に気づいてクリックし、新奇性が薄れるにつれて消えていく一時的な効果を生み出します。リフトが新奇性の期間を過ぎても維持されるか確認できる長さで実施してください。サンプルサイズが早く集まる場合でも、UI/UX 実験では通常、2週間が最低期間です。

初頭効果。逆の問題です。既存ユーザーは1週目に変更に抵抗を感じても、3週目には適応することがあります。UIの配置変更テストでよく見られます。結果が悪く見えるからといって1週目にテストを打ち切ると、その期間では初頭効果が本来の効果を上回るという点を見逃します。

ホールドアウト期間。実験で恒久的な機能（通知頻度、デフォルト設定、検索ランキング）を変更する場合は、リリース後少なくとも1か月間、新しい動作を適用しないホールドアウトグループを維持してください。ホールドアウトでは、初日のリフトだけでなく長期的な効果を測定します。長期的な効果は短期的な効果と異なることがよくあります。通知の変更によって初日のエンゲージメントが高まっても、3か月後の継続率が低下する可能性があります。

最長期間。通常は4〜6週間です。それ以上になると、テストを取り巻く状況が変化します。季節性が移り変わり、マーケティングキャンペーンが始まり、製品も進化します。テスト期間中にユーザー層の比較可能性が失われ、介入群と対照群の比較がクリーンでなくなります。検出力を確保するために6週間を超えるテストが必要なら、MDE が間違っている可能性があります。変更が小さすぎて、明確に検出できないのです。

---

A/B テストをしてはいけないこと

実験についての議論では省かれることの多いセクションです。率直に述べる価値があります。

UX のバグ修正。現在の動作に明らかな問題がある場合（ボタンが動作しない、文言が間違っている、アクセシビリティに問題があるなど）は、修正してください。A/B テストは見せかけにすぎません。正しい答えは「ユーザーが動作するボタンを好むか見てみよう」ではなく、動作するボタンをリリースすることです。

法律で義務付けられている変更。GDPR の同意フロー、アクセシビリティへの準拠、規制上の免責事項などです。リリースしてください。リフトは関係ありません。重要なのは法令遵守です。法令を遵守すべきかどうかを A/B テストするのは、真剣に検討すべき問いではありません。

戦略的、または哲学的なブランドに関する問い。「ブランドの語り口は、遊び心のあるものと真面目なもののどちらにすべきか？」は A/B テストの問いではありません。ブランドエクイティ、オーディエンスの期待、長期的なポジショニングを踏まえ、背景を理解する人間が決めるべきブランド戦略の問いです。クリック率が高いバリエーションを選んでも、この問いへの答えにはなりません。クリック率はブランドの意思決定基準ではないからです。実験データはブランドに関する意思決定の材料の一つとして使い、それ自体を意思決定にしないでください。

すでに決定していること。テスト結果にかかわらず、経営陣がある方針にコミットしているなら、実験を実施しないでください。結果が意思決定を変えないテストを行うという見せかけの A/B テストは、実験の規律全体に対する信頼を損ないます。他の PM はテストを見て、結果が無視されるのを見て、この会社では実験結果が重要ではないと結論づけます。すると、事前に判断基準を決めなくなります。そして、実験の規律は崩壊します。

テスト設計が不可能なこと。デバイスをまたぐエクスペリエンス、ネットワーク効果、10人の運用チーム向けの社内ツールなど、サンプルサイズが根本的に小さすぎるものや、ランダム化が根本的に汚染されるものです。定性調査、縦断的なコホート分析、あるいは単にリリースして様子を見ることが適切な場合もあります。クリーンに設計できない実験から、クリーンな答えは得られません。

---

セグメント分析

事前登録したセグメントと、事後的に見つけたセグメント。テストの実施前に「新規ユーザーとリピーターの結果を確認する」と宣言しておくのは問題ありません。テスト後に「火曜日にモバイル経由で登録したカリフォルニア州のユーザー」で大きな効果があったと気づくのは、ほとんどの場合、ノイズを掘り起こしているにすぎません。

多重比較の問題。分析するセグメントを一つ増やすたびに、偶然「有意な」結果が見つかる確率は高くなります。互いに独立したセグメントが20個あり、p＝0.05の場合、まったくの偶然による偽陽性が一つは見つかると予想されます。セグメントが50個なら、2つか3つです。50個のセグメントを分析して、有意になったものだけを報告してはいけません。

層別化が役立つ場合と、誤解を招く場合。次の3つがすべて当てはまる場合、層別化は有効です。そのセグメントが事前登録されていること。そのセグメントで行動が異なると予想する根拠が実際にあること。設定した検出力で効果を検出できるだけのサンプルが、そのセグメント内にあること。このうち一つでも欠けていれば、層別化はノイズを掘り起こしているにすぎません。基本方針は、全体の結果を報告することです。事前登録したセグメントは、追加の参考情報として報告します。計画していなかったセグメントは報告しません。

「加重平均」という捉え直し。あるセグメントでは処置の効果がプラスで、別のセグメントではマイナスの場合、問うべきなのは「効果のあるセグメントだけに出荷しよう」ではなく、「実際に出荷する対象の母集団全体での加重平均効果はどれくらいか」です。特定のセグメントだけに出荷するには、通常、UIの複雑化、対象ユーザーを絞り込むためのインフラ、継続的な保守が必要ですが、セグメント固有の効果はそれに見合わないことが多いです。特定のセグメントだけに出荷することに慎重な姿勢を取るのは健全です。

---

交互作用効果

よくある問題です。チェックアウトフローで5つのA/Bテストを同時に実施しています。それぞれのテストでは小さな効果が見られます。しかし、組み合わせたときに効果が単純に掛け合わさるとは限りません。単純に足し合わせられるとも限りません。個別のテストでは明らかにならない形で、互いに影響し合う可能性があります。

実験前の準備。新しい実験を開始する前に、同じ画面や機能でほかにどの実験が進行中か確認してください。ほかのPM担当者に尋ねてください。どのテストを相互排他的にし、どのテストを重複させてもよいか調整してください。

ミューテックス（相互排他的）実験グループ。ほとんどのプラットフォームは、テストAのユーザーがテストBにも割り当てられないようにする除外ルールに対応しています。交互作用が起こりそうな場合は、これを使ってください。代償はサンプルサイズで、得られるメリットは結果の解釈可能性です。重要度の高いテストが少数なら、ミューテックスが適切です。重要度の低いテストが数十件ある場合、完全なミューテックスは現実的ではありません。その場合は、重複を調整し、記録してください。

「あとで分析すればよい」という誤謬。重複する実験を事後的に切り分けるのは難しく、費用もかかり、たいてい結論が出ません。交互作用効果を分離できる要因計画には、ほとんどのプロダクトでは確保できないほどのサンプルサイズが必要です。あとから解きほぐすのではなく、事前に調整してください。

---

比率指標とデルタ法

落とし穴。コンバージョン率は、コンバージョン数をユーザー数で割った比率です。生のカウントに対する標準偏差の計算を、そのまま比率に適用することはできません。比率指標に単純な分散推定を使うと、信頼区間が狭くなりすぎ、信頼度を過大評価して、誤ったリリース判断につながります。

重要な理由。多くの実験プラットフォームでは、比率指標に対してデルタ法（またはブートストラップなど、比率を考慮した推定法）が密かに使われています。お使いのプラットフォームで使われていなければ、信頼区間は正しくありません。しかも、重要な方向に誤っています。有意に見えても実際には有意でないものをリリースしてしまいます。

確認方法。プラットフォームのベンダーに、「比率指標にはどのような分散推定法を使っていますか」と尋ねてください。答えが「割合に対する標準的な t 検定」なら、単純な二値コンバージョン（ユーザーごとに1行で、コンバージョンしたかどうか）以外の比率については誤りです。「デルタ法」「ユーザーレベルで再サンプリングするブートストラップ」「テイラー展開による線形化」などの答えなら適切です。他にも妥当な答えはあります。重要なのは、プラットフォームチームが比率を考慮した推定法をきちんと説明できるかどうかです。

具体例。ユーザーあたりの収益は、総収益を総ユーザー数で割った比率です。比率を考慮した推定法を使わないと、RPU の上昇率は信頼度が過大評価されがちです。報告された上昇率が5％で p 値が0.04でも、分散を正しく計算すると、実際には統計的有意性のない点推定値が5％だったにすぎない可能性があります。誤った計算に基づいてリリースすると、本番環境で主張された効果をもたらさない変更をリリースすることになります。

分散削減（CUPED、層化サンプリング、制御変量）について詳しくは、リリース後に experimentation-analytics スキルを参照してください。

---

ネットワーク効果と両面市場

干渉の問題。両面マーケットプレイス（Uber、Airbnb、eBay、DoorDashなど、買い手と売り手がいるあらゆるプラットフォーム）では、買い手向けの処置が、テストの対象グループに含まれているかどうかにかかわらず、売り手に影響を与える可能性があります。買い手の需要を増やす処置は、売り手の行動を変化させます。同じ売り手を取り合っている「対照群」の買い手も、処置群の買い手の行動によって供給状況が変わることになります。その結果、テストでは処置の効果を正確に測れず、処置の効果に干渉の影響が加わったものを測定してしまいます。

よくあるパターン。対照群が汚染されるマーケットプレイス実験です。効果の半分が対照群に漏れたため、テストでは小さな効果しか報告されません。チームは真の効果を過小評価し、有望なアイデアを却下して、誤った教訓を得てしまいます。

緩和策（いずれも完璧ではありません）。クラスター無作為化では、個々のユーザーではなく、市場全体（都市、地域、市場セグメント）を処置群または対照群に割り当てます。クラスター内の干渉は排除できますが、実効サンプルサイズが桁違いに小さくなります。スイッチバック実験では、時間枠ごとに母集団全体を処置群と対照群に交互に割り当てます（第1週は処置、第2週は対照、第3週は処置など）。ユーザー間の干渉は排除できますが、慎重な時間的モデリングが必要です。地理的な分離では、他の地域のネットワークを従来の動作のままにして、1つの都市で実験を行います。干渉は排除できますが、費用も時間もかかります。

定性的な調査に切り替えるタイミング。干渉が深刻で、無作為化によって分離できない場合、テストでは知りたいことがわかりません。ユーザー調査、縦断的なコホート分析、または計測を慎重に行う段階的なロールアウトに切り替えてください。判断すべきなのは「効果が有意だったか」ではなく、「ロールアウトのモニタリングに投資するだけの効果があると考えられるか」です。

---

シーケンシャルテストと途中結果を覗く問題

途中結果を覗く問題。毎日結果を確認し、有意差が見られた時点でテストを止めると、偽陽性率は名目上の5％を大きく上回ります。標準的な統計検定では、テストの終了時に1回だけ分析することを前提としています。分析を複数回行うと、αが膨らみます。

数値で見ると、分析を1回行う場合の偽陽性率は5％（α＝0.05の場合）です。テスト期間中に3回分析すると、偽陽性率は14％近くまで上昇します。28日間のテストで毎日結果を覗くと、偽陽性率は30％を超えることがあります。実際には存在しない「有意」な結果を目にしてリリースし、本番環境で再現しない様子を見ることになります。

シーケンシャルテストの手法。最新のプラットフォームの多く（Statsig、Eppo、PostHogの一部、mSPRTを備えたGrowthBook）では、αを膨らませずに毎日結果を覗けるよう、計算を調整するシーケンシャルテストに対応しています。こうした手法には、逐次確率比検定、群逐次デザイン、混合逐次確率比検定（mSPRT）による常に有効なp値などがあります。プラットフォームが対応している場合は、これらを使用してください。テスト途中の推論を適切に行える代わりに、統計的検出力が多少犠牲になります。

事前に登録する停止ルール。プラットフォームがシーケンシャルテストに対応していない場合は、テストを実施する前に分析予定日を宣言してください。事前の取り決めを保存しておきます。予定日までは結果を確認しないでください。どうしても確認せざるを得ない場合（確認せずに済ませるのが難しいプラットフォームもあります）は、目にした結果を根拠に判断しないでください。判断を行うのは、早期の結果が好ましく見えたときではなく、事前に決めた分析予定日です。

「結果が非常に良さそうだから早めにリリースする」という罠。結果は、ほとんどの場合、14日目より3日目のほうが劇的に見えます。平均への回帰が起こり、新奇性は薄れ、指標は安定します。所定の期間を最後まで実施してもなお良好な結果が出るテストこそ、リリースする価値があります。「初期の結果が良かった」ため早々にリリースされたものは、本番環境で期待外れに終わる割合が高くなります。

---

事前の取り決めとpハッキング

pハッキングの例。結果が期待どおりにならないときに、人々がしばしば無意識に行うこと：

• 有意差が出るまで追加のセグメントを分析する
• 見出しの結果が変わるまで「外れ値」を除外する
• テストの途中で主要指標を切り替える
• テスト期間を「もう少しだけ」延長する
• データが示した内容に合うよう、仮説を言い換える
• 結論が出なかった複数のテストを「傾向」としてまとめ、リリースの根拠にする

それぞれは、小さな判断に思えます。しかし積み重なると、規律が損なわれます。その結果は「実際の効果を発見した」ではなく、「何かが有意に見えるまで分析のつまみを回し続けた」となります。

事前の取り決めによる解決策。テストを実施する前に、次のことを書き留めます。主要指標とその計算方法、検出できるように検出力を確保したMDE、暦日での期間、分析するセグメント（ある場合）、考えられる各結果をリリースまたは中止の判断に対応づける決定ルールです。タイムスタンプ付きで、事前の取り決めをどこかに保存してください。実験設定をリリースするPRの説明文でも、署名付きのSlackメッセージでも、ピン留めしたチケットでもかまいません。後から変更できない場所に保存します。

結果が出たら、事前の取り決めに従います。結果が明確でリリースしたい場合は、リリース申請を提出します。結果が悪く中止したい場合は、中止します。結論が出なかった場合は、以下で説明する結論が出ない場合の解決手順に従い、新たな分析を作り出さないでください。

「多くのことを学べた」という罠。テストを実施した結果、結論が出なかった場合、答えは「結論が出なかった」です。「根底にある仕組みは予想より複雑だと分かった」でも、「興味深いセグメントの動態を発見した」でもありません。結論が出なかったなら、結論は出ていません。何か教訓があるとしても、それは次の仮説に活かすものであり、今回の仮説に後付けするものではありません。

---

結果を読み取り、判断を下す

結果は3つに分類します。明確な勝利ならリリースします。明確な敗北なら中止します。結論が出ない場合は、最も判断が難しいケースです。

結論が出ない場合の対応策を、望ましい順に並べます。

1. 変更のコストが低く、元に戻せるため、そのままリリースします（ガードレールに問題がなく、その変更が有害だという情報が本当にない場合に限り、正当化できます）。ここで求められる基準は高く、「動いた方向は良かった」だけでは不十分です。
2. 規模を拡大して実施します。トラフィックや期間を増やし、変更をより大胆にできる場合はMDEを大きくします。結論が出なかった結果は、当初の検定力が不足していた、または効果が予想より小さいという証拠として扱います。
3. アイデアを中止します。最もよくある正しい判断ですが、PMは仮説に投資しているため、実行するのが最も難しい対応です。
4. 仮説を見直して再検証します。結論が出なかった結果を使って、作用の仕組みを洗練させます。新しいテストは継続ではなく新規のテストです。改めて事前に判断基準を決めてください。

ベイズ的な考え方を加えます。事前の確信が強かった場合（ユーザー行動についてわかっていることを考えれば、明らかにうまくいくはずだと考えていた場合）、結論が出なかった結果でも、確信度はある程度更新されるはずです。事前の予想が間違っていたのか、効果が予想より小さいのか、あるいは実装が控えめすぎて効果を捉えられなかったのかもしれません。事前の確信が弱かった場合（何が起きるか本当に見当がつかなかった場合）、結論が出なかった結果はそのまま結論が出なかったということです。事前の予想はすでに不確かで、結果もその不確かさを解消しませんでした。

最も判断が難しいケースは、主要指標が良好でもガードレールが曖昧な場合です。売上は増えたものの、サポートへの問い合わせも増えました。コンバージョンは増えたものの、セッション時間は減りました。事前に定めた判断ルールを使ってください。ガードレールとのトレードオフについて事前に決めていなかった場合は、「リリースしない」を既定の判断にしてください。ガードレールは、結果を見る前から重視していた指標です。結果を見た後で基準を引き下げてはいけません。

結果を読み取るための手順ごとのチェックリストは、references/results-interpretation-checklist.md を参照してください。

---

よくある失敗と対処法

要点をまとめたリファレンスです。それぞれのパターンの詳しい説明は、references/common-failures.md を参照してください。

• 「トラフィックが足りなかった」は、MDEが小さすぎたことを意味します。検出する価値のある、より大きな変更を選んでください。
• 「リリース後に効果が消えた」は、テスト期間が5日間で、新奇性効果を捉えたことを意味します。次回はより長く実施してください。UIの変更では最低2週間必要です。
• 「新規ユーザーには効果があったが、再訪ユーザーにはなかった」は、そのセグメントが事後的に選ばれたもので、おそらくノイズだったことを意味します。全員にリリースするか、中止してください。そのセグメントにだけリリースしてはいけません。
• 「12日間、途中で何度も確認した結果、p値が0.04に上がった」は、偽陽性率が名目上の値よりはるかに高いことを意味します。事前に判断基準を定め、逐次検定を使用してください。
• 「売上は増えたが、リテンションは低下した」は、ガードレールに抵触したことを意味します。リリースしてはいけません。
• 「結果を再現できない」は、最初の結果がノイズか、プラットフォームのバグだった可能性が高いことを意味します。再実行する前に調査してください。
• 「コンバージョンは増えたが、新しい広告キャンペーンによるボットのトラフィックが原因だった」は、外部イベントが結果を交絡させたことを意味します。影響を受けやすいテストの実施中はキャンペーンを停止するか、獲得元ごとに層別化してください。
• 「テストを実施したが結論が出ず、傾向の方向性が見えたのでリリースした」は、自分たちの規律を無視したことを意味します。結論が出ないという分類があるのには理由があります。傾向のパターンを証拠の代わりにしてはいけません。

---

必要なデータを入手できない場合

このスキルの出力は、単独では生成できないデータ、測定値、またはツールの結果に依存します。必要な入力、ツール、またはデータソースが利用できない、あるいは検証できない場合、許容される出力は不足を明示した成果物です。何が必要だったのか、実際に何を取得または検証できたのか、出力のどの部分に影響するのかを記載してください。成果物を完成させるために必要な数値を捏造、推定、または補間することは、決して認められません。不足を明示すれば、それが完全な回答です。

---

参考ファイル

• references/hypothesis-templates.md。因果関係・効果の大きさ・メカニズムのテストに合格する仮説を書くための具体的な形式です。コンバージョン、エンゲージメント、収益、リテンション、ファネルのステップ指標など、さまざまな指標タイプの例を紹介しています。
• references/sample-size-tables.md。一般的なコンバージョン率実験向けの、事前計算済みサンプルサイズ表です。使い方と、サンプルサイズ計画でよくある落とし穴も解説しています。
• references/common-failures.md。誤ったリリース判断につながる15のアンチパターンを、それぞれ症状、根本原因、対処法、予防策とともに紹介しています。
• references/results-interpretation-checklist.md。結果を読み解くための段階的なチェックリスト、3つの判断区分（成功、失敗、結論が出ない）の決定マトリクス、リリース後のモニタリング手順を記載しています。
• references/platform-comparison.md。主要な実験プラットフォーム（Statsig、PostHog、GrowthBook、Optimizely、Amplitude、Eppo、Kameleoon）の特徴、注意点、選定用の決定マトリクスをまとめています。
• references/pre-experiment-readiness-checklist.md。リリース前に実施する10項目の実施可否チェックリストです。
• references/post-experiment-decision-framework.md。判断時のフレームワークです。事前のコミットメントを確認し、ルールを機械的に適用し、リリース・中止・結論保留の各手順に振り分け、1週間以内に事後分析を書く方法をまとめています。

---

締めくくり：判断に迷ったときは

基本姿勢は慎重です。結果が不明確な場合は、リリースしないでください。偽陰性（実際には成功していたものをリリースしなかった）のコストは、通常、偽陽性（実際には機能しないものをリリースし、今後ずっと保守しなければならなくなった）のコストより小さいです。保守コストは積み重なりますが、機会損失のコストは積み重なりません。いつでも再びテストできるからです。

実験設計の規律とは、わからないときに「わかりません」と率直に言う規律です。それを口にすることは、PMがその週に行う仕事のなかでも、とりわけ大きな影響をもたらすことがあります。結果が実際よりも確かなものだと思い込んで、決断力があるように見せるためにリリースし、変更が本番環境で機能しなかったときには、ひそかに失敗を受け入れる。そうしたいという衝動に駆られるものです。ですが、規律ある対応は、「テストでは結論が出ませんでした。確かな答えを得るために変更する点はこれです。新しいテスト計画はこちらです」と伝えることです。そう伝えるのがプロフェッショナルです。それ以外のふりをするのは、見せかけにすぎません。

プラットフォーム固有のパターン（どのプラットフォームがどの実験タイプに最適か、MCP コマンドの形式、注意すべき点）については、選択したプラットフォームのドキュメントを参照してください。このスキルの下位にある運用レイヤー（フラグの管理、古いフラグの廃止、環境の調整）については、feature-flagging スキルを参照してください。このスキルの上位にある分析レイヤー（分散の削減、ベイズ的な代替手法、逐次検定の計算）については、experimentation-analytics スキルを参照してください。