LP×Contact Form 7

Web制作の現場において、LP（ランディングページ）のフォーム実装は判断が分かれるポイントです。

今回のプロジェクトは「複数の採用LP」の制作。クライアントは外部ASPフォームと契約しておらず、メインのWordPress（以下WP）サイトで既にContact Form 7（以下CF7）が稼働している状況でした。

当初、ディレクターからは「管理が楽なように、既存のフォームをiframeで埋め込めないか」という相談を受けました。しかし、マークアップエンジニアの視点から検証した結果、検討の遡上に載せたのは「LPをPHP化し、WPシステムを直接ロードして埋め込む」手法です。

その技術的背景と、判断基準となる「サーバー環境」の考え方を整理します。

1. 「物理的に同じサーバー」であることの定義

この手法（wp-load.phpを読み込む方法）が採用できるかどうかは、ドメインの見え方ではなく、「ドメインルート（公開ディレクトリ）が同じサーバー内にあるか」という物理的な条件が鍵となります。

条件： WPがインストールされているディレクトリと、LPのディレクトリが同じサーバーの公開領域（public_html や www など）に含まれている。
物理階層のイメージ：
- public_html/（ドメインルート）
  - index.php（WPのコア）
  - wp-load.php（←これを読み込んでWPの機能を呼び出す）
  - lp/index.php（今回のLPをPHP化して配置）
理由： プログラムの実行パスが通っているため、LP側からWPのシステムを内部的に参照できるからです。

サーバーが異なる（物理的にファイルを参照できない）場合の手段が WP REST API です。これは「ファイルの中身をロードする」のではなく、「通信（API）」でデータをやり取りします。

ただし、この手法は現場のスキルセットによって工数やリスクが変動する点に注意が必要です。

API連携は、HTML/CSSを主体とするコーディング環境においては「専門外」の領域になりやすく、万が一「メールが届かない」などのトラブルが起きた際、原因がフロントか、バックエンドか、WPの設定かを特定できないリスクがあります。

「直接ロード」であれば、CF7の標準機能をそのまま活用するため、トラブルシューティングの透明性が高く、保守的な観点からも一つの選択肢となり得ます。

直接ロードを採用する場合、マークアップエンジニアはあらかじめ以下の「WP特有の挙動」をコントロールし、LPとしての品質を整えます。

自動改行（wpautop）の抑制: LP側に、意図しないタグ挿入によるデザイン崩れを防ぎます。
依存アセットの確実な発火: wp_head() 等を通じて、CF7の動作に必要なスクリプトを確実に読み込みます。
送信後の挙動制御: wpcf7mailsent イベントをフックし、送信完了後にサンクスページへ確実にリダイレクトさせることで、広告計測等の計測漏れを防ぎます。

「ASPを契約していない」「でもデザイン品質は落としたくない」といった制約がある中で、どのような実装がプロジェクトにとって最適か。

単に「できる・できない」の二択ではなく、ドメインルートやサーバー環境、そして運用フェーズでの保守性を考慮し、最適な実装形式をディレクターと共に探っていく。そうしたエンジニアの視点を共有することが、プロジェクトをより円滑に進めるための一助になるのではないでしょうか。