WordPressをやめて静的ブログへ。試して、つくって、わかった7つのこと

本ブログは、たまたま数か月前からWordPressをやめ、すべての記事をMarkdownの.mdファイルで管理し、静的なHTMLに書き出すシステムを構築して切り替えていた。原稿から公開前にページを作る、いわゆるAstro的な構成だ。https://docs.astro.build/…/on-demand-rendering/

そこへ、PHPの重大な脆弱性のニュースが届いた。WordPressなどが使うPHPの実行環境に問題があり、影響を受ける構成ではログインせずに攻撃者のコードを実行されるおそれがある。修正版は2026年10月21日に公開された。https://www.php.net/archive/2026.php#2026-10-21-5

このニュースを見て、サーバーで動くCMSという記事管理システムから、静的HTMLをFTPで公開する方式へ、まさか流れが戻るのかと感じた。大規模言語モデルであるLLMの登場によって、記事中心の用途では、昔ながらの静的HTMLが最先端の選択にも見えてくる。この巡り合わせが面白くて、記事にしたくなった。

静的HTMLは、攻撃される処理そのものを減らせる

違いは、読者からアクセスされたときに、公開サーバーが何をするかだ。WordPressのような動的CMSは、通常、PHPを動かし、データベースから記事を取り出してページを作る。

管理画面、プラグイン、画像のアップロードなど、外部からの入力を受け付ける処理もある。こうした処理に欠陥があると、不正な入力から改ざんやコード実行につながる。ログイン前に動く処理の欠陥は、管理画面のパスワードを強くするだけでは防げない。会員情報を扱うサイトなら、情報流出に発展するおそれもある。

本ブログの方式では、記事を組み立てる処理を手元のPCで済ませ、公開サーバーは完成済みのHTMLを返す。公開用CMSや記事用データベースを置かないので、それらを狙う攻撃経路を減らせる。鍵を増やすというより、使わない出入口をなくす考え方だ。https://cheatsheetseries.owasp.org/…/Attack_Surface_Analysis_Cheat_Sheet.html

ただし、HTMLに置き換えても、古いPHPやCMSが外部から動かせる状態で残っていれば危険は残る。Webサーバーや編集用PC、転送アカウント、配信するJavaScriptの保守も必要だ。

この構成で実際に運用し、直してきた7つの点を紹介したい。

1. Markdownは、人間には読みにくかった

原本は.mdがよさそう、と少し安易に決めた。Markdownは見出しや箇条書きを記号で書くテキスト形式だ。AIに渡しやすく、整理もしやすい。しかし、そのまま眺めても画像の並びや余白など、記事の感じがつかめない。

試行錯誤の末、MarkdownをHTMLに変換して表示し、その上で編集できるビジュアルエディターを作った。原本はMarkdownのまま、公開ページに近いデザインを見ながら書ける。これで一気に作りやすくなった。

2. タイトルやタグの管理が困難になった

ファイルを並べただけでは、タイトル、日付、タグ、代表画像などを管理しにくい。そこで原稿の先頭に、記事の設定をまとめるfrontmatterを付けた。短い例なら、こうなる。

---
title: "31.5型4Kモニターを使ってみた"
date: "2026-10-18"
draft: false
tags: ["PC", "Review"]
---

実際には説明文、代表画像、記事の識別子やURL名も持たせる。共通のレイアウトと組み合わせてページを作り、タイトルや日付、タグは画面から編集できるようにした。情報の置き場所と操作画面がそろうと、管理の不便は気にならなくなった。

3. 見出しや引用の記法を、毎回思い出すのが面倒だった

H1、H2といった見出しや引用、表、YouTubeの埋め込み。記事を書くたびに記法を思い出すのは面倒だ。

見出しや引用を挿入パネルから選び、YouTubeのURLから埋め込みを作れるようにした。原稿の保存形式がMarkdownでも、人間が記号を全部手打ちする必要はない。

4. 1記事の更新でも、公開までに時間がかかった

1記事を更新するだけでも、記事一覧や検索用データなどを作り直す。公開前の比較やコピーにも時間がかかり、送信を待つ以前の処理が重かった。

そこで生成対象をブログに絞り、同じ内容のファイルは書き直さないようにした。前回このPCから公開に成功した内容と比較し、追加・変更分だけを転送用にコピーして送る。ファイルの識別情報や変更情報が同じなら、内容照合の計算結果も再利用する。

ブログの各ページを再生成する処理は残っている。通常の更新では、全件の遠隔照合や不要なコピー・転送を省くことで、待ち時間を減らせた。

5. 画像や動画の再アップロードが負担になった

特に重いのが画像や動画だ。本文を少し直しただけなのに、大きな素材まで送り直すのはつらい。

素材の内容から作る識別子を公開URLに含め、同じ素材は同じURLで再利用するようにした。公開済みの記録と照合し、変わっていない素材は再送しない。新しい画像や動画は送るが、記事の更新ごとに全部送り直すことはなくなった。

6. 記事を下書きに戻しても、公開先には残っていた

原稿を下書きに戻しても、公開済みのHTMLはサーバーに残る。記事の削除や公開対象からの除外は、意外に面倒だった。

今は公開を取りやめる記事を記録し、次の公開処理で反映する。公開の記録がある記事について、削除対象とサーバー上の内容を照合し、該当するHTMLと公開用Markdownだけを削除する。

画像や動画は自動削除しない。他の記事でも使っている素材を巻き込まないためだ。記事と素材を分けて扱うことで、運用しやすくなった。

7. 自宅のPCでしか、記事を更新できなくなった

原稿も編集環境もローカルにある。WordPressのように、別の場所から管理画面を開いて更新する使い方ができなくなった。これが一番不便だった。

今はDotsなどのエージェントを通じて、スマートフォンから自宅PCでの原稿修正を指示できるようになった。外出先で気づいた修正をその場で頼めるようになり、この不便もずいぶん小さくなった。

仕組みは、原稿・生成・公開を分ける

全体の流れは、次のようになる。

手元のPC：Markdown＋画像 → ビジュアル編集 → HTML・一覧・検索データ
公開先　：確認した変更分をFTPSで受け取り、読者へ配信

FTPSはファイル転送の通信を暗号化する方式だ。ファイル操作とHTML生成はRustで実装し、編集画面には、Windowsアプリ内にWeb画面を表示するWebView2を使っている。公開サーバーで記事を組み立てるCMSは動かさない。

自作するなら、まず1記事をHTMLにするところから始め、共通レイアウト、記事管理、公開処理を足していくと考えやすい。

結局、CMSが引き受けていた仕事を、手元のPCで少しずつ作り直していた。Markdownを選ぶだけで完成ではなく、編集と管理と公開まで整えて、ようやく使いやすくなった。同じようなブログを考えている人の参考になればうれしい。