AIでLPを作るときは、最初に「誰のどんな課題を、何の価値で解決し、訪問者に何をしてほしいか」を一文にし、構成・文章・デザイン・実装を分けて進めます。一度の指示でページ全体を生成すると、根拠のない訴求、複数の主CTA、実装できない機能が混ざりやすくなります。まず情報設計と根拠を固め、画面構造を確認した後に実装へ進めてください。
目次
Offerとコンバージョンを一つに絞る
LPの最初の仕事は、見た目を整えることではなく、提供内容と対象を明確にすることです。誰が、どの状況で、何に困り、何を受け取れるのかを書きます。「業務を効率化する」では広すぎるため、「毎月の請求確認に時間がかかる小規模チームが、確認漏れを減らすために使う」のように、対象と作業を具体化します。これは訴求案であり、効果を示す根拠がなければ実績として断定しません。
次に、訪問者に一つの主行動を求めます。購入、相談、資料請求、無料登録などを並列に置くと、どの行動が主か分からなくなります。補助行動が必要なら、主CTAを選ぶために使う情報を先に示し、視覚的にも弱く配置します。CTAを押した後に何が起こるか、必要な入力や条件は何かも明らかにします。
ClaimとEvidenceを分けて整理する
訴求文を書く前に、主張、根拠、条件、確認状態を一覧にします。料金、成果、対応機能、導入社数、顧客の声などは、確認可能な出典と対象範囲を記録します。実績値の期間、対象顧客、算定方法が分からない場合は、AIに補わせず掲載候補から外します。仮説と確認済みの事実を同じ見た目で並べないでください。
表は横にスクロールできます
| 訴求案 | 根拠として必要なもの | 根拠がない場合 |
|---|---|---|
| 作業時間を短縮 | 測定対象、期間、比較方法 | 効果ではなく試したい課題として記載 |
| 料金が安い | 比較対象、時点、含む費用 | 優位性を断定しない |
| 使える機能 | 現行仕様、プラン、利用条件 | 未確認ラベルで公開を保留 |
| 利用者の評価 | 本人の同意、出典、文脈 | 架空の testimonial を作らない |
証拠がある場合でも、見出しの主張が元資料より強くないか確認します。例えば一部利用者の感想を「誰でも満足」と一般化したり、短期間の試行を恒常的な成果として見せたりしません。外部の比較表を使うなら、比較条件と確認日を揃えます。
ページの流れをユーザーの疑問に沿わせる
section一覧は、読者が判断する順に組みます。典型的な要素として、対象と価値、使う場面、解決の仕組み、根拠、料金や条件、よくある質問、CTAがあります。ただし、すべてのLPへ同じ順番で置く必要はありません。すぐ条件を確認したい商品なら料金や対象範囲を前に出し、初めての概念を説明する必要があるなら問題と仕組みから始めます。
sectionごとに「読者がここで知りたいこと」「使える根拠」「次に理解すること」を記録します。重複する説明は一つにまとめ、提供内容と無関係な一般論は削ります。ページをスクロールしても主CTAの意味が変わらないか、補助リンクが購入・相談を邪魔していないかを確認します。FAQは本文で説明しきれない条件を補う役割にし、重要条件をFAQの奥に隠しません。
Copyは構成の確定後にsection単位で作る
全ページを一括生成するより、見出し、要点、根拠、CTAをsectionごとに作ります。Headlineは注目を引くだけでなく、誰に何を提供するか伝える必要があります。抽象的な「未来を変える」より、対象・作業・価値が読者に伝わる表現を選びます。見出しと本文で異なる約束をしないよう、主張台帳と照合します。
依頼例：
「対象は、月次の問い合わせ内容を分類する担当者です。LPの目的は相談申し込み一つです。確認済みの提供機能は入力CSVの分類候補作成と確認用一覧の出力です。時間短縮率、顧客数、成果の数値は根拠がないため追加しないでください。sectionごとに見出し案、説明、必要な証拠、確認待ちを表にしてください。CTAは『相談内容を送る』とし、送信前に必要な情報と返信条件の確認欄を置いてください。全体copyを完成させる前に不足情報を質問してください。」
この例は構成検討用の架空設定で、実在サービスの機能・実績を示しません。生成されたcopyをそのまま公開文として採用せず、根拠と提供条件を人が確認します。
Wireframeで情報量と操作を試す
文章が大枠で固まったら、色や写真を後回しにした低忠実度wireframeを作ります。hero、主要価値、比較、フォーム、CTAの占める高さを確認し、読み手が主行動へ進むまでに何を理解する必要があるかを見ます。スクロール途中で似た説明やCTAを繰り返しすぎていないかも点検します。
フォームがある場合は、入力項目が目的達成に必要か、必須・任意が分かるか、エラー時に入力内容が失われないかを確認します。登録前に必要な条件、返信までの流れ、価格・契約の条件は、判断に必要な位置へ置きます。スマートフォンの画面では表や長い見出し、固定CTAが本文を隠さないかをwireframe段階から試します。
Visual designは既存ルールへ合わせる
wireframeの順序と情報量を確認してから、色、書体、余白、画像、図表、アニメーションを適用します。ブランドガイドがある場合は、色やロゴをAIに新しく作らせず、正式な部品と規則を使います。商品画面を見せるなら実際の画面か、説明用のmockかを区別します。生成画像を実績写真や顧客の声の証拠に見せないようにします。
Figmaやv0などのAI機能は初期案や編集可能なUIを作れる場合がありますが、機能・提供条件・出力形式は更新されます。利用中のアカウントで現在使えるか、コードが既存環境と合うかを先に確認します。特定機能の提供を前提にページ設計を固定せず、手作業で代替できる設計にします。生成案に不要な依存関係、架空のAPI、ダミー料金が含まれていないかも確認します。
実装は受け入れ条件を決めて小さく進める
実装前に、既存の技術構成、route、component、フォーム送信先、分析計測、利用する画像やフォントを確認します。AIへ全サイトの作り替えを頼まず、例えば「heroの構成だけ」「FAQの表示だけ」と範囲を切り、差分をレビューできる単位で進めます。公開環境のURLや環境変数を推測でコードへ入れないようにします。
受け入れ条件には、表示幅、リンク先、フォームの成功・失敗、キーボード操作、読み込み状態、404、メタ情報、画像サイズなどを含めます。クリックできるボタンが実際のActionを行うか、送信後に状態が分かるか確認します。見た目が完成しても送信先が未実装なら、動作済みと扱いません。計測eventは既存契約を維持し、LP改善を理由に名前やparameterを変更しません。
公開前に内容・動作・表示をQAする
デスクトップとモバイルで、headline、本文、表、画像、フォーム、CTA、footerが崩れないか確認します。横スクロール、文字の切れ、画像の代替テキスト、色のコントラスト、フォーカス表示も見ます。リンクは全て実在routeへ到達するか、古い価格や仕様を残していないか確認日とともに記録します。
表は横にスクロールできます
| QA領域 | 確認 | 失敗したとき |
|---|---|---|
| 説明 | 対象・価値・条件が一致 | claim台帳とcopyを照合 |
| CTA | 押した後の動作が説明どおり | link / form / success stateを修正 |
| 根拠 | 数値・機能・testimonialの出典あり | 未確認主張を外す |
| モバイル | overflow・操作・フォーム問題なし | 情報順・余白・表を調整 |
| 表示速度 | 画像・scriptが必要量か | assetと第三者scriptを見直す |
| アクセシビリティ | keyboard・label・contrast | semanticsとfocusを修正 |
QA担当が実装者と同じ推測を共有しないよう、根拠URLと期待結果をテスト条件に含めます。conversion rateが改善したと主張する場合は、比較期間、流入元、サンプル、計測条件が必要です。公開前の見た目確認だけで成果を保証しません。
Formと個人情報の取り扱いも設計する
フォームは必要最小限の項目にし、なぜ情報を求めるか、どのように連絡へ使うか、送信後に何が起きるかを説明します。利用者の入力をanalyticsや外部serviceへ流す場合は、既存のprivacy policy、同意、データ保持、アクセス権を担当者に確認します。機密情報を入力欄へ求める必要がなければ、注意書きだけで済ませず、項目自体を削除できるか検討します。success画面、二重送信、通信失敗時の表示も、内容と実装の両方で確認します。
AIものさしの判断
LP制作では、AIにページ全体を一度に書かせるより、offer・根拠・情報順・copy・wireframe・実装を分ける方が、主目的を保った修正ができます。主CTAと対象ユーザーが明確で、主張の根拠を追え、フォームと表示を試せるなら公開準備へ進めます。根拠のない効果、料金条件の不明、提供機能の未確認、送信先の未実装が残るなら、装飾や公開を進めず、その項目の確認を優先してください。
公開後の計測を成果と混同しない
公開後に問い合わせ数や登録数を見る場合は、何を一件と数えるか、対象期間、流入元、重複送信やbotをどう扱うかを先に定義します。クリック数だけでは、相談完了や適切な問い合わせが増えたか分かりません。計測環境、同意設定、既存のanalytics contractを確認し、送信テストと本番イベントを区別します。変更前後を比較するときは、同時期の広告・季節性・流入構成の差も記録し、LPの変更だけが原因と断定しないようにします。十分なデータがないなら、観察結果と仮説を分けて報告します。