AI時代のWeb制作。バニラJS・jQuery・フレームワークの選定基準と事例

ウェブ制作の現場では、長らく「jQuery」が標準とされてきましたが、近年の「表示速度の重視」や「AIによるコード編集」の普及により、選定基準が大きく変化しています。

jQueryは依然として「基本」の立ち位置にあります。圧倒的な工期短縮、豊富なプラグイン、そして蓄積されたノウハウ。しかし、現代では「AI運用のしやすさ」や「大規模開発の秩序」など、目的に応じてバニラJSやフレームワークを使い分ける判断が求められています。

プロジェクトの目的と運用体制に合わせた、3つの典型的な選定事例を紹介します。

技術選定の比較一覧

AIは「指定なし」ならバニラJSで回答する

AIを使ってコードを生成する際、実は大きなポイントがあります。AIは特に指定がない限り、最も汎用性が高く確実な「バニラJS」でコードを書き出すという性質を持っている点です。

• プロンプトの手間が減る: 「Reactで書いて」「jQueryを前提にして」と毎回補足する必要がなく、素の指示だけでそのまま使えるコードが返ってきます。

• 精度の向上: AIにとって標準JSは学習量が最も多いため、ライブラリ固有のバグやバージョン違いによるエラーを起こしにくくなります。

この「AIの標準言語がバニラJSである」という事実は、パイプコーディング（繋ぎ込み）のスピードを劇的に高める見えないメリットとなります。

事例1：AIと共創する「機動力重視」のメディアサイト

選定：バニラJS (Vanilla JS)

• プロジェクトの背景

  納品後、クライアント自身がAI（CursorやChatGPT等）を活用して頻繁にABテストや機能追加を行いたい。

• なぜバニラか？

  AIがコードを生成する際、ReactやVueの独自ルール（State管理など）があると、生成コードをそのまま貼り付けても動かない「構文エラー」が多発します。標準規格のバニラJSであれば、AIが出したコードをそのまま「パイプ」のように繋ぎ込むことができ、クライアントの試行錯誤を邪魔しません。

• 勘所

  「納品して終わり」ではなく、クライアントが自ら育てていくサイトに最適。

事例2：スピードとコストを両立する「標準的」な企業サイト

選定：jQuery

• プロジェクトの背景

  予算・納期がタイトで、スライダーやアニメーションなど、一般的なリッチ表現を盛り込みたい。

• なぜjQueryか？

  世界中に膨大なプラグイン資産があるため、ゼロから開発する必要がありません。検証済みのパーツを組み合わせることで、開発工数を大幅に圧縮できます。また、多くのコーダーが扱えるため、jQueryなら「誰でも触れる」という安心感があります。

• 勘所

  「定額・短期間・定番の動き」が求められる、安定感重視のプロジェクトに最適。

事例3：多人数で開発し続ける「成長型」Webサービス

選定：モダンフレームワーク (React / Vue.js 等)

• プロジェクトの背景

  複数のエンジニアがチームで開発し、複雑なユーザー登録やマイページ機能などが存在する。

• なぜフレームワークか？

  「コンポーネント指向」により、コードの書き方を統一できるため、大人数で触ってもコードが複雑化しにくいのが特徴です。大規模なシステムにおいて、長期間の品質管理を可能にします。

• 勘所

  「サイト」というより「システム（アプリ）」に近い、構造的な秩序が必要な開発に最適。

選定を左右する「5つのチェックリスト」

どれを選ぶべきか迷った際は、以下の3点を確認してください。

1. AIのデフォルトを活かすか？
   プロンプトに細かな条件を付けなくても動く環境を渡したいなら、重要箇所は「バニラ」

2. 「誰が」保守するのか？
   制作会社に任せるなら「jQuery」。クライアント自身がAIで自走するなら「バニラ」。

3. 「何のために」動かすのか？
   リッチなプラグインを楽に導入したいなら「jQuery」。

4. システム規模は？
   1枚のLPや中小サイトなら「jQuery」。巨大なサービスなら「フレームワーク」。

5. 「いつまで」使うのか？
   10年単位の寿命を求めるなら、ライブラリの廃止に左右されない「バニラ」。

まとめ

「どれか一つ」に固執するのではなく、「jQueryの効率」「バニラの自由度」「フレームワークの秩序」を、プロジェクトの性質に合わせて部位ごとに最適化する。

技術のトレンドに流されるのではなく、「納品後のクライアントが、いかにストレスなくサイトを改善し続けられるか」。その運用体験（DX）までを見据えた技術選定こそが、これからの制作現場に必要だと思います。

Web制作の現場において、避けては通れないのが「老朽化したサーバーからの脱却」です。 先日、計10サイト（うち9サイトがWordPress）のサーバー移転と、それに伴う一斉アップデートを担当しました。

元々の環境は「PHP 5.x」「WordPress 4.x」というレガシーな構成。旧サーバーのアップデートが止まっていることへの不安や、バラバラだった管理の一元化が今回のミッションでした。

単なる「引っ越し」では済まない、技術的負債と向き合う現場でどのような選択をしたのか。その事例をご紹介します。

1. 「作り直し」ではないからこその、コードの取捨選択

今回の案件は、サイトを新しく作り直すリプレイスではありません。限られた予算とスケジュールの中で、「新しい環境でいかに安定して動かすか」がゴールです。

ここで重要になるのが、完璧を追い求めすぎないことでした。

• 古い関数の置換とプラグインの精査：最新のPHP環境では動かない古い関数を書き換え、開発が止まったプラグインは「代替プラグイン」へリプレイスするか、あるいは「最小限の改変」で動かすか。

• 表示と動作の維持：リプレイスなら新しく作るだけですが、既存の挙動を維持しながら環境だけを変える作業は、実はより細やかな調整を要します。

どこまでを修正範囲とするか。ディレクター様と予算を相談しながら、事象毎に対応策・改修案を検討・決定していきました。

「動かないから作り直しましょう」と突き放すのではなく、現状の資産を活かしながら着地させる。それが「調整力」の使い所だと考えています。

「どこまで直すか」の線引きと追加費用の考え方

移転作業を進めると、コードを開けてみて初めてわかる根深い不具合が見つかることもあります。その際、独断で進めたり、後から一方的に追加費用を請求したりはしません。

• 基本範囲：新サーバーで「現状の表示・動作」が再現できるまでの修復。

• 追加検討：大規模な仕様変更が必要な場合。例えば、「代替となるプラグインが存在せず、既存プラグインを大幅に改修する必要がある」「廃止するにしてもテーマ側の大規模な修正が不可欠」といったケースです。

想定以上の事象が発生するたびに、「この修正にはこれだけの工数がかかる」「今回はプラグインの改変で最小限に抑えるか、あるいは今後のために新調するか」をディレクター様と相談し、予算内で納得感のある着地点を検討・決定していきました。

2. 業務を止めない、一歩先を行く「メール移転」の工夫

Webサイトの表示以上に、クライアントの業務に直結するのがメールの問題です。10サイト分ともなると、その影響範囲は小さくありません。

今回は、切り替え時の混乱を最小限に抑えるため、以下のフローを徹底しました。

• 事前設定によるスムーズな移行：あらかじめ新サーバー側にアカウントを作成。さらに、メーラーには先回りしておいていただきました。これにより、切り替え後の「設定がわからない」というトラブルを回避しています。

• 予期せぬ外部ブロックへの迅速な対応：サーバー移転後、Hotmail（Outlook系）等の外部サービス側でメールがブロックされていました。これは事前に察知しきれない「地雷」の一つですが、発覚後すぐに対象サービスへのホワイトリスト追加依頼を働きかけるなど、トラブルを長引かせないための連携を重視しました。

3. 「丸投げ」から始まる、技術的なパートナーシップ

こうした複雑な移転案件において、制作会社のディレクター様が最も負担に感じるのは「どこに地雷が埋まっているか分からない」という不安ではないでしょうか。

私は、単に作業を請け負うだけでなく、以下のような「安心感」を提供することを大切にしています。

• リスクの事前洗い出し：移転前に環境を調査し、不具合が出そうな箇所をあらかじめ共有します。

• 予算に応じた柔軟な提案：全てを最新に書き換えるのがベストかもしれませんが、予算が合わないこともあります。その際「この方法なら安価に直せる」「ここはしっかり直すべき」といった、現実的な相談をさせていただきます。

検討材料の一つとして、いつでもご相談ください

「古い仕様のまま放置されているサイトがあるけれど、触るのが怖い」「サーバーをまとめたいが、メール周りの調整が不安」。

そんな課題があれば、ぜひ一度お声がけください。 押し付けの提案ではなく、プロジェクトの状況に寄り添った答えを一緒に見つけていければ幸いです。

納品後の制約を「改善」に変えた、イベントカレンダーの実装事例

Webサイトは公開して終わりではありません。運用が始まってから新たな制約が判明したり、さらなる使い勝手の向上が求められたりすることも多いものです。

今回は、当初「トップページへのカレンダー表示」と「個別記事の作成」という要件で納品した「FullCalendar」導入事例が、その後の環境変化を経て、いかにパフォーマンスを30％以上向上させるに至ったかをご紹介します。

背景：上位組織の仕組みと、デザインカンプの意図

本案件のスタートは、サイトのトップページにイベントカレンダーを配置し、各イベントの詳細を個別記事で管理するという要件でした。

そこには上位組織が運用しているイベントカレンダーの仕組みを参考にしたいという明確な意図がありました。しかし、実際に扱うデータ構造や記事のボリューム、さらにはサイトのルールが異なるため、そのままコピーすることは現実的ではありません。

そこで、ディレクターと打ち合わせを重ね、「どこまで共通化し、どこから独自設計にするか」の整合性を丁寧に調整しました。

特にこだわったのが、デザインカンプに描かれていた「カレンダー・モーダル・個別記事」による3層の導線設計です。カレンダー上のイベントをクリックした際、即座にページ遷移するのではなく、まずはモーダルで概要を表示。そこから「詳細記事へ」「関連情報へ」といった複数の導線を設けることで、ユーザーがページを移動することなく情報を取捨選択でき、必要に応じて深い階層へ進める自然な回遊を実現しました。

初期実装：スピードと柔軟性を優先したプラグイン活用と、見えてきた課題

当初の構築段階では、イベント情報の管理にカスタムフィールドプラグインを採用しました。

なぜ独自のプログラムを組まずにプラグインを選んだのか。それは、「限られた予算内で、将来的な要件変更に最も簡素かつ迅速に対応できるから」です。

開発初期において、最初からフルスクラッチの独自システムを構築することは、コストを押し上げるだけでなく、仕様変更のたびに追加費用が発生するリスクを孕みます。あえて柔軟性の高い構成をベースに据えることで、進行中の細かな調整や追加要望に対しても、予算の範囲内でロジックを崩さず、最小限のコストで打ち返せる状態を優先しました。

しかし、運用を進める中で、標準的なAJAX方式ゆえの課題も見えてきました。今回の要件ではカレンダーの表示タイプによって複数のJSONを出力する必要があり、データが重なるほどリクエストのオーバーヘッドが無視できなくなっていたのです。

「表示までに一瞬の『間』が空く」という状態は、UX（ユーザー体験）の観点からも改善の余地があると感じていました。

経緯：納品後の制約を「REST API化」による改善へ

無事に納品を完了し、運用が進んでいたある時、大きな状況の変化がありました。

クライアント側のセキュリティ方針が更新され、それまで使用していたカスタムフィールドプラグインは利用不可となったのです。

納品後のこの制約に対応するため、データ構造をプラグインに依存せず、テーマ内で完結する独自実装へと急遽シフトすることになりました。

この際、大きな強みとなったのが、すでに数ヶ月の運用を経て「フィールドの設計自体には問題がないこと」が証明されていた点です。運用実績に裏打ちされた完成度の高い設計をそのままコードへ落とし込むことができたため、移行は非常にスムーズでした。

幸いにもこの改修時には、予算的な余裕がありました。そこで、単なるプラグインの代替に留めるのではなく、前述の「JSON出力の重さ」を抜本的に解消すべく、システムを「WP REST API + FullCalendar」の構成へと刷新する提案を行いました。

成果：数値で現れた「30％以上」の速度改善

REST APIベースへの切り替えにより、カレンダーの挙動は劇的に進化しました。

• パフォーマンスの向上：インサイトデータ上で30％以上の高速化を確認。

• ストレスのない操作感：月を切り替える際の読み込み待ちがほぼ解消され、体感でも明らかに「軽くなった」と分かるレベルに。

制約をきっかけとした改修ではありましたが、予算というリソースを最大限に活かし、結果として「運用の継続性」を確保しつつ、サイト全体のユーザー体験（UX）を底上げすることができました。

制作のポイント

今回のプロジェクトにおいて、制作パートナーとして意識したポイントです。

• ディレクターとの整合性調整：上位組織の仕組みをリサーチした上で、ディレクターと「自サイトにとっての正解」を議論し、仕様を固めた。

• 「複数導線」を持つモーダルの実装：デザインカンプの意図を汲み取り、モーダル内に詳細記事や関連リンクを配置。ユーザーを迷わせない情報の厚みを構築。

• 納品後の変化への柔軟な対応：プラグイン利用不可などの予期せぬ制限に対し、単なる「修正」に留めず、パフォーマンス向上という付加価値を乗せて打ち返した。

• リソースに応じた技術提案：予算の余裕を「将来への投資」と捉え、REST API化によるデータ取得の最適化を提案・実行。

変化に寄り添い、現実的で「モアベター」な落としどころを探る

今回の事例は、最初から完璧な計画があったわけではなく、上位組織との調整や、納品後の制約、運用の変化に合わせて、その都度「モアベター」を選択し続けた結果です。

「既存の仕組みを参考にしたいが、そのままでは難しい」「特殊なUIを指定されているが、実装できるか」といった懸念は多いかと思います。

最初からフルスペックのシステムを組まなくても、まずは要件を満たし、状況に応じて中身をアップデートしていく。そんな柔軟な進め方も、一つの正解だと考えています。アイデア段階の「これ、どう実装するのがいいかな？」というご相談から、ぜひお気軽にお声がけください。

後記：なぜ「ベスト」ではなく「モアベター」なのか

今回の事例を通じて、改めて感じたことがあります。それは、予算や納期、予期せぬ制約が複雑に絡み合うWeb制作の現場において最初から「絶対的なベスト（最善）」を定義するのは、ある種の思考停止になりかねないということです。

開発のスタート時点では、クライアントの運用体制がどこまで固まっているか、将来的にどのような要件の変化があるか、すべてを見通すことはできません。

もし、初期段階で「これが最高の実装だ」と決め打ちして独自のガチガチなシステムを組んでいたら、納品後の「プラグイン利用不可」という急な制約変更に対応できず、多大な改修コストや工期が発生していたかもしれません。

• まずは要件を柔軟に満たせる構成でスタートする

• 運用を経て検証された設計をベースにする

• 変化に合わせて、その時点での最適解へアップデートする

この「その時々の状況におけるモアベター（より良い選択）」を積み重ねていくアプローチこそが、結果として「破綻しないシステム」と「納得感のある着地点」に繋がると考えています。

「完成図が見えきっていないけれど、まずは形にしたい」「運用しながら育てていきたい」といった、現実的な課題に向き合っている制作会社様。ぜひ、その時点での「モアベター」を一緒に探るパートナーとして、お力になれれば幸いです。

1. プロジェクトの背景と要件

今回の診断サイト制作では、以下の条件が求められました。

• 柔軟性： 診断ロジックや質問内容が未確定で、作りながらブラッシュアップしたい。

• 拡張性： 今回の仕組みをベースに、別なドメイン・別のサイトへ水平展開したい。

• 運用性： プログラムがわからなくても、HTMLや管理画面の操作だけで更新を完結させたい。

• 体験： ユーザーの離脱を防ぐため、画面遷移（URL遷移）なしでサクサク動かしたい。

2. 採用した解決策：ヘッドレスWordPress

これらを実現するために、WordPressを「サイトの器」としてではなく、「データの箱（API）」として使用する手法を採用しました。

構成のポイント

• バックエンド（管理画面）： WordPressのカスタム投稿とカスタムフィールドを活用。

• フロントエンド（表示側）： バニラJS（生のJavaScript）によるシングルページ構成。

3. 制作会社様にとっての「3つのメリット」

① 「プログラム不要」で中身をブラッシュアップ

質問文、選択肢、診断結果の数値、イラスト画像……。これらすべてをWordPressの管理画面から編集可能にしました。エンジニアにコード修正を依頼することなく、ディレクターやクライアント様の手で、公開直前まで内容を追い込むことができます。

② 「バニラJS」による高いメンテナンス性

クライアント様がAIを活用した「パイプコーディング」を運用していたことがわかったため、本プロジェクトではあえてバニラJSでの実装を選択しました。

ReactやVue.jsといったモダンなフレームワークは、構文ルールや複雑な依存関係が「パイプコーディング」の障壁となることが想像できます。バニラJSであれば、コンパイルも不要でAIの出したコードを直接反映できるため、クライアントのプロンプトに対応しやすいからです。

③ 「テーマを作らない」ことによるコスト最適化

今回は「ヘッドレス」という名の通り、WordPress側のテーマ制作は行っていません。 既存のテーマをホワイトアウトさせて「データの送受信」に特化させることで、見えない部分の作り込みをカット。その分、デザインの自由度やUIの向上にリソースを割くことが可能になりました。

4. エンジニアの目線：あえて「作り込みすぎない」

今回の設計で大切にしたのは、「エンジニアがいないと何もできない状態」を作らないことです。

• HTMLベースの組み込み： フロントエンド側は、特定のIDを振ったHTMLにJSを読み込ませるだけ。コーダーの方が、通常のサイト制作と同じ感覚でデザインを調整できます。

• 水平展開の容易さ： コア部分はREST APIで共通化されているため、別の診断を作る際も、WordPress側の設定をコピーするだけでスピーディに立ち上げが可能です。

制作ポイント

• フロントエンド： バニラJS（コンパイル不要、URL遷移なし）

• バックエンド： WordPress（REST API活用、カスタムフィールドで柔軟な編集）

• 拡張性： 質問の増減や、別ドメインへの水平展開も容易

• メリット： デザインの完全自由化 ＋ クライアント自身でのコンテンツ更新可能能力

こんな時にご相談ください

「ガチガチのシステム開発」にするほどではないけれど、「既存のプラグインでは自由度が足りない」。そんな案件に、今回のヘッドレスWP構成は非常に相性が良いです。

• 「中身が固まっていないけれど、とりあえず箱だけ作っておきたい」

• 「一つのシステムを使い回して、複数の診断ツールを量産したい」

• 「デザインにはこだわりたいが、運用の手間は最小限にしたい」

技術の押し付けではなく、プロジェクトの規模や予算に合わせた「最適な引き算」をご提案します。もし似たような課題をお持ちでしたら、まずは壁打ち相手としてお気軽にお声がけください。

Webhook を活用した商品情報の自動同期

サイトの新規制作において、「製品一覧ページを作りたい」「記事に関連商品情報を載せたい」というご要望をいただくことは少なくありません。

一見するとシンプルな要件ですが、エンジニアの視点で見ると、その先にある「日々の運用コスト」が大きな課題として浮かんできます。今回は、EC-CUBEとWordPressを連携させ、運用の手間とミスを劇的に減らした事例をご紹介します。

1. 「手動更新」に潜む、運用開始後のリスク

当初の要件は「製品一覧」と「関連商品の表示」のみで、機能面での細かな指定はありませんでした。しかし、そのまま最小構成（手動更新）で進めた場合、以下のようなリスクが予想されました。

• 情報のズレ： EC側で価格改定や在庫切れがあっても、ブランドサイト側の更新を忘れてしまう。

• 作業の二度手間： 同じ情報を2つの管理画面に入力しなければならない。

• ヒューマンエラー： 商品名やURLの打ち間違いが起きやすく、ブランド価値を損なう。

これらは、運用が始まってからクライアントの負担としてじわじわと効いてくる部分です。

2. なぜ「Webhook同期」が最適なのか？（他方式との比較）

連携方法にはいくつか種類がありますが、本プロジェクトでは「軽さ」と「情報の鮮度」を重視し、Webhookを活用した自動同期を採用しました。他の方式と比較すると、そのメリットが明確になります。

Webhookは、EC-CUBE側で商品が「登録・更新・削除」された瞬間だけWordPressに通知を飛ばす仕組みです。無駄な負荷をかけず、常に最新の状態を保つことができます。

3. 実装における「現場目線」のこだわり

単にデータを同期するだけでなく、制作会社やライターの方が「迷わず、安全に」使える工夫を施しました。

• 入力ミスを物理的に防ぐ： WordPress側に同期された商品データは「読み取り専用」に設定。運用者が誤って編集してしまい、EC側の情報と矛盾が生じる事態を防ぎます。

• 記事制作をスムーズに： 投稿画面では、同期済みの商品リストから選択するだけで関連商品を紐付けられるUIを構築。URLをコピペする手間をゼロにしました。

• 他チームとのスムーズな連携： EC側を別会社が担当している場合でも、エラー時の責任分界点（どちらのシステムの問題か）を明確にするログ設計を行い、ディレクター様の進行管理をサポートします。

4. 「やりすぎない」カスタマイズが、将来の柔軟性を生む

最初からフルシステムを組む必要はありません。

「まずは価格と在庫状況だけ同期させておき、将来的にレビューやキャンペーン情報も連携させる」といった、フェーズに合わせた拡張が可能です。ブランドサイトがECに依存しすぎない構造にしているため、将来的な仕様変更にも柔軟に対応できます。

制作パートナーとして、一歩先の「安心」を。

「こうした連携ができるなら、あの案件の提案に盛り込めるかも」

「技術的な話はわからないけれど、運用の手間を減らすアイデアが欲しい」

そんな段階でのご相談も大歓迎です。

ただ作るだけでなく、クライアントが長く、楽に使い続けられるサイトを、一緒に作り上げませんか。

Web制作において、コーディングは単に「デザインをブラウザに写す」作業ではありません。

単にデザインを再現するだけでなく、リリース後の「運用」と「成果」を見据えた土台作りです。

世の中にはデザインを切り貼りしただけの安価な「使い捨てLP」も存在しますが、私はマーケティング施策としての継続性を重視し、「テキスト再現」を軸とした丁寧な実装を大切にしています。

なぜ、丁寧に組み込むことが、結果としてプロジェクトの成功につながるのか。その理由と、判断基準を整理します。

1. 柔軟なリキッド制御

PCデザインを起点とするプロジェクトにおいて、単に画像を並べるのではなく、独自のCSS共通セットを活用したリキッドレイアウトを構築します。

• 可変サイズによる最適化: PCファーストの設計において、minmax() などを活用し、画面幅の変化に対してもレイアウトが破綻しないリキッドコーディングで「柔軟さと堅牢さ」を両立させます。

• ベストエフォート: Can I Use でブラウザの対応状況を常にチェックしつつ、その時々の最適な実装を選択。どんな環境でも「読み心地」が損なわれず、ユーザーの滞在時間を支える土台を作ります。

2. 継続的マーケティング施策としての「テキスト再現」

LPはリリースがゴールではなく、そこからABテストなどを繰り返し、成果を高めていく「資産」となります。

初期費用を極端に抑えた「画像主体」の制作は、一見安く済みますが、運用のスピード感を奪い、結果としてマーケティング機会の損失を招きます。私は、「リリース後の修正に無駄なデザイナー待ちを作らない」ことこそが、真のコストパフォーマンスだと考えています。

3. 実装の難易度と「画像逃げ」の境界線

「テキスト再現」には、画像切り貼りにはない高度なコーディングスキルが求められます。安価な案件で画像主体になりがちな背景には、コーダーのスキル不足という側面も無視できません。

• 「画像逃げ」による負債の発生: 複雑な重なりや特殊なレイアウトをCSSを制御できないコーダーは、安易にデザインを「一枚の画像」として書き出します。一見綺麗に見えますが、テキストとしての価値を失い、レスポンシブ時の微調整や文言修正が不可能な状態を招きます。

4. デザイン再現とコード品質のバランス

すべてを無理にCSSで組むことが正解ではありません。コンテンツの重要度に応じて、戦略的に「画像」と「テキスト」を使い分けています。

• テキストで組むべき箇所（徹底）：

  訴求の肝となるコピーや、頻繁に変更が予想されるコンテンツ。これらはSEOやアクセシビリティの観点からも、テキストとして正しく構造化します。

• 画像での妥協を認める箇所（最適化）：

  ブランドロゴや、CSSで再現しようとすると「同じテキストを何重にも記述する」コード肥大化などの弊害が出る複雑な装飾（多重シャドウ、特殊なグラデーションなど）。

  デザインツールの質感とWebの表示には微細な差が出ます。

  「デザインの質感を守るために画像にするか」「運用性とコードの綺麗さを優先してCSSにするか」。その判断を独断で進めるのではなく、ディレクターやデザイナーと相談しながら着地点を見つけます。

制作ポイント

• フロントエンド：テキスト再現 ＋ リキッドコーディング

• 運用最適化：デザイナー待ちを作らない高速なLPO

• 持続性：マーケティング資産としての品質

予算に合わせ、長期的な視点で「丁寧に組む」

私は、極端な低単価で「使い捨て」を前提とした案件には、十分な貢献が難しいと考えています。それは、結果としてクライアントに負債を残すことになると知っているからです。

ご予算に合わせつつも、自前のライブラリと設計思想をフル活用し、制作チームのハブとなり、一過性ではない「丁寧に組まれたLP」を形にしていく。そんなパートナーシップを大切にしています。

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のシステムを内部的に参照できるからです。

× 直接埋め込みが困難なケース

• 条件： URL上は同じドメイン配下に見えても、中身が「別サーバー」や「別契約のインスタンス」にある場合。

• 物理階層のイメージ：

  • サーバーA：WPが稼働

  • サーバーB：LP（静的ファイル）をアップロード

• 理由： 物理的に「家（サーバー）」が違うため、外部からPHPファイルを直接ロードして実行することはセキュリティ上制限されます。

2. もう一つの選択肢「WP REST API」との比較

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

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

現場視点での検討ポイント

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

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

3. 実装時にマークアップエンジニアが配慮すべき点

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

1. 自動改行（wpautop）の抑制: LP側に、意図しないタグ挿入によるデザイン崩れを防ぎます。

2. 依存アセットの確実な発火: wp_head() 等を通じて、CF7の動作に必要なスクリプトを確実に読み込みます。

3. 送信後の挙動制御: wpcf7mailsent イベントをフックし、送信完了後にサンクスページへ確実にリダイレクトさせることで、広告計測等の計測漏れを防ぎます。

制作ポイント

• フロントエンド：デザインの完全自由化と計測の最適化

• バックエンド：既存資産の「直接ロード」による有効活用

• 保守・運用：リスクを抑えた技術選定

• メリット：低コスト・高パフォーマンスの実装

状況に合わせた「実装の目利き」を

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

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