「A と B で購入率に差がある」と報告する前に、AI に有意差の判定を頼んでいる事業担当・マーケターの方向けの記事です。AI の有意差判定が正しいかを、GA4 の公開サンプルデータで 9 回試し、SQL と手計算で検算しました。読み終わると、AI への頼み方と、答えの数値を自分で確かめる手順が分かり、「有意です」を報告に書いてよいかを判断できるようになります。
この記事で分かること
- AI に有意差を判定させる時の、質問の書き方 3 通りと、それぞれの答えの違い
- AI が答えた p 値（差が本当はないと仮定した時に、今と同じかそれ以上の差が偶然出る確率）を、SQL と電卓で検算する手順
- 人数が少ない時や、数値を丸めた時に、結論がどう変わるか
ざっくり結論
筆者が 2026-11-10 に試した範囲では、AI（Claude の Sonnet 系モデル）の答えは 9 回とも、検定の統計量・p 値・結論が検算と一致しました。頼み方を変えて変わったのは、数値ではなく、注意書きの量と、途中の値を確かめられるかどうかでした。
一方で、3 か月分のデータの p 値は 0.0539 で、よく使われる基準の 0.05 のすぐ上でした。購入率を 1.60% と 1.70% に丸めてから同じ式に入れると、p 値は 0.045 になり「有意」に逆転します。AI の答えが正しくても、報告に書く人が数値を丸めると結論が変わりうる、というのが今回いちばんの発見です。
有意差とは：偶然のぶれと区別する考え方
有意差（偶然のぶれだけでは説明しにくい差）を判定する作業を、有意差検定と呼びます。購入率は、同じサイトでも日によって上下します。だから、2 つのグループの購入率が少し違うだけでは、「本当に差がある」のか「たまたま」なのかを区別できません。
検定では、まず「2 つの購入率は本当は同じ」という仮説を置きます。これを 帰無仮説（否定されることを期待して置く仮説）と呼びます。そのうえで、帰無仮説が正しいとした時に、今の差が出る確率（p 値）を計算します。
p 値が、事前に決めた 有意水準（どこまで小さければ偶然ではないとみなすかの線。よく 5% = 0.05 を使う）を下回れば「有意な差がある」と判断します。NIST（米国国立標準技術研究所）のハンドブックは、2 つの割合が等しいかを、z という統計量で検定する方法を示しています（NIST/SEMATECH e-Handbook: Comparing two proportions）。
この方法を z 検定 と呼びます。購入率の差を 標準誤差（偶然のぶれで差がどれくらい動くかの目安）で割った値が z です。z のように、検定の判断に使うために計算する数値を 検定統計量 と呼びます。
z が 0 から遠いほど、差が偶然のぶれより大きいことを表します。
使うデータ：GA4 の公開サンプルの端末別の購入率
使ったのは、Google が BigQuery で公開している GA4 のサンプルデータ ga4_obfuscated_sample_ecommerce です。Google Merchandise Store（Google ブランド商品のオンラインストア）の 2020 年 11 月 1 日から 2021 年 1 月 31 日までの 3 か月分のデータで、BigQuery の無料枠で十分扱えるとされています（Google for Developers: GA4 の BigQuery サンプル データセット）。
集計の定義は次のとおりです。
| 項目 | 定義 | 根拠 |
|---|---|---|
| 端末 | device.category（mobile・tablet・desktop） | BigQuery Export スキーマ |
| ユーザー数 | user_pseudo_id（ユーザーごとに割り当てられる仮名の ID）の重複を除いた数 | 公式のサンプルクエリと同じ数え方 |
| 購入したユーザー | 期間内に purchase イベントを 1 回以上送った user_pseudo_id | purchase は購入手続きの完了時に送る推奨イベント（推奨イベント） |
購入したユーザーの定義は、筆者が決めたものです。期間は、1 日（2020-12-01）、1 週間（2020-12-01〜07）、3 か月（全期間）の 3 通りにしました。人数が変わると結論がどう変わるかを見るためです。
-- 端末別のユーザー数と購入したユーザー数（期間は _TABLE_SUFFIX で切り替える）
SELECT
device.category AS device,
COUNT(DISTINCT user_pseudo_id) AS users,
COUNT(DISTINCT IF(event_name = 'purchase', user_pseudo_id, NULL)) AS buyers
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20210131'
GROUP BY device
ORDER BY device;筆者がこの SQL を 2026-11-10 に実行した結果が、次の表です（購入率は筆者が計算）。
| 期間 | 端末 | ユーザー数 | 購入したユーザー数 | 購入率 |
|---|---|---|---|---|
| 1日 | desktop | 2,498 | 59 | 2.36% |
| 1日 | mobile | 1,721 | 38 | 2.21% |
| 1日 | tablet | 89 | 1 | 1.12% |
| 1週間 | desktop | 14,706 | 313 | 2.13% |
| 1週間 | mobile | 9,966 | 213 | 2.14% |
| 1週間 | tablet | 570 | 13 | 2.28% |
| 3か月 | desktop | 158,917 | 2,541 | 1.60% |
| 3か月 | mobile | 109,195 | 1,851 | 1.70% |
| 3か月 | tablet | 6,250 | 97 | 1.55% |
なお、このデータは本物らしく見えるよう難読化されており、内部の整合性が少し制限される可能性があると公式ページに書かれています（Google for Developers）。数値は手順を学ぶための例として見てください。
AI に渡した集計表と、頼み方 3 通り
上の表を期間ごとに AI へ渡し、「desktop と mobile の購入率に差があるか」を聞きました。頼み方は次の 3 通りです。
| 頼み方 | 質問文の要点 | ねらい |
|---|---|---|
| 結論だけ | 「有意な差がありますか。結論だけ答えてください」 | 忙しい時に一番やりがちな聞き方 |
| 途中を書かせる | 「有意水準 5% で判定し、検定の名前、購入率、検定統計量、p 値を、計算の途中の値も含めて書いて」 | 答えを検算できる形にする |
| 式を指定 | NIST の式をそのまま渡し、各値を小数で書かせる | 検定の種類の取り違えを防ぐ |
実行の条件は次のとおりです。条件を書いておかないと、読者が同じ結果を出せるかを判断できないためです。
- 実行日: 2026-11-10。Claude Code の CLI から、モデル
claude-sonnet-5-5に質問 - コード実行やファイル操作などの道具はすべて無効（AI は頭の中の計算だけで答えた）
- 各条件 1 回だけ。同じ質問をもう一度すると、言い回しや桁数が変わる可能性がある
- ChatGPT など他の AI では試していない
式を指定した時の質問文は、次のとおりです（表の部分は期間ごとに差し替えました）。自分のデータで試す時は、表と端末名を入れ替えて使えます。
次の表は、あるECサイトの端末別のユーザー数と、購入したユーザー数です。
| 端末 | ユーザー数 | 購入したユーザー数 |
|---|---|---|
| desktop | 158917 | 2541 |
| mobile | 109195 | 1851 |
| tablet | 6250 | 97 |
desktop と mobile の購入率に差があるかを、次の式で判定してください。2標本の割合の差の z 検定（両側、有意水準5%）。
p̂1 = x1/n1、p̂2 = x2/n2、合併した割合 p̂ = (x1+x2)/(n1+n2)
z = (p̂1 − p̂2) / √( p̂(1−p̂)(1/n1 + 1/n2) )
p̂1・p̂2・p̂・分母（標準誤差）・z・p値を小数で書き、結論を書いてください。desktop を1、mobile を2とします。結論だけを聞いた時の答え（3 か月）
有意差はありません(5%水準)。
購入率は desktop が約1.60%、mobile が約1.70%で、2標本比率のz検定では z≈1.93、p≈0.054 でした。
ただし p値は5%に非常に近く、境界線上の結果です。「結論だけ」と頼んでも、AI は検定の名前と z・p 値を添えました。ただし AI は z を 1.93 と正の値で書きました。検算の z は −1.93 なので、符号は逆です。z の値だけでは、どちらの購入率が高いかはこの答えから分かりません（購入率は文中に書かれています）。
途中を書かせた時の答え（3 か月、原文から抜粋）
2標本の比率の差の検定(プールした分散を用いる z 検定、両側)です。
（中略）
- desktop: p₁ = 2541 / 158917 ≈ 0.015989(1.599%)
- mobile: p₂ = 1851 / 109195 ≈ 0.016951(1.695%)
（中略）
- プールした購入率: p̂ = (2541 + 1851) / (158917 + 109195) = 4392 / 268112 ≈ 0.016381
（中略）
- 標準誤差: SE = √(0.016113 × 1.5451×10⁻⁵) ≈ 4.990×10⁻⁴
（中略）
- z = (p₁ − p₂) / SE ≈ −0.000962 / 0.000499 ≈ −1.93
- 両側 p値 = 2 × P(Z ≤ −1.928) ≈ 0.054
（中略）
ただし p 値は境界に近いため、データを追加して再検証する価値はあります。途中の値が並ぶので、どの段階で数値がずれたかを 1 行ずつ確かめられます。この答えは、差の 信頼区間（本当の差がおそらく入る範囲）も自分から計算していました。
検算：2 つの割合の差の検定を SQL と手計算で行う
検算には、NIST のハンドブックにある 2 標本の割合の差の z 検定を使います（NIST: Comparing two proportions）。式は次のとおりです。
p̂1 = x1 / n1 （desktop の購入率。x は購入した人数、n はユーザー数）
p̂2 = x2 / n2 （mobile の購入率）
p̂ = (x1 + x2) / (n1 + n2) （2 群をまとめた購入率）
z = (p̂1 − p̂2) / √( p̂ × (1 − p̂) × (1/n1 + 1/n2) )
両側検定: |z| が 1.96 以上なら、有意水準 5% で有意z が分かれば、正規分布（平均を中心に左右対称な釣り鐘形の分布。人数が多い時の偶然のぶれはこの形に近づく）の表から p 値を読めます。筆者が確認した範囲では、BigQuery の SQL だけで正規分布の確率を求める組み込みの関数が見つからなかったため、z までを SQL で計算し、p 値は Node.js で計算しました。
-- 3 か月の desktop と mobile について、z まで SQL で計算する
WITH agg AS (
SELECT
device.category AS device,
COUNT(DISTINCT user_pseudo_id) AS n,
COUNT(DISTINCT IF(event_name = 'purchase', user_pseudo_id, NULL)) AS x
FROM `bigquery-public-data.ga4_obfuscated_sample_ecommerce.events_*`
WHERE _TABLE_SUFFIX BETWEEN '20201101' AND '20210131'
AND device.category IN ('desktop', 'mobile')
GROUP BY device
),
pair AS (
SELECT
MAX(IF(device = 'desktop', n, NULL)) AS n1, MAX(IF(device = 'desktop', x, NULL)) AS x1,
MAX(IF(device = 'mobile', n, NULL)) AS n2, MAX(IF(device = 'mobile', x, NULL)) AS x2
FROM agg
)
SELECT
x1 / n1 AS p1,
x2 / n2 AS p2,
(x1 + x2) / (n1 + n2) AS p_pool,
(x1 / n1 - x2 / n2)
/ SQRT((x1 + x2) / (n1 + n2) * (1 - (x1 + x2) / (n1 + n2)) * (1 / n1 + 1 / n2)) AS z
FROM pair;SQL の結果と、電卓代わりの Node.js で同じ式を計算した結果は、小数 6 桁以上で一致しました。筆者が計算した検算の値は次のとおりです。
まず、式に入れる購入率です。
| 期間 | desktop の購入率 | mobile の購入率 | まとめた購入率 |
|---|---|---|---|
| 1日 | 0.023619 | 0.022080 | 0.022991 |
| 1週間 | 0.021284 | 0.021373 | 0.021320 |
| 3か月 | 0.015989 | 0.016951 | 0.016381 |
次に、その購入率から計算した標準誤差・z・p 値と、判定です。
| 期間 | 標準誤差 | z | 両側 p 値 | 5% で有意か |
|---|---|---|---|---|
| 1日 | 0.0046951 | 0.3277 | 0.7431 | いいえ |
| 1週間 | 0.0018742 | −0.0474 | 0.9622 | いいえ |
| 3か月 | 0.00049895 | −1.9277 | 0.0539 | いいえ（境界） |
結果を比べる：統計量・p 値・結論
AI の 9 回の答えと、検算の値を並べたのが図 1 と次の 2 つの表です。
1 つ目は、AI の答えと突き合わせの結果です。
| 期間 | 頼み方 | AI の z | AI の p 値 | 突き合わせ |
|---|---|---|---|---|
| 1日 | 結論だけ | 0.33 | 0.74 | 一致 |
| 1日 | 途中を書かせる | 0.328 | 0.743 | 一致 |
| 1日 | 式を指定 | 0.328 | 0.743 | 一致 |
| 1週間 | 結論だけ | 0.05 | 0.96 | 絶対値は一致（符号は書かれていない） |
| 1週間 | 途中を書かせる | −0.047 | 0.96 | 一致 |
| 1週間 | 式を指定 | −0.047 | 0.962 | 一致 |
| 3か月 | 結論だけ | 1.93 | 0.054 | 絶対値は一致（符号は書かれていない） |
| 3か月 | 途中を書かせる | −1.93 | 0.054 | 一致 |
| 3か月 | 式を指定 | −1.93 | 0.054 | 一致 |
2 つ目は、突き合わせに使った検算の値と結論です。AI の結論は、9 回とも「有意でない」でした。
| 期間 | 検算の z | 検算の p 値 | 検算の結論 |
|---|---|---|---|
| 1日 | 0.3277 | 0.7431 | 有意でない |
| 1週間 | −0.0474 | 0.9622 | 有意でない |
| 3か月 | −1.9277 | 0.0539 | 有意でない |
図 1 のグラフの値は、これらの表の z の絶対値です。今回の 1 回ずつの試行では、9 回とも数値と結論が検算と合い、計算の誤りは見つかりませんでした。途中を書かせた答えの差の信頼区間（下限 −0.00195、上限 +0.00002）も、筆者の計算と一致しました。
頼み方で違いが出たのは、数値以外の部分です。図 4 のとおり、注意書きの量と、途中の値を確かめられるかどうかが変わりました。
| 項目 | 結論だけ | 途中を書かせる | 式を指定 |
|---|---|---|---|
| z と p 値が検算と合った | 3 / 3 | 3 / 3 | 3 / 3 |
| 結論が検算と合った | 3 / 3 | 3 / 3 | 3 / 3 |
| z の符号 | 書かない | 書く | 書く |
| 途中の値を確かめられる | できない | できる | できる |
| 「差がない証明ではない」などの注意 | 1 / 3 | 2 / 3 | 1 / 3 |
| 「端末が原因とは言えない」への言及 | 0 / 3 | 0 / 3 | 0 / 3 |
注意の回数は、3 期間の答えのうち、その種類の注意を 1 つ以上書いた回数です（筆者が答えの文から分類）。どの頼み方でも、「端末が購入の原因とは言えない」という点には触れませんでした。
人数を変えると結論はどう変わるか（1 日・1 週間・3 か月）
人数が増えるほど、購入率のぶれ幅は狭くなります。図 2 は、端末別の購入率の 95% 信頼区間を、期間ごとに並べたものです。
信頼区間は、筆者が「購入率 ± 1.96 × √(購入率 ×（1 − 購入率）÷ 人数)」という式（正規近似、つまり購入率のぶれを正規分布に当てはめて計算する方法）で計算しました。
| 期間 | 端末 | 下限 | 購入率 | 上限 | 幅（ポイント） |
|---|---|---|---|---|---|
| 1日 | desktop | 1.77% | 2.36% | 2.96% | 1.19 |
| 1日 | mobile | 1.51% | 2.21% | 2.90% | 1.39 |
| 1日 | tablet | 0%（計算上は −1.07%） | 1.12% | 3.31% | 4.38 |
| 1週間 | desktop | 1.90% | 2.13% | 2.36% | 0.47 |
| 1週間 | mobile | 1.85% | 2.14% | 2.42% | 0.57 |
| 1週間 | tablet | 1.06% | 2.28% | 3.51% | 2.45 |
| 3か月 | desktop | 1.54% | 1.60% | 1.66% | 0.12 |
| 3か月 | mobile | 1.62% | 1.70% | 1.77% | 0.15 |
| 3か月 | tablet | 1.25% | 1.55% | 1.86% | 0.61 |
1 日だけのデータでは、desktop の幅が約 1.2 ポイントあります。購入率の差は 0.15 ポイントしかないので、これを見分けるのは無理だと分かります。3 か月に広げると幅は 0.12 ポイントまで狭まり、約 0.1 ポイントの差が境界線ぎりぎりまで近づきました。
1 日の tablet は、式そのものが合わない
1 日の tablet は 89 人中 1 人しか購入していません。下限がマイナスになったのは、人数が少なすぎて正規分布で近似する前提が崩れているためです。NIST のハンドブックは、z 検定は標本が十分大きい時に使う方法で、小さな標本には フィッシャーの正確確率検定（2×2 の表から確率をそのまま数える方法）が良い選択だとしています（NIST）。
筆者が 1 日の desktop と tablet をフィッシャーの検定で比べると、片側の p 値は 0.381 でした。NIST の説明に従って 2 倍すると両側で 0.762 です。z 検定（p = 0.446）とは値が違いますが、どちらも有意ではありません。
少人数の群が入る時は、AI に「人数が少ない群があるので、フィッシャーの正確確率検定も使って」と頼むと安全です。
丸め方ひとつで結論が逆になる
3 か月の p 値は 0.0539 で、0.05 のすぐ上でした。そこで筆者は、途中で数値を丸めた場合に結論がどう変わるかを計算しました。
| 計算に使った購入率 | z | 両側 p 値 | 5% で有意か |
|---|---|---|---|
| 丸めない（0.015989 と 0.016951） | −1.9277 | 0.0539 | いいえ |
| % で小数 3 桁（1.599% と 1.695%） | −1.9240 | 0.0543 | いいえ |
| % で小数 1 桁（1.6% と 1.7%） | −2.0026 | 0.0452 | はい |
報告資料で「desktop 1.6%、mobile 1.7%」と丸めた表を作り、その表を AI に渡して判定させると、AI が正しく計算しても「有意」と答えると考えられます（この渡し方は今回試していません）。AI に渡すのは丸める前の人数（ユーザー数と購入した人数）にし、割合は AI と検算の両方で計算するのが安全です。
検算の手順（番号付き）
図 3 は、AI の判定を報告に使うまでの流れです。
- SQL で、比べたいグループごとのユーザー数と購入したユーザー数を数えます。
- 集計表を、丸めない人数のまま AI に渡します。
- 質問文に、検定の式、両側検定、有意水準 5% を書き、途中の値も書かせます。
- 同じ式を SQL かスプレッドシートで計算し、まとめた購入率・標準誤差・z を出します。
- z の絶対値を 1.96 と比べ、5% で有意かを判定します（p 値は標準正規分布の表や関数で求めます）。
- AI の z・p 値・結論と、検算の値を 1 つの表に並べます。
- 合わない時は、AI がどの検定を使ったかを確かめ、式を指定して聞き直します。
- 合った時だけ、「差がある（または、あるとは言えない）」と、「原因かどうかは分からない」を分けて報告に書きます。
検算の値と AI の値がずれる時は、計算の誤りとは限りません。AI が別の検定を選んでいる場合があるためです。今回の途中を書かせた答えも、カイ二乗検定（表の各マスの人数のずれから差を調べる検定）で計算しても同じ結果になる、と書き添えていました。
標準誤差の出し方が違うだけでも値は変わります。筆者が 3 か月のデータで、2 群をまとめずに標準誤差を出すと 0.00050161 になり、z は −1.918 でした（まとめた場合は −1.9277）。まず「同じ検定と同じ式を使ったか」を確かめ、そのうえで計算のずれを疑う順番にすると、正しい答えを誤りと判定せずに済みます。
つまずきやすい点：差があることと原因であることは別
「有意な差」は「端末が原因」という意味ではない
今回の端末の違いは、くじ引きのように無作為に分けた A/B テスト（訪問者をランダムに 2 つに分けて比べる実験）ではありません。パソコンで買い物をする人とスマホで見るだけの人では、そもそも目的が違う可能性があります。だから、仮に有意な差が出ても、言えるのは「この期間、端末ごとに購入率が違った」までで、「スマホにしたから購入率が上がる」とは言えません。
今回の 9 回の答えは、どれもこの点に触れていませんでした。原因かどうかの線引きは、AI に任せず報告を書く人が加える必要があります。
同じ人が両方のグループに入っている
3 か月のデータでは、全 270,154 人のうち 4,182 人（約 1.5%）が 2 種類以上の端末で記録されていました（筆者が user_pseudo_id ごとに端末の種類を数えて確認）。z 検定は、2 つのグループが別々の人であることを前提にしています。今回は重なりが小さいため影響は限られると考えられますが、重なりが大きいデータでは、この前提の崩れを報告に添える必要があります。
「有意でない」は「差がない」ではない
3 か月の p 値 0.0539 は、「差があると言い切る根拠がまだ足りない」という意味で、「差がない」と証明したわけではありません。3 か月の答えでこの点を自分から書いたのは、式を指定した答えだけでした（途中を書かせた答えは、1 日の答えで同じ注意を書いていました）。報告では「5% の基準では有意とは言えないが、境界に近い」と、p 値と一緒に書くのが誤解の少ない書き方です。
実際にやってみて気づいた点
筆者は以前、このサイトの運用で、区分別の売上の表を AI に渡し、渡し方を 2 通りに変えて答えを SQL で検算する試みをしました。その時も、AI が書いた数値が一次情報とずれるとサイトの信頼を損なうため、本文の数値と出典の一致を確認項目にしました。
今回も同じ考えで、AI の答えの数値はすべて検算の表と並べています。区分別の売上の検算は 「先月なぜ売上が落ちたか」を AI に探させて寄与度分解で検算した記事 にまとめています。
購入率の集計そのものを AI に SQL で書かせる場合は、AI に書かせた GA4 の BigQuery SQL を、購入率などの 3 問で検算した記事 が参考になります。AI に報告文まで書かせる時の誤りの出方は、AI に GA4 月次レポートを書かせて検算したプロンプト集 で扱っています。
まとめ
- 今回の 9 回の試行では、AI の有意差判定は z・p 値・結論とも検算と一致しました。ただし各条件 1 回だけの結果で、毎回合う保証にはなりません。
- 頼み方で変わったのは注意書きと検算のしやすさです。式と有意水準を指定し、途中の値を書かせると、1 行ずつ確かめられます。
- p 値が 0.05 に近い時は、割合の丸めだけで結論が逆になります。AI には丸める前の人数を渡し、「差がある」と「原因である」は分けて書きます。
次にやること
検算した数値をどう見せるかの参考には、ダッシュボードの一覧で、このサイトが公開データから作ったダッシュボードの例をご覧ください。端末別の購入率や z を計算する SQL が定義どおりか、第三者の目で確かめたい場合は、BigQuery SQL レビューパックもご利用いただけます。
参考にした一次情報
- Google for Developers: Google アナリティクス 4 の BigQuery サンプル データセット（ウェブ e コマース）（2026-11-10 確認。期間・難読化・無料枠・サンプルクエリ）
- Google アナリティクス ヘルプ: BigQuery Export スキーマ（2026-11-10 確認。device.category、user_pseudo_id）
- Google アナリティクス ヘルプ: 推奨イベント（2026-11-10 確認。purchase イベント）
- NIST/SEMATECH e-Handbook of Statistical Methods: Comparing two proportions（2026-11-10 確認。2 標本の割合の差の z 検定、フィッシャーの正確確率検定）