ランディングページ最適化は「運用の契約」から始まる
ランディングページ最適化（LPO）とは、個別施策の寄せ集めではなく、広告や検索で示した約束がファーストビュー、証拠、CTA、フォーム、計測を経て有効問い合わせに変わるまでの連鎖を計測し、一度に一つの意思決定を改善していく運用です。ボタンの色やコピーの言い換えを試す前に、この連鎖のどこで約束が途切れているかを特定できる状態を作ることが先決です。
この記事で持ち帰れるもの
本記事は、LP改善の担当者が次の5点をそのまま自社に書き写して使えるように構成しています。
- 連鎖の各要素に所有者と確認データを割り当てる「LPO契約表」
- GA4のイベントと有効問い合わせを突き合わせる計測仕様の書式
- W3Cの公式基準で点検するフォームのチェック項目
- 証拠と戻しやすさで並べ替える優先バックログ
- 変更前の値と停止条件まで残す変更台帳
逆に、この記事では「この施策でCVRが平均何%上がる」といった数字は示しません。改善幅は流入の質と現状の壊れ方に依存するため、他社平均を根拠に自社の意思決定はできないからです。示せるのは、判断を可能にする計測と運用の型です。読み終えたら、改善を始める・延期する・別施策を選ぶ・外注しない、のどれを選んでも根拠を説明できる状態を目指します。
LPO契約表 — 連鎖の要素ごとに所有者と確認データを決める
LPO契約表とは、流入の約束から有効問い合わせまでの連鎖を要素に分解し、それぞれに所有者・確認するデータ・欠損時の対応を割り当てた一覧表です。改善の議論を始める前にこの表を埋めると、「誰も所有していない要素」と「データが存在しない要素」が空欄として可視化されます。
契約表の書式と記入例
| 連鎖の要素 | 所有者の例 | 確認するデータ | 欠損時の対応 |
|---|---|---|---|
| 目的（有効問い合わせの定義） | 事業責任者 | CRMの商談化記録 | 定義するまで改善判断を保留する |
| 対象流入 | 広告・SEO担当 | 参照元・メディア別セッション | 流入を分けられない間は全体CVRで判断しない |
| ファーストビューの約束 | コピー担当 | 広告文・検索クエリの原文 | 流入ごとに約束が違うならLPを分ける |
| 証拠（約束の裏付け） | 戦略担当・法務 | 掲載可能な事実の一覧 | 裏付けの無い約束は掲載を止める |
| CTA | デザイン担当 | CTAクリックのイベント | 計測が無い状態でCTA変更を評価しない |
| form_start（入力開始） | 計測担当 | 自社の計測仕様と発火ログ | 入力開始の条件を確認するまでフォーム改修を評価しない |
| 成功送信 | 実装担当 | サーバー側の受付記録 | 送信操作と受付成功を区別できるまで送信数を成果と呼ばない |
| 有効問い合わせ | 営業担当 | CRMと照合した判定結果 | 判定基準が無ければ営業と定義を合意する |
ここで最も重要なのは下の2行です。媒体の管理画面に表示されるコンバージョン、フォームの送信操作、サーバーが受け付けた成功送信、営業が確認した有効問い合わせ、その先の商談は、それぞれ別のデータです。この区別が無いままCVRだけを見ると、「送信は増えたが有効問い合わせは減った」変更を成功と記録してしまいます。逆に、対象外の問い合わせを減らす変更はCVR上は悪化に見えても事業には貢献します。契約表は、この誤認を仕組みで防ぐための最初の一枚です。
約束と証拠の照合 — 入場券とPODを混同しない
ファーストビューの点検で重要なのは、比較テーブルに乗るための「入場券」と、選ばれる理由である「POD（Point of Difference）」を分けて扱うことです。これは公式仕様ではなく、私たちが訴求の点検に使っている診断の型で、読者が自社の状況に当てはめて使うことを想定しています。
「運用が丁寧」「レポートが早い」のような、競合も同じことを言える要素は入場券であってPODではありません。入場券は競合と同等でよく、投資配分は「入場券は広く薄く同等に、PODは狭く厚く独自に」が原則です（株式会社くるみ「CEP×POD」自社ポジショニング方法論、2026年）。
照合の手順
- 対象流入ごとに、広告文や検索クエリが読者に何を約束しているかを原文のまま書き出します
- その約束に対応する証拠（掲載可能な事実）がLP上のどこにあるかを対応表にします
- 証拠の無い約束は、証拠を用意するか、約束自体を削ります
- 残った訴求を入場券とPODに仕分けし、PODにファーストビューの面積を割きます
LPをいじる前の一次診断
そもそも広告経由の成果が出ていない場合、「比較の段階で負けている」のか「そもそも比較されていない」のかを先に判別します（株式会社くるみ「広告不調の一次診断フレーム」初回ヒアリングの実務手順、2026年）。認知や母数が不足しているのにLPと入札を触り続けても、予算だけが減っていきます。この場合の合理的な判断は、LPOを延期して比較前の出会い方を再設計することです。改善しないという選択肢を持つことも、LPOという運用の一部です。
計測仕様 — GA4イベントと有効問い合わせをつなぐ
計測仕様とは、イベント名、発火条件、重複の扱い、成功条件、同意の扱い、CRMとの照合キーを一枚の文書に残したものです。管理画面の名称や設定手順は変わる前提で、「何を計測したいのか」と「どう確認するのか」を仕様として残しておくと、担当者や画面が変わっても運用が壊れません。
GA4側で確認すること
GA4のイベントには、設定不要で収集される自動収集イベント、サイト側で有効化する拡張計測イベント、Googleが名前と用途を定義した推奨イベント、自社で定義するカスタムイベントがあります。推奨イベントの一覧と定義は公式リファレンスで確認できます（GA4 推奨イベントのリファレンス、2026年7月確認）。
問い合わせ計測では、Googleが定義する推奨イベントと、自社が定義・検証する中間イベントを分けます。公式リファレンスはgenerate_leadを、フォームなどでリードが生成されたときに記録する推奨イベントとして定義しています。一方、入力開始を表すform_start、送信操作、サーバー受付などをどの条件で記録するかは、自社のフォーム実装と計測仕様で明示します（GA4 推奨イベントのリファレンス、2026年7月確認）。推奨名を使うだけでは、発火の正しさや営業上の有効性までは保証されません。
GA4の外で自社が決めること
- 成功条件: form_submitは送信操作の計測であり、サーバーが受け付けた成功送信とは別に定義します
- 重複の扱い: 同一ユーザーの再送信・二重送信をどのキーで除外するかを決めます
- 同意の扱い: 同意管理の状態によって計測に欠損が生じる前提で、欠損の規模を把握してから改善効果を読みます
- CRM照合キー: 送信IDやタイムスタンプなど、GA4のイベントとCRM上の有効問い合わせを突き合わせるキーを実装します
この4点はどの計測ツールを使っても自社で決めるしかない項目です。ここが曖昧なままだと、後段のテスト結果がすべて読めなくなります。
フォーム点検 — 項目数ではなくW3C基準で見る
フォーム改善のポイントは、項目数を一律に減らすことではなく、各項目の必要性と、W3Cが公開する公式基準を満たしているかを点検することです。項目を減らしても送信操作が増えるとは限らず、営業に必要な情報が欠ければ有効問い合わせ以降の判断にも影響します。まず各項目について「営業プロセスのどこで実際に使うか」を説明できるか確認し、説明できない項目を削除候補として、計測可能な形で検証します。
W3Cの公式基準で点検できる項目
W3CのWCAG 2.2には、フォームに直接適用できる達成基準があります。
- ラベルと入力説明: コンテンツが入力を要求する場合、ラベルまたは説明を提供することが達成基準3.3.2（レベルA）として定義されています。求める入力形式が特殊な場合は、その形式の説明まで含みます（WCAG 2.2 達成基準3.3.2の解説、2026年7月確認）
- エラーのテキスト識別: 入力エラーが自動検出された場合、エラー箇所を特定しテキストで説明することが達成基準3.3.1（レベルA）です。色や枠線の変化だけでエラーを示す実装はこの基準を満たしません（WCAG 2.2 達成基準3.3.1の解説、2026年7月確認）
運用側で点検する項目
次の2点はWCAGの引用ではなく、有効問い合わせにつなげるための運用上の点検項目です。
- 成功通知: 送信後に「受け付けた」ことが明確に伝わるか。通知が曖昧だと再送信による重複や、問い合わせ後の不信を招きます
- 個人情報の利用目的: 取得する情報を何に使うかをフォームの近くで示し、自社のプライバシーポリシーの記載と矛盾していないかを確認します
アクセシビリティ対応は特定ユーザー向けの追加作業ではなく、エラーで止まるすべてのユーザーの離脱要因を減らす基礎品質として扱うのが実務的です。
表示性能 — Core Web Vitalsは実ユーザーデータで読む
表示性能の点検で重要なのは、単一の性能スコアで良し悪しを断定せず、実ユーザーデータとラボ測定を分けて読むことです。GoogleのCore Web Vitalsは、読み込み（LCP）、応答性（INP）、視覚的安定性（CLS）の3指標で構成され、それぞれ2.5秒以内、200ミリ秒以下、0.1以下が「良好」の閾値として定義されています。評価はページ読み込みの75パーセンタイルで行い、モバイルとデスクトップを分けて見ます（web.dev「Core Web Vitals」、2026年7月確認）。
フィールドデータとラボデータの違い
同じ公式ドキュメントは、実ユーザーの環境で計測するフィールド測定と、開発環境で再現するラボ測定を明確に区別し、ラボ測定はフィールド測定の代替にはならないと述べています。ラボのスコアが良くても、実ユーザーの回線や端末では体験が悪いことは普通に起きます。数値を見るときは次の2点を必ず確認してください。
- どちらのデータか: 実ユーザー由来（フィールド）か、測定ツールの再現環境（ラボ）か
- どの範囲か: 対象LPのURL単体の数値か、サイト全体（オリジン）の集計か。範囲が違う数値同士を比べても判断できません
性能はガードレール指標として扱う
性能の悪化がコンバージョン低下の唯一の原因だとは断定できません。実務では、性能を「改善の主指標」ではなく「変更時に監視するガードレール指標」として変更台帳に載せます。証拠や画像を追加するときは、対象URLの実ユーザーデータ、ラボでの再現、変更前値を確認し、事前に決めた停止条件に達したら切り戻します。公式閾値だけでCVRへの因果を判定しません。
優先バックログと変更台帳 — 一度に一つの意思決定を検証する
改善テーマの優先順位は、思いついた順や声の大きさではなく、仮説の証拠、期待影響、実装工数、回帰リスク、戻しやすさ、判断可能性の6つの軸で決めることが重要です。
優先バックログの6軸
| 軸 | 問い | 低評価になる例 |
|---|---|---|
| 仮説の証拠 | どのデータがこの仮説を支持するか | 「なんとなく古い気がする」 |
| 期待影響 | 連鎖のどの要素が動くと見込むか | 影響する要素を特定できない |
| 実装工数 | 誰が何を変更するか | 外部ベンダー待ちで見積不能 |
| 回帰リスク | 壊れうる既存機能は何か | フォーム実装に触るのに検証環境が無い |
| 戻しやすさ | どれだけ速く元に戻せるか | 戻す手順が文書化されていない |
| 判断可能性 | 結果を何のデータで判定できるか | 計測仕様が無く判定不能 |
判断可能性が最も低い仮説は、どれほど有望に見えても着手しません。検証できない変更は、成功しても失敗しても学習が残らないからです。
変更台帳に残す10項目
変更のたびに、変更前値、仮説、対象、無作為化単位、主要指標、ガードレール、開始条件、停止条件、結果、未確認事項の10項目を記録します。特に「変更前値」と「停止条件」は後から書けない項目なので、開始前に埋めてください。
ABテストの停止条件は開始前に決める
「一要素だけ変えれば因果が確定する」という理解は不正確です。因果の確からしさは変更点の数ではなく、無作為化の設計と分散の評価に依存します。Microsoft Researchの研究は、オンラインのABテストでは無作為化の仕組みが複雑になりやすく、単位を独立同分布と仮定すると分散を過小評価し、実際には有意でない差を有意と誤判定しうることを示しています（Trustworthy Analysis of Online A/B Tests: Pitfalls, challenges and solutions、2026年7月確認）。p値が一度小さくなった時点で勝者を宣言する運用は、この誤判定を制度化するようなものです。無作為化の単位の考え方はABテストのランダム割り当ての仕組み、必要な検出力の見積もりはABテストのサンプルサイズ計算で詳しく扱っています。
責任分界 — 公開・停止・ロールバックを誰が決めるか
責任分界で重要なのは、作業の分担表を作ることではなく、公開する・停止する・元に戻すという3つの決定を誰が下すかを先に合意しておくことです。
領域別の責任と決定権の例
| 領域 | 担う判断 | 備考 |
|---|---|---|
| 戦略 | 有効問い合わせの定義、PODの選定 | 契約表の「目的」行を所有する |
| 計測 | 計測仕様の維持、判定可能性の担保 | 仕様に無い変更を差し戻せる権限が要る |
| コピー | 約束と証拠の整合 | 法務確認前の公開を止められること |
| デザイン | CTA・情報設計の変更 | ガードレール指標の悪化に責任を持つ |
| 実装 | フォーム・計測タグの変更と切り戻し | 戻し手順の文書化まで含む |
| 法務 | 表示・個人情報の適法性 | 法務上の停止条件と決定権を自社ルールで定める |
| 営業 | 有効問い合わせの判定、CRM照合 | 判定基準の変更は台帳に記録する |
決定権で揉めやすいのは停止とロールバックです。公開と停止を同じ決定者だけに委ねる場合は、自己判断の見直しが遅れるリスクを点検します。停止条件を変更台帳に事前に書き、条件に該当したら担当者が停止を提起でき、定めた決定者が期限内に判断する形式にすると、判断根拠を後から確認できます。
「変えない」「延期する」「外注しない」も決定です
責任分界には、実行しない決定も含まれます。計測仕様が無いなら改修を延期して仕様づくりを先に行う。比較されていない段階ならLPOではなく認知の施策に予算を移す。契約表・計測仕様・変更台帳を自社で維持できるなら外注せず内製する。逆に外注する場合も、この3点を社内に残す前提で契約しないと、判断材料が社外にだけ蓄積することになります。
よくある質問（FAQ）
LPOの運用設計について、よく受ける質問をまとめます。
LPOだけで問い合わせの母数は増やせますか？
増やせない場合があります。LPOの優先度が上がるのは、比較の土俵に乗っているのに選ばれていない証拠があるときです。比較候補に入っていない可能性が高い場合、LPだけを変えても問い合わせ母数が増えるとは限りません。最初に「比較で負けているのか、比較されていないのか」を仮説として切り分け、後者を示す証拠があれば、比較前の出会い方も改善候補に含めてください。
個別の症状から施策を選ぶ診断記事とは、どう使い分けますか？
本記事は目的・計測・責任・運用をまとめた全体の契約であり、症状別に一つのテストを選ぶ実践はランディングページ改善の優先施策まとめが扱う領域です。順序としては、契約表と計測仕様を先に整え、そのうえで症状別の診断から個別テストを選ぶと、結果を判定できる状態でテストに入れます。
フォームの項目は少ないほど良いのでしょうか？
一律には言えません。項目を減らした結果は、送信操作と有効問い合わせを分けて確認する必要があります。営業に必要な情報が欠けると、後段の判定や対応にも影響し得ます。判断基準は項目数だけではなく、各項目の必要性を営業プロセスで説明できるか、そしてラベル・入力説明・エラー表示がW3Cの達成基準を満たしているかです。
性能スコアが低いと、コンバージョンは必ず下がりますか？
断定できません。Core Web Vitalsの閾値は体験品質の公式基準であって、コンバージョンとの関係はサイトごとに異なります。実ユーザーデータとラボ測定を区別したうえで、性能は「変更で悪化させないガードレール指標」として変更台帳に載せるのが実務的な扱いです。
流入が少なくABテストが成立しない場合、外注すべきですか？
外注の前に、検証方法を変える選択があります。流入が少ないLPでは、無作為化を伴うテストではなく、変更台帳を使った逐次変更と、成功送信・有効問い合わせのCRM照合で判断する方が現実的です。外注する場合は、契約表・計測仕様・変更台帳を社内に残す条件で契約できるかを判断基準にしてください。それができない外注は、結果の判断材料が社内に蓄積しません。
まとめ — 変えない判断まで含めてLPOです
ランディングページ最適化は、流入の約束、証拠、CTA、フォーム、計測、有効問い合わせを一つの連鎖として点検し、一度に一つの意思決定を検証する運用です。本記事の型を使うと、次の4通りの結論がどれも「実行可能な判断」になります。
4つの出口
- 始める: LPO契約表の空欄を埋め、判断可能性の高い仮説から変更台帳を書き始める
- 延期する: 計測仕様が無い、または有効問い合わせの定義が無いなら、改修より先に定義と計測を整える
- 別施策を選ぶ: 比較されていない段階なら、LPではなく比較前の認知・想起の設計に予算を移す
- 外注しない・する: 契約表・計測仕様・変更台帳を社内に残せる形なら外注も機能し、残せないなら契約条件を見直すか、内製で最小の運用から始める
CVRという指標そのものの扱い方はCVR改善の基本的な考え方も参考にしてください。
私たちくるみは、AIを物量と速度のエンジンに、人の目利きを質の担保にするAIグロースファームとして、計測設計から証拠づくり、ABテストの運用までを一体で支援しています。「契約表を埋めてみたら、所有者のいない行が多すぎた」という状態こそ相談のしどきです。とはいえ、本記事の表と台帳は外部に頼らず自社だけでも運用を始められるように作ってあります。まず一枚、埋めてみてください。