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制作において、コーディングは単に「デザインをブラウザに写す」作業ではありません。

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

世の中にはデザインを切り貼りしただけの安価な「使い捨て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を契約していない」「でもデザイン品質は落としたくない」といった制約がある中で、どのような実装がプロジェクトにとって最適か。

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