ヘッドレスWordPress：導入する価値があるとき、無駄になるとき

要点

ヘッドレスWordPressとは、WordPressをコンテンツのデータベースとしてだけ使い、ページは別のフロントエンドから配信する構成です。ページビルダーと積み重なったプラグインでHTMLがすでに重くなっているコーポレートサイトなら、理にかなっています。効果は痛いところに具体的に効きます。訪問者は、アクセスのたびにPHPがページを組み立てるのを待つのではなく、完成済みのHTMLを受け取ります。コストも具体的です。デプロイが2つ、監視する環境が2つになり、編集担当者はレイアウトのドラッグ＆ドロップを失います。今、公開担当者がビルダーでセクションを丸ごと自分で変えているなら、ヘッドレスはその権限を開発側に移します。これは技術ではなく業務プロセスの判断です。ECストアにとって、ヘッドレスは間違った処方箋です。カタログ、カート、チェックアウトに必要なのは、追加のレイヤーではなくECプラットフォームです。問うべきは速くなるかどうかではなく、コンテンツのどれだけが毎週変わり、誰がそれを変えるのか、です。

1. ヘッドレスで実際に変わること

従来のWordPressでは、アクセスのたびにPHPが動き、データベースに問い合わせ、有効なプラグインのフィルターを実行し、HTMLを組み立てて返します。マークアップはテーマが決め、ページビルダーは独自の構造を差し込み、スクリプトやスタイルを登録するプラグインはすべてブラウザの読み込み待ちに加わります。公式の要件は、2026年9月16日に確認したWordPress.orgの要件ページによると、PHP 8.3以上、MariaDB 10.11以上（またはMySQL 8.0以上）、そしてHTTPSです。

ヘッドレス版でも、WordPressはPHPとデータベースで動き続けますが、一般の訪問者が直接アクセスすることはありません。WordPressはREST API（ドキュメントではブロックエディタの基盤と説明されています）でJSONを返すか、WPGraphQL経由でGraphQLを返します。サイトジェネレーター（Next.js、Astro、Nuxt）がビルド時にそのデータを取得し、完成したHTMLとCSSをCDNに公開します。

本当に変わるのは3つです。

• 訪問者のクリティカルパスが、PHP、データベース、プラグインの処理を通らなくなる。
• マークアップを書くのはビルダーではなく、フロントエンドを作る人になる。
• コンテンツの公開がページの公開と同じではなくなる。ビルドまたは再検証のステップが加わる。

変わらないこと：管理画面は存在し続け、アップデート、バックアップ、ログイン保護が引き続き必要です。ヘッドレスはセキュリティ対策ではありません。管理画面の露出が減るのは、トラフィックの入口でなくなるからにすぎません。

ドキュメントが明言している点

REST API Handbook自身がこう注意しています。「You do not need to use the REST API to build a WordPress theme or plugin.」ヘッドレスは選択肢であり、自然な進化ではありません。そうでないと言う人は、アーキテクチャを売り込んでいます。

2. 工事を正当化する（あるいは却下する）数字

アーキテクチャを変える前に、感覚ではなくフィールドデータを見てください。2026年9月16日に確認したChrome for Developersのドキュメントによると、CrUXはChromeの実ユーザーのデータを集めたもので、Google検索のページエクスペリエンス要因に使われています。PageSpeed Insightsなら、何もインストールせずに、公開されている任意のURLについてこのデータを確認できます。

落とし穴が2つあります。1つ目は、ドキュメント自身が述べているように、Lighthouseのスコアはラボ指標の加重平均で、重みはバージョンによって変わってきたことです。フィールドのLCPとINPではなくスコアを追いかけるのは、温度計を最適化するようなものです。2つ目は、すべてのサイトにCrUXのデータがあるわけではないことです。公式の手法では、ページが一般に発見可能で十分な訪問者がいることが条件で、iOS版Chrome、Android WebView、その他のChromium系ブラウザは除外されます。小規模なコーポレートサイトは、オリジン単位でしか表示されないか、まったく表示されないことがよくあります。

モバイルのフィールドLCPが2.5秒を大きく超え、レポートがレンダリングブロックとサードパーティのJavaScriptを指摘しているなら、配信の問題です。LCPが2.5秒以内で、不満が編集担当者にとって管理画面が遅いことなら、ヘッドレスでは何も解決しません。管理画面は同じままです。

3. ヘッドレスが本当に勝つ場面

切り替えが元を取れる3つのシナリオ：

重いページビルダーを使い、コンテンツがほとんど変わらないコーポレートサイト。 ランディングページ、サービスページ、チーム紹介ページ。HTMLを一度生成してCDNから配信すれば、PHP、データベース、ビルダーのJavaScriptの大半が訪問者の経路から消えます。

複数の場所に表示する必要があるコンテンツ。 同じ記事がサイト、アプリ、社内ダッシュボードに使われる場合です。ここではWordPressはAPIを持つコンテンツソースになり、それこそREST APIが作られた目的です。

テーマでは満たせない要件を持つフロントエンド。 状態を持つインターフェース、インスタント検索、自社システムとの連携。これをサードパーティのテーマの上に書くほうが、直接書くより高くつきます。

そして、ほぼ確実に無駄になるケースは、5ページのサイトで、トラフィックが少なく、1人がビルダーで編集している場合です。このときは、まともなホスティング、プラグインの整理、画像の圧縮、キャッシュで、プロセスを変えずに効果の大部分が得られます。

4. 本当のコスト：2つのデプロイと、マーケティングの手を離れるレイアウト

これは営業資料から消えがちな点です。ヘッドレスはツールを1つ増やすのではなく、システムを丸ごと1つ増やします。

環境が2つになります。WordPress（PHP、データベース、バックアップ、プラグイン）と、フロントエンド（ビルド、デプロイ、CDN、ログ）です。デプロイが壊れうる場所が2つ、認証情報のセットも2つ。サイトが落ちたとき、最初の問いは「どっちが？」になります。

2つ目のコストは組織的なものです。ビルダーなら、編集担当者は新しいセクションをドラッグして公開できます。ヘッドレスでは、誰かがフロントエンドに対応するブロックを作っていない限り、そのセクションは存在しません。既存のフィールド内のコンテンツは自由に変えられますが、新しいレイアウトは開発タスクになります。依頼のキューを持つチームなら許容できますが、金曜の夜にマーケティングが自分で公開する組織では耐えられません。

3つ目のコストは、テーマが無料でくれていたものを作り直すリストです。フォーム、検索、ページネーション、サイトマップ、SEOタグ、パンくずリスト、フィード、旧URLのリダイレクト、下書きのプレビュー。どれも単独なら難しくありません。まとめると数週間です。

5. コンテンツがフロントエンドに届く仕組み

公式の入口は2つあり、どちらを選ぶかで作業が変わります。

REST APIは標準で組み込まれています。JSONを返し、/wp-json/wp/v2/ で応答します。早い段階で気づく細部があります。2026年9月16日に確認したページネーションのドキュメントによると、per_page は1リクエストあたり100件が上限で、レスポンスには X-WP-Total と X-WP-TotalPages ヘッダーが含まれます。900件の記事があるサイトなら、ビルド時のリクエストは1回ではなく9回です。

curl -sI "https://exemplo.com.br/wp-json/wp/v2/posts?per_page=100" \
  | grep -i "x-wp-total"

もう1つの入口がWPGraphQLです。2026年9月16日に確認した公式ドキュメントによると、あらゆるWordPressサイトに拡張可能なGraphQLスキーマを提供する、無料のオープンソースのプラグインです。利点は、記事オブジェクト全体を受け取って半分捨てるのではなく、使うフィールドだけを要求できることです。

非公開のコンテンツ（下書き、プレビュー）の認証にはApplication Passwordsを使います。公式リファレンスによると、REST APIに専用のエンドポイントがあり、パスワードごとに last_used と last_ip を記録します。

遠回しにせず言うと、セキュリティのルールはこうです。アプリケーションパスワードは本番環境の認証情報です。ビルドの環境変数に置き、リポジトリにも、バージョン管理されたファイルにも、チケットにも決して貼りません。利用者ごとに個別のパスワードを発行し、1つを失効させてもほかが止まらないようにします。

6. サイト全体を再ビルドせずにコンテンツを公開する

編集担当者のもっともな不安は、読点ひとつ直すのに10分のビルドを待つことです。答えはインクリメンタルな再検証です。

Next.jsでは、ISRが静的ページを時間経過またはオンデマンドで再検証します。2026年9月16日に確認したバージョン16.3.5のドキュメントは、フル再ビルドなしでキャッシュを無効化する revalidatePath と revalidateTag を説明し、プロジェクトの設計を左右する3つの制限を挙げています。Node.jsランタイムでしか動かないこと、static exportでは動かないこと、複数のインスタンスを動かす場合はディスクキャッシュがインスタンスごとになり、共有のキャッシュハンドラーが必要になることです。

export const revalidate = 3600

同じドキュメントには、あとで揉めないための注意書きもあります。「revalidatePath invalidates the cache entries but regeneration happens on the next request.」つまり、編集担当者が公開するとキャッシュが古いものとしてマークされ、誰かがそのURLにアクセスしたときに新しいページが表示されます。確認するには、x-nextjs-cache ヘッダーが HIT、STALE、MISS、REVALIDATED のどれを返すかを見ます。

curl -sI https://seusite.com.br/blog/post | grep -i x-nextjs-cache

トリガーはWordPress側から出します。save_post のWebhookが、共有シークレットを付けてフロントエンドの再検証ルートを呼び出します。これがなければ、更新は設定した時間まで待つことになります。

Astroは、アダプターを使ったルートごとのオンデマンドレンダリングという別の方法で同じ問題を解決します。どちらを選ぶかよりも、運用上の問いに答えを出すことのほうが重要です。誰がボタンを押し、何分でページが変わるのか、です。

7. ECストアは別の問題で、答えはヘッドレスではない

ここで計算の性質が変わります。ストアには、在庫を持つカタログ、状態を持つカート、決済を伴うチェックアウト、送料計算、クーポン、請求書があります。WooCommerceの前にヘッドレスのフロントエンドを置いても、これらのどれも消えません。WooCommerceはすべて動かしたまま、同期を保つレイヤーがさらに1つ増えるだけです。

さらに悪いことに、ストアで一番つらいのはまさに動的な部分です。リアルタイム在庫の商品、カート、チェックアウトは静的ではありません。事前レンダリングしたHTMLの効果は、まさにお金が入ってくる場所で小さくなり、保守コストはそのまま残ります。

WooCommerceのセキュリティと保守の観点は、WooCommerceはまだ安全か？プラグイン、海賊版、スパム、そしてShopifyへ移行する理由で詳しく説明しています。ここで言いたいのはアーキテクチャの話です。ストアのヘッドレス化は、診断がプラットフォームの問題であるのに、症状に対処するために複雑さを足すことになります。パフォーマンスと保守に悩むストアは、チェックアウト、カタログ、CDNをベンダーが解決済みのホスティング型ECプラットフォームへ移るべきです。

正直に言えば例外もあります。専任チームを持ち、プラットフォームでは満たせないフロントエンドの要件がある大規模な運用です。その場合の議論は、ヘッドレスWordPressではなく、分離型のストアフロントについてになります。

8. アーキテクチャを変える前の安上がりな道

判断する前に、半日を診断に使ってください。順番に：

1. トップページと内部ページ2つでPageSpeed Insightsを実行し、モバイルとデスクトップの両方で、75パーセンタイルのフィールドLCPとINPを日付とともに記録する。フィールドデータがなければ、サイトはCrUXに載るだけの訪問量がなく、判断はラボデータだけに頼ることになる。
2. 有効なプラグインを一覧にし、過去90日間使っていないものに印をつける。1つ外すごとに、経路からスクリプトとクエリが消える。
3. PHPとデータベースを公式要件と照らし合わせる。PHP 8.3以上、MariaDB 10.11以上またはMySQL 8.0以上。
4. キャッシュ、圧縮、画像フォーマットを確認する。サイズ指定のない大きな画像は、LCPの悪化とレイアウトのずれのよくある原因。
5. そこで初めて問う。残った遅さは、アクセスのたびにPHPがページを組み立てていることから来ているのか、それともページが読み込むものの重さから来ているのか。

ページの重さが原因なら、ヘッドレスはほとんど何も変えません。同じJavaScriptと同じ画像が転送されるだけです。サーバーがページを組み立てていることが原因で、しかもコンテンツがあまり変わらないなら、そこで初めて検討する意味があります。

PHPを最新にし、ページキャッシュを入れ、画像を最適化したVPSなら、多くのケースをわずかなコストで解決できます。質の悪いホスティングを適切なものに替えるのは、週末で元に戻せます。アーキテクチャの変更は戻せません。

よくある質問

10ページのサイトにヘッドレスWordPressは見合いますか？

ほとんどの場合、見合いません。コンテンツがあまり動かない小さなサイトなら、適切なホスティング、プラグインの整理、キャッシュ、画像の最適化でほぼ同じ効果が得られ、デプロイを2つ抱える必要もありません。ヘッドレスが元を取れるのは、ページ数が多いとき、同じコンテンツを複数のチャネルで使うとき、あるいはテーマでは満たせない要件を持つフロントエンドがあるときです。

ヘッドレスにするとWordPressは安全になりますか？

露出は減りますが、リスクはなくなりません。管理画面は一般トラフィックの入口ではなくなりますが、オンラインのままで、アップデート、バックアップ、ログイン保護が引き続き必要です。Application Passwordsはパスワードごとに last_used と last_ip を記録するので、ほかの連携を止めずに1つだけ失効させられる点で役立ちます。

編集担当者はコンテンツを管理できなくなりますか？

コンテンツは管理できます。レイアウトは一部できなくなります。テキスト、画像、既存のフィールドは、いつもの管理画面で編集できます。公開担当者の手を離れるのは、ブロックをドラッグして新しいセクションを作ることです。それはフロントエンドのコンポーネント次第になります。マーケティングが毎週自分で新しいページを作っているなら、この摩擦こそ移行しない最大の理由です。

フルビルドを待たずに公開できますか？

できます。インクリメンタルな再検証を使います。Next.jsのISRは revalidatePath と revalidateTag で時間経過またはオンデマンドで再検証し、公式ドキュメントは、無効化によってキャッシュが古いものとしてマークされ、再生成は次のリクエストで行われると明記しています。制限も確認してください。Node.jsランタイムでしか動かず、static exportでは動かず、複数インスタンスではディスクキャッシュがインスタンスごとになります。

自分のWooCommerceストアにヘッドレスを使えますか？

技術的には可能ですが、実際には原因に手をつけずに複雑さを足すことになります。カート、チェックアウト、リアルタイム在庫は動的なので、事前レンダリングしたHTMLの効果はまさにストアが売上を上げる場所で小さくなり、背後ではWooCommerce全体が動き続けます。そうなると、議論すべきは追加のレイヤーではなくプラットフォームです。

まとめ

ヘッドレスはアップグレードではなくトレードオフです。コーポレートページの高速な配信を手に入れる代わりに、2つの環境、2つのデプロイ、そして公開担当者の手を離れるレイアウトで支払います。判断は2つの問いで決まり、PageSpeed Insightsのフィールドデータと編集担当者の日常業務で答えを出します。遅さの原因はサーバーがページを組み立てることか、ページが読み込むものの重さか。そして、誰かが自分で新しいセクションを作る必要があるのは週に何回か。ECストアの場合、答えはアーキテクチャ以前の問題です。進むべきはECプラットフォームで、その理由はWooCommerceはまだ安全か？プラグイン、海賊版、スパム、そしてShopifyへ移行する理由にまとめています。WordPressのコンテンツを自社のフロントエンド、アプリ、社内システムに流したいなら、それはオーダーメイドの連携（REST、GraphQL、再検証用Webhook、キュー）です。サイトの概要、URL、現在コンテンツを編集している人を、oailton.dev/ja/contato からお知らせください。