2021年、マンチェスターの中規模なeコマースブランド（SKU数は約40,000）から電話をもらった。在庫管理システムは激怒していた。ヘッドレスShopifyの構築にNext.jsフロントエンドを組み合わせて、18ヶ月間に£180,000を費やしたのに、ページロード時間が置き換えたShopifyテーマよりも遅くなっていたのだ。開発チームは1人の請負業者から4人に膨れ上がった。コンテンツエディターがブログ記事を公開するには、デベロッパーが立ち会う必要があった。Next.js front end, and their page load times were slower than the Shopify theme they'd replaced. Their development team had grown from one contractor to four. Content editors needed a developer present just to push a blog post live.
重要なポイント：複数のフロントエンドが本当に必要な場合、またはモノリシック構造では達成できないパフォーマンスが必要な場合にのみヘッドレス化を検討してください。優れたテーマを備えた1つのWordPressサイトは、不要なスタックを保守する3人の開発者に勝ります。Go headless when you genuinely need multiple front ends or performance a monolith cannot hit; one WordPress site with a good theme beats three developers maintaining a stack you did not need.
ヘッドレスは彼らに未来として売られてきた。技術的には、その通りだ。しかし誰も、運用に実際どれだけのコストがかかるかを説明しなかった。
Seahawk Mediaで12,000以上のサイトの構築または監督に携わってきた。ヘッドレスが正しい判断だったのは、そのうち8～10%程度に過ぎない。残りの90%は、災難になっていただろう。高コストで、出荷が遅く、メンテナンスが苦しい。このポストは、既にチェックを切ってしまう前に、自分のプロジェクトがどちらの分類に当てはまるかを知ることについてだ。
---
「ヘッドレス」が実際に意味するもの
定義をさっさと片付けよう。従来のCMS（WordPress、Squarespace、その他）は、コンテンツ管理バックエンドをフロントエンドのプレゼンテーション層と結合する。ネイティブに相互作用する。ヘッドレスはそれを分離する。CMS（Contentful、Sanity、Strapi、ヘッドレスモードのWordPress）は純粋なコンテンツAPIになる。フロントエンド（Next.js、Nuxt、Astro、SvelteKit、その他好みのもの）がそのコンテンツを取得し、好きなように描写する。WordPress, Squarespace, whatever, couples the content management back end to the front-end presentation layer. They talk to each other natively. Headless decouples them. Your CMS (Contentful, Sanity, Strapi, WordPress in headless mode) becomes a pure content API. Your front end, Next.js, Nuxt, Astro, SvelteKit, whatever you fancy, fetches that content and renders it however it wants.
シンプルな考え方です。複雑さはほかのあらゆるところに忍び込んできます。
実際にプロジェクトに現れるスタック
実務では、誰かが「ヘッドレス」と言うとき、通常はこれらの組み合わせのいずれかを意味します：
- ContentfulまたはSanityをCMSとして、REST又はGraphQLでJSONを配信 as the CMS, serving JSON over REST or GraphQL
- フロントエンドはNext.js、静的生成（SSG）またはサーバーサイドレンダリング（SSR）のいずれか on the front end, either statically generated (SSG) or server-side rendered (SSR)
- デプロイメントとエッジ機能はVercelまたはNetlify for deployment and edge functions
- コマースが関わっている場合はShopify Storefront APIまたはBigCommerce or BigCommerce if there's commerce involved
- Algoliaの何らかのバージョンを検索に使用します。ネイティブの検索オプションは通常ひどいからです。Algolia for search, because the native search options are usually rubbish
これらのそれぞれが別々のベンダー関係、別々の請求行、金曜日の午前2時に問題が発生する可能性のある別々のものです。
---
ヘッドレス化が本当に必要な理由
本当の正当な理由がある。アーキテクチャを否定しているわけではない。ただ、無差別に適用されるのに疲れているだけだ。
マルチチャネルコンテンツ配信が最強の議論だ。同じコンテンツがWebサイト、モバイルアプリ、キオスク表示、スマートTV向けインターフェイスに表示される必要がある場合、結合されたCMSは本当に面倒になる。すべての4つのサーフェスが照会する1つのコンテンツAPI？それは本当に意味がある。Seahawkはドバイのホスピタリティクライアント（パブリックファイシング向けサイト、内部スタッフアプリ、プロパティ全体のデジタルサイネージを備えたリゾートグループ）を持っていた。すべてに供給するSanityの単一インスタンス。それは正しい判断だった、終わり。 is the strongest argument. If the same content needs to appear on a website, a mobile app, a kiosk display, and a smart TV interface, a coupled CMS becomes genuinely painful. One content API that all four surfaces query? That actually makes sense. Seahawk had a hospitality client in Dubai, one of those resort groups with a public-facing site, an internal staff app, and digital signage across the property. Single Sanity instance feeding all of it. That was the right call, full stop.
実スケールでのパフォーマンスが2番目の正当な議論だ。CDNエッジから配信される静的に生成されたページは、サーバーの最適化がいかに良好でも、PHP描写のWordPressページが単純にできない方法で高速だ。月間数百万のページビューについて話している場合、これらのミリ秒は意味のある収益差に複合化される。Googleのリサーチはロード速度とコンバージョン率の相関を何度も記録している。理論的ではない。 is the second legitimate argument. Statically generated pages served from a CDN edge are fast in a way that PHP-rendered WordPress pages simply aren't, regardless of how well you've optimised your server. When you're talking about millions of page views per month, those milliseconds compound into meaningful revenue differences. Google's research has documented the correlation between load speed and conversion rate repeatedly, it's not theoretical.
チーム分離も重要だが、フロントエンドとバックエンドの独立したチームを持つ組織にだけ当てはまる。20人のマーケティング部門がエンジニアリングチームから独立して動きたいなら、CMSとフロントエンド間のクリーンなAPI契約があれば、両サイドはお互いをブロックしないで作業できる。 matters too, though only for organisations big enough to have separate front-end and back-end teams. If your content team is a 20-person marketing department that wants to move independently of your engineering team, a clean API contract between CMS and front end lets both sides work without blocking each other.
この3つのケースなら、複雑さのコストに値する価値がある。それ以外は通常、アーキテクチャの衣をかぶった願望的思考に過ぎない。
---
ヘッドレス化が単なる過度なエンジニアリングになる場合
ロンドンの会計事務所向け5ページのブロシュアサイトはヘッドレスアーキテクチャを必要としない。1人の開発者を雇用している200商品のWooCommerceストアも同じだ。
この間違いは絶えず見かけることがある。特にNext.jsを発見したばかりで、すべてに使いたいデベロッパーから。（2019年、小さな慈善クライアント向けのヘッドレスブログを構築し、新規投稿でNetlifyリビルドをトリガーするようにWebhooksを3日間設定して、請求して、何か壊れるたびに電話してくる、自分も有罪だった。）問題は、ヘッドレスがCMSから基盤整備への操作上の複雑性を移動させることだ。WordPressは自らアップデートする。カスタムNext.js + Contentfulパイプラインはそうではない。
ヘッドレスが通常、得られるもの以上のコストがかかる具体的なシナリオ：
- 小さなコンテンツチーム。1～2人がすべてのコンテンツを管理している場合、WordPressのような適切な結合されたCMSの編集体験は、ヘッドレスCMSよりも本当に優れている。プレビュー環境は難しい。インライン編集は廃止される。WYSIWYGは無力化される。, if one or two people manage all the content, the editorial DX of a proper coupled CMS like WordPress is genuinely better than a headless CMS. Preview environments are harder. Inline editing is gone. WYSIWYG is neutered.
- 限定的な予算。適切なヘッドレスビルドは、開発に相応するWordPressビルドの2～3倍の費用がかかり、継続的メンテナンスはより高い。予算が制約の場合、そのお金はほぼいつもどこか他の場所でより良い効果を生じさせる。, a proper headless build costs 2-3x a comparable WordPress build to develop, and the ongoing maintenance is higher. If budget is a constraint, that money almost always does more good elsewhere.
- コンテンツの頻繁な更新と静的生成は、ビルド時間を意味する。1日50記事を配信するニュース発行者は、毎回フルサイト再構築に8分待つことは望まない。(もちろん、段階的な静的再生成は役に立つ。ただ、それ自体の複雑性も追加される。), static generation means build times. A news publisher pushing 50 articles a day doesn't want to wait 8 minutes for a full site rebuild every time. (Yes, incremental static regeneration helps. It also adds its own complexity.)
- 専任のDevOpsがいない場合、誰かがデプロイメントパイプライン、CDN設定、環境変数、プレビュー URL を管理する必要がある。小規模チームでは、その誰かは他のすべての業務も担当している開発者になることがほとんどだ。, someone has to own the deployment pipeline, the CDN config, the environment variables, the preview URLs. On a small team, that someone is usually the developer who's also doing everything else.
---
WordPressヘッドレスの中道
私が異論を唱えたいのは、「従来のWordPress」と「別のCMSを持つ完全なヘッドレス」の間の偽りの二者択一です。特定のクラスのプロジェクトで本当にうまく機能する中道が存在します。
WordPressをヘッドレスバックエンドとして使用し、WP REST API または WPGraphQL を使うと、クライアントが既に知っているコンテンツ管理体験が得られる(率直に言うと、ほとんどのクライアントは WordPress を知っている)。同時に、モダンフロントエンドの柔軟性も手に入る。Contentful に支払う必要はない。誰も再トレーニングされない。編集チームは Gutenberg を使い続ける。フロントエンドは、そのプロジェクトに最適なフレームワークであればなんでもいい。WP REST API or WPGraphQL, gives you the content management experience your clients already know (and honestly, most clients know WordPress), combined with the flexibility of a modern front end. You're not paying for Contentful. You're not retraining anyone. The editorial team keeps Gutenberg. The front end gets to be whatever framework suits the project.
過去4年間でおそらく30～40プロジェクトでこのパターンを使ってきた。特に、WordPress に膨大な既存コンテンツライブラリがあり、移行は望まないが React フロントエンドでパフォーマンスやインタラクティビティが欲しいマーケティングサイトで、うまくいく。トレードオフとしては、WPGraphQL プラグインメンテナンスが面倒になることがあり、PHP サーバーを実行し続ける必要があり、WordPress ホスティングから完全には逃げられない。
---
ヘッドレスCMSの選定：実践的な比較
すべてのヘッドレスCMSが同じではなく、フロントエンドフレームワークの興奮で認められているより、選択はずっと重要です。
Contentful
エンタープライズグレードの選択肢。堅牢な API、良好な SDK、妥当な編集 UI。価格が痛いポイントだ。無料プランは小さなプロジェクトには本当に役立つが、制限に達すると、何か面白いことをする前に月300ドル以上を見ることになる。予算が本物で、適切なロールと権限ワークフローが必要な組織のプロジェクトなら、Contentful に手を伸ばすだろう。
Sanity
ほとんどの中堅ヘッドレスプロジェクトにおける個人的なお気に入り。GROQ クエリ言語は一日使えば表現力が高い、Sanity Studio は Contentful ではできない方法でカスタマイズ可能、リアルタイム協業は素晴らしい。価格はより合理的だ。欠点は、非技術的なコンテンツエディタにとって学習曲線が急であること、Studio が WordPress と十分に異なる外観であるため、常にトレーニング期間があることだ。GROQ query language is expressive once you've spent a day with it, Sanity Studio is customisable in ways Contentful isn't, and the real-time collaboration is excellent. Pricing is more reasonable. The downside is that the learning curve for non-technical content editors is steeper, the Studio looks different enough from WordPress that there's always a training period.
Strapi
オープンソース、自己ホスト、実行は無料。SaaS CMS料金を払わないクライアントがいてサーバーがある場合、Strapiの検討の価値があります。管理パネルはまともです。ただし、ホスティング、アップグレード、セキュリティパッチのメンテナンスは自分で行うことになります。軽くはありません。
Astroとコンテンツコレクション
コンテンツ量が多く、ほぼ静的なサイト、ドキュメント、ブログ、マーケティングサイトには、ローカルコンテンツコレクションを備えた Astro の検討の価値がある。CMS なし。コンテンツはリポジトリ内の Markdown または MDX ファイルとして存在する。開発者はそれを愛する。非技術的なエディタは通常それを嫌う。このルートに進む前に視聴者を知れ。Astro with local content collections is worth considering. No CMS at all. Content lives as Markdown or MDX files in the repo. Developers love it. Non-technical editors usually hate it. Know your audience before going this route.
---
パフォーマンスの議論：数値が実際に示すもの
スピードについてのふわふわした主張ではなく、実際のベンチマークを示そう。
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サイトを完全に下回る可能性がある。アーキテクチャだけでは救いにならない。Web Almanac's data on CMS performance shows that the performance gap between headless-oriented frameworks and traditional coupled CMSes is real but not automatic. A badly implemented Next.js site can absolutely underperform a well-configured WordPress site. Architecture alone doesn't save you.
---
意思決定を行う：私が実際に使うフレームワーク
クライアントからのブリーフが届いて、ヘッドレスが適切かどうか疑問がある場合、僕は推奨を確約する前に5つの質問を通す。
- そのコンテンツは複数のサーフェス上に表示される必要があるか？イエスなら、ヘッドレスは真剣に検討される。ノーなら、主要な正当性を失う。 If yes, headless gets a serious look. If no, it loses a major justification.
- コンテンツチームの技術的な理解度はどのレベルか？非技術的なエディターが厳しい締切の中、慣れないCMSで作業するのは悪い組み合わせだ。 Non-technical editors on a tight deadline in an unfamiliar CMS is a bad combination.
- 予想されるトラフィックとパフォーマンス要件は？合理的なホストで月間5万ビロー未満？WordPressで十分対応できる。 Sub-50,000 monthly visitors on a reasonable host? WordPress handles it fine.
- 継続的なメンテナンス専任の開発者がいるか？「何か壊れたら誰か呼ぼう」というなら、ヘッドレスインフラは負債だ。 If the answer is "we'll call someone when it breaks," headless infrastructure is a liability.
- 実際の予算は？初年度の運用も含めて。構築だけでなく。ホスティング、CMSサブスクリプション、アップデート用の開発者時間。総所有コストだ。 Not just the build. Hosting, CMS subscriptions, developer time for updates. Total cost of ownership.
1、4、5番の質問が揃わなければ、僕は従来型またはハイブリッドアプローチを推奨して安心して眠れる。
---
FAQ
ヘッドレスWordPressは従来のWordPressセットアップより優れているか？
あなたのプロジェクトにとって「より良い」が何を意味するかに完全に依存する。マルチチャネル配信、チーム分離、または高トラフィック量でのパフォーマンスなら、ヘッドレス WordPress、または WordPress を専用ヘッドレス CMS に置き換えることは有意義に改善できる。小規模チームと中程度のトラフィックを持つ標準的なビジネスサイトなら、良いテーマと適切なキャッシングを備えた従来の WordPress の方が、構築しやすく、実行コストが安く、クライアントに引き継ぎやすい。
ヘッドレスは常にパフォーマンスが向上するのか？
いいえ。この神話はプロジェクト予算に本当の損害をもたらしています。CDNから配信される静的に生成されたページはデフォルトでより高速ですが、最適化されていない画像、滝状のAPIリクエスト、適切なキャッシングがないヘッドレスビルドは、チューニングされたWordPressサイトよりもパフォーマンスが落ちる可能性があります。パフォーマンスはアーキテクチャではなく、実行方法次第です。by default, but a poorly configured headless build with unoptimised images, waterfall API requests, and no proper caching can absolutely underperform a well-tuned WordPress site. Performance is about execution, not just architecture.
ヘッドレスに移行する最も安い方法は？
£5/月のVPS上のStrapiとVercelの無料枠に展開したAstroまたはNext.jsを組み合わせれば、非常に低い月額コストで機能するヘッドレスセットアップが実現できます。代わりに開発者の時間を費やすことになります。実は何も無料ではなく、コストがどこに落ちるかを選んでいるだけです。
ヘッドレスビルドは従来のCMSビルドと比べて、通常どのくらいの期間がかかるのか？
私の経験では、ヘッドレスセットアップでの同等のプロジェクトはWordPressよりもおよそ1.5倍から2.5倍長くかかります。特にそれがチームにとって初めてのヘッドレスプロジェクトである場合はそうです。このギャップはチームがスタックに習熟するにつれて狭まります。タイムラインと見積もりにこれを誠実に組み込んでください。「数週間で終わる」と言われたヘッドレスの構築が4ヶ月かかってしまったクライアントは戻ってきません。
ブロックエディタを備えたWordPressが登場したことで、ヘッドレスは今、廃れかけているのか？
いいえ、ただし低い範囲ではユースケースが限定されてきています。Gutenbergは、以前ヘッドレスが正当化されていたいくつかのシナリオを侵食してきました。インタラクティブでコンポーネント駆動型のコンテンツ体験は、今ではWordPressで分離なしでより達成可能です。高い範囲では、大規模なマルチチャネル出版とコマースについては、ヘッドレスはかつてないほど関連性があります。
---
ヘッドレスはステータスシンボルではありません。それはトレードオフです。より多くの柔軟性、より多くの複雑性、より多くのコストと引き換えに、特定の状況で本物のゲインが得られます。コミットする前に状況を理解してください。冒頭で述べたマンチェスターのeコマースクライアントは、結局Shopifyテーマにいくつかのカスタムフロントエンドコンポーネントを加えたものに移行しました。開発オーバーヘッドを60%削減し、読み込み時間はついに改善されました。時には昔のやり方が正しいやり方です。それに恥じることはありません。