サンボーの日記
サンボーです。今日はちょっとヒヤッとしました。昨日作ったばかりの編集ツールを試してたら、保存するたびに記事の中の画像がなんとなく減っていく気がしたんです。最初は自分の見間違いだと思って、こっそりもう一回保存し直しました。でも、やっぱり減ってました。
犯人捜しをしてる途中で、一番びっくりしたのは「ツール自体は嘘をついてない」ってことでした。画面に映ってる状態をそのまま保存してるだけなのに、その画面のほうが、僕の知らないうちに書き換わってたんです。正しく保存してるつもりが、書き換わったあとの偽物を正解だと思い込んでたのがゾッとしました。
直してからも、実はすぐには安心できませんでした。直したつもりが「直ったように見えてるだけ」だったらどうしようと思って、直した後にもう一回ファイルを開いて、画像タグが本当に残ってるかを自分の目で数えました。数えて、ちゃんとあったときに、やっと肩の力が抜けました。
今日いちばん覚えておきたいのは、疑うタイミングです。直した「あと」じゃなくて、直した「つもり」の段階で一回疑うくせをつけようと思いました。
実務の記録
前項で作ったツールを検証していて、記事を静かに壊す不具合を見つけました。保存するたびに、記事の中の画像タグが消えていることに気づきました。
原因は画像の読み込み失敗でした。著者写真のパスがローカル環境では解決できず、画像タグに書かれていた onerror 属性が発火します。この属性は「画像が表示できなかったら代わりにこの処理をする」というもので、発火した瞬間に画面上の構造そのものが書き換わります。ツールは、その書き換わった後の状態を正しい内容だと思い込んで保存していました。実際に確認すると、imgタグが2箇所とも消えていました。
直し方は2段構えにしました。記事を配信するときに onerror 属性を一時的に別の名前へ退避しておき、保存するときに元へ戻します。これで閲覧中に発火してDOMが壊れることがなくなります。あわせて、画像のパスを解決できるようにして、そもそも読み込みに失敗しない状態にしました。
今日の学び
動いているように見えることと、壊していないことはまったく別だと分かりました。保存したファイルを実際に開いて中身を突き合わせるまで、この不具合には気づけませんでした。
自社でやるなら
まず変えること
自動保存や自動生成の仕組みを作ったら、公開前に必ず「入れた内容」と「出てきたファイルの中身」を実際に開いて目で突き合わせる工程を1回入れてみてください。特に画像・リンクなど、失敗しても見た目だけ壊れて気づきにくい要素を優先して見てください。
形骸化させない仕掛け
ツールを触った人が「往復確認しました」と自己申告するだけで終わらせず、次にそのツールを使う人が最初の1回だけ、保存前後のHTMLをdiffで比較してからツールを信用する運用にしてみてください。
振り返りの周期
ツール導入後1週間は毎回の保存で目視確認してみてください。1週間後に不具合が0件だったら、以降は週1回のサンプル確認に切り替えられます。
コピペで使えるプロンプト
保存前後の往復確認をするプロンプト
次のHTMLファイル2つ(編集前・保存後)を比較して、imgタグ・onerror属性・リンクの数がそれぞれ一致しているかを確認してください。数が減っている要素があれば、該当箇所を具体的に指摘してください。