PHPの脆弱性で考える個人ブログの安全性。実際にWordPressをやめて静的HTMLへ移行したら思わぬ不便があった話

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

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を動かし、データベースから記事を取り出してページを作る。管理画面、プラグイン、画像のアップロードなど、外部からの入力を受け付ける処理もある。

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

本ブログの方式では、記事の作成やHTMLの生成を手元のパソコンで済ませ、公開サーバーは完成済みのHTMLを返す。公開用CMSや記事用データベースを置かないので、それらを狙う攻撃経路を減らせる。使わない出入口そのものをなくす考え方だ。https://cheatsheetseries.owasp.org/…/Attack_Surface_Analysis_Cheat_Sheet.html

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

しかし実際に運用してみると、CMSを使っていたときには意識しなかった不便に直面した。

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

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

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

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

CMSでは当たり前の機能であるが統一された方式がなくなった。ファイルを並べただけでは、タイトル、日付、タグ、代表画像などを管理しにくい。とても困った。そこで原稿の先頭に、記事の設定をまとめるfrontmatterを付けた。短い例なら、こうなる。

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

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

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

H1、H2といった見出しや引用、表、YouTubeの埋め込み。記事を書くたびに記法を思い出すのは面倒だ。というか.mdの方式はシャープ二つとか、簡単なのだけど馴染みがない。

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

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

本システムは、1記事を更新するだけでも、ブログの記事ページや一覧、検索用データをまとめて再生成する構成にした。静的サイトだから必ず全件の作り直しが必要というわけではなく、これは本システムの作りによるものだ。公開前の比較やコピーにも時間がかかり、送信を待つ以前の処理が重かった。10分ぐらいかかってしまった。どうしようもない。

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

ブログの各ページを再生成する処理は残っている。通常の更新では、全件の遠隔照合や不要なコピー・転送を省くことで、待ち時間を減らせた。これで許容できる時間で公開できるようになった。100記事ぐらいなら問題ない。1000記事になるとどうだろうか。

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

特に重いのが画像や動画だ。本文を少し直しただけなのに、大きな素材まで送り直すのはつらい。30分とか60分とか時間がかかった。これはひどい。

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

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

原稿を削除したり下書きに戻しても、公開済みのHTMLはサーバーに残る。記事の削除や公開対象からの除外は、意外に面倒だった。原稿の.mdと、そこから書き出したHTMLを別々に扱う必要があるためだ。

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

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

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

原稿も編集環境もローカルにある。WordPressのように、別の場所から管理画面を開いて更新する使い方ができなくなった。これが一番不便だった。今の運用では、原稿と公開の記録を同じPCにまとめているため、別のPCへ気軽に切り替えられない。つまり原本がある1台のパソコンからの作業が必要だ。

そこでDotsなどのエージェントを通じて、スマートフォンから自宅PCでの原稿修正を指示できるようになった。外出先で気づいた修正をその場で頼めるようになり、この不便もずいぶん小さくなった。1台のPCは常時LLM用に電源を入れてある。なんかサーバーに近い稼働になった。

その結果メリットも増えてきた

2-3か月かけて、いろいろな不便を直したらだいぶ使いやすくなった。また大きなメリットも出てきた。原本が.mdファイルなので、マルチランゲージの変換が簡単にできることや、表示速度が速くなったことなどだ。リモートでLLMに記事の下書きを頼むことも増えた。だんだん便利になった。

ざっと仕組みを紹介、参考になればうれしいな

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

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

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

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

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