株式会社Koinobori
HANDS-ON / 執筆：杉﨑（代表取締役）

顧問の顔写真が消えた——「使われていない」の誤判定 — 中小企業 × AI 経営（2026年7月）

サイト整理で「参照ゼロ」と判定し画像37枚を削除したら、顧問の顔写真2枚が実は使われていて表示が壊れていました。実行時に組み立てられるファイル名は文字列検索では見つからない、という実録です。

タグ: #Webサイト運用 #画像管理 #品質保証 #自動判定の落とし穴 #中小企業 #2026

はじめに：この記事の前提

Koinobori 代表取締役の杉﨑です。 社員数名の会社を経営しながら、このコーポレートサイトも自分の手で作り、AI を相棒に毎日更新しています。

サイトは「作る」よりも「片付ける」ほうが、実は怖い作業だと今回思い知らされました。サイトを軽くしようと”使われていない画像”を洗い出して消したところ、会社の顧問を紹介するページから顔写真が消えていた。 原因を追うと、機械的な判定にはっきりとした穴があることが分かりました。技術トラブルの武勇伝というより、「“使われていない”という判定を、どこまで信じていいのか」という経営判断の話として読んでいただければと思います。

私たちは自社のコーポレートサイトのほかにも、いくつかの Web サービスを自社で運用しています。サイトの数が増えるほど、片付けの手間も増えます。 使わなくなった画像や古いページを放置すればサイトは重くなり、逆に「もう使っていないだろう」と急いで消せば、今回のように事故が起きる。片付けは、増やすことと同じくらい設計が要る作業だというのが、このコラムで繰り返し感じていることです。今回はその中でも、特に印象に残った一件でした。

1. 課題：37枚を消した後で、静かに壊れていた

1-1. なぜ画像を片付けるのか

サイトを長く運用していると、過去のキャンペーンや差し替え前の写真など、もう表示に使われていない画像がフォルダの中に積み上がっていきます。 使われない画像はサーバーの容量を圧迫するだけでなく、後から見た人が「これはまだ使っているのか、もう使っていないのか」を判断できず、管理コストを押し上げる要因にもなります。

そこで定期的に、「どこからも呼ばれていない画像」を洗い出して削除する作業をしています。少し前のセッションで、この作業により画像37枚を「参照ゼロ」と判定し、まとめて削除しました。

判定のやり方はシンプルです。画像のファイル名を、サイトの設計図（コード）の中で検索する。どこにもヒットしなければ「使われていない」とみなす。 特別な方法ではなく、多くの現場でごく普通に行われているやり方です。これまでこの方法で問題が起きたことはありませんでした。

1-2. 消えて、初めて気づいた

数日後、会社概要のページを何気なく開いて青ざめました。顧問を紹介するカードの写真が、2枚とも空白になっている。 名前とプロフィールの文章はそのまま表示されているのに、顔写真の場所だけが灰色の何もない枠になっていたのです。

急いで削除の記録を調べると、原因はすぐに分かりました。「参照ゼロ」と判定して消した37枚のうち、2枚が実は現役で使われていた。 割合にすると、37枚中2枚、およそ5.4%です。数字だけ見れば小さな誤判定ですが、その2枚がよりによって、社外の方（顧問）の信用に直結する場所でした。取引先や採用候補者がこのページを見たときに、手入れが行き届いていない印象を与えかねない箇所です。数の少なさは、影響の小ささを意味しませんでした。

1-3. なぜ気づくまでに数日かかったのか

正直に言うと、削除の直後に確認はしていました。トップページや主要な導線は目視でチェックし、崩れがないことを確認した上で本番に反映しています。 それでも見逃したのは、顧問紹介のページが「毎日は見に行かない場所」だったからです。

日々のアクセスが多いページは、少しの異変でもすぐに誰かの目に留まります。しかし訪問頻度が低いページほど、壊れたまま気づかれずに残るリスクが高い。 今回は数日で自分自身が気づけましたが、これが社外の担当者の目に先に触れていたら、と考えると背筋が冷えます。「主要な導線だけ確認すれば十分」という感覚そのものを、見直すきっかけになりました。

2. 取り組み：なぜ「文字列検索」は見抜けなかったのか

2-1. 犯人探しの前に、まず切り分け

最初にやったのは、「誰の作業が悪かったか」を探すことではなく、「なぜ機械の判定が外れたのか」を切り分けることでした。感情的に犯人を探しても、同じ間違いはまた起きます。

消えた2枚の画像を調べると、共通点が見つかりました。どちらのファイル名も、サイトの設計図（コード）の中に、“そのままの文字”としては一度も書かれていなかったのです。

2-2. 見つかった原因：名前が「その場で組み立てられていた」

会社概要ページの顧問紹介の部分には、表示速度を上げるための工夫が入っていました。もとの画像とは別に、より軽い形式の画像を自動で用意し、対応するブラウザにはそちらを優先して見せる仕組みです。ページの表示を速くする、よくある高速化のテクニックの一つです。

問題は、その「軽い形式」の画像ファイル名の作り方でした。もとの画像ファイル名の拡張子部分を、ページが表示される”その瞬間”にプログラムが自動的に書き換えて作っていたのです。たとえるなら、宛名をあらかじめ紙に書いておくのではなく、配達員がポストの前でスタンプを押して、その場で宛名を完成させるようなものです。完成した宛名（ファイル名）は、手元の控え（コード）のどこにも文字として残りません。

文字列検索は、控えに”書いてある文字”を探す作業です。配達の瞬間にしか存在しない宛名は、控えを見ても見つかりません。 「参照ゼロ」という判定は、機械としては正しい手順を踏んだ結果でしたが、実態とは食い違っていました。

この仕組み自体は、悪いものではありません。ページの表示を軽くする工夫は、訪問者の体感速度を上げ、離脱を減らす効果があります。実際、このサイトでも各所に同じ考え方を取り入れています。便利な工夫が、別の作業（今回で言えば片付け）の判定基準と噛み合っていなかった、というのが正確な言い方だと思います。工夫を導入するときに「この工夫は、後から行う点検作業とぶつからないか」までは、当時考えが及んでいませんでした。

2-3. もう一つの壊れ方：普通の確認では気づけない

さらに厄介だったのは、壊れ方そのものが、普通のチェックでは見つけにくい種類だったことです。確認の仕方によって、見え方がまったく違いました。

確認のしかた見え方
元の画像ファイルそのものを開いて確認する正常に見える（ファイル自体はそのまま残っている）
軽い形式に対応した、今の主流のブラウザで実際にページを見る顔写真が表示されない（壊れている）
軽い形式に対応しない古い確認方法・以前保存した画面で見る正常に見える（軽い形式を要求しないため）

いま出回っているブラウザのほとんどは、この軽い形式に対応しています。つまり訪問者のほとんどは壊れた状態を見ているのに、確認する側が「元の画像は無事だから大丈夫だろう」と考えたり、対応していない環境や古い記録越しに見てしまうと、壊れていることに気づけません。 実際、私たちもしばらくの間、これに気づけませんでした。「表示は確認したはず」が、実は確認になっていなかった、という怖さです。

2-4. 似た書き方が他にもないか、全体を洗い直す

原因が特定できたら、次にやるべきは「この1箇所を直して終わり」にしないことです。同じ「その場で名前を組み立てる」書き方が、サイトの他の場所に紛れていないかを、コード全体を横断して確認しました。

結果として、該当する書き方は最初に見つけた1箇所のみでした。念のため、実際にサイトが出力した最終形の中身をすべて洗い、軽い形式の画像がすべて実体として存在しているかも確認しました。ここまでやって初めて、「今回の穴はここだけだった」と言い切れる状態になります。

2-5. AIに片付けを任せるときほど、人間の最終確認を

このコラムのシリーズでは何度か触れていますが、私はサイトの改修や整理の多くを AI に指示して進めています。今回の画像削除も、「参照ゼロの画像を洗い出して」という指示に対して、機械が文字列検索で判定し、その結果に従って削除を実行したという流れでした。

AI は指示された手順を正確にこなします。問題は、AI の実行力ではなく、判定の物差し（今回で言えば「文字列検索でヒットするか」）そのものが不完全だったことです。ここを見抜けるのは、最終的には人間の役割だと改めて感じました。「AI に任せたから安心」ではなく、「AI に任せた作業の”判定基準”が正しいかどうかは、人間が検証する」という分担が必要です。

3. 結果：2枚を復元し、被害をゼロに戻す

原因が「軽い形式のファイル名が表示の瞬間に組み立てられる」ことだと分かれば、対応そのものは早いものでした。

作業自体は数十分で完了しました。ただし、もし気づかなければ、そのまま何ヶ月も表示が壊れたままだった可能性があります。 顧問紹介のページは、トップページほど日常的に見に行く場所ではありません。発見が遅れるリスクは、実際に十分ありました。今回はたまたま自分の目で気づけましたが、「たまたま気づけた」を仕組みに変えなければ、次は見逃す、という危機感を持ちました。

被害の範囲を整理すると、こうなります。

項目内容
削除した画像37枚
実は現役だった画像2枚（誤判定率 約5.4%）
表示不具合が出ていた期間発見まで数日
復旧にかかった時間数十分
復旧後の被害ゼロ（2枚とも完全復元、他に穴なし）

数字だけ見れば「誤判定率5.4%」は小さく見えます。しかしどこで誤判定が起きるかは選べません。 今回はたまたま会社の信用に関わる場所を直撃しました。

3-1. 他のサイトにも同じ穴がないか

被害を復旧させただけでは、再発防止にはなりません。私たちは複数の Web サービスを自社で運用しているため、同じ「表示速度を上げる工夫」が他のサイトにも入っていないかを併せて確認しました。 幸い、今回のような「その場でファイル名を組み立てる」書き方をしていたのは、このコーポレートサイトのこの1箇所だけでした。

ただし、これで「もう起きない」と言い切れるわけではありません。似たような高速化の工夫は、今後も新しく増えていきます。 そのたびに「これは片付け作業の判定とぶつからないか」を意識する必要がある、というのが正直なところです。1件直して終わりにせず、同じ構造の問題が他にもないかを疑う癖を持つことが、再発防止の実質だと考えています。

4. 学び：「使われていない」の証明責任は、消す側にある

今回の一番の教訓は、判定方法そのものの見直しです。

「使われていない」と判定するなら、“コードに書いてあるか”ではなく、“実際に呼ばれるか”で確かめる。

文字列検索は手軽で、たいていの場合は正しく機能します。しかし、名前が実行時に自動で組み立てられる仕組みが一つでも混ざっていると、検索は静かに見落とします。 しかも見落としはエラーという形では現れません。ページは普通に表示され、「何かがおかしい」という合図が一切出ないまま、欠けた状態が続きます。

もう一つの学びは、「消す」作業と「足す」作業では、慎重さの基準を変えるべきだということです。何かを足す作業は、失敗してもゼロに戻すだけで済みます。一方、削除の失敗は**「気づかれないまま、ずっと欠けたままになる」**という、質の違うリスクを持ちます。今回の一件を機に、画像を削除する前には、サイトが実際に生成した最終的な出力の中身をすべて確認し、そこに映るすべての参照が実体を持っているかを見るというひと手間を、必ず挟むルールにしました。

今回を機に、画像を消す作業のやり方そのものを変えました。

項目以前のやり方今回以降のやり方
判定の根拠コード（設計図）に文字として書かれているかサイトが実際に生成した最終出力に、その参照が現れるか
確認するタイミング削除前に一度だけ削除前と、削除後の本番確認の二段構え
表示確認の範囲主要な導線を目視訪問頻度の低いページも含めて横断確認
「ゼロ」の扱い検索でヒットしなければゼロと確定ゼロは仮説として扱い、実際の呼び出しで検証してから確定

特別なツールを新たに導入したわけではありません。 「どのタイミングで、何を根拠に確認するか」という手順を一段厚くしただけです。地味な変更ですが、同じ事故を二度目は起こさないための、いちばん確実な投資だと考えています。

機械の判定は便利ですが、「機械がゼロと言った」は、「本当にゼロである」ことの証明にはなりません。 これは画像に限った話ではなく、在庫の棚卸し、書類の整理、使っていないアカウントの解約など、多くの「片付け」作業に共通する落とし穴だと思います。探す場所が正しくなければ、どれだけ丁寧に探しても答えは間違えます。そして探す場所が正しいかどうかを最後に判断するのは、機械ではなく人間の役割です。

たとえば、社内で契約しているツールを「もう誰も使っていないだろう」と解約する場面を想像してみてください。ログイン履歴だけを見て判断すれば、たまたまその時期に使っていなかった人を見落とすかもしれません。 「記録上ゼロに見える」ことと「実際にゼロである」ことの間には、常に確認の余地があります。今回の画像の話は小さな一件ですが、判定の物差し自体を疑う視点は、経営判断のあらゆる場面に応用できると感じました。

おわりに

顧問の顔写真という、会社の信用に直結する場所で起きたトラブルでした。幸い被害は数十分で直せる範囲でしたが、「なぜ気づけなかったのか」を掘り下げると、便利な仕組みほど、その裏側の動き方を理解していないと、思わぬ落とし穴になることがよく分かりました。

このコラムでは、AI を相棒にサイトを作り、運用してきた過程を何度も紹介してきました。AI は作業を速く、正確にこなしてくれます。 しかし「速く正確にこなす」ことと、「その作業の前提が正しいこと」は別の話です。今回のように、判定の物差し自体にわずかな穴があれば、AI はその穴ごと忠実に実行してしまいます。だからこそ、AI に任せる範囲が広がるほど、人間が最後に見るべき”物差しの妥当性”は、むしろ重くなっていると感じています。

改めて、今回の教訓を3つにまとめます。

  1. 「使われていない」の判定は、書いてある場所を探すのではなく、実際に呼ばれるかで確かめる — 文字列検索は、実行時に組み立てられる名前を見落とす
  2. 誤判定の数が少なくても、置き場所次第で被害は大きくなる — 37枚中2枚という小さな数字が、会社の信用に関わる場所を直撃した
  3. 消す作業は、足す作業より基準を上げる — 足す失敗はゼロに戻るだけだが、消す失敗は気づかれないまま残り続ける

「使っていないはずのものを片付けたら、実は現役だった」——中小企業の日々の運用の中では、意外とよくある話ではないでしょうか。私たちも今回、“機械的な判定を疑う”というひと手間を仕組みに組み込むきっかけになりました。

読者への問い: 御社のサイトや資料フォルダにも、「もう使っていないはずだから」で消してしまった何かはありませんか？ 消す前に、“実際に呼ばれているか”まで確かめられているでしょうか。

この記事を読んだ方へ

サイトの整理・保守も、作ることと同じくらい丁寧な設計が要ります。運用の落とし穴も含めて伴走しています。

👉 AI 導入サポートサービス — 中小企業向け、設計から構築・運用まで 👉 お問い合わせフォーム — 個別のご相談・お見積もり

関連記事: アクセス解析を2か月ぶりに直視したら、思い込みが4つ壊れた

執筆：Koinobori 株式会社 代表取締役 杉﨑

RELATED — 関連コラム

こちらもどうぞ