NEXT.JS、ASTRO、WORDPRESS IN 2026

Next.js、Astro、WordPress のどれを選ぶか——これは起業家やエージェンシークライアントから最も頻繁に受ける質問です。答えはほぼ常に彼らの予想と異なります。この判断は「フレームワーク対フレームワーク」ではありません。判断軸は「インテント」です。実際に何を構築しているのか、ローンチ後は誰が保守するのか、そして最も避けたい失敗モードは何か。この3つに正直に向き合えば、フレームワークの選択は自ずと決まります。

以下は、12年間にわたり3つすべてを本番運用してきたオペレータからの視点です。Seahawk Media では毎週 WordPress、Next.js、Astro を実行していますが、多くの場合、同じクライアント案件の異なるライフサイクル段階で使い分けています。いずれも本当に優れたソフトウェアです。いずれも特定の状況では間違った答えになります。このガイドはマーケティングページのツアーではなく、私が実際に使っている判断フローです。

Next.js

Next.jsはReactフレームワークであり、サーバーレンダリング層、ファイルシステムルーティング、静的HTML、サーバーレンダリングHTML、またはその中間を生成するビルドシステムを備えています。AppRouterモデルはバージョン15以降安定し、React Server Componentsがデフォルトとなり、このフレームワークはグリーンフィールドReactプロジェクトの主流な選択肢です。Vercelが提供し、NetlifyとCloudflareが実行し、エコシステムは非常に広大です。

Astro

Astroはコンテンツファーストのフレームワークで、デフォルトではJavaScriptを一切出荷せず、インタラクティビティが必要な場所にのみReact、Vue、Svelte、またはSolidコンポーネントを追加できます。その得意分野はコンテンツサイト、マーケティングページ、ブログ、ドキュメント、パンフレットサイトです。メンタルモデルは「デフォルトではHTML、必要な箇所ではJS」で、これはすべてがJavaScriptであることを前提とするReactの仮定を逆転させています。

WordPress（クラシックおよびヘッドレス）

WordPressはPHPで動作し、MySQLデータベースに存在し、ウェブ上で最大のプラグインエコシステムを持っています。2026年現在、WordPressは2つの運用モードを持ちます。クラシック（WordPressがバックエンドとフロントエンド両方をレンダリング）とヘッドレス（WordPressがAPIおよびCMS役割を果たし、Next.js、Astro、またはNuxtがレンダリングを処理）です。ヘッドレスWordPressは、エディターを使うWordPressの世界とエンジニアを使うNext.jsの世界を橋渡しするものです。

Next.jsはプロダクト型サイトに勝ります。具体的には、チームがReactに精通しており、プロダクトが一般的なマーケティングサイトを超えたステートフルなインタラクティビティを持ち、データモデルがカスタムであり（一般的なブログやCMSではない）、エンジニアリングチームが長年にわたってコードベースを所有するという場合です。

私が出荷した具体的な例は、マーケティングフロントドアを備えたSaaS ダッシュボード、ログインと個人用コンテンツを備えたマーケットプレイス、深くカスタマイズされたデモを備えた開発者ツール企業サイト、HostList.ioのようなマルチテナント型ディレクトリプラットフォームです。これらはすべて、React Server Components、Next.jsのデータ取得プリミティブ、および同じフレームワーク内で静的マーケティングページと認証されたアプリサーフェス間のシームレスな遷移から恩恵を受けます。

Next.jsが急速にコストが高くなるのは、非技術的なエディターを持つコンテンツが多いサイトです。CMS統合は常にカスタムであり、編集ワークフローは常に再構築され、それを維持するチームは永続的にエンジニアリング人員を配置する必要があります。編集チームが3人のライターで、エンジニアの関与なしに公開したいのであれば、Next.jsは間違った戦いをしています。

Astroはコンテンツ重視のサイト、特に強いデザイン言語とクリーンなコンポーネントを配信する能力を備えたエンジニアリング体制があるサイトに最適です。具体的には、マーケティングサイト、ドキュメンテーションハブ、パンフレットサイト、ポートフォリオ、エージェンシーサイト、パフォーマンスがブランドの一部であるブログといった用途です。訪問者体験が読むまたはスキャニングであり、ステートフルなフローとのインタラクションではないサイトの種類です。

本サイト gautamkhorana.com はAstroで構築されています。2026年のデザイン重視のエージェンシーや個人プロダクトローンチの多くのマーケティングサイトも同じです。論理は単純です。デフォルトJavaScriptがゼロということは、Lighthouseのスコアが楽々100になり、コンテンツモデルがプレーンなマークダウンまたはSanityまたはSupabaseであり、ビルドパイプラインが任意のCDN上で無限トラフィックに耐える静的HTMLを生成します。私がAstroで配信したサイトは、ローンチ以来、パフォーマンスリグレッションがまったくありません。少数ではなく、ゼロです。

Astroが間違った選択肢となる場合、それは大規模な認証済みユーザーステート、フロントエンド複雑性がコンテンツ複雑性をはるかに上回る場合、またはチームがコードベース全体でReactイディオムに移行する必要がある場合です。Astroは軽量であることに優れていますが、重いプロダクトを構築するには間違ったツールです。

WordPressはコンテンツ重視のサイト、エディター体験がレンダリングパフォーマンスより重要な場合、プラグインエコシステムが実際の問題を解決する場合、そしてチームが継続的なエンジニアリング体制を構築しない場合に最適です。/guides/wordpress/ ピラーが全詳細をカバーしており、短い要約は以下の通りです。非技術的なエディターがいる場合、プラグインレバレッジが重要であり、3年間の総所有コスト(TCO)が決定指標であれば、WordPressはコンテンツ重視のサイトの大多数にとって引き続き正しい答えです。

具体的には、定期的な編集更新を伴うパンフレットサイト、地域の複雑な税務処理をWooCommerceが解決するeコマースサイト、MemberPressまたはRestrict Content Proがワークフローをすぐに提供するメンバーシップサイト、ニッチなプラグインがモデルの90%を処理する不動産またはジョブボードサイト、クライアントが今後の変更にデベロッパーを配置したくない明確な希望があるサイトです。

ヘッドレスWordPressはブリッジアーキテクチャです。エディター体験とプラグインエコシステムのためにWordPressを保持しつつ、パフォーマンスとデザインコントロールのためにNext.jsまたはAstroでフロントエンドをレンダリングします。狭いながらも実在する一連のケースで効果があります。

以下の場合に効果があります。編集チームがWordPressにコミットしており移行しない場合だが、マーケティングサイトがパフォーマンスに関わる場合(高トラフィック、高額な広告費、ブランド的に重視するLighthouseスコア)。デザイン言語が異なり過ぎてWordPressテーマレイヤーでは対応できないが、コンテンツモデルが本当にWordPress的である場合(投稿、ページ、カスタム投稿タイプ、ACFフィールド)。会社が編集的成熟度とエンジニアリング的成熟度の両方を備えており、両方の体制構築に余裕がある場合です。

以下の場合には効果がありません。チームが編集的成熟度もエンジニアリング能力も備えていない場合(二重に支払うことになる)、プロジェクトが本当に月に1回編集されるパンフレットサイトである場合、予算が二重スタック保守に対応不可能なほど限定的である場合です。2026年のヘッドレスWordPressを実行する現実的なコストは、12ヶ月間の従来型WordPressの実行コストの約1.5倍から2倍です。パフォーマンスとデザインの利得がそれを正当化することを確認してください。

Next.js の文脈では、レンダリング戦略の選択はフレームワークの選択そのものよりもコスト上の影響が大きい。4つのオプションは以下の通り：

Static Site Generation (SSG)

すべてのページがビルド時に構築され、CDN からプレーン HTML として配信される。最も安価で、最速で、最も安全。マーケティングサイトやブログに適した正当なデフォルト。制約は、コンテンツの変更にはフルリビルドと再デプロイが必要ということ。数千ページ未満のサイトなら問題ない。数万ページのサイトでは、ビルド時間がボトルネックになる。

Incremental Static Regeneration (ISR)

ページはビルド時に静的に生成され、その後オンデマンドまたはスケジュールで再検証される。スケールするコンテンツサイト向けの中間的なソリューション。ほとんどのチームが直面する落とし穴：Vercel での ISR 課金は呼び出し単位であり、9万1000ページで頻繁に再検証する場合、月間数百万イベントのレベルに達したことがある。Deluxe Astrology サイトに「1週間に本番マージは2回まで」という明確なルールがあるのは、各マージがおよそ 600 万件の ISR 書き込みイベントを発火させるからだ。ISR は優れたテクノロジーだが、スケールでは現実的なコスト曲線がある。

Server-Side Rendering (SSR)

すべてのリクエストでページをレンダリング。認証済みダッシュボード、パーソナライズされたコンテンツ、ページコンテンツがリクエストしたユーザーに依存するあらゆるケースに適した答え。コスト モデルはリクエスト単位の CPU であり、トラフィックの多い公開ページではすぐに高額になる。マーケティングページでは SSR を避けよ。

React Server Components (RSC)

Next.js 15 のデフォルトで、上記と組み合わせて使用されることが多い。RSC はデータ取得をサーバーにプッシュし、クライアントに送信する JavaScript を削減する。メンタルモデルは調整が必要だが、パフォーマンスと DX の利点は実在する。2026 年の新しい Next.js の仕事のほとんどはデフォルトで RSC を使用すべき。

Next.js または Astro でヘッドレスに進む場合、CMS レイヤーの決定はフレームワークに次いで 2 番目に重要です。すべてのプロジェクトで評価する 5 つの実行可能なオプション：

Sanity

新しいヘッドレスプロジェクトの私のデフォルト推奨。スキーマアズコードのアプローチは市場で最もクリーンなコンテンツモデルであり、エディタ体験は非技術的なエディタにとって本当に優れており、GROQ クエリ言語はほとんどのコンテンツ形状に対して GraphQL よりも柔軟です。価格は合理的にスケーリングします。トレードオフ：WordPress よりプラグンエコシステムが少なく、カスタム編集ワークフローで時々摩擦が生じます。

ヘッドレス WordPress（WPGraphQL または REST 経由）

エディタの WordPress 親和性が主な制約である場合の正解です。WPGraphQL は 2026 年で成熟しており、Faust.js スタックは Next.js 統合を簡単にします。コスト：WordPress とフロントエンドの両方を保守する必要があります。これは 2 つの世界を橋渡しする固有のオーバーヘッドです。

Supabase

コンテンツモデルが長文散文よりも構造化データである場合の選択肢：ディレクトリ、リスティング、プログラマティック SEO サイト、テーブル形式のもの。HostList.io は Supabase で動作します。コスト：Supabase はコンテンツレイヤーの配慮がある データベースであり、編集上の意味での CMS ではありません。エディタは好みません。

Contentful

強力なワークフロー機能とロケール対応を備えたエンタープライズレベルの選択肢。高い層での価格はすぐにスケーリングします。チームが正式なコンテンツガバナンスと予算に見合う場合に適しています。

Payload、Strapi

データレジデンシーやコスト管理が主な関心事である場合のセルフホスト型オプション。どちらも2025年までに大幅に成熟した。CMS層を自分たちで所有したい技術力を持つチーム向け。

デプロイ先の選択は、時間とともに複合効果をもたらす3番目の決定事項。実行可能なホスト3つ：

Vercel

Next.js公式ホスト、最もスムーズな開発者体験、最高額の価格帯。帯域幅とISR呼び出しはほとんどのチームが請求書が届くまで見落とすコストレバー。DXの優位性のためにVercelでサイトを実際に運用しているが、コスト曲線は予想より急峻。ISRを大規模に使用している場合、最初の見積もりの少なくとも2倍の予算を計上する必要がある。

Netlify

AstroとNext.jsの静的レンダリング向けに優れており、フルRSC対応Next.js App Routerではやや洗練さに欠ける。価格予測はVercelより予測可能。ビルド分単価モデルが注視すべきレバー。本サイトはNetlifyで運用されている。

Cloudflare PagesとWorkers

2026年における最高のコスト対パフォーマンス、規模での運用で他の2つより圧倒的に低コスト、基盤ネットワークはグローバル配信において比類なし。トレードオフ：デプロイメントモデルとNext.js統合はVercelより洗練さに欠ける。コスト重視でエンジニアリング能力があるプロジェクトに対しては、粗い部分をナビゲートする価値がある。

それを保守するチームに合致するフレームワークを選ぶ。当たり前に聞こえるが、Seahawk で見かけるフレームワーク選定の違反ルールの中で最も多いのはこれだ。

React エンジニア 3 人のチームが WordPress で構築すべきではない。PHP エンジニア 1 人と執筆者 3 人のチームが Next.js で構築すべきではない。エンジニアがゼロで フリーランスデザイナー1 人のチームは、Webflow、Framer、ホステッド WordPress のどれでも構築すべきではない。正解は Webflow、Framer、またはホステッド WordPress だ。

フレームワークとチームのミスマッチのコストは初日に支払われない。その後何年にもわたって、チームがフレームワークに対抗して働く状況として支払われる。テクノロジーを運用の現実に合わせるのだ。

2026 年に私が納品または監査したサイトからの実数値。すべて 75 パーセンタイルのフィールドデータで測定：

Static-rendered Astro

LCP は一貫して 1.0 秒以下。ほとんどのページで初期 JavaScript は 30KB 未満。Lighthouse 100 はデフォルト成果であり、最適化目標ではない。コンテンツサイトにおいて最も難易度の高い層。

Static-rendered Next.js（App Router、RSC）

最適化されたサイトで LCP 1.0 ～ 1.5 秒。初期 JavaScript 80 ～ 150KB。どれだけのクライアントコンポーネントを配信するかによって異なる。Lighthouse 90+ は達成可能だが、意図的な最適化作業が必要。

ISR または SSR Next.js

LCP は 1.5 〜 2.5 秒、キャッシュヒット率とオリジンレスポンスタイムに左右される。コールドキャッシュミスで劇的にパフォーマンスが低下する。適切なユースケースであれば優れたテクノロジーだが、アクティブな監視が必須となる。

マネージドホスティング（Kinsta、WP Engine）上の WordPress に加えて Cloudflare

LCP は通常 1.8 〜 3.0 秒。努力次第で Lighthouse 70 〜 85。ほとんどのコンテンツサイトで許容できるが、静的オプションと比べると実質的に劣る。パフォーマンスの天井は現実的な制約として存在する。

共有ホスティング上の WordPress

LCP は 3.5 秒以上。パフォーマンスがブリーフの一部を占めるサイトでは避けるべき。

3 つすべてが最高レベルでランク付けできる。2026 年の SEO 議論は、どのフレームワークが「より SEO フレンドリー」かという話ではない。実装品質の問題だ。

Astro または Next.js での静的レンダリングは、最もクリーンなインデックス可能 HTML と最速の Core Web Vitals をもたらす。いずれもランキング要因である。WordPress に Yoast または Rank Math を組み合わせると、最も包括的なエディタ内 SEO ツール機能が得られ、非技術的なエディタがクリーンなメタデータをデプロイするのに実質的に役立つ。ヘッドレス WordPress であれば両者の利点が得られるが、ダブルスタックのメンテナンス負担が代償となる。

SEO の失敗を見かけるのは、ブラウザで主要コンテンツをレンダリングする JavaScript 多用型の Next.js サイトの場合だ。Google は技術的には JavaScript でレンダリングされたコンテンツをインデックスできるが、遅延、完全性、一貫性のすべてが HTML でレンダリングされたコンテンツより劣る。SEO が重要であれば、サーバーサイドまたは静的にレンダリングする。常に、だ。

ほとんどのクライアントは間違ったマイグレーションの質問をします。正しい質問は「WordPressからNext.jsへマイグレーションできるか」ではなく、「各オプションの3年間の総コスト（それを保守するのに必要なチームを含む）はいくらか、そして実際に気になるメトリクスをどちらがもたらすか」です。

Seahawk Mediaで実施する典型的なWordPressからheadless Next.jsへのマイグレーションは、スコープに応じて25,000〜90,000USDです。そのマイグレーションは通常、Lighthouseスコアが広告費用またはコンバージョン率に影響を与えるトラフィックの場合、12か月以内に元が取れます。月間2,000アクセスのブロシュアサイトには元が取れません。

より頻繁に意味があるマイグレーションは、共有ホスティング上のWordPressからKinsta上のWordPress、プラスCloudflareレイヤー、プラスより厳選されたプラグンダイエットです。同じプラットフォーム、異なる運用の現実、再プラットフォーム化のコストの10分の1で、素材的により良いパフォーマンスとセキュリティ。ほとんどのクライアントにとって正しい答えは「Next.jsで再構築する」ではなく、「既存のWordPressのインストールを修正する」です。

これは2026年のすべての新規クライアント会話で実行する実際の意思決定ツリーです。

チームがエンジニアリング能力をゼロに持っており、編集がこれまたは唯一の機能である場合：WebflowまたはホストされたWordPress。

チームが編集主導で軽い技術サポートがあり、コンテンツが豊富でプラグインエコシステムのニーズがある場合：マネージドホスティング上のクラシックWordPress。デフォルトの答え。

チームが編集主導だが、パフォーマンスとデザインが要件の一部である場合：headless WordPressにAstroまたはNext.jsフロントエンド。

チームがエンジニアリング主導で、プロダクトがコンテンツ豊富で、デザイン言語が珍しく、ユーザー状態がほぼない場合：SanityまたはSupabaseを持つAstro。

チームがエンジニア主導であれば、プロダクトは認証済みユーザー状態とステートフルなインタラクティビティを備えている。Next.js with Sanity または Supabase を使い、Vercel または Cloudflare Pages にデプロイする。コスト感度によって選択する。

データモデルが本当にテーブル型でスケールする場合（ディレクトリ、リスティング、プログラマティック SEO）：Next.js または Astro with Supabase を使う。HostList.io がこのケーススタディだ。

2026年に「最高」のフレームワークは存在しない。チーム、コンテンツの形状、運用の実態の組み合わせごとに最適なフレームワークが存在するのだ。うまく納品するチームは、この三つを正直に一致させたチームだ。苦労するチームは、フレームワークを先に選んで、自分たちの現実をそれに合わせようとしたチームだ。

間違ったフレームワークを選ぼうとしている三つの正直なサイン。友人が使っているから選んでいる、今四半期のトレンドリストに載っているから選んでいる、マーケティングページのデモが何か感じさせてくれたから選んでいる。これらはどれも良い理由ではない。正しい理由はこうだ。これは自分のチームに合っている、これは自分のコンテンツに合っている、これは三年間の自分の予算に合っている。

自分たちが構築しているものにどれが適切かについて、第二の意見が欲しいなら、Seahawk Media で相談を受け付けている。会話は無料、推奨は正直で、時には現在の WordPress サイトを保ち、ホスティング層を修正することが正しい答えだと言うこともあるだろう。なぜなら、実際の数字がそれを示しているからだ。