mcpField
E
experimentation-analytics

experimentation-analytics

github.com/rampstackcoデータ・データベース1.0k239 回インストール1 週間前に更新
リポジトリ

experimentation-analytics について

実験結果を読むプロダクトマネージャーやデータアナリスト向けの解説スキルです。信頼区間や p 値の解釈、多重検定、実験パネルと BI データの照合を扱います。

主な機能

  1. 01信頼区間と p 値の解釈
  2. 02多重検定リスクの把握
  3. 03逐次検定と途中確認の理解
  4. 04実験パネルと BI データの照合

活用シーン

  1. 01結果を基に実験の公開や中止を判断
  2. 02データ不足による結論の不確実性を評価
  3. 03指標やセグメント別の発見を検証

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/rampstackco/claude-skills --skill experimentation-analytics

インストール後、Claude Code で/experimentation-analyticsを入力して読み込まれたか確認します。

同梱ファイル

SKILL.md と一緒にインストールされる参考資料やスクリプト。

README.md
references/
analytics-platform-comparison.md
common-interpretation-failures.md
confidence-interval-cheatsheet.md
dashboard-vs-experiment-reconciliation.md
p-value-interpretation-guide.md
result-presentation-templates.md
statistical-method-reference.md

詳細

実験分析

実験結果を自分に都合よく解釈しないための、データチーム向けメンターの実践ガイドです。

結果パネルは、実験の正念場です。そこに表示された数値によって、リリースするか、中止するか、改善を続けるかが決まります。また、設計段階で取られた近道もすべて明らかになります。検出力が不足したテストでは信頼区間が広くなり、途中で結果を確認したテストでは p 値が不自然に小さくなり、デルタ法による補正を行わない比率指標ではリフトの推定値に過剰な確信が生まれます。誤ったものをリリースする判断のほとんどは、結果パネルの読み違いに端を発します。

このスキルは、読み違いを防ぐための規律です。実験が適切に設計されていること(experiment-design スキルを参照)、プラットフォームの結果パネルが技術的に正しいこと(最新のプラットフォームの大半は正しいものの、一部の古いものはそうではありません)、そして画面上の数値を読み取れることを前提としています。難しいのは、それぞれの数値が実際には何を意味し、何を意味しないのかを理解することです。このスキルでは、それを扱います。

このスキルを使う場面:実験結果パネルを確認し、リリース、中止、改善のいずれかを決めようとしているときはいつでも。


このスキルの目的

このスキルでは、結果の解釈、数値の信頼性を支える統計的概念、そして実験の数値と BI の数値が一致しないときに経営層の混乱を防ぐダッシュボードの照合作業を扱います。対象読者は、実験結果を一緒に読み解き、統計の危険な部分を覆い隠さない共通の語彙を必要とするプロダクトマネージャーとデータアナリストです。

関連分野は、補完的なスキルで扱います。experiment-design スキルでは、仮説、サンプルサイズ、MDE、セグメント、テストしてはいけない内容など、実験前の検討事項を扱います。テストを設計する前に読み、結果を読むときにこのスキルを読んでください。feature-flagging スキルでは、フラグ管理、環境への昇格、古いフラグのクリーンアップなど、運用上の仕組みを扱います。この 3 つのスキルを合わせることで、実験の意図から結果の解釈まで、実験ライフサイクル全体を網羅できます。プラットフォーム固有の MCP コマンドについては、選択したプラットフォームのドキュメントを参照してください。Statsig、PostHog、Optimizely、GrowthBook、Eppo、Amplitude、Kameleoon はいずれも豊富な分析機能を提供しており、このスキルはその読み解き方を示します。


結果パネル:最新のプラットフォームに必須の表示項目

以下の項目が 1 つでも欠けている結果パネルは、ブラックボックスです。ブラックボックス型のプラットフォームの結果は特に慎重に扱い、不足している項目を自分で計算できるよう、割り当てデータとイベントデータをエクスポートしてノートブックに取り込むことを検討してください。

信頼できるプラットフォームに表示される項目:

  • バリアントとトラフィック配分(例:50/50、33/33/33)。テスト期間中に配分がずれる場合は、割り当ての不具合が疑われます。
  • バリアントごとの主要指標:点推定値、信頼区間(ベイズ法では信用区間)、バリアント単位のサンプルサイズ。
  • リフト:バリアントからコントロールを差し引いた値を、絶対変化量と相対変化率の両方で表示します。どちらの数値も重要です。相対値は直感的に理解しやすく、絶対値は収益の計算に用いられます。
  • 統計的有意性:p 値(頻度論的手法)または最良である確率(ベイズ法)。どの解釈規則が適用されるか分かるよう、手法を明確に示す必要があります。
  • 適用された分散削減手法:CUPED、事後層別化、回帰調整。プラットフォームがこれらを明示せずに適用する場合は、どの手法なのか確認してください。
  • ガードレール指標のステータス:各ガードレールを、許容範囲に対して緑、黄、赤で示します。許容範囲は設計時に設定し、パネルはその適用を担います。
  • 事前登録済みのセグメントに限ったセグメント別結果。事後にセグメントを切り替えて確認するのは魅力的ですが、危険です。
  • テストのステータス:実行中、終了、判断記録済み。
  • テスト期間中のリフトの時系列。ここで新奇性効果、初頭効果、割り当ての不具合が明らかになります。

結果パネルにこれらの項目が表示されていない場合、最初にすべきことはリリースではなく、それらを表示させることです。


信頼区間:最も重要な数値

結果パネルで最も重要な数値は、リフトの信頼区間(CI)です。点推定値よりも、p値よりも重要です。CIは、実際に何が分かっているかを示します。

95% CI が[+2%、+6%]の場合の意味:サンプリングを繰り返すと、真の効果は95%の確率でこの範囲に収まります。真の効果はおそらく中央付近にありますが、両端の値もデータと完全に整合しています。

意味しないこと:「真の効果が+2%から+6%の間にある確率が95%」という文字どおりの意味ではありません。これはベイズ信用区間の意味であり、多くの場合、数値上は似た答えになりますが、概念的には異なります。PMは大まかな直感で通常は問題ありませんが、アナリストは懐疑的な相手に数値を説明するときに備えて、正確な意味を知っておくべきです。

多くのリリース判断では、CIの中央よりも幅が重要です。CIの幅が広い場合、まだ分かっていることは多くありません。幅が狭い場合は、精度高く分かっています。点推定値は最善の推測であり、幅は慎重さを示します。

重要度順の実践的な判断基準:

  1. CIにゼロと、意味のある正の数値(たとえば[-1%、+5%])の両方が含まれる場合、リリースを判断するにはデータが不十分です。以上です。点推定値は好ましく見えるかもしれませんが、データは効果がない場合とも、意味のある成果がある場合とも整合しています。どちらなのかは判断できません。
  2. CIがすべて正の値(下限がゼロより大きい。たとえば[+1%、+4%])であれば、実際に効果があります。次に大きさを評価します。下限は実装コストに見合う大きさでしょうか?
  3. CIがすべて負の値(上限がゼロ未満。たとえば[-5%、-1%])であれば、実際に悪影響があります。テストを中止してください。
  4. CIがゼロをまたぐものの幅が狭い場合(たとえば[-0.5%、+0.5%])、これは実質的に効果なしという結果です。効果は実質的にゼロとみなせるほど小さいです。有用な情報です。「リフト」を理由に変更をリリースする必要はありません(リフトがないと分かったため)。ただし、悪影響を心配する必要もありません。
  5. CIがゼロをまたぎ、幅も広い場合(たとえば[-5%、+8%])、テストの結果は決定的ではありません。データは、中程度の成果、効果なし、中程度の損失のいずれとも整合しています。実施期間を延ばす、規模を大きくする、または利用可能なトラフィックでは問いに答えられないと受け入れる、のいずれかを選んでください。

計算例付きチートシートは、references/confidence-interval-cheatsheet.mdを参照してください。


P 値:何を意味し、何を意味しないか

P 値とは、真の効果がゼロである場合に、観測されたリフト(またはそれ以上のリフト)が得られる確率です。P 値が 0.04 ということは、効果がないという帰無仮説のもとでは、この程度のリフトが偶然だけで得られるのは約 4%の確率だという意味です。

頻繁に誤用されていますが、P 値は次のことを意味するものではありません。

  • 「処置が有効である確率が 96%」という意味ではありません。この文には正当な解釈がありません。P 値は処置が有効ではないという前提で計算されるため、処置が有効である確率を示すことはできません。
  • 「効果が大きい」という意味ではありません。ごく小さな効果でも、膨大なサンプルを対象に検定すれば、非常に小さな P 値になることがあります。P 値が示すのは帰無仮説に反する証拠の強さであり、効果の大きさではありません。
  • 「結果が再現される」という意味ではありません。P 値が 0.04 の場合、ほとんどの公表研究では再現率は 50%を大きく下回ります。統計的有意性は再現性を意味しません。

0.05 という基準は慣例であって、絶対的な決まりではありません。あらかじめ α を 0.05 と定めていた場合は、それに従ってください。事前に決めておくという規律は、具体的な基準値よりも重要です。事前に決めていなかった場合、P 値が 0.06 なのと 0.04 なのとで決定的な違いがあるわけではありません。それを決定的な違いとして扱うのは見せかけにすぎません。

P 値と合わせて、必ず信頼区間(CI)も確認してください。P 値は帰無仮説について、CI は効果の大きさについて教えてくれます。どちらも重要ですが、単独では十分ではありません。CI が [+0.1%, +0.3%] の場合、P 値 0.001 は実在するものの実用上はごく小さな効果を示します。一方、CI が [-1%, +12%] の場合、P 値 0.08 は大きな効果の可能性も、効果ゼロの可能性もある、不確実な推定値を示します。前者は技術的には有意でもリリースする価値はなく、後者は技術的には有意でなくても、さらに詳しく調べる価値があるかもしれません。

途中で何度も結果を確認する問題は、P 値にも直接当てはまります。標準的な P 値は、テスト終了時に 1 回だけ分析することを前提としています。複数回分析すると、偽陽性率が上昇します。逐次検定に対応した最新のプラットフォームは、途中で結果を確認しても有効性が保たれる「常時有効」または「いつでも有効」な P 値を報告しますが、旧式のプラットフォームはそうではありません。どちらを確認しているのか把握しておきましょう。詳しくは references/p-value-interpretation-guide.md をご覧ください。


多重検定の補正

問題を一文で言うと、独立した比較を20件、αを0.05として行うと、偶然だけで偽陽性が1件出ると予想されます。比較が50件なら2〜3件、100件なら5件です。

意図せず多重検定が発生する場面:

  • 複数のバリエーション:AとB、C、Dを比較する場合、対照群とのペア比較は1回ではなく3回です。
  • 複数の指標:主要指標に加えてガードレール指標を6つ、副次指標を3つ追跡すると、どこかで有意差が見つかるチャンスは10回あります。
  • 複数のセグメント:10セグメントに指標が3つずつある場合、チャンスは30回です。
  • 複数の時間枠:第1週、第2週、第3週、そしてテスト全体を確認すると、指標とセグメントの組み合わせごとにチャンスは4回あります。

知っておくべき補正方法は2つです。

  • ボンフェローニ補正。αを比較の数で割ります。保守的な方法で、検定群全体におけるファミリーワイズ誤差率(検定群全体で偽陽性が1件でも発生する確率)を制御します。偽陽性が致命的な場合に使います。
  • Benjamini-Hochberg(BH)補正。より保守性が低く、偽発見率(有意と判定されたもののうち、偽陽性が占める割合の期待値)を制御します。探索的分析に適しています。

最新のプラットフォームの多くは、設定オプションとしてこれらを標準でサポートしています。設定するか、プラットフォームがデフォルトでどの補正を適用するかを把握しておきましょう。表示するp値に補正を自動的に適用するプラットフォームもあれば、補正前の数値を報告し、計算をユーザーに任せるプラットフォームもあります。

PM向けの経験則:主要指標と主要セグメントを事前登録します。それ以外はすべて探索的なものとして扱います。主要ではない指標やセグメントでの結果に基づいてリリースを正当化するには、より大きな効果があること、追試で再現すること、またはその両方が必要です。主要な指標とセグメントをあらかじめ指定する習慣は、どんな補正式よりも多重検定の落とし穴から身を守ってくれます。


逐次検定の計算

分析の観点から、途中経過をのぞく問題を改めて考えます。従来のt検定、z検定、比率検定では、テスト終了時に1回だけ分析することを前提としています。テスト中にデータを5回分析し、有意差が見えた時点で停止すると、偽陽性率は名目上の5%を大きく上回ります。4週間のテストで毎日途中経過を確認すると、偽陽性率は30%を超えることがあります。

逐次検定の手法では、偽陽性を増やさずに継続的なモニタリングができるよう、計算方法を調整します。次の用語を目にするでしょう。

  • mSPRT(混合逐次確率比検定)。「常時有効」なp値を算出します。いつ確認しても、偽陽性率は名目上のαに保たれます。最新のプラットフォームでよく使われています。
  • 群逐次デザイン。事前に中間分析の回数(たとえば3回)を決め、それぞれの分析で調整済みの有意水準を使います。mSPRTほど柔軟ではありませんが、よく理解されています。
  • 常時有効な信頼区間。常時有効なp値の信頼区間版です。固定期間の信頼区間より幅が広いのは設計上のもので、途中経過を確認できるようにする代わりに、統計効率が多少低下します。

逐次検定を組み込んだ最新のプラットフォーム:Statsig(デフォルトで常時有効)、Eppo(設定で逐次信頼区間を選択可能)、PostHogの一部(実験の種類による)、GrowthBook(mSPRTをサポート)。パネルに「常時有効なp値」または「いつでも有効な信頼区間」と表示されていれば、それは逐次検定です。修飾語なしで「p値」とだけ表示されていれば、固定期間方式であり、途中経過の確認によって偽陽性が増える可能性があります。

プラットフォームが逐次検定をサポートしていない場合は、開始時に分析日を1日に決め、途中経過を見ず、どうしても確認しなければならない場合でも、その結果に基づいて意思決定しないようにします。意思決定は、事前に決めた日まで保留します。これは大変です。逐次検定を使えば、より簡単になります。

トレードオフ:同じサンプルサイズの場合、逐次検定は固定期間検定より信頼区間が広く、p値も有意になりにくくなります。実際にコストはかかりますが、途中経過を見ない規律を保つのが現実的でないPMの業務では、通常それだけの価値があります。


CUPED による分散の低減

CUPED(Controlled-experiment Using Pre-Experiment Data)は、同じユーザーの実験前の行動を使ってベースラインを差し引き、処置効果のシグナルをより明確にします。その結果、点推定値はそのままに、信頼区間が大幅に狭まります。多くの場合、30%から50%狭まり、実質的にサンプルサイズを無料で約2倍にするのと同等です。

CUPED が有効な場合:

  • 実験前のベースラインの分散が大きい指標:ユーザーあたりの収益、ユーザーあたりのセッション数、エンゲージメント時間、コンテンツの消費量。
  • ユーザーに意味のある利用履歴があるテスト(ログイン済みユーザー、特定の日付より前から利用しているユーザー)。
  • 実験前の行動が実験中の行動を強く予測する、長期運用中のプロダクト。

CUPED が有効でない場合:

  • 実験前のデータがない新規ユーザー。
  • 実験前のベースラインがない一度限りのコンバージョン指標(ユーザーが登録するかどうかの二択で、差し引くものがありません)。
  • 実験前の行動と、変化させようとしている指標との相関がほとんどないテスト。

CUPED 調整済みの結果の見方:点推定値は未調整の推定値とほぼ同じで、信頼区間(CI)はより狭くなります。CUPED を使うと「有意」だった結果が、CUPED を使わないと「有意でない」に変わるのは通常のことであり、CUPED 調整済みのほうが検出力の高い検定です。逆に、CUPED を使わない場合は有意で、使うと有意でなくなった場合、未調整の結果はおそらくノイズであり、CUPED がそれを正しく取り除いたと考えられます。

よくある誤解:「CUPED でリフトが小さくなったので、未調整のバージョンをリリースすべきです」。これは誤りです。CUPED が低減するのは分散であり、点推定値ではありません。CUPED の適用後にリフトが小さく見える場合、未調整のリフトは実験前の行動との偶然の相関によって膨らんでいた可能性が高く、CUPED の推定値のほうが真の効果に近いものです。調整済みのバージョンを信頼してください。

プラットフォームの対応状況:Statsig、Eppo、GrowthBook、PostHog の一部、Amplitude(Experiment 製品)。Optimizely には同等の分散低減機能があります。利用しているプラットフォームで CUPED が提供されている場合は、実験前のデータがあるすべての指標で有効にしてください。

CUPED、デルタ法、その他の統計手法について詳しくは、references/statistical-method-reference.md を参照してください。


異質な処置効果(HTE)とセグメント

異質な処置効果とは、セグメントによって処置の効果が異なることです。新規ユーザーでは+5%、パワーユーザーでは-2%となり、平均は+1%です。これはよくあることで、多くの場合興味深いものですが、結果を過大解釈しがちです。

HTEに惹かれる理由は、「新規ユーザーにだけリリースすればよい」という考えです。危険な理由は、事後的なセグメントの発見は多くの場合ノイズであること、ターゲティングのためのインフラには実コストがかかること、セグメントごとの挙動によってUIが複雑になり、時間とともにその複雑さが積み重なることです。

HTEへの適切な対処方法は次のとおりです。

  • リリース前に、注目するセグメントを事前登録します。2つか3つで十分です。10個では過剰適合が起こるのを待つようなものです。
  • 事前登録したセグメントで意味のある効果の違いが見られた場合は、追加調査に値する根拠として扱います。そのセグメントだけにリリースしてよいという合図ではありません。
  • セグメント限定の挙動をリリースする前に、セグメントの規模は重要性を判断するのに十分か、効果はターゲティングの作業を正当化できるほど大きいか、本番環境でターゲティングを適切に構築できるかを確認します。
  • データをさまざまな方法で切り分けた事後分析によってセグメントが見つかった場合は、その結果を追加テストの仮説として扱います。1回の観察結果だけに基づいてリリースしてはいけません。

HTEと単純な平均の違い:セグメント間で効果に意味のある差がある場合、平均ではどちらの効果も過小評価されます。母集団の半分には+10%、残りの半分には-5%の効果がある処置を平均すると+2.5%となり、半分に対する成果を過小評価し、残りの半分に対する損失を無視することになります。「全員にリリースする」判断では平均が依然として適切な数値ですが、「セグメントごとのターゲティングに投資すべきか」を判断するには、セグメントごとの数値が適切な材料になります。

実用的な経験則:事前登録したセグメント間で意味のある効果の違いが見られた場合は、追加検証の仮説を立てます。適切な検出力を持つ追加テストを実施して、セグメントごとの挙動を確認します。その後、セグメント別にリリースするかを判断します。追加テストのコストは、実際には機能しないセグメント別の挙動をリリースするコストよりはるかに小さいものです。


比率指標とデルタ法

「率」指標の多くは比率です。コンバージョン率はコンバージョン数をユーザー数で割った値です。クリックスルー率はクリック数をインプレッション数で割った値です。ユーザーあたりの収益は、収益をユーザー数で割った値です。平均注文額は、収益を注文数で割った値です。

分析においてこれが重要な理由:合計値に対する標準的な分散推定は、比率にそのまま適用できません。比率に対して単純に分散を推定すると、信頼区間が不適切に狭くなり、偽陽性率が高くなります。数学的な基盤が誤っているため、実際には有意でないものを有意に見える状態でリリースしてしまいます。

正しいアプローチは2つあります。

  • デルタ法。微積分に基づく補正(テイラー展開による線形化)により、比率指標に対する正しい信頼区間とp値を算出します。高速で、十分に理解されており、現在の多くのプラットフォームで採用されています。
  • ブートストラップ。シミュレーションに基づく代替手法です。ユーザーを復元抽出で何度も再サンプリングし、その都度比率を計算して、経験分布を読み取ります。分布に依存せず直感的ですが、デルタ法より低速です。

プラットフォームの確認方法:「比率指標にはどの分散推定量を使っていますか?」と尋ねてください。答えが「比率に対する標準的なt検定」であれば、単純な二値コンバージョン(ユーザーごとに1行で、コンバージョンしたか、しなかったかを表すもの)ではない比率については誤りです。答えが「デルタ法」、「線形化」、または「ブートストラップ」であれば、正しい方法です。

現在の多くのプラットフォーム(Statsig、Eppo、PostHog、Optimizely、GrowthBook)は、この処理を正しく行います。古いプラットフォームや自社開発のプラットフォームでは、正しく処理できないことがよくあります。リスクは気づきにくいものです。ダッシュボードには妥当に見えるものの狭すぎる信頼区間が表示され、実際には主張された効果を生まない変更をリリースしてしまいます。

計算例。ユーザーあたりの収益は、総収益を総ユーザー数で割った比率です。誤った(単純な)分散推定量では、処置群の上昇率が5%で、信頼区間がゼロを含まないとします。正しいデルタ法の推定量を使うと、同じ点推定値でも信頼区間はゼロを含みます。誤った計算では「有意だからリリース」となります。正しい計算では「結論は出ていないため、期間を延長するか、ばらつきを受け入れる」となります。誤った計算に基づいてリリースすると、本番環境で主張された効果を生まない変更を出してしまい、その後、リリースがなぜダッシュボードの数値を動かさなかったのかと困惑することになります。


ベイズ分析と頻度論分析の結果パネル

頻度論分析のパネル(多くの古いプラットフォームや、現在の多くのプラットフォームの一部)には、p値、信頼区間、「統計的に有意」というラベルが表示されます。ベイズ分析のパネル(デフォルトのEppo、オプションとして利用できるStatsig、PostHogの一部)には、最良である確率、信用区間、事後分布が表示されます。

多くのPMの状況では、実験が正しく設計されていれば、どちらのアプローチでもリリースするか中止するかの判断は同様になります。用語は異なりますが、根本的な判断は似ています。

ベイズ分析の利点:

  • 複数のバリアントを自然に比較できます。「バリアントBが最良である確率は87%」は、これに相当するボンフェローニ補正済みのp値の羅列よりも自然に読めます。
  • 設計上、途中経過の確認に安全です。逐次補正を使わなくても、事後確率はいつ確認しても妥当です。
  • 仮説検定に詳しくない関係者にとって、より直感的です。
  • 事前知識がある場合は、情報量のある事前分布を利用できます(実際のリリース判断ではまれです)。

頻度論分析の利点:

  • よりよく理解されています。多くの分析チームは、頻度論に関するトレーニングをより多く受けています。
  • 事前登録の定義がより明確です。「有意水準は0.05、MDEは5%、判定ルールはX」と曖昧さなく定義できます。
  • 規制対象の分野において、より長い実績があります。

1つの実験内で両方を使い分けても問題ありません。多くのプラットフォーム(Eppo、Statsig)では切り替えが可能です。実験ごとにどちらかを選び、最後まで使い続けてください。より都合のよい解釈を求めて実験の途中で切り替えてはいけません。これはベイズ分析と頻度論分析の間で行うp値ハッキングであり、実験の規律を損ないます。


ネットワーク効果とSUTVA違反

SUTVA(Stable Unit Treatment Value Assumption:安定単位処置値仮定)とは、「あるユーザーへの処置が、別のユーザーの結果に影響しない」という意味の専門用語です。SUTVAが成り立つ場合、標準的なA/Bテストの計算が機能します。違反している場合、計算は真の効果を体系的に過小評価または過大評価します。

SUTVAに違反する場合:

  • 双方向マーケットプレイス。購入者への変更が販売者の行動を変え、その影響が同じ供給をめぐって競合する対照群の購入者にも及びます。処置群の購入者の行動が対照群の体験に漏れ込みます。
  • ソーシャル製品。処置群ユーザーの行動の変化は、その友人がどのグループに属しているかにかかわらず、交流相手のユーザーの体験に影響します。
  • 供給が制約される機能。供給が限られている場合、処置群ユーザーは同じ希少なリソースをめぐって対照群ユーザーと競合するため、テストでは処置効果と代替効果を明確に分離できません。
  • 通知システム。通知量を増やす処置は、処置セルだけでなく、プラットフォーム全体のユーザー行動を変えます。

「干渉によってリフトが弱まる」というパターンが、最もよく見られるケースです。マーケットプレイスの実験では、処置の効果が小さく見える場合、干渉がないときの真の効果は、標準的なA/Bテストで報告される値の2~3倍になる可能性があります。対照群への効果の漏れによってリフトが小さく見えたために、効果のあるテストを打ち切るのはよくある間違いです。

検出方法:

  • スイッチバック実験。時間枠ごとに母集団全体を処置群と対照群の間で切り替えます(第1週は処置、第2週は対照など)。各時間枠内のユーザー間の干渉を排除できますが、慎重な時間モデリングが必要です。
  • クラスター無作為化。個々のユーザーではなく、単位全体(都市、市場、友人グループ)を割り当てます。実効サンプルサイズが小さくなる代わりに、クラスター内の干渉を排除できます。
  • 地域実験。一部の地域で導入し、ほかの地域では導入を見送ります。時間と費用がかかりますが、干渉の影響を受けません。

干渉の有無が不確かな場合は、確認のため、小規模なクラスター無作為化版を実施してください。クラスター無作為化によるリフトがユーザー単位の無作為化によるリフトを大きく上回る場合、干渉の証拠があるため、主要なテストをクラスター無作為化で再実施してください。


ダッシュボード指標と実験指標の照合

シナリオ:ビジネスインテリジェンスのダッシュボードでは、先週の売上が8%増加したと表示されています。一方、実験プラットフォームでは、テスト群によって売上が2%増加したと示されています。両方が正しいということは、あり得るのでしょうか?

発生頻度の高い順に、考えられる答えを挙げます。

  • 分母が異なります。ダッシュボードは全ユーザーを対象にしている一方、実験では登録済みユーザーのみを対象にしています。ほとんどの実験では一部のユーザーだけが登録されるため、リフトが当てはまるのはそのユーザーだけです。
  • 対象期間が異なります。ダッシュボードは直近7日間を対象にしている一方、実験は開始日から終了日までの固定期間を対象にしています。2つの期間はそれぞれ独立して変動することがあります。
  • 外部要因があります。マーケティングキャンペーン、季節性、競合他社の動向、ニュースの流れなどです。実験ではランダム割り当てによってこれらの要因が適切に除外されますが、ダッシュボードには反映されます。
  • 選択効果があります。実験に登録されるユーザーが誰かは重要です。新規ユーザーのみでしょうか?ログイン済みユーザーのみでしょうか?機能フラグのチェックを通過したユーザーのみでしょうか?フィルターが変わるたびに、リフトが当てはまる母集団も変わります。
  • 指標の定義が異なります。「売上」は、一方では総額、もう一方では返金額を差し引いた金額かもしれません。「コンバージョン」の数え方が、システムごとに異なることもあります。

照合の原則:実験結果を「今週、この機能が売上をXドル押し上げました」と報告してはいけません。必ず「テスト期間中、登録済みユーザーの売上がY%向上しました」と報告してください。前者の表現は、実験では測定できない全社的な影響を示唆します。後者は、実験で実際に示されたことを正確に表しています。

照合で最もよくある失敗は、「ブレンド帰属」の落とし穴です。PMが実験で得たリフト(たとえば、ユーザーあたり売上が2%増加)に全ユーザー数を掛けて、全社的な影響の推定値(「増分売上1,000万ドル」)を算出します。これは二重の意味で誤りです。リフトが当てはまるのは登録済みユーザー(通常、全ユーザーの10%から50%)のみです。さらに、登録済みユーザーのグループ内であっても、リフトはテスト条件下で測定されたものです。長期的には、また全面展開時には、効果が異なる可能性があります。適切な表現は、「4週間のテスト期間中、登録済みユーザー(アクティブユーザー全体の約30%)では、対照群と比べてユーザーあたり売上が2%向上しました」です。そのうえで、リーダー層が全面展開時にどう反映されるかを慎重に計算できます。

より詳しい照合パターンや、ステークホルダー向けの表現については、references/dashboard-vs-experiment-reconciliation.mdを参照してください。


長期的な効果の推定

ほとんどのA/Bテストは2~4週間実施されます。多くの機能に関する意思決定では、30~90日間の状況を把握する必要があります。行動はより長い期間をかけて変化するためです。目新しさが薄れ、初期効果が弱まり、リテンションへの影響が現れ、ネットワーク効果が積み重なっていきます。

長期的な測定方法は、主に次の3パターンです。

  • ホールドアウト群。リリース後30日以上にわたり、一定割合のユーザー(多くの場合5%~10%)には対照群の処置を継続します。そのユーザーの長期的な行動を、変更を導入したユーザーと比較します。ホールドアウト群は元のテストと同じタイミングでランダムに割り当てられているため、この比較では長期的な効果を明確に測定できます。
  • 地域実験。一部の市場で変更を導入し、ほかの市場では導入を見送ります。市場のペア間で長期的な差を測定します。時間と費用がかかり、市場同士に比較可能性が必要ですが、干渉の影響を受けず、ユーザー単位のランダム化では測定できない効果も測定できます。
  • 差の差法(diff-in-diff)。変更を導入した市場と対照市場について、導入前と導入後の測定結果を比較します。一切ランダム化できない場合(規制対応の展開、パートナー固有の変更など)に役立ちます。ランダム化手法より精度は劣りますが、ランダム化が不可能な場合には妥当な方法です。

実用的な経験則:目新しさのリスクがある機能(新しいUI、新しい仕組み、新しい価格設定、新しい通知頻度)には、30日間のホールドアウトを設ける価値があります。後からではなく、リリース時に設定してください。後から設定するには展開を巻き戻す必要があり、実務ではほとんど行われません。ホールドアウトのコストは小さく(少数のユーザーに1か月間、以前のエクスペリエンスを提供するだけです)、その価値は、長期的な悪化が積み重なる前に検知できることにあります。


よくある解釈の失敗

よく見られるパターンを簡潔にまとめています。各パターンの詳細は references/common-interpretation-failures.md を参照してください。

  • 「P が 0.04 だから、リリースしよう。」CI の幅、効果の大きさ、ガードレールが考慮されていません。有意性は必要条件であって、十分条件ではありません。
  • 「3 日目に +5% だったので、早めに終了した。」途中経過ののぞき見、新奇性効果、あるいはその両方です。3 日目のリフトは 14 日目のリフトより大きくなることがよくあります。早期に終了すれば、ノイズをリリースすることになります。
  • 「新しいフローはパワーユーザーに効果があった(事後分析のセグメント)。」ノイズの探索です。データをさまざまな方法で切り分けて見つけたセグメントであり、見かけ上のリフトは再現されないでしょう。
  • 「実験では +2% だったのに、ローンチ後は +0.5% しか得られなかった。」多くの場合、実験結果は正しかったのです。リフトが適用されたのは、テスト条件下で登録されたユーザーであり、全体にローンチすると、未登録ユーザー、新奇性の薄れ、またはテストでは捉えられなかった干渉効果によって、効果が希釈されます。
  • 「売上は伸びたが、リテンションの CI がゼロをまたいでいたので無視した。」これはガードレール違反を「シグナルなし」と言い換えたものです。リテンションがガードレールなら、そのガードレールは拘束力を持ちます。「明確なシグナルは見られなかった」と「安全であるという証拠がある」は同じではありません。
  • 「CUPED で調整したら、本物の処置効果が消えてしまった。」CUPED が減らすのは分散であり、点推定値ではありません。CUPED 後にリフトが小さく見えたなら、調整前のリフトはおそらくノイズであり、CUPED がそれを正しく取り除いたのでしょう。調整後の値を信頼してください。
  • 「2 つのセグメントで効果が逆だったので、効果の高いほうのセグメントにリリースした。」両方のセグメントが事前登録され、ターゲティングのインフラストラクチャが整っているのでなければ、過剰適合の可能性が高いです。リリースする前に再テストしてください。
  • 「テストを実施したが結論は出なかった。それでも傾向は明らかだったので、リリースした。」結論が出なかったものは、結論が出なかったのです。方向性を示すパターンは証拠ではなく、ノイズを都合よく読み取ったものです。

信頼できる実験解釈のための14の考慮事項

信頼できる解釈は、14の考慮事項が交わるところに成り立ちます。それぞれについて、上の各セクションで詳しく説明しています。

  1. 結果パネルの完全性。 パネルには、バリアント、割り当て、バリアントごとの指標、リフト、有意性、分散削減、ガードレール、セグメント、時系列、ステータスが表示されます。不足があれば、危険信号です。
  2. 信頼区間の読み方。 中心値より幅が重要です。CI がゼロを含まない場合、狭い範囲でゼロを含む場合、広い範囲でゼロを含む場合を網羅する、実践的な判断ルールが5つあります。
  3. p値の意味。 帰無仮説が真である場合に、そのリフトが観測される確率です。処置が有効である確率ではありません。必ず CI と併せて読みます。
  4. 多重検定の補正。 ファミリーワイズエラー率の制御には Bonferroni 法、偽発見率には BH 法を使います。主要指標とセグメントを事前登録し、それ以外は探索的なものとして扱います。
  5. 逐次検定の数学。 常に有効な p 値と任意の時点で有効な CI は、途中で結果を確認しても有効性を保ちます。固定期間の p 値は、毎日モニタリングすると偽陽性率が上昇します。
  6. CUPED による分散削減。 点推定値は同じまま、CI の幅が狭くなります。実験前データが利用可能で有益な場合は、必ず使います。
  7. 異質な処置効果。 セグメントを事前登録します。事後分析で見つかったセグメント効果は、出荷の判断材料ではなく、追試の仮説として扱います。
  8. 比率指標。 デルタ法またはブートストラップを使います。単純な比率推定量は分散を過小評価し、偽陽性率を高めます。
  9. ベイズ統計と頻度論。 実験ごとにどちらか一方を選び、一貫して使います。実験が適切に設計されていれば、どちらも同様の出荷判断につながります。
  10. ネットワーク効果と SUTVA。 マーケットプレイスやソーシャル製品では、SUTVA に違反することがよくあります。干渉が疑われる場合は、クラスターランダム化、スイッチバック、または地理的実験を実施します。
  11. ダッシュボードの照合。 分母、時間枠、外部要因、指標の定義の違いが、BI ダッシュボードと実験パネルの食い違いの大半を説明します。
  12. 長期効果の推定。 30〜90日かけて現れる効果には、ホールドアウト、地理的実験、差分の差分法を使います。
  13. よくある解釈の失敗。 優秀なチームが間違ったものを出荷してしまう、最もよくあるパターンをまとめています。
  14. 「結論が出ない」という判断の規律。 最も難しい判断は、「出荷するには十分なシグナルがありません」です。これは正しい判断であることがよくあります。

上の各セクションでは、それぞれの考慮事項を順に詳しく説明しています。判断を下す前に、該当するセクションを読んでください。判断した後ではありません。


参考ファイル

  • references/confidence-interval-cheatsheet.md。信頼区間(CI)の読み方、無視すべき点、5つの判断ルールと、それぞれの具体例を説明します。
  • references/p-value-interpretation-guide.md。p値の意味、人々が意味すると装っていること、0.05という慣例、途中確認の問題、多重検定の背景について説明します。
  • references/statistical-method-reference.md。CUPED、デルタ法、逐次検定手法(mSPRT、群逐次、いつでも有効な手法)、HTE の扱い、多重検定の補正、クラスター無作為化について説明します。アナリスト向けの技術リファレンスです。
  • references/dashboard-vs-experiment-reconciliation.md。BI の数値が実験の数値と一致しない理由、複合アトリビューションの落とし穴、統計の専門家ではない関係者への違いの伝え方について説明します。
  • references/result-presentation-templates.md。関係者への共有に使える5つのテンプレートです。明確な成功、明確な失敗、結論が出ない場合(最も一般的で、最も難しいケース)、結果が混在する場合(主要指標はプラスだが、ガードレール指標は曖昧)、長期ホールドアウトの報告を扱います。
  • references/analytics-platform-comparison.md。主要な7つのプラットフォーム(Statsig、PostHog、Optimizely、GrowthBook、Eppo、Amplitude、Kameleoon)の概要をまとめています。それぞれが公開する情報、隠している情報、注意すべき点を取り上げます。
  • references/common-interpretation-failures.md。15以上のよくある解釈の失敗パターンを、名称、症状、根本原因、対処法、予防策とともに説明します。

締めくくり:結論が出ないと判断する勇気

実験結果のほとんどは、リリースするか中止するかが明確ではありません。結論が出ない結果です。リフトはあるものの、CI がゼロをまたいでいる、リフトは実在するものの、実装コストを正当化できない、リフトは有意だがガードレール指標に懸念がある、あるセグメントでは非常に良く見えるものの、そのセグメントが小さいか、ターゲティングの仕組みが存在しない、といったケースです。

PM が週ごとに下す判断のなかで最も難しいものは、「リリースするにはシグナルが不十分です」と伝えることです。結果を見たあとで基準を下げたくなる誘惑は非常に大きいものです。「結論は出ない」と言う規律は、断定することよりも正しい判断をすることを重視する規律です。

同じ規律はアナリストにも当てはまります。有意に見えるまでデータを別の切り口で分析し続けること、分散低減手法をもう1つ適用すること、テストの途中で頻度論からベイズ統計に切り替えることへの誘惑は常にあります。個々の判断はどれも、小さな裁量のように感じられます。しかし、積み重なると分析の完全性が損なわれます。結果は「実際の効果を見つけた」ではなく、「分析上のつまみを十分に調整した結果、何かが有意に見えた」になります。

結論が出ないことも正当な結果です。そこから得る教訓があるとすれば、それは次の仮説に生かすことです。効果は予想より小さかった、セグメントが重要だった、検定の検出力が不足していた、指標が適切ではなかった。結論が出なかった結果を使って、次のテストをより良いものに設計してください。現在の結果に合わせて後付けでストーリーを作らないでください。

実験前の設計規律については、experiment-design スキルを参照してください。バリアントを提供するフィーチャーフラグの運用上の仕組みについては、feature-flagging スキルを参照してください。プラットフォーム固有の MCP コマンドやプロンプトの例については、選択したプラットフォームのドキュメントを参照してください。

コメント