2021年、マンチェスターの中規模なeコマースブランド（SKU数は約40,000）から電話をもらった。在庫管理システムは激怒していた。ヘッドレスShopifyの構築にNext.jsフロントエンドを組み合わせて、18ヶ月間に£180,000を費やしたのに、ページロード時間が置き換えたShopifyテーマよりも遅くなっていたのだ。開発チームは1人の請負業者から4人に膨れ上がった。コンテンツエディターがブログ記事を公開するには、デベロッパーが立ち会う必要があった。
重要なポイント：複数のフロントエンドが本当に必要な場合、またはモノリシック構造では達成できないパフォーマンスが必要な場合にのみヘッドレス化を検討してください。優れたテーマを備えた1つのWordPressサイトは、不要なスタックを保守する3人の開発者に勝ります。
ヘッドレスは彼らに未来として売られてきた。技術的には、その通りだ。しかし誰も、運用に実際どれだけのコストがかかるかを説明しなかった。
Seahawk Mediaで12,000以上のサイトの構築または監督に携わってきた。ヘッドレスが正しい判断だったのは、そのうち8～10%程度に過ぎない。残りの90%は、災難になっていただろう。高コストで、出荷が遅く、メンテナンスが苦しい。このポストは、既にチェックを切ってしまう前に、自分のプロジェクトがどちらの分類に当てはまるかを知ることについてだ。
---
「ヘッドレス」が実際に意味するもの
定義をさっさと片付けよう。従来のCMS（WordPress、Squarespace、その他）は、コンテンツ管理バックエンドをフロントエンドのプレゼンテーション層と結合する。ネイティブに相互作用する。ヘッドレスはそれを分離する。CMS（Contentful、Sanity、Strapi、ヘッドレスモードのWordPress）は純粋なコンテンツAPIになる。フロントエンド（Next.js、Nuxt、Astro、SvelteKit、その他好みのもの）がそのコンテンツを取得し、好きなように描写する。
シンプルな考え方です。複雑さはほかのあらゆるところに忍び込んできます。
実際にプロジェクトに現れるスタック
実務では、誰かが「ヘッドレス」と言うとき、通常はこれらの組み合わせのいずれかを意味します：
- ContentfulまたはSanityをCMSとして、REST又はGraphQLでJSONを配信
- フロントエンドはNext.js、静的生成（SSG）またはサーバーサイドレンダリング（SSR）のいずれか
- デプロイメントとエッジ機能はVercelまたはNetlify
- コマースが関わっている場合はShopify Storefront APIまたはBigCommerce
- Algoliaの何らかのバージョンを検索に使用します。ネイティブの検索オプションは通常ひどいからです。
これらのそれぞれが別々のベンダー関係、別々の請求行、金曜日の午前2時に問題が発生する可能性のある別々のものです。
---
ヘッドレス化が本当に必要な理由
本当の正当な理由がある。アーキテクチャを否定しているわけではない。ただ、無差別に適用されるのに疲れているだけだ。
マルチチャネルコンテンツ配信が最強の議論だ。同じコンテンツがWebサイト、モバイルアプリ、キオスク表示、スマートTV向けインターフェイスに表示される必要がある場合、結合されたCMSは本当に面倒になる。すべての4つのサーフェスが照会する1つのコンテンツAPI？それは本当に意味がある。Seahawkはドバイのホスピタリティクライアント（パブリックファイシング向けサイト、内部スタッフアプリ、プロパティ全体のデジタルサイネージを備えたリゾートグループ）を持っていた。すべてに供給するSanityの単一インスタンス。それは正しい判断だった、終わり。
実スケールでのパフォーマンスが2番目の正当な議論だ。CDNエッジから配信される静的に生成されたページは、サーバーの最適化がいかに良好でも、PHP描写のWordPressページが単純にできない方法で高速だ。月間数百万のページビューについて話している場合、これらのミリ秒は意味のある収益差に複合化される。Googleのリサーチはロード速度とコンバージョン率の相関を何度も記録している。理論的ではない。
チーム分離も重要だが、フロントエンドとバックエンドの独立したチームを持つ組織にだけ当てはまる。20人のマーケティング部門がエンジニアリングチームから独立して動きたいなら、CMSとフロントエンド間のクリーンなAPI契約があれば、両サイドはお互いをブロックしないで作業できる。
この3つのケースなら、複雑さのコストに値する価値がある。それ以外は通常、アーキテクチャの衣をかぶった願望的思考に過ぎない。
---
ヘッドレス化が単なる過度なエンジニアリングになる場合
ロンドンの会計事務所向け5ページのブロシュアサイトはヘッドレスアーキテクチャを必要としない。1人の開発者を雇用している200商品のWooCommerceストアも同じだ。
この間違いは絶えず見かけることがある。特にNext.jsを発見したばかりで、すべてに使いたいデベロッパーから。（2019年、小さな慈善クライアント向けのヘッドレスブログを構築し、新規投稿でNetlifyリビルドをトリガーするようにWebhooksを3日間設定して、請求して、何か壊れるたびに電話してくる、自分も有罪だった。）問題は、ヘッドレスがCMSから基盤整備への操作上の複雑性を移動させることだ。WordPressは自らアップデートする。カスタムNext.js + Contentfulパイプラインはそうではない。
ヘッドレスが通常、得られるもの以上のコストがかかる具体的なシナリオ：
- 小さなコンテンツチーム。1～2人がすべてのコンテンツを管理している場合、WordPressのような適切な結合されたCMSの編集体験は、ヘッドレスCMSよりも本当に優れている。プレビュー環境は難しい。インライン編集は廃止される。WYSIWYGは無力化される。
- 限定的な予算。適切なヘッドレスビルドは、開発に相応するWordPressビルドの2～3倍の費用がかかり、継続的メンテナンスはより高い。予算が制約の場合、そのお金はほぼいつもどこか他の場所でより良い効果を生じさせる。
- コンテンツの頻繁な更新と静的生成は、ビルド時間を意味する。1日50記事を配信するニュース発行者は、毎回フルサイト再構築に8分待つことは望まない。(もちろん、段階的な静的再生成は役に立つ。ただ、それ自体の複雑性も追加される。)
- 専任のDevOpsがいない場合、誰かがデプロイメントパイプライン、CDN設定、環境変数、プレビュー URL を管理する必要がある。小規模チームでは、その誰かは他のすべての業務も担当している開発者になることがほとんどだ。
---
WordPressヘッドレスの中道
私が異論を唱えたいのは、「従来のWordPress」と「別のCMSを持つ完全なヘッドレス」の間の偽りの二者択一です。特定のクラスのプロジェクトで本当にうまく機能する中道が存在します。
WordPressをヘッドレスバックエンドとして使用し、WP REST API または WPGraphQL を使うと、クライアントが既に知っているコンテンツ管理体験が得られる(率直に言うと、ほとんどのクライアントは WordPress を知っている)。同時に、モダンフロントエンドの柔軟性も手に入る。Contentful に支払う必要はない。誰も再トレーニングされない。編集チームは Gutenberg を使い続ける。フロントエンドは、そのプロジェクトに最適なフレームワークであればなんでもいい。
過去4年間でおそらく30～40プロジェクトでこのパターンを使ってきた。特に、WordPress に膨大な既存コンテンツライブラリがあり、移行は望まないが React フロントエンドでパフォーマンスやインタラクティビティが欲しいマーケティングサイトで、うまくいく。トレードオフとしては、WPGraphQL プラグインメンテナンスが面倒になることがあり、PHP サーバーを実行し続ける必要があり、WordPress ホスティングから完全には逃げられない。
---
ヘッドレスCMSの選定：実践的な比較
すべてのヘッドレスCMSが同じではなく、フロントエンドフレームワークの興奮で認められているより、選択はずっと重要です。
Contentful
エンタープライズグレードの選択肢。堅牢な API、良好な SDK、妥当な編集 UI。価格が痛いポイントだ。無料プランは小さなプロジェクトには本当に役立つが、制限に達すると、何か面白いことをする前に月300ドル以上を見ることになる。予算が本物で、適切なロールと権限ワークフローが必要な組織のプロジェクトなら、Contentful に手を伸ばすだろう。
Sanity
ほとんどの中堅ヘッドレスプロジェクトにおける個人的なお気に入り。GROQ クエリ言語は一日使えば表現力が高い、Sanity Studio は Contentful ではできない方法でカスタマイズ可能、リアルタイム協業は素晴らしい。価格はより合理的だ。欠点は、非技術的なコンテンツエディタにとって学習曲線が急であること、Studio が WordPress と十分に異なる外観であるため、常にトレーニング期間があることだ。
Strapi
オープンソース、自己ホスト、実行は無料。SaaS CMS料金を払わないクライアントがいてサーバーがある場合、Strapiの検討の価値があります。管理パネルはまともです。ただし、ホスティング、アップグレード、セキュリティパッチのメンテナンスは自分で行うことになります。軽くはありません。
Astroとコンテンツコレクション
コンテンツ量が多く、ほぼ静的なサイト、ドキュメント、ブログ、マーケティングサイトには、ローカルコンテンツコレクションを備えた Astro の検討の価値がある。CMS なし。コンテンツはリポジトリ内の Markdown または MDX ファイルとして存在する。開発者はそれを愛する。非技術的なエディタは通常それを嫌う。このルートに進む前に視聴者を知れ。
---
パフォーマンスの議論：数値が実際に示すもの
スピードについてのふわふわした主張ではなく、実際のベンチマークを示そう。
Seahawk クライアントで、SaaS 企業、約80ページ、中程度のトラフィック。マネージド WordPress インストールから Next.js と Sanity への移行を行い、Vercel にデプロイした。移行前、Lighthouse スコアはモバイルで62～68程度だった。移行後、一貫して91～96。Time to First Byte は約420ms から80ms未満に低下した。これは限定的な改善ではない。これは全く別の製品だ。
しかし、これが重要だが、彼らは専任のフロントエンド開発者、Sanity トレーニングを受けた4人のコンテンツチーム、8週間のビルドを吸収した予算があった。ヘッドレスが機能するための条件が揃っていたため、パフォーマンス向上は本物だった。
Web Almanacのデータは、ヘッドレス志向のフレームワークと従来の結合型CMSの間のパフォーマンスギャップが実在するが自動ではないことを示している。実装の悪いNext.jsサイトは、設定の良いWordPressサイトを完全に下回る可能性がある。アーキテクチャだけでは救いにならない。
---
意思決定を行う：私が実際に使うフレームワーク
クライアントからのブリーフが届いて、ヘッドレスが適切かどうか疑問がある場合、僕は推奨を確約する前に5つの質問を通す。
- そのコンテンツは複数のサーフェス上に表示される必要があるか？イエスなら、ヘッドレスは真剣に検討される。ノーなら、主要な正当性を失う。
- コンテンツチームの技術的な理解度はどのレベルか？非技術的なエディターが厳しい締切の中、慣れないCMSで作業するのは悪い組み合わせだ。
- 予想されるトラフィックとパフォーマンス要件は？合理的なホストで月間5万ビロー未満？WordPressで十分対応できる。
- 継続的なメンテナンス専任の開発者がいるか？「何か壊れたら誰か呼ぼう」というなら、ヘッドレスインフラは負債だ。
- 実際の予算は？初年度の運用も含めて。構築だけでなく。ホスティング、CMSサブスクリプション、アップデート用の開発者時間。総所有コストだ。
1、4、5番の質問が揃わなければ、僕は従来型またはハイブリッドアプローチを推奨して安心して眠れる。
---
FAQ
ヘッドレスWordPressは従来のWordPressセットアップより優れているか？
あなたのプロジェクトにとって「より良い」が何を意味するかに完全に依存する。マルチチャネル配信、チーム分離、または高トラフィック量でのパフォーマンスなら、ヘッドレス WordPress、または WordPress を専用ヘッドレス CMS に置き換えることは有意義に改善できる。小規模チームと中程度のトラフィックを持つ標準的なビジネスサイトなら、良いテーマと適切なキャッシングを備えた従来の WordPress の方が、構築しやすく、実行コストが安く、クライアントに引き継ぎやすい。
ヘッドレスは常にパフォーマンスが向上するのか？
いいえ。この神話はプロジェクト予算に本当の損害をもたらしています。CDNから配信される静的に生成されたページはデフォルトでより高速ですが、最適化されていない画像、滝状のAPIリクエスト、適切なキャッシングがないヘッドレスビルドは、チューニングされたWordPressサイトよりもパフォーマンスが落ちる可能性があります。パフォーマンスはアーキテクチャではなく、実行方法次第です。
ヘッドレスに移行する最も安い方法は？
£5/月のVPS上のStrapiとVercelの無料枠に展開したAstroまたはNext.jsを組み合わせれば、非常に低い月額コストで機能するヘッドレスセットアップが実現できます。代わりに開発者の時間を費やすことになります。実は何も無料ではなく、コストがどこに落ちるかを選んでいるだけです。
ヘッドレスビルドは従来のCMSビルドと比べて、通常どのくらいの期間がかかるのか？
私の経験では、ヘッドレスセットアップでの同等のプロジェクトはWordPressよりもおよそ1.5倍から2.5倍長くかかります。特にそれがチームにとって初めてのヘッドレスプロジェクトである場合はそうです。このギャップはチームがスタックに習熟するにつれて狭まります。タイムラインと見積もりにこれを誠実に組み込んでください。「数週間で終わる」と言われたヘッドレスの構築が4ヶ月かかってしまったクライアントは戻ってきません。
ブロックエディタを備えたWordPressが登場したことで、ヘッドレスは今、廃れかけているのか？
いいえ、ただし低い範囲ではユースケースが限定されてきています。Gutenbergは、以前ヘッドレスが正当化されていたいくつかのシナリオを侵食してきました。インタラクティブでコンポーネント駆動型のコンテンツ体験は、今ではWordPressで分離なしでより達成可能です。高い範囲では、大規模なマルチチャネル出版とコマースについては、ヘッドレスはかつてないほど関連性があります。
---
ヘッドレスはステータスシンボルではありません。それはトレードオフです。より多くの柔軟性、より多くの複雑性、より多くのコストと引き換えに、特定の状況で本物のゲインが得られます。コミットする前に状況を理解してください。冒頭で述べたマンチェスターのeコマースクライアントは、結局Shopifyテーマにいくつかのカスタムフロントエンドコンポーネントを加えたものに移行しました。開発オーバーヘッドを60%削減し、読み込み時間はついに改善されました。時には昔のやり方が正しいやり方です。それに恥じることはありません。