WordPressとAstroの使い分けで迷ったら確認する3つの条件
「とりあえず WordPress」で進めた結果、更新機能を使わないままの重いサイトが出来上がる — 制作の現場でよく起きる判断ミスのパターンです。 技術選定を慣れで決めると、クライアントの保守費用が不必要に膨らみ、後で説明に困る場面が出てき…
「とりあえず WordPress」で進めた結果、更新機能を使わないままの重いサイトが出来上がる — 制作の現場でよく起きる判断ミスのパターンです。
技術選定を慣れで決めると、クライアントの保守費用が不必要に膨らみ、後で説明に困る場面が出てきます。
この記事では、自分が実案件で WordPress と Astro を使い分ける際の判断軸を、具体的な基準と体験談を交えて整理します。
「クライアントが自分で更新するか」が最初の分岐点
技術選定で最初に確認するのは、「クライアント自身がコンテンツを更新する必要があるか」という1点です。
これが Yes なら WordPress が現実的な選択肢に入ります。
No なら、WordPress を選ぶ理由はほぼなくなります。
WordPress は CMS としての機能が充実している分、保守の手間とコストが必ず発生します。
サーバーサイドの処理・プラグイン管理・セキュリティアップデート、それが全部乗ってきます。
クライアントが更新しない案件にこれを乗せるのは、必要以上のコストを押し付けることになります。
実際、自分が担当した地域イベントの告知 LP は、公開後にコンテンツを更新する予定がゼロでした。
この案件に WordPress を使う選択肢は、最初から検討に入りませんでした。
Astro で静的実装したことで、サーバー負荷は最小限、保守コストはほぼゼロという結果になっています。
「CMS が必要」= WordPress という条件反射を一度外して考えると、選択肢が広がります。
Astro を初めてクライアント案件で使った話
自分にとって初めての Astro クライアント案件は、地方の 1Day イベント告知 LP でした。
期間は約2週間、スピード勝負、公開日は動かせないという条件です。
事前に Astro でテストサイトを作って学習してから臨みましたが、本番案件では想定外のトラブルが起きました。
tsx コンポーネントを使った箇所で、ビルド時に相対パスが出力されるという挙動があったのです。
特殊な階層にデプロイしていた影響で、生成されたパスが壊れてページが表示されない問題が発生しました。
対応は2段階で動きました。
まずスピード優先でビルド成果物を手動修正して公開。
その後、Astro の base path 設定を調べて根本解決しました。
「事前学習をしたから大丈夫」とはならないのが本番案件の現実です。
初めての技術を使う時は、応急処置のルートも事前に想定しておくことが必要だと、この案件で学びました。
結果として納期に間に合い、アニメーション・カウントダウン・Google Analytics 全部入りでクライアント満足度は高かったです。
静的実装なので表示速度も速く、イベント当日のアクセス集中にも問題なく対応できました。
Astro が向かない案件の条件
Astro が合わないケースも明確にあります。
以下の条件に1つでも当てはまる場合、WordPress か別の CMS を選ぶ方が現実的です。
- クライアント自身がブログ・お知らせ・商品情報を定期的に更新する
- 会員機能・カート・動的フォームなど、サーバーサイド処理が必須
- 制作後の運用をクライアントが自走する必要がある
特に3つ目は見落としがちです。
技術者がいない事業者が自走する前提の場合、管理画面の使いやすさで WordPress が圧倒的に有利です。
Astro で作った静的サイトを「自分で更新してください」とクライアントに渡すのは、更新手段がない状態を作ることになります。
Astro でも Headless CMS（microCMS や Contentful など）と組み合わせれば、更新機能は実装できます。
ただし構成が複雑になり、保守コストは上がります。
「シンプルに更新したい」というニーズには WordPress の方が素直に答えられます。
WordPress と Astro の使い分けフロー
自分が案件で使っている判断フローはこうです。
- クライアント自身が更新するか？ → Yes なら WordPress を検討 / No なら次へ
- 会員・カートなどサーバーサイド処理が必要か？ → Yes なら WordPress or 専用システム / No なら次へ
- 公開後にコンテンツの追加・変更が発生するか？ → Yes なら Headless CMS 連携を検討 / No なら Astro 静的実装
このフローで考えると、LP・告知サイト・ポートフォリオ・コーポレートサイト（更新なし）は Astro が全然いいという判断になります。
WordPress は「クライアントが更新する」「動的処理が必要」の条件が揃って初めてその強みが活きます。
「とりあえず WordPress」をやめてから、自分は保守費用の説明が楽になりました。
「なぜこの技術を選んだか」を言語化できると、クライアントへの説明コストが下がり、後から不満が出にくくなります。
次の案件で技術選定に迷ったときは、まずこのフローの1番目から確認してみてください。
まとめ
- 技術選定の最初の分岐は「クライアントが自分で更新するか」
- 更新不要な案件に WordPress を選ぶと、不要な保守コストが発生する
- Astro は静的実装に強く、表示速度・セキュリティ・保守コストで優位
- 初めての技術で本番案件を受ける時は、応急処置のルートを事前に想定する
- 「CMS が必要」= WordPress という条件反射を外すと選択肢が広がる