AstroとWordPressの使い分け：迷わない3つの判断基準

「AstroかWordPressかで迷ったまま提案してしまう」「Astroでビルドしてサーバーに上げたら画像が全部404になった」— どちらかに当てはまるなら、この記事が使える。
選択基準の3条件と、サブディレクトリ配置時のアセット404問題の原因・対処を整理する。

AstroかWordPressか ― 3条件で自己診断する

次の3項目を確認するだけで判断できる。

1. クライアントが自分でコンテンツを更新するか（公開後に触る運用があるか）
2. 管理画面からの操作が必要か（ログイン機能・会員機能）
3. クライアントが意図せずレイアウトや文言を変える可能性があるか

1つでも「はい」があれば、WordPressまたはヘッドレスCMS×静的ジェネレーターを選ぶ。
3つ全部「いいえ」なら、Astroで作れる。
これで8割の判断が済む。
「動きが多いからWordPressが必要」は理由にならない。
カウントダウン、Swiper、フォーム、外部埋め込みは全部Astroで実装できる。

「更新しないサイト」にWordPressを選ぶコスト

WordPressを選ぶと次のコストが自動でついてくる。

• コアとプラグインとテーマの定期アップデート
• 管理画面アカウントへの不正アクセス対応
• クライアントが知らないうちに変更してレイアウトが崩れる事故対応

更新しない静的LPにこれらを背負わせる合理性はない。
Astroの静的ファイルは「触らなければ何も壊れない」状態を長期間維持できる。

Astroをサブディレクトリにデプロイするとアセットが404になる理由

Astroは設定なしでビルドすると、/_astro/... や /images/... のようなドメイン直下起点の絶対パスでHTMLを出力する。
ローカルの preview モードはルートディレクトリから配信するため問題が出ない。
しかし https://example.com/events/summer/ のようなサブディレクトリに置いた瞬間、HTMLが https://example.com/_astro/xxx.js を取りに行き、そこにはファイルがないため404が起きる。
DevToolsのネットワークタブを開いて、リクエスト先がドメイン直下の /_astro/ になっていたらこの問題を踏んでいる。

LP案件での実例 ― 地域イベント告知LPでAstro初案件

実案件として、地域イベントの告知LPをAstroで初めて作ったことがあります。
更新予定のないLPだったため、WordPressの保守費用を残さないことを優先しAstroを選びました。
結果として毎月の保守費用は発生せず、クライアントも管理画面を開かずに済む構成にできましたが、本番デプロイで tsx コンポーネントの相対パスでアセットが 404 になるトラブルに遭遇しました。
LP 単発案件で同じ選択をする方は、下記のサブディレクトリ 404 問題を先に読んでおくことをおすすめします。

tsxコンポーネントを使う場合は特に注意

@astrojs/react を入れてtsx経由でコンポーネントを書くと、この問題が顕在化しやすい。
.astroファイル単体でも同じ問題は起きるが、React/Vueラッパーを使うとアセット参照が増えるため症状が出やすい。
SwiperやカウントダウンをReactコンポーネントに切り出す案件では、デプロイ先のパス構造を確認してからビルド設定を決める順番が重要。

対処 ― 応急処置と根本解決

応急処置：astro-relative-links でまず動かす

astro-relative-links インテグレーションを使うと、ビルド時にすべての絶対パスを相対パスに変換できる。
納期が迫っているときの即効策として使える。

npx astro add astro-relative-links

// astro.config.mjs
import { defineConfig } from 'astro/config';
import react from '@astrojs/react';
import relativeLinks from 'astro-relative-links';

export default defineConfig({
  integrations: [react(), relativeLinks()],
});

再ビルドすると HTML内の /_astro/xxx.css が ./_astro/xxx.css に変わり、サブディレクトリ配置でも全ファイルが読み込まれる。

根本解決：site / base / assetsPrefix を設定する

時間があるときは astro.config.mjs に3つの設定を入れるのが正規解。

// astro.config.mjs
import { defineConfig } from 'astro/config';
import react from '@astrojs/react';

export default defineConfig({
  site: 'https://example.com',
  base: '/events/summer/',
  build: {
    assetsPrefix: '/events/summer/',
  },
  integrations: [react()],
});

site は公開URLのオリジン、base はデプロイ先のサブディレクトリパス。
build.assetsPrefix を同じ値で指定することで、_astro/ 配下のアセット参照もサブディレクトリを含んだ絶対パスで出力される。
この設定を入れてから astro-relative-links を外せば、応急処置なしで動く状態になる。
サブディレクトリに配置する可能性がある案件では、tsxを使う使わないにかかわらず最初の5分で設定しておく。

Astroの設定まわりを体系的に把握したいときは、こちらが参考になる。

ここまで自力 / ここからプロに相談

以下は自力で対応できる範囲。

• ドメイン直下に配置するLPやポートフォリオサイト
• 公開後に更新が発生しない静的サイト
• Astroのビルド設定を自分で触れる開発者向け案件

以下は相談したほうが早い。

• ドメイン直下かサブディレクトリかが固まっていない段階での設計判断
• WordPressからAstroへの移行（既存URLを変えずに動かす要件が絡む場合）
• ヘッドレスCMSとの連携設計

まとめ

• AstroかWordPressかは「誰がどう更新するか」で8割が決まる
• 更新者・管理画面・意図しない変更リスク — この3条件が全部「なし」ならAstroを選ぶ
• Astroをサブディレクトリに置くと、設定なしではアセットが404になる
• 応急処置は astro-relative-links、根本解決は site / base / build.assetsPrefix の3設定
• Astroの静的納品は「触らなければ何も壊れない」保守体制を長期間維持できる

技術選定の壁打ちや実装について相談があれば、お気軽にご連絡ください。
要件に合わせた選択基準の整理から、実装・保守まで対応しています。

無料相談・お問い合わせはこちら