自社サイトのA/Bテストツール：Google Optimize代替案の比較と導入

自社サイトのA/Bテストツール：Google Optimize代替案の比較と導入

1. Google Optimizeはなぜ終了したのか、本当にA/Bテストが必要か

Google Optimizeは無料で使いやすかったものの、2023年9月に正式にサービス終了し、公式はFirebaseかサードパーティ製ツールへ誘導しています。多くのB2Bサイト運営者はまず「早く代替を探さなければ」と考えます。でも有料契約の前に、まず自問してください。あなたのサイトの1日の訪問数は、A/Bテストの結論を出せるだけあるでしょうか。

A/Bテストの統計的有意性にはサンプル数が必要です。コンバージョン率5%で、相対20%の改善（5%から6%へ）を検出したい実験では、各バージョンに少なくとも数千セッションが必要です。B2Bの自社サイトで1日100なら、1か月回しても3000セッション、2バージョンに分けると各1500で、有意性の要件には全く届きません。この状態でVWOに何万円も払っても、3か月後に見えるのは「有意差なし」ばかりです。GEO実験設計と同じ理屈で、サンプルが足りないなら実験より先にコンテンツで流入を貯めるべきです。

2. 3タイプの代替案：軽いものから重いものへ

Google Optimizeの代替ツールは3タイプに分かれます。1つ目は有料SaaSで、代表はVWO、Optimizely、Omnivariateです。機能は最も充実していますが高価で、月額は通常数百から数千ドル、1日の訪問が1万を超えるサイトに向きます。2つ目はオープンソースの自社構築で、代表はGrowthBookです。無料ですが自分で導入と保守が必要で、技術チームがあれば対応できます。3つ目は手動の段階リリースで、ツールを使わずリリースのペースとGA4のデータ比較で判断します。流入が小さいときはこれが最も現実的です。

多くの人はまず「VWOとOptimizelyはどちらが良いか」と聞きますが、これは本末転倒です。まず自分がどの流入帯にいるかを判断し、それからツールを選びます。B2Bの自社サイトはほとんどが第1の帯で、手動の段階リリースで十分です。フォームのA/Bテストの統計手法はフォームA/Bテスト：変数の設計、サンプルサイズ、統計的有意性。

三、手動カナリアリリースの進め方：少ない流入でも検証できる

日訪問数が厳密なA/Bテストに足りないときは、手動カナリアリリースが最も現実的です。仕組みはシンプルで、新ページをいきなり全公開せず、まず新バージョンを20%の訪問者に見せ、旧バージョンを80%に配信し、GA4で両バージョンの主要指標（フォーム送信率、滞在時間、直帰率）を比較します。2週間走らせて傾向を見て、傾向が明確になってから全公開します。

カナリアリリースに専用ツールは不要で、GTMの組み込み変数で実現できます。訪問者IDのハッシュで振り分け、20%を新バージョンへ。重要なのは振り分けが安定していること。同じ訪問者は毎回同じバージョンを見る必要があり、今回新・次回旧ではいけません。GTMでの振り分け方法はGTMのタグ・トリガー・変数の管理をご覧ください。新バージョンの公開手順は公式サイト保守で毎月やる6つのこと。

四、統計的有意性：なぜ途中でテストを止めてはいけないのか

A/Bテストで最も多い失敗は「途中で止める」ことです。3日走らせて新バージョンのコンバージョン率が10%高いと分かり、すぐに勝利宣言して全公開する。これは典型的な統計の罠で、サンプルが少ないと変動が改善に見えやすく、あと数日走らせれば元に戻ることもあります。統計的には、サンプル数を十分に集め、実験を予定期間まで走らせてからでないと結論は出せません。

B2Bの自社サイトは流入が少ないため、途中で止めることには特に注意が必要です。正しいやり方は、実験開始前に必要なサンプル数を計算し（オンラインのサンプルサイズ計算ツールを使う）、その期間を走り切ることです。途中の傾向がどれほど「良く」見えても止めません。走り切っても有意でなければ、その変更に効果はなかったと認め、無理に解釈しないことです。フォーム項目のA/Bテスト方法は問い合わせフォームの項目設計と転換率。

ツールを導入すべきかどうかには、もう一つ実践的な判断基準があります。過去3か月で検証したいページ変更が5つ以上あり、そのすべてが感覚で決めているなら、体系的な実験プロセスが本当に必要です。たまにボタンの色を変えたいだけなら、手動カナリアリリースとGA4の傾向確認で十分で、新しいツールを導入して運用負担を増やす必要はありません。

五、デプロイの注意点：ページを遅くしない

A/Bテストツールは一般にページ読み込み時にJSを注入して振り分けを行うため、Core Web Vitalsが悪化します。特に有料SaaSは注入されるスクリプトが小さくなく、LCPに影響が出やすいです。導入時はテストスクリプトをGTMまたは非同期読み込みにして、レンダリングをブロックしないようにしましょう。トラフィックの少ないサイトなら手動カナリアリリースで性能への影響はほぼゼロです。小規模サイトに手動方式を勧める理由の一つでもあります。

もう一つの性能の落とし穴はクライアントサイドでの新版レンダリングです。多くのA/Bツールは旧版のJSを読み込んだ後にDOMを新版へ置き換えるため、CLS（累積レイアウトシフト）が大きくなります。実験中はここを注視してCore Web Vitals、コンバージョンを測るために性能を壊さないようにしましょう。テストスクリプトの適切な読み込みは海外展開サイトのコンプライアンス基盤。

六、よくある選定ミス

FAQ よくある質問

最後に

A/Bテストツールの選択は、突き詰めればトラフィック量の選択です。ツールは高ければよいのではなく、自分のトラフィックに合っているほどよいのです。B2Bの自社サイトで最もよくある失敗は、大手ECサイトのやり方をそのまま持ち込んでA/Bテストをすることです。日次訪問200でバージョン差を検出しようとしても、3か月後には「有意差なし」ばかりで、お金を使ったうえに自信まで失います。

実行は3ステップ。第一に、まず日次訪問数を確認し、500未満なら手動カナリアリリースとGA4で進め、ツールは買わないこと。第二に、実験開始前に必要サンプルサイズを計算し、2週間は走らせてから結論を出すこと。第三に、毎回1つの変数だけをテストし、直列で進めること。トラフィックが日次訪問2000以上に育ってから、有料SaaSを本格的に検討すれば遅くありません。

覚えておきたい一言。A/Bテストはツールの問題ではなく、サンプルサイズの問題です。トラフィックが足りなければ、どんなに高いツールでも真実にはたどり着けません。