A/Bテストは「機会損失」である。勝ちパターンを決めつけず、常に変化し続ける「動的LP」の作り方（AWS CloudFront編） -CloudFront Functionsで実現する、サーバーレス・パーソナライズ。流入元判定による「出し分け」実装ガイド

なぜなら、「パターンAの方が好きだった40%のユーザー」を、今後ずっと切り捨てることになるからです。

Webサイトは印刷されたポスターではありません。

全員に同じ「勝ちパターン」を見せる必要はないのです。

• Instagramから来た人には、インスタっぽい「エモい画像」を。
• Google検索から来た人には、カタログっぽい「スペック表」を。

相手に合わせて、カメレオンのように姿を変えるページ。それが「動的LP（Dynamic Landing Page）」です。

「でも、そんなシステムを作るには高額なツールが必要でしょう？」

いいえ、AWSを使っているなら、追加契約なしで今すぐ実装できます。

本記事では、AWSのCDNサービスであるCloudFrontの拡張機能、「CloudFront Functions」を使って、サーバーレスかつ爆速で「動的LP」を構築する具体的な手順を解説します。

---

第1章：CloudFrontは「配送屋」から「コンシェルジュ」へ

これまでのCloudFrontの役割は、S3にある画像やHTMLをユーザーに高速で届ける「配送屋（CDN）」でした。

しかし、今のCloudFrontは違います。「CloudFront Functions」という小さな脳みそを手に入れ、「コンシェルジュ」へと進化しました。

何ができるのか？

ユーザーのリクエストがサーバーに届く「手前」で、プログラムを実行できます。

1. ユーザーがアクセスしてくる。
2. CloudFront Functionsが瞬時に「お客様、どちらから来ましたか？」と確認する。
3. 「Instagramですね。では、こちらの特別なページをご案内します」と、表示するHTMLを差し替える。

この処理にかかる時間は1ミリ秒以下。ユーザーは処理されていることに気づかず、体感速度は爆速のままです。

---

第2章：実装レベル「流入元（Referer）での出し分け」

では、実際に作ってみましょう。

今回は最も効果が出やすく、実装も簡単な「流入元（リファラ）による出し分け」を行います。

【構成】

• LP_Default.html: 通常のLP
• LP_Instagram.html: インスタ映えを意識したLP
• LP_Google.html: 検索ユーザー向けのLP

これら3つのファイルをS3に置いておき、CloudFront Functionsで振り分けます。

具体的なコード（JavaScript）

CloudFrontの管理画面から「関数（Functions）」を作成し、以下のコードを貼り付けます。

例）JavaScript

function handler(event) {
    var request = event.request;
    var headers = request.headers;
    var uri = request.uri;

    // 1. トップページへのアクセスか確認
    // (CSSや画像へのアクセスで発火させないため)
    if (uri === '/' || uri === '/index.html') {
        
        // 2. 流入元（Referer）があるかチェック
        if (headers.referer && headers.referer.value) {
            var referer = headers.referer.value;

            // 3. Instagram経由なら、エモいLPへ内部書き換え
            if (referer.includes('instagram.com')) {
                request.uri = '/LP_Instagram.html';
            } 
            // 4. Google検索経由なら、機能訴求LPへ内部書き換え
            else if (referer.includes('google.com')) {
                request.uri = '/LP_Google.html';
            }
        }
        // それ以外は、そのままデフォルトのindex.htmlが表示される
    }

    // 変更されたリクエストをS3へ送る
    return request;
}

ポイント：リダイレクトではなく「Rewrite」

ここで重要なのは、301/302リダイレクトを行っていない点です。

ブラウザのURL欄は https://example.com/ のまま変わりません。しかし、表示される中身だけが LP_Instagram.html にすり替わっています。

これにより、ユーザーに「別ページに飛ばされた」という違和感を与えず、かつ
SEO的にも1つのURL（ドメイン評価）に集約できるメリットがあります。

---

第3章：なぜ「Lambda@Edge」ではなく「CloudFront Functions」なのか？

AWSには、似た機能として「Lambda@Edge」があります。

しかし、今回の用途（URLの書き換えやヘッダー操作）であれば、間違いなく「CloudFront Functions」を選ぶべきです。

特徴	CloudFront Functions (CFF)	Lambda@Edge
起動速度	爆速 (1ミリ秒以下)	普通 (コールドスタートあり)
コスト	激安 ($0.1 / 100万件)	高め ($0.6 + 時間課金)
用途	URL書き換え、ヘッダー操作	外部API連携、重い画像処理

CloudFront Functionsのコストは、100万アクセスあっても約15円です。

ほぼ誤差レベルのコストで、動的なパーソナライズ環境が手に入ります。これが「中小企業こそCFFを使うべき」と主張する理由です。

---

第4章：動的LPのビジネスメリット

技術的なメリットだけでなく、経営的なメリットも明確です。

1. 「飽き」との戦いに勝つ

静的なLPは、一度作ると陳腐化していきます。

しかし動的LPなら、
例えば「雨の日だけクーポンバナーを出す」といったロジックを入れることで、常に「ライブ感（鮮度）」のある売り場を維持できます。

2. 広告品質スコア（Quality Score）の向上

GoogleやMetaの広告において、「広告文と飛び先ページの一致率」はクリック単価（CPC）に直結します。

「機能訴求の広告」をクリックしたのに「情緒的なLP」が出ると、スコアは下がります。

動的LPでここを一致させることで、広告費の削減にも寄与します。

---

まとめ：Webサイトは「印刷物」ではない

私たちはつい、Webサイトを「一度公開したら終わりのポスター」のように扱ってしまいます。

しかし、Webは本来、アクセスするたびに形を変えられる「ソフトウェア（生き物）」です。

• A/Bテストで「1つの正解」を探すのをやめる。
• CloudFront Functionsを使って、相手に合わせた「無数の正解」を用意する。

AWSを使っているなら、追加のSaaSを契約する必要はありません。

まずは上記のコードをコピペして、「インスタから来た人だけ特別扱いする」ことから始めてみませんか？

それだけで、あなたのサイトの「接客力」は劇的に向上するはずです。

---

👇 【UX】表示速度も「おもてなし」

:::info【Amazon】LPが表示されるまでの「0.1秒」をデザインする

せっかく動的LPを表示しても、読み込みが遅ければ離脱されます。

脳を錯覚させて待ち時間を消す、Amazon流のUX実装パターン。

👉 記事を読む：Amazonに学ぶ「知覚パフォーマンス」と3つの実装パターン

:::

👇 【概念】なぜパーソナライズが必要なのか？

:::info【Netflix】私とあなたで「表紙」が違う理由

Netflixが実践する、A/Bテストを超えた「バンディットアルゴリズム」によるクリエイティブ自動生成の戦略論。

👉 記事を読む：Netflixが採用する「バンディットアルゴリズム」とクリエイティブの自動生成

:::

👉記事を書いた人