AstroとWordPressを比べて、自分はAstroを選んだ。決め手は作り方とCloudflareとの相性

AstroとWordPressを、構成・更新方法・表示速度・運用・拡張性・Cloudflareとの相性まで比較。ゆまラボで最終的にAstroを選んだ理由を実際のサイト運用目線で整理します。

執筆：ゆまラボ運営者

公開：更新：
AstroとWordPressを比べて、自分はAstroを選んだ。決め手は作り方とCloudflareとの相性

ゆまラボを作り始めるとき、最初からAstroに決めていたわけではありません。

ブログを作るならWordPress。これは今でもかなり自然な選択です。管理画面があって、記事を書けて、画像を入れて、テーマやプラグインも山ほどある。実際、サイトを「運営する」ことだけ考えれば、WordPressの完成度はかなり高いです。

それでも最終的に選んだのはAstroでした。

理由を一言で「Astroの方が速いから」とすると、かなり話を省きすぎています。比べていくと、そもそもAstroとWordPressは同じ土俵の製品ではありません。片方はWebフレームワーク、もう片方はCMSです。

2026年9月時点ではAstroは7.3、WordPressは7.1まで進んでいます。どちらも昔のイメージだけで語るとズレます。WordPressはブロックエディターやサイト編集がかなり進化していますし、Astroも「静的HTMLを書き出すだけのSSG」ではなく、必要なページだけオンデマンドで描画する構成まで普通に取れるようになっています。

自分には、性能差よりもサイトをどう作って、どう更新して、どう置いておくかの違いの方が大きく感じました。

AstroとWordPressでサイト公開までの構成が異なることを示した概念図

※ 記事内の図は比較内容を整理するために作成した概念図です。各社の公式資料や実際の製品画面ではありません。

AstroとWordPressは作り方から違う#

WordPressは、PHPとMySQLまたはMariaDBを使って動くCMSです。記事本文や設定はデータベースに入り、テーマやプラグインを組み合わせてページを返します。現在の推奨環境もPHP 8.3以上、MariaDB 10.11以上またはMySQL 8.0以上となっています。

Astroは考え方がかなり違います。

ブログのようなページなら、MarkdownやMDX、コンポーネントなどを元にビルドし、HTMLを事前生成して配信できます。Astro自身も「content-driven websites」を主な用途としていて、デフォルトではクライアント側JavaScriptを極力送らない設計です。

ここを理解すると、比較がかなり分かりやすくなります。

横にスクロールできます
見るところAstroWordPress
立ち位置WebフレームワークCMS
記事管理Markdown / MDX / Content Collectionsなど管理画面・DB
基本の配信静的生成が得意。必要ならSSRも可能PHPで動的生成。キャッシュ利用も可能
カスタマイズコードでかなり自由テーマ・プラグインが非常に豊富
非エンジニアの更新工夫が必要かなりやりやすい
Gitとの相性とても良い標準運用では記事DBと分離しやすい
サーバー管理静的構成ならかなり小さくできるPHP・DBを動かす環境が必要
CloudflarePages / Workersへ直接載せやすいCDNやプロキシとして使えるがOriginは残る

WordPressの方が機能が多い、Astroの方が軽い、という比較だけでは少し足りません。

WordPressは最初から「記事を書く人がサイトを管理するための仕組み」が入っています。Astroは「Webサイトを作るための土台」で、何を載せるか、どう管理するかはかなり自分で決められます。

この違いが後から効いてきました。

WordPressの管理画面は今でも便利#

ここはAstroを選んだからといって無理に逆張りするところではありません。

WordPressの管理画面は便利です。

ブラウザを開いてログインし、記事を書き、画像をアップロードして公開する。予約投稿もできるし、複数人で運用するなら権限管理もある。ブロックテーマならヘッダーやフッターを含めて管理画面側から触れる範囲も広くなっています。

プラグインの存在も大きいです。

問い合わせフォームが欲しい、SEO設定を細かく触りたい、関連記事を出したい、キャッシュを入れたい。こういう要求に対して、まず既存プラグインを探せるのは強い。トラブルが起きても検索すれば事例が出てくる可能性が高いです。

会社のWebサイトや、技術者ではない人が頻繁に更新するメディアを作るなら、自分でもWordPressを候補から外しません。

Astroで同じことをやろうとすると、CMSを別途組み合わせるか、Gitベースの編集フローを用意するか、自前で管理画面を作ることになります。

ただ、ゆまラボはそこが違いました。

記事そのものをMarkdownで持っていても困らない。むしろ、コードと一緒にGitで管理できる方が都合がいい。AIに記事やサイト構造の修正を頼むときも、ファイルとして全部見える方が扱いやすいです。

Astro系のコード・Markdown運用とCMS管理画面中心の運用フローを比べた概念図

自分の場合、WordPressの「管理画面がある」という強みが、必ずしも最優先ではありませんでした。

Astroは必要なものを自分で組み立てる#

Astroを最初に触ると、WordPressと比べて少し素っ気なく感じます。

管理画面はありません。プラグインを検索して有効化すれば何でも増える、という世界でもない。記事一覧、カテゴリ、タグ、前後の記事リンク、目次なども、必要ならサイト側で作ります。

でも実際にゆまラボを作っていて、この部分の印象が変わりました。

「足りない」より、「勝手に決められていない」に近いです。

記事のFrontmatterをどうするか。カテゴリを何階層にするか。画像をどこに置くか。記事ページをどう組むか。全部リポジトリの中にあります。

変更した内容はGitに残るので、どこで何を変えたかも追いやすい。デザインを大きく変える場合も、テーマの設定画面とPHPテンプレートとプラグイン設定を行き来するより、コード側で把握できる方が自分には分かりやすかったです。

AstroにはContent Collectionsもあり、Markdownを単なるバラバラのファイルとして扱うのではなく、スキーマを持たせて整理できます。Astro 7ではMarkdown処理やビルド周りもかなり手が入り、7.2では大規模な静的サイト向けにincremental static buildsの実験機能まで入っています。

少なくとも「記事が増えたらAstroはすぐ限界」という感じではありません。

それに、Astro 7ではAIコーディングエージェントを意識したdev serverや構造化ログも入っています。AIを使いながらサイトを修正していく今の作り方とは妙に相性がいいです。

これはWordPressにできないという意味ではありません。WordPressもREST APIを持っているので、CMSとしてWordPressを使い、フロントだけAstroにするヘッドレス構成も作れます。

ただ、それを始めると今度はWordPressとAstroの両方を運用することになります。

ゆまラボ規模なら、そこまでしなくていいという判断でした。

WordPressも構成次第で十分速くできる#

Astroを勧める記事では、かなり高い確率で表示速度の話が出てきます。

実際、Astroは速いサイトを作りやすいです。静的生成したHTMLをそのまま配れて、必要のないJavaScriptをブラウザへ送らない設計なので、コンテンツ中心のサイトとは素直に噛み合います。

ただし、WordPressだから必ず遅いわけではありません。

キャッシュ、CDN、画像最適化、軽いテーマ、適切なプラグイン構成、十分なサーバー性能。この辺をきちんとやればWordPressでも高速なサイトは作れます。

逆も同じです。

Astroを使っていても巨大なJavaScriptを載せたり、重い外部スクリプトを大量に呼んだり、画像を雑に扱えば普通に遅くなります。

SEOも同様です。

Astroなら自動的に検索順位が上がるわけではないし、WordPressならSEOに不利ということもありません。WordPressにはSEO関連の選択肢が豊富ですし、AstroならHTML構造やメタ情報を自分でかなり直接管理できます。

ここはフレームワーク名で勝敗を付ける場所ではないと思っています。

それより、自分が気にしたのは速い状態をどれだけ単純な構成で維持できるかでした。

WordPressは高速化できる。ただ、そのためにキャッシュやサーバー設定、プラグイン構成を管理する場面が出てくる。

Astroで静的に寄せられるサイトなら、そもそも実行するものを減らせます。

この差は長く運用すると結構大きいです。

Cloudflareに載せるならAstroの構成がシンプル#

自分がAstroを選んだ理由の中で、かなり大きかったのがCloudflareです。

AstroはCloudflare PagesにもWorkersにも公式のデプロイ手順があります。静的ブログならビルド成果物をそのまま配信できるし、SSRが必要になればCloudflareアダプターを使ってWorkers側で動かす構成も取れます。

ここまでは単なる「対応ホスティングの一つ」という話でした。

2026年1月に状況がさらに変わっています。Astroを開発するThe Astro Technology CompanyがCloudflareに加わりました。Astroは引き続きMITライセンスのオープンソースで、Cloudflare専用になるわけではないと明言されていますが、両者の開発上の距離はかなり近くなっています。

実際、Astro 7.3でも@astrojs/cloudflareにカスタムWorkerエントリーポイント向けのfinalize()ヘルパーが追加されています。

AstroとWordPressをCloudflareまで含めて配置した場合の構成差を示す概念図

WordPressでもCloudflareは使えます。

WordPressの前段にCloudflareを置いて、CDN、キャッシュ、DNS、WAFなどを利用する構成は普通にできます。Cloudflareを使うからWordPressが不利という話ではありません。

違うのは、その奥です。

WordPressはCloudflareの後ろにPHPを動かすOriginとデータベースが必要です。キャッシュが効いている間は速くても、CMS本体を動かす環境自体は残ります。

Astroでほぼ静的に作るなら、Gitへpushしてビルドし、その成果物をEdgeから配るところまで構成をかなり単純にできます。

ゆまラボでやりたいことを考えると、こちらの方が自然でした。

ブログを書くためにサーバーを管理したいわけではありません。WordPress本体、テーマ、プラグイン、PHP、DBの組み合わせを定期的に気にしたいわけでもない。

コードを書いて、記事を書いて、pushしたら公開される。

その形に寄せたかったです。

ゆまラボではAstroを選んだ#

もし「今日からブログを書きたい。コードはなるべく触りたくない」と言われたら、WordPressを勧める場面は普通にあります。

WordPressはCMSとして完成されています。歴史も長く、テーマもプラグインも多い。管理画面だけでかなりのことができます。複数人で記事を書くなら、Astroより圧倒的に説明しやすいはずです。

でも自分がゆまラボでやりたかったのは、完成したブログシステムを借りて記事を追加することだけではありませんでした。

サイトそのものを触りたい。

記事が増えたらカテゴリの見せ方を変えたいし、AIを使って機能も足したい。CSSも変えたい。ビルドで失敗したら、その修正過程も記事にしたい。サイトを作る行為自体が、ゆまラボの内容の一部になっています。

そう考えると、管理画面の便利さよりも、全部がコードとして手元にある方が面白い。

AstroはWordPressの代用品ではありません。

逆にWordPressも、Astroより古いから置き換えられるようなものではありません。

「誰が更新するのか」「どこまでコードを触りたいのか」「サーバーをどこまで持ちたいのか」で選択は変わります。

自分の場合は、Markdownで記事を書ける。Gitで全部管理できる。必要なものだけ実装できる。そしてCloudflareへ素直に載せられる。

この組み合わせが一番しっくりきました。

特に2026年に入ってAstroとCloudflareの距離がかなり近くなったことで、今から同じ条件でもう一度選び直しても、おそらくAstroを選びます。

WordPressをやめたかったからではなく、ゆまラボを自分で作り続けるにはAstroの方が面白かった。

最終的にはそこでした。

参考#