2021年、不動産会社のクライアントから連絡があった。予算もまあまああり、前のエージェンシーをちょうど解雇したばかりだった。ブリーフはシンプルだった。リスティングポータルを再構築することだ。前任の開発者は8カ月かけてカスタムのNext.jsアプリケーションを組み立てていた。デモでは素晴らしく見えた。ただし、チーム内の一人がプルリクエストとデプロイメントパイプラインなしに更新することができなかった。リスティングを管理する不動産エージェントは、回避策としてGoogleシートを使用していた。
重要なポイント：エディターが自律性を必要とし、コンテンツが日々変わる場合はWordPressが勝利します。サイトが製品であり、エンジニアリングがその背後にある場合はNext.jsが勝利します。フレームワークではなく、チームが決めるべきです。
Advanced Custom Fields Proを使ってWordPressで再構築し、約6週間で完成させました。それ以来、彼ら自身で管理しています。
その話はNext.jsに対する異論ではない。ツールを選ぶ前に問題を理解していないことに対する異論だ。逆のこともやったことがある。React駆動アプリケーションが必要だったクライアントにWordPress multisiteを渡し、18カ月後にそれが圧力の下で軋むのを見たことがある。
Seahawk Mediaで12,000以上のサイトを構築してきた経験から、どのフレームワークが「勝つ」かはもう気にしていません。重視しているのは、実際に運用できて、パフォーマンスが出て、日曜日の夜11時に問題を起こさないかということです。
---
両方のテクノロジーの現在の正直な状態
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年からそれと複雑な関係を持ってきた）、非技術的なユーザーに実際に機能するブロックベースの編集体験を提供する。
Reactエコシステムには、WordPressの編集体験の箱から出た直後に近いものは何もない。Sanity.ioは美しいスタジオを持ち、Contentfulは構造化コンテンツに適しているが、どちらもWordPressが持つプラグインエコシステムや検索エンジンの親熟度を持たない。一般的なマーケティング採用者はWordPressを使ったことがある。ヘッドレスCMSを使ったことはない。
プラグインエコシステムの深さ
WooCommerce、Yoast、Gravity Forms、WP Rocket、ACF Pro。これらは単なるプラグインではなく、独自のエコシステムを持つプラットフォーム全体だ。Seahawkが控えめなカタログを持つクライアント向けのeコマースプロジェクト（例えば、5,000SKU以下）を行う場合、WooCommerceをKinstaまたはWP Engineの適切なホスティングセットアップと組み合わせれば問題なく処理できる。キャッシング後のサブ2秒のロード時間、完全な在庫管理、放棄カートリカバリー、Stripe統合、すべて午後のうちに設定できる話だ。
その機能をShopifyまたはヘッドレスコマースレイヤーを使ったカスタムNext.jsビルドで再現しようとすると、開発期間は数週間、継続的なメンテナンスコストは大多数の中小企業クライアントが正当化できるレベルではありません。
予算とタイムラインの現実
正直なところ、ほとんどのプロジェクトにはカスタムReactアプリケーション用の予算がない。KadenceまたはBlocksyのようなプレミアムテーマで構築されたよく出来たWordPressサイト、カスタムデータ構造用のACF、パフォーマンス用のWP Rocketは2～4週間で納品でき、ほぼ誰でもメンテナンスできる。それは制限ではなく、実用性だ。
---
Next.jsが複雑性の価値を発揮する場面
インタラクティビティとアプリケーションロジック
2022年のことですが、Seahawkはフィンテック系のプロジェクトに取り組んでいました。クレジット分析企業向けのダッシュボードです。リアルタイムデータフィード、複雑なフィルタリング、ロールベースのアクセス制御、3つの異なるデータプロバイダーとのAPI統合が必要でした。headless WordPressを約2時間検討してみましたが、結局のところそれは完全に不適切なツールだと認めざるを得ませんでした。Next.jsで構築し、認証にはNextAuth.jsを、データ取得にはReact Queryを使いました。今も稼働していて、パフォーマンスも良好です。何より、クライアントの内部チームが実際に貢献できるコードベースになっています。
WordPressは技術的にはアプリケーションらしいことができます。しかし本当の意味で動的な領域に踏み込もうとするたびに、条件ロジック付きの複数ステップフォーム、外部APIへのデータ送信、リアルタイムダッシュボード、細粒度のクライアント側ステート管理が必要な場合、私はアーキテクチャと戦っていることに気づきます。
プラグイン依存なしのスケール時のパフォーマンス
Next.jsの静的サイト生成（SSG）またはインクリメンタル静的再生成（ISR）は、ほぼ恥ずかしいほど高速なページを生成できます。キャッシング プラグインは不要です。WP Rocketの設定ダイアルは不要です。ページは単なる静的HTMLで、必要な場所でハイドレーションが行われます。
VercelのISRに関するドキュメンテーションは仕組みをよく説明していますが、実際の意味合いはこうです。50,000本の記事を扱うニュース配信向けNext.jsサイトは、サイト全体を再構築することなく、スケジュールに従って個別ページを再検証できます。これは本当に強力な機能で、WordPressではフラグメントキャッシュでしか近似できません。
開発者体験とチーム構成
React開発チームを持つエージェンシーであれば、WordPress開発には過小評価されることが多い学習曲線があります。PHP、WordPressのテンプレート階層、フック・アーキテクチャ、functions.phpの深淵、こうしたものは難しくありませんが、異なるものです。有能なJS開発者を雇った経験がありますが、彼らがWordPressテーマのコードベースを見ると、最初の2週間は迷子になっていました。
逆に、チームがTypeScriptとReactで生活している場合、ContentfulやSanityのようなヘッドレスCMSを備えたNext.jsプロジェクトはより快適な環境です。コードはテスト可能で、型は明示的で、VercelやNetlifyを介したデプロイメント ワークフローは本当に優れています。
---
ヘッドレスWordPress の中間層（そして実際の問題）
多くのエージェンシーは「headless WordPress」を折衷案として採用しています。WordPressをCMSバックエンド、Next.jsをフロントエンドとする構成です。その説明は完璧に聞こえます。編集チームは使い慣れたインターフェースを保持でき、開発者はモダンなフロントエンドスタックを手に入れられます。
実際には? 特定の状況では本当に有用で、他の状況では本当に頭痛の種です。
うまくいくケース：
- 編集ワークフローが非交渉的な大規模パブリッシングプラットフォームで、フロントエンドのパフォーマンスも厳密な要件である場合
- WordPress インフラに既に投資済みの組織で、コンテンツチームの再トレーニングなしにフロントエンドを近代化したい場合
- ACF のデータモデリングが有効な複雑なコンテンツリレーションシップを持つサイトで、表示層に React が必要な場合
実際の問題点：
- WPGraphQLは優れていますが、WordPressの環境下でGraphQLクエリのパフォーマンスをデバッグするのは大変です。複雑さのレイヤーを追加することになり、それが問題を引き起こす可能性があります。
- エディタ向けのプレビュー機能、つまり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開発者でフロントエンドを自社保有・拡張したいと考えている
そして、どちらの方向に進むにしても一歩立ち止まるべき危険信号がいくつかあります：
- クライアントがNext.jsを要求するのは「より最新だ」と読んだから。それは要件ではありません。
- プロジェクトが本当にアプリケーションロジックを必要としているにもかかわらず、「簡単だから」という理由でWordPressを選択する
- 「フューチャープルーフ」という表現を、実際に将来何が必要かを説明せずに正当化として使う者
---
パフォーマンス：実際の数字を使おう
ここが会話がよく間違う地点だ。Lighthouse スコアを全てのように扱う人が多い。
最適化されたWordPressサイト、まともなホスティング、WP RocketやFlyingPress、WebP画像、適切に構築されたテーマであれば、PageSpeed Insightsで90以上を常に獲得します。Seahawkは一貫して95以上を達成するWordPressサイトを納品してきました。魔法ではなく、単に適切な設定です。
クライアント側のデータ取得が至る所にあり、画像が最適化されていない、適切なキャッシング戦略がない、設定の悪い Next.js アプリケーションは 50 台のスコアになる。実際に見てきた。
「高速なWordPressサイト」と「高速なNext.jsサイト」の差は、フレームワーク信奉者が示唆するより遥かに狭いです。Googleの独自のCore Web Vitals研究によれば、オリジンの技術は実装品質ほどには重要ではありません。パフォーマンスの低いサイトのボトルネックはほとんどの場合、画像、レンダリングをブロックするリソース、サーバーレスポンスタイムであり、これらはWordPressやNext.jsに本質的に内在する問題ではありません。
Next.jsが本当に提供するのは、より高度なパフォーマンスコントロールです。ルートごとにデータをどのように取得し、ページをいつレンダリングするかについて、正確な判断ができます。ただしコントロールは、正しく行使してこそ役に立ちます。
---
SEO：WordPress はエコシステム上の優位性を持つ、本来的な優位性ではない
定期的に訂正する必要のある誤解があります。WordPressはSEOに本質的に優れているわけではありません。適切なサーバーサイドレンダリングを備えたNext.jsアプリはGoogleで完全にクロール可能です。<Head>コンポーネント、next-sitemapによるサイトマップ生成、JSON-LDによる構造化データ、すべて実現可能です。
WordPress が持つのは Yoast SEO または Rank Math だ。これは非技術的ユーザーに、メタタイトル、説明、正規 URL、スキーママークアップを管理するためのビジュアルインターフェースを与える。これは技術的なアドバンテージではなく、編集ワークフロー上のアドバンテージだ。
サイトがメタタグと構造化データを理解する開発者によって管理される場合、Next.js SEOの実装は難しくありません。サイトがSEOコンサルタントやマーケティングマネージャーをページタイトル調整のためにチケットを切らずに使用する必要がある場合は、WordPressを選んでください。
---
FAQ
WordPress は古くて最新フレームワークに置き換わっているのではないですか？
WordPressは少なくとも2014年以降、「置き換わる」と言われ続けてきました。私が真剣にその議論を聞き始めたのもその時期です。しかし実際には起きていないし、今後も起きるとは思いません。問題はWordPressが最新技術かどうかではなく、あなたが抱えている課題を解決するかどうかです。膨大な数のWebサイトにとって、WordPressはそれを実現します。AutomatticはそれでもなおGutenbergとFull Site Editingの経験に多大な投資を続けています。進化しているのです。ただTwitterのフィードを沸かせるような方向ではないだけです。
React フロントエンドを備えたバックエンドとして WordPress を使用できますか？
はい、これはヘッドレス WordPress であり、上記でトレードオフについて説明しました。要約すると：WPGraphQL または REST API を使用してコンテンツを配信し、Next.js でフロントエンドをビルドしてください。機能します。ただ複雑さが増します。要件が実際に求めている場合のみ実行してください。アーキテクチャとして興味深く聞こえるからではなく。
Next.js サイトは WordPress と比べてビルドにどのくらいの時間がかかりますか？
本当はスコープに左右されますが、同等のマーケティングサイトであれば、Next.jsは通常、初回配信まで40～60%長い時間がかかります。コンポーネントをゼロから書いて、デザインシステムを構築し、CMSを統合し、デプロイメントを設定するからです。WordPressにプレミアムテーマとACFを組み合わせれば、より短い時間でずっと先に進めます。Next.jsが時間投資を回収できるのは、長期的なスケーラビリティと開発者の使いやすさにおいてです。ただしチームの構成がそれを正当化する場合に限ります。
Astro や Remix などの他のフレームワークについてはどうですか？
知っておく価値がある。特にAstroは、コンテンツが豊富な静的サイトに興味深く、Seahawk Mediaでも小規模プロジェクトで試験運用しています。Remixはデータロードモデルの点で説得力があります。ただし、WordPressのようなエコシステムの成熟度やクライアント認知度、またはNext.jsのエンタープライズ採用には及びません。今のところ、ほとんどのエージェンシーの判断は、WordPressかNext.jsか、その他は隙間市場での検討になります。
クライアントには常に「より優れた」技術的な選択肢を推奨すべきでしょうか。
いいえ。クライアントのチームが保守できない最良の技術的選択肢は、彼らが実際に使用できる次点の選択肢よりも悪いものです。私はこれを何度も痛い目で学びました。アーキテクチャ図だけでなく、関わる人間にとって機能するものをデリバリーしてください。
---
本当のスキルはWordPressを知ることでも、Next.jsを知ることでもありません。それぞれをどの場面で使い分けるか、そして自分の好みではなくクライアントの現実に基づいてその判断を下す正直さを持つことです。
2021年の不動産クライアント？今でもWordPress上です。今でも自分たちでリスティングを管理しています。日曜夜の電話はありません。