WordPressとReactの連携方法：ヘッドレス構成とテーマ組み込みの使い分け

「WordPress×React」で検索すると、フロントエンドを丸ごと分離するヘッドレス構成の記事と、既存テーマの一部にReactを差し込むテーマ組み込みの記事が入り混じって出てきます。この2つは目的も構築コストもまったく違うため、先に見分けないと「作ってはみたが運用が回らない」失敗に直結します。この記事では両アプローチの違いと選び方を先に示し、そのうえでWordPress REST APIとReactの具体的な連携手順、Next.jsなどフロントエンドの選定、ヘッドレス特有のSEO対策までを一次情報ベースで整理します。

まとめ：WordPressとReactの連携で先に決めること

• 2つのアプローチがある。フロントを完全分離する「ヘッドレス構成」と、既存テーマにReact部品を埋め込む「テーマ組み込み」。求める体験と運用体制で選ぶ。
• サイト全体をReactで作り替えたいならヘッドレス。特定ページや管理画面のUIだけ動的にしたいならテーマ組み込みで十分で、ヘッドレス化は過剰。
• データ連携はREST APIかWPGraphQLの二択。標準で使えるのはREST（/wp-json/wp/v2/）、取得を1リクエストに絞りたいならWPGraphQLプラグインを追加する。
• フロントは2026年時点でNext.jsが事実上の第一候補。かつて有力だったFrontityは2022年に積極的な開発を終了しており、新規採用は避ける。
• SPAのままだとSEOで不利。SSR/SSG/プリレンダリングでHTMLを返す構成にし、メタ情報とサイトマップをフロント側で再構築する必要がある。

WordPressとReactを組み合わせる2つのアプローチ

同じ「WordPress×React」でも、実装は大きく2系統に分かれます。検索結果の上位でも、ヘッドレスCMSとしてブログを作る解説と、既存テーマにReactを入れる解説が混在しています。最初にどちらを目指すかを決めることが、構成選定の出発点です。

アプローチ1：ヘッドレス構成（フロントエンドを分離する）

WordPressを管理画面・コンテンツ保管庫（バックエンド）だけに使い、表示側はReactで作った別アプリケーションが担う構成です。両者はREST APIまたはWPGraphQL経由でJSONをやり取りします。ページ遷移や表示速度をReact側で最適化でき、WordPressのPHPテーマは表示に使いません。反面、フロントエンドを別に構築・ホスティングするため、実装と運用の負担は最も大きくなります。サイト全体をReact/Next.jsで作り替える、複数チャネル（Web・アプリ）へ同じコンテンツを配信する、といった要件で選ぶ構成です。

アプローチ2：既存テーマにReactを組み込む

PHPテーマはそのまま使い、動きが必要な一部分だけをReactで描画する方法です。WordPressのブロックエディター（Gutenberg）自体がReactで作られており、カスタムブロックは@wordpress/scriptsを使ってReactで開発します。表示側の一部を動的にするだけなら、WordPress 6.5（2024年）で標準搭載されたInteractivity APIを使えば、フロントを分離せずにReactに近い宣言的なUIを実装できます。ViteやwebpackでReactコンポーネントをビルドし、特定テンプレートで読み込む手法もこの系統です。ヘッドレス化に比べて学習コストと運用負担が小さく、既存サイトを壊さずに段階導入できます。

どちらを選ぶか：表示比率で決める選定基準

判断は「表示側をどこまでReactに置き換えたいか」で決まります。トップから記事ページまで含めてサイト全体の表示体験を作り込みたい、あるいはWeb以外にも配信したいならヘッドレス構成。逆に、既存のWordPressサイトを維持したまま検索フォームや料金シミュレーターなど特定の動的パーツだけを足したい場合は、ヘッドレス化はコストに見合いません。まずテーマ組み込みで試し、React比率が上がってから分離を検討する順序が、失敗を避けやすい進め方です。

ヘッドレスWordPressとは：仕組みと従来型との違い

ヘッドレスWordPressは、コンテンツ管理と表示（ヘッド）を切り離した使い方を指します。従来型では1つのWordPressがコンテンツ保存とHTML生成の両方を担いますが、ヘッドレスではHTML生成を外部のフロントエンドに委ね、WordPressはAPIでデータを返すだけになります。CMSとしての違いをより広く比較したい場合はヘッドレスCMSと従来型CMSの大きな違いとは？も参照してください。

従来型WordPressとの構造的な違い

従来型はテーマ（PHP）とプラグインで見た目と機能を組み立て、サーバー側でHTMLを生成して返します。ヘッドレスではこのテーマ層を使わず、フロントエンドがAPIからJSONを取得して画面を組み立てます。この分離により、表示技術の選択がWordPressの制約から独立します。一方で、WordPressのテーマ・多くの表示系プラグイン（スライダー、フォーム表示など）はフロント側では機能しなくなり、同等の機能を自前で用意し直す必要があります。

ヘッドレス化が向くケース・向かないケース

向くのは、表示速度やUIをフロント側で作り込みたい大規模サイト、同じコンテンツをWebとモバイルアプリへ配信したいケース、フロントエンドのエンジニアが揃っているチームです。逆に、更新をWordPressの管理画面だけで完結させたい小規模サイトや、表示系プラグインに依存した運用には向きません。ヘッドレス化するとプレビューや「編集画面の見た目＝公開後の見た目」が崩れ、運用者の負担がむしろ増えることがあります。技術的なメリットだけで判断せず、更新する人の運用まで含めて決めるべき論点です。

WordPress REST APIでReactと連携する手順

ヘッドレス構成でもテーマ組み込みでも、データの受け渡しにはWordPress REST APIが基本になります。REST APIは投稿・固定ページ・カスタム投稿タイプ・メディアをJSONで返す標準機能で、追加インストールなしに/wp-json/wp/v2/配下で使えます。

エンドポイントの確認とデータ取得

公開済み投稿の一覧は/wp-json/wp/v2/postsで取得できます。?_embedを付けるとアイキャッチ画像や著者などの関連データも同時に返るため、React側での追加リクエストを減らせます。カスタム投稿タイプを返すには、登録時にshow_in_restをtrueにしておく必要があります。

// PHP: カスタム投稿タイプをREST APIに公開する
register_post_type("product", array(
  "public"       => true,
  "show_in_rest" => true,   // これが無いとAPIに出ない
  "rest_base"    => "products",
));

Reactからの取得と表示

React側はfetchやSWR、TanStack QueryでエンドポイントをたたきJSONを描画します。認証が不要な公開データの取得はこれだけで動きます。

import { useState, useEffect } from "react";

function Posts() {
  const [posts, setPosts] = useState([]);

  useEffect(() => {
    fetch("https://example.com/wp-json/wp/v2/posts?_embed")
      .then((res) => res.json())
      .then((data) => setPosts(data));
  }, []);

  return (
    <ul>
      {posts.map((post) => (
        <li key={post.id}>{post.title.rendered}</li>
      ))}
    </ul>
  );
}

export default Posts;

REST APIとWPGraphQLの使い分け

REST APIは標準で使える反面、必要なデータが複数エンドポイントに分かれ、リクエスト数が増えがちです。取得を1回にまとめたい、必要なフィールドだけ絞りたい場合は、プラグインWPGraphQLを追加してGraphQLで問い合わせる選択肢があります。WPGraphQLは内部にデータローダーを標準で備え、関連データをまとめて取得してクエリ数を抑えます。さらに別プラグインのWPGraphQL Smart Cacheを併用すると、永続化クエリとCDNキャッシュでレスポンスを高速化できます。小規模・標準構成ならRESTで十分、画面ごとに取得データが複雑ならWPGraphQL、という切り分けが実務的です。

query {
  posts(first: 10) {
    nodes {
      id
      title
      slug
      featuredImage { node { sourceUrl } }
    }
  }
}

ヘッドレスWordPress＋Reactのフレームワーク選び

ヘッドレス構成では、素のReact（Create React Appは非推奨となり、現在はViteで立ち上げるのが一般的）でも作れますが、SEOと表示速度を考えると、レンダリングを制御できるフレームワークを重ねるのが定石です。

Next.js：2026年時点の実質標準

ヘッドレスWordPressのフロントエンドは、2026年時点でNext.jsが最も広く使われます。App RouterでSSG（静的生成）・SSR（リクエスト時生成）・ISR（定期的な静的再生成）を用途ごとに使い分けられ、更新頻度の低い記事は静的化、動的なページはSSRといった配分が可能です。デプロイ先はVercelやNetlifyが一般的です。各方式の違いはNext.jsにおける主要なレンダリング方法の種類と概要で整理しています。

Astroなど他の選択肢

記事中心でJavaScriptの配信量を最小化したいサイトでは、必要な箇所だけをハイドレートするAstroも有力です。Reactコンポーネントをそのまま部分的に使えるため、WordPressをコンテンツ供給元にした静的サイトと相性が良い構成です。

Frontity・Faust.jsの現状（採用前に確認）

かつて「WordPress専用のReactフレームワーク」として使われたFrontityは、2022年に積極的な開発・メンテナンスを終了しており、開発チームはWordPress本体のInteractivity APIへ移行しました。新規プロジェクトでの採用は避けるべきです。WP Engineが提供するFaust.js（プレビューやルーティングの補助）も、2025年にNext.js専用から複数フレームワーク対応のアダプタへ全面的に作り直す方針が示され、位置づけが流動的です。採用するなら最新の開発状況を確認し、汎用的なNext.js＋WPGraphQL構成も併せて検討してください。「WordPress React フレームワーク」で見つかる古い記事はFrontity前提のものが多いため、公開日と対象バージョンを必ず確認してください。

ヘッドレスWordPressのSEO対策

ヘッドレス化そのものはSEOに有利でも不利でもなく、フロントエンドの作り方で決まります。クライアント側だけで描画するSPAのまま公開すると、検索エンジンにHTMLが渡らずインデックスが遅れたり欠けたりします。ここが従来型WordPressから移行する際の最大の落とし穴です。

SPAのSEO課題とSSR/SSG/プリレンダリング

対策の基本は、初期表示のHTMLをサーバー側で用意することです。Next.jsならSSRやSSGで、クロール時点で本文入りのHTMLを返します。既存のReactアプリを大きく変えたくない場合は、プリレンダリングでクローラー向けに静的HTMLを生成する方法もあります。React全般のインデックス対策はReact SEO対策とは？SSR・SSG・プリレンダリングの選び方と実装手順で詳しく扱っています。

メタ情報・サイトマップ・構造化データの引き継ぎ

従来型ではYoast SEOやRank Mathがtitle・meta description・OGP・サイトマップ・構造化データを自動出力しますが、ヘッドレスではこれらがフロント側に反映されません。WPGraphQLにはYoast/Rank Math連携の拡張があり、設定したメタ情報をAPIで取得してフロントの<head>に出力し直せます。サイトマップとcanonicalはフロントエンド側で生成する必要があり、WordPressが吐くサイトマップURLをそのまま使うと表示側ドメインと食い違う点に注意します。

導入時の課題と運用コスト

ヘッドレス構成は技術的な利点が語られがちですが、実際に効いてくるのは運用面の負担です。導入前に想定しておくべき課題を整理します。

プレビュー・編集体験の劣化と対処

ヘッドレスでは「公開前プレビュー」が標準では機能しません。WordPressの編集画面はPHPテーマの表示を前提にしているため、フロント側でプレビュー用のルートとトークン認証を別途実装する必要があります。Next.jsのDraft Mode（旧Preview Mode）を使うのが一般的で、この実装を省くと運用者が公開前に見た目を確認できず、更新が滞ります。

二重運用のコストと向かないケース

ヘッドレスはWordPress（バックエンド）とフロントエンドの2つを保守する構成になり、ホスティング費・監視・アップデート対応が二重になります。表示系プラグインの機能は自前実装に置き換わるため、開発工数も増えます。更新担当が非エンジニアで、管理画面だけで運用を完結させたい組織には向きません。SEOや速度が目的なら、まずキャッシュ・画像最適化・サーバー増強といった従来型の改善で足りないかを先に検証し、それでも不足する場合にヘッドレスを検討する順序が現実的です。

よくある質問

WordPressでヘッドレス化は可能ですか？

可能です。REST API（標準）またはWPGraphQL（プラグイン）でコンテンツをJSONとして取り出し、React/Next.jsなどのフロントエンドで表示します。WordPress本体の追加改造は不要で、カスタム投稿タイプを公開する場合のみshow_in_restの設定が必要です。

WordPressとReactの連携にPHPの知識は必要ですか？

ヘッドレス構成でもバックエンドはWordPress（PHP）のままなので、カスタム投稿タイプの登録やREST/GraphQLの拡張でPHPを触ります。ただし表示側はReact/JavaScriptで完結します。既存テーマにReactを組み込む方式では、テンプレート側のPHPを扱う場面がより多くなります。

REST APIとWPGraphQLはどちらを使うべきですか？

標準機能だけで済ませたい、構成が単純ならREST APIで十分です。画面ごとに必要なデータが複雑で、リクエスト数や転送量を抑えたい大規模サイトではWPGraphQLが有利です。プラグイン追加と学習コストが許容できるかで判断します。

ヘッドレスWordPressはSEOに不利ですか？

SPAのまま公開すると不利になりますが、SSRやSSGで初期HTMLを返せば従来型と同等以上にできます。加えて、メタ情報・サイトマップ・構造化データをフロント側で出力し直す実装が必須です。ここを省くとインデックスや検索表示で問題が出ます。

Frontityは今も使えますか？

2022年に積極的な開発が終了しており、新規採用は推奨されません。既存資産がなければ、2026年時点ではNext.js＋WPGraphQL（またはREST API）の構成が標準的な選択です。

関連記事

• React SEO対策とは？SSR・SSG・プリレンダリングの選び方と実装手順
• Next.jsにおける主要なレンダリング方法の種類と概要
• ヘッドレスCMSと従来型CMSの大きな違いとは？