2021年、あるクライアントから連絡があった。不動産会社で、予算もそこそこあり、前のエージェンシーをちょうど解雇したばかりだった。ブリーフはシンプルだった。リスティングポータルをリビルドすること。前の開発者は8ヶ月かけてカスタムのNext.jsアプリケーションをスキャフォールディングしていた。デモでは素晴らしく見えた。チームの誰もが、プルリクエストとデプロイメントパイプラインなしにそれを更新することができなかった。リスティングを管理する不動産エージェントは、Google Sheetを回避策として使っていた。
重要なポイント：エディターが自律性を必要とし、コンテンツが日々変わる場合はWordPressが勝利します。サイトが製品であり、エンジニアリングがその背後にある場合はNext.jsが勝利します。フレームワークではなく、チームが決めるべきです。WordPress wins when editors need autonomy and content changes daily; Next.js wins when the site is a product with engineering behind it. The team decides, not the framework.
Advanced Custom Fields Proを使ってWordPressで再構築し、約6週間で完成させました。それ以来、彼ら自身で管理しています。WordPress with Advanced Custom Fields Pro in about six weeks. They've been managing it themselves ever since.
その話はNext.jsに対する反論ではない。問題を理解する前にツールを選ぶことに対する反論だ。私は反対のこともやった。クライアントにWordPress multisiteを渡したが、彼らは本当のReactで駆動されるアプリケーションが必要だった。18ヶ月後、それが圧力の下で軋む様子を見た。
Seahawk Mediaで12,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サーバーのあちこちで混乱を引き起こしている。Vercel's 2023 usage data showed it processing hundreds of billions of requests a month. The App Router introduced in Next.js 13 changed how people think about server components -- and yes, it also broke a lot of tutorials published before 2023, which is still causing confusion in Discord servers everywhere.
だが、ここが肝心だ。これら2つのテクノロジーは、Twitter論争が見せるような意味での競合物ではない。WordPressはテーマレイヤーを持つCMSだ。Next.jsはオプションのCMS統合を備えたReactフレームワークである。どちらが実際に優れているかについてのベン図は、要件について具体的になると、重なる部分が非常に少ない。
---
WordPressが本当に無敵な領域
コンテンツの多いサイト、非開発者による管理
ぶっちゃけ言う。クライアントがマーケティングチーム、コンテンツマネージャー、またはコードに触れずに公開する必要がある誰かを持っているなら、WordPressはほぼ常に正しい答えだ。Gutenbergエディタ、それを愛しているか嫌っているか（2018年からそれとの複雑な関係を持っている）、非技術ユーザーにブロックベースの編集体験を与える。anyone who 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を使ったことがない。Sanity.io has a beautiful studio, Contentful is solid for structured content -- but neither has the plugin ecosystem or the search-engine familiarity that WordPress has. Your average marketing hire has used WordPress before. They haven't used a headless CMS.
プラグインエコシステムの深さ
WooCommerce、Yoast、Gravity Forms、WP Rocket、ACF Pro。これらはプラグインに過ぎず、独自のエコシステムを持つ全体的なプラットフォームだ。Seahawkがそこそこのカタログ（例えば5,000 SKU未満）を持つクライアント向けのe-commerceプロジェクトをやるとき、WooCommerceをKinstaまたはWP Engine上のまともなホスティング設定と組み合わせると、それはうまく処理する。キャッシング後の2秒以下のロード時間、フル在庫管理、放棄されたカート回復、Stripe統合について話している。すべて午後で構成された。Kinsta or 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時間検討した後、それが完全に不適切なツールだと認めざるを得ませんでした。Next.jsで構築し、認証にはNextAuth.jsを、データフェッチにはReact Queryを使いました。今でも動作していますし、速度も変わりません。クライアントの内部チームが実際に貢献できるコードベースになっています。
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.php rabbit hole -- it's not hard, but it is different. 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」を折衷案として選んでいます――バックエンドはWordPress、フロントエンドはNext.js。売り文句は完璧に聞こえます。編集チームは使い慣れたインターフェースを保てる、開発者は最新のフロントエンドスタックを得られる。
実際には? 特定の状況では本当に有用で、他の状況では本当に頭痛の種です。
うまくいくケース：good cases:
- 編集ワークフローが非交渉的な大規模パブリッシングプラットフォームで、フロントエンドのパフォーマンスも厳密な要件である場合
- 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 flags that should make you pause regardless of which direction you're leaning:
- クライアントが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に固有の問題ではありません。Google's own Core Web Vitals research shows 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 control over 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 via next-sitemap, structured data via JSON-LD -- it's all achievable.
WordPress が持つのは Yoast SEO または Rank Math だ。これは非技術的ユーザーに、メタタイトル、説明、正規 URL、スキーママークアップを管理するためのビジュアルインターフェースを与える。これは技術的なアドバンテージではなく、編集ワークフロー上のアドバンテージだ。
サイトが構造化データとメタタグを理解する開発者によって管理される場合、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上です。今でも自分たちでリスティングを管理しています。日曜夜の電話はありません。