LP案件でWordPressをやめてAstroを選んだ判断と落とし穴
LP案件の見積もり、毎回WordPressで出していませんか？
「更新もほぼないのに保守費用だけかかる」「プラグイン更新のたびにエラーが出ないか怖い」という状況は、制作会社から受託するコーディング案件でも自社でLPを運営するケースでも、実はよく起きています。
WordPressが過剰になる案件の判断軸と、自分がAstro初クライアント案件で踏んだtsx相対パスの落とし穴を、実際の対処コードとあわせて書きます。
その保守費用、LPに本当に必要ですか
WordPressは「更新する」ことを前提に設計されたCMSです。
PHP・MySQL・プラグイン・テーマ、これらは常に最新を保たないとセキュリティリスクが上がります。
そのための保守費用なので、コンテンツを更新し続けるサイトなら理にかなっています。
問題は、「クライアント自身がコンテンツを更新しない」LPや告知ページに対してもWordPressを選んでしまうケースです。
以下に当てはまる案件は、WordPressが過剰になっている可能性があります。
- クライアントが管理画面を自分で操作しない
- コンテンツの更新が月0〜1回以下
- フォームはGoogleフォームや外部サービスで代替できる
- 公開後にページ構成や文章が大きく変わる予定がない
これらが当てはまる案件でWordPressを選ぶと、「サーバーとWordPressの管理コストだけが残る」状態になりやすいです。
判断軸は「クライアントが自分でコンテンツを更新するか」の1点
技術選定に迷ったとき、自分が使っている判断軸はシンプルに1つです。
「クライアントが自分でコンテンツを更新するか」—この1点だけで8割の選定が決まります。
- 更新する → WordPressのCMS機能が必要なのでCMSを選びます
- 更新しない → 静的サイトジェネレーターで十分です。Astroなどを検討してみてください
Astroを選んだときのメリットを具体的に挙げると、次のとおりです。
- PHPもMySQLも不要で、サーバー要件がシンプルになります
- ビルド後はHTML・CSS・JSだけになるので、ページ読み込みが速くなります
- プラグイン更新によるエラーリスクがゼロです
- 保守費用をサーバー代だけに抑えやすくなります
実際に、地域イベントの告知LPを受けたとき、クライアントから「動きを多く取り入れたい」「アナリティクスも入れてほしい」という要望がありました。
管理画面でコンテンツを更新する必要は一切なかったので、Astro + TypeScript（tsx）で実装しました。
WordPress製の類似LPと比較すると、ビルド成果物はHTMLとCSSとJSだけで、サーバー要件も最小限で済みました。
「CMS = WordPress」の条件反射から一度離れると、保守コストが大きく変わります。
Astro初案件で踏んだtsx相対パスの落とし穴
AstroでReact（tsx）コンポーネントを使う場合、注意が必要な挙動があります。
自分が初めてのAstroクライアント案件で踏んだのが、tsxコンポーネント使用時のビルド後パス問題でした。
状況を整理すると、次のような流れです。
- Astroプロジェクト内でReact（tsx）コンポーネントを使用しました
- ビルドを実行すると、CSSやJSのパスが相対パス形式で出力されました
- デプロイ先がドメイン直下ではなく、サブディレクトリ（例:
/event/2026/）でした - CSS・JSのパスが合わなくなり、スタイルと動作がすべて消えました
公開日が動かせない案件だったので、まず応急処置としてビルド成果物（distディレクトリ）内のHTMLを手動で修正し、パスを絶対パスに書き換えて公開しました。
当日の公開には間に合いましたが、修正のたびに手動対応が必要になる状態です。
根本解決としては、astro.config.mjsにbaseオプションを追加します。
// astro.config.mjs
import { defineConfig } from 'astro/config';
import react from '@astrojs/react';
export default defineConfig({
base: '/event/2026/', // デプロイ先のサブディレクトリパスを指定
integrations: [react()],
});この設定を入れると、ビルド時にすべてのアセットがbaseを考慮した絶対パスで出力されます。
事前にテストサイトで学習済みでも、本番でサブディレクトリデプロイのケースを試していなければ同じトラブルを踏みます。
初めての技術でクライアント案件を受けるときは、応急処置のルートをあらかじめ考えておくことをおすすめします。
自力でできる判断 / プロに任せた方がいい作業
技術選定と基本実装は、判断軸さえ持っていれば自力で進められます。
一方、デプロイ設定が複雑になると、判断ミスがそのまま公開事故につながります。
自力でできること
- 「クライアントが自分で更新するかどうか」の確認と判断
- Astroの基本セットアップとビルド
astro.config.mjsへのbase設定追加- tsxコンポーネントの動作確認（ローカルでデプロイ先の階層を再現してテスト）
プロ領域 / 経験が必要な判断
- 特殊なサーバー環境へのデプロイ最適化
- CI/CDを使ったビルドパイプラインのカスタマイズ
- tsxコンポーネントが増えた時の設計判断（どこまでAstroコンポーネントで書くか）
- WordPressとAstroのハイブリッド構成（一部コンテンツだけCMS管理したい場合）
「静的サイトで十分かCMSが必要か」の判断さえ正確にできれば、基本実装はドキュメントで追えます。
ハイブリッド構成や複雑なデプロイ設定が絡んできたら、そこからはパートナーに相談してみてください。
まとめ
- 更新不要なLP案件にWordPressを使うと、保守コストだけが残りやすくなります
- 判断軸は「クライアントが自分でコンテンツを更新するか」の1点です
- Astroはサブディレクトリデプロイ時に
base設定が必要です。忘れるとCSSやJSのパスが崩れます - tsxコンポーネントを使う場合は、デプロイ先の階層をローカルで再現してビルドテストしてから本番に臨んでください
- 初めての技術で案件を受けるときは、公開日に間に合う応急処置ルートを事前に用意しておくと安心です
コーディング代行や実装判断で詰まったら、Buildへ気軽に相談してください。
「これWordPressじゃないとダメ？」という技術選定の確認だけでも受け付けています。