どうやら、前回の投稿から4年以上が経っているらしい。
この4年間、技術から離れていたわけではない。むしろ、仕事でもプライベートでも、技術に触れる機会は以前より増えている。
それでもブログを更新していなかったのには、いくつか理由がある。
一つは、生成AIの登場によって、技術情報を発信することの価値を、自分の中で見出しにくくなっていたことだ。
以前であれば、開発中に遭遇したエラーや、その解決方法を記事にすることにも一定の意義があった。しかし、今では生成AIに質問すれば、多くの問題はその場で解決できる。生成AIを活用したコーディングが日常になったことで、わざわざ記事として残す意味を考えるようになっていた。
もう一つは、仕事で向き合う課題の変化だ。
前職では、いわゆるJTC（伝統的な日本企業）のDX推進部門に所属していた。そこでは、技術的な課題以上に、組織や現場の業務にデータドリブンな意思決定を根付かせることの難しさを実感した。
技術的に実現できることと、それが組織に受け入れられ、実際の行動変容につながることは、まったく別の話だ。
こうした経験こそ文章にする価値があるのかもしれないが、問題が複雑であるがゆえに、自分の中でもなかなか整理しきれずにいた。
そんなこんなで、気がつけば4年以上が経っていた。
ところが今回、思わぬきっかけでブログを再開することになった。
PHPの深刻な脆弱性が公表され、長らく放置していたWordPressのメンテナンスが必要になったのだ。
これが思いのほか大変で、紆余曲折を経てようやく復旧できた。
せっかくなので、今回の対応を備忘録として残しておこうと思う。
きっかけはPHPの深刻な脆弱性
2026年10月21日、PHPに関する深刻な脆弱性が2件公表された。
- CVE-2026-109618
- CVE-2026-109619
いずれも、条件によっては外部から認証なしで任意のコードを実行される可能性がある、深刻な脆弱性だ。
詳しくは、以下の記事が参考になる。
PHPの2件の深刻な脆弱性についてまとめてみた – piyolog
当ブログは、お名前.comのレンタルサーバー上でWordPressを動かしている。
WordPress自体はPHPで開発されたCMS（コンテンツ管理システム）なので、今回の脆弱性も無関係ではない。
そこで、長らく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のバックアップには、ファイルだけでなくMySQLのデータも必要になる。記事や各種設定はデータベースに保存されているためだ。
デバッグログを有効化して原因を調査する
次に取り組んだのは、500エラーの原因調査だ。
WordPressには、PHPのエラーなどをログファイルに出力するデバッグ機能がある。
通常は管理画面から設定するわけではなく、サーバー上にある 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
引き続きデバッグログを確認すると、今度はLION BLOGの一部の処理でエラーが発生していることがわかった。
古いテーマのコードが、現在のPHP環境と互換性を持っていないようだ。
となると、テーマを変更したい。
しかし、相変わらずWordPressの管理画面にはログインできない。
そこで、WordPressが設定情報を保存しているMySQLを直接操作することにした。
phpMyAdminを使ってテーマを切り替える
MySQLを操作するために、phpMyAdminを導入した。
phpMyAdminは、ブラウザからMySQLのデータベースを操作できる管理ツールだ。
通常であればWebブラウザ上で比較的簡単に操作できるのだが、お名前.comのレンタルサーバー環境では、導入するまでがなかなか面倒だった。
FTP経由でファイルを配置したり、必要な設定を変更したりと、思いのほか手間がかかった。
導入にあたっては、以下の記事が参考になった。
お名前.comのレンタルサーバーにphpMyAdminを導入する方法
phpMyAdminからWordPressのデータベースにアクセスし、wp_options テーブルの設定を変更する。
WordPressでは、利用中のテーマに関する情報が、主に次の項目に保存されている。
templatestylesheet
これらを、WordPressの標準テーマである「Twenty Twenty-Five」に切り替えた。
これで問題のあるLION BLOGを読み込まずに済むはずだ。
しかし、それでも管理画面にはログインできなかった。
なかなか手強い。
最後はプラグインの互換性問題
さらにデバッグログを確認すると、今度は一部のプラグインでPHPとの互換性に起因するエラーが発生していることがわかった。
問題になっているプラグインを特定し、サーバー上から該当プラグインのファイルを取り除いた。
すると、ようやくWordPressの管理画面にログインできるようになった。
ここまで来れば、あとは通常の管理画面から操作できる。
長かった……。
Cocoonへテーマを移行し、PHP 8.4への更新が完了
管理画面が復旧したので、今後もメンテナンスが継続されているテーマへ移行することにした。
選んだのは、無料のWordPressテーマ「Cocoon」だ。
以前のテーマに強いこだわりがあったわけではないし、これを機に、なるべく新しい環境でも運用しやすい構成に変更したかった。
Cocoonをインストールして適用し、テーマやプラグインの状態を確認したうえで、再度PHPを8.4へ更新した。
今回は無事にWordPressが動作した。
こうして、ようやく今回のメンテナンスが完了した。
振り返ると、原因は一つではなく、WordPress本体のファイル、テーマ、プラグインと、複数の問題が重なっていた。
長期間メンテナンスを怠ると、いざ更新が必要になったときに、まとめて技術的負債を返済することになる。
身をもって実感した。
今回の対応で感じたこと
レンタルサーバーは便利だが、自由度の低さがもどかしい
今回、特にもどかしく感じたのは、レンタルサーバー環境での作業のしにくさだった。
現在は、お名前.comで契約したレンタルサーバーを利用している。
プランや契約内容にもよるが、今回の環境ではSSHを使った操作ができず、基本的にFTP/SFTP経由でファイルを編集する必要があった。
普段の開発では、VS Codeや生成AIを活用したコーディングが当たり前になっている。
特に最近は、LLMを活用したコーディングエージェントにコードベースを調査させ、修正案の作成からテストまで支援してもらうこともできる。
もしSSHでサーバーに接続できる環境であれば、権限や安全性に配慮しつつ、ログの調査やファイルの確認、修正などをもっと効率的に進められただろう。
一方、今回のようにファイル転送を中心とした操作しかできない環境では、作業の自由度がどうしても制限される。
エラーを調べ、関連するファイルを確認し、ローカルで修正してサーバーにアップロードする。
生成AI以前の開発スタイルを思い出すような作業だった。
もちろん、これはレンタルサーバー全般の問題というより、今回利用しているサービスやプランの制約によるところが大きい。
とはいえ、普段の開発環境とのギャップを強く感じた。
だからといって、WordPressを捨てるべきかというと……
今回のような経験をすると、WordPressを使い続けるべきなのか、少し考えてしまう。
WordPressは非常に便利なCMSだが、PHP本体、WordPress本体、テーマ、プラグインと、複数のコンポーネントを継続的にメンテナンスする必要がある。
それぞれの更新タイミングや互換性まで考慮すると、長期間放置した環境の更新はなかなか骨が折れる。
では、AWSに移行して、CMSのような仕組みを自分で構築すればよいのか。
技術的にはできるだろう。
例えば、静的サイトとしてブログを構築し、S3やCloudFrontで配信する構成も考えられる。
これなら、少なくとも公開サイトでPHPやWordPressを動かす必要はなくなる。
ただし、記事の投稿・編集、画像管理、下書き、プレビューなど、WordPressが当たり前のように提供している機能をどう実現するかという問題が残る。
また、AWSに移行したからといって、セキュリティや運用の問題がなくなるわけでもない。
自分で構築するということは、その分だけ自分で管理しなければならない領域も増えるということだ。
そう考えると、CMSとしての機能を手軽に利用できるWordPressの優位性も、改めて感じる。
何だかんだで、WordPressはよくできている。
それでも、AWSへの移行は少し楽しそうだ
とはいえ、今回の一件で、ブログのインフラを見直したい気持ちが強くなったのも事実だ。
今の自分にとって、ブログは技術情報を発信する場所であると同時に、趣味として新しい技術を試す場所でもある。
そういう意味では、AWS上に自分なりのブログ基盤を構築してみるのも面白そうだ。
運用コストやメンテナンスの負担を考えれば、必ずしも合理的な選択とは限らない。
それでも、個人開発なのだから、合理性だけを追い求める必要もないだろう。
しばらくはCocoonで運用しつつ、いずれはAWSへの完全移行も検討してみたい。
そして、今回のような技術的なトラブルだけでなく、仕事で経験してきたDXやデータ活用の難しさについても、少しずつ言語化していければと思う。
4年ぶりのブログ再開が、単なるトラブル対応の記録で終わらないことを願っている。
コメント