A/Bテスト（スプリットテストとも呼ばれる）は、ユーザーを機能やデザインの異なるバリアントにランダム割り当てして対照実験を行い、結果を比較することでパフォーマンスの高いバージョンを特定する手法です。モバイルアプリでは、A/BテストはApp Store / Play Storeのアップデートなしにアプリの動作を変更するリモートコンフィグシステムを通じて実施するのが一般的です。
2026年の主要モバイルA/Bテストプラットフォーム
- Firebase Remote Config / A/Bテスト — GoogleのFirebase Analytics と深く統合された無料プロダクト。モバイルA/Bテストで最も広く使われている。
- Optimizely — ウェブ＋モバイルにわたるエンタープライズ向けA/Bテストプラットフォーム。
- Statsig — モダンなA/Bテスト＋フィーチャーフラグプラットフォーム。グロース段階で人気。
- LaunchDarkly — A/Bテスト機能を内包したフィーチャーフラグプラットフォーム。エンジニアリングチーム主導。
- Apptimize — モバイルアプリに特化したA/Bテスト。
- Split.io — フィーチャーフラグ＋A/Bテストプラットフォーム。
- Amplitude Experiment — Amplitude Analytics内のA/Bテスト機能。
成熟したアプリの多くはA/Bテストを継続的に実施しています——オンボーディングのバリアント、ペイウォールのバリアント、機能デザイン、コピーの変更など。継続的なテストが運用モデルです。単発の実験はセットアップのオーバーヘッドを無駄にします。
サンプルサイズと期間：A/Bテストはテストしたい効果を検出するのに十分なサンプルが必要です。計算は複雑になりますが、有用な目安：
- 高トラフィックアプリ（DAU 100万以上）：5%超の効果を1〜7日で検出可能。
- 中程度トラフィックアプリ（DAU 5万〜50万）：5%超の効果には通常1〜2週間、1〜3%の効果には2〜4週間。
- 低トラフィックアプリ（DAU 5万未満）：小さな効果へのA/Bテストは非現実的なことが多い。大きな効果（15%超）のみ。
ほとんどのA/Bテストプラットフォームはサンプルサイズ計算機を内蔵しています。検出力が不十分なテスト（サンプル不足）は偽陽性・偽陰性の率が高くなります——これは経験の浅いテスト担当者によくある失敗パターンです。
よくある統計的落とし穴
- テスト完了前に結果をのぞき見する — p値を繰り返し確認すると偽陽性率が上がります。事前にサンプルサイズを設定し、達成まで待ちましょう。
- 多重比較問題 — 20の指標を同時にテストすると、実際には効果がなくても約1つが「有意」に見えます。有意性の閾値を調整してください。
- 選択バイアス — バリアントが（意図的かどうかに関わらず）異なるオーディエンスに配信されている場合、因果関係を測定できていません。
- ノベルティ効果 — 新しいバリアントは最初の1週間、目新しさによって優れたパフォーマンスを示すことが多く、その後元に戻ります。定常状態の行動を捉えられるだけテストを長く実施してください。
- 層別分析の欠如 — テスト全体の結果は中立でも、特定のコホートでは強い勝ち・負けが出ている場合があります。必ずセグメント分析を行ってください。
- 実際的有意性と統計的有意性の混同 — 0.5%の改善は統計的に有意かもしれませんが、実装コストが高い場合はリリースする価値がないこともあります。
モバイルアプリでA/Bテストすべきもの（インパクトの大きい順）：
- ペイウォールのバリアント — 価格設定、コピー、レイアウト、トライアル期間。収益インパクトが最大であることが多い。
- オンボーディングフロー — 画面数、コピー、パーソナライゼーションの質問、ATTプロンプトのタイミング。
- プッシュ通知のコピー・送信タイミング — 送信時刻のバリエーション、コピーのバリアント。
- アプリ内メッセージのバリアント — モーダル対バナー、トリガーロジック。
- 機能デザイン — 新機能のUX、ボタン配置、ナビゲーションパターン。
- App Storeのアセット（Google Play Store Experiments）— アイコン、スクリーンショット、短い説明文。
成熟したモバイルアプリはこれらの面で5〜30以上の並行A/Bテストを実施しています。