> ## Documentation Index > Fetch the complete documentation index at: https://meta.niceshare.site/llms.txt > Use this file to discover all available pages before exploring further. # A/Bテスト > A/Bテストは、どちらのパフォーマンスが優れているかを判断するために、ウェブページまたはアプリの2つのバージョンを比較する手法です。統計的に有効なA/Bテストの実施方法を学びましょう。 **カテゴリ**: 手法
**タイプ**: 実験フレームワーク
**起源**: 無作為化比較試験、18世紀の医学 / ウェブ最適化、1990年代〜2000年代
**別名**: スプリットテスト、バケットテスト、管理実験 **クイックアンサー** — A/Bテストは、ウェブページ、アプリ画面、機能など、製品の2つのバージョンを比較して、どちらが定義された目標でより優れたパフォーマンスを発揮するかを決定する手法です。異なるバージョンに異なるユーザーを無作為に公開し、結果を測定することで、チームはユーザー体験とビジネスメトリクスを実際に改善する変更について、データに基づいた決定を下すことができます。重要な洞察は、直感は信頼できないということです。相関関係と因果関係を製品上の決定で確実に区別できるのは、管理された実験だけです。 ## A/Bテストとは？ A/Bテストは、特定のメトリクスでどちらのバージョンがより優れた結果を達成するかを決定するために、製品要素の2つのバリアントを比較する管理された実験です。1つのバージョン（A、コントロール）は、変更されたバージョン（B、トリートメント）と比較され、ユーザーは各グループに無作為に割り当てられます。グループ間の結果の差を測定することで、チームは行動の変化を特定の修正に帰属させることができます。 このプラクティスには何世紀にもわたる医学研究にルーツがありますが、ウェブおよびプロダクト開発への応用は、Amazon、Google、Netflixなどの企業がデータ駆動型のプロダクト意思決定で実験し始めた1990年代後半から2000年代初頭に始まりました。今日、A/Bテストはデジタルプロダクト開発の基本的なプラクティスであり、ボタンの色からユーザー体験全体まで、すべてを最適化するために事実上すべての主要なテック企業によって使用されています。 > 「管理された実験は、データに基づいた決定を下したいと考える人のツールキットの中で最も強力なツールである。」 — ロン・コハビ、元Netflixエグゼクティブ、A/Bテストのパイオニア A/Bテストの力は、特定の変更の効果を分離する能力にあります。管理された実験がなければ、観察された改善が変更によるものなのか、外部要因によるものなのか、偶然によるものなのかを知ることは不可能です。適切に設計されたA/Bテストは、観察された差が本物であるという統計的信頼を提供します。 ### A/Bテストを3つの深さで理解する * **ビギナー**: 改善したい単一の主要メトリクス（クリック率やコンバージョン率など）を定義することから始めましょう。テストする簡単な変更を1つ作成し、サンプルサイズが十分に大きいことを確認し、結果を分析する前に固定期間テストを実行しましょう。 * **プラクティショナー**: 多変量テストを使用して、複数の変数を同時にテストしましょう。適切な統計的有意性の閾値（通常95％）を実装しましょう。結果をセグメント化して、異なるユーザーグループにわたる効果を理解しましょう。ただし、小さなサンプルセグメントを過度に解釈しないように注意しましょう。 * **上級者**: 結果が決定的な場合に早期に停止できる順次テスト手法を適用しましょう。新規性効果に対する長期的効果をテストするために、ホールドアウトグループを使用しましょう。不確実性の定量化を伴うより迅速な意思決定のためにベイズ分析を実装しましょう。 ## 起源 A/Bテストの起源は、20世紀初頭のロナルド・フィッシャーなどの統計学者の研究に続き、医学研究の標準となった無作為化比較試験（RCT）の概念にさかのぼります。被験者をトリートメントグループとコントロールグループに無作為に割り当てて、介入の効果を分離するという基本的な原則は、製品テストに直接翻訳されます。 制御された実験のウェブ最適化への適応は、1990年代後半に始まりました。2000年、Googleは1ページあたりに表示する検索結果の数について、最初のA/Bテストの一つを実行しました。Amazon、Netflix、その他のインターネット企業は、ユーザーインターフェースの小さな変更が数百万人のユーザーに適用された場合、莫大な財務的影響を与える可能性があることを認識し、すぐにこのプラクティスを採用しました。 Amazonで実験をリードし、後にNetflixに移ったロン・コハビは、デジタル製品のための現代のA/Bテストプラクティスを形式化したことで広く認められています。彼の仕事は、実験プログラムにおける信頼、速度、反復の重要性など、今日でも使用されている統計的および運用上のベストプラクティスの多くを確立しました。 ## 重要ポイント テストの前に、何が起こると予想し、その理由を明確にしましょう。良い仮説は、変更、期待される結果、成功を測定するメトリクスを指定します。 目標を直接測定する主要メトリクス（コンバージョン率、ユーザーあたりの収益など）を選択しましょう。意図しない結果を監視するための二次メトリクスを含めましょう。虚栄のメトリクスの最適化を避けましょう。 開始前に必要なサンプルサイズを計算しましょう。統計的有意性を達成するのに十分な期間テストを実行しましょう。統計的有意性と実用的な有意性の違いを理解しましょう。 比較可能性を確保するために、ユーザーをテストグループに無作為に割り当てましょう。セッション間で一貫性のある割り当て（同じユーザーが同じバージョンを見る）を使用しましょう。ユーザーレベルとセッションレベルの無作為化を考慮しましょう。 結論を出す前に十分なサンプルサイズを待ちましょう。セグメント分析を注意して検討しましょう。セグメントが多すぎると偽陽性のリスクが高まります。勝者を実装し、敗者で反復しましょう。 ## 応用 ECサイトは、チェックアウトフロー、価格ページ、製品説明、行動喚起をテストします。1つの勝利テストで収益を10〜30％増加させることができます。 アプリ開発者は、オンボーディングフロー、機能設定、ペイウォール、通知のタイミングをテストします。モバイルテストは多くの場合、エンゲージメントとリテンションのメトリクスに焦点を当てます。 マーケターは、件名、送信時間、コンテンツレイアウト、行動喚起をテストします。EメールのA/Bテストは通常、開封率とクリック率に焦点を当てます。 広告チームは、異なる広告コピー、画像、見出し、ランディングページをテストします。広告レベルでのA/Bテストは、顧客獲得コストを最適化します。 ## ケーススタディ MicrosoftのBing検索エンジンは、大規模なA/Bテストの画期的な例を提供しています。2009年から2015年の間に、Bingチームは結果ページのレイアウトからアルゴリズムの微調整まで、あらゆるものをテストし、常に200以上のA/Bテストを同時に実行しました。特に注目すべきテストの一つは、より多様な結果を含むようにデフォルトの検索設定を変更することでした。テストは、ユーザー満足度は向上したが、当初は収益の増加にはつながらないことを示しました。しかし、チームはこの変更がアルゴリズムのトレーニングに役立ち、長期的な改善につながり、最終的に年間収益を12％以上増加させたことを発見しました。初期の結果が否定的に見えても、実験を実行する価値を示しています。 ## 境界と失敗モード A/Bテストには、実践者が理解しなければならない重要な制限があります。第一に、A/Bテストは小さな漸進的な変更のみを比較できます。ユーザーは客観的により良いデザインであっても、不慣れなインターフェースに否定的に反応することが多いため、抜本的な再設計をテストすることは困難です。第二に、テストには大量のトラフィックが必要です。微妙な変更や小さな改善をテストするには、多くの場合、統計的有意性を達成するために数百万人のユーザーが必要です。 もう一つの重要な失敗モードは「ピーキング」です。テストが適切なサンプルサイズに達する前に結果を繰り返し確認し、結果が有望に見える場合に早期に停止することです。これにより、偽陽性率が劇的に増加します。さらに、短期的な結果は、ブランド構築や顧客生涯価値などの長期的な効果を捉えないことがよくあります。最後に、A/Bテストは根本的なプロダクト・マーケット・フィットの問題を解決できません。ボタンの色の最適化をどれだけ行っても、誰も望まない製品を救うことはできません。 ## よくある誤解 統計的有意性は、差が本物である可能性が高いことだけを伝え、実用的に重要であることは伝えません。統計的に有意な0.1％の改善は、実装コストを正当化しない場合があります。 同時にテストを多く実行すると、あるテストのユーザーが別のテストの影響を受ける干渉効果を引き起こす可能性があります。質と学習が量より重要です。 A/Bテストは何が機能するかを教えてくれますが、なぜかは教えてくれません。テストに値する仮説を生成し、結果を適切に解釈するには、優れた製品判断が必要です。 ## 関連コンセプト 仮説を検証可能な予測として構造化することです。A/Bテストは製品仮説を検証する実行手法です。 仮説を検証する体系的なアプローチです。A/Bテストは科学的思考を製品上の決定に適用します。 計画・実行・確認・改善は、反復的テストと学習のフレームワークを提供します。A/Bテストは「確認」フェーズを体現しています。 増分的に構築してテストすることで無駄を最小化します。A/Bテストは、フル実装前に仮説を検証することで、リーンプロダクト開発を可能にします。 目標と主要結果には、A/B実験でテストできるメトリクスが含まれることがよくあります。OKRは目標を提供し、A/Bテストは測定を提供します。 主要業績評価指標は、A/Bテストが測定するメトリクスです。良いKPIは意味のあるテストに不可欠です。 ## 一言でわかる 直感よりもデータを信頼しましょう。A/Bテストは、ユーザーの成果とビジネスメトリクスを実際に改善する変更について、統計的に有効な証拠を提供します。