• WordPressをヘッドレス化すると、コスト・管理画面のカスタマイズ性能の両面で他のヘッドレスCMSに対して有利。
  • 更にWordPressで一般的な懸念事項として挙げられるセキュリティやパフォーマンスに対してもヘッドレス化で解決。

弊社ヨハクは2024年11月末で5期目が終わり12月より6期目に入ります。この5年間の間、Web制作会社にあるまじき適当な状態で放置していたWebサイトをこのタイミングでようやくリニューアルすることにしました。

せっかくなので「採用事例がまだ少ないモダンな構成にしたい」「でも単純に最新技術を追い求めるのではなく、すぐにでもクライアントワークとして流用できる構成にしたい」という方針のもとに技術選定を進め、結果的に以下の構成を採用することになりました。

  • フロントエンド：Astro
  • CMS：WordPress(ヘッドレス&GraphQL)
  • CI/ホスティング：Cloudflare Pages

フロントエンドをAstroにするのは割と最初から決めていたのですが問題はCMSです。弊社でもすでに何件もヘッドレスCMSの案件を取り扱っていましたが、Next.jsやAstroと組み合わせて爆速なサイトを作れる恩恵がある反面、色々と懸念点があるのも事実なんですよね。

ヘッドレスCMSに対する懸念点

ユーザー毎にかかるコスト・セキュリティ

一般的にSaaS系のヘッドレスCMSは管理画面にログインするユーザー毎に費用がかかります。無料もしくは低コストなプランで抑えようとすると、アカウントの共有で乗り切るしかないのですが、セキュリティ的には不安が残ります。また、定額プランでは権限を細かく設定することも難しいので、あるユーザーが間違って設定を変更してしまったということも起こりがちです。

配信データ量に対する従量課金

同じくSaaS系のCMSに限定されますが、CMSに登録した画像はそのサービスのCDNに乗って高速に配信される反面、コストもそれなりにかかります。無料で始めたのに急にアクセスがスパイクして毎月数百ドルの請求が発生するようなリスクは避けなくてはいけません。

入力画面におけるカスタマイズ性の低さ

一部のサービスを除いてヘッドレスCMSの入力画面の構築はそのサービスが提供するGUI上行われます。サービスごとにクセがあり、狙っていた構造が仕様上作れないということも多々。また、GUIであるが故にバージョン管理とも相性が悪く、複数名での作業にも向いていません。「WordPressの入力画面構築もGUIじゃない？」というツッコミは当然ありそうですがそれは後述で。

ヘッドレスWordPressならすべて解決できた

ユーザー毎にかかるコスト・セキュリティ

WordPressはオープンソースかつ無償利用が前提なので各ユーザーにかかるコストも当然ゼロです。また、必要に応じて権限も柔軟に設定し、管理者権限以外には設定画面を見せない、記事の公開権限を持つユーザーを限らせるみたいなことも容易に可能です。

配信データ量に対する従量課金

一般的なWordPressのホスティングサービスにおける配信データ量に対する制限はSaaS系のサービスに比べたら圧倒的に緩いはずです。更に今回はWP Offload Mediaというプラグインを利用して、WordPressに登録した画像をすべてCloudlfare R2から配信する設定を行いました。R2は登録時にごく微量の料金がかかるものの配信コストはゼロなので、ここにかかるコストはほぼゼロになったと言っても過言ではないでしょう。おまけにR2の速度は爆速です。

入力画面におけるカスタマイズ性の低さ

WordPressにはCMSとして20年以上の歴史があります。色々と物議を醸すことも多いですが、管理画面構築のためのツールとしてはさすがに積み重ねてきたものが違うのかなと。Advanced Custom Fields Pro や Admin Columns Pro, Admin Menu Editor Pro などの定番の有償プラグインを組み合わせれば管理画面のカスタマイズは自由自在にできます。また、弊社ではACFのカスタムフィールド設定をPHPで記述できる内製のフレームワークがあり、入力要素の設定はgit管理ができているのです。

更にWordPressそのものに対する懸念点にも対応

ここまでヘッドレスCMSにおけるWordPressの優位性を述べてきましたが、実はWordPressをヘッドレス化することによって、既存のWordPressに対してよく耳にする懸念点すらも解決できている要素があります。

セキュリティ的なリスク

セキュリティ対策を怠らなければWordPressでもかなり安全に運用できることは間違いなのですが、ヘッドレスWordPressの構成の場合はフロントとCMSがサーバーごと切り離されているので、改ざんやのっとりに対するリスクは圧倒的に低いといえます。このヨハクWebに関しては、画像もR2に置いてしまったのでWordPressのURLはフロントのソースコード上からは完全に隠されており、CMSのアドレスを特定することは不可能と言っていいでしょう。むしろ、こうして公表していなければCMSがWordPressであると判断することも難しいはずです。

毎回PHPを実行するから遅い

これもサーバーを調整したりキャッシュ系のプラグインを正しく使えばかなり早くはなるんですが、フロント側をSSGで出力してCDNに乗せてしまっているこのヘッドレス方式が爆速なことは間違いないです。

DX(Developer Experience)が悪い

正直、WordPressをヘッドレス化する一番のメリットはこれかと。個人的にWordPressの開発において一番しんどいと感じるのはHTMLで下書きしたフロントの内容をPHPに移植するタイミングです。試行錯誤の度にHTMLとPHPを往復するのは無駄の極み。かといって、いきなりPHP込のテーマで書き始めると、コードの書き味が悪すぎて息苦しいのです。

対してヘッドレス構成ならば、管理画面やWordPressの設定は純粋なPHPとして書いておきつつ、フロント側はAstroやNext.jsなどDXに優れたフレームワークを使えるので試行錯誤のクオリティも上がります。

現時点での解決すべき課題

本サイトにおいては社内案件なので運用でカバーしつつ公開を優先とする方針にしましたが、クライアントワークとしてこの仕組みを提案するには解決すべき課題もいくつかあるので以下に挙げておきます。なお、これらはヘッドレスWordPressだけの問題ではなく、ヘッドレスCMS全般における運用面の課題なので「ヘッドレスCMSにおける現時点の正解はWordPress」という本記事の趣旨が揺らぐことはありません。

ステージング・プレビュー環境の確立

下書き・プレビューボタンをポチッと押したらその状態の記事がすぐに確認できることって、純粋なWordPressのすごくいいところの一つだと思うのです。これに近しいUXを実現するためには、ステージング環境だけSSRを有効にしながら下書きレベルの記事もAPI経由で取得できる仕組みを整える必要がありそうです。

ビルドステータスの確認

ヘッドレス構成においてビルドプロセスというものがあることは仕方ないにしても、公開ボタンを押してからのビルドステータスを管理画面上で確認する方法はほしいですね。Netlifyならビルドステータスのバッジを利用すれば容易に実現可能なんですが、Cloudflare PagesやVercelの場合は自前でWebhookを用意する必要がありそうです。

まとめ

最後に不便なところも述べましたが、ヘッドレスWordPress構成におけるデメリットとしてあげられる事項はこの程度です。工数面でも現場の知見が溜まってくれば純粋なWordPressと同等もしくは下回るくらいで進められるではないかと。前述の通り今後はクライアントワークでも活用していきたいのでご興味のある方はぜひご用命ください。

リニューアル後の初回につき気合が入って長くなりましたが、Astroに関する言及はおそらく次回以降の近いうちに。

おまけ：他に検討していたCMSたち

Payload

実はいま一番期待しているヘッドレスCMSです。セルフホスティングタイプで上記のヘッドレスCMSに対する懸念点は概ね解決しています。ただ、ラーニングカーブがきつく、また、CMSそのものをホスティングできるサーバーがかなり限定されるのがネックで。あとは、現時点ではまだ発展途上でWordPressと比較検討した結果、半年以内にクライアント案件として投入するのは難しそうという判断になりました。ただ、期待していることは間違いないので、今後のアップデートは注視しつつ検証も続けていく予定です。

Sanity

SaaS系では一番好きなヘッドレスCMSです。管理画面をコードベースで自分で作っていくスタイルはラーニングカーブはあるものの、git管理もしやすく非常に魅力的。実案件としても弊社としていくつか実績があります。WordPressに対して完全NGが出るのならば弊社としては現状の第一候補ですね。

ただ、料金プランが以前は「フリープランで始めて配信量が超過したらその分(規模的には数ドル程度)だけを払えばいいよ」という方針だったのでクライアントワークとしてもおすすめしやすかったのですが、最近の料金改定でフリープランの場合はこの超過料金(overage) の設定がなくなり有料プランへの契約が必須になってしまったのはリスクかなと。まぁ、その代わりに基本の転送量が大幅に増大しているので、課金プランに強制切り替えみたいなことは滅多に発生しないとは思うのですが。