32blogby Studio Mitsu

WordPressからVercelに移行すべき理由

WordPressのセキュリティ・パフォーマンス問題をデータで検証し、Vercel + Next.jsへの移行メリット・コスト・注意点を解説する。

by omitsu17 min read
目次

WordPressからVercelに移行すべきか? プラグイン起因のセキュリティ脆弱性、遅いページ表示、終わらないメンテナンスに時間を取られているなら、答えはイエスだ。Vercel + Next.jsはプラグイン層を丸ごと排除し、グローバルCDNから事前ビルド済みページを配信する。サーバーサイドPHPの攻撃面がゼロになる。

WordPressは全Webサイトの42.6%で使われている(2026年3月時点)。だが「使われている」ことと「最適な選択」であることは違う。

プラグインの更新に追われ、速度改善のためにキャッシュプラグインを入れ、セキュリティのためにWAFプラグインを入れ——そのプラグイン自体が脆弱性の原因になる。この構造的な矛盾に気づいたとき、移行先の候補に上がるのがVercel + Next.jsだ。

この記事では、WordPressの問題点をデータで検証し、Vercel + Next.jsへの移行を判断するための材料を提供する。

WordPressが抱える構造的な問題

セキュリティ:プラグインという攻撃面

Patchstack の 2026年レポート によると、2025年に発見されたWordPressの脆弱性は 11,334件(前年比42%増)。1日あたり約31件のペースだ。

そのうち 91%がプラグインに起因 する。WordPress本体(コア)の脆弱性はわずか2件。つまり問題の本質はWordPress本体ではなく、エコシステムの構造にある。

さらに深刻なのは以下の点だ:

  • 46%が公開時点でパッチなし — 脆弱性が公開されてもプラグインが未修正のまま
  • 悪用された脆弱性の20%は6時間以内に攻撃開始 — 攻撃者の動きは速い
  • 高深刻度の脆弱性が倍増 — 2025年は1,966件、過去2年分の合計を上回る

2024年のデータ(7,966件、43%が認証なしで悪用可能)も十分深刻だったが、2025年はさらに加速している。プラグインを1つ追加するたびに攻撃面が広がり、平均的なWordPressサイトは20〜30個のプラグインを使っている。

パフォーマンス:プラグインが重ねるレイヤー

各プラグインがJavaScriptとCSSを追加する。問い合わせフォーム、スライダー、SEOツール、アナリティクス——積み重ねた結果、ページの読み込みが遅くなる。

Neodigit の計測データ によると:

指標WordPressNext.js
モバイル Lighthouse スコア51%86%
デスクトップ Lighthouse スコア97%100%
平均読み込み時間2〜4秒0.5〜1.5秒

速度を改善するためにキャッシュプラグインを入れる。そのプラグインが競合を起こす。別のプラグインで対処する——この連鎖がWordPressの構造的な問題だ。

メンテナンス:終わらない更新作業

WordPressの運用には3層の更新が必要だ:

  1. WordPress本体 のアップデート
  2. プラグイン のアップデート(20〜30個)
  3. テーマ のアップデート

プラグインを更新したら既存の機能が壊れた、という経験は珍しくない。更新しなければ脆弱性が放置される。どちらを選んでもリスクがある。

Vercel + Next.jsで何が変わるか

攻撃面がほぼゼロになる

Vercel + Next.jsで静的サイト(SSG)を構築すると、サーバーサイドにPHPが存在しない。SQLインジェクション、リモートコード実行、プラグイン経由の攻撃——これらの攻撃面が構造的に消える。

プラグインがないから、プラグインの脆弱性もない。

VercelのインフラにはDDoS緩和が組み込まれており、HTTPSも自動設定される。セキュリティのために別途プラグインを入れる必要がない。

CDNから直配信される速度

SSGで生成されたHTMLは、Vercelのグローバルエッジネットワークから直接配信される。PHPがリクエストのたびにHTMLを組み立てるWordPressとは根本的に仕組みが違う。

Next.jsの主な速度面のメリット:

  • 自動コード分割 — 必要なJavaScriptだけをロード
  • 画像の自動最適化 — WebP/AVIF変換、レスポンシブサイズ、遅延読み込み
  • プリフェッチ — リンク先のページを事前に読み込み

キャッシュプラグインで「速くする」のではなく、アーキテクチャとして速い。

GitHubにpushするだけでデプロイ

WordPressのデプロイは、FTPでファイルをアップロードするか、管理画面から操作するか、いずれにしても手動だ。

Vercelでは:

  1. コードをGitHubにpush
  2. Vercelが自動でビルド・デプロイ
  3. 数十秒〜2分で本番に反映

PRを作ればプレビューURLが自動生成される。問題があれば1クリックでロールバックできる。プラグインの更新で壊れたときのような「元に戻せない」恐怖がない。

コストを比較する

月額コスト

環境月額
さくらのレンタルサーバー スタンダード約425円〜
Xserver スタンダード約990円〜
ConoHa WING ベーシック約1,452円〜
Vercel Hobby無料
Vercel Pro$20(約3,000円)

個人ブログなら Vercel Hobbyプラン(無料) で十分だ。100 GBのデータ転送、グローバルCDN、自動HTTPSが含まれる。

見えにくいWordPressのコスト

WordPressのホスティング費用は安く見えるが、実際にはプラグイン費用が加算される:

  • WP Rocket(キャッシュ): 約$59/年
  • Wordfence Premium(セキュリティ): 約$149/年
  • UpdraftPlus Premium(バックアップ): 約$70/年
  • 有料テーマ: $50〜$200(買い切り)

すべて無料プラグインで代用できるが、無料版は機能制限があり、サポートも限定的。結局、まともに運用しようとすると年間$200〜$400のプラグイン費用がかかる。

Vercelではこれらの機能がインフラに組み込まれている。キャッシュはCDNが担い、セキュリティはプラットフォームレベルで提供され、デプロイのたびにバックアップ相当のスナップショットが残る。

移行すべきでないケース

公平に言おう。Vercel + Next.jsへの移行が 向いていないケース もある。

コードを書きたくない場合

Next.jsはReactベースのフレームワークだ。HTML/CSS/JavaScriptの知識が前提になる。WordPressの管理画面のように、GUIだけでサイトを構築・更新することはできない。

非技術者がコンテンツを更新する必要があるなら、ヘッドレスCMS(ContentfulSanitymicroCMSPayload 等)を組み合わせる必要がある。これは追加の学習コストと、場合によっては追加費用を意味する。

動的機能が多い場合

WordPressのプラグインで実現している以下の機能は、自分で実装するか外部サービスに置き換える必要がある:

  • コメント → Giscus / Disqus
  • お問い合わせフォーム → Resend / SendGrid + Server Actions
  • サイト内検索 → Algolia / Fuse.js
  • 会員管理 → Clerk / Auth.js
  • EC機能 → Shopify Headless / Stripe

プラグインを入れれば数分で使える機能を、一から構築することになる。動的機能が多いサイトほど移行コストは高くなる。

既存のWordPressで問題がない場合

「別に困っていない」なら移行する理由がない。WordPressは43%のWebサイトで使われている実績があり、コミュニティも巨大だ。現状のサイトがCore Web Vitalsを満たし、セキュリティ対策も十分で、メンテナンスが苦にならないなら、わざわざリスクを取って移行する必要はない。

移行の全体像

移行を決めた場合の大まかなステップを示す。

1. コンテンツのエクスポート

WordPressの管理画面から ツール → エクスポート でXMLファイルをダウンロードする。記事本文、カテゴリ、タグ、公開日などのメタデータが含まれる。画像は別途ダウンロードが必要だ。

2. コンテンツ形式の変換

WordPressのHTMLコンテンツをMarkdown(またはMDX)に変換する。手動でも可能だが、記事数が多い場合は変換スクリプトを書くのが現実的だ。

3. Next.jsプロジェクトの構築

Next.jsでサイトを構築する。ゼロから作る必要はなく、ブログ用のスターターテンプレートが多数公開されている。

4. リダイレクトの設定

これが最も重要なステップだ。 URLが変わるとGoogleのインデックスが無効になり、検索順位が下がる。

next.config.ts で旧URLから新URLへのリダイレクトを設定する:

ts
const nextConfig = {
  async redirects() {
    return [
      {
        source: "/2025/01/my-old-post/",
        destination: "/blog/my-old-post",
        permanent: true,
      },
    ];
  },
};

export default nextConfig;

すべての旧URLに対して301リダイレクトを設定すること。1つでも漏れると、そのページの検索トラフィックを失う。

5. Vercelにデプロイ

GitHubリポジトリをVercelに接続すれば、自動デプロイが始まる。DNS設定でカスタムドメインを向ければ移行完了だ。

FAQ

WordPressからNext.jsへの移行にどれくらいかかる?

サイトの複雑さによる。50〜100記事程度のシンプルなブログなら週末で移行できる。カスタムプラグイン、EC機能、会員機能があるサイトは数週間かかることもある。コンテンツの変換自体は単純で、時間がかかるのは動的機能の再構築とリダイレクトのテストだ。

移行後にSEO順位は下がる?

301リダイレクトを全URLに正しく設定すれば下がらない。Googleは301を恒久的な移転として扱い、ランキングシグナルを引き継ぐ。2〜4週間は変動があるが、Google Search Consoleで毎日モニタリングすれば問題は早期に発見できる。

WordPressをヘッドレスCMSとしてNext.jsと組み合わせられる?

できる。WordPress REST APIWPGraphQLプラグインでコンテンツを取得し、Next.jsでレンダリングする。既存の編集ワークフローを維持しつつ、フロントエンドのパフォーマンスを改善できる。大手メディアでもこのパターンは使われている。

Vercelの無料Hobbyプランで本当に足りる?

個人的な非商用ブログなら十分だ。100 GB帯域幅、グローバルCDN、自動HTTPS、プレビューデプロイが含まれる。広告やアフィリエイトなどで収益が発生するサイトはProプラン($20/月)が必要になる。

コメント・お問い合わせフォーム・検索はどうする?

外部サービスか自前実装になる。コメントはGiscus(GitHub Discussions連携)が定番。お問い合わせフォームはResendSendGrid + Next.js Server Actionsで実装できる。検索は小規模ならFuse.js、大規模ならAlgoliaがある。

Next.jsの画像最適化はWordPressと比べてどう?

WordPressはShortPixelやImagifyなどのプラグインに依存する。Next.jsには組み込みの<Image>コンポーネントがあり、WebP/AVIF変換、レスポンシブサイズ生成、遅延読み込みをプラグインなしで自動処理する。Vercel上なら画像最適化はプラットフォームに含まれている。

Next.jsはWordPressよりメンテナンスが大変?

メンテナンスの種類が違う。WordPressはプラグインとコアの更新が常に必要で、1つスキップすれば脆弱性のリスクがある。Next.jsは動く部品が少ない — コード、依存関係(package.jsonで管理)、フレームワーク本体だけだ。プラグインの競合もテーマの破損もない。代わりに、機能拡張にはプラグインではなくコードを書く必要がある。

まとめ

この記事で検証したこと:

  • セキュリティ: WordPressの脆弱性は年間約8,000件、96%がプラグイン由来。Vercelは攻撃面が構造的に小さい
  • パフォーマンス: WordPress平均2〜4秒 vs Next.js 0.5〜1.5秒。CDN直配信のアーキテクチャ差
  • コスト: Vercel Hobbyプランなら無料。WordPressの隠れたプラグイン費用にも注意
  • 移行すべきでないケース: コードを書かない人、動的機能が多いサイト、現状で問題がないサイト
  • 移行手順: エクスポート → 変換 → 構築 → リダイレクト設定 → デプロイ

WordPressが悪いわけではない。43%のWebサイトを支えている実績は本物だ。ただ、プラグインを積み重ねて速度とセキュリティを維持する構造に限界を感じているなら、Vercel + Next.jsは検討する価値がある。

Vercel Proに移行する場合はSpend Managementの正しい設定を最初にやっておくこと。従量課金の仕組みを理解せずに使うと予想外の請求が来る。VPSへのセルフホストも選択肢に入るならCoolify + VPSでNext.jsをセルフホストする全手順も参考になる。

公式リソース:

関連記事: