あるクライアントが2021年に電話をくれた。マンチェスターの中堅規模のeコマースブランド、SKU数は約40,000、複数の地域ストアフロント。彼らは激怒していた。Next.jsフロントエンドを備えたヘッドレスShopifyの構築に18ヶ月かけて£180,000を費やしたのに、ページロード時間は置き換えたShopifyテーマよりも遅くなっていたのだ。開発チームは1人の契約社員から4人に増えていた。コンテンツエディターはブログ記事を公開するだけのために開発者が同席する必要があった。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.
ヘッドレスは彼らに未来として売られてきた。技術的には、その通りだ。しかし誰も、運用に実際どれだけのコストがかかるかを説明しなかった。
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を配信 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時に問題が発生する可能性のある別々のものです。
ヘッドレス化が本当に必要な理由
ヘッドレス化が本当に必要な理由
ここがポイントだ。実際に、正当な理由が存在する。私はこのアーキテクチャを否定していない。ただ、無分別に適用されるのに疲れているだけだ。
マルチチャネル対応のコンテンツ配信が最も強い理由だ。同じコンテンツをウェブサイト、モバイルアプリ、キオスク表示、スマートテレビインターフェースに出す必要があるなら、結合型CMSは本当に厄介になる。4つのサーフェスすべてが照会する1つのコンテンツAPIなら、実際に意味がある。Seahawk Mediaはドバイのホテルクライアントを抱えていた。公開ウェブサイト、スタッフ向け内部アプリ、施設全体のデジタルサイネージを持つリゾートグループだ。1つの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ストアも同じだ。
ヘッドレス化が単なる過度なエンジニアリングになる場合
ロンドンの会計事務所向け5ページのブロシュアサイトはヘッドレスアーキテクチャを必要としない。1人の開発者を雇用している200商品のWooCommerceストアも同じだ。
これは特にNext.jsを発見したばかりの開発者からよく見かけるミスです。彼らはそれをあらゆるものに使いたがります。（2019年の私自身も同じ罪を犯しました。小さな慈善団体のクライアント向けにヘッドレスブログを構築し、新しい投稿でNetlifyの再ビルドをトリガーするウェブフックの設定に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問い言語は1日使えば表現力があり、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で達成しやすくなっています。高位層では、大規模なマルチチャネルパブリッシングとコマースのために、ヘッドレスはこれまで以上に関連性があります。
---
Headlessは身分の象徴ではありません。トレードオフです。より高い柔軟性、より高い複雑性、より高いコストと引き換えに、特定の状況において本当の利益を得られます。コミットする前に、その状況を理解してください。冒頭で言及したマンチェスターのeコマースクライアントは、最終的にカスタムフロントエンドコンポーネントを備えたShopifyテーマに移行しました。開発のオーバーヘッドを60%削減でき、ロードタイムもついに改善されました。時には古いやり方が正しいやり方です。それに恥ずかしさはありません。