Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
いまさら聞けない ABテスト入門
Search
木村彩恵(skmr2348)
October 01, 2025
Technology
1
260
いまさら聞けない ABテスト入門
DeNA+GO AI関連勉強会の発表資料を一部編集したものになります。
ABテストの手順や実施するにあたって個人的に気をつけたいと感じているポイントをまとめました。
木村彩恵(skmr2348)
October 01, 2025
Tweet
Share
More Decks by 木村彩恵(skmr2348)
See All by 木村彩恵(skmr2348)
ダイナミックプライシング とその実例
skmr2348
3
780
Other Decks in Technology
See All in Technology
旅で応援する✈️ NEWTが目指すコミュニティ支援とあたらしい旅行 / New Travel: Supporting by NEWT on Your Journey
mii3king
0
120
Copilot Studio ハンズオン - 生成オーケストレーションモード
tomoyasasakimskk
0
190
「REALITY」3Dアバターシステムの7年分の拡張の歴史について
gree_tech
PRO
0
120
AWSでAgentic AIを開発するための前提知識の整理
nasuvitz
2
230
クラウドとリアルの融合により、製造業はどう変わるのか?〜クラスメソッドの製造業への取組と共に〜
hamadakoji
0
270
私のMCPの使い方
tsubakimoto_s
0
120
Databricks AI/BI Genie の「値ディクショナリー」をAmazonの奥地(S3)まで見に行く
kameitomohiro
1
370
エンタメとAIのための3Dパラレルワールド構築(GPU UNITE 2025 特別講演)
pfn
PRO
0
620
OCIjp_Oracle AI World_Recap
shinpy
1
150
会社を支える Pythonという言語戦略 ~なぜPythonを主要言語にしているのか?~
curekoshimizu
1
260
[OCI Skill Mapping] AWSユーザーのためのOCI – IaaS編(Compute/Storage/Networking) (2025年10月8日開催)
oracle4engineer
PRO
1
150
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
Featured
See All Featured
Bash Introduction
62gerente
615
210k
XXLCSS - How to scale CSS and keep your sanity
sugarenia
249
1.3M
Measuring & Analyzing Core Web Vitals
bluesmoon
9
630
How to train your dragon (web standard)
notwaldorf
97
6.3k
Designing Experiences People Love
moore
142
24k
Helping Users Find Their Own Way: Creating Modern Search Experiences
danielanewman
30
2.9k
How to Think Like a Performance Engineer
csswizardry
27
2.1k
Reflections from 52 weeks, 52 projects
jeffersonlam
353
21k
Code Review Best Practice
trishagee
72
19k
Side Projects
sachag
455
43k
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
The Cult of Friendly URLs
andyhume
79
6.6k
Transcript
AI 2025.07.17 GO株式会社 木村 彩恵 いまさら聞けない ABテスト入門
AI 2 ▪ 主に以下の3つ ▪ ログ分析 ▪ コストがかからない ▪ 未知のシナリオでの施策評価が難しい
▪ シミュレーション ▪ 未知のシナリオでも施策の効果を検証できる ▪ モデルの精度が悪いと、結果が信頼できない ▪ ABテスト ▪ 施策効果を実際に計測できる ▪ コストがかかる 業務でよく使う施策の評価方法
AI 3 ▪ ABテストは施策の効果を直接計測できて非常に強力! ▪ 過去に実施したABテストを振り返ると・・・ ▪ 判断できなかったケース ▪ 判断が誤っていたケース
▪ やり直したケース 本日の発表の動機 適切なABテストの やり方を知って、 正しい意思決定が できるようになりたい
AI 4 ▪ A/Bテスト実践ガイド ▪ pythonで学ぶ効果検証入門 ▪ Lyftブログ ▪ https://eng.lyft.com/challenges-in
-experimentation-be9ab98a7ef4 ▪ ChatGPTによる調査 今回の発表の参考文献
AI 5 ▪ ターゲットをランダムに複数のグループに分けて、グループ間でKPIを比較す ることで施策に効果があるかどうかを判断する方法 ▪ 現状のグループをControl群、施策を適用したグループをTreatment群と 呼ぶ ▪ 施策に効果があるかどうかは統計検定で「Control群とTreatment群の
KPIに有意な差がない」という帰無仮説を棄却できるかどうかで判断する ▪ p値(ControlとTreatmentが同じ母集団の場合に、偶然差が出る 確率)が有意水準以下、or ▪ ControlとTreatmentの差の信頼区間が0をまたがない そもそもABテストとは?
AI 6 ▪ ABテストは主に以下の手順に沿って実施される ▪ Step1. KPI設計 ▪ Step2. テスト設計
▪ Step3. テスト実装・実施 ▪ Step4. データ収集・モニタリング ▪ Step5. 分析 ABテストの手順 各手順の内容や気を付けるべきポイントを共有します
AI 7 ▪ やること ▪ 解決したい課題と課題を解決する仮説を明確化 ▪ 仮説を裏付けるKPIを設計する ▪ 課題:ECサイトにおいてCVR(=全セッションのうち、購入完了
セッションの割合)が低く、売り上げが伸び悩んでいる ▪ 仮説:購入ボタンを大きくするとCVRが上がるはず →KPI:CVR・決済ページ到達率などを計測する ▪ 気を付けること ▪ 施策の副作用も可能な限り考慮しKPIを設計する ▪ 購入ボタンを大きくすることでCVRは改善したが、購入後キャンセ ル率も上がってしまった →キャンセル率もKPIでケアすべきだった Step1. KPI設計
AI 8 ▪ ゴールメトリクス ▪ 施策が成功したかどうかを判定するメトリクス ▪ 前ページの例では:CVR ▪ ドライバーメトリクス
▪ ゴールに影響を主要な行動をモニタリングするメトリクス ▪ 前ページの例では:カート到達率、決済ページ到達率 ▪ ガードレールメトリクス ▪ 副作用を監視するメトリクス ▪ 前ページの例では:購入後キャンセル率 KPIの分類
AI 9 ▪ やること ▪ テストに関わる項目を決定する ▪ ランダム化単位(割り付け方法) ▪ テスト期間
▪ 分析時の検定手法 ▪ オフラインAAにより品質をチェックする ▪ 気を付けること ▪ ランダム化単位は互いに干渉を受けないか ▪ テスト期間は十分か Step.2 テスト設計
AI 10 ▪ 基本的には、施策がどの単位で影響を受けるかによって決める ▪ KPIが定義されている単位を採用する ▪ 干渉が起こる場合は、KPIの単位よりも大きい単位とする場合もある ▪ Step1のECサイトの場合、KPIがCVRであるため、セッション単位とするのが
自然 ▪ ただし、同一ユーザーが複数の群にまたがるのが問題となる施策であれ ばユーザー単位としたほうが良い ▪ サイトの見た目が変わるような施策の場合、Treatment群を一度経 験した後にControl群とすると影響が出るかもしれない ランダム化単位の考え方(基本)
AI 11 ▪ セッションやユーザー単位で干渉が起きる場合は、時間単位や地域単位とす ることも考える ▪ 例えば、モバイルオーダーのようなマッチング問題の場合、 ユーザー単位でマッチングを変えると、他のペアにも影響を及ぼす ランダム化単位の考え方(ユーザー単位で干渉する場合) Control
Control Treatment Control Treatmentのアルゴリズムを変えるとControlにも影響が出る例 時間かかる ならキャン セル
AI 12 ▪ 一方で時間単位とした場合、以下のような問題が起きる ▪ 外部要因(時間・曜日・天候やイベント)の影響を受けやすい ▪ ControlとTreatmentで同じ時間帯を同じ回数実施する ▪ 1日目の10:00-10:30はControl、2日目の10:00-10:30は
Treatment ▪ 共変量コントロール等で外部要因の影響を排除する(後述) ▪ 切り替わった瞬間にKPIの急変動が起きる ▪ 切り替え後の一定期間(ウォッシュアウト期間)のデータを破棄 ランダム化単位の考え方(時間単位の問題点) 10:00- Control 10:30- Treatment 11:00- Control 11:30- Treatment 10:00- Treatment 10:30- Control 11:00- Treatment 11:30- Control 1日目 2日目
AI 13 ▪ サンプルサイズは、有意水準と検出力が一定の水準を満たすように設計する ▪ 有意水準α:ControlとTreatmentが差がない場合に、偶然差があると判 定される確率(0.05以下) ▪ 検出力1-β:ControlとTreatmentに差がある場合に正しく差があると判 定される確率(0.8以上)
テスト期間の考え方(有意水準と検出力) 検定の結果 差がある 差がない Controlと Treatmentの 真の分布 差がある 1-β: 検出力 β: 第二種の過誤 差がない α:第一種の過誤 (=有意水準) 1-α
AI 14 ▪ サンプルサイズは有意水準αと検出力1-βに加え、効果量(検出したい差)も 影響する ▪ 正規分布に従う場合のサンプルサイズ ▪ 効果量が小さいほど、必要となるサンプルも増える テスト期間の考え方(サンプルサイズ定式化)
効果量小 検出力 有意水準 効果量大
AI 15 ▪ 効果量の定義はサンプルサイズを計算する対象のKPIによって変わる ▪ 比率の差(例えばCVR):Cohen’s h ▪ Control群の比率 pC
とTreatment群の比率 pT の効果量h ▪ 連続値の差(例えば単価):Cohen’s d ▪ Control群の平均 μC とTreatment群の平均 μT の効果量d テスト期間導出例(効果量の定式化)
AI 16 ▪ cohen’s hはstatsmodelsの 関数で計算可能 テスト期間導出例(python実装例)
AI 17 ▪ 過去のログを用いて、以下の手順の繰り返しにより計算したp値の分布が一様 かどうかを確認する ▪ ABテストと同じロジックでランダム化 ▪ KPIを集計、統計検定によりp値を計算 テスト設計の品質チェック(オフラインAAテスト)
ControlとTreatmentで同じ 分布の場合 ControlとTreatmentで異な る分布の場合
AI 18 ▪ p値が一様になっていない場合、以下の点で問題がないかをチェックする ▪ 割り付け ▪ 同じユーザーがControlとTreatment両方に入っていないか ▪ セグメント
▪ KPIに相関がありそうな属性(新規/既存や性別、年齢別)で偏りが ないか ▪ 分析 ▪ クエリのミスがないか オフラインAAで問題が見つかった場合の対応
AI 19 ▪ やること ▪ テスト実装 ▪ 気を付けること ▪ 施策以外の部分に差がでないかを確認する
▪ 例えばECサイト上で実施するABの場合、ページ表示速度など ▪ オンラインAAを実施するのも有効 ▪ 深夜や週末に発火するABは避ける ▪ 不測の事態に対応できるように、対応しやすい時間でまずは開始 Step3. テスト実装
AI 20 ▪ やること ▪ KPIのモニタリング ▪ 外部要因に注意する(ECサイトの場合、セールがあった等) ▪ 気を付けること
▪ 途中解析をすると多重検定の問題が発生する ▪ 多重検定の問題:第一種の過誤の発生確率が高まる ▪ どうしても途中解析したい場合は以下のような方法がある ▪ α spending(後述) ▪ ベイジアンAB ▪ ABテストの結果を確率分布として推定する Step4. データ収集、モニタリング
AI 21 ▪ 途中解析することを前提に、解析時に使用するαを定める方法 ▪ 分析するタイミングを決める(例えば、25%, 50%, 75%, 100%のデー タを取得したタイミング)
▪ 各タイミングで使用するαを決定する ▪ Pocock型:均等割する(α/4 = 1.25%) ▪ O’Brien-Fleming型:最初は保守的に、最後は緩和する方法 ▪ 各タイミングで検定する ▪ p値<αとなったら帰無仮説を棄却してデータ収集を終了する α spending
AI 22 ▪ やること ▪ 帰無仮説が棄却できるかどうかを統計検定により判定する ▪ 気を付けること ▪ KPIが正規分布かどうかを意識する
▪ 分布の可視化 ▪ 正規性検定 ▪ Q-Qプロット Step5. 分析
AI 23 ▪ データの分布が正規分布ではないor外れ値がある場合に、T検定やZ検定を 用いると検出力が下がってしまい、母集団に差がある場合であっても見過ご されてしまうことがある ▪ ヒストグラム等で分布をみるのが重要 データの分布の可視化 例えば単価データは右図のような
対数正規分布となることが多い グラフでは明らかに分布が異なるが、 T検定では以下のように有意差なしと の結果になる • p値: 0.2429 • 平均差: 283.71 • 95%信頼区間: ◦ [-195.83, 763.2731]
AI 24 ▪ ヒストグラムで可視化する以外にも、正規性検定やQ-Qプロットなどにより 正規分布かどうか判断できる ▪ 正規性の検定(Shapiro-Wilk検定) ▪ Control、Treatmentそれぞれで検定、p値が有意水準以下の場合は 正規性を棄却
▪ 前述の例の場合はControl、Treatmentいずれもp値=0となった 正規性の確認(Shapiro-Wilk検定)
AI 25 ▪ ヒストグラムで可視化する以外にも、正規性検定やQ-Qプロットなどにより 正規分布かどうか判断できる ▪ Q-Qプロット ▪ X軸に理論分布の分位点、Y軸に実データの分位点をプロット ▪
正規分布でない場合に直線にならない 正規性の確認(Q-Qプロット)
AI 26 ▪ ブートストラップCI ▪ データを何度も抽出して統計 分布を作ることで、信頼区間 を推定する方法 ▪ 先の単価データの場合、信頼
区間が[51.6350, 524.4042] となり有意差ありと判定 正規分布でない場合の対処法(ブートストラップCI)
AI 27 ▪ 検定する場合も2つのアプローチがある ▪ WelchのT検定(Z検定) ▪ 分散が異なっていてもよい ▪ 回帰分析(OLS)を使う方法
▪ ControlとTreatmentで分散が異なる場合、係数のp値や信頼区間が 不正確になる可能性がある ▪ 頑健SEで等分散性の緩和可能 ▪ 共変量コントロールなどにより、外部要因の除去がしやすい 検定のアプローチ
AI 28 ▪ 以下のようにControlとTreatmentで分散が異なるケースを考える ▪ Control:クリック率20%、サンプル数50 ▪ Treatment:クリック率30%、サンプル数200 ▪ 各手法で求めたCIは以下の通り。
▪ 頑健SEの方が信頼区間がZ検定やブートストラップCIと近い 頑健SEによる等分散性の緩和 Lower CI Upper CI Welch Z検定 0.039 0.28 ブートストラップCI 0.035 0.275 OLS(標準SE) 0.02 0.30 OLS(頑健SE) 0.039 0.281 HC1を指定すると頑健SE
AI 29 ▪ 共変量コントロール ▪ KPIに影響を与える既知の要因がある場合、モデルに含める ▪ 例えばクリック率が過去のクリック傾向に依存する場合 外部要因の除去(共変量コントロール) 共変量あり
共変量なし
AI 30 ▪ DID(差分の差分法) ▪ Control群とTreatment群で施策前後の差を比較することで施策の効果 を推定する方法 ▪ 平行トレンド仮定が成り立つ必要がある ▪
平行トレンド仮定:施策以外の外部要因がControlとTreatmentで 共通である 外部要因の除去(DID) 時間経過による変化 施策による変化 施策前 施策後 Control Treatment
AI 31 ▪ 今回の発表ではABテストの手順や各手順で気を付けたいことをまとめました ▪ 実際に施策効果を測定可能である一方、設計や実施後の分析を適当にすると 結果が変わり、誤った結論につながります ▪ ABテストについてはまだまだ勉強中なので、役に立つTipsがあれば、 コメントでぜひ教えてください!
まとめ