プロンプトを編集

タイトル必須4 / 120

本文必須5,745 文字

# LPモックアップ画像から、実際に使えるLPを実装する

添付のLPモックアップ画像をもとに、レスポンシブなLPを実装してください。
目標は、画像に似たページを作ることではなく、画像のデザイン意図を保ちながら、クライアントレビューに出せる実装と検証結果をそろえることです。

## 案件情報

- 商品・サービス：［記入］
- 対象読者：［記入］
- 訪問者に取ってほしい行動：［購入／問い合わせ／予約など］
- CTAの文言・遷移先・送信先：［記入］
- 確定したコピー・価格・掲載情報：［記入、またはファイルを指定］
- 支給素材：［ロゴ／商品画像／背景／フォントなど］
- 実装環境・公開先：［記入。未指定なら下記の方針に従う］
- 変更禁止の要素・対応ブラウザ：［あれば記入］

未記入の項目は、添付資料と既存プロジェクトから確認してください。
見た目に関する仮定は明記して進めて構いません。価格、実績、口コミ、権利許諾、URL、送信先は推測で埋めないでください。
画像が参照できない場合は、見たふりをせず不足を報告してください。

## 1. 元画像の扱いと、再現の優先順位

元画像は、複数セクションの構成と視覚表現をまとめた見本です。
画像全体のピクセル寸法や縦横比は、実際のWebページの幅・高さの指定ではありません。

忠実に保つもの：
- ブランドカラー、背景の質感、書体の印象、見出しの強弱。
- 主役となる画像、図形、装飾と文字の位置関係。
- セクションごとの構図の特徴、情報の順序、確定コピー。

Web向けに設計し直すもの：
- 各セクションの高さ、余白、本文幅、文字サイズ、改行。
- PCとスマートフォンの列数、配置、画像のトリミング。
- スクロール中の見え方、セクション間のつながり、操作時の状態。

画像を丸ごと貼る、横幅に合わせて全体を縮小する、セクション画像を縦に並べるだけの実装は禁止します。
元画像の全要素を絶対配置し、ページ全体をscaleで縮小する実装も禁止します。

可読性や操作性と衝突する場合に限り、見た目を必要最小限変更してください。
変更理由を記録し、元画像と無関係なテンプレートへ作り替えないでください。
特に、すべてを同じ角丸カードや同じフェードインに置き換えないでください。

## 2. 実装前に、画像を閲覧体験の設計へ変換する

既存コード、支給素材、参照画像を確認した後、短い設計メモを作ってください。

最初に、元画像らしさを決めている視覚的な特徴を3〜5点に整理してください。
続いて、各セクションについて次の内容を示してください。

- そのセクションで伝える主題と、表示する情報。
- 「見せ場」「説明」「短い補助情報」のどれに当たるか。
- PCでの高さの方針と、スマートフォンでの配置。
- 主役となる要素、読み始める位置、CTAの有無。
- 前後のセクションとの静的なつなぎ方。
- 動きを使う場合の目的、開始条件、終了状態、所要時間と移動量。
- 動きを無効にした場合の表示。
- 支給素材で再現できる部分と、不足する素材。

元画像から読み取れたことと、あなたが補った設計を区別してください。
セクション数を増やす、順番を変える、訴求内容を変える必要がある場合は、通常のレイアウト調整とは分けて提案してください。

設計メモを提示したら、重大な未確定事項以外は仮定を記録し、実装と検証まで進めてください。
ビジネス情報や接続先が未確定の部分は、レビュー用の仮表示とし、公開前の未完了項目へ残してください。

## 3. セクションの高さとスクロール設計

「すべてのセクションを1画面に固定」ではなく、「見せ場は約1画面、説明は内容に応じた高さ」を基本方針にしてください。

### 見せ場

ファーストビューや、主役を大きく見せるセクションは、画面の高さを基準に構図を組んでください。
必要な場合はmin-height: 100svhなどを用い、内容が増えたら自然に高さが伸びる構造にしてください。
固定ヘッダーが重なる領域や、ブラウザのアドレスバーを考慮してください。
100dvhを使う場合は、スクロール中の高さの変化が構図を揺らさないか確認してください。

### 説明

機能説明、料金、比較、事例、FAQなどは、内容量に合わせて高さを決めてください。
1画面に収めるために本文を小さくする、情報を削る、文字を隠す、セクション内部だけをスクロールさせる方法は使わないでください。

### 短い補助情報

ロゴ列、注記、補助リンクなどを、理由なく1画面まで引き伸ばさないでください。

### 共通

- セクションの高さは、画面の横幅だけでなく高さも確認して調整する。
- スマートフォンや高さの低い画面では、1画面の構図より読みやすさを優先する。
- 内容のない大きな空白を、スクロール距離を増やす目的で作らない。
- 次のセクションが少し見える構図も許容する。毎回画面端で切り替わる必要はない。
- 縦方向はブラウザ標準のスクロールを使う。
- ホイールやタッチ操作を乗っ取り、1回の操作で次の画面へ強制移動させない。
- ページ全体への強制スクロールスナップは初期実装では使わない。

## 4. セクション間のつながりと動き

区切りは、境界線やアニメーションを追加することだけで表現しないでください。
元画像の世界観に合わせ、背景、余白、見出し、構図、装飾の重なりで話題の切り替わりを示してください。
背景が連続していても、どこから次の主題が始まるか分かれば構いません。

アニメーションを無効にした状態で、先にページを成立させてください。
その後、視線を主役へ導く、比較を理解させるなど、目的のある場所だけに動きを追加してください。
動きを使わない判断も認めます。

- 元画像の主役と競合する装飾や、意味のない3D表現を追加しない。
- 見出しやCTAを読むために、長い演出の終了を待たせない。
- ファーストビューの主要テキストとCTAは、初期状態で表示する。
- 登場演出は視線を誘導したい要素に限定し、上へ戻るたびに本文を消して再演出しない。
- 通常の読書スクロールに、過剰な視差移動や強いズームを付けない。
- stickyを使う場合は、固定する理由と解除地点を決める。
- stickyを解除しても同じ情報を読める構造にする。
- 狭い画面や高さの低い画面では、stickyなどの演出を簡略化する。
- prefers-reduced-motion: reduceでは、移動、ズーム、視差、強制的な滑らかスクロールを停止または簡略化する。
- 演出のスクリプトが失敗しても、本文と主要リンクを表示する。
- 同じ短い演出のためだけに、大きなアニメーションライブラリを追加しない。

## 5. 素材、HTML、レスポンシブ実装

### 素材

文字、背景、商品画像、装飾を分けて扱ってください。
見出し、本文、価格、ボタンの文言は、原則として編集できるHTMLのテキストにしてください。
ロゴなど表現上必要な部分は、適切な代替テキストとともに画像を使って構いません。

複雑なイラストや商品画像を、似ていないCSS図形へ置き換えないでください。
支給された単体素材を優先し、元画像から安全に切り出せる素材は切り出して構いません。
文字が重なった画像や、隠れた背景は、元のレイヤーを取得できたものとして扱わないでください。
再現に素材が足りない場合は、必要な素材と用途を明記してください。
フォント名や素材の提供元を特定できない場合は、推定を事実として報告しないでください。

### HTMLとCSS

- 本文のレイアウトは通常フロー、Grid、Flexを中心に組む。
- 絶対配置は、構図上必要な装飾など局所的な用途に限定する。
- 見出し階層、リンク、ボタン、フォームを用途に合ったHTMLで実装する。
- 色、余白、文字サイズ、角丸など、繰り返す値は共通化する。
- 320 CSS px相当の幅でも、通常の本文が横スクロールなしで読めるようにする。
- PCの画面を縮小表示するのではなく、スマートフォン用に要素を並べ直す。
- 見た目の配置と、読み上げ・キーボード操作の順序を矛盾させない。
- 横にはみ出す原因を直す。ページ全体のoverflow-x: hiddenで問題を隠さない。
- 装飾だけを意図的に切り抜く場合は、その要素の範囲で処理する。

### 実装環境

既存プロジェクトがある場合は、その構成とルールを優先してください。
指定のない新規の静的LPは、HTML・CSSと必要最小限のJavaScriptを基本にしてください。
必要のないフレームワーク変更や依存関係の追加はしないでください。

## 6. 見た目以外の完成条件

### 操作

- CTAとナビゲーションは、正しいリンク先や対象へつなぐ。
- 行き先のないボタン、仮のhref="#", 見せかけの送信成功を残さない。
- 未接続の機能は未接続と分かるレビュー表示にし、公開前の未完了項目に記録する。
- フォームがある場合は、入力エラー、送信中、成功、失敗の状態を実装する。
- 成功表示は、実際の送信処理の結果に従わせる。
- メニューやアコーディオンは、キーボードでも操作できるようにする。
- hoverだけに操作の手がかりを依存させず、フォーカスを見える状態にする。
- 固定ヘッダーや追従CTAが、本文、入力欄、移動先の見出しを隠さないようにする。

### 表示と読みやすさ

- 通常の本文は、背景とのコントラスト比4.5:1以上を基準に確認する。
- ボタンなど主要な操作領域は、44×44 CSS px以上を設計上の目安にする。
- 文字を200%に拡大しても、情報や機能を失わないようにする。
- 画像の代替テキスト、フォームのラベル、エラーの説明を付ける。
- 画像やフォントの読み込み前後で、大きな位置ずれが生じないようにする。

### 公開準備

- 確定情報に基づき、ページタイトル、説明文、OGPを設定する。
- 公開URLなどが未定の項目は、架空の値で完成扱いにしない。
- 画像を表示サイズに応じて用意し、不要な大容量データを避ける。
- 初期表示に必要な画像と、後から読み込める画像を分ける。
- アクセス解析、外部サービス、本番への公開は、指定や許可なしに追加・実行しない。

## 7. ブラウザで確認し、修正する

コードを書いただけで完了にしないでください。
利用可能なブラウザ操作ツールを使い、起動したページを実際に確認してください。

基準となるビューポート例：
- PC：1440×900、1280×720。
- タブレット：768×1024。
- スマートフォン：390×844、360×640。
- 追加確認：幅320 CSS px相当、高さの低い横向き画面。

画像だけを見た推測を「動作確認済み」と呼ばないでください。

### 見た目の確認

ページ全体のスクリーンショットに加え、各セクションが表示された通常の画面サイズのスクリーンショットも確認してください。

元画像との比較では、色、書体の印象、主役、構図、情報の強弱を照合してください。
元画像の全体縦横比へ合わせるために、意図して設計し直した高さを元に戻さないでください。

### スクロールの確認

上から下、下から上へ実際にスクロールし、次を確認してください。

- 主役と見出しが同時に理解できる位置にあるか。
- 話題の切り替わりが、余白と構図で分かるか。
- 区切りで不自然な空白、重なり、切断が生じていないか。
- スクロール速度が変わっても、情報を読み逃す実装になっていないか。
- 演出のために、本文を読めない時間が生じていないか。
- stickyの開始・解除、ページ内リンク、途中位置での再読み込みが破綻しないか。
- アニメーションを減らす設定でも、情報と操作が維持されるか。

### 機能と技術の確認

CTA、メニュー、フォーム、キーボード操作、文字拡大を確認してください。
フォームの試験はテスト環境で行い、許可なく本番へ個人情報やテスト申込を送らないでください。
コンソールエラー、読み込み失敗、横はみ出しを調べてください。
プロジェクトに存在するbuild、lint、型チェック、関連テストを実行してください。

計測できる場合は、表示速度とレイアウトの位置ずれも測定してください。
Core Web Vitalsの目標は、モバイル・PC別に集計した実ユーザーデータの75パーセンタイルでLCP 2.5秒以下、INP 200ms以下、CLS 0.1以下です。
ローカル計測やLighthouseのスコアを、実ユーザーデータでの達成と混同しないでください。

問題を見つけたら修正し、影響する画面と操作を再確認してください。
ブラウザ確認や実機確認ができない場合は、実施できた検証と未検証の項目を分けて報告してください。
端末のエミュレーションを、実機確認済みとして報告しないでください。

## 8. 引き渡し

最後に、次を簡潔に提出してください。

1. 実装したファイルと起動・ビルド方法。
2. 元画像から保った部分と、Web向けに変更した部分、その理由。
3. 確認したブラウザ、画面サイズ、操作、テストの結果。
4. 比較用スクリーンショットの保存先。
5. 素材不足、仮コピー、未接続機能、未検証環境など、公開前に残る作業。

「実装済み」「検証済み」「未確認」「クライアント確認待ち」を区別してください。
未完了項目がある場合は、「そのまま納品・公開可能」と断定しないでください。

説明メモ（任意）0 / 300

タグ（任意）0 / 12

まだタグは付いていません

既存のタグ（押すと付きます）

キャンセル