LPフォームの制作要件
Date2026/04/14 Last Modified2026/04/14
概要
「問い合わせのできるLPを作成してほしい！」という要望は、小規模な案件だとよくある話。
しかし、その実どういう要件で作ってほしいのかは提案する必要があるので、普段こういう機能を付けているという経験をまとめたい。
セキュリティや機能など。
セキュリティ編
Laravelを使うと、bladeを扱えない人が改修時に参画できなくなるため、簡素なLPはPHPで作成することもしばしば。
PHPで作成すると、見過ごしていたセキュリティ要件がちらほら出てくるので、注意点をまとめる。
1. CSRF対策
CSRF対策とは、CSRF（Cross-Site Request Forgery）攻撃を防ぐための対策である。
つまるところ、フォーム送信や確認ページのURLを直接たたくことにより、本来とは違う経路でのリクエストを送られないようにすること。
対策しなかった場合起こり得ること
- バリデーションをすり抜けて不正な値が送信される
- botによるスパム送信が簡単に行われる
実装方法
- セッションの開始時にトークンを生成してセッションに入れる
- フォームの隠しフィールドに同じトークンを設定して送信する
- リクエストの検証時、セッションとトークンの一致を確かめる
2. 二重送信対策
二重送信対策とは、同じ内容のフォームを複数回送信することを防ぐための対策である。
故意に二重送信するほかに、動作の遅い環境で何度も送信してしまうことを防ぐ意味もある。
対策しなかった場合起こり得ること
- 多重リクエストによる攻撃の温床になる
- メールが複数回送られることで、ユーザーと管理者の体験が損なわれる
- アフィリエイト等の集計が不正確になる
実装方法
- フォームを表示するときにトークンも一緒に生成してセッションに入れる
- フォームの隠しフィールドに同じトークンを設定して送信する
- リクエストの検証時、セッションとトークンの一致を確かめる
- 追加で、jsで送信ボタンを無効化するとなお良い
3. XSS対策
XSS対策とは、XSS（Cross-Site Scripting）攻撃を防ぐための対策である。
送信内容に実行可能なスクリプトを仕込むことにより、不正な動作を引き起こす攻撃。
対策しなかった場合起こり得ること
- セッションの乗っ取りや、クッキー窃取によるなりすまし
- 偽サイトへの誘導や、SQLインジェクション
実装方法
- htmlspecialchars()関数を使用して、HTMLタグをエスケープする
4.設定ファイルへのアクセス制限
設定ファイルは、webサーバーから直接アクセスできないようにする。
慣習で.envなどを普通に置いておくと、example.com/.env みたいな形でアクセスできてしまってあらゆるものが漏洩する。
対策しなかった場合起こり得ること
- APIキーが漏洩してメールが大量送信される
- DBの接続情報が漏洩してデータベースが操作される
- AWSのキーが漏洩してコンソールが破壊される
実装方法
- .htaccessやnginxの設定で、設定ファイルへの直接アクセスをブロックする
- 一応config.phpのようにphpにしてしまえば直アクセスは防げるが、不安ではある
5. .gitignoreの設定
gitの管理下に置くべきファイルと置かないファイルを明確にする。
例えば、.envやconfig.phpなどは、.gitignoreに追加しておくと良い。
SEO編
最近はSEOに最適化されたAIがあるので、何が不足しているのかを検証してくれるようになってきている。
しかし依然としてデザインに弱いので、コーディングが必要な際は以下を意識しながら。
バックエンドエンジニアの領域からはかけ離れている気がするが……なんでもエンジニアなので。
1. DOMを正しい構造で書く
ひとつのページにタグは一つだけ書く。
2. 画像の最適化
ogp画像などを除いて、すべての画像はwebp形式に変換し、alt属性をつける。
FV画像を除き、lazy loadingを適用する。
3. リンクの最適化
リンク先が外部の場合はrel=“noopener"を付与する。
4. テキスト化
基本的に画像に文字が載っている状態は良くない(検索エンジンが読み取れない)ので、なるべく画像ベタ張りのページは避ける。
…etc
メール編
問い合わせフォームを作成するということは、メールで通知したいということでもある。
Wordpressなどでもフォームに同梱されているので、一般的な機能。
1. SMTPを使う
SMTPサーバーを設定して、メールを送信する。
mb_send_mail()関数を使用しない。また、自作のpostfixなどを本番で利用しない。
事例として、不審なメールとしてMicrosoftにアドレスがBANされるという事象が発生したことがある。
2. SPF / DKIM / DMARCレコード
メールサーバーの設定で、SPF / DKIM / DMARCレコードを設定する。
これにより、メールがスパムと判定されるのを防ぐ。同上。
3. メールアドレスも取得したドメインに由来することを伝える
メールアドレスは自由になんでも使えるわけではないので、要件を立てるときにきちんと確認すること。
後々、example.comというサイトなのに「アドレスはnoreply@hogehoge.comでお願いします」という要望にあとで気付いて事故になることがある。
4. multipart/alternativeを使う
メールの本文は、テキストとHTMLの両方を送信する。
これにより、メールクライアントがどちらを表示するか選択できる。一部の古いメールクライアントにてスパム判定リスクがあるため、テキストとHTMLの両方を送信すると良い。
管理画面編
問い合わせをメールで管理していたが、件数も増えてきたので集計のために管理画面を作ってほしいと依頼を受けることもある。
大抵ほしい機能というのは皆同じ。
1. 一覧表示 / 検索 / 並び替え
問い合わせの一覧を表示する。
ユニークIDでの検索、日付のfrom-toでの検索、問い合わせタイプの絞り込みなどがあれば良い。
2. CSV出力
定番の機能。いま検索した結果をCSVでダウンロードできるようにする。
3. ページネーション機能
特に要件として指定されることは少ないが、後で気づきがち。
約20件くらいで1チャンクとし、「最初へ」「前へ」1, 2, 3, …10 「次へ」「最後へ」のような形にする。
4. 認証
軽い要件だとBasic認証でよいという声が多い。
IP制限を掛けてほしいといった場合、サブディレクトリ単位でIP制限を掛けるのは作りによっては難しい場合があるので注意。
こちらから提案できるのであれば、管理画面はadminのサブドメインを切った方がやりやすい。
外部API連携編
管理画面を作ってもらったけれど、よくよく考えたら自社のDBに接続してデータを流してほしいかも…！という声も多い。
APIの仕様はさまざまなので、この時点でフォームの項目を変えないといけないパターンもあり。
1. APIの切り替えフラグを作る
テスト環境と本番環境を分けるために、必ず切り替えられるフラグを定数で用意しておくべき。
環境が分かれているならキーを入れ替え。本番用しかない場合は、APIのON/OFF機能。
これによりテストのしやすさが10倍変わる。
2. 失敗時の処理
メール→管理画面への蓄積→APIへの送信という流れが想定されるが、どこかで失敗があった場合の処理を決めておく必要がある。
ユーザーにメールだけは返すようにするのか、行けるところまで行くのか、API連携を起点として全体をエラーハンドリングするのか。
なお失敗した場所がわかるように、必ずログは取るようにすること。
まだまだ色々と気を付けていたことがありそうだが、一旦このあたりで。何かあったら追記。
一枚モノのLPをぺろっと作ってほしい、の中には案外いっぱい要件が詰まっているということを覚えておきたい。