WordPress をヘッドレス CMS として使う - REST / WPGraphQL・ACF 設計・Next.js / Astro 連携と判断基準

「WordPress をヘッドレス CMS にできますか？」と聞かれたら、答えは 「できる。ただし、やるべきかは別問題」です。

ヘッドレス化は単なる技術的なスイッチではなく、ページのレンダリング方法・デプロイ・運用フロー・長期コストを丸ごと作り変える決断になります。本記事では、WordPress をヘッドレス CMS として運用する全体像と、採用判断の現実的な基準を整理します。元ネタは ACF 公式ブログの解説記事ですが、実務で踏みやすいポイントを足して再構成しています。

ヘッドレス WordPress とは何か

従来の WordPress は、1 つのリクエストの中ですべてを処理します。

• PHP が MySQL にクエリを投げ
• テーマのテンプレートを読み込み
• HTML を組み立て
• 完成したページをブラウザに返す

ヘッドレス構成では、この責務が分割されます。WordPress はコンテンツと編集の基盤（バックエンド）に徹し、データを API 経由で公開。レンダリングは独立したフロントエンドアプリが担います。

3 層アーキテクチャ

ヘッドレス WordPress は、次の 3 層で構成されます。

各層を独立して開発・デプロイ・スケールできるのがヘッドレスの強みであり、同時に複雑さの源でもあります。

なぜヘッドレスにするのか（メリット）

分離することで得られるものは、主に「制御」と「再利用」です。

• フロントエンドの自由: WordPress テーマの制約から解放され、好きなフレームワーク・好きな設計で UI を組める
• エッジ最適化: 静的生成 + CDN 配信でパフォーマンスを追い込める
• マルチチャネル配信: 同じコンテンツを Web・モバイルアプリ・デジタルサイネージなど複数チャネルへ届けられる

実例として、Al Jazeera は複数 CMS を 1 つのヘッドレス WordPress スタック（GraphQL 層 + React フロント）に統合し、TechCrunch は REST API + デコープルドフロントでサイトを再構築しています。

レンダリング方式: SSG / SSR / ハイブリッド

レンダリングがフロントエンドに移ると、ページをどう生成するかを自分で決めることになります。

実運用ではこれらを組み合わせるのが普通です。安定ページは静的生成、頻繁に更新されるページは ISR / SSR、という使い分けになります。

REST API か WPGraphQL か

ヘッドレス WordPress で最初に悩むのが API 層の選択です。

REST API（標準搭載）

WordPress には REST API が標準搭載されています。/wp-json/wp/v2/ 配下に投稿・固定ページ・メディアなどのエンドポイントが用意され、プラグイン不要で使えます。

# 投稿一覧を取得
curl https://example.com/wp-json/wp/v2/posts
 
# 特定の投稿
curl https://example.com/wp-json/wp/v2/posts/123

シンプルなプロジェクトなら REST で十分です。

WPGraphQL（関連データが多いなら）

データモデルが関連的（ネスト・再利用コンポーネント・複雑なクエリ）になってくると、WPGraphQL が有利になります。/graphql という単一エンドポイントに対し、フロントが必要なフィールドだけを 1 クエリで取得できます。

query GetPost($slug: ID!) {
  post(id: $slug, idType: SLUG) {
    title
    content
    featuredImage {
      node { sourceUrl altText }
    }
    categories {
      nodes { name slug }
    }
  }
}

REST だと「投稿エンドポイント」と「カテゴリーエンドポイント」を別々に叩く必要がある場面でも、GraphQL なら1 リクエストにまとめられるのが大きな違いです。over-fetching（要らないフィールドまで返ってくる）・under-fetching（足りなくて追加リクエスト）の両方を避けられます。

迷ったら「小規模なら REST、コンテンツモデルが育つ見込みなら WPGraphQL」が目安です。

ACF でコンテンツをモデリングする

ヘッドレスの成否を分けるのが、このコンテンツモデリングです。従来構成では PHP テンプレートが表示を吸収してくれるので、多少ゆるい構造でも何とかなります。しかしヘッドレスでは、API がバックエンドとフロントエンドの「契約」になるため、構造の悪さが後工程すべてに波及します。

ACF が解決する問題

Advanced Custom Fields（ACF） を使うと、すべてを 1 つの WYSIWYG（リッチテキスト）フィールドに詰め込む代わりに、フロントエンドのコンポーネントに対応する構造化フィールドを定義できます。

• hero セクション、FAQ、統計ブロック、CTA …といった「見た目の塊」をフィールドとして定義
• フロントエンドは予測可能な API データを受け取れる
• WPGraphQL for ACF を使えば、型付き GraphQL スキーマの一部にもなる

フィールドの選び方

モデリングの原則

1. ドメインをモデル化: イベント・事例・チームメンバーなど実体ごとにカスタム投稿タイプを作り、分類はタクソノミーで
2. フィールドレベルで構造化: 「一定の形を持つセクション」は必ずモデル化する。リッチテキストに構造的コンテンツを押し込まない
3. Gutenberg の方針を最初に決める: ブロックを HTML としてレンダリングするのか、ACF フィールドに置き換えるのか、構造化ブロックを採用するのか。後付けにしない
4. API をプロダクトとして扱う: フロントが必要なフィールドだけを公開し、可視性を明示。ACF Local JSON でフィールドグループ定義をバージョン管理し、変更を追跡・デプロイ可能にする

ACF を API に出す設定

• REST の場合: フィールドグループ設定で「Show in REST API」を有効化すると、フィールドがレスポンスに含まれる
• GraphQL の場合: WPGraphQL 本体に加え、ブリッジプラグインの WPGraphQL for ACF を入れ、フィールドグループ設定で「Show in GraphQL」を有効化する

WPGraphQL for ACF を使うと、各 ACF フィールドグループが AcfFieldGroup インターフェースを実装する GraphQL オブジェクト型として公開され、フィールドグループが割り当てられた各ロケーション（投稿タイプ・タクソノミー等）には WithAcf* インターフェースが実装されます。これにより、フラグメントを使ってコンポーネント単位で必要なフィールドを再利用できます。

# WithAcf* インターフェースをフラグメントで対象にする例
query GetPageBlocks($id: ID!) {
  page(id: $id, idType: URI) {
    ...PageHeroFields
  }
}
 
fragment PageHeroFields on Page {
  pageHero {        # ACF フィールドグループ（show_in_graphql 済み）
    heading
    subheading
    backgroundImage { node { sourceUrl } }
  }
}

PHP / JSON でフィールドグループを登録する場合は、show_in_graphql => true と graphql_field_name の指定が必要です。なお WPGraphQL for ACF は WordPress.org リポジトリには無く、GitHub / Composer から導入します（v2.0 系へのアップグレードが推奨されています）。

フロントエンドフレームワークの選択

フレームワーク選びは「レンダリング要件・チームの知見・プレビューの重要度・目標とするパフォーマンス」の 4 軸で決まります。

WordPress 連携の実績とエコシステムを重視するなら Next.js、とにかく軽量・高速を狙うなら Astro、というのが 2026 年時点の鉄板です。

デプロイは「2 つのパイプライン」になる

ヘッドレス WordPress は、デプロイ対象が 2 系統に増えます。

• WordPress バックエンド: マネージド WordPress ホスティングで稼働
• フロントエンド: Vercel / Netlify / Cloudflare Pages などに別途デプロイ

それぞれに環境変数・ビルドプロセス・キャッシュ戦略が必要です。この分離が強力である一方、運用上のオーバーヘッドを生みます。WP Engine のようにバックエンドと Node.js フロントを一緒にホストするマネージドプラットフォームを使うと運用負荷は下げられますが、アーキテクチャ上の分離自体は残ります。

分離で「失われるもの」を補完する

ヘッドレス化で一番見落とされがちなのが、従来の WordPress が自動でやってくれていたことが消える点です。ここを埋める作業を計画に入れておかないと、ローンチ直前に慌てます。

SEO メタデータ

Yoast SEO などが生成するメタタグ・OGP・構造化データは、自動では出力されません。REST / GraphQL 経由で取得し、フロントエンドの <head> に自前で注入する必要があります。

サイトマップ・canonical・リダイレクト

sitemap.xml、canonical URL、リダイレクトも自動処理されなくなります。フロント側で再構築するか、プロキシする設計が要ります。

プレビュー

編集者が慣れた WordPress のプレビュー体験が失われます。Next.js の Draft Mode のようなフレームワークネイティブの仕組みや、Faust.js のようなツールキットで再構築します。ここを軽視すると編集者の体験が大きく劣化するので注意。

キャッシュとパージ

エッジ配信を効かせるなら、キャッシュヘッダー設計とパージが肝になります。投稿更新時に CDN / ISR をどう無効化するか（Webhook で再生成、revalidate、オンデマンド ISR など）を事前に決めておきます。このあたりは当ブログの CDN キャッシュ設計記事 も参考にしてください。

そもそもヘッドレスにすべきか

ここが本記事で一番大事なところです。問いは「ヘッドレスは優れているか？」ではなく、「自分のプロジェクトに、ヘッドレスでしか解けない具体的な課題があるか？」です。

左側に当てはまるなら、ヘッドレス WordPress は柔軟性・スケーラビリティ・制御をもたらします。右側なら、よく最適化された従来型 WordPress のほうが、はるかに少ない複雑さで同じ成果を出せます。

「流行っているから」「モダンだから」でヘッドレス化すると、2 つのデプロイ・プレビュー再構築・SEO 再実装・運用人員のコストだけが残る、というのは本当によくある失敗です。

専用ヘッドレス CMS との比較

「WordPress をヘッドレス化する」以外に、最初から API ファーストで設計された専用ヘッドレス CMS（Contentful / Sanity / Strapi など）という選択肢もあります。

既にWordPress に投資している・コンテンツ量が多い・移行案件ならヘッドレス WordPress がコスト効率的。完全に新規で、クリーンなモデリングとオムニチャネルを最優先するなら専用 CMS が有利、という整理になります。

導入ステップまとめ

最後に、ヘッドレス WordPress 構築の流れを 5 ステップで。

1. WordPress を立て、API 層を選ぶ: マネージドホストに WordPress を入れる。シンプルなら REST、関連データが多いなら WPGraphQL
2. コンテンツを API 向けにモデリング: カスタム投稿タイプ + ACF で構造化。Local JSON でバージョン管理
3. フロントエンドを選んで接続: Next.js / Astro などで API を叩いてレンダリング
4. 両システムをデプロイ: バックエンド（マネージド WP ホスト）とフロント（Vercel 等）を別々に。環境変数・キャッシュ戦略を個別に設計
5. 残りのピースを埋める: SEO メタ注入・サイトマップ・canonical・リダイレクト・プレビュー・キャッシュパージ

まとめ

• WordPress はヘッドレス CMS として使える。バックエンド / API 層 / フロントエンドの 3 層に分離する構成
• API 層は小規模なら REST、複雑なら WPGraphQL。GraphQL は必要なフィールドだけを単一クエリで取れるのが強み
• ヘッドレスの成否はコンテンツモデリングで決まる。ACF でフロントのコンポーネントに対応した構造化フィールドを設計し、Local JSON でバージョン管理する
• フロントは Next.js（エコシステム最大） か Astro（軽量高速） が有力
• SEO・サイトマップ・プレビュー・キャッシュパージは自動では付いてこない。分離で失われる機能の補完を必ず計画に入れる
• 最重要は採用判断。「ヘッドレスでしか解けない課題があるか」で決める。ブローシャーサイトや個人ブログなら、従来型のほうが安く速い

ヘッドレス WordPress は強力だが万能ではない道具です。高トラフィック・マルチチャネル・フロント完全制御という明確な動機があるときに、その複雑さが報われます。逆に言えば、その動機が無いなら、従来型 WordPress をきちんと最適化するほうがほとんどの場合は正解です。

参考リンク

• How to Set Up WordPress as a Headless CMS - ACF Blog
• WPGraphQL
• WPGraphQL for ACF
• WordPress REST API Handbook
• Advanced Custom Fields
• Faust.js