このブログは2022年2月を最後に、4年ほど更新が止まっていました。
WordPressのバージョンは5.9。テーマのSWELLも2022年当時のまま。プラグインに至っては、すべて4年前のバージョンで止まっていました。
放置していたサイトを最新化するまでの記録を、3回に分けて書きます。1回目は、なぜ更新が止まったのかと、現状をどう把握したかについてです。
なぜ4年も放置したのか
一番の理由は、率直に言って飽きたからです。
やる気満々で始めたにもかかわらず、すぐに飽きました。思い返してみると、1本書くのにそれなりに時間がかかるわりに、書いたところで別に何にもならない。そこでやる気を失った気がします。
ネタがなかったわけではありません。書きたいことはいろいろありました。ただ「また数時間かかるのか…」と思うと、ついつい別のことをしてしまう。その繰り返しでした。
そして決定的だったのは、焦る理由がなかったことです。前職からの繋がりや紹介で仕事が入ってきていたので、ブログを営業ツールとして機能させる必要がありませんでした。書かなくても困らない、という状況が4年続いたわけです。
再開した理由
状況が変わりました。
ひとつは、AIの普及によって制作の仕事の性質が変わってきたことです。以前なら外注していた範囲を、クライアント側がAIを使って内製化するケースが出てきました。仕事の総量というより、外に出る部分が減っている感覚です。
ただ、これをAIのせいだと言い切るつもりはありません。そもそも私が営業活動をしてこなかったツケが、たまたまこのタイミングで表面化しただけかもしれない。紹介頼みで4年間やってきたのだから、当然といえば当然です。
いずれにせよ、自分から動く必要が出てきました。そこで営業活動の一環として、このブログを立て直すことにしました。
もうひとつのきっかけはWordPress 7系のリリースです。従来とはかなり違う方向性で、触ってみたいと思いました。それをそのまま記事にできれば一石二鳥です。
加えて、LLMOのように「AIに読まれる記事をどう書くか」という話題が出てきています。こういうものは人のサイトで実験するわけにいかないので、自分のブログでやるのが一番です。
書くハードルが下がった
もうひとつ、再開を後押しした要素があります。
4年前に挫折した「1本書くのに数時間かかる」という問題が、かなり軽減されました。作業しながら詰まったところをメモしておけば、そこから記事の構成を組み立てたり、下書きを起こしたりする部分はAIに任せられます。
実際、この記事もそうやって書いています。作業ログとエラーメッセージを渡して、構成を整理してもらい、内容を確認しながら仕上げる。素材は自分、加工はAI、という分担です。
逆に言えば、素材がなければ書けません。実際に手を動かして詰まった記録がないと、どこかで見たような一般論しか出てこない。そこはこれまでと変わらないと思っています。
仕事が減る一因になったのもAIなら、ブログを再開できたのもAIというのは、少し皮肉な話ですが。
現状を把握する
さて、実際に何がどうなっているのか。まずは本番サーバーにSSHで接続して確認しました。
WordPressのバージョン
grep "wp_version =" wp-includes/version.php$wp_version = '5.9.16';5.9のリリースは2022年1月。4年前です。
ちなみに末尾の .16 は、5.9系のセキュリティリリースが16回当たっていることを意味します。WordPressは旧バージョンにもセキュリティパッチを提供していて、マイナーアップデートは自動で適用されます。つまりコアのセキュリティは維持されていた、ということです。
テーマとプラグイン
ls wp-content/themes
ls wp-content/pluginsテーマはSWELLと自作の子テーマ。プラグインは8個入っていました。内訳はセキュリティ、バックアップ、SEO、サイトマップ生成、コードハイライト、開発補助といったところで、どれもよくある構成です。（プラグイン名は伏せておきます）
SWELLのバージョンも確認します。
grep -i version wp-content/themes/swell/style.cssVersion: 2.5.8.52022年前半のバージョンでした。現行版は2.19系なので、14世代分の差があります。
タイムスタンプから状態を読む
ここで面白い情報が出てきました。wp-content の中身をタイムスタンプ付きで見てみます。
ls -la wp-content/drwxr-xr-x 8 user group 145 8月 22 09:41 .
-rw-r--r-- 1 user group 28 11月 12 2021 index.php
drwxr-xr-x 4 user group 4096 10月 4 2025 languages
drwxr-xr-x 10 user group 254 8月 24 09:28 plugins
drwxr-xr-x 4 user group 71 2月 12 2022 themes
drwxr-xr-x 2 user group 10 8月 13 09:55 upgrade
drwxr-xr-x 11 user group 205 1月 1 2026 uploads注目したのは日付のばらつきです。
themesは2022年2月のままlanguagesは2025年10月pluginsは当日
themes が4年前で止まっているのは想定どおり。一方で languages（翻訳ファイル）が2025年に更新されているのは、WordPressが自動で翻訳を取得しているからです。
問題は plugins が当日更新されていたことです。私はこの日、プラグインを触っていません。
このとき私は「プラグインの自動更新が動いているのだろう」と考えました。この判断は後に間違いだと分かるのですが、それは第3回に書きます。
いずれにせよ、タイムスタンプを見るだけで「どの部分が生きていて、どの部分が止まっているか」がある程度わかります。引き継ぎで受け取ったサイトの状態を調べるときにも使える方法です。
サーバー環境
PHPのバージョンも確認しておきます。ここで少し引っかかりました。
php -vPHP 5.4.16 (cli) (built: Apr 1 2020 04:07:17)PHP 5.4。さすがにこれでWordPressは動きません。
調べてみると、Xserverではサーバーパネルで設定したPHPのバージョンと、SSHでログインしたときのコマンドライン用PHPは別物として扱われるようです。CLI側は初期状態で 5.4.16 になっているという報告が複数見つかりました。私が見た出力も、他の方が数年前に書かれている内容とビルド日まで一致していたので、長らくこの状態が続いているのだと思います。
実際のバージョンはサーバーパネルの「PHP Ver.切替」で確認できました。
PHP 8.2.30つまりこのサイトは、WordPress 5.9をPHP 8.2で動かしている状態でした。5.9のリリース時点でPHP 8.2は存在していないので、公式には想定外の組み合わせです。動いてはいるものの、内部では大量の警告が出ているはずでした。（実際そのとおりで、ローカルに持ってきたときに大量のDeprecated警告が出ました）
CLIのPHPが古いとWP-CLIが動かない
この「WebとCLIでPHPのバージョンが違う」という状況は、実作業で地味に効いてきます。
WordPressにはWP-CLIというコマンドラインツールがあり、データベースのエクスポートやプラグインの操作をコマンドで実行できます。XserverにもWP-CLIは用意されているのですが、実行しようとするとエラーになりました。
WP-CLIの動作要件はPHP 7.0以上。CLI側が5.4では要件を満たしていません。
対処法としては、自分のホームディレクトリにWP-CLIを入れて、新しいPHPを明示的に指定して実行する方法があります。
mkdir -p ~/bin && cd ~/bin
curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar
chmod +x wp-cli.pharそのうえで、実行時に使うPHPを指定します。
alias wp='/usr/bin/php8.2 ~/bin/wp-cli.phar'/usr/bin/php8.2 の部分は環境によって異なります。次のようなコマンドで、サーバーに入っているPHPを探せます。
ls /usr/bin/php*
ls -d /opt/php*/bin/php 2>/dev/nullエイリアスを ~/.bashrc に書いておけば、次回以降も使えます。
echo "alias wp='/usr/bin/php8.2 ~/bin/wp-cli.phar'" >> ~/.bashrc
source ~/.bashrc
wp --infowp --info の出力でPHPのバージョンが8系になっていれば準備完了です。
なお、そもそもCLIで使われるPHP自体を切り替えてしまう方法もあるようです。~/bin に新しいPHPへのシンボリックリンクを張って、PATH の優先順位を上げるという考え方です。
ln -s /usr/bin/php8.2 ~/bin/php
echo 'export PATH=$HOME/bin:$PATH' >> ~/.bashrc
source ~/.bashrcこちらのほうが根本的ですし、cronでPHPを実行する場合にも効いてきそうです。今回は試していないので「こうすればよさそう」という程度ですが、CLIを頻繁に使うなら検討する価値がありそうです。
ただ今回は、データベースをエクスポートできれば十分だったので、深追いはしませんでした。phpMyAdminからでも同じことができるからです。
サーバーパネルからphpMyAdminにログインし、対象のデータベースを選んでエクスポートタブから実行するだけ。記事7本程度のサイトならダンプは数MBなので、ブラウザ経由でまったく問題ありません。
コマンドで解決しようとしてPHPのパス探しに時間を使うより、動くほうを選ぶ、という判断です。
「中途半端に生きているサイト」
現状をまとめるとこうなります。
| 項目 | 状態 |
|---|---|
| WordPress | 5.9.16（メジャーは4年前、セキュリティパッチのみ適用） |
| テーマ（SWELL） | 2.5.8.5（14世代前） |
| プラグイン | 8個すべて4年前 |
| PHP | 8.2.30（本体より新しい） |
| 翻訳ファイル | 2025年に自動更新 |
完全に死んでいるわけではありません。コアのセキュリティパッチは当たり続けているし、サイトも普通に表示されています。
一方で、メジャーアップデートだけが4年止まっている。PHPだけが先行して新しい。このちぐはぐな状態が、実は一番厄介です。
なぜなら、いつ壊れるか予測できないからです。プラグインが新しいコアを前提に更新されれば、5.9との組み合わせで動かなくなる可能性がある。PHPがさらに上がれば、5.9のコードが対応できなくなる。自分が何もしていないのに、ある日突然壊れる可能性があります。
そして、こういう「中途半端に生きているサイト」は、実際にはかなり多いのではないかと思います。完全に放置されて壊れているサイトより、動いているぶん問題が見えにくい。制作会社が引き継ぎで受け取るサイトも、たいていこの状態でしょう。
次にやること
現状が把握できたので、方針を決めました。
- 本番をローカルに複製する — これまで本番で直接編集していたので、まずそれをやめる
- 段階的にアップグレードする — 一気に上げず、壊れたときに原因を特定できるようにする
- 順序を守る — テーマ → WordPress本体 → PHP の順。逆にすると壊れる
次回は、本番サイトをローカル環境に持ってくる作業を書きます。XserverからのSSH接続、rsyncでの取得、データベースの移行、そしてGit管理の立て直しについてです。
作業中、本番で直接編集していた痕跡がはっきり残っていることも分かりました。そのあたりも含めて書きます。
なお、ローカルに持ってきた際に出た大量のDeprecated警告については、
表示を止めるだけでもひと苦労でした。
