記事
4年ぶりのブログ更新。WordPressの復旧からコンテンツ消失、そしてAWSへの移行まで
この記事の目次 16項目
どうやら、前回の投稿から4年以上が経っているらしい。
この4年間、技術から離れていたわけではない。むしろ、仕事でもプライベートでも、技術に触れる機会は以前より増えている。
それでもブログを更新していなかったのには、いくつか理由がある。
一つは、生成AIの登場によって、技術情報を発信することの価値を、自分の中で見出しにくくなっていたことだ。
以前であれば、開発中に遭遇したエラーや、その解決方法を記事にすることにも一定の意義があった。しかし、今では生成AIに質問すれば、多くの問題はその場で解決できる。生成AIを活用したコーディングが日常になったことで、わざわざ記事として残す意味を考えるようになっていた。
もう一つは、仕事で向き合う課題の変化だ。
前職では、いわゆるJTC（伝統的な日本企業）のDX推進部門に所属していた。そこでは、技術的な課題以上に、組織や現場の業務にデータドリブンな意思決定を根付かせることの難しさを実感した。
技術的に実現できることと、それが組織に受け入れられ、実際の行動変容につながることは、まったく別の話だ。
こうした経験こそ文章にする価値があるのかもしれないが、問題が複雑であるがゆえに、自分の中でもなかなか整理しきれずにいた。
そんなこんなで、気がつけば4年以上が経っていた。
ところが今回、思わぬきっかけでブログを再開することになった。
PHPの脆弱性対応をきっかけにWordPressが動かなくなり、ようやく復旧したと思ったら、今度はブログのコンテンツを失ってしまったのだ。
最終的には、Webアーカイブに残された過去のページを手がかりにコンテンツを復元し、AWS上にブログを再構築することになった。
なかなか波乱に満ちた復旧作業だったので、備忘録として残しておこうと思う。
きっかけはPHPの深刻な脆弱性
2026年10月、PHPに関する深刻な脆弱性が公表された。
条件によっては、外部から認証なしで任意のコードを実行される可能性があるというもので、放置できない内容だった。
詳しくは、以下の記事が参考になる。
当時のブログは、お名前.comのレンタルサーバー上でWordPressを動かしていた。
WordPressはPHPで開発されたCMS（コンテンツ管理システム）なので、PHPの脆弱性とは無関係ではない。
そこで、長らくPHP 7.4のまま運用していた環境を、この機会にPHP 8.4へ更新することにした。
ちなみに、PHP 7.4はすでに公式サポートが終了しているバージョンだ。今回の脆弱性に限らず、以前から更新すべき状態だった。
しかし、ここから思わぬ苦労が始まる。
PHP 8.4に更新したらブログが動かなくなった
レンタルサーバーの管理画面からPHPのバージョンを8.4へ変更したところ、WordPressでエラーが発生するようになった。
どうやら、これまで利用していたWordPressテーマ「LION BLOG」が原因の一つらしい。
LION BLOGは以前から利用していた無料テーマだが、長らく更新されておらず、新しいPHPとの互換性に問題があるようだった。
WordPressは本体だけでなく、テーマやプラグインもPHP上で動作する。
そのため、WordPress本体が新しいPHPに対応していたとしても、テーマやプラグインが古いままだと、サイト全体が正常に動作しなくなることがある。
これまで問題なく動いていたからといって、PHPだけを更新すればよいわけではなかった。
ひとまずPHPを7.4に戻し、元の状態に復旧することにした。
しかし、事態はそう簡単ではなかった。
PHPを戻しても、管理画面で500エラーが発生する
PHPを7.4に戻すと、ブログの公開ページは表示できるようになった。
ところが、WordPressの管理画面にアクセスすると、HTTP 500エラーが発生する。
HTTP 500は、サーバー内部で何らかのエラーが発生したことを示すステータスコードだ。
これだけでは原因を特定できない。
PHPのバージョンを変更したことに加え、プラグインの自動更新などによって、互換性のない組み合わせになっている可能性も考えられた。
問題は、管理画面にログインできないため、WordPress上からテーマやプラグインを操作できないことだ。
つまり、復旧するにはサーバー上のファイルやデータベースを直接操作する必要がある。
ここから、久しぶりに泥臭い作業をすることになった。
サーバー上のファイルをバックアップし、原因を調査する
何かを変更する前に、まずはファイルのバックアップを取ることにした。
普段はMacBookで開発していることもあり、最初はVS CodeのSFTP拡張機能を使って、レンタルサーバー上のファイルをローカルにコピーしようとした。
しかし、なかなかうまくいかない。
ファイル数やサイズ、あるいは通信の問題なのか、途中で転送が止まってしまい、コピーが完了しなかった。
そこで、Mac向けのファイル転送クライアントである「Cyberduck」を使ってみることにした。
結果的には、こちらの方が扱いやすかった。
多少時間はかかったものの、ファイルの転送やサーバー上のファイルの確認・編集がしやすくなった。
続いて、WordPressの wp-config.php を編集し、デバッグログを有効化した。
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
これにより、エラー内容をログに記録しつつ、サイトの画面上には表示しないようにできる。
ログを確認しながら問題を切り分けたところ、まずWordPress本体のファイルに問題があることがわかった。
具体的には、wp-admin や wp-includes に、本来存在するはずのファイルが一部見当たらなかった。
これらは、WordPressの管理画面や内部処理を構成する重要なディレクトリだ。
なぜファイルが不足していたのか、正確な原因はわからない。
ただ、この状態では正常に動作しないため、公式サイトから利用中のWordPress 7.1.3をダウンロードし、該当するディレクトリのファイルをサーバーへ再配置した。
これで一つ問題を解消できた。
しかし、残念ながら管理画面はまだ復旧しない。
テーマとプラグインの互換性問題を解消する
引き続きデバッグログを確認すると、今度はLION BLOGの一部の処理でエラーが発生していることがわかった。
古いテーマのコードが、現在のPHP環境と互換性を持っていないようだ。
となると、テーマを変更したい。
しかし、相変わらずWordPressの管理画面にはログインできない。
そこで、WordPressが設定情報を保存しているMySQLを直接操作することにした。
phpMyAdminでテーマを切り替える
MySQLを操作するために、phpMyAdminを導入した。
phpMyAdminは、ブラウザからMySQLのデータベースを操作できる管理ツールだ。
お名前.comのレンタルサーバー環境では、FTP経由でファイルを配置したり、必要な設定を変更したりと、導入までに思いのほか手間がかかった。
導入にあたっては、以下の記事が参考になった。
お名前.comのレンタルサーバーにphpMyAdminを導入する方法
phpMyAdminからWordPressのデータベースにアクセスし、wp_options テーブルの設定を変更する。
WordPressでは、利用中のテーマに関する情報が、主に次の項目に保存されている。
templatestylesheet
これらを、WordPressの標準テーマである「Twenty Twenty-Five」に切り替えた。
これで問題のあるLION BLOGを読み込まずに済むはずだ。
しかし、それでも管理画面にはログインできなかった。
なかなか手強い。
最後はプラグインの互換性問題
さらにデバッグログを確認すると、今度は一部のプラグインでPHPとの互換性に起因するエラーが発生していることがわかった。
問題になっているプラグインを特定し、サーバー上から該当プラグインを取り除いた。
すると、ようやくWordPressの管理画面にログインできるようになった。
ここまで来れば、あとは通常の管理画面から操作できる。
長かった……。
Cocoonへ移行し、ようやくWordPressが復旧
管理画面が復旧したので、今後もメンテナンスが継続されているテーマへ移行することにした。
選んだのは、無料のWordPressテーマ「Cocoon」だ。
これを機に、なるべく新しい環境でも運用しやすい構成に変更したかった。
Cocoonをインストールして適用し、テーマやプラグインの状態を確認したうえで、再度PHPを8.4へ更新した。
今回は無事にWordPressが動作した。
こうして、ようやく今回のメンテナンスが完了した。
……と思っていた。
まさかのコンテンツ消失
WordPressの復旧後、引き続きサーバー上のファイルを整理していたところ、FTP操作を誤ってブログのコンテンツを削除してしまった。
ここまで苦労して復旧したというのに、まさか自分の操作で再びブログを壊すことになるとは。
当然、バックアップからの復旧を試みた。
しかし、確認してみると、取得していたバックアップには復旧に必要なコンテンツが含まれていなかった。
WordPressでは、記事の本文などはMySQLのデータベースに保存され、画像などはサーバー上のファイルとして保存される。
そのため、サーバー上のファイルだけをバックアップしていても、ブログ全体を復旧できるとは限らない。
今回のバックアップからは、元の状態に戻すことができなかった。
バックアップは取得すること自体が目的ではなく、実際に復元できる状態になっていることが重要なのだと、今さらながら痛感した。
さて、どうしたものか。
10年近く使ってきたドメインを、このまま捨てるのは惜しい
このブログは、10年弱にわたって運用してきたものだ。
ここ数年はほとんど更新していなかったとはいえ、過去に書いた記事もあるし、何より長年使ってきたドメインにはそれなりに愛着がある。
コンテンツを失ったからといって、ブログそのものを終了してしまうのは、どうにも勿体ない。
何とか復旧する方法はないだろうか。
そこで思いついたのが、Webアーカイブの活用だった。
Webアーカイブには、過去のWebページを保存し、当時の状態を閲覧できるサービスがある。
代表的なのが、Internet Archiveの「Wayback Machine」だ。
調べてみると、幸いなことに、当ブログの過去のページもスナップショットとして残されていた。
つまり、元のWordPressやデータベースが失われていても、過去に公開していたページを手がかりに、コンテンツを再構築できる可能性がある。
もちろん、Webアーカイブにすべての記事や画像が保存されているとは限らない。
それでも、何もない状態から作り直すよりは、はるかに現実的な選択肢に思えた。
Webアーカイブからコンテンツを復元し、AWSへ移行する
ここからは、これまでとは少し違うアプローチを取ることにした。
WordPressを再び動かすのではなく、Webアーカイブに残された過去のページからコンテンツを抽出し、静的なWebサイトとして再構築する方法だ。
いわば、公開されていたWebページから元のコンテンツをリバースエンジニアリングするような作業である。
Webアーカイブに保存されたHTMLを取得し、記事のタイトルや本文、画像、URLなどを復元する。
そして、それらをもとに静的なWebページを生成し、AWS上でホスティングする。
今回採用したのは、Amazon S3とCloudFrontを中心とした静的ホスティング構成だ。
- Amazon S3：生成したHTMLや画像などのファイルを保存する
- Amazon CloudFront：保存したWebページをインターネット上に配信する
- Amazon Route 53：ドメイン名と配信先を結びつけるDNSを管理する
ドメインの登録・契約は、引き続きお名前.comを利用することにした。
つまり、ドメインそのものを移管することなく、ブログの配信基盤だけをレンタルサーバーからAWSへ移行した形になる。
この構成なら、WordPressやPHPをサーバー上で動かす必要がない。
当然、WordPressの管理画面やプラグインもなくなるため、従来とは運用方法が変わる。
今後の記事はMarkdownなどで管理し、静的サイトとして生成・公開する運用を想定している。
Webアーカイブからのコンテンツ復元や、AWSでのインフラ構築については、それぞれ技術的に面白い部分があった。
ただ、書き始めると今回の記事がかなり長くなってしまうので、具体的なリバースエンジニアリングの方法やAWSの構成については、別の記事で紹介したい。
今回の対応で感じたこと
レンタルサーバーの制約と、運用の難しさ
今回の一連の対応を通じて、レンタルサーバー環境での作業のしにくさを改めて感じた。
もちろん、レンタルサーバーは手軽にWebサイトを公開できる便利なサービスだ。
しかし、今回利用していた環境ではSSHによる操作ができず、基本的にはFTP/SFTPを通じてファイルを編集する必要があった。
普段の開発では、VS Codeや生成AIを活用したコーディングが当たり前になっている。
特に最近は、LLMを活用したコーディングエージェントにコードベースを調査させ、修正案の作成からテストまで支援してもらうこともできる。
一方、FTPを中心とした操作では、ローカルでファイルを修正してサーバーにアップロードするなど、どうしても手作業が増える。
そして、今回はその操作ミスによって、最終的にコンテンツを失うことになった。
もちろん、これはレンタルサーバーそのものが悪いという話ではない。
適切なバックアップや変更管理ができていなかったことが大きい。
ただ、普段の開発環境とのギャップを感じたのは確かだ。
AI Agentがなければ、今回の選択肢は取れなかったと思う
今回、特に印象に残ったのは、Webアーカイブからのコンテンツ復元とAWSへの移行作業だ。
正直なところ、生成AIによるコーディング支援が一般的になる以前であれば、今回のような方法を選択することはなかったと思う。
Webアーカイブからページを収集し、HTMLを解析し、必要なコンテンツを抽出する。
さらに、それを静的サイトとして再構築し、AWS上のインフラを整備する。
一つひとつの技術要素は、決して新しいものではない。
PythonでWebページを解析することも、AWSで静的サイトを公開することも、以前から可能だった。
しかし、それらを組み合わせて、一つの仕組みとして実装するには、それなりの時間と労力が必要になる。
特に個人ブログの復旧という目的に対して、そこまでの工数をかけるかと言われれば、以前の自分なら躊躇しただろう。
ところが、今は状況が違う。
AIコーディングエージェントを活用することで、実現したいことを具体化し、必要なコードやインフラ構成を短いサイクルで作成・検証できる。
もちろん、AIが出力したものをそのまま採用すればよいわけではない。生成されたコードの妥当性や、セキュリティ、運用方法などを確認する必要はある。
それでも、アイデアを実際に動くものへ変えるまでのハードルが、以前とは比べものにならないほど下がったと感じた。
会社では、AIエージェントを活用したコーディングが当たり前になりつつある。
自分自身も日常的に利用しているので、その有用性は理解しているつもりだった。
それでも、まさか個人ブログの復旧にまで活用することになるとは思わなかった。
本来であれば、諦めていたかもしれないブログの復旧。
それが、Webアーカイブからのコンテンツ再構築という、少し変わった方法で実現できた。
今回の経験は、AIエージェントによって、単に開発が効率化されるだけでなく、これまで工数の面で現実的ではなかった選択肢が、実行可能な選択肢に変わることを実感する機会になった。
WordPressを離れて、改めてCMSの便利さも感じる
今回、最終的にはWordPressを離れ、AWS上の静的サイトへ移行することになった。
静的サイトであれば、PHPやWordPress本体、テーマ、プラグインの互換性を気にする必要はない。
少なくとも、公開サイトの運用においては、今回のような問題が発生する可能性を減らせる。
ただし、その代わりに失うものもある。
WordPressでは、管理画面から記事を書き、画像をアップロードし、プレビューして公開するところまで、一通りの機能が揃っている。
静的サイトでは、こうした仕組みを自分で用意するか、別のサービスと組み合わせる必要がある。
今回のようにMarkdownとGitHubを中心に管理する運用であれば、それほど困らないかもしれない。
一方で、技術に詳しくない人が日常的に記事を更新するのであれば、WordPressの方が使いやすい場面も多いだろう。
結局のところ、どちらが優れているというより、何を重視するかの問題なのだと思う。
今回の自分にとっては、WordPressの機能を維持することよりも、メンテナンス対象を減らし、自由に構成を変更できることの方が魅力的だった。
何より、自分で構築した環境を触ること自体が、趣味として楽しい。
おわりに
PHPの脆弱性対応から始まった今回の作業は、WordPressの復旧、コンテンツ消失、Webアーカイブからの復元、そしてAWSへの移行と、想像もしなかった展開になった。
振り返ってみると、長期間メンテナンスしていなかったことや、バックアップの不備など、反省すべき点は多い。
一方で、AIコーディングエージェントという新しい開発手段があったからこそ、これまでなら諦めていたかもしれない方法でブログを再構築できた。
そう考えると、今回の一件も悪いことばかりではなかったのかもしれない。
そして、冒頭で触れた「生成AIの時代に、技術ブログを書く意味」についても、少し考えが変わった。
技術的な手順そのものは、今や生成AIに聞けば教えてもらえることも多い。
しかし、なぜその技術を選んだのか、どこで失敗し、何を考えて別の方法を試したのか。
こうした実体験や意思決定の過程には、まだ文章として残す価値があるのではないだろうか。
少なくとも、今回のような失敗と試行錯誤は、生成AIに質問しただけでは得られなかった経験だ。
今後は、Webアーカイブからのコンテンツ復元や、AWS上での静的サイト構築についても記事にしていきたい。
4年以上空いてしまったが、これを機に、また少しずつブログを書いていこうと思う。