LP 作成の実務ガイド｜要求整理から公開受入まで

LP 作成とは、ページを公開する作業ではなく、「誰に何を約束し、その根拠は何か。訪問者に何を入力してもらい、成功と失敗をどう検知し、失敗したらどう復旧するか」を検収できる状態に落とす作業です。デザインやコピーはその一部にすぎません。

この記事は、LPを自社で作る人が、要求整理からコピー、フォーム、計測、公開、検収、引継ぎまでに決めるべきことを一つずつ埋められるように書いています。読み終えたときに手元に残るのは「きれいな画面」ではなく、公開してよいかを自分で判定できる基準の一式です。

この記事が扱う範囲と扱わない範囲

• 扱う範囲: 自社制作のための要求仕様づくり、訴求の点検、フォーム・性能・計測の受入、公開判定、引継ぎ
• 扱わない範囲: LPそのものの定義や通常ページとの違いはLPとは何かを整理した記事に、制作会社へ外注する場合の会社選定はLP制作の外注に関する記事に分けています

この記事では「この構成や色にすればCVRが上がる」とは説明しません。LPの事業成果は対象読者、商品条件、訴求、根拠、流入、フォーム、計測など複数要因の影響を受け、画面の型だけでは保証できないためです。W3C、Google、消費者庁の一次資料を参照し、公開時点で何を検査でき、何が公開後の未確認事項として残るかを分けます。

この記事の「入力契約」は、LP企画前の前提を6項目で記録する、くるみの制作フォーマットです。公式規格や唯一の項目数ではありません。デザイン着手前に確認済みの前提、仮説、正本、承認者を1枚へ置き、後工程で判断が変わった理由を追えるようにします。

入力契約の6項目

1. 誰が: 想定する読者の役割と立場（例: 事業会社のマーケ担当で、決裁者への説明責任がある）
2. どの状況で: このページに来る直前に何が起きているか（検索、広告、紹介、比較表からの流入など）
3. 何と比較し: 読者の頭の中にある代替案（競合サービス、内製、何もしない）
4. 何を不安に思い: 申込みをためらわせる具体的な懸念
5. 何を証拠として受け入れ: その不安を解消するのに読者が納得する資料の種類（仕様、第三者資料、デモなど）
6. 次に何をするか: このLPで読者に求める唯一の行動（資料請求、問い合わせ、申込みのいずれか一つ）

記入例はあくまで仮の値

たとえば「経理部門の課長が、月次締めの遅れをきっかけに検索で流入し、現行の手作業と比較し、導入工数を不安に思っている」といった記入は、読者であるあなたが自社の状況に置き換えるべき仮定です。この記事の例をそのまま使っても、あなたのLPの前提にはなりません。

埋まらない欄の扱い

6項目のうち埋まらない欄は、空欄のまま進めるのではなく「仮説」とラベルを付けて残します。仮説のまま公開する場合は、公開後にどの計測やヒアリングで検証するかを隣に書いておきます。確認済みの前提と仮説を区別しておくことが、後の改善判断の土台になります。

訴求の点検では、「競合も同じことを言える安心要素」と「このLPで選ばれる理由」を分けることが重要です。私たちはこの点検法を「入場券とPODを混同しない」と呼んでいます。

「運用が丁寧」「レポートが早い」は比較テーブルに乗るための入場券であって、選ばれる理由（POD）ではない。競合も同じことを言える要素はPODから外す。投資配分は「入場券は広く・薄く・同等に、PODは狭く・厚く・独自に」。 — 株式会社くるみ「CEP×POD」（自社ポジショニング方法論、2026年）

仕分けの手順

LPに載せる主張を書き出し、「競合が社名を差し替えて同じ文を載せられるか」を問い、くるみの仮説上の入場券とPODに仕分けます。これは掲載位置や成果を保証する法則ではありません。入場券は削除せず、読者の不安を解くために必要な量を残します。POD候補は、競合が言いにくいだけでは不十分で、対象読者に重要であり、根拠資料と適用条件を示せる場合に目立つ位置の候補にします。仕分け後は、実際の読者調査や公開後データで仮説を検証します。

主張ごとに根拠所有者を置く

仕分けが終わったら、残った主張の一つひとつに「この根拠資料は誰が持っているか」を割り当てます。所有者が決まらない主張は、掲載を保留します。根拠所有者の欄が全部埋まった状態が、コピー工程に進んでよい条件です。この台帳は後述の主張台帳にそのまま引き継ぎます。

この記事の工程分解表では、情報設計、コピー、根拠、画面、フォーム、計測、公開の7工程に、入力、成果物、受入証拠、戻し条件を割り当てます。7という数は公式基準ではなく、担当が一人でも変更理由と受入結果を残すための制作単位です。

工程分解表

「戻し条件」を先に決めておく理由

戻し条件は、制作前に差し戻しの判定を固定し、制作後に都合よく基準を変えないためのものです。外注時は、受入証拠、再作業の範囲、回数、費用、承認者を発注条件へ対応づけます。表は自社の体制に合わせて変更し、変更した基準と理由も記録します。

フォームの受入では、正常送信だけでなく、空欄、形式不正、二重操作、通信失敗を確認することが重要です。正常系だけでは、入力エラー時に送信記録を作らないことや、通信失敗後に誤って完了扱いしないことを検証できません。

フォームで先に確認するWCAG 2.2の3基準

次の3項目はいずれもWCAG 2.2のレベルAですが、これだけでWCAG全体への準拠や法令適合を表明できるわけではありません。フォームの初期確認として使い、サイト全体の対象範囲と適合確認は別に計画します（2026年7月20日確認）。

• ラベルまたは説明（達成基準3.3.2）: 入力を求める場合、必要なlabelまたはinstructionが提示されているか。Labels or Instructionsの解説で目的と例外を確認します
• エラーの特定（達成基準3.3.1）: 入力エラーが自動検出された場合、誤りの項目を特定し、内容をテキストで説明しているか。Error Identificationの解説で確認します
• フォーカス順序（達成基準2.4.3）: 順番が意味や操作へ影響する場合、フォーカス可能な要素が意味と操作性を保つ順序になっているか。Focus Orderの解説で確認します

試すべき5つの失敗系

1. 正常入力: 送信後に成功が明確に通知されるか
2. 空欄送信: 必須項目を空のまま送信し、どの欄が未入力かテキストで戻るか
3. 形式不正: メールアドレス欄に不正な文字列を入れ、修正方法が分かる形で戻るか
4. 二重送信: 送信ボタンを連打し、受信側で重複がどう扱われるか
5. 通信失敗: 通信を切った状態で送信し、入力内容が失われないか・再送の案内が出るか

クライアント側の見た目だけで完了にしない

ブラウザの表示、サーバー受信、通知、CRM登録は別の事実です。正常入力では期待する受信・登録が1件だけ残ることを確認します。空欄・形式不正・通信失敗では、完了表示や成功記録が残らないことが合格証拠になる場合があります。二重送信では、画面の抑止と受信側の重複処理をそれぞれ確認します。各シナリオの「残るべき記録」と「残ってはいけない記録」を先に決めてください。

Core Web Vitalsは、Googleが示すユーザー体験の指標で、現在はLCP、INP、CLSで構成されます。性能の受入では、公開前のラボ測定と、公開後に蓄積する実ユーザーデータを分けます。この指標だけでCVR、検索順位、アクセシビリティ、法令適合は判定できません。

Core Web Vitalsの読み方（ラボとフィールド）

GoogleのCore Web Vitalsの閾値の定義は、LCP 2.5秒以下、INP 200ミリ秒以下、CLS 0.1以下を「良好」とし、実ユーザー計測の75パーセンタイルで評価する考え方を示しています（2026年7月20日確認）。新規LPには公開前の実ユーザーデータがないため、ラボ測定で明らかな問題を調べ、公開後に十分なfield dataが得られた時点で75パーセンタイルを記録します。データが不足する間は合格へ丸めず「未確認」とします。

注意点として、閾値を満たすことはCVRの改善や検索順位、法令適合を保証しません。性能は「遅さで読者を失わないための受入条件」であり、事業成果は前章までの訴求と計測で別に検収します。

アクセシビリティは段階的な目標として運用する

アクセシビリティ対応は一度の合格で完成するものではなく、方針を示して段階的に広げる運用が実態に合っています。参考になるのがデジタル庁のウェブアクセシビリティ方針（2026年7月20日確認）で、2021年9月1日に方針を定め、JIS X 8341-3:2016の適合レベルAA準拠（加えてJISに含まれないWCAG 2.2の18基準）を目標に掲げつつ、2026年3月31日時点の到達状況はレベルAに一部準拠であること、目標時期を2027年3月31日とすることを公開しています。この公開例のように、目標、対象範囲、確認時点、現状を分けて記録します。他組織の到達状況を自社の免責には使わず、確認していない基準を準拠済みと表明しません。

公開受入表の例

公開前はラボ条件とアクセシビリティの確認結果を記入し、field dataは未確認の理由と再確認日を置きます。欄が埋まること自体ではなく、結果、証拠、不合格時の対応が受入記録です。

計測設計では、CTAクリックから有効問い合わせまでを別の事象として記録し、同じ「CV」にまとめないことが重要です。段階を分けると、取りこぼし、重複、未確認の場所を検査できます。

7段階の証拠連鎖

1. CTAクリック: ボタンが押された事実。関心の兆候にすぎず、リードではありません
2. フォーム表示: フォームまで到達した事実
3. 送信操作: クライアント側で送信が実行された事実
4. サーバー受信: サーバー側に受信レコードが残った事実。ここから先が「届いた」証拠です
5. 受付完了: 読者に完了が通知された事実
6. CRM登録: 顧客管理側にレコードが作られ、重複が排除された事実
7. 有効問い合わせ: 入力契約の対象条件に合致すると人が判定した事実

各段階に「何を証拠とするか」と「誰が確認するか」を割り当てます。1〜3と5は画面側のイベント、4と6はサーバーとCRMの記録、7は人の判定です。

GA4イベントの位置づけ

GA4のevent解説は、自動収集、拡張計測、推奨、custom eventを分けています。推奨eventリファレンスには、リードが生成された際のgenerate_leadが定義されています（2026年7月20日確認）。フォームのserver受信など、自社が「lead生成」と定義した成功事実に対応するtriggerを検収してから採用し、CTAクリックやフォーム表示には使いません。GA4 event名だけで事業上の問い合わせを証明したことにはなりません。

• 完了画面のURL表示だけを唯一の証拠にしない: 完了ページは再読み込みや直接アクセスでも表示され得るため、サーバー受信記録との突合なしでは件数を確定できません
• CTAクリックをリードと呼ばない: クリックは連鎖の1段目であって、4段目以降の証拠を伴いません

受入テストでは一意なtest IDを使い、各scenarioで「残るべき記録」と「残らないべき成功記録」を照合します。正常送信は技術段階ごとに1件、空欄・形式不正・通信失敗は成功記録0件、二重操作は設計した重複処理どおりかを確認します。test送信を有効問い合わせへ数えず、CRMでtest除外または無効判定が記録されることも証拠にします。

主張台帳とは、効果や性能をうたうコピーの一つひとつに、対象・表示文・根拠資料・適用条件・確認日・承認者の6項目を対応づけて管理する一覧表です。コピーは書いた時点ではなく、「根拠資料と対応づけて承認された時点」で掲載可能になります。

主張台帳の6項目

• 対象: 誰に対する主張か
• 表示文: LPに載せる文言そのもの
• 根拠資料: 対応する資料の名称と保管場所
• 適用条件: その主張が成り立つ前提や範囲
• 確認日: 資料を最後に確認した日付
• 承認者: 掲載を承認した人

資料と表示文が対応しない行は、公開しません。表示だけ先に作って「根拠は後で揃える」を許すと、台帳は形骸化します。

景品表示法の不実証広告規制を前提に置く

効果・性能の表示については、消費者庁が不実証広告規制の解説（2026年7月20日確認）で示すとおり、消費者庁は事業者に対し期間を定めて表示の裏付けとなる合理的な根拠資料の提出を求めることができ、提出されない場合などは景品表示法第7条第2項に基づき不当表示とみなされる仕組みがあります。合理的な根拠と認められるには、客観的に実証された内容であることと、主張された効果と資料が適切に対応していることの2つが必要とされています。主張台帳は、表示と資料の対応を日常的に確認するための社内フォーマットであり、台帳があるだけで合理的根拠や法令適合を保証しません。個別の表示が法令に適合するかは、対象表示と資料に基づいて専門家へ確認してください。

AIに任せる範囲と人が締める範囲

生成AIは、訴求の言い換え、構成、エラーメッセージの候補作成に使えます。ただし品質向上は前提にせず、従来案と同じ入力・受入基準で比較します。一次情報、権利、アクセシビリティ、フォーム挙動、計測は人が証拠を確認し、公開を承認します。prompt、入力、出力、採否理由、使用モデルを残せば、担当変更後に同じ評価セットで差分を再検証できます。

自社制作の現場でよく出る質問に、本文で定義した基準を当てはめて答えます。

ノーコードツールで作る場合も、この受入手順は必要ですか？

必要です。ツールが肩代わりするのは画面実装の一部であって、入力契約、訴求の仕分け、フォーム失敗系の確認、計測の突合、主張台帳はツールに関係なく残ります。むしろツール利用時は、フォームの送信先やエラー表示の挙動を自分で変えられない場合があるので、失敗系5種を試して仕様として記録しておくことが引継ぎの助けになります。

フォームの検収は実装者に任せてよいですか？

判定基準の所有者は発注側である自社です。実装者には失敗系5種のテスト記録を成果物として求め、受け取った上で、空欄送信・形式不正・キーボードのみの操作は自分でも試してください。「実装者が確認する値」と「自社が判定する基準」を分けるのが、工程分解表の受入証拠の考え方です。

計測はGA4のイベント設定だけで足りますか？

足りません。GA4 eventは実装したtriggerに応じた分析用の記録であり、clientまたはserverのどちらから送っても、フォーム受付、CRM登録、有効問い合わせを単独では証明しません。一意なtest IDで各段階の期待値を照合し、testを有効問い合わせから除外します。本番では期間、タイムゾーン、重複条件を固定し、未確認の差分を残して検査します。

アクセシビリティはどこまで対応すれば公開してよいですか？

この記事の3基準とキーボード操作は、フォームの初期確認であり、WCAG全体の合格ラインではありません。対象ユーザー、法令・契約、サイト方針に応じて目標レベル、対象範囲、試験方法、未達項目、改善期限を決めます。準拠を表明する場合は、該当する規格と試験結果に基づいて専門家へ確認してください。

公開後に文言や価格を直したら、何を再検査すればよいですか？

直した内容によって再検査の範囲が決まります。効果や条件に関わる文言なら主張台帳の該当行（根拠資料と適用条件、確認日）を更新し、フォームや計測に触れたなら失敗系5種と証拠連鎖の突合をやり直します。いずれの場合も公開判定表の該当項目を再記入し、変更日と変更者を残してください。修正のたびに全項目を検査し直す必要はありませんが、「どこまで再検査したか」の記録がない修正は、次の改善判断を濁らせます。

この記事で提案するLP公開判定は、ページ表示だけでなく、次の10項目に証拠、未確認事項、戻し条件を記入することです。10項目は公式規格ではなく、法令・契約・対象ユーザーに応じて追加します。

公開判定表の10項目

• 対象: 入力契約の6項目が記入済みか（仮説には検証方法が付いているか）
• 約束: 入場券とPODを自社仮説として仕分け、重要性・根拠・適用条件から掲載位置を判断したか
• 根拠: 主張台帳の全行に根拠資料と承認者があるか
• CTA: 求める行動が一つに絞られているか
• 入力: フォームのラベル・エラー表示・フォーカス順序を確認したか
• 成功: 送信成功が読者に通知され、サーバー受信と一致するか
• 失敗: 失敗系5種の挙動を記録したか
• 計測: scenario別に残る記録と残らない成功記録を照合し、testを有効問い合わせから除外したか
• 性能: 公開前のラボ条件と結果、公開後field dataの未確認理由・再確認日を記入したか
• 担当: 各工程の受入証拠と戻し条件に責任者がいるか

公開後の改善は別の仕事です。数値を根拠に改善を回す進め方はLPOの考え方を整理した記事に分けています。

自社だけで判定しきれない時

訴求の仕分けや、計測の証拠連鎖の設計は、初回は判断に迷う部分が多い工程です。私たち株式会社くるみは、AIを物量と速度のエンジンに、人の目利きを質の担保にするAIグロースファームとして、LPの要求整理から計測・受入の設計、AIを使った制作工程の仕組み化までを支援しています。「公開判定表のどこが埋まらないのか」を持ち込んでいただければ、そこが相談の出発点になります。