「ヘッドレスCMSにしたほうがいいですか」。サイトの作り直しを相談されるとき、ときどきこう聞かれます。表示が速くなる、安全になる、と聞いて関心を持たれた方が多いようです。
ヘッドレスCMSは、記事を書く管理画面と、閲覧者が見る公開サイトを分ける作り方です。管理画面には、WordPressのような既存のCMSを使うことも、Next.jsなどでそのサイト専用の管理画面を作ることもできます。WordPressを使い続けるなら、更新する担当者の画面はほとんど変わりません。ただ、裏側では、プレビューやフォーム、予約公開の仕組みを公開サイトの側に作り直すことになります。選ぶ前に見ておきたいのは、何が変わって、どこに費用がかかるのか、の2つです。
この記事の結論
ヘッドレスCMSが向くのは、お知らせやコラムが中心で、管理画面を外から見えない場所に置きたいサイトです。フォームや予約、会員、ECなど、プラグインで足している機能が多いサイトは、WordPressのまま保守していくほうが合うこともあります。迷ったときは、更新する担当者がふだん使う機能（プレビュー、予約公開、フォーム）が、分けたあとも同じように使えるかどうかを基準にすることを勧めます。
ヘッドレスCMSは、管理と公開を分ける作り方
ふつうのWordPressは、記事を保存する仕組みと、閲覧者に見せる画面を、同じところで動かしています。テーマが画面を組み立て、プラグインが機能を足します。
ヘッドレスCMSにすると、WordPressは記事を保存して渡すだけの役になります。公開サイトはNext.jsなどで別に作り、WordPressから記事の内容を受け取って表示します。この受け渡しに使うのが、WordPressに標準で入っているREST APIという仕組みです。WordPressの公式資料も、REST APIを使えば、WordPressの内容を別のアプリケーションで使えると説明しています。
管理画面は、WordPressに限りません。ほかのCMSを使うことも、Next.jsなどで、そのサイトの更新に必要な項目だけを持つ管理画面を作ることもできます。ここでは、これまでのWordPressと比べやすいように、「管理はWordPress、公開はNext.js」の組み合わせを例に説明します。
更新する担当者から見て、変わることと変わらないこと
記事を書く画面と、誰が何をできるかという権限は、これまでのWordPressと同じです。変わるのは、書いたものが公開サイトに出るまでの部分です。
| 項目 | これまでのWordPress | 管理はWordPress、公開はNext.js | 決めておくこと |
|---|---|---|---|
| 記事を書く画面 | WordPressの管理画面 | 同じ | — |
| 権限 | 管理者・編集者・投稿者など | 同じ（WordPressの権限がそのまま使える） | — |
| プレビュー | プレビューのボタンで、公開時の見た目を確かめられる | 公開サイトの側にプレビューの仕組みを作る。作らないと、下書きを公開時の見た目で確かめられない | 誰が、どの画面で確かめるか |
| 公開の反映 | 公開するとすぐに変わる | 公開サイトのページが作り直されたときに変わる。作り直すきっかけ（公開したときの通知、一定の時間ごと）を作る | 公開してから反映までの時間 |
| 予約公開 | 指定した時刻に公開される | WordPressでは予約どおり公開になるが、公開サイトはページが作り直されるまで変わらない | 予約の時刻にも作り直しを連動させるか |
| お問い合わせフォーム | プラグインで置ける | 公開サイトの側に、フォームと受け付けの仕組みを用意し直す | 送信をどこで受け付け、どこに通知するか |
| サイト内の検索 | 標準の検索がある | 公開サイトの側に作る | 何を検索の対象にするか |
| SEOの設定 | プラグインの設定がそのまま出る | 公開サイトの側で、タイトルや説明文を出力する | どのプラグインの値を使うか |
| プラグイン | 公開画面に機能を足せる | 公開画面に働くプラグインは使えない。管理画面の中で働くものは使える | いま使っているプラグインのうち、何を公開側で作り直すか |
プレビューは、Next.jsにDraft Modeという仕組みがあります。編集者だけが、下書きを公開サイトの見た目で確かめられ、ほかの閲覧者にはいつものページが表示されます。ただし、WordPressのプレビューのボタンとつなぐための設定は、公開サイトの側で作る必要があります。
SEOのタイトルや説明文を公開サイトで出せるかどうかは、使っているSEOプラグインが、その値をREST APIに出すかどうかで決まります。たとえばYoast SEOは、記事をREST APIで取り出すと、タイトルや説明文などの値を一緒に返します。ヘッドレスの構成で使うことを想定した機能で、公開サイトはその値を受け取って出力できます。
値をREST APIに出さないプラグインの場合は、WordPressの側に、保存されている値をREST APIへ出す設定を足します。WordPressは、記事に付けた追加の項目（カスタムフィールド）を、出す設定をしない限りREST APIに含めないためです。
分けることで得られること
分けたときにいちばん変わるのは、公開サイトでWordPressを動かさなくなることです。閲覧者がアクセスする公開サイトでは、WordPressのテーマやプラグインを読み込みません。管理画面の場所も公開サイトに出さず、ログインできる人や場所を絞れます。
もう一つは、管理画面の側に障害が起きたときの影響です。ページを前もって作っておいて配信する作りにすると、管理画面の側が止まっても、作ってあるページは表示を続けられます。たとえば、Next.jsのサイトをVercelで公開する場合、Vercelの公式資料は、ページの作り直しに失敗したときは、保存してあるページを出し続けると説明しています。
表示の速さやデザインも、テーマの作りに縛られずに、公開サイトの側で調整できます。ただし、分ければ攻撃や障害がなくなるわけではありません。変わるのは、どこかで問題が起きたときに、その影響を管理画面と公開サイトのどちらかにとどめやすくなる点です。たとえば、上のように管理画面が止まっても、作ってあるページは表示を続けられます。
管理画面と公開サイトの置き場所
分けるときは、管理画面と公開サイトをどこに置くかも決めます。置き方は、大きく3通りです。
同じサーバーの、別のディレクトリに置く
サーバーの契約は一つで済み、費用を抑えやすい置き方です。サーバーに障害が起きると、管理画面と公開サイトの両方に影響します。
別のドメインに置く
管理画面を、公開サイトとは別のドメインで動かします。公開サイトのアドレスから、管理画面の場所をたどれないようにできます。
管理画面と公開サイトを、別のサーバーに置く
片方の障害が、もう片方に広がりにくくなります。サーバーは、管理画面と公開サイトでそれぞれ契約し、管理します。
どの置き方でも、公開サイトから管理画面の場所が分からないように作り、ログインできる人や場所を絞ることができます。どこまで分けるかは、サイトの規模、障害が起きたときにどこまで影響を許せるか、費用の3つを見比べて決めることになります。
費用は3つに分けて考える
ヘッドレスCMSの見積もりを比べるときは、次の3つを分けて見ると、何に費用がかかっているのかが分かります。
- 管理画面の費用WordPressなら本体は無料で、置き場所のサーバー代がかかります。サービスとして提供されているCMSなら、その利用料です。専用の管理画面を作るなら、その制作費と置き場所の費用がかかります。
- 公開サイトの制作費画面に加えて、上の表のプレビュー、反映のきっかけ、フォーム、検索など、これまでWordPressが受け持っていた部分を作る費用です。
- 公開後の保守の費用WordPressの更新に加えて、公開サイトの側の部品の更新と、公開サイトの置き場所（Vercelなど）の管理が増えます。
とくに見落としやすいのが、3つ目です。分けたあとも、管理画面としてのWordPressは更新を続ける必要があります。そこに公開サイトの保守が加わります。
WordPressのままのほうが合うサイト
次のようなサイトは、分けるより、いまのWordPressをきちんと保守していくほうが合うことがあります。
- プラグインで足している機能が多いフォーム、予約、会員、ECなど。公開サイトの側で一つずつ作り直すことになります。
- 担当者が見た目を確かめながらページを作るブロックを組み合わせて、ページごとにレイアウトを変えている場合、プレビューと同じ見た目を公開サイトで再現する手間がかかります。
- 公開サイトの保守を担う人がいない分けたあとは、管理画面と公開サイトの両方を保守し続ける体制が必要です。
- いまの悩みが、更新の停止や表示の遅さWordPressを更新できていない、表示が遅い、といった悩みなら、作りを変える前に、保守や改修で解決できることがあります。
分けたほうが合うサイト
- これから新しく作るいまのサイトから移す記事や、作り直すプラグインがありません。プレビューやフォーム、検索も、最初から分けた形で設計できます。
- 費用を抑えながら、更新は自社で続けたい分けるときも、管理画面を一から作るより、WordPressを管理画面に使うほうが費用を抑えやすくなることもあります。どこまで抑えられるかは、実装したい内容によります。更新する人は慣れた画面のまま、自社で更新を続けられます。
- お知らせやコラムが中心で、ページの作りが決まっている記事の形がそろっていれば、公開サイトの側で作る画面も少なくて済みます。
- 管理画面を、外から見えない場所に置きたい公開サイトでWordPressを動かさず、管理画面への入口を絞れます。
- デザインや表示の速さを、テーマに縛られずに作りたい公開サイトは、表示に必要な機能だけで作れます。
- 管理画面を、自社の更新作業に合わせて作りたい管理画面を分けると、そのサイトの更新に必要な項目だけを持つ管理画面を、一から作ることもできます。入力欄を絞ったり、使わないメニューを隠したりする整え方なら、WordPressの管理画面のままでもできます。
- 同じお知らせを、複数のサイトやアプリに出したいグループ会社やブランドごとにサイトがある、自社のアプリにも同じお知らせを出している、といった場合です。一つの管理画面で書けば、APIでそれぞれの出し先へ渡せるので、場所ごとに入力し直さずに済みます。同じ文章を複数のサイトに載せるときは、検索に出すサイトを一つに決めます。ほかのサイトのページは、検索に載せない設定（noindex）にしておきます。同じ内容のページどうしが、検索で競い合わないようにするためです。
当社で分けた例
grandworkでは、これまでに複数のサイトで管理画面と公開サイトを分けてきました。そのうちの一つでは、管理画面と公開サイトを別々のドメインに置いています。このサイトは共有のレンタルサーバーを使っていて、サーバーでプログラムを常に動かしておく仕組みは使えませんでした。公開サイトには会員のログインや決済がなかったため、公開サイトはそのレンタルサーバーで動く形で作り、管理画面のWordPressは、別のドメインに置いてディレクトリも分けています。共有のレンタルサーバーでも、このように管理画面と公開サイトを分けられます。
このとき、上の表で挙げた点を一つずつ作っています。お問い合わせは、公開サイトのフォームから送られた内容を、中継用のプログラムを通して管理画面の側で受け付ける作りにしました。確認のために、公開時とほぼ同じ見た目の確認用の画面を用意し、タイトルや説明文、構造化データは公開サイトの側で出力しています。更新する方の画面は、使う項目だけに絞りました。分けると決めたあとは、こうした作り直しが一つずつ必要になります。
分けるかどうかを決めるのは、技術の新しさではなく、更新する人の作業と、公開後に誰が保守するかです。いまのサイトでどの機能を使っているかが分かれば、分けた場合に作り直すものと、その費用の目安をお伝えできます。
- 管理と公開を分けたサイトを検討している方へ管理画面はWordPressなどのCMSのほか、専用に作ることもできます。公開サイトをNext.jsなどで作る構成をご案内しています。ヘッドレスCMS型Webサイト制作の内容を見る
- いまのWordPressのまま整えたい方へ作りを変える前に、いまの構成や更新の状態を単発で調べます。WordPress点検の内容を見る