---
title: "ABテストツール比較｜Google Optimize終了後の選び方"
description: "Google Optimize終了後のABテストツール選定を、Webビジュアル編集型・feature flag型・エンタープライズ統合型・内製の4方式で比較。見積の質問表と実験運用チェックリストで導入と見送りを判断できます。"
canonical: https://curumi.co.jp/blog/ab-test-tools-comparison
date: 2026-04-07T00:00:47.713Z
---

# ABテストツール比較｜Google Optimize終了後の選び方

## Google Optimize終了後のABテストツールの現在地

Google Optimizeは2023年9月30日に提供を終了しました。現在は第三者ツールまたは内製基盤でバリエーションを配信し、Google Analyticsで結果を解釈する構成が基本です。[Google Analyticsの実験連携に関する公式ガイド](https://developers.google.com/analytics/devguides/collection/ga4/integration)も、第三者ツールで実験を実行する方法と、内製実験をGoogle Analyticsで計測する方法を案内しています。この前提に立つと、選定の論点は「どの製品が人気か」ではなく「自社の実験対象に合う実装方式はどれか」に変わります。

### 公式に確認できる現状（2026年7月時点）

- Google OptimizeとOptimize 360は2023年9月30日で利用できなくなり、同日時点で稼働中だった実験とパーソナライゼーションも終了しました
- Googleは自前ツールの維持ではなく第三者ABテストツールとの連携に投資する方針を示し、連携パートナーの例としてAB Tasty、Optimizely、VWOを挙げています。連携用のAPIも公開済みです
- GA4単体にはテストの配信・管理機能がありません。GA4が担うのは、流入・行動データと突き合わせた結果の解釈です

### この記事で判断できること

本記事は製品名と非公開価格の横並びではなく、実験対象、実装方式、統計の扱い、GA4連携、組織の運用能力という選定軸で候補を絞る構成です。読み終えた時点で、導入候補の絞り込みだけでなく「今は導入しない」という選択も、根拠を持って下せる状態を目指します。

## 実装方式で分ける4タイプ：実装責任と用途

ABテストツールは製品名から入らず、実験対象と実装責任で4つの方式に分けて考えることが重要です。同じ「ABテスト」という言葉でも、LPの文言を差し替える実験と、プロダクトの機能を出し分ける実験では、実装する人も使う仕組みも別物だからです。

| 方式 | 主な実験対象 | 実装の担い手 | 配信と分析の関係 |
|------|------------|------------|----------------|
| Webビジュアル編集型 | LPやサイトの文言・レイアウト | マーケター中心（タグ設置後はノーコード） | ツールが配信し、GA4などで分析を補完 |
| feature flag型 | 機能・アルゴリズム・導線 | エンジニア（SDKを組み込む） | flagで配信を制御し、指標はツールやDWHで分析 |
| エンタープライズ統合型 | Web体験とパーソナライズ全般 | 開発・マーケの横断チーム | スイート内で配信・分析・自動最適化まで完結 |
| 内製 | 自社プロダクト全般 | エンジニアとデータ職 | 自前の割付ロジックとGA4やDWHで分析 |

### 各方式が向くケース

- **Webビジュアル編集型**: エンジニアの手を借りずにLPの訴求やレイアウトを検証したい場合に向きます。タグを一度設置すれば、以降の変更はマーケター側で完結します
- **feature flag型**: 検索ロジックや料金導線など、プロダクト側の実験に向きます。機能のリリース制御と実験が同じ仕組みに乗るため開発フローに組み込みやすく、サーバーサイド配信もこの方式に含まれます
- **エンタープライズ統合型**: パーソナライズや多変量テストまで一つの基盤で回したい場合の選択肢です。その分、横断チームの体制と教育が前提になります
- **内製**: 割付と集計を自社基盤で持つ選択です。自由度は最大ですが、統計の正しさとデータ品質の担保がすべて自社責任になります

### 「配信」と「分析」を分けて考える

誰にどの案を見せるかという配信と、差をどう測るかという分析は別の機能です。Optimize終了後はこの分離が前提になり、配信は第三者ツール、分析はツール内レポートとGA4の併用という構成が一般的になりました。では、両者の数値がずれたらどうするのか。どちらを意思決定の正とするかを連携設計の段階で決めておくと、判定のたびに議論が振り出しに戻る事態を防げます。

## 代表4製品：公式ドキュメントで確認できた機能

![VWO、Optimizely、Adobe Target、Statsigの公式確認済み主要機能を横並びカードで比較した図](https://assets.curumi.co.jp/articles/ab-test-tools-comparison/section-2.png)

代表製品の比較は、公式ドキュメントで確認できた機能に限定して行うのが安全です。以下は2026年7月時点で各社の公式ページに記載を確認できた内容の要約です。価格は非公開のものが多いため、次章の質問表で個別に確かめる前提で読んでください。

| 製品 | 公式に確認できた主な機能 |
|------|----------------------|
| VWO Feature Experimentation | feature flagの設定とflagルール管理、環境単位の権限、多変量ルール、セグメント配信、勝ちバリエーションの自動デプロイ、ホールドアウトグループ、承認フロー、複数SDK対応 |
| Optimizely | Feature Experimentation（JavaScript・Python・JavaなどのSDKを組み込みflag上で実験）とWeb Experimentation（スニペット設置でABテスト・多変量テスト）の2製品体制。オーディエンス設定、イベント計測、結果分析 |
| Adobe Target | 手動ABテスト、成績の良い体験へ配信を自動で寄せるAuto-Allocate、機械学習で個人ごとに出し分けるAuto-Targetの3タイプ。配分比率は非対称も可（新体験を5%だけに配信する例をドキュメントが示す） |
| Statsig | ランダム化比較試験としてのABテスト・多変量実験、p値と信頼区間による判定、割付単位をユーザーID・デバイスID・セッションIDの3種から選択、相互排他の並行実験 |

### 出典として確認したページ

- [VWO Feature Experimentationの公式ヘルプ](https://help.vwo.com/hc/en-us/categories/45598910060825-VWO-Feature-Experimentation)は、feature flagを軸にした実験・段階的リリース・ガバナンス機能を扱い、Webの見た目を編集する従来型の製品とは別領域として位置づけています
- [Optimizelyの開発者向け公式ページ](https://www.optimizely.com/developers/experimentation/)は、Feature ExperimentationがSDK組み込み、Web Experimentationがスニペット設置という実装の違いを説明しています。実験をflagルールの上に構築しStats Engineで結果を分析する設計は、同社ヘルプ記事でも確認できました（2026年7月時点）
- [Adobe Targetの公式ドキュメント](https://experienceleague.adobe.com/en/docs/target/using/activities/abtest/test-ab)は、3タイプの使い分けに加え、5を超える体験を2か所以上で検証する場合は先に多変量テストで影響の大きい領域を特定する指針を示しています
- [Statsigの公式ドキュメント](https://docs.statsig.com/experiments/overview)は、割付単位ごとの特性（ユーザーIDはセッション・デバイスをまたいで持続、デバイスIDは未登録ユーザー向け、セッションIDは単一セッションの行動検証向け）を説明しています

### この比較の読み方

ここに挙げた機能は候補選定の入口であり、製品の順位付けではありません。トラフィック規模、既存の開発スタック、分析基盤との相性で評価は入れ替わります。価格・無料枠・契約条件は公開情報だけでは確定できないため、本記事では断定せず、次章の質問表で自社条件に引き付けて確認する構成にしています。

## 価格の確かめ方：見積で確認する質問表

![ABテストツールの費用をライセンス費・実装費・サポート費の3層積み上げ棒グラフで示し、見積時の確認7項目を併記した図](https://assets.curumi.co.jp/articles/ab-test-tools-comparison/section-3.png)

見積比較では、課金単位や利用量を同じ条件で確認することが重要です。見積比較では、課金単位や利用量を同じ条件で確認することが重要です。価格が非公開の製品が多いABテストツールでは、相場表を信じるより見積時の質問リストを持つことが実用的です。課金単位が製品ごとに異なり（月間ユニークユーザー、セッション、イベント、席数など）、同じ「月額」でも中身が違うため、金額の一点比較は誤解を生みやすいのです。

### 見積時に確認する7項目

| 確認項目 | 見積時の質問例 |
|---------|--------------|
| 課金単位 | 何に対して課金されるか。月間ユニークユーザー、セッション、イベント、席数のどれか |
| トラフィック算定 | 対象ドメイン・サブドメイン・アプリのどこまでが計測対象か。超過時は追加課金か配信停止か |
| 環境数 | 本番のほか、ステージングや開発環境での利用が契約枠に含まれるか |
| 席数と権限 | 閲覧のみのメンバーも課金対象か。承認フローや権限管理は上位プラン限定か |
| サポート | 日本語サポートや導入支援の有無と費用。対応時間と範囲 |
| 実装費 | タグ・SDKの実装、同意管理ツールとの連携、データ整備を誰が担うか。外部委託する場合の初期費用 |
| 契約条件 | 最低契約期間、中途解約、自動更新、翌年度の改定条件 |

### 質問表の使い方

候補の各製品に同じ質問を投げ、回答を一つの表に埋めていくと、表面上の月額ではなく自社条件での総コストを比較できます。総コストにはライセンス費のほか、実装費と運用にかかる人件費が含まれます。トラフィックの伸びを見込むなら、現在の量だけでなく1〜2年後の想定量でも金額を出してもらうと、成長した途端に費用が跳ねる事態を避けられます。もう一つの副産物として、この質問に即答できない営業窓口しかない製品は、導入後のサポート品質も同水準だと考えて評価に織り込めます。

## 統計とデータ品質：有意差とビジネス判断を分ける

![4案の主指標改善率を横棒グラフで示し、p値・効果量・ガードレール指標など判定前の確認項目を並べた図](https://assets.curumi.co.jp/articles/ab-test-tools-comparison/section-4.png)

統計的有意性、ビジネス上の意味、データ品質は、別々の基準で判断することが重要です。ツールが「有意差あり」と表示しても、それだけで施策の価値が証明されたことにはなりません。

### 有意差が示すこと・示さないこと

[Statsigの公式ドキュメント](https://docs.statsig.com/experiments/overview)は、p値と信頼区間を使って実験結果を評価する方法を説明しています。p値は、差がないという仮定のもとで、観測値以上に極端な結果が得られる確率です。ただしp値が語るのは「偶然では説明しにくい」ことまでです。採用の価値があるかは、差の大きさ（効果量）、実装と保守のコスト、他指標への波及を合わせて判断します。有意でも小さすぎて投資に見合わない差もあれば、有意に届かなくても再検証に値する差もあります。

### ガードレール指標を先に決める

主指標のCV率が改善しても、売上単価、解約、表示速度、問い合わせの質が悪化しては本末転倒です。「これが悪化したら中止する・採用しない」という指標を開始前に列挙し、判定時には主指標とセットで確認します。ガードレールなしの運用は、局所最適でサイト全体を傷つけるリスクを見逃します。

### 割付単位とSRM：結果の信頼性を支える2つの確認

割付単位（ユーザー・デバイス・セッションのどれでランダム化するか）は分析の前提を決めます。Microsoft Researchの[WSDM 2017の研究論文](https://www.microsoft.com/en-us/research/publication/trustworthy-analysis-of-online-a-b-tests-pitfalls-challenges-and-solutions/)（Deng・Lu・Litz）は、標準的な統計分析が割付単位のiid（独立同分布）仮定に立つこと、そして個人ごとの効果のばらつきが大きい場合にこの近似が分散の過小推定を招き、差を過大に検出しうることを指摘しています。加えて、設定した配分比（例：50対50）と実際の割付数が乖離するSRM（サンプル比率不一致）は実装・計測の不具合を示すシグナルで、乖離が確認されたテストの結果は採用しないのが原則です。割付の仕組みは[ABテストのランダム割付の考え方](/blog/ab-test-random-assignment)で詳しく解説しています。

### 同意管理と表示性能

クライアント側で画面を書き換える方式では、ちらつき（フリッカー）や表示速度への影響が起きえます。同意管理ツール（CMP）を使っている場合は、同意前にテスト用スクリプトを発火させない制御も必要です。無償評価の段階で、自社の同意設定のまま実ページの表示品質を確かめておくと、導入後の手戻りを防げます。

## 導入前チェックリスト：実験が成立するかを先に判定する

ツールを契約する前に、自社で実験が成立するかどうかを判定することが先決です。直近でやりたいテストを1つ選び、次の8項目が埋まるかを確かめてみてください。埋まらない項目が多いほど、ツールより先に整えるべきものがあるサインです。

### 実験運用チェックリスト（8項目）

- **主指標**: このテストで動かしたい指標を1つに絞れているか
- **ガードレール指標**: 悪化したら中止・不採用とする指標を列挙したか
- **割付単位**: ユーザー・デバイス・セッションのどれで割り付けるか決めたか
- **MDE（検出したい最小の差）**: どれくらいの差があれば意思決定を変えるのかを数値にしたか
- **必要サンプル**: ベースラインのCV率とMDEから必要数を逆算したか。「◯件あれば十分」という固定の目安はどのサイトにも当てはまりません。計算手順は[ABテストの必要サンプルサイズの計算方法](/blog/ab-test-sample-size-calculation)を参照してください
- **停止規則**: いつ・何を見て終了判定するかを開始前に決めたか。途中経過を眺めて有利なタイミングで止める運用は誤判定の温床です
- **SRM確認**: 判定の前に割付比率の実測値を確認する手順があるか
- **実験台帳の責任者**: 仮説・設定・結果・採否の理由を記録し続ける担当者を決めたか

### 「導入しない」が正解になる条件

チェックリストが埋まらない典型は次のような状況です。月間のCV数が少なく、現実的な期間で差を検出できない。テスト結果を意思決定に使う場が存在しない。サイトの全面リニューアル直前で、結果がすぐ無効になる。台帳の責任者が決まらない。こうした状態でツールだけ契約しても費用が固定費化するだけです。その予算はユーザー調査やヒアリングによる仮説づくり、あるいはトラフィック獲得に回す方が合理的で、実験が成立する条件が整った時点で選定に戻れば十分間に合います。

## 機能は入場券：差がつくのは仮説と意思決定の運用

機能比較で見える製品間の差よりも、仮説と意思決定の運用能力の差が成果を分けます。各候補はそれぞれの実装方式に必要な配信・分析機能を備えていますが、Web編集、feature flag、エンタープライズ統合、内製では前提となる体制が異なるからです。

### 入場券とPODを混同しない

私たちがB2Bマーケティング支援で使う整理に、比較テーブルに乗るための要素（入場券）と選ばれる理由（POD）を区別する考え方があります（株式会社くるみ「CEP×POD」自社ポジショニング方法論、2026年）。これはツール選定にもそのまま当てはまります。

> 入場券は競合と同等であればよく、差を生むのは独自の要素です。ABテストツールの機能は実験を成立させる入場券であり、成果の差は「どんな仮説を立て、結果から何を決めるか」という運用の側に生まれます。

機能の多さで選ぶと、使わない機能に費用を払い続けることになりがちです。逆に、前章のチェックリストが回る組織なら、必要条件を満たす候補から方式と運用コストに合うものを選ぶことで、成果検証への道筋を作れます。

### 運用能力をAIで補強する視点

生成AI（ClaudeやGPTなど）の活用で、バリエーション案の量産や仮説の言語化は速くなりました。一方で、停止規則を守る、SRMを確認する、台帳に採否と理由を残すといった意思決定の規律は、自動では生まれません。実装の観点では、実験台帳の下書きや結果サマリーの整形をAIエージェントに任せ、人の時間は採否の判断と次の仮説の選定に使うという分担が現実的です。ツール選定の段階から、この規律を誰が担うのかを決めておくと、導入後の形骸化を防げます。

## ABテストツールに関するよくある質問

ABテストツールの選定でよく寄せられる質問に回答します。

### GA4だけでABテストは完結しますか？

完結しません。Googleアナリティクスの公式ヘルプ（2026年7月時点で確認）は、GA4でABテストを行うには第三者の実験ツールとの統合が必要で、テストの実行・管理はツール側、結果の解釈はGA4側と説明しています。連携時はイベント設計をそろえ、数値がずれた場合にどちらのレポートを正とするかを先に決めておきます。

### 無料で使えるABテストツールはありますか？

オープンソースや無料プランを持つ製品は存在しますが、無料枠の条件は変わりやすく、公開情報だけで断定するのは危険です。ライセンスが無料でも、実装・分析・運用の人件費はかかります。無料の選択肢を検討する際の見方は[無料ABテストツールの比較](/blog/ab-test-free-tools-comparison)で扱っています。

### 統計の専門知識がないと運用できませんか？

判定の計算自体は多くのツールが自動化しています。必要なのは計算力よりも解釈の規律です。有意差とビジネス上の意味を分ける、開始前に決めた停止規則を守る、判定前にSRMを確認する。この3点を押さえれば実務は回せます。逆にこの規律がないと、高機能なツールでも誤った結論を量産してしまいます。

### ABテストはSEOに悪影響がありますか？

Googleは、[Search Centralの公式ガイド](https://developers.google.com/search/docs/crawling-indexing/website-testing)に沿って実施するテストは通常、検索でほとんど、またはまったく影響しないと説明しています。ただし、検索エンジンとユーザーに別の内容を見せるクローキングはスパムポリシー違反です。テスト用URLを分ける場合はrel="canonical"と302（一時）リダイレクトを使い、テスト終了後は不要な差し替えを速やかに取り除きます。

### ABテストツールが不要なのはどんな場合ですか？

月間のCV数が少なく現実的な期間で差を検出できない場合、テスト結果を意思決定に使う体制がない場合、直後に全面リニューアルを控えている場合は、見送る判断が合理的です。その間は定性調査や仮説づくり、トラフィック獲得に投資し、実験が成立する条件が整った段階で再検討することをおすすめします。

## まとめ：5つの入力で導入可否を決める

ABテストツールの導入可否は、実験対象、実装方式、統計とデータ品質、総コスト、運用能力という5つの入力で決まります。Google Optimizeが2023年9月30日に終了し、配信は第三者ツール、分析はGA4との併用という構成が前提になった今こそ、製品の知名度ではなく自社条件からの逆算が選定の近道です。

### 導入判断の手順

1. **実験対象を決める** — LPなどWebの見た目か、機能・導線などプロダクト側か
2. **実装方式を選ぶ** — Webビジュアル編集型、feature flag型、エンタープライズ統合型、内製のどれが自社の開発体制に合うか
3. **統計とデータ品質の要件を確認する** — 割付単位、ガードレール指標、SRM確認を運用に組み込めるか
4. **見積質問表で総コストを出す** — 課金単位・トラフィック・環境数・席数・サポート・実装費まで含めて比較する
5. **運用チェックリストで最終判定する** — 8項目が埋まらなければ「今は導入しない」を選び、先に体制と仮説を整える

### 次の一歩

候補が数製品に絞れたら、無償評価の期間に本記事のチェックリストを使ってテストを1本設計してみてください。最初のテストの具体的な進め方は[LPのABテストのやり方](/blog/lp-ab-test-how-to)で解説しています。機能は入場券にすぎず、成果は仮説と意思決定の運用から生まれます。実験体制の設計や仮説づくりを外部と組む場合も、この5つの入力を先に整理しておけば、支援側との議論を最初から具体的に始められます。