Headless CMS

ヘッドレス CMS 構築|Next.js × WordPress で速く安全なサイトを

編集は WordPress のまま。表示は静的ファイルで、速く、落ちない。

ヘッドレス CMS 構築は、WordPress を「編集するための道具」に専念させ、表示側を Next.js で作り直してビルド時に全ページを静的な HTML にする構成です。向き不向きは先に書きます。当てはまらない場合は通常の WordPress 制作をご提案します。andcre.com 自体がこの構成(Next.js 15 + WPGraphQL + Cloudflare Pages)で動いており、以下の構成図・コード・計測値はすべてこのサイトから起こしたものです。地域を問わず、オンラインで全国から承ります。

ヘッドレス CMS とは ― 編集画面と表示を分ける構成

通常の WordPress サイトでは、WordPress が「編集」と「表示」の両方を担います。訪問者がページを開くたびに、WordPress がデータベースを読み、テーマの PHP で HTML を組み立てて返します。ヘッドレス CMS 構成では、この「表示」の役割を WordPress から切り離します。WordPress は記事や制作実績を編集・保管する場所(ヘッド = 見た目を持たない CMS)になり、表示は別のアプリケーション ―― このサイトでは Next.js ―― が担当します。

Next.js はビルド時に WordPress から WPGraphQL でデータを取り出し、全ページを HTML ファイルとして書き出します。訪問者に届くのはその静的ファイルで、WordPress には訪問者からのアクセスが届きません。 ページの表示に PHP の実行もデータベースの読み取りも発生しないため、速く、アクセス集中や CMS 側の障害の影響を受けにくくなります。

一方で、公開までに「ビルドして配信先に置く」工程が挟まること、表示側は WordPress のテーマやプラグインではなくコードで作ることになるため、すべてのサイトに向くわけではありません。向き不向きを先に整理します。

向いている案件・向かない案件

向いている

  • 表示速度と安定性を優先したいコーポレートサイト・採用サイト

    静的ファイルの配信なので、アクセス集中や WordPress 側の障害の影響を受けにくい

  • 編集者は WordPress に慣れていて、管理画面を変えたくない

    編集体験はそのまま。変わるのは表示側だけ

  • デザインや機能を制作会社に依存せず、長く育てたい

    表示側は TypeScript のコードとして管理でき、テストと CI で回帰を防げる

  • セキュリティ要件が厳しい(公開サイトから CMS を隠したい)

    訪問者が触るのは静的ファイルと限定された API だけ

向いていない

  • WordPress のプラグインで見た目や機能を頻繁に足したい

    表示側は Next.js なので、プラグインの表示機能はそのままでは使えない

  • 更新の即時反映が最優先(分単位)

    公開までにビルドとデプロイが挟まる。このサイトでは CI とローカルのどちらからもデプロイできるが、数分は要する

  • 予算が限られ、5 ページ程度の一般的な構成で十分

    通常の WordPress 制作の方が開発量が少ない。見積例(5 ページ・336,000 円)の範囲で収まる

  • サーバーやドメインの管理を 1 社にまとめたい

    CMS のサーバーと配信先(Cloudflare)の 2 系統を管理する

「向いていない」に当てはまる場合は、通常の WordPress 制作をご提案します。制作の流れと費用の決まり方はホームページ制作サービスにまとめています。

実証事例: このサイト自体がヘッドレス構成で動いています

ご覧いただいているこのサイトが、ヘッドレス CMS 構成の実例です。構成図と各要素の役割は、このサイトのソースコードとアーキテクチャ資料(docs/CODEMAPS)から起こしています。
andcre.com の構成: 編集者 → WordPress → Next.js ビルド → Cloudflare Pages → 訪問者。動的処理は Cloudflare Workers と Workers AI編集者WordPress 管理画面WordPress(api.andcre.com)投稿 / 制作実績 CPT / RAG コンテキストWPGraphQL + REST APIContact Form 7訪問者から直接は見えないNext.js 15 ビルドRepository → Service → PagegenerateStaticParams全ページを HTML に書き出しGitHub Actions / ローカルCloudflare Pages静的ファイル(dist/)CDN から配信_worker.js(/api/*)訪問者ブラウザ / 検索エンジンCloudflare Workers AIGLM-4.7-Flash + AI Gateway投稿GraphQLdeployHTML / 画像/api/chatRAG(REST)お問い合わせ: 訪問者 → /api/contact(Workers)→ Contact Form 7(WordPress REST)。Turnstile で検証
andcre.com の構成。編集者は WordPress で書き、ビルドで全ページを静的な HTML にしてから Cloudflare Pages が配信します。フォームと AI チャットだけを Cloudflare Workers が処理します(出典: このサイトのコードとアーキテクチャ資料)。
  • 編集者は WordPress(api.andcre.com)の管理画面で投稿・制作実績・AI 用コンテキストを編集する
  • Next.js 15 のビルドが WPGraphQL で取得し、Repository → Service → Page の順で全ページを HTML に書き出す
  • Cloudflare Pages が静的ファイルを CDN から訪問者に配信する。WordPress は訪問者から直接見えない
  • お問い合わせと AI チャットは Cloudflare Workers の /api/* が処理し、AI は Workers AI(GLM-4.7-Flash)が回答する

WordPress は編集だけ、表示は Next.js、配信は Cloudflare

andcre.com の構成要素と役割
技術役割
編集(CMS)WordPress + WPGraphQL投稿・制作実績・AI チャット用コンテキストを管理。編集者はこれまでどおり WordPress の管理画面を使う
取得WPGraphQL(+ Offset Pagination)/ REST APIビルド時に GraphQL で本文・一覧・更新日を取得。お問い合わせ(Contact Form 7)と AI 用コンテキストは REST
生成Next.js 15(App Router・静的エクスポート)+ React 19 + TypeScriptRepository → Service → Page の 3 層で取得と変換を分け、全ページを HTML として書き出す
配信Cloudflare Pages(CDN)書き出した HTML・CSS・画像を世界中のエッジから配信。WordPress は訪問者から直接アクセスされない
動的処理Cloudflare Workers(_worker.js)/api/contact・/api/chat・/api/health など 5 本の API をエッジで処理。Turnstile でボットを遮断
AICloudflare Workers AI(GLM-4.7-Flash)+ AI GatewayWordPress に登録したコンテキスト(RAG)を注入して回答するチャットボット

表示側は TypeScript 5.7 と Tailwind CSS 4 で実装し、Vitest による自動テストと GitHub Actions のビルド検証を通してからデプロイします。バージョンはこのサイトの package.json に記載のものです。

編集は WordPress のまま、表示は静的ファイル

編集者の作業は、通常の WordPress と同じです。お知らせや記事は「投稿」、制作実績は専用のカスタム投稿タイプ(portfolio)に、アイキャッチ・カテゴリ・本文を入力して公開します。制作実績にはお客様の声(評価・本文・投稿者)の項目があり、入力すると実績ページとトップページの「お客様の声」に反映されます。

AI チャットボットの回答に使うコンテキストも、WordPress のカスタム投稿タイプ(rag_context)で管理します。サービス内容や FAQ を WordPress に書けば、チャットボットがそれを根拠に答えるようになります。コードを触らずに回答内容を更新できるのは、CMS を「知識の置き場」として使えるヘッドレス構成の利点です。

訪問者に届くのは、ビルド時に書き出した HTML・CSS・画像です。WordPress の管理画面や PHP は公開サイトから直接見えず、攻撃対象になる面が小さくなります。公開後にご自身でできること・ご依頼が必要なことの線引きは、通常の制作と同じく公開後の作業分担の表に準じます。

ビルド時のデータの流れ

WordPress の生データをページが直接扱わないよう、取得・変換・生成を 3 層に分けています。どこで何が起きるかが追えるので、不具合の切り分けと機能追加が楽になります。
  1. WordPress から取得(Repository)

    Axios の GraphQL クライアントが WPGraphQL に問い合わせます。タイムアウト 30 秒、GraphQL エラーとネットワークエラーを分けて例外にします。

  2. 型に変換(Service)

    取得した JSON を TypeScript の型(PostType / PortfolioType など)に変換し、アイキャッチ・カテゴリ・日付を整えます。ページ側は WordPress の生データを触りません。

  3. ページを生成(Page)

    記事・カテゴリ・制作実績の URL 一覧を generateStaticParams で列挙し、1 ページずつ HTML に書き出します。WordPress に到達できず 0 件のときはビルドを原因つきで停止します。

  4. サイトマップと更新日

    sitemap.xml の lastmod は、記事は WordPress の更新日、固定ページは Git の最終コミット日から生成します。

フォームやチャットなど動的な機能はエッジで処理

静的ファイルだけでは、お問い合わせの送信やチャットのような「訪問者の入力に応じた処理」ができません。このサイトでは、その部分だけを Cloudflare Workers(配信と同じエッジ)で処理しています。
Cloudflare Workers で処理する API
API役割
/api/contactお問い合わせフォームの送信を Contact Form 7 の REST API に中継
/api/chatAI チャット。Turnstile 検証(初回のみ)→ RAG コンテキスト取得(5 分キャッシュ)→ Workers AI 呼び出し
/api/rag/refreshRAG コンテキストのキャッシュ更新(API キー必須)
/api/wordpress/*WordPress API のプロキシ(キャッシュ付き)
/api/health死活確認

お問い合わせフォームと AI チャットは Cloudflare Turnstile でボットを遮断してから処理します。AI は Cloudflare Workers AI の GLM-4.7-Flash(131K トークンのコンテキスト)を AI Gateway 経由で呼び、WordPress に登録したコンテキストを注入して回答します。回答の根拠が WordPress にあるので、サービス内容が変わってもコードを変えずに追従できます。

この構成で得られたもの(実測)

数値は自社サイトの実測です(PageSpeed Insights、2026 年 9 月 12 日)。案件の数値を保証するものではなく、この構成で到達している水準の参考としてご覧ください。
andcre.com の実測値
指標備考
Largest Contentful Paint(desktop)2.0 秒トップページ。PageSpeed Insights の lab 値
First Contentful Paint(desktop)0.5 秒同上
Performance スコア(desktop)84 / 100同上。mobile はイントロ演出の改修中のため未掲載
静的ページ数25ビルド時に生成する HTML の数(2026-09-12 時点で 25)
自動テスト400 件Vitest。SEO の回帰チェック(60 項目)も別途スクリプトで実行

数値以外に、この構成で得られているものが 3 つあります。1 つ目は、WordPress が停止してもサイトの表示が止まらないこと。2 つ目は、表示側が TypeScript のコードなので、見出し構造・構造化データ・メタ情報の回帰を自動テストで検出できること(このサイトでは SEO の回帰チェックを 60 項目以上、スクリプトで実行しています)。3 つ目は、公開サイトから CMS の管理画面と PHP が見えないことです。

制作実績の詳細ページも同じ仕組みで生成しています。実例として、美容室サイトのNext.js + WordPress による制作実績をご覧ください。

構築の進め方

工程の骨格は通常のホームページ制作と同じで、KPI 策定・現状分析から始まり、ワイヤーフレーム、コンテンツ、環境構築、CMS、お問い合わせ機能、テスト・公開の順に進めます(制作の流れ 8 工程)。ヘッドレス構成で変わるのは「環境構築」と「CMS」の中身です。

  • 環境構築: WordPress(編集用)と Cloudflare Pages(配信用)の 2 系統を用意し、WPGraphQL などのプラグインを設定します。既存の WordPress を使う場合は、データはそのまま、プラグインの追加だけで済みます
  • CMS: WordPress のテーマを作る代わりに、Next.js のページとコンポーネントを実装します。投稿タイプごとに「取得 → 変換 → 生成」の 3 層を用意します
  • テスト・公開: ビルドが通ること、生成されたページの見出し・メタ情報・構造化データが想定どおりであることを自動テストで確認してから、CI またはローカルからデプロイします
  • 移行の場合: 既存の URL 構造は維持し、変更が必要な URL はリダイレクトで引き継ぎます。検索評価を落とさないための手順はリニューアルの進め方と同じです

費用は通常の WordPress 制作より高くなります

ヘッドレス構成で増えるのは、表示側の実装だけです。ページ数が同じでも、WordPress のテーマを当てる代わりに画面をコードで起こす分、一般的なレイアウトの WordPress 制作(見積例: 5 ページ・336,000 円・税別)より高くなります。どれだけ増えるかは作る画面の数で変わるので、要件を伺ってからお見積りします。

公開後に継続してかかる費用は、WordPress を置くサーバーとドメインの実費、配信先(Cloudflare)の利用料、保守をご契約いただく場合の保守費用です。保守の範囲と契約条件は契約・お支払い・保守の条件に準じます。

ヘッドレス CMS 構築のよくある質問

Q.ヘッドレス CMS にすると、WordPress の管理画面は使えなくなりますか?

使えます。投稿・固定ページ・カスタム投稿の編集はこれまでどおり WordPress の管理画面で行います。変わるのは、そのデータをどう表示するか(テーマではなく Next.js)だけです。

Q.記事を公開してからサイトに反映されるまで、どのくらいかかりますか?

ビルドとデプロイを経て反映されます。このサイトでは GitHub Actions またはローカルからのデプロイで、数分で反映されます。分単位の即時反映が必須の場合は向いていません。

Q.既存の WordPress サイトからヘッドレス構成に移行できますか?

できます。WordPress のデータはそのまま使い、WPGraphQL などのプラグインを追加して、表示側を Next.js で作り直します。URL 構造は維持し、必要な箇所はリダイレクトで引き継ぎます。

Q.WordPress が停止したら、サイトも止まりますか?

止まりません。訪問者に配信されているのはビルド済みの静的ファイルです。停止中は新しい記事の反映とお問い合わせフォームの送信ができなくなりますが、ページの表示は続きます。

Q.費用は通常の WordPress 制作より高くなりますか?

表示側を Next.js で実装する分、開発量が増えます。費用は「準備の有無 × 開発量」で決まるため、同じページ数でもヘッドレス構成の方が高くなるのが通常です。要件を伺ってお見積りします。

Q.SEO 上の効果はありますか?

静的配信で表示が速く、構造化データやメタ情報をコードで管理できる点は有利です。ただし順位は内容とリンクで決まるため、構成を変えるだけで上がるものではありません。

ヘッドレス CMS 構築のご相談はお気軽にどうぞ。

既存の WordPress サイトの URL と、更新の頻度・体制をお知らせいただければ、向き不向きからお答えします。お見積りは無料です。全国オンラインで対応します。

050-3743-9081

ヘッドレス CMS 構築とあわせて検討する

通常の WordPress 制作の流れ・納期・契約条件はホームページ制作サービスにまとめています。

通常の構成ならいくらかは、料金プランと見積例をご覧ください。ヘッドレス構成は開発量の分を個別にお見積りします。

同じ構成で制作した実例は制作実績一覧にあります。

静的配信の速さを検索順位につなげるならSEO対策サービスで対応します。

実装を担当する代表の経歴・著書は代表プロフィールと事業者概要に掲載しています。

既存サイトの URL と更新体制をお知らせいただければ、向き不向きからお問い合わせフォームでお答えします(無料)。

最終更新: