はじめに
この記事は、株式会社asken (あすけん) Advent Calendar 2025の12/22の記事です。
こんにちは。2025年5月にデータサイエンティストとしてaskenに入社した平です。前職では通信会社で新卒から約8年間、データサイエンス関連の業務を幅広く経験しました。最近はあまり参加できていませんが、業務外ではKaggleやatmaCupにも挑戦しています。
現職のaskenに入社後の半年間は主にAIツールの活用やデータ基盤の整備に取り組んできました 1。一方で、A/Bテストといった効果検証の領域に関心はあったものの、既存の運用で問題ないように見えたため積極的に関わっていませんでした。
そんな中、あるA/Bテストの結果に違和感を覚えたことをきっかけに、設計や運用の見直しに着手することになりました。本記事では、試行錯誤から得た学びをもとに、A/Bテストの勘所を整理します。
きっかけ：「有意差あり」への違和感
発端は、あるA/Bテスト結果への違和感でした。実施されていたA/Bテストでは検出したい差の大きさ（MDE）や検出力が事前に設定されておらず、サンプルサイズと有意水準のみが決まっていました。そこで、個人的に見積もったMDEとサンプルサイズを照らし合わせたところ、明らかな矛盾がありました。
- 事前予測：現実的なMDEでは十分な検出力を確保できず、有意差は出ないはず
- 実際の結果：有意差あり！
🤔 妙だな… 2 と思い調査した結果、集計クエリの誤りと割り当て比率の偏りが発覚しました。技術的なバグがデータを歪めていたのです。
ただ、真の問題はバグそのものではありませんでした。 結果としての「p < 0.05（有意差）」の有無にばかり注目が集まってしまい、事前の検出力設計が十分に議論されないまま進んでしまっていた。ここが根本原因だと考えました。 社内ではA/Bテストは以前から実施されていましたが、統計的な設計プロセスや基準（お作法）の標準化が追いついていなかったのです。
この気づきをきっかけに、A/Bテストの設計と運用を見直す取り組みを始めました。
改善に取り組む中で重要性を実感したこと
以下の内容は知識としては知っていましたが、実際にA/Bテストの運用に深く関わる中で重要性を身をもって痛感しました。
検出力（Power）の重要性
検出力とは「本当に差があるとき、それを検出できる確率」です。
検出力80%の場合、（同じ条件で）効果がある施策を100回A/Bテストしたら、理論上は80回ほど検出できる計算になります。逆に言えば、20回程度は見逃してしまうリスクがあるということです。これを事前に計算しないと、そもそも検出できない実験を走らせてしまうことになります。
今回の違和感も「この設計では検出力が足りないはず」という直感から始まりました。
MDE（最小検出可能効果）は「ビジネスの意思決定」の問題
MDE（Minimum Detectable Effect：最小検出可能効果）とは、設計段階で決める「検出したい差の大きさ」のことです。統計の文脈で「効果量」と呼ばれることもあります。
MDEの設定が難しいのは、以下の2つの制約があるからです。
1. 成熟したサービスでは期待できる改善幅が小さい
あすけんは2013年からアプリ版のサービスを提供しており、累計会員数1300万人、MAU 132万人のサービスです。このような成熟したサービスでは、主要指標の劇的な改善は難しく、現実的に期待できるMDEは小さくなりがちです。
2. 対象を限定するとサンプルサイズの確保が難しい
「新規ユーザー」や「特定機能の利用者」など対象を限定したテストでは、MAUが多くても十分なサンプルサイズを確保することが難しくなります。
一方で、検出したいMDEを小さく設定しすぎると、必要なサンプルサイズが膨大になります。例えば、MDEを半分（0.5倍）にすると、必要なサンプルサイズは概ね4倍に跳ね上がります。
そのため、以下の2点を考慮した「現実的な妥協点」を探る必要があります。
- 最低ライン（ROI）：開発・運用コストを回収するために、最低どのくらい改善する必要があるか？
- 相場観（過去実績）：過去の類似施策ではどの程度の改善幅だったか？
過去の施策結果の蓄積（ナレッジ）があれば、この見積もりの精度は上がります。現在はその知見を蓄積している段階で、「この種の改善なら○%程度」という相場観を組織として持てるようにしていきたいと考えています。
MDEが決まらないと、サンプルサイズも期間も決まりません。つまり、A/Bテストの設計におけるMDEとは、統計の問題である以前に、「どの程度の成果を目指す施策なのか」を定義するビジネス上の意思決定なのです。
有意水準を事前に決める
有意水準についても、テスト開始前に決めておくことが重要です。
有意水準は「本当は差がないのに、差があると誤って判断してしまう確率」のことです。結果を見てから基準を変えるのは「後出しジャンケン（pハッキング）」になってしまうため、必ず事前に固定します。
一般的に0.05が用いられますが、探索的なテストや偽陽性のリスクを許容できる場面では、確保できるサンプルサイズとのトレードオフを考慮して0.1に設定することもありました。
AAテストによる割り当て・計測の検証
今回のように割り当ての信頼性に疑義がある場合や、初めてテストを実施する際には、AAテストで検証することが重要です。
AAテストとは、施策による差分が一切ない状態でユーザーをA/Bに分けるテストです。主に以下の2点を確認します。
- 割り当て比率の確認：A/Bの比率（例：5:5）が想定どおりになっているか
- 指標の差の確認：主要な指標やガードレール指標についてA/Bで有意差が出ていないか
施策を入れていないのに有意差が出ている場合、割り当てのロジックだけでなく、計測や集計の不備（イベント発火やクエリの誤りなど）が疑われます。
割り当ての検証が重要なのは、問題が発覚した場合に再テストするしかないからです。2週間などの貴重な時間を費やして検証しても、割り当てに偏りがあればデータは使い物にならず、期間もコストも無駄になってしまいます。事前にAAテストで確認しておくことで、無駄な手戻りを防げます。
まとめ
データ基盤を整理したことによるデータ理解と統計知識の両方があったからこそ、今回の問題を発見できたと思います。
現在は月1〜4件のA/Bテストを実施していますが、まだ「型」を作っている途中です。いわゆる Crawl-Walk-Run でいえば、クロールからウォークに差しかかったあたり。記事内で触れた設計や運用もまだ完全にはできておらず、試行錯誤しつつ改善しています。
定量的なアプローチ（A/Bテスト）と、「ひとびとの明日を今日より健康にする」というミッションに代表される定性的な面 3。両方を大事にして、いいサービスにしていきたいと思います。
採用について
askenではエンジニアを絶賛募集中です。
まずはカジュアルにお話しできればと思いますので、ぜひお気軽にご連絡ください！
https://hrmos.co/pages/asken/jobs
