2021年にさかのぼると、あるクライアントが私のもとに、それまで約40回は聞いたことのあるようなブリーフを持ってきました。「編集者が知っているWordPressバックエンドが欲しいが、サイトは高速である必要がある。本当に高速でね」彼らはVercelのマーケティングページでヘッドレスアーキテクチャについて何かを読んでいました。私が一言も言う前に、すでに売り込まれていました。私はそのプロジェクトを引き受け、WordPressのRESTAPIからコンテンツを取得するNext.jsフロントエンドをVercel上に構築し、本当に素晴らしいものを納品しました。Lighthouseのスコアは美しかったのです。クライアントは約3ヶ月間、それを気に入っていました。fast. Like, really fast." They'd read something about headless architecture on a Vercel marketing page. They were sold before I said a word. I took the project, built a Next.js frontend on Vercel pulling content from a WordPress REST API, and delivered something genuinely impressive. The Lighthouse scores were beautiful. The client loved it for about three months.
その後、マーケティングマネージャーがポップアップフォームを追加したいと言いました。その次はメンバーシッププラグイン。その次はライブチャットで、投稿カテゴリーに紐付けられた条件付きロジック。そして徐々に、静かに、全体のセットアップがうなり始めました。
そのプロジェクトは、どのチュートリアルよりもヘッドレスWordPressの実際の制限について多くのことを教えてくれました。ですから、正直な全体像をお伝えします。
「Vercel上のヘッドレスWordPress」が実際に意味するもの
人々がこの用語を曖昧に使っているため、ここで正確にしておく価値があります。
WordPress を実行している場合（通常は別のサーバー、Kinsta や WP Engine などのマネージドホスト、あるいは安い VPS 上）、それは純粋にコンテンツ管理システムとして機能します。テーマはフロントエンドを提供しません。代わりに、Next.js（または Nuxt、Astro、SvelteKit）アプリが WordPress REST API または WPGraphQL 経由でコンテンツを取得し、Vercel がそのフロントエンドをビルドしてデプロイします。Kinsta or WP Engine, or even a cheap VPS) purely as a content management system. No theme serves the frontend. Instead, your Next.js (or Nuxt, or Astro, or SvelteKit) app fetches content via the WordPress REST API or WPGraphQL, then Vercel builds and deploys that frontend.
Vercel は WordPress 自体をホストしていません。それが全てです。WordPress には PHP、データベース（MySQL）、サーバー側での実行が必要です。Vercel は Node.js のサーバーレス関数と静的ファイルを実行します。cPanel サーバーに WordPress をインストールするのと同じ方法で、Vercel に WordPress をデプロイすることはできません。
つまり、誰かが「Vercel で WordPress をホストする」と言うとき、彼らが実際に意味しているのは：Vercel でフロントエンドをホストし、WordPress は完全に別の場所で実行する、ということです。この区別は非常に重要であり、ブログ記事でこれがどのくらい頻繁に見落とされているかに驚きます。frontend on Vercel, while WordPress runs somewhere else entirely. That distinction matters enormously, and I'm shocked how often it gets glossed over in blog posts.
このセットアップが本当に輝く場面
ここで公平に言いたいのは、自分が出荷した headless WordPress + Vercel プロジェクトの中には本当に誇りに思っているものがあり、アーキテクチャがその複雑さに見合う特定の条件があります。
トラフィックが多い編集系メディアサイト
Seahawk は 2022 年にスポーツメディアパブリッシャー向けのプロジェクトを行いました。1日に数万ページビュー、12 人のコンテンツチーム、WordPress から絶対に離れたくない編集者たち。Incremental Static Regeneration（ISR）を 60 秒のリバリデーションウィンドウに設定した Next.js フロントエンドを Vercel 上に構築しました。大きな試合の日、オリジン WordPress サーバーはほとんど影響を受けませんでした。Vercel のエッジネットワークはスケーリングについての会話なしにトラフィックスパイクを吸収しました。
コンテンツがバッチ単位で変更されるサイト（記事は公開されるが、2 分ごとに編集されない）では、ISR は素晴らしいフィットです。エッジで静的ファイルのパフォーマンスを得つつ、合理的に新しいコンテンツが提供されます。
フロントエンドに極度の柔軟性が必要なサイト
デザイナーがカスタムスクロールアニメーション、複雑なコンポーネント遷移、またはページの途中に埋め込まれた React ベースの対話的ツールを望んでいる場合、従来の WordPress テーマはずっとあなたと戦っています。分離したフロントエンドはその制御を開発者に完全に返します。WordPress テーマの設計上の制約は単に消え去ります。
Node/Reactエコシステムに深く根ざしている開発チーム
チームが毎日Reactアプリをリリースしており、PHPを外国語のように扱っている場合、WordPressのテーマ開発を強制するのは本当に苦痛です。ヘッドレスなら、開発チームは自分たちの世界に留まりながら、コンテンツ編集者には既に知っているツールを提供できます。適切なチームであれば、これは本当の生産性向上です。
私が実際に使っているツールスタック
今日、ヘッドレスWordPress + Vercelを使う場合、スタックはこのような感じです:
- WordPressホスト: KinstaまたはCloudways。どちらも管理されたMySQLバックアップを何も考えずに処理します。 Kinsta or Cloudways. Both handle managed MySQL backups without me thinking about it.
- GraphQLレイヤー: WPGraphQLプラグイン。複雑なポストタイプに対して、REST APIよりもコンテンツクエリをはるかに簡潔にします。 WPGraphQL plugin. It makes content queries far cleaner than the REST API for complex post types.
- フロントエンドフレームワーク: Next.js。チームがApp Routerに対応していればApp Router、経験の少ない人への引き継ぎが必要ならPages Router。 Next.js. App Router if the team is comfortable with it, Pages Router if we need a faster handoff to someone less experienced.
- デプロイメント: Vercel。PRごとのプレビュープレイメントだけで導入の価値があります。 Vercel, obviously. Preview deployments per PR are worth the price of admission alone.
- オンデマンド再検証: WordPressウェブフック(カスタムプラグインまたはAdvanced Custom Fields hooks経由)がコンテンツ公開時にVercel再検証エンドポイントにping送信します。 WordPress webhooks (via a custom plugin or Advanced Custom Fields hooks) that ping a Vercel revalidation endpoint when content is published.
- プレビューコンテンツ: @wpengine/headlessパッケージ、またはエディターが再ビルドなしで未公開投稿をプレビューできるカスタムNext.jsドラフトモード設定。 The
@wpengine/headlesspackage or a custom Next.js draft mode setup so editors can preview unpublished posts without a rebuild.
プレビュー機能についてのポイント最後の1つは、正直に認めるのが気が進まないほど長い時間がかかった。編集者はWordPressで「プレビュー」を押して、本番環境に出るものと全く同じものを見ることを期待している。デカップルされたセットアップでは、それを正しく配線するのに丸一日の作業がかかる。
うまくいかない場所（そしてうまくいかなくなる）
よし。ここは君に正直にならないといけない。ほとんどの「headlessが未来」という記事がスキップしている部分だからだ。
プラグイン。本当にたくさんのプラグイン。
WordPressの力はプラグインエコシステムから来ている。WooCommerce、Gravity Forms、メンバーシップ プラグイン、予約システム、Yoastのような高度なSEOツール（はい、Yoastは相変わらず機能するが、メタタグのフロントエンドレンダリングには追加の配線が必要）、スライダープラグイン、フロントエンドに関わるもの何でも。従来のセットアップでは、プラグインはPHPをページに直接レンダリングする。ヘッドレスセットアップでは、フロントエンドコンポーネントを明示的に構築して出力を複製していない限り、何も表示されない。
2023年後半に1人のクライアントが僕のところに来た。プロジェクト途中での相談だった（Seahawk Mediaのプロジェクトではなく、他の誰かのごたごたを引き継いだもの）。彼らは良い意図でheadlessにしてから、WooCommerceを追加しようとした。その後4ヶ月間、Reactで カスタムカートとチェックアウトフローを構築し、WooCommerceのREST APIを呼び出し、Stripeウェブフックを手動で処理し、基本的にWooCommerceが既に構築していた車輪を再発明することになった。時間コストは、従来のWordPress + WooCommerceセットアップを使用した場合のおよそ3倍だった。
ヘッドレスWooCommerceは実現可能だ。WooCommerceはREST APIについて十分に文書化している。しかし「実現可能」と「価値がある」は別の質問だ。WooCommerce has documented their REST API well. But "doable" and "worth it" are different questions.
プレビュー体験は決して完全に一致しない
僕は今までにヘッドレスWordPressプロジェクトを6～7件納品しているが、プレビューワークフローに完全に満足したクライアントは一度もいない。WordPressで「プレビュー」を押すことと、実際にレンダリングされるものを見ることの間には常にギャップがある。ときにはドラフトモードのクッキーの問題。ときにはISRキャッシュのタイミング。従来のWordPressセットアップから来た編集者にとってそれは困惑させるものであり、不満は静かに、しかし執拗に来る。
2つのシステムを保守する
これは明らかに聞こえるかもしれませんが、チームを本当に困らせます。これで2つの独立したインフラストラクチャ上の懸念事項を管理することになります。WordPressサーバー（独自の更新、セキュリティパッチ、プラグインの競合、データベースバックアップを備えている）とVercelフロントエンド（独自のビルドパイプライン、環境変数、サーバーレス関数の制限を備えている）です。午前2時に何かが壊れたら、確認する場所は2倍になります。
Seahawkでは、WordPressプラグインが自動更新されてREST APIレスポンスの形状を静かに変更し、フロントエンドコンポーネントを壊したプロジェクトがありました。WordPressサイド側ではエラーは発生していません。ライブサイト上で単に静かなコンテンツギャップが発生しているだけです。その種の障害は、従来のWordPressエラーよりも本当にキャッチしづらいものです。
リアルタイムコンテンツは厄介
サイトのコンテンツが頻繁に変更される場合（ライブスコア、株価、ユーザー生成コメント、1分未満の鮮度が必要なもの）、ISRの再検証モデルは不向きです。古いデータを提供するか、リクエストのたびにWordPressバックエンドにヒットするかのいずれかになり、これはパフォーマンス上の議論の大部分を無効にします。
コスト：提案書に誰も記載しないもの
金銭と時間について具体的に説明します。なぜなら、これらのプロジェクトで不足入札をしている代理店を見たことがあるからです。
- 初期ビルドのオーバーヘッド：従来のWordPressビルドと比較して、同等の複雑性で少なくとも30～40%多くの開発時間を予算化してください。そのギャップは実際です。プロジェクト全体でそれを追跡してきました。 Budget at least 30-40% more development time compared to a traditional WordPress build of equivalent complexity. That gap is real. I've tracked it across projects.
- Vercelの価格設定：無料のHobbyプランは商用作業には不十分です。Proは1シート月額$20で、帯域幅とサーバーレス関数の実行コストはトラフィックの多いサイトで増加します。コミットする前に数字を実行してください。 The free Hobby plan won't cut it for commercial work. Pro is $20/month per seat, and bandwidth and serverless function execution costs stack up on high-traffic sites. Run the numbers before you commit.
- WordPressホスティング：まだ信頼できるマネージドホストが必要です。それはトラフィックに応じて月額$30～100の別途費用です。つまり、「安い静的ホスティング」というナラティブはすぐに崩壊します。 You still need a reliable managed host. That's another $30-100/month depending on traffic. So your "cheap static hosting" narrative falls apart quickly.
- 継続的なメンテナンス：2つのプラットフォーム、2つの潜在的な問題のセット。従来のマネージドWordPressセットアップと比較して、少なくとも月額保守料の20%多く考慮してください。 Two platforms, two sets of potential problems. Factor in at least 20% more monthly retainer time compared to a traditional managed WordPress setup.
実際に推奨できる場面
ここまでの説明を踏まえた上で、headless WordPress on Vercelがトレードオフに見合う具体的なシナリオを挙げます。
- サイトはコンテンツが充実しており読み込み中心である。主に記事やランディングページで、トランザクション的なフローではないcontent-heavy and read-heavy: mostly articles or landing pages, not transactional flows
- コンテンツチームが既にWordPressを理解していて、CMS切り替えを検討していないalready knows WordPress and won't entertain switching CMS
- パフォーマンスのスケーリングが本当のビジネス要件であり、単なる「あると良い」ものではない
- 開発チームがReactと最新のJavaScriptツーリングに対応できる
- 概要にプラグインの複雑な依存関係がない、もしくは明確にスコープから除外されている are in the brief, or you've explicitly scoped around them
- スタックの両面を理解している長期的な技術的所有者が配置されている
これらのシナリオでは反対意見を述べます。
- クライアントがWooCommerceやプラグイン依存のフロントエンド機能を求めている
- チームが小さく、2つのシステムの保守負荷を吸収できない
- エディターは高速で使い慣れたプレビューワークフローが必要だが、それを正しく構築する予算がない
- サイトがユーザーアカウント、動的パーソナライゼーション、またはリアルタイムデータ要件を持っている
- クライアントは「最新っぽいから」という理由だけで欲しい
その最後の理由。私はそれ以上に聞く機会が多い。
最初に検討する価値のある代替案
このスタックをデフォルトにする前に、少なくともこれらの選択肢を検討すべきだ：
- 適切なマネージドホスト上の従来型WordPress：Kinsta、Cloudways、またはRocket.netに適切なキャッシング（WP RocketまたはNginx FastCGI キャッシュ）を組み合わせれば、何も分離させずにLighthouse スコアを90点台で達成できる。分離型にしないとパフォーマンスが出ないと思い込んでいたクライアントが驚くことをよく見かける。 Kinsta, Cloudways, or Rocket.net with proper caching (WP Rocket or Nginx FastCGI cache) will get you Lighthouse scores in the 90s without decoupling anything. I've seen this surprise clients who assumed they needed to go headless just to be fast.
- Faust.js by WP Engine：ヘッドレスWordPressのために特別に構築されており、プレビューモード、認証、ルーティングなど、本来なら自分たちで構築する多くのボイラープレートを処理する。このアーキテクチャにコミットしているなら、一見の価値がある。 Built specifically for headless WordPress, it handles a lot of the boilerplate (preview mode, authentication, routing) that you'd otherwise build yourself. Worth a look if you're committed to the architecture.
- 専用のヘッドレスCMS：実際にはWordPressのプラグインエコシステムが不要な場合、SanityやContentfulのようなものは、Vercelホストの Next.js フロントエンドにとってより洗練されたフィットかもしれない。保守すべきPHPサーバーがまったくない。 If your team doesn't actually need WordPress's plugin ecosystem, something like Sanity or Contentful might just be a cleaner fit for a Vercel-hosted Next.js frontend. No PHP server to maintain at all.
よくある質問
よくある質問
WordPressを文字通りVercelにデプロイできますか？
いいえ。WordPressはPHPとMySQLデータベースが必要です。VercelのインフラストラクチャはNode.jsサーバーレス関数と静的ファイル配信を中心に構築されています。Next.js（または他のJavaScript）フロントエンドをVercelにデプロイして、そのフロントエンドが別の場所でホストされているWordPressインスタンスからコンテンツを取得することはできます。ただし、WordPress自体は別のサーバーで動作します。
ヘッドレスWordPressはSEOに悪影響を与えますか？
本質的には与えません。ただし、不注意にセットアップすると悪影響を与える可能性があります。Next.jsではサーバーサイドレンダリングと静的生成の両方が得られ、どちらも検索エンジンが問題なくインデックスできる完全にレンダリングされたHTMLを生成します。リスク領域はメタタグの処理（Yoastの出力をフロントエンドで明示的に取得してレンダリングする必要があります）とサイトマップ生成（WordPressから取得するNext.jsの動的サイトマップルートを構築したいでしょう）です。これらが正しければSEOは問題ありません。
Vercelの無料プランはヘッドレスWordPressフロントエンドで十分ですか？
個人プロジェクトやプロトタイプであれば、おそらく十分です。商用サイトの場合は違います。HobbyプランはVercelの利用規約で商用利用を禁止しており、実際のトラフィックがあるサイトではサーバーレス関数呼び出しの制限に達します。初日からProプランの予算を組んでください。
Next.jsでWordPressプレビューモードをどのように処理しますか？
Next.jsにはDraft Mode（Pages Routerの以前のPreview Mode）が組み込まれています。パターンは以下の通りです。Next.jsで/api/previewルートを作成してプレビュークッキーを設定し、WordPressの「プレビュー」ボタンがシークレットトークンを使用してそのルートを呼び出すように設定します。クッキーが存在する場合、ページコンポーネントはキャッシュされた静的バージョンではなくWordPressから直接下書きコンテンツを取得します。WPGraphQLはドラフト投稿クエリをネイティブにサポートしているため、このパターではREST APIよりもWPGraphQLを推奨しています。/api/preview route in Next.js that sets a preview cookie, then configure a WordPress "Preview" button to call that route with a secret token. When the cookie is present, your page components fetch draft content directly from WordPress instead of the cached static version. WPGraphQL supports draft post queries natively, which is why I prefer it over the REST API for this particular flow.
フォームやお問い合わせページについてはどうでしょう?
フォームはプラグインからヘッドレスへの移行の中でも比較的シンプルな部類です。Gravity Forms の送信は Gravity Forms REST API に直接ポストできます。もしくは WordPress フォームをスキップして、Netlify Forms (ただし Vercel を使用している場合はそちらになります) や、フロントエンド側での直接的な Formspree 統合を使用することもできます。正直なところ、フォームに関しては私は通常 Formspree を使って、午後のうちに完結させてしまいます。Formspree and call it done in an afternoon.
---
Vercel 上の Headless WordPress は、実在するユースケースを持つ実在するアーキテクチャです。銀の弾丸でもなければ、奇をてらった手法でもありません。これを最大限に活用しているチームは、何をトレードオフとしているか明確に理解した上で、余分なビルド時間に予算を確保し、解決すべき具体的なパフォーマンスか柔軟性の問題を持っていたチームです。それがあなたのプロジェクトに当てはまるなら、試す価値があります。当てはまらないなら、複雑さは避けた方が無難です。