このブログは2004年に始めて、もう20年を超えました。古い記事をたまに読み返すと、画像が表示されていなかったり、サムネイルをクリックしても元画像が出てこなかったりする記事がけっこうあります。前から気にはなっていたんですが、なかなか手が回っていませんでした。
ブログプラットフォームの変遷
リンクが切れている原因は、このブログの歴史にあります。最初はHTMLを手書きし、その後HTML編集ツールを使うようになり、CMSを導入し、さらにCMSを乗り換え、その間にサーバーの移行も何度かしています。
移行のたびに記事は引っ越してきたんですが、画像の参照先までは完全に移せていなかった模様です。画像の置き場所も、/Images/ディレクトリだったり、サイトのルート直下だったり、CMSの/files/フォルダだったりと、時代ごとにバラバラ。今年の夏に自宅サーバーをラズパイからミニPCへ移したので、これを機に古い記事も片付けることにしました。
これまでのやり方
リンク切れに気がついたら、記事のソースを開いて画像のリンクを確認し、サーバーの中から該当しそうなファイルを探して、リンクを書き換える。これまではこれを手作業でこつこつやっていました。1記事なら大したことはないんですが、全部の記事を確認するのはとても無理。気がついたものだけ直す、という状態でした。
AIエージェントに調べてもらう
そこで、サーバー移行でもお世話になったHermes Agentに、リンク切れの調査を頼んでみました。まずは一番古い2004年と2005年の記事を対象に、表示されない画像を洗い出し、その画像がサーバー内にあるかを確認してもらいます。
2年分の記事は286件。そのうち画像を含む記事は92件、画像の参照は125件で、87件が表示できない状態でした。2004年に至っては、画像50件が全滅です。
原因はあっけないもので、記事側のリンクは/images/、サーバー上のディレクトリは/Images/。頭文字が大文字か小文字かの違いだけでした。LinuxではimagesとImagesは別物扱いなので、これだけでリンクが切れていたわけです。画像ファイル自体はちゃんとサーバーに残っていました。
これならパスを直すだけで済みます。https://www.wandaba.com/images/をhttps://www.wandaba.com/Images/に置き換えてもらい、ついでにhttpsにも統一しました。記事中のサムネイルだけでなく、クリックで開く元画像へのリンクもまとめて直して、56記事・187箇所。2004年の画像はすべて表示されるようになりました。2005年に残った13件は、全部Amazonの古い商品画像でした。こちらは自分のサーバー側では直せないので、後回しにしています。
画像が二重に開く
画像が表示されるようになったところで、新しい問題が出てきました。サムネイルをクリックすると、ポップアップウインドウとLightBoxの両方で画像が開く記事があります。
調べてもらうと、昔のHTML編集ツールが埋め込んだポップアップ用のJavaScript（window.open()）と、今のWordPressのLightBoxプラグイン用の指定が、同じリンクに両方付いていました。これまではポップアップ側の画像パスも切れていたので目立たなかったんですが、パスを直したことで両方が動くようになった模様です。
古いポップアップの処理だけを外して、LightBoxに一本化してもらいました。2004・2005年で69記事・93箇所。その後、2006〜2008年分も同じように直して、全部で180記事を超えました。
ちなみに記事本文を書き換えるときは、毎回変更前の本文をバックアップしてから作業してもらっています。いざとなれば元に戻せるので、安心して任せられます。
サーバーにない画像は写真ライブラリから
続けて2006年以降も調べていくと、サーバー内に画像そのものがないケースが増えてきました。そこで、Macの写真ライブラリを探してもらいました。昔のデジカメや携帯で撮った写真もライブラリに取り込んであるので、記事に残っているファイル名で検索すれば見つかるはず、という作戦です。
これがけっこう当たりました。2008〜2011年の記事で、ファイル名で見つけた写真を使って20記事以上を直しています。写真ライブラリの元画像をサーバーに置き、サムネイルを作り直して、リンクも張り替えてもらいました。
ただ、DVC00003.JPGのようなデジカメの連番ファイル名は、カメラを変えたり番号が一周したりすると、同じ名前の写真がたくさん出てきます。DVC00003.JPGだけで14枚ありました。実際、サーバーに同じ名前の画像があって、AIはパスを直せば復旧できると判断したんですが、表示してみたら記事とは別の写真でした。そこで、ファイル名が一致して、かつ撮影日が記事の時期と合っている写真を正解とするルールにして、差し替えてもらっています。
AIもそれなりに間違える
この差し替えのときは、AIのミスにも2回ほど付き合うことになりました。1回目は、画像ファイルは差し替えたのに記事側のリンクが直っていなかったこと。2回目は、リンクを直す置換処理で画像のURLが壊れて、サムネイルが壊れた画像アイコンになっていたことです。どちらも「直しました、HTTP 200で確認済み」と報告が来ていたんですが、実際にページを開いてみたらおかしかった、というパターンでした。
画像ファイルが存在することと、ページで正しく表示されることは別物ですね。最後は自分の目でページを見て確認するのが大事だと、改めて思いました。
ファイル名で見つからない写真
一番厄介だったのは2010〜2011年頃の記事です。当時はスマホから直接投稿していて、CMSのプラグインがアップロード時に画像を変換していたので、ファイル名が20100103102013_1856.jpgのような形式に変わっていました。旧サーバーに残っていた画像アーカイブやInternet Archiveも探してもらったんですが、残っていたのは記事のHTMLだけで、画像は見つかりませんでした。
このファイル名、よく見ると「年月日時分秒_管理番号」になっていそうです。写真ライブラリで試しに見てみると、撮影日が一致して、時刻も少しずれているくらいの写真が見つかりました。そこで、ファイル名から日時を読み取り、同じ日に撮影された写真を時刻の近い順に候補として出してもらうことにしました。
不明な画像77枚に対して、出てきた候補は108枚。候補の写真を書き出してもらい、記事の内容と見比べながら自分で選んでいきました。結果、40記事は写真を特定できて修正完了。一方で17記事は、候補の中に該当する写真がありませんでした。
直ったのはいいんですが、これが結構大変で……。候補を開いては記事と見比べ、似たような料理写真やプラモデルの途中経過写真が並んでいると、どれだったか悩む。しかも写真アプリからの書き出しが途中で止まって、写真アプリを再起動してやり直したりもしました。候補を出すところまではAIが速いんですが、最後の目視確認がボトルネックで、やり方を見直す必要があると感じています。
やってみて
パスのずれで切れていたリンクは、AIエージェントに調べてもらうとあっという間に見つかり、修正まで一気に片付きました。手作業でソースを眺めていた頃とは比べ物になりません。
一方、画像そのものを探す作業になると、まだ人間の出番が多いです。ファイル名で見つかればいいんですが、名前が変わってしまった画像は、候補を出してもらっても最後は目で確認するしかありません。
それに、この作業はまだ2011年の記事までしか終わっていません。2012年以降は今のWordPressの構成にだいぶ近づいているはずなので、作業が減ってくれることを期待しています。
次は自分史？
今回の作業で、AIエージェントに過去の記事をひととおりチェックしてもらえることが分かりました。だったら、ブログの記事から自分史みたいなものを作れないか、検討してみたいと思っています。
たとえば、スマホやデジカメの乗り換えの歴史。今回の作業でも、画像のファイル名を見るだけで、時期ごとに使っていたカメラが違うのが分かりました。DVCで始まる携帯の写真、DSCNのデジカメ、R00で始まる写真、そしてiPhoneのIMG。写真のデータには撮影した機種名も残っていて、2006年頃の写真はドコモのSH902iで撮ったものでした。2005年の末には「SH902iに機種変更」という記事も書いています。
記事と写真のデータを突き合わせれば、何年に何を使っていたか、けっこう正確にたどれそうです。20年分の記事があるので、ネタには困らないはず。
注記：この記事は、生成 AI (Hermes Agent) を使って執筆しています。作業の記録や検証結果は筆者自身の環境でのものですが、文章の構成・執筆に生成 AI の支援を受けています。内容には注意を払っていますが、誤りがあればご指摘ください。