会社情報
採用情報
お問い合わせ
Article

LP最適化事例：A/Bテストで成果が出た要素とは

高田晃太郎
LP最適化事例：A/Bテストで成果が出た要素とは

Microsoftの実験研究（Kohaviら）では、提案された変更のうち主要指標を有意に改善したのはおよそ3割に留まると報告されています[1]。LP（ランディングページ）最適化でも同じ構図で、闇雲に要素を差し替えるだけでは再現性のある成果には届きません。一般に、B2B/B2Cを問わず複数の事例を時系列で追うと、テストの設計品質と計測の健全性、そしてユーザー体験の本丸である性能（表示速度など）と摩擦低減（入力負荷や不安の低減）が勝率を押し上げる共通因子として挙げられます。

技術的には難しく見えないLPのA/Bテストほど、露出制御の不備やSRM（サンプル比不一致＝割当比率と観測数のズレ）、Cookie寿命（ブラウザのトラッキング防止でCookieが短命化する現象）、ボット流入、固定ホライズン違反（途中で覗き見して意思決定すること）のような小さな綻びが結果を歪めます[1,3,4]。逆に言えば、**テストの事前登録（検証計画を事前に固定）とパワー設計、データ品質の監視、そして因果推論の初歩（CUPED＝事前データで分散を減らす手法）**を淡々と実装すれば、勝ち筋は見えてきます[2]。本稿では、成果が出た要素の実例とともに、再現可能性を担保する実装の中身まで掘り下げます。

A/Bテスト設計の原則と落とし穴

テストの勝率を上げる近道は魔法のUIではなく、検証計画の健全性です。効果量の見積もりから露出の割当、ガードレール指標（安全性を守る副次指標）の設定、SRM検知、ボット除外、固定ホライズン（期間・サンプルを事前固定）または逐次検定（見るたびに意思決定可能だが境界条件が必要）の選択までを事前登録し、逸脱しない運用を徹底します[1,3]。特にLPではセッションベースのコンバージョンが多く、ITP（Intelligent Tracking Prevention）によるCookie寿命短縮や広告経由の短期的なトラフィックミックス変化が結果を揺らしやすい点に注意が必要です[4]。

サンプルサイズとMDEの決め方

パワー80%、有意水準5%を基本とし、ベースCVRと検出したい最小検出効果（MDE）から必要サンプルを求めます[1]。固定ホライズンで走り切る前提なら、途中の覗き見を避け、所定のサンプル到達まで結果を開かない運用が安全です[1]。以下はPythonとstatsmodelsで二項比率差のサンプルサイズを概算する例です。

import math
from statsmodels.stats.power import NormalIndPower

# ベースCVRとMDE（相対）
base_cvr = 0.03  # 3%
rel_mde = 0.15   # +15%
alpha = 0.05
power = 0.8

alt_cvr = base_cvr * (1 + rel_mde)
effect = alt_cvr - base_cvr

# 正規近似での効果量（Cohen's h）
from statsmodels.stats.proportion import proportion_effectsize
h = proportion_effectsize(base_cvr, alt_cvr)

analysis = NormalIndPower()
n_per_group = analysis.solve_power(effect_size=h, alpha=alpha, power=power, ratio=1.0, alternative='two-sided')

print(f"必要サンプル/群: {math.ceil(n_per_group):,}")

実務では流入源ごとにCVRが大きく異なるため、ターゲットのトラフィックミックスで再計算することが欠かせません。さらに分散削減のCUPEDを併用すれば必要サンプルを縮められますが、事前に共変量の相関を確認してゲインが出るか判断します[2]。

データ品質とSRM検知

SRMは理論割当と観測比の乖離を指し、ボットや実装ミス、フィルターの偏りで発生します。単純なカイ二乗検定で常時監視し、発見したらテストを無効化して原因を潰します[1]。イベントストリームからの簡易チェックはSQLで十分です。

-- 割当比50:50のSRM検知（カイ二乗）
WITH assign AS (
  SELECT variant, COUNT(*) AS n
  FROM events
  WHERE experiment_id = 'lp_hero_ab' AND event_name = 'exp_view'
    AND event_date BETWEEN '2025-08-01' AND '2025-08-07'
  GROUP BY variant
),
agg AS (
  SELECT SUM(n) AS total,
         MAX(CASE WHEN variant = 'A' THEN n END) AS a,
         MAX(CASE WHEN variant = 'B' THEN n END) AS b
  FROM assign
)
SELECT a, b,
       -- 期待度数
       ( (a - total/2.0)*(a - total/2.0) )/(total/2.0) +
       ( (b - total/2.0)*(b - total/2.0) )/(total/2.0) AS chi2,
       -- 自由度1の右片側p値（近似）。エンジンにより関数を置換
       EXP(-0.5 * ( ( (a - total/2.0)*(a - total/2.0) )/(total/2.0) + ( (b - total/2.0)*(b - total/2.0) )/(total/2.0) )) AS p_approx
FROM agg;

露出制御は固定のユーザーIDと安定ハッシュで行い、初回割当をローカルに保存します。セッションIDや可変のリファラーで割当を行うとSRMやスイッチングが発生します[1]。最低限のアサイナーは以下のように実装できます。

/* In-house assignment with sticky bucketing */
(function(){
  const EXP_ID = 'lp_hero_ab_v1';
  const KEY = 'exp:' + EXP_ID;
  try {
    let v = localStorage.getItem(KEY);
    if (!v) {
      const uid = (localStorage.getItem('uid') || (crypto.randomUUID ? crypto.randomUUID() : String(Math.random())));
      localStorage.setItem('uid', uid);
      const enc = new TextEncoder().encode(EXP_ID + ':' + uid);
      const digestPromise = crypto.subtle ? crypto.subtle.digest('SHA-256', enc) : Promise.resolve(null);
      (digestPromise.then ? digestPromise : Promise.resolve(digestPromise)).then(d => {
        let hash = 0;
        if (d) {
          const arr = Array.from(new Uint8Array(d));
          hash = arr.reduce((a, c) => ((a << 5) - a + c) | 0, 0);
        } else {
          for (let i = 0; i < enc.length; i++) hash = ((hash << 5) - hash + enc[i]) | 0;
        }
        v = (Math.abs(hash) % 2) === 0 ? 'A' : 'B';
        localStorage.setItem(KEY, v);
        logExposure(v);
      });
    } else {
      logExposure(v);
    }
    function logExposure(variant){
      navigator.sendBeacon && navigator.sendBeacon('/exp/log', new Blob([JSON.stringify({exp: EXP_ID, v: variant, t: Date.now()})], {type: 'application/json'}));
      document.documentElement.setAttribute('data-exp-'+EXP_ID, variant);
    }
  } catch(e) { /* fail closed */ }
})();

この段階までをテンプレート化しておくと、LP改善のサイクルは格段に安定します。

勝った具体要素1——ファーストビュー性能の徹底

最も再現性高く勝ちやすいのは、ヒーローセクションの表示性能です。公開事例でも、Largest Contentful Paint（LCP）を短縮することでCVRが二桁パーセント伸びた例が報告されており[5,6]、LPでは見かけの違いが最小限でも、体感速度の改善がファーストインプレッションの離脱抑制に直結します。一般的には、モバイルのLCPを数百ミリ秒〜1秒程度短縮できると、CVRで約10〜30%の改善が観測される可能性があります（サイトや業界により幅あり）[5,6]。

HTML側ではヒーロー画像にfetchpriority、明示的サイズ、適切なフォーマットを指定し、フォントはFOIT（文字が一時的に消える現象）を避ける構成にします。以下はLPの折返し上の要素を優先するスニペットです。

<link rel="preload" as="image" href="/img/hero.avif" imagesrcset="/img/hero.avif 1x, /img/hero@2x.avif 2x" imagesizes="100vw">
<img src="/img/hero.avif" alt="製品の価値を端的に示すビジュアル" width="1280" height="720"
     fetchpriority="high" decoding="async" loading="eager">
<link rel="preload" as="style" href="/css/critical.css">
<link rel="preload" as="font" href="/fonts/Inter.var.woff2" type="font/woff2" crossorigin>
<style>html{font-display:swap}</style>

サーバではBrotli圧縮とキャッシュ制御、画像CDNでの自動最適化を基本にします[8]。Node/Expressでの最低限の設定例は次の通りです。

import express from 'express';
import compression from 'compression';
import path from 'path';
import { fileURLToPath } from 'url';

const app = express();
app.disable('x-powered-by');
app.use(compression({ level: 6 }));
app.use((req, res, next) => {
  res.setHeader('Cache-Control', 'public, max-age=31536000, immutable');
  next();
});

const __dirname = path.dirname(fileURLToPath(import.meta.url));
app.use(express.static(path.join(__dirname, 'public')));

app.listen(3000, () => console.log('LP server on :3000'));

改善の妥当性は行動指標だけでなくWeb Vitalsで併記すると説得力が増します。現在はINP（Interaction to Next Paint）も主要指標ですが、ここではLCP/CLSに加えてFID/INPを送信する軽量な計測コードを示します[7]。

import { onCLS, onLCP, onFID, onINP } from 'web-vitals/attribution';

function send(metric){
  const body = JSON.stringify({ n: metric.name, v: metric.value, id: metric.id, t: Date.now() });
  navigator.sendBeacon('/vitals', new Blob([body], {type: 'application/json'}));
}

onLCP(send);
onCLS(send);
onFID(send);
onINP(send);

パフォーマンス改善のA/Bは効果が広帯域に及ぶため、ガードレールとして直帰率やスクロール深度の悪化がないかもモニタリングします。Web VitalsとCVRの同時改善が観測できれば、パフォーマンス起点のLP最適化は高い再現性で勝てるとチームに共有しやすくなります[5,6,7]。

勝った具体要素2——フォーム摩擦の削減と信頼の可視化

問い合わせや資料請求を目的としたLPでは、フォームの項目数を削減し、先に信頼を可視化することでCVRが持続的に伸びやすくなります。公開事例や業界の報告では、9項目から5項目への集約のように初期入力を絞り、役職や電話番号などは後続のナーチャリングで取得する設計にすることで、フォーム完了率がおおむね10〜25%程度改善した例が見られます[9]。フォーム直上に顧客ロゴや第三者評価のバッジ、個人情報の取り扱いに関する簡潔な説明を置く施策も、安心感の醸成に有効です。

どの項目が摩擦になっているかは、フィールド単位のファネルで把握します。イベントが粒度高く計測されていれば、次のような集計で各項目の離脱寄与を推定できます。

-- フィールド別の離脱ポイント可視化
WITH steps AS (
  SELECT session_id, field_name, MIN(event_time) AS first_ts
  FROM form_events
  WHERE form_id = 'contact_v3' AND event IN ('focus', 'change', 'blur')
  GROUP BY session_id, field_name
),
ordered AS (
  SELECT session_id, field_name,
         ROW_NUMBER() OVER (PARTITION BY session_id ORDER BY first_ts) AS step
  FROM steps
),
completion AS (
  SELECT session_id, MAX(CASE WHEN event = 'submit' THEN 1 ELSE 0 END) AS submitted
  FROM form_events
  WHERE form_id = 'contact_v3'
  GROUP BY session_id
)
SELECT o.field_name,
       COUNT(*) AS viewers,
       SUM(CASE WHEN c.submitted = 1 THEN 1 ELSE 0 END) AS converters,
       1.0 * SUM(CASE WHEN c.submitted = 1 THEN 1 ELSE 0 END) / COUNT(*) AS step_cvr
FROM ordered o
JOIN completion c USING (session_id)
GROUP BY o.field_name
ORDER BY step_cvr ASC;

項目削減がリード品質を悪化させないかは、商談化や受注といったダウンストリーム指標で非劣性検定を行います。CUPEDを使うとばらつきが小さくなり、短い期間でも判断しやすくなります[2]。Pythonでの簡易CUPED実装は以下の通りです。

import numpy as np
from scipy import stats

# x: 事前期間の行動（例: 過去のLP接触回数）、y: 実験期間の成果（0/1）
def cuped_effect(y_treat, y_ctrl, x_treat, x_ctrl):
    x = np.concatenate([x_treat, x_ctrl])
    y = np.concatenate([y_treat, y_ctrl])
    theta = np.cov(x, y, bias=True)[0,1] / np.var(x)
    y_adj_t = y_treat - theta * x_treat
    y_adj_c = y_ctrl - theta * x_ctrl
    diff = y_adj_t.mean() - y_adj_c.mean()
    se = np.sqrt(np.var(y_adj_t, ddof=1)/len(y_adj_t) + np.var(y_adj_c, ddof=1)/len(y_adj_c))
    z = diff / se
    p = 2 * (1 - stats.norm.cdf(abs(z)))
    return diff, z, p

# 使用例
# diff, z, p = cuped_effect(y_t, y_c, x_t, x_c)

コピーについては、曖昧なキャッチーさよりも「次に起こること」を具体的に示した文面が強く、無料トライアルであれば期間と提供範囲、問い合わせであれば返答の目安時間を明示した方が勝ちやすい傾向が一般に見られます。定性的に思える要素でも、レスポンスSLAや顧客ロゴの点数化（例：ロゴの知名度スコア）を共変量としてCUPEDに取り込むと判断の精度が上がります[2]。

運用を支える計測とガードレールの作り方

LPのA/Bは施策サイクルが短い反面、計測の綻びが成果の再現性を損ねます。初回露出イベント、ファネル各段のイベント、CVイベント、トラフィック属性、ボット指標を同一ストリームに詰め、日次の健全性レポートでSRMと外れ値を監視する体制を整えます[1,3]。特に広告流入では短期間のキャンペーンがミックスを歪めるため、同期間に「広告停止のオーガニックのみ」を並走で回すスモールテストを用意すると、因果の方向が確認しやすくなります。

クライアントサイドの実装では、実験割当、Vitals、ファネルの各イベントを一貫したセッション/ユーザーIDで結線し、遅延送信にはsendBeaconを用います[10]。露出直後のログ欠損に備えて、ページ遷移時やvisibilitychangeでもフラッシュするのが安全です。バックエンドではイベント到着の遅延を考慮してウォーターマーク（遅延データを切る境界時刻）を設定し、集計は到着順ではなくイベントタイムで扱います。

逐次検定を採用する場合は、常時監視の利点と引き換えに、境界の正当化（例：SPRTやalpha spending）を実装側で担保する必要があります。プラットフォームが未対応なら、固定ホライズンでの運用を推奨します[1]。BigQueryなど列指向DWHを使う場合、事前共変量を保持しておけばCUPEDのSQL実装も可能です[2]。

-- BigQueryでのCUPED（簡易）
WITH base AS (
  SELECT user_id, variant,
         SAFE_CAST(ANY_VALUE(pre_views) AS FLOAT64) AS x,
         AVG(CAST(converted AS INT64)) AS y
  FROM lp_sessions
  WHERE experiment_id = 'lp_form_v5'
  GROUP BY user_id, variant
), theta AS (
  SELECT COVAR_POP(x, y) / VAR_POP(x) AS theta FROM base
)
SELECT b.variant,
       AVG(y - t.theta * x) AS y_adj
FROM base b CROSS JOIN theta t
GROUP BY b.variant;

また、実験のガードレール指標としては、ページ滞在時間やスクロール深度だけでなく、**コスト側の指標（レンダリング時間、エラー率、バックエンドのP95応答時間）**を同時に監視することで、局所最適によるシステム負債の蓄積を防げます。運用の型化は組織の記憶であり、テンプレートとダッシュボードに落としてこそ回ります。

まとめ——勝率3割時代のLP最適化をどう設計するか

実験の勝率が3割前後という現実は、偶然を信じる理由ではなく、プロセスを磨く理由になります[1]。ファーストビューの性能を底上げし、フォームの摩擦を取り去り、信頼を可視化する。この三点はドメインを跨いで再現性が高く、公開事例ではCVRで約10〜30%の改善が報告されています[5,6,9]。設計面では、事前登録とサンプルサイズ、SRM監視、ガードレールの併走、そしてCUPEDによる分散削減を実装として仕組みに落とし込みます。そうすれば、たとえ一つのテストが外れても、次の打ち手が折れずに前へ進みます。

あなたのチームは、次のLPテストで何を確かめますか。もし迷うなら、まずは現在のLCPとフォーム項目数、そして信頼の可視化の有無を点検してみてください。すぐに直せる一手から始めて、テスト設計のテンプレート化とダッシュボード整備までを一気通貫に整える。このサイクルが回り始めたとき、A/Bテストは発明ではなく、積み重ねの武器に変わります。関連テーマはさらに深掘りできます。

参考文献

  1. Kohavi R, Tang D, Xu Y, Chen T. Trustworthy Online Controlled Experiments: A Practical Guide to A/B Testing. O’Reilly Media; 2020. https://www.oreilly.com/library/view/trustworthy-online-controlled/9781492044398/
  2. Deng A, Xu Y, Kohavi R, Walker T. Improving the Sensitivity of Online Controlled Experiments by Utilizing Pre-Experiment Data (CUPED). Microsoft Research; 2013. https://www.researchgate.net/publication/237838291_Improving_the_Sensitivity_of_Online_Controlled_Experiments_by_Utilizing_Pre-Experiment_Data
  3. Kohavi R, Longbotham R, Walker T, Xu Y. Pitfalls of long-term online controlled experiments. 2012. https://www.researchgate.net/publication/313449492_Pitfalls_of_long-term_online_controlled_experiments
  4. WebKit. Intelligent Tracking Prevention (ITP) updates and cookie restrictions. 2019. https://webkit.org/blog/9582/intelligent-tracking-prevention-2-3/
  5. web.dev. 楽天24のCore Web Vitals改善事例（訪問者あたり収益+53.37%、CVR+33.13%など）. https://web.dev/case-studies/rakuten?hl=ja#:~:text=%E3%81%BE%E3%81%9F%E3%80%81Rakuten%2024%20%E3%81%AF%E5%AE%9F%E9%9A%9B%E3%81%AE%E3%83%A6%E3%83%BC%E3%82%B6%E3%83%BC%E3%81%AE%20Core%20Web,%E4%B8%8A%E6%98%87%E3%81%99%E3%82%8B%E5%8F%AF%E8%83%BD%E6%80%A7%E3%81%8C%E3%81%82%E3%82%8B%E3%81%93%E3%81%A8%E3%82%82%E7%A2%BA%E8%AA%8D%E3%81%97%E3%81%BE%E3%81%97%E3%81%9F%E3%80%82
  6. web.dev. Renaultのパフォーマンス改善とコンバージョン増加の事例. https://web.dev/case-studies/renault#:~:text=match%20at%20L64%201%20second,increase%20in%20conversions
  7. web.dev. Web Vitals ガイド（LCP/CLS/FID と測定方法）. https://web.dev/vitals/
  8. RFC 7932. Brotli Compressed Data Format. IETF; 2016. https://www.rfc-editor.org/rfc/rfc7932
  9. MarketingSherpa. How one additional form field affected conversions (case study). https://www.marketingsherpa.com/article/case-study/how-one-additional-form-field#:~:text=additional%20form%20field%2C%20it%20was,mean%20it%20wasn%27t%20a%20successful
  10. MDN Web Docs. Navigator.sendBeacon(). https://developer.mozilla.org/en-US/docs/Web/API/Navigator/sendBeacon