なぜすべてのサイトに同じ技術が使えないのか
WordPressは、ブログから会員サイト、EC（電子商取引）サイトまで同じ仕組みで作れます。柔軟な代わりに、どの用途でも、閲覧のたびにデータベースへ問い合わせる作りと、本体とプラグインの更新を追い続ける必要が付いてきます。用途によっては、そのどちらも要らないことがあります。
リプレースで基盤を選ぶときは、サイトが扱うデータの性質を先に見ます。閲覧者ごとに表示が切り替わるか、更新の頻度はどれくらいか。ここを決めないまま構成を選ぶと、公開したあとで作り直すことになります。
用途に合わせた2つの移行先
当方が案内する移行先は2つです。ただし「Astroは静的だけ、Laravelは動的だけ」という分け方ではありません。AstroはCloudflare上でサーバー側の処理も動かせます。Cloudflareは公式資料で、専用のサーバーを立てずにサーバー側のコードを動かせること、その用途として認証やフォーム送信の処理を挙げています。
分かれ目は、動的処理があるかどうかではありません。閲覧者ごとに内容が変わる仕組みが、事業の中心にあるかどうかです。フォームや小規模なAPIで足りる範囲なら、作り置きの構成に外部サービスを足して収まります。会員機能・EC・予約のように、データと画面が結びついて事業の中心にある場合は、作り替えの範囲が変わります。
- 閲覧が中心のサイト: Astro + Cloudflare：コーポレートサイト、オウンドメディア、採用サイトなど、閲覧者ごとに表示内容が変わらないサイトに向きます。静的サイトジェネレーター『Astro』でビルド時に全ページをHTMLファイルへ書き出し、Cloudflare Pagesなどのエッジネットワーク（CDN）から配信します。閲覧のたびにサーバーでプログラムを動かさないため、公開側で更新を追う対象が減ります。表示にかかる時間は、画像や外部から読み込むスクリプトの量でも変わるため、構成しだいです。
- 閲覧者ごとに内容が変わる仕組みが中心のサイト: Laravel：会員マイページ、閲覧者どうしのマッチング、予約管理、データベースと頻繁にやり取りする条件検索などがあるサイトに向きます。PHPの開発フレームワーク『Laravel』で、必要な機能だけを作ります。プラグインを組み合わせて作らないため、プラグインどうしの相性で起きる不具合はなくなります。代わりに、作った分のコードを自社で保守する対象として抱えます。
技術選定マトリクス
当方が想定する標準の構成で比べた場合の違いです。Astro側をSSRで動かす、Pages Functionsを足す、といった選択でこの表は変わります。
| 比較項目 | Astro + Cloudflare (SSG) | Laravel (Webアプリ) |
|---|---|---|
| 向くサイトの性質 | コーポレート、メディア、採用、LP（閲覧が中心） | 会員サイト、予約システム、マイページ（閲覧者ごとに内容が変わる） |
| 標準構成の配信方式 | 作り置きしたページを配信（SSG）。動的な部分はPages Functionsや外部サービスで補う | アクセスのたびにサーバー側で処理して組み立てる |
| 公開側の保守 | 公開側にWordPress本体もDBも置かないため、そちらの更新追従は無くなる | フレームワークとライブラリの更新追従が続く |
| 設計の自由度 | 画面の作りは自由に組める。閲覧者ごとに出し分ける処理は、そのつど外部サービスやサーバー側の処理を足すことになる | 業務ロジックとデータ構造を要件どおりに組める |
この記事の説明が当てはまらない場合
閲覧が中心のサイトでも、更新した内容をその場で反映する必要がある場合は、事前に作り置きする構成が合いません。在庫や空き枠のように秒単位で変わる情報を出しているサイトが該当します。
反対に、会員機能やECがあっても、ログインが必要な範囲が小さく、閲覧側と分けられる場合は、閲覧側だけを作り置きの構成へ移せることがあります。会員機能の有無だけでは決まりません。
AstroをSSR（アクセスのたびにサーバー側で組み立てる方式）で動かす構成や、Pages Functionsで認証やフォーム処理を持たせる構成を選ぶ場合、この記事の比較表は当てはまりません。作り置きを前提にした保守の軽さも、その分だけ変わります。
ページ数が多く、全件の作り置きに時間がかかるサイトも、この記事の前提から外れます。更新のたびに全件を作り直す構成では、公開までの待ち時間が運用の制約になります。
権限の細かい制御、監査記録、外部システムとの連携が要件にある場合も、比較表の4項目だけでは決まりません。Laravel以外のフレームワークや、既存のSaaSで足りることもあります。
移行先の判断は、記事の分類ではなく、実際のデータの持ち方と更新の頻度で決まります。当方の分類は候補を絞るための出発点であり、確定ではありません。
相談相手に確認すること
見積や方針を受け取ったら、次の4点を確認してください。どれも、その場で答えられる範囲です。
1つめは、更新した内容が公開ページに反映されるまでの時間です。事前に作り置きする構成では、更新から反映までに時間差が生じます。何分・何秒まで許容できるかを先に決めます。
2つめは、いま動いている機能のうち、移行先で作り直しが要るものと、外部サービスへ預けられるものの区別です。フォーム、サイト内検索、会員機能は分かれやすい箇所です。
3つめは、公開先を切り替える当日の手順と、切り戻しの条件です。検証をどこまで終えてから切り替えるかを、工程として決めておきます。
4つめは、移行後に自社で更新できる範囲です。更新のたびに依頼が必要になる構成では、保守の負担が形を変えて残ります。
参考情報（外部サイト）
本文で参照した外部の公開情報です。
- Pages Functions（サーバー側の処理・認証・フォーム送信の扱い）（外部サイト）（Cloudflare）
- Deploy an Astro site（AstroのSSGとSSRの扱い）（外部サイト）（Cloudflare）