ランディングページ改善は「最初に崩れた一箇所」を直すことから
ランディングページの改善で最初にやるべきことは、新しい施策を足すことではありません。流入 → メッセージ(訴求) → 表示体験 → CTA → フォーム → 有効問い合わせというイベントの連鎖を上流から順にたどり、最初に崩れている一箇所を特定して、そこだけを直すことです。
ボタンの色、入力項目の削減、ヒートマップの導入。こうした施策はどれも「崩れている場所と噛み合えば効くことがある」ものであって、どこにでも効く万能薬ではありません。たとえば流入クエリとページの約束がズレているLPでは、フォームをどれだけ磨いても、そもそもフォームに到達する人が増えません。
なぜ施策リストから始めると失敗するのか
施策リストから始める改善は、原因の仮説を持たないまま変更を積み重ねることになります。変更が増えるほど、どの変更が何に効いたのかを切り分けられなくなり、うまくいっても再現できず、悪化しても戻せません。
本記事では、施策の羅列ではなく、GA4で確認できるイベント連鎖から原因を絞り込む診断手順と、仮説の優先順位づけ、変更台帳による検証方法までを一続きで解説します。読み終えたときに「次に検証すべき一つの仮説」を自分の言葉で書ける状態がゴールです。
イベント連鎖の診断表 — どこで崩れているかをデータで特定する
LP改善の診断とは、流入から有効問い合わせまでのイベント連鎖を上流から順に点検し、症状・確認データ・次の一手を対応づける作業です。以下の表を上から順に確認し、最初に崩れている行で止まってください。
| 確認ポイント | 崩れているときの症状 | 確認するデータ | 崩れていたときの次の一手 |
|---|---|---|---|
| 流入意図 | 直帰が多く滞在が極端に短い | 流入クエリ・広告の訴求内容と検索語句レポート | 訴求とLPの約束を照合し、意図がズレたクエリや配信面を除外する |
| ファーストビューの約束 | スクロールされずに離脱する | スクロール到達率、ページ別エンゲージメント | 誰の・どの課題を・どう解くかを一文で言い直す |
| 証拠 | 読了はされるがCTAに進まない | CTA手前までの到達とCTAクリックの落差 | 約束を裏づける根拠(データ・第三者評価・提供物の具体)を約束の直後に置く |
| CTA | 表示されているがクリックされない | CTAクリックイベント | 押した先に何が起きるかをボタン文言と周辺テキストで明示する |
| form_start | フォーム到達はあるが入力が始まらない | form_start イベント | フォーム冒頭の負荷(項目の見え方・所要の見通し)を点検する |
| 成功した送信 | 入力は始まるが完了しない | form_submit と送信完了ページ表示の差分 | エラー表示・入力形式・確認画面の挙動を実機で再現する |
| 有効問い合わせ | 送信は増えたが商談につながらない | CRM側の有効・無効の内訳 | 訴求とフォーム項目が「誰を集めているか」を見直す |
form_start と form_submit を使う場合も、自動収集されている前提にせず、自社のフォーム実装で各イベントが発火するかを確認します。GA4の公式Developerガイドは、自動収集、拡張計測、推奨、カスタムの4種類を区別し、RealtimeとDebugViewでイベントとパラメータを確認できると説明しています（GA4イベント設定の公式ガイド、2026年7月確認）。送信完了ページやサーバー側の成功記録とも突き合わせます。
「データがない」は「問題がない」ではない
診断表を埋めようとして、そもそもデータが存在しない行が見つかることがあります。その場合、最初の改善対象はLPではなく計測です。
計測されていない区間では、成功も失敗も判定できません。診断の最初の成果物は「どこが計測できていないか」の一覧です。
計測の欠損を放置したまま下流の施策を打つと、効果があってもなくても学びが残りません。
流入の意図とファーストビューの約束を照合する — 入場券とPODを分ける
流入と訴求の照合では、「比較テーブルに乗るための条件」と「選ばれる理由」を分けることが重要です。私たちくるみでは、この区別を「入場券とPOD」と呼んで診断に使っています(株式会社くるみ「CEP×POD」自社ポジショニング方法論、2026年)。これは外部の規格や研究が定めた基準ではなく、自社の支援経験から整理した診断の視点です。
入場券とは、対応が丁寧、実績がある、サポートが手厚い、といった「競合も同じことを言える要素」です。欠けていれば比較から外されますが、揃えたところで選ばれる理由にはなりません。一方POD（Point of Difference）は、その会社・そのサービスを選ぶ独自の理由です。ファーストビューが入場券だけなら、選ばれる理由が伝わっていない可能性を仮説として検証します。
照合の実務手順
- 検索語句レポートや広告見出しから、流入上位の意図を書き出す
- LPのファーストビューが約束している内容を一文で書き出す
- 両者を並べ、訪問者の意図に対する答えになっているかを判定する
- 約束が入場券だけで構成されていないかを確認し、PODを一つ立てる
たとえば「〇〇 費用」で流入しているのに、ファーストビューが機能紹介から始まるLPは、1行目の照合で崩れています。この状態では、CTAやフォームより先に、流入意図と約束の不一致を原因仮説として検証します。変更前後で下流指標も確認し、影響範囲を実測します。
「何をコンバージョンと数えるか」を先に決める — 媒体CVと有効問い合わせの区別
成果定義では、媒体管理画面のコンバージョン、フォーム送信、有効問い合わせ、商談を分けて数えることが重要です。この4つは名前が似ていますが、指しているものが違います。
- 媒体CV: 広告媒体が計測・推定したコンバージョン。媒体側の計測仕様や推定の影響を受けます
- フォーム送信: サイト側で確認できる送信完了。テスト送信や営業メールも含まれます
- 有効問い合わせ: 送信のうち、実際に営業対象となる問い合わせ。判定はCRMや営業側で行います
- 商談: 有効問い合わせのうち、実際に会話が始まった件数
CVRが上がったのに有効率が下がる変更は、成功ではありません。たとえば入力のハードルを下げた結果、対象外の送信が増えて営業の対応負荷だけが増えるケースです。広告管理画面の数字だけで判断すると、この悪化を判定できません。GA4の推奨イベントでは、フォームなどによる初回リード獲得をgenerate_lead、有望なリードの判定をqualify_leadとして区別しています（GA4推奨イベントの公式リファレンス、2026年7月確認）。自社の定義と一致する場合に使い、CRMの判定と照合します。
自動入札に渡す学習イベントも同じ区別で決まる
自動配信へ渡す成果イベントと、事業側が評価する有効問い合わせが異なる場合は、媒体上の改善と事業上の改善が一致しない可能性があります。どのイベントを媒体へ渡すかを記録し、フォーム成功、有効問い合わせ、商談を同じ識別子で追います。下流の結果を媒体へ連携する場合も、同意、個人情報、媒体仕様を確認してから実装します。
フォームの点検は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月確認)。赤枠やアイコンの色だけでエラーを示すフォームは、この基準を満たしません。
点検リスト
- 必要性: その項目は問い合わせ対応に本当に必要か。取得目的を説明できない項目は削除候補です
- ラベル: すべての入力欄に、何を入れるべきかが見えるラベルがあるか
- 入力形式: 期待する形式(全角・半角、ハイフンの有無など)を入力前に示しているか
- エラー: どの欄が・なぜエラーなのかをテキストで説明しているか
- 成功通知: 送信の成功が利用者に明確に伝わるか。計測している完了イベントと実際の完了体験が一致しているか
- 個人情報: 取得目的と取り扱いを送信前に確認できるか
項目を減らすこと自体は目的ではありません。有効問い合わせの判定に必要な情報まで削ると、送信数は増えても後工程の負荷が増え、成果の総量ではマイナスになることがあります。診断表の「有効問い合わせ」の行とセットで判断してください。
表示体験の診断 — Core Web Vitalsは実ユーザーのデータで見る
表示体験の診断では、実ユーザーのフィールドデータと開発時のラボデータを区別することが重要です。
Googleのweb.devによれば、Core Web Vitalsは読み込みのLCP、応答性のINP、視覚的安定性のCLSの3指標で構成され、モバイル・デスクトップ別のページロードの75パーセンタイルで、LCP 2.5秒以内・INP 200ミリ秒以下・CLS 0.1以下が目安とされています(web.dev「Web Vitals」、2026年7月確認)。Core Web Vitalsはフィールドで測定できる実ユーザー体験の指標です。Chrome UX Report（CrUX）を使う場合は、URL単位の値と、サイト配下のページを集約したオリジン単位の値を区別します（CrUX APIの公式ガイド、2026年7月確認）。ラボ値は同じ条件での再現と回帰確認に使い、フィールド値と直接混ぜません。
スコアだけでCVR低下の原因と断定しない
性能の数値を診断に使うときは、次の3点を確認してください。
- 見ている値がフィールドかラボか、どのページ・どの期間・どの母集団の集計かを台帳に書き残す。集計範囲が違う数値同士を比べると、改善の前後比較が成立しません
- 性能はイベント連鎖の一箇所にすぎない、と位置づける。閾値をクリアしても、訴求のズレやフォームの不備は残ります
- 性能が大きく閾値を外れている場合でも、CVRとの因果は検証で確認する。性能改善は表示体験の欠陥を潰す作業であり、単体スコアの到達が事業成果を保証するわけではありません
アクセシビリティと性能は、どちらも「公式の基準で機械的に点検できる欠陥リスト」として使うのが正しい位置づけです。スコアを上げること自体が目的化すると、診断表の他の行が置き去りになります。
仮説の優先順位づけと変更台帳 — 「即効性」というラベルで選ばない
仮説の優先順位では、即効性という主観的なラベルだけでなく、証拠の強さ、期待影響、実装工数、回帰リスク、戻しやすさの5軸で比べることが重要です。各軸の評価根拠を変更台帳へ残します。
| 判断軸 | 確認する問い | 判断の目安 |
|---|---|---|
| 証拠の強さ | その仮説はどのデータに基づくか | 診断表で特定した欠損に基づく仮説 > 一般論に基づく仮説 |
| 期待影響 | 直るとイベント連鎖のどこが動くか | 影響が想定される区間と指標を明記する |
| 実装工数 | 誰が・どれだけの作業で実装できるか | 自社の担当、レビュー、検証、復旧まで含めて見積もる |
| 回帰リスク | 他の箇所を壊す可能性はあるか | フォーム実装の変更は計測も同時に壊しやすい |
| 戻しやすさ | 失敗したとき元に戻せるか | 戻せない変更ほど検証設計を厚くする |
変更台帳に残す9項目
選んだ仮説は、実行前に台帳へ記録します。最低限、次の9項目です。
- 変更前値(主要指標の現状)
- 仮説(何を変えると、なぜ、何が動くか)
- 対象(ページ・流入経路・期間)
- 主要指標
- ガードレール指標(有効問い合わせ率など、悪化させてはいけない指標)
- 開始条件
- 停止条件(どうなったら中断するか)
- 結果
- 未確認事項
台帳を構造化テキストで残しておくと、あとからAIエージェントに「過去の変更と結果」を入力して次の仮説候補を挙げさせる、という運用にもつながります。候補出しはAIに任せられますが、5軸での採否判断は人が持ちます。台帳は検証の記録であると同時に、改善サイクルを自動化するときの学習データにもなります。
ABテストの健全性チェック — 固定日数とp値だけで勝者を決めない
A/Bテストでは、期間やp値を見る前に、無作為化、露出、欠損、同時変更、サンプル比の健全性を確認することが重要です。仕組みが壊れたテストの統計値は、どれだけ有意に見えても意味を持ちません。
Microsoft Researchの論文「Trustworthy analysis of online A/B tests: pitfalls, challenges and solutions」(Deng, Lu, Litz、2017年)は、オンラインのABテストでは無作為化の仕組みが複雑になりやすく、古典的な統計分析が前提とする独立性の仮定が崩れ、分散を過小評価しうることを指摘しています(Microsoft Researchの論文ページ、2026年7月確認)。「有意差が出た」という結果自体が、分析の前提次第で過信になりうるということです。
実行前後のチェックリスト
- 無作為化単位: ユーザー単位かセッション単位か。同一ユーザーが両パターンを見ていないか
- 露出: 割り当てられた人が、実際に変更箇所を見たか
- 欠損: 計測の欠けが片方の群に偏っていないか
- 同時変更: テスト期間中に別の変更(広告配信の調整、LPの修正)を重ねていないか
- サンプル比: 割付比率と実際の観測数の比率が一致しているか。ズレていたら結果を読む前に仕組みを疑う
判定ルールは実行前に決めます。「固定の日数が経ったら終了」「p値が閾値を切ったら勝ち」ではなく、必要な標本の条件と停止条件を先に台帳へ書き、満たすまで判定しないのが原則です。テスト設計の具体的な手順はLPのABテストのやり方に、必要な標本数の考え方はABテストのサンプルサイズ計算に分けてまとめています。
ランディングページ改善のFAQ
診断を実務に落とすときによく出る質問に答えます。
改善の優先順位はどう決めればよいですか?
イベント連鎖を上流から確認し、最初に観測できる崩れを原因仮説の出発点にします。優先する変更は、下流への影響も含めて5軸で比較します。複数箇所が崩れている場合は、証拠の強さ・期待影響・実装工数・回帰リスク・戻しやすさの5軸で比較して一つに絞ります。「一度に一仮説」を守るほうが、複数同時に変えるより結果的に速く進みます。
フォームの項目は減らすべきですか?
一律の答えはありません。取得目的を説明できない項目は削除候補ですが、有効問い合わせの判定に必要な情報まで削ると、送信は増えても後工程の負荷が増えます。項目数の前に、ラベル・入力形式・エラーのテキスト説明・成功通知というW3Cの達成基準に基づく点検を済ませてください。そのうえで削る場合も、ガードレール指標に有効問い合わせ率を置いて検証します。
表示速度はどこまで改善すれば十分ですか?
公開されている目安は、実ユーザー計測の75パーセンタイルでLCP 2.5秒以内・INP 200ミリ秒以下・CLS 0.1以下です。ただし閾値への到達はCVR改善の保証ではありません。表示体験はイベント連鎖の一箇所であり、達成後も他の行の診断は残ります。逆に大きく外れているなら、訴求の議論より先に直す価値があります。
ABテストができるほどアクセスがない場合はどうすればよいですか?
必要な標本条件を満たせない場合は、A/Bテストから因果的な勝敗を結論づけません。前後値、ガードレール指標、季節や配信変更などの外部要因を台帳に残し、観察結果として扱います。変更する場合は一度に一仮説へ絞り、戻しやすさと回帰リスクを確認します。
外注すべきか、社内で続けるべきかはどう判断しますか?
分岐点は、診断→一仮説→検証→記録のループが社内で回っているかどうかです。回っているなら外注しない判断も十分に合理的です。計測が壊れたまま直せない、診断表を埋めても仮説が立たない、という状態なら外部支援を検討する段階です。依頼範囲の切り方や判断材料はLPO外注の判断ポイントにまとめています。「まず計測整備だけ済ませて改善は延期する」「LPより流入設計が先」という選択肢も含めて比較してください。
まとめ — 診断・一仮説・検証・記録のループを回す
ランディングページ改善では、施策を増やす前に、診断、単一仮説、検証、記録の順序を固定することが重要です。本記事の要点を並べます。
- 流入・訴求・表示・CTA・フォーム・有効問い合わせのイベント連鎖を上流から点検し、最初に崩れた一箇所だけを直す
- 計測の欠損が見つかったら、LPより先に計測を直す
- 訴求は入場券とPODを分けて点検し、流入の意図とファーストビューの約束を照合する
- フォームと表示体験は、W3CとGoogleの公式基準を欠陥リストとして使う
- 仮説は5軸で選び、変更台帳に記録してから検証する。媒体CVではなく有効問い合わせで成否を判定する
最初の一歩
今日始めるなら、診断表の7行についてデータが取れているかどうかの棚卸しからです。埋まらない行があれば、それが最初の改善対象です。全行が埋まるなら、最初に崩れている行に対する一仮説を台帳に書いてください。
このループを社内で回せるなら、外注しない選択も候補になります。回らない原因が計測やデータ設計にある場合、あるいは媒体AIに渡す学習イベントの設計から見直したい場合は、AIグロース支援を行う私たちくるみに相談する選択肢もあります。いずれの場合も、次の一手が「なんとなくの施策」ではなく「台帳に書かれた一仮説」になっていれば、この記事の目的は果たされています。