🧬AI×BigQueryでEC商品説明文のA/Bテスト結果を分析し改善提案する

はじめに：説明文で売れ方が変わる

同じ商品でも、商品説明文の書き方ひとつで売れ方は変わります。スペックを淡々と並べた説明文と、使ったあとの暮らしが想像できる説明文では、同じアクセス数でも購入数に差が出ることは珍しくありません。値段も写真も在庫も同じなのに、文章だけで結果が動く。これは怖くもあり、同時に大きな伸びしろでもあります。

問題は、その差を「なんとなく良くなった気がする」で終わらせてしまうことです。説明文を書き換えて、翌週の売上が少し増えたとしても、それが文章のおかげなのか、たまたまその週に流入が増えただけなのかは、感覚では区別できません。きちんと出し分けて、きちんと計測して、統計的に判断する。この記事では、その一連の流れをGA4とBigQuery、そしてAIを組み合わせて回す方法を解説します。

A/Bテスト自体は新しい手法ではありませんが、専用のテストツールを入れなくても、GA4のイベントとBigQueryのクエリだけで群別のCVRを比較し、差が偶然かどうかを確かめることはできます。さらに、勝った理由の言語化や次の改善案づくりは、AIが得意とするところです。データで結果を出し、AIで次の一手を考える。この組み合わせが、説明文改善のサイクルを速くしてくれます。

A/Bの出し分けと計測設計（GA4）

まず決めるべきは、何をどう出し分けるかです。商品説明文のA/Bテストでは、同じ商品ページに対してパターンAとパターンBの2種類の説明文を用意し、訪問者をどちらかに振り分けます。振り分けの方法はカートシステムやCMSによって異なりますが、ユーザー単位で一貫して同じパターンを見せることが重要です。同じ人が訪問のたびに違う説明文を見てしまうと、どちらの効果かわからなくなります。

GA4側では、ユーザーがどちらのパターンを見たかを記録します。商品ページの表示時に、テスト名とパターンをパラメータとして持つカスタムイベントを送るのがシンプルです。たとえば description_ab というイベントに、test_name（テストの識別子）と variant（A または B）を付けて送信します。あわせて、購入完了時の purchase イベントが正しく計測されていることも確認しておきます。

計測設計で気をつけたいのは、振り分けと計測のタイミングをそろえることです。ページが表示された瞬間にパターンが確定し、その確定した値をイベントに乗せる。この順番が崩れると、見ていないパターンが記録されたり、イベントが欠損したりします。テストを始める前に、開発ツールでイベントが意図どおり飛んでいるかを必ず確認してください。GA4のDebugViewでリアルタイムに確認できます。

振り分けの単位も最初に決めておきます。ログイン前のユーザーが多いECでは、ブラウザのCookieやローカルストレージにパターンを保存し、同じ端末では常に同じ説明文を見せる方法が一般的です。ただしCookieが消えたり、別の端末で見たりすると、同じ人が別パターンに振り分けられることがあります。完璧な一貫性は難しいので、ある程度のばらつきは前提として受け入れ、その分サンプルを多めに集めて埋める、という割り切りが現実的です。

もうひとつ、テスト期間中は説明文以外の条件を動かさないことも大切です。テストの途中で価格を変えたり、別のセールを重ねたり、写真を差し替えたりすると、CVRの差が説明文によるものなのか他の変更によるものなのか、切り分けられなくなります。一度に変える要素はひとつだけ、というのがA/Bテストの基本姿勢です。

また、テスト対象の商品はある程度アクセスがあるものを選びます。1日に数人しか見ないページでテストしても、結論が出るまでに何ヶ月もかかってしまいます。流入が多く、かつ説明文の影響が出やすい商品から始めるのが現実的です。GA4からBigQueryへのエクスポートを設定しておけば、これらのイベントは生ログとして蓄積され、あとから自由に集計できます。

BigQueryで群別CVR・有意差の見方

イベントがBigQueryに溜まったら、パターンごとにユニークユーザー数と購入ユーザー数を数え、CVRを比べます。ここで大事なのは、分母をそろえることです。説明文を見た人を分母にし、その中で購入に至った人を分子にします。流入経路や全体のセッション数を分母にしてしまうと、説明文の効果以外のノイズが混ざります。

次のクエリは、GA4エクスポートのイベントテーブルから、テストを見たユーザーと購入したユーザーをパターン別に集計する例です。

-- description_ab を見たユーザーと purchase したユーザーをパターン別に集計
WITH exposed AS (
  SELECT
    user_pseudo_id,
    (SELECT value.string_value FROM UNNEST(event_params)
      WHERE key = 'variant') AS variant
  FROM `your_project.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'
    AND event_name = 'description_ab'
    AND (SELECT value.string_value FROM UNNEST(event_params)
          WHERE key = 'test_name') = 'item_a_desc_v1'
),
-- 1ユーザーは最初に見たパターンに固定する
first_variant AS (
  SELECT user_pseudo_id, ANY_VALUE(variant) AS variant
  FROM exposed
  GROUP BY user_pseudo_id
),
buyers AS (
  SELECT DISTINCT user_pseudo_id
  FROM `your_project.analytics_123456789.events_*`
  WHERE _TABLE_SUFFIX BETWEEN '20260801' AND '20260831'
    AND event_name = 'purchase'
)
SELECT
  f.variant,
  COUNT(*) AS users,
  COUNTIF(b.user_pseudo_id IS NOT NULL) AS buyers,
  ROUND(COUNTIF(b.user_pseudo_id IS NOT NULL) / COUNT(*) * 100, 2) AS cvr_pct
FROM first_variant f
LEFT JOIN buyers b USING (user_pseudo_id)
GROUP BY f.variant
ORDER BY f.variant;

これでパターンAとBのCVRが並びます。仮にAが2.1%、Bが2.6%だったとして、ここで早合点しないことが肝心です。0.5ポイントの差が本物なのか、それとも偶然のばらつきなのかは、サンプルサイズによって意味が変わります。

差が偶然かどうかを大まかに確かめる方法として、2つの比率の差の検定（z検定）の考え方を使います。各パターンのCVRと人数から標準誤差を求め、差が標準誤差の何倍に当たるかを見るというものです。次のクエリは、その目安となるz値を計算します。

-- 2群のCVR差に対する z 値の目安を計算
WITH stats AS (
  SELECT
    SUM(IF(variant = 'A', users, 0))  AS n_a,
    SUM(IF(variant = 'A', buyers, 0)) AS x_a,
    SUM(IF(variant = 'B', users, 0))  AS n_b,
    SUM(IF(variant = 'B', buyers, 0)) AS x_b
  FROM `your_project.tmp.ab_summary`  -- 上のクエリ結果を保存したテーブル
)
SELECT
  SAFE_DIVIDE(x_a, n_a) AS p_a,
  SAFE_DIVIDE(x_b, n_b) AS p_b,
  SAFE_DIVIDE(x_b, n_b) - SAFE_DIVIDE(x_a, n_a) AS diff,
  SAFE_DIVIDE(
    SAFE_DIVIDE(x_b, n_b) - SAFE_DIVIDE(x_a, n_a),
    SQRT(
      SAFE_DIVIDE(x_a + x_b, n_a + n_b) *
      (1 - SAFE_DIVIDE(x_a + x_b, n_a + n_b)) *
      (SAFE_DIVIDE(1.0, n_a) + SAFE_DIVIDE(1.0, n_b))
    )
  ) AS z_value
FROM stats
-- 両群に一定数のユーザーが集まるまでは計算しない（ゼロ除算・過小サンプル対策）
WHERE n_a > 0 AND n_b > 0;

なお、どちらかの群の人数がまだ0のときは標準誤差の計算が割り算で壊れるため、SAFE_DIVIDE で安全に処理しつつ、両群にユーザーが集まるまで（ここでは n_a > 0 AND n_b > 0）は計算しないようにしています。本来は数十人程度では結論が出ないので、件数のしきい値はもっと大きく取るのが現実的です。

z値の絶対値がおおむね1.96を超えていれば、有意水準5%でAとBに差があると言える目安になります。1.96に届かなければ、差はまだ偶然の範囲かもしれないので、テストを継続するか、結論を保留します。あくまで目安であり、本格的な判断には統計の専門知識や専用ツールを併用することをおすすめします。

なお、CVRだけでなく、購入単価や1ユーザーあたり売上まで見ると、より立体的に評価できます。説明文の違いがまとめ買いを促した、といった効果はCVRだけでは見えません。売上を絡めた集計は、別記事のECのセール施策効果をGA4×BigQueryでbefore/after比較する分析テンプレートで扱った考え方が応用できます。

AIに勝ち要因の分析・改善案を出させる

数字でどちらが勝ったかがわかったら、次は「なぜ勝ったのか」を言語化します。ここがAIの出番です。集計結果と両方の説明文をAIに渡し、勝ったパターンの何が効いたのかを推測させ、さらに次の改善案を出させます。

人間が勝ち要因を考えると、どうしても「自分が書いたから」「最近こういう書き方が流行りだから」といったバイアスが入りがちです。AIに分析させると、文章の構造、訴求の順番、具体性の度合いといった観点を、ある程度フラットに洗い出してくれます。もちろんAIの推測も仮説に過ぎませんが、次のテストの種としては十分役立ちます。

AIに渡すプロンプトは、たとえば次のような構成にします。

あなたはECの商品説明文を分析する担当者です。
以下のA/Bテスト結果と2つの説明文を読み、
(1) パターンBが勝った要因の仮説を3つ
(2) 次に試すべき改善案を3つ
を、根拠とともに挙げてください。
データにない断定は避け、仮説であることを明示してください。

# テスト結果
パターンA: 表示2,480人 / 購入52人 / CVR 2.10%
パターンB: 表示2,510人 / 購入65人 / CVR 2.59%
z値: 2.31（5%水準で有意の目安）

# 説明文A
（パターンAの全文をここに貼る）

# 説明文B
（パターンBの全文をここに貼る）

ポイントは、データにない断定をさせないことと、仮説であることを明示させることです。AIは聞かれると自信たっぷりに理由を語りますが、それが必ず正しいわけではありません。あくまで「次に検証する仮説のリスト」として受け取り、出てきた改善案をまた次のA/Bテストにかける。この往復が、説明文を着実に良くしていきます。

出てきた改善案は、そのまま全部を一度に試さないことも大切です。3つの案をまとめて反映してしまうと、次のテストで勝っても負けても、どの変更が効いたのかわからなくなります。優先度の高いものから順に、ひとつずつ検証していく。遠回りに見えますが、効いた要素を確実に特定できるので、結果的に説明文の「勝ちパターン」が手元に蓄積されていきます。

BigQueryの中でAIを呼び出す方法もあります。Gemini連携を使えば、集計結果をテーブルに保持したまま、SQLの延長でテキスト分析を回せます。説明文が何百商品もある場合は、1件ずつ手作業でAIに貼るより、まとめて処理できる仕組みのほうが現実的です。この方法はBigQueryのAI.GENERATE関数でGeminiにテキスト分析させるで詳しく解説しています。

⚠️ 有意性・サンプルサイズ・複数検定の注意

最後に、A/Bテストでつまずきやすい落とし穴を整理します。ここを押さえないと、データに基づいているつもりで、実は誤った結論に飛びついてしまいます。

ひとつ目は、サンプルサイズの不足です。数十人ずつのデータでCVRを比べても、ほとんどの差は偶然の範囲に収まります。CVRが低いECほど、結論を出すには多くのユーザーが必要になります。テストを始める前に、検出したい差の大きさからおおよその必要人数を見積もり、その人数が集まるまでは結論を出さない、という規律が大切です。

ふたつ目は、テストを早く止めてしまうことです。途中経過でBが勝っているのを見て、満足してすぐ止めると、たまたま良かった瞬間を結果として採用してしまう危険があります。これは「のぞき見問題」と呼ばれ、本来は有意でない差を有意だと誤判定する原因になります。あらかじめ期間か必要人数を決め、そこに達するまでは判断しないのが基本です。

みっつ目は、複数検定の問題です。ひとつのテストでCVR、購入単価、滞在時間、離脱率と何でもかんでも比べて、どれかひとつでも差が出たら勝ちとすると、偶然の差を拾う確率が跳ね上がります。たくさんの指標を同時に見るほど、何かが偶然に有意に見えてしまうのです。主役となる指標（多くの場合はCVR）を最初に1つ決め、それで判断する。ほかの指標は参考程度に留めます。

そして、統計的に有意であることと、ビジネス上意味があることは別だという点も忘れないでください。10万人を集めればごくわずかな差も有意になりますが、その差が利益に見合うとは限りません。逆に、有意でなくても方向性として一貫しているなら、改善のヒントにはなります。数字は判断材料であって、判断そのものではない、という距離感を保つことが、データを長く使い続けるコツです。

季節やセールの影響にも注意します。テスト期間にたまたまセールやイベントが重なると、その効果が説明文の差に紛れ込みます。できるだけ平常時にテストを行うか、難しい場合は両パターンが同じ条件にさらされるよう、同時並行で出し分けることで影響を均します。AとBを別の週に分けて比べるのではなく、同じ期間に同時に振り分けるほうが、外部要因の影響を受けにくくなります。

まとめ

商品説明文のA/Bテストは、特別なツールがなくても、GA4のイベントとBigQueryのクエリだけで回せます。流れとしては、ユーザー単位で説明文を出し分け、見たパターンと購入をGA4で計測し、BigQueryで群別CVRを集計して、z値で差が偶然でないかを確かめる。ここまでがデータの仕事です。

その先の「なぜ勝ったのか」「次に何を試すか」は、AIに仮説を出させると効率が上がります。ただしAIの答えはあくまで仮説であり、それをまた次のテストで検証するという往復があってこそ、説明文は着実に良くなっていきます。サンプルサイズ、早すぎる停止、複数検定といった落とし穴を避けながら、ひとつずつ検証を積み重ねてください。

文章という、これまで感覚で判断されがちだった領域を、数字とAIで地道に磨いていく。手間はかかりますが、同じアクセス数のまま売上を伸ばせる数少ない手段のひとつです。まずはアクセスの多い商品をひとつ選び、小さなA/Bテストから始めてみてください。