Next.jsで作るコーポレートサイト：問い合わせが増える理由と実装ポイント

WordPressから Next.jsへ移行したら問い合わせ数が増加した実案件を元に、高速表示・SEO・フォーム実装まで実践的なポイントを解説します。

こんな悩み、ありませんか？

コーポレートサイトをWordPressで運用しているけれど、「なんとなく表示が遅い気がする」「問い合わせが思ったより来ない」「プラグインの更新のたびにヒヤヒヤする」——そんな状況に心当たりはないでしょうか。

Webサイトはただ存在するだけでは意味がありません。訪問者が「この会社に頼みたい」と思い、実際に問い合わせボタンを押すまでの体験設計が、ビジネス成果に直結します。

Fivenineでも、長年WordPressでコーポレートサイトを構築してきた実績がありますが、ここ数年でNext.jsを採用するケースが増えています。理由は明快です。パフォーマンス・SEO・セキュリティの三点において、WordPressを大きく上回るケースが多いからです。

この記事では、実際のクライアント案件で得られた知見をベースに、「なぜNext.jsのコーポレートサイトは問い合わせが増えるのか」を技術的な根拠とともに解説します。WordPressからの移行を検討しているWeb担当者や、新規でサイト構築を考えているエンジニアの方に、具体的な実装イメージを持ってもらえれば幸いです。

なぜWordPressサイトは「問い合わせが来にくい」のか

WordPressはCMSとして優れたプラットフォームですが、コーポレートサイトとして長期運用すると、いくつかの構造的な問題が蓄積されていきます。

主な原因は3つです。

① 表示速度の問題　WordPressはリクエストのたびにPHPがDBに問い合わせてHTMLを生成します。キャッシュプラグインで改善できるものの、プラグイン同士の干渉やサーバースペックに依存するため、安定した高速表示を保ち続けるのは想像以上に手間がかかります。Googleの調査では、ページ読み込みが1秒から3秒に延びるだけでモバイルユーザーの直帰率が32%上昇するという数字も出ており、表示速度はそのままコンバージョンに影響します。

② セキュリティリスクの高さ　WordPressはシェアが大きいがゆえに攻撃の標的になりやすく、プラグインの脆弱性が定期的に発見されます。担当者が更新を怠ると、そのまま侵害されるリスクが常につきまといます。

③ コアウェブバイタル（CWV）のスコア低下　Googleが2021年以降、検索順位の指標として取り込んでいるCWV（LCP・CLS・FID）は、重いプラグインやサードパーティスクリプトが積み重なるWordPressサイトではスコアが下がりやすく、SEO上の不利につながります。

フロントエンド開発をお探しですか？

React・Vue・モダンなUI/UX開発をサポートします

無料で相談する

実案件ストーリー：製造業クライアントの問い合わせが1.6倍になるまで

神奈川県内の製造業クライアント（従業員50名規模）から「サイトはあるけど問い合わせが月に1〜2件しか来ない」というご相談をいただいたのは昨年のことです。既存サイトはWordPress製で、Lighthouseのパフォーマンススコアは42点、モバイルでのLCP（最大コンテンツ描画時間）は6秒超という状態でした。

まず原因分析を行ったところ、不要なプラグインが23個導入されており、トップページだけで12MBを超えるHTMLとスクリプトが読み込まれていました。ユーザーは技術的な背景など知る由もありませんが、「なんか重いな」という体験は確実に離脱を誘発していたはずです。

選択肢はリニューアルか改修かの二択でしたが、プラグイン依存が深く、テーマも高度にカスタマイズされていたため、部分改修よりもNext.js + ヘッドレスCMS（Contentful）による全面再構築を提案しました。コンテンツの更新頻度が低く（月1〜2回程度）、表示性能とSEOを最優先にすべき要件だったからです。

結果として、リニューアル3ヶ月後には月間問い合わせが平均3.2件に増加。Lighthouseスコアは98点、LCPは1.2秒まで改善しました。もちろんサイト構造やCTAの見直しも並走して行いましたが、表示速度の改善が離脱率低下に直接効いたという分析結果が出ています。

Next.jsコーポレートサイトの実装ポイント

1. Static Site Generation（SSG）でページを静的化する

コーポレートサイトはほとんどのページが更新頻度の低いコンテンツです。Next.jsのSSGを使えば、ビルド時にすべてのページをHTMLとして生成し、CDNから直接配信できます。DBもPHPも介さないため、WordPressとは根本的に速度の桁が違います。

// app/services/[slug]/page.tsx（App Router使用）
import { getServiceBySlug, getAllServiceSlugs } from '@/lib/contentful';

export async function generateStaticParams() {
  const slugs = await getAllServiceSlugs();
  return slugs.map((slug) => ({ slug }));
}

export default async function ServicePage({
  params,
}: {
  params: { slug: string };
}) {
  const service = await getServiceBySlug(params.slug);

  return (
    <main>
      <h1>{service.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: service.bodyHtml }} />
    </main>
  );
}

generateStaticParams によって全サービスページが静的生成されます。ヘッドレスCMSでコンテンツを更新した際は、WebhookでVercelの再ビルドをトリガーすれば自動反映されます。

2. 問い合わせフォームをAPI Routesで実装する

コンバージョンの要であるフォームは、Next.jsのApp Routerに備わるRoute Handlersで実装します。外部フォームサービスに依存しないため、デザインの自由度が高く、スパム対策もカスタマイズしやすいのが利点です。

// app/api/contact/route.ts
import { NextRequest, NextResponse } from 'next/server';
import { sendMail } from '@/lib/mailer';
import { z } from 'zod';

const contactSchema = z.object({
  name: z.string().min(1, '名前を入力してください'),
  email: z.string().email('正しいメールアドレスを入力してください'),
  message: z.string().min(10, '10文字以上でご入力ください'),
});

export async function POST(req: NextRequest) {
  const body = await req.json();
  const parsed = contactSchema.safeParse(body);

  if (!parsed.success) {
    return NextResponse.json(
      { errors: parsed.error.flatten().fieldErrors },
      { status: 400 }
    );
  }

  await sendMail({
    to: process.env.CONTACT_MAIL_TO!,
    subject: `【お問い合わせ】${parsed.data.name} 様より`,
    text: parsed.data.message,
  });

  return NextResponse.json({ success: true });
}

zod でサーバーサイドのバリデーションを行い、不正なデータの流入を防ぎます。メール送信には nodemailer + SendGridの組み合わせが実運用で安定しており、弊社でも標準採用しています。

3. メタデータとOGP設定を丁寧に行う

SEO観点で見落とされがちなのが、ページごとのmetadata設定です。Next.js 13以降のApp Routerでは、generateMetadata関数を使うことで動的なOGPタグ生成が簡単に実装できます。

// app/services/[slug]/page.tsx（続き）
import type { Metadata } from 'next';

export async function generateMetadata({
  params,
}: {
  params: { slug: string };
}): Promise<Metadata> {
  const service = await getServiceBySlug(params.slug);

  return {
    title: `${service.title} | 株式会社〇〇`,
    description: service.description,
    openGraph: {
      title: service.title,
      description: service.description,
      images: [{ url: service.ogImageUrl }],
    },
  };
}

SNSでシェアされた際に正しいOGP画像とタイトルが表示されるかどうかは、初回訪問者の印象を大きく左右します。WordPressではプラグイン任せになりがちなこの部分を、コードレベルで確実に制御できるのはNext.jsの強みです。

よくある失敗パターンと対処法

実際に移行案件を手がける中で、同じミスが繰り返されるのを何度も目にしてきました。事前に把握しておくだけで大きくつまずくリスクを減らせます。

`"use client"`をファイル先頭に書けばとりあえず動くため、慣れないうちは全ページに書きがちです。しかしClient ComponentはSEOに不利なケースがあり、バンドルサイズも増加します。**インタラクションが必要な箇所（フォーム・アニメーション）だけにClient Componentを閉じ込め、ページ全体はServer Componentで構成する**のが基本原則です。

コーポレートサイトは高品質な写真を多用しますが、通常の`<img>`タグを使うとLCPスコアが悪化します。`next/image`の`Image`コンポーネントを使えば、WebP変換・遅延読み込み・サイズ最適化が自動的に行われます。既存HTMLからの移行時に見落としやすい箇所なので、リリース前に必ずLighthouseで確認してください。

React Hook FormやZodによるフロント側バリデーションだけを実装して、API Routeのサーバー側バリデーションを省略するケースがあります。フロント処理はブラウザで書き換え可能なため、**サーバー側でも必ず同等のバリデーションを実装する**ことが不可欠です。先述のコード例ではこれを前提に設計しています。

Next.jsでは`NEXT_PUBLIC_`プレフィックスがついた環境変数はブラウザから参照可能になります。メールサービスのAPIキーやDB接続情報を誤って`NEXT_PUBLIC_`で定義すると、本番環境で情報漏洩につながります。サーバーのみで使う秘密情報はプレフィックスなしで定義し、Route HandlerやServer Componentの中だけで参照するよう徹底してください。

フロントエンド開発をお探しですか？

React・Vue・モダンなUI/UX開発をサポートします

無料で相談する

Web制作・UI改善もお任せください

フロントエンド開発

モダンな技術で、使いやすく美しいWebサイトを実現します

200件以上の制作実績顧客満足度97% 初回相談無料

サービス詳細 30秒で送信 — 無料で相談する

※ 通常1営業日以内にご返信します