個人の技術ブログを続けていると、更新頻度を落とす原因は「書くことがない」より、公開までの手順が重いことだったりします。

WordPress は今でも非常に成熟した選択肢です。

管理画面、テーマ、プラグイン、複数人編集、権限管理、公開ワークフロー。企業サイトやニュース系メディアでは今でも十分強いです。

ただ、私は自分の長期的な技術ブログでは、だんだん WordPress を使い続けたいと思わなくなりました。

記事を書くだけなのに、キャッシュ、プラグイン、バックアップ、アップデート、互換性、管理画面の可用性まで気にする必要があるからです。

最終的に私は、フロントを Astro、記事を Markdown、公開を GitHub Actions、本番サーバーは静的ファイル配信だけという構成にしました。

目的はシンプルです。

「記事を書くこと」と「常時稼働する CMS を保守すること」を分離したかった。

WordPress が古いからではなく、ランタイムを持ち続けたくなかった

これは WordPress を否定する話ではありません。

WordPress の公式 Hardening WordPress でも、security はリスクをゼロにすることではなく減らすことだと説明しています。

ファイル権限、プラグインの出所、バックアップ、ホスティング環境をまとめて考える必要があります。

Updating WordPress でも、更新は一つのボタンだけではなく、wp-admin、wp-includes、plugins、FTP、.maintenance など複数要素に関係します。

これは WordPress が未成熟だからではありません。むしろ成熟しているからこそ、実運用上の責任範囲まで明確にされているのだと思います。

ただ、個人ブログで長く書き続ける場合、記事更新と「稼働中 CMS の保守」が常にセットになるのは私には重く感じました。

記事が 5 本のときより、30、50、100 本と増えた後でも更新し続けられるかを考えると、前面のテーマより後ろ側の運用摩擦の方が重要になります。

一番大きかったのは、記事が普通のファイルに戻ったこと

Astro というと、静的サイトだから高速、サーバーが軽い、という話が先に出やすいです。

もちろんそれも利点ですが、私が一番気に入っているのは記事そのものがリポジトリ内の Markdown になったことです。

タイトルを変える、description を直す、段落を組み替える、内部リンクを追加する。すべての変更を Git が履歴として残します。

戻したければ commit を戻せばよく、CMS の DB や管理画面に依存しません。

さらに、将来テーマやフロントエンドを作り直しても、コンテンツ自体は普通のテキストファイルです。

これは独立開発者にとって大きな安心感があります。管理しているのが「ある CMS 内に保存された記事」ではなく、長期的に蓄積していく自分の技術資産になるからです。

もう一つ大きいのは、執筆が普段の開発フローとつながることです。

• ローカルで書く
• ローカルで preview
• Git diff を見る
• build
• push

記事公開のためだけに別の管理画面へ頭を切り替える必要がありません。

この小さな差が、長期ではかなり効きます。

Content model を固定すると記事数が増えても崩れにくい

技術ブログは、最初の数本では構造の乱れが見えません。

記事数が増えると、少しずつ問題が出ます。

• description がある記事とない記事
• tag の粒度がばらばら
• 多言語記事の path が一致しない
• category 名を変えたのに古い記事が残る
• SEO metadata の形式が記事ごとに違う

私はこうしたルールをプロジェクト側に固定し、build 時に検証するようにしています。

Astro の Content collections は schema と type safety を強く意識した仕組みです。

私にとって重要なのは「きれいに書ける」ことより、間違った content が build を通らないことです。

言語、path、title、pubDate、category、tags、topic といった frontmatter を最初に制約しておくと、後で SEO、言語別ルート、topic hub を追加しても崩れにくくなります。

WordPress でも同じ構造を作れますが、私はルールを CMS の設定ではなく repository のコードとして持つ方が安心でした。

公開が git push まで短くなると更新の心理的コストが下がる

公開手順の摩擦は、思っている以上に更新頻度へ影響します。

記事を書き終えた後に、

• 管理画面へ移動
• 公開操作
• cache purge
• plugin 確認
• backup
• 本番表示確認

が毎回必要だと、「後でまとめてやろう」となりやすいです。

今の私のフローはもっと短いです。

Markdown を編集し、build を一度確認して、push するだけです。

GitHub Actions では push、schedule、workflow_dispatch といった trigger が標準機能として用意されています。公式ドキュメント に沿って、そのまま通常の CI/CD として構成できます。

このブログでは、だいたい次の流れです。

Markdown を編集
    ↓
ローカル build
    ↓
git push
    ↓
GitHub Actions
    ↓
静的ファイルを build
    ↓
本番サーバーへ upload
    ↓
release を切り替え
    ↓
公開 URL を検証

便利なのは「ボタンが数個減ったこと」ではありません。

記事を書き終えた後に、別の運用モードへ頭を切り替えなくてよくなったことです。

本番サーバーの役割を単純にする

WordPress を運用していたときに私が負担に感じたのは、サーバーが多くの役割を持つことでした。

• CMS
• PHP runtime
• database
• plugin runtime
• cache
• admin login
• content storage

一方、今の構成では build は CI 側で完了します。

本番サーバーは基本的に、

• 静的成果物を受け取る
• release を複数保存する
• current を切り替える
• Nginx で配信する

だけです。

オンライン環境が「よく手を入れるアプリケーション」ではなく、安定した deployment target に近づきます。

結果として、SEO でもテーマページ、内部リンク、代表記事、更新頻度といった content 側に時間を戻しやすくなりました。

Git-first だと AI を公開フローに組み込みやすい

単に WordPress から Astro へ移るだけなら、それ自体は新しい話ではありません。

私が今の構成に将来性を感じるのは、AI を editor の「文章を整えるボタン」ではなく、content pipeline の一部として組み込みやすいことです。

現在のプロジェクトでは、AI workflow が次のような処理を扱えます。

• Markdown や Notion の原稿を読む
• 技術ブログとして構成を整理する
• 機密情報を公開前に除去する
• title / description / slug / category / tags を整える
• 多言語版を作る
• build する
• commit / push
• deployment を確認する

これは、コンテンツが Git 上のファイルとして存在するから自然に組めます。

CMS の管理画面へ AI を追加するというより、content を code と同じように「処理可能な asset」として扱えます。

独立開発者にはこの方が相性が良いと感じています。

どちらが優れているかではなく、数年後の運用に合うか

非エンジニアが管理画面から編集する必要がある、複雑な権限・レビュー・会員機能・フォーム・EC を短時間で追加したい。

そのようなサイトなら WordPress は今でも非常に合理的です。

一方、私のように、

• 個人の技術記事を長期蓄積したい
• SEO を重視する
• content を version control したい
• rollback を簡単にしたい
• 多言語を管理したい
• AI を更新フローに組み込みたい
• 普段の開発習慣と公開手順を揃えたい

なら、Astro + Markdown + GitHub Actions の方が合います。

私が見ているのは「今日 1 本公開するのが楽か」ではなく、「半年後も更新したいと思えるか」です。

その意味で、今はこの構成の方が自分の運用に合っています。