WordPressを使わずにブログを作る方法を探している人の多くは、単に「別のCMSを知りたい」のではなく、いまの運用に疲れているはずです。私もそうでした。記事を増やすほど管理画面が重くなり、プラグイン更新の通知が積み上がり、表示速度や脆弱性の不安が常に頭の片隅に残る。その状態で「もっと記事を書こう」「もっと改善しよう」と言われても、正直かなりしんどいです。
このブログ自体、WordPressを使わずに Astro + MDX + Cloudflare Pages で運営しています。だからこの記事では、理論だけではなく「なぜその構成にしたのか」「どう作るのか」を、実際の運用前提で整理します。
まず結論: WordPressを使わずにブログを作るなら静的サイトが有力
私の結論はかなりシンプルです。更新頻度が高すぎないブログや、記事中心のメディアを個人または小規模で運営するなら、WordPressの代わりに静的サイトを選ぶ価値は大きいです。
静的サイトとは、公開時点で HTML / CSS / 必要最小限の JavaScript を生成しておき、アクセス時に毎回サーバーでページを組み立てない構成です。代表例が Astro のような静的サイトジェネレーターです。
この方式にすると、WordPressでありがちな悩みをかなり減らせます。
- 管理画面やプラグイン起因の重さを避けやすい
- PHP・MySQL・テーマ・プラグインの更新運用が不要になる
- 公開面が静的ファイル中心なので攻撃対象が小さくなる
- Markdownベースで記事を管理できる
- GitHub と相性がよく、変更履歴がきれいに残る
WordPressをやめたくなる典型的な理由
1. 重い、遅い、気持ちよく書けない
これはかなり大きいです。WordPressは多機能ですが、そのぶん「記事を書く」という一点に集中しづらい場面があります。管理画面の体感速度、ブロックエディタの操作、プラグイン同士の干渉など、細かいストレスが積み重なります。
私自身も、書くこと自体より「管理画面の都合に合わせる時間」が増えている感覚がありました。
一方で Astro + MDX にすると、記事はほぼテキストファイルです。エディタは VS Code で十分ですし、見出し・表・コード・補足も Markdown 記法を中心に扱えます。書く環境が軽いと、更新のハードルは想像以上に下がります。
2. 脆弱性がずっと気になる
WordPressそのものが悪いというより、普及率が高いぶん常に狙われやすい、という構造があります。テーマ、プラグイン、ログイン保護、バックアップ、WAF、アップデート確認。これらを適切に回せるなら問題は減りますが、個人や小規模運営ではここに工数を割き続けるのが重いです。
「記事を書いて集客したい」のに、「まず保守し続けないと不安」という状態になりやすい。そこが、私がWordPressを運用コストの高い選択肢だと感じた理由です。
Cloudflare Pages に静的ファイルを置く構成なら、公開面にはWordPressの管理画面もデータベースもありません。もちろんゼロリスクではありませんが、少なくとも「CMSが公開面にぶら下がっている不安」からはかなり離れられます。
3. コンテンツを資産として扱いにくい
ここは技術にやや明るい人ほど気になるはずです。WordPressでは記事データがDB中心で管理されるため、Gitベースのワークフローと相性がよくありません。AIで下書きを作る、差分を見る、レビューする、履歴を残す、といった流れをきれいに組みにくいです。
このブログでは、記事そのものが apps/site/src/content/articles/*.mdx に置かれています。本文も frontmatter も GitHub で差分管理できるので、AI に下書きを書かせ、人間がレビューし、必要なら別の AI に追加確認させる、という流れに自然につながります。
WordPressを使わずにブログを作る基本構成
私がいま推している最小構成は次の4つです。
Astroでサイトを作る- 記事を
Markdown / MDXで管理する GitHubでバージョン管理するCloudflare Pagesで公開する
必要に応じて、独自ドメインを接続し、問い合わせや計測を足していきます。ドメイン取得・リポジトリ管理・公開基盤を別レイヤーとして整理しておくと、あとで手段を入れ替えやすくなります。
ステップ1: Astroで土台を作る
Astroは、コンテンツ中心サイトとの相性がかなり良いです。不要なJavaScriptを極力出さず、生成されるHTMLが軽い。記事主体のメディアでは、この設計思想が効きます。
さらに、Content Collections を使えば frontmatter の型を揃えられます。カテゴリ、タグ、CTA、公開状態などを schema で管理できるので、記事が増えても崩れにくいです。このブログでもその方式を採っています。
ステップ2: 記事はMDXで書く
MDXにすると、Markdownの書きやすさを維持しながら、必要な箇所だけコンポーネントを差し込めます。たとえば CTA、比較表、注意書き、関連記事導線などです。
WordPressのように「エディタ上の見た目はそれっぽいけれど、裏側が複雑」という状態になりにくく、ファイルを読めば構造が分かる。この透明性は、長期運営でかなり重要です。
ステップ3: GitHub連携で更新フローを整える
GitHub を使うメリットは、コード保管だけではありません。
- 記事の変更履歴が残る
- 誰が何を直したか追いやすい
- AI生成文の差分レビューがしやすい
- Cloudflare Pages と連携して push ベースで自動デプロイできる
「ブログを書く」と「サイトを運営する」が同じ流れに乗るので、運用がぶれにくくなります。
ステップ4: Cloudflare Pagesで公開する
Cloudflare Pages を選んだ理由は、速さと無料枠、そしてGitHub連携のシンプルさです。リポジトリをつなぎ、ビルド設定を入れれば、更新のたびに自動で反映できます。 また、個人や小規模メディアの初期フェーズでは「まず固定費を抑えたい」はかなり現実的な要件です。Cloudflare Pages はその意味で始めやすいです。高速CDN寄りの配信基盤としても扱いやすく、WordPressのようにサーバー契約・DB管理・キャッシュ最適化を個別に積み上げる発想から離れられます。
なぜ私は Astro + Cloudflare Pages を選んだのか
理由は4つです。
-
書くことに集中しやすい
記事がテキストファイルなので、執筆環境が軽いです。CMS操作より本文改善に時間を使えます。 -
速いサイトを作りやすい
Astroは静的出力との相性がよく、メディアサイトでも表示速度を出しやすいです。 -
運用コストを下げやすい
WordPress的な保守項目が大幅に減るため、少人数運営と相性が良いです。 -
AI運用に向いている
記事、ログ、プロンプト、ビルド情報をすべてファイルとして扱えるので、AIエージェントと人間の共同編集基盤として成立します。
この「AIが触りやすい」という観点は、今後かなり重要になると見ています。WordPressを完全否定したいわけではありません。ただ、AIと一緒に継続運営する前提なら、Markdown中心の静的構成のほうが自然です。
こんな人にはこの構成が向いている
- WordPressの管理・更新に時間を使いたくない
- 表示速度を重視したい
- 技術に少し慣れていて、GitHub運用に抵抗がない
- 自分やチームでコンテンツを資産として管理したい
- AIで下書き生成や改善提案を回したい
逆に、非技術者だけで即日更新したい、編集者が多数いてWYSIWYG重視、会員機能や複雑な動的機能が必要、という場合はWordPressや別のヘッドレスCMSのほうが向くこともあります。ここは用途で判断すべきです。
まず何から始めればいいか
最初の一歩は、大きく作り込むことではありません。
- Astro の最小ブログを立ち上げる
- 3本だけ記事を書く
- GitHub に載せる
- Cloudflare Pages で公開する
- 独自ドメインをつなぐ
この順番で十分です。最初から完璧なCMSや管理画面を作ろうとすると、だいたい止まります。私もまずは「軽く書けて、速く公開できる」構成を優先しました。
次のアクション
WordPressを使わずにブログを作るなら、重要なのは「何に置き換えるか」より「運用の摩擦をどこまで減らせるか」です。私にとってその答えが Astro + MDX + GitHub + Cloudflare Pages でした。このブログ自体が、その実例です。
まずは無料の Astro メディア構築テンプレで土台を確認するのが早いです。構成から相談したい場合は、ページ下部の相談導線から声をかけてください。遠回りに見えても、最初に軽い基盤を選んだほうが、あとで効きます。