2021年、あるクライアントから連絡がありました。不動産会社で、予算も十分、直前までの代理店をクビにしたばかりです。ブリーフはシンプルでした。リスティングポータルの再構築です。前任の開発者は、カスタムメイドのNext.jsアプリケーションのスキャフォルディングに8ヶ月を費やしていました。デモでは素晴らしく見えました。しかし、チームの誰かが単独でプルリクエストとデプロイメントパイプラインなしに更新することはできませんでした。リスティングを管理する不動産エージェントは、回避策としてGoogleシートを使用していました。
私はそれをAdvanced Custom Fields Proを使用したWordPressで約6週間で再構築しました。それ以来、彼らは自分たちで管理してきました。Advanced Custom Fields Proin about six weeks. They've been managing it themselves ever since.
その話はNext.jsに対する主張ではありません。ツールを選ぶ前に問題を理解していなかったことに対する主張です。その逆もやりました。マルチサイトWordPressをクライアントに提供してしまったとき、彼らは本当のReactドリブンアプリケーションが必要だったのに、18ヶ月後にそれが圧力の下で音を立てるのを見ました。
Seahawk Mediaで5,000以上のサイトを構築した後、どのフレームワークが「勝つ」かについて気にしなくなりました。どのフレームワークが納品され、パフォーマンスを発揮し、日曜日の夜11時にあなたを悩ませることのないものかが重要です。Seahawk Media, I've stopped caring about which framework "wins." I care about which one ships, performs, and doesn't come back to haunt you at 11pm on a Sunday.
---
両方のテクノロジーの現在の正直な状態
WordPressはウェブ全体の43%以上を支える。この数字はあちこちで繰り返されすぎて意味が薄れてしまったが、ちょっと考えてみてほしい。43%だ。これは単なるレガシーの慣性ではなく、ネットワーク効果、プラグインエコシステム、ホスティングインフラストラクチャ、そして地球上のすべての共有サーバーに焼き付けられた20年分の制度的知識である。
一方、Next.jsは本番環境のReactフレームワークの主流になった。Vercelの2023年の使用データによると、毎月数千億件のリクエストを処理している。Next.js 13で導入されたApp Routerはサーバーコンポーネントについての考え方を変えた。そしてはい、2023年以前に公開されたたくさんのチュートリアルを壊してしまった。それはいまもDiscordサーバーのあちこちで混乱を引き起こしている。
だが、ここが肝心だ。これら2つのテクノロジーは、Twitter論争が見せるような意味での競合物ではない。WordPressはテーマレイヤーを持つCMSだ。Next.jsはオプションのCMS統合を備えたReactフレームワークである。どちらが実際に優れているかについてのベン図は、要件について具体的になると、重なる部分が非常に少ない。
---
WordPressが本当に無敵な領域
コンテンツの多いサイト、非開発者による管理
ぶっちゃけた話をしよう。クライアントにマーケティングチーム、コンテンツマネージャー、あるいはコードに触れずに公開する必要がある誰かがいるなら、WordPressはほぼ常に正しい答えだ。Gutenbergエディター（2018年からこれとは複雑な関係にあるが）は、ブロックベースの編集体験を非技術者に提供する。実際に機能している。anyonewho needs to publish without touching code — WordPress is almost always the correct answer. The Gutenberg editor, love it or loathe it (I've had a complicated relationship with it since 2018), gives non-technical users a block-based editing experience that actually works.
Reactエコシステムの何もがWordPressの社説体験に箱から出してすぐには及ばない。Sanity.ioは素晴らしいスタジオを持っている、Contentfulは構造化コンテンツには堅牢だ。だが、どちらもWordPressが持つプラグインエコシステムや検索エンジンの親近感には及ばない。平均的なマーケティング採用担当者はWordPressを使ったことがある。彼らはヘッドレスCMSを使ったことはない。
プラグインエコシステムの深さ
WooCommerce、Yoast、Gravity Forms、WP Rocket、ACF Pro。これらは単なるプラグインではなく、独自のエコシステムを持つプラットフォーム全体です。Seahawkが比較的小規模なカタログ（例えば5,000 SKU未満）を持つクライアント向けのeコマースプロジェクトを手がける場合、KinstaやWP Engineの適切なホスティングと組み合わせたWooCommerceで十分対応できます。キャッシング後の読み込み時間が2秒未満、完全な在庫管理、カート放棄回復、Stripe統合など、すべてが1日の午後で設定できます。Kinstaor WP Engine handles it fine. We're talking sub-2-second load times after caching, full stock management, abandoned cart recovery, Stripe integration — all configured in an afternoon.
その機能をShopifyまたはヘッドレスコマースレイヤーを使ったカスタムNext.jsビルドで再現しようとすると、開発期間は数週間、継続的なメンテナンスコストは大多数の中小企業クライアントが正当化できるレベルではありません。
予算とタイムラインの現実
正直なところ、ほとんどのプロジェクトはカスタムReactアプリケーションの予算を持っていません。KadenceやBlocksyといったプレミアムテーマを備えた よく構築されたWordPressサイト、カスタムデータ構造用のACF、パフォーマンス向上用のWP Rocketなら、2～4週間で納品でき、ほぼ誰でもメンテナンスできます。それは制限ではなく、実用性です。
---
Next.jsが複雑性の価値を発揮する場面
インタラクティビティとアプリケーションロジック
2022年、Seahawkはフィンテックプロジェクト、つまり信用分析企業向けのダッシュボードを手がけました。リアルタイムデータフィード、複雑なフィルタリング、ロールベースアクセス制御、3つの異なるデータプロバイダーとのAPI統合です。ヘッドレスWordPressの検討に約2時間費やしましたが、それが完全に不適切なツールであることを認めざるを得ませんでした。NextAuth.js認証とReact Queryによるデータフェッチングを使ってNext.jsで構築しました。今も稼働していて、パフォーマンスも優秀で、クライアントの社内チームが実際に貢献できるコードベースです。
WordPressは技術的にはアプリケーション的なことができます。ただ、本当に動的な領域に押し込もうとするたびに（条件付きロジック付きの複数ステップフォーム、外部APIに接続されたもの、リアルタイムダッシュボード、きめ細かいクライアント側のステート管理が必要なもの、など）、アーキテクチャに対抗するハメになってしまい、アーキテクチャと協調することができません。
プラグイン依存なしのスケール時のパフォーマンス
Next.jsの静的サイト生成（SSG）またはインクリメンタル静的再生成（ISR）は、ほぼ恥ずかしいほど高速なページを生成できます。キャッシング プラグインは不要です。WP Rocketの設定ダイアルは不要です。ページは単なる静的HTMLで、必要な場所でハイドレーションが行われます。
VercelのISRに関するドキュメントは仕組みをよく説明していますが、実際の意味はこうです。50,000個の記事を持つニュース出版社向けNext.jsサイトは、サイト全体を再構築することなく、スケジュールに従って個別ページを再検証できます。これは本当に強力で、WordPressがフラグメント キャッシングで近似できるだけのものです。explains the mechanism well, but the practical implication is this: a Next.js site for a news publication with 50,000 articles can revalidate individual pages on a schedule without rebuilding the entire site. That's genuinely powerful and something WordPress can only approximate through fragment caching.
開発者体験とチーム構成
React ネイティブの開発チームを持つエージェンシーの場合、WordPress開発には過小評価されることが多い実際の学習曲線があります。PHP、WordPressテンプレート階層、フック アーキテクチャ、functions.phpのウサギの穴 — 難しくはありませんが、異なります。才能あるJS開発者を雇いましたが、WordPressテーマのコードベースを見ると最初の2週間は迷ったようでした。functions.phprabbit hole — it's not hard, but itisdifferent. I've hired talented JS developers who looked at a WordPress theme codebase and felt lost for the first two weeks.
逆に、チームがTypeScriptとReactで生活している場合、ContentfulやSanityのようなヘッドレスCMSを備えたNext.jsプロジェクトはより快適な環境です。コードはテスト可能で、型は明示的で、VercelやNetlifyを介したデプロイメント ワークフローは本当に優れています。
---
ヘッドレスWordPress の中間層（そして実際の問題）
多くのエージェンシーは「ヘッドレスWordPress」を妥協案として採用しています — バックエンドCMSとしてのWordPress、フロントエンドとしてのNext.js。ピッチは完璧に聞こえます。編集チームは使い慣れたインターフェイスを保持します。開発者はモダンなフロントエンド スタックを手に入れます。
実際には? 特定の状況では本当に有用で、他の状況では本当に頭痛の種です。
良いケース：goodcases:
- 編集ワークフローが非交渉的な大規模パブリッシングプラットフォームで、フロントエンドのパフォーマンスも厳密な要件である場合
- WordPress インフラに既に投資済みの組織で、コンテンツチームの再トレーニングなしにフロントエンドを近代化したい場合
- ACF のデータモデリングが有効な複雑なコンテンツリレーションシップを持つサイトで、表示層に React が必要な場合
実際の問題点：actual problems:
- WPGraphQL は優れていますが、WordPress コンテキストにおける GraphQL クエリのパフォーマンスデバッグは苦痛です。複雑性のレイヤーを追加することになり、後で問題が生じる可能性があります。is excellent, but debugging GraphQL query performance in a WordPress context is painful. You're adding a layer of complexity that can bite you.
- エディター向けのプレビュー機能——Next.js フロントエンドでドラフト投稿を確認する機能——は常にバグの原因になります。複数のプロジェクトでこれに何日も費やしてきました。
- 2 つの独立したシステムを運用することは、2 つの単一障害点、2 セットのインフラストラクチャコスト、そして 2 つのデプロイメントパイプラインを保守する必要があります。
- リアルタイム機能は依然として厄介です。WordPress REST API からは相当な追加作業なしに WebSocket を得られません。
ヘッドレス WordPress は魔法の中間案ではありません。それ自体の trade-off を持つ第 3 の選択肢であり、特定の要件が本当に複雑性を正当化する場合にのみ意味があります。
---
実際の判断方法（私の真のチェックリスト）
十分なプロジェクトを経験した後、2回目のクライアント通話の前に確認する簡潔な質問セットに絞り込みました。
以下の場合、WordPressを選ぶ傾向があります：
- クライアントまたはそのチームがコンテンツを独立して管理する必要がある
- プロジェクトが主にコンテンツとマーケティングページである（複雑なものでも）
- 予算が£20K未満で、タイムラインが8週間以内である
- E-コマースが必要だが、カタログが約10,000製品以下である
- クライアントが既にWordPressを使用しており、移行に実質的な意義がない
以下の場合、Next.jsを選ぶ傾向があります：
- プロジェクトが重要なインタラクティブ機能またはアプリケーションのような要件を持つ
- チームは主にJS/Reactの開発者で構成されている
- レンダリング戦略（SSG、SSR、ルート毎のISR）を細粒度で制御する必要がある
- フロントエンドデザインシステムがカスタム仕様でReactコンポーネント駆動である
- SanityやContentfulのような最新のヘッドレスCMSと統合する正当な理由がある
- 長期的には、クライアントが社内のJS開発者でフロントエンドを自社保有・拡張したいと考えている
そして、どちらの方向に傾いていようと、立ち止まるべき危険信号がいくつかある：red flagsthat should make you pause regardless of which direction you're leaning:
- Next.jsが「より最新」だと読んだからという理由で要求するクライアント――これは要件ではない
- プロジェクトが本当にアプリケーションロジックを必要としているにもかかわらず、「簡単だから」という理由でWordPressを選択する
- 「フューチャープルーフ」という表現を、実際に将来何が必要かを説明せずに正当化として使う者
---
パフォーマンス：実際の数字を使おう
ここが会話がよく間違う地点だ。Lighthouse スコアを全てのように扱う人が多い。
よく最適化された WordPress サイト — ちゃんとしたホスティング、WP Rocket または FlyingPress、WebP 画像、きちんと構築されたテーマ — は PageSpeed Insights で 90 以上を普通に達成する。Seahawk は WordPress サイトで 95 以上を一貫して納品している。魔法ではなく、ただ適切な設定だ。
クライアント側のデータ取得が至る所にあり、画像が最適化されていない、適切なキャッシング戦略がない、設定の悪い Next.js アプリケーションは 50 台のスコアになる。実際に見てきた。
「高速な WordPress サイト」と「高速な Next.js サイト」の間のギャップは、フレームワーク信奉者が示唆するより遥かに狭い。Google 自身の Core Web Vitals 研究では、オリジナルテクノロジーは実装品質ほど重要でないことを示している。パフォーマンスの低いサイトの大部分のボトルネックは、画像、レンダリングをブロックするリソース、サーバーレスポンスタイム — これらは WordPress または Next.js に本来的に関連した問題ではない。Google's own Core Web Vitals researchshows that origin technology matters far less than implementation quality. The bottlenecks in most poorly performing sites are images, render-blocking resources, and server response times — none of which are inherently WordPress or Next.js problems.
Next.js が本当に提供するものは、パフォーマンスに対する更なるコントロールだ。ルートごとにデータをどのように取得し、ページをいつレンダリングするかについて正確な決定を下すことができる。しかしコントロールはそれを正しく行使した時だけ役に立つ。more controlover performance. You can make precise decisions per-route about how data is fetched and when pages are rendered. But control only helps you if you exercise it correctly.
---
SEO：WordPress はエコシステム上の優位性を持つ、本来的な優位性ではない
ここは定期的に訂正する必要のある誤解だ。WordPress は本来的に SEO に優れているわけではない。適切なサーバー側レンダリングを備えた Next.js アプリケーションは Google に完全にクロール可能だ。<Head> コンポーネント、next-sitemap 経由のサイトマップ生成、JSON-LD 経由の構造化データ — 全てが実現可能だ。<Head>component, sitemap generation vianext-sitemap, structured data via JSON-LD — it's all achievable.
WordPress が持つのは Yoast SEO または Rank Math だ。これは非技術的ユーザーに、メタタイトル、説明、正規 URL、スキーママークアップを管理するためのビジュアルインターフェースを与える。これは技術的なアドバンテージではなく、編集ワークフロー上のアドバンテージだ。
サイトが meta タグと構造化データを理解する開発者によって管理される場合、Next.js SEO の実装は難しくありません。SEO コンサルタントやマーケティング マネージャーがチケットを切らずにページ タイトルを調整する必要がある場合は、WordPress を選択してください。
---
FAQ
WordPress は古くて最新フレームワークに置き換わっているのではないですか？
WordPress は少なくとも 2014 年からこの議論を真剣に聞き始めた時以来、「置き換わっている」状態にあります。それは起きていませんし、起きると予想していません。問題は WordPress が最新かどうかではなく、あなたが抱えている問題を解決するかどうかです。膨大な数のウェブサイトにとって、それは解決しています。Automattic は Gutenberg とフルサイト編集エクスペリエンスに継続的に大きく投資しています。進化していますが、Twitter のフィードを興奮させるような方法ではありません。
React フロントエンドを備えたバックエンドとして WordPress を使用できますか？
はい、これはヘッドレス WordPress であり、上記でトレードオフについて説明しました。要約すると：WPGraphQL または REST API を使用してコンテンツを配信し、Next.js でフロントエンドをビルドしてください。機能します。ただ複雑さが増します。要件が実際に求めている場合のみ実行してください。アーキテクチャとして興味深く聞こえるからではなく。
Next.js サイトは WordPress と比べてビルドにどのくらいの時間がかかりますか？
スコープに本当に依存しますが、同等のマーケティング サイトの場合、Next.js は初回デリバリーのビルドに通常 40～60% の時間がかかります。コンポーネントをスクラッチから書き、デザイン システムをセットアップし、CMS を統合し、デプロイメントを構成しています。プレミアム テーマと ACF を使用した WordPress はより高速に進むことができます。Next.js が時間投資を回収する場所は、長期的なスケーラビリティと開発者の使いやすさです。ただし、チーム構成がそれを正当化する場合に限ります。
Astro や Remix などの他のフレームワークについてはどうですか？
知っておく価値がある。特にAstroは、コンテンツが豊富な静的サイトに興味深く、Seahawk Mediaでも小規模プロジェクトで試験運用しています。Remixはデータロードモデルの点で説得力があります。ただし、WordPressのようなエコシステムの成熟度やクライアント認知度、またはNext.jsのエンタープライズ採用には及びません。今のところ、ほとんどのエージェンシーの判断は、WordPressかNext.jsか、その他は隙間市場での検討になります。
クライアントには常に「より優れた」技術的な選択肢を推奨すべきでしょうか。
いいえ。クライアントのチームが保守できない最良の技術的選択肢は、彼らが実際に使用できる次点の選択肢よりも悪いものです。私はこれを何度も痛い目で学びました。アーキテクチャ図だけでなく、関わる人間にとって機能するものをデリバリーしてください。
---
実際のスキルはWordPressを知っていることでもなく、Next.jsを知っていることでもありません。それぞれをいつ使うべきかを知ることです。そしてあなた自身とクライアントに対して正直に、彼らの現実に基づいて、あなたの好みではなく判断を下すことです。
2021年の不動産クライアント？今でもWordPress上です。今でも自分たちでリスティングを管理しています。日曜夜の電話はありません。