本文へスキップ
Build

Column

コラム

ツール・環境

AstroとWordPressの使い分け — 更新しないサイトにWordPressは重すぎる

AstroとWordPressの使い分け — 更新しないサイトにWordPressは重すぎる のアイキャッチ

制作したHPを納品してから、クライアントが一度も管理画面を開いていない—そんな経験はないでしょうか。
更新予定のないサイトにWordPressを選ぶケースは思いのほか多く、メンテナンスの手間だけが残る状況が生まれます。
この記事では、地域イベントの告知LPにAstroを初めて使った実案件を通じて、AstroとWordPressの使い分けをどう判断しているかをお伝えします。

更新しないHPにWordPressを使い続けると発生するコスト

「なんとなくWordPressで」という判断が、保守コストを積み上げているケースがあります。
WordPressはCMSとして優秀ですが、その価値はクライアントがコンテンツを自分で更新することにあります。
誰も更新しないサイトでは、CMS機能はただの重荷になります。

更新しないHPにWordPressを使い続けると、以下のコストが発生します。

  • WordPressコア・プラグインの定期アップデート対応
  • PHPバージョン依存のトラブル対応
  • セキュリティ脆弱性の監視と対応
  • 不要なプラグインによるパフォーマンス低下

実際、保守案件でクライアントに「管理画面を最後に開いたのはいつですか?」と聞くと、「覚えていない」と答えるケースは珍しくありません。
そういったHPは、AstroとWordPressの使い分けを検討する価値が十分あります。
技術を変えるだけで、保守の手間を大幅に減らせる場合があります。

AstroとWordPressを使い分ける3つの判断軸

自分が技術を選定するとき、まず以下の3つを確認します。
この問いを外すと、「やっぱり静的サイトにすれば良かった」という後悔につながります。

クライアントが自分でコンテンツを更新するか

これが一番の判断軸です。
「ブログを自分で書きたい」「お知らせを随時追加したい」という要望があれば、WordPressを選びます。
一方、「制作したら基本的に変更しない」「更新があれば制作側に依頼する」という場合は、静的サイトで十分です。
CMS機能を使わないのに、CMSの維持コストを払い続ける理由はありません。

公開後に動的な機能が必要か

フォーム送信・会員機能・EC機能などが必要なら、WordPressのプラグインエコシステムが強みを発揮します。
ただし、問い合わせフォームだけならAstroにFormspreeやNetlify Formsを組み合わせれば対応できます。
「動的機能が必要=WordPress」という条件反射は、少し立ち止まって確認する価値があります。

保守・運用コストをどこまで下げたいか

Astroは静的サイトを出力するため、PHPやWordPressコアのアップデートが不要になります。
セキュリティリスクも大幅に下がります。
保守費用を抑えたい案件、特に一度作ったら長期間変更しないサイトには、Astroを選ぶ根拠になります。

地域イベントLPでAstro初案件、本番で起きたトラブルと解決

自分のAstro初クライアント案件は、地方の1Dayイベントの告知サイトでした。
公開日は動かせない、スピード勝負の条件です。
事前にテストサイトで学習はしていましたが、本番特有のトラブルが出ました。

tsxコンポーネントの相対パス問題

カウントダウン表示やアニメーションをReact/TypeScript(tsx)で実装したところ、ビルド時に相対パスで出力される挙動がありました。
そのサイトはルート直下ではなく、特殊なディレクトリ階層にデプロイする必要があり、出力されたパスがすべて壊れた状態になりました。
ブラウザで開いたら画像もCSSも読み込まれない、という状況です。

スピード優先だったため、まずビルド後の成果物を手動で修正して公開する応急処置を取りました。
その後、astro.config.mjsbase オプションを設定することで根本解決しました。
事前のテストでは再現しなかった問題で、本番の特殊なデプロイ環境で初めて発覚したトラブルです。

この経験から学んだのは、初めての技術で本番案件を受ける時は「応急処置のルート」を事前に決めておくことです。
「調べながら進む時間」を最初からスケジュールに組み込んでおくと、納期直前のパニックを減らせます。
2週間という期間でのAstro初案件は難航した部類でしたが、それでも静的サイトを選んだことは正解でした。

Astroを選んで良かった点

トラブルはありましたが、Astroを選んだ判断は正解でした。
イベントが終わったあとも、WordPressコアのアップデートもプラグインの管理も一切不要です。
クライアントへの保守費用の説明がシンプルになり、「公開後はほぼメンテなしで大丈夫です」と伝えられるのは、提案としての強みになります。

WordPressを選ぶべきケース

Astroを推してきましたが、WordPressが明らかに向いているケースも当然あります。
使い分けの軸を持っていれば、WordPressを選ぶ判断もブレません。

  • クライアントが自分でブログや新着情報を更新する(管理画面を使いこなす前提がある)
  • ECサイトやカート機能が必要(WooCommerceなどのプラグインエコシステムを活用する)
  • カスタム投稿タイプで大量のコンテンツを管理する
  • 既存のWordPressサイトの改修・保守案件(乗り換えコストが高すぎる)

「クライアントが更新するかどうか」を最初に確認するだけで、大半の技術選定は迷わなくなります。
「とりあえずWordPress」ではなく、この1問を最初に置くだけで、AstroとWordPressの使い分けが自然とできるようになります。

WordPressを使った保守・改修の事例については、WordPressカテゴリの記事でも紹介しています。

まとめ

  • 更新しないHPにWordPressを使い続けると、不要な保守コストが積み上がります
  • 技術選定の最初の問いは「クライアントが自分でコンテンツを更新するか」です
  • 更新不要な案件(LP・イベントサイト・コーポレートサイト)はAstroが向いています
  • Astroの静的出力はセキュリティリスクが低く、公開後の保守コストを下げられます
  • 初めての技術での本番案件は、応急処置のルートを事前に用意しておくと安心です
  • WordPressが向いているのは「クライアント更新あり」「EC機能あり」「既存サイトの改修」のケースです

技術選定に迷ったとき、あるいは現在のHP保守コストが高いと感じたとき、お気軽にご相談ください。
自分の案件でどの技術が向いているか、一緒に考えます。

Buildへの相談はこちら