サイトの画像がある日まとめて表示されなくなる原因｜外部サービスの直リンクを自社ホストへ移す判断と一括修正の手順

サイトを何も更新していないのに、ある日を境に写真が何枚も表示されなくなった。画像の枠だけ残って中身が空白、あるいは壊れた画像のアイコンが出る。サーバー会社に問い合わせても「障害は起きていない」と言われる。こうした相談を受けることがあります。

「複数の画像が同時に」「更新していないのに」という条件がそろう場合、原因はほぼ決まっています。画像のURLが自社サーバーではなく外部サービスのサーバーを指しており、そのサービス側で配信が止まったためです。制作ツールが自動で用意する配信サーバー、画像共有サービスへの直リンク、過去に使っていた別サービスの残骸。いずれも自社サーバーは正常なので、サーバー側をいくら調べても原因は見つかりません。

結論から書きます。対処は次の4段階です。

1. 表示されない画像のURLを実際に確認し、ホスト名が自社ドメインかどうかで切り分ける
2. 外部だった場合は、原本をアーカイブ、ローカル、サーバー、ブラウザキャッシュの順で回収する
3. 回収した画像を自社サーバーに置き、参照先をテンプレート側で書き換えて全ページを一括で更新する
4. 更新後のHTMLに外部ホスト名が残っていないことを機械的に確認する

この記事では、弊社graciautoが運営を支援している名古屋の美容サロンFC（25店舗）の店舗サイト群で、共通テンプレートが外部配信サーバーへ直リンクしていた画像14本が全店舗で同時に表示されなくなった実例をもとに、切り分けの手順、原本回収の順番、自社ホストへ移す一括修正の手順、外部に置いてよい画像と置いてはいけない画像の線引きをまとめます。

まず切り分ける｜「一部だけ」「全部」「複数サイトで同時」で原因が違う

画像が表示されない原因は複数あり、症状の出方で見る場所が変わります。最初に、消えた画像のURLをブラウザで直接開いてください。表示されない画像を右クリックして「新しいタブで画像を開く」とすれば、URLと、その先で何が返っているかが分かります。

症状	疑う原因	見る場所
特定のページの画像1〜2枚だけ消えた	ファイルの削除・改名、権限の変更	自社サーバーのファイルと権限
公開作業や移転の直後に画像だけ全部403	公開先のパーミッション設定	サーバーのディレクトリ権限
一部の人だけ古い画像が見える	ブラウザやCDNのキャッシュ	キャッシュの有効期限とファイル名
更新していないのに複数の画像が同時に消えた。同じ作りの別サイトでも同時に消えた	画像URLが外部サービスを指しており、そちらの配信が止まった	画像URLのホスト名

自社サーバー内での権限トラブルは画像だけ表示されないときは403を疑う、一部の人だけ古いままの現象はサイトを更新したのに一部の人だけ古いまま見える原因で扱っています。この記事は4行目、外部サービス側で配信が止まった場合の話です。

見分け方は単純で、画像URLのホスト名が自社ドメインかどうかです。自社サイトが example.jp なのに、画像のURLが xxxx.cloudfront.net や制作ツールの名前を含むドメイン、画像共有サービスのドメインになっていれば、その画像は自社のものではなく借り物です。ブラウザで開いたときに403（アクセス拒否）や404（存在しない）が返り、しかもそのドメインの画像が全部同じ状態なら、サービス側で配信が止まったと判断できます。

外部直リンクが失効するとどうなるか｜25店舗で14本が同時に消えた実例

実例で、何がどう壊れるかを具体的に書きます。

対象は、名古屋の美容サロンFCの店舗サイト群です。25店舗分のサイトが1つの共通テンプレートから生成されており、店舗ごとの写真や住所は個別に持ちますが、ブランド共通の画像はテンプレート側に組み込まれています。このテンプレートは制作の初期段階でAI制作ツールを使って組んだもので、ツール側が自動で用意した配信サーバーに置かれた画像を、テンプレートがそのままURLで参照している状態でした。

ある日、そのドメインの全URLが403を返すようになりました。影響を受けた共通画像は14本です。

画像の種類	本数	使われていた場所
施術前後の比較写真	10枚	ギャラリー（5ペア）
使用しているカラー剤の紹介写真	1枚	トップ・メニュー・店舗紹介の3か所
特徴セクションの写真	1枚	トップ
髪色変化のアニメーション用	2枚	部品として実装

テンプレートに組み込まれていたので、25店舗すべての本番サイトで同じ14本が同時に壊れました。店舗側からの報告ではなく、新店舗のサイトを作る検証中に見つかったものです。共通テンプレートの外部依存は、こういう形で一斉に表面化します。

ここで押さえておきたいのは、自社サーバーは何も変わっていないという点です。サーバー会社の障害情報を見ても、サーバー内のファイルを確認しても、異常は見つかりません。切り分けを先にやらないと、ここで時間を使うことになります。

原本を回収する｜アーカイブ、ローカル、サーバー、ブラウザキャッシュの順

外部の配信が止まった画像を自社に移すには、まず原本が要ります。回収先は、確実性の高い順に4つあります。

1. 自社の保管場所。制作時に受け取った素材フォルダ、撮影データ、クライアントから届いたファイル
2. サーバー上の別の場所。旧サイトのアップロードフォルダ、バックアップ、旧CMSのメディアライブラリ
3. Webアーカイブ。Wayback Machineなどに対象ドメインの記録があれば取得できる
4. ブラウザのキャッシュ。最近そのサイトを閲覧した端末に、画像ファイルが残っていることがある

実例では、1〜3がすべて空振りでした。ローカル全域の検索でも、圧縮ファイルの中身まで含めて原本はなく、サーバー全域にもなく、Webアーカイブには対象ドメインの記録が0件でした。制作ツール側の配信サーバーはアーカイブの巡回対象に入っていないことがあり、ここに期待しすぎない方がよいです。

決め手になったのは4のブラウザキャッシュでした。普段そのサイトを確認している別の端末に、URL一致で画像ファイルが残っており、14本中7本を原寸のまま回収できました。ただし、これは最後の手段です。閲覧していなければ残っていませんし、キャッシュは容量上限で古いものから消えていきます。原本を自社で保管しておく運用の方が、ずっと確実です。

回収できなかった画像の扱い｜3つの判断基準

回収できなかった7本は、画像ごとに使われ方を確認して、次の3通りに分けました。

状況	判断	実例
コード上に残っているが、どのページからも使われていない	実害ゼロ。何もしない	アニメーション用の2枚は未使用の部品だった
複数枚で構成する要素の一部が欠けた	回収できた分で構成を縮小し、復元手順をコードにコメントで残す	比較写真5ペアのうち2ペアが揃ったのでギャラリーを2ペア構成へ
単独で使われており、代替がないと枠が空く	既存のブランド画像で代替し、原本が入手できたら差し替える	カラー剤の写真3か所を共通のブランド写真へ

「壊れたまま」「枠を消す」以外に、「縮小して復元手順を残す」「代替して差し替え前提にする」という選択肢を持っておくと、原本待ちの間もサイトを正常な状態に戻せます。

自社ホストへ移して一括修正する手順

原本が揃ったら、外部URLへの参照を自社配信へ切り替えます。ページを1枚ずつ直すのではなく、テンプレート側で直して全サイトを再生成するのが正しい進め方です。25店舗のサイトを個別に修正すると、直し忘れが必ず出ます。

実例で行った手順は次のとおりです。

1. 回収した画像をWebP形式に最適化し、テンプレートの素材フォルダに置く
2. 各ページの画像参照を、外部URLの文字列からテンプレート内の素材ファイルへの参照に書き換える。ビルドツールを使っている場合は、素材をimportで読み込む形にすると、ビルド時にハッシュ付きのファイル名で自社の配信フォルダに束ねられる
3. 全店舗分をビルドし直す。実例では26店舗（作業中に新店舗が1つ増えていました）を順番に処理し、26件すべて成功、失敗0件
4. 生成されたファイルのうち必要なものだけを各店舗のサーバーへ転送する。検索エンジン向けに生成してある静的ページがあれば、それも再生成する
5. 転送後、サンプルの店舗を実際にブラウザで描画して検証する

検証で確認する項目は3つです。

• 壊れた画像が0件であること
• HTML内に外部配信ドメインの文字列が0件であること
• ページのtitleなど、画像以外の要素が変わっていないこと

実例では5店舗をサンプルに実描画し、壊れた画像0・外部ドメイン参照0・titleの維持を確認しています。「画像だけ直したつもりで、再ビルドの過程で他の要素を巻き込んでいた」という事態は、この3点目で拾えます。

自社サイトの28枚を移した例｜圧縮と参照の一括置換

同じ作業は、弊社graciautoのサイトでも行っています。こちらは失効する前に移したケースです。

サイト構築の初期にAI制作ツールを使っていた経緯があり、ヒーロー画像・ロゴ2種・会社紹介・エリアページ4本・LP4本・スタッフ17枚の計28枚が、ツール側の配信サーバーを指していました。これを全部ダウンロードして自社の配信フォルダに置き、ソース内の参照を一括で自社パスに置換しました。

このとき気をつけた点が3つあります。

• ダウンロードした28枚（合計47MB）が本当に画像ファイルかを、拡張子ではなくファイルの中身で検証した。配信サーバーがエラーページを返していると、拡張子は画像でも中身はHTMLということが起こる
• 原本のファイル名を変えなかった。旧URLとの対応が追えるので、置換漏れの確認が楽になる
• 構造化データに書かれたロゴのURLも、相対パスではなく自社ドメインの絶対URLにそろえた。HTMLのimgタグだけ直すと、検索エンジン向けの記述に外部URLが残る

あわせて画像の圧縮も行い、サイト全体の画像容量は45MBから10MBになりました。ヒーロー画像1枚は5.1MBから184KBです。自社ホストへ移す作業は、外部依存を切るだけでなく、画像の重さを見直す機会にもなります。

外部に置いてよい画像と、置いてはいけない画像の線引き

「外部の画像URLは全部だめ」ではありません。判断基準は、その配信元の存続と設定を自社で管理できるかです。

配信元	判断	理由
制作ツールが自動で用意した配信サーバー	移す	ツールの契約やプロジェクトの状態次第で止まる。納品先の管理下にない
画像共有サービス・チャットツールの直リンク	移す	直リンクを想定しておらず、URLの有効期限や規約変更で止まる
旧サイトや別サービスのドメイン	移す	解約や移転のタイミングで消える。移行の積み残しになりやすい
自社のCMS用サブドメイン	状況次第	配信は止まらないが、検索エンジンから遮断していると画像検索やシェア画像に載らない
自社で契約しているCDN	置いてよい	自社の契約と設定で管理できる。契約の更新担当を決めておく

4行目は、失効とは別の落とし穴です。配信は続いているのに、robots.txtで遮断したCMS側のドメインを画像が指していると、検索結果のサムネイルや共有カードに画像が出ません。この確認手順はSNSでシェアしても画像が出ないときの確認順にまとめています。

共通テンプレートで複数サイトを生成する構成では、テンプレート内の外部URLをすべて洗い出してから量産に入るのが正しい順番です。1サイトなら1か所の修正で済むものが、25サイトに広がると25か所の修正と検証になります。

起こりうる失敗と予防

この種の作業で起こりうる失敗を、予防策とあわせて整理します。

起こりうる失敗	予防策
納品後しばらくしてから外部配信が止まり、クライアントから「画像が消えた」と連絡が来る	納品前の検収でHTMLを自社ドメイン以外のホスト名で検索し、外部参照を0件にしてから納品する
原本がどこにも残っておらず、Webアーカイブにも記録がない	制作時の素材は自社の保管場所に原本のまま残す。配信サーバーにしか無い状態を作らない
ブラウザキャッシュからの回収に頼ることになり、揃わない	キャッシュは最後の手段。上の2行を守っていれば使わずに済む
1サイトだけ直して、同じテンプレートの他のサイトを直し忘れる	個別修正ではなくテンプレート側で直し、全サイトを再生成して一括転送する
imgタグは直したが、OGP画像や構造化データの中に外部URLが残る	HTML全体を外部ホスト名の文字列で検索する。imgタグだけ見ない
再ビルドと一括転送で、検索エンジン向けに生成してあった静的ページや設定ファイルを消してしまう	転送は必要なファイルだけに限定する。転送後に静的ページを再生成する
ダウンロードしたファイルが実は画像ではなくエラーページだった	拡張子ではなくファイルの中身で画像かどうかを検証してから配置する

上の表で最も効くのは1行目です。納品前に外部参照を0件にするという検収項目を1つ足すだけで、残りの行はほぼ起きなくなります。

よくある質問

Q. サーバー会社に問い合わせたら「障害はない」と言われました。どこに聞けばいいですか

自社サーバーに障害がないのは正しい回答です。画像URLのホスト名を確認して、外部サービスのものであれば、問い合わせ先はそのサービスか、サイトを作った制作会社になります。問い合わせと並行して、原本の回収を始めてください。外部サービス側の復旧を待つより、自社ホストへ移す方が早く、再発もしません。

Q. 表示されている画像を右クリックで保存して、それを原本にしてはだめですか

まだ表示されている画像があるなら、すぐに保存してください。それが原本の代わりになります。配信が止まった後に気づくと保存はできず、回収に手間がかかります。外部URLの画像を見つけた時点で、止まる前に手元へ落としておくのが最も安い対処です。

Q. 制作会社に納品してもらったサイトです。外部依存があるかを自分で確認できますか

できます。サイトの任意のページをブラウザで開き、ページのソースを表示して、自社ドメイン以外のホスト名を検索してください。画像のURLに自社ドメイン以外のものが並んでいれば、その配信元が止まると画像が消えます。分析タグやフォント配信など、外部で問題ないものもあるので、画像ファイル（.jpg .png .webp）のURLに絞って見ると判断しやすいです。

まとめ

• 更新していないのに複数の画像が同時に消えた場合、画像URLが外部サービスを指していて、そちらの配信が止まった可能性が高い。自社サーバーは正常なので、サーバー側を調べても見つからない
• 切り分けは画像URLのホスト名で行う。自社ドメイン以外で、そのドメインの画像が全部同じ状態なら外部側の失効
• 原本は自社の保管場所、サーバー上の別の場所、Webアーカイブ、ブラウザキャッシュの順で探す。実例では最後のブラウザキャッシュで14本中7本を回収した
• 回収できない画像は「未使用なら放置」「構成を縮小して復元手順を残す」「代替して差し替え前提にする」の3通りで処理し、サイトを正常な状態に戻す
• 修正はページ単位ではなくテンプレート側で行い、全サイトを再生成して一括転送する。実例では26サイトを26件すべて成功で更新した
• 検証は、壊れた画像0件・HTML内の外部ホスト名0件・画像以外の要素の維持の3点
• 納品前の検収に「外部参照を0件にする」を1項目足すと、この問題はほぼ起きなくなる

複数店舗のサイトで画像がまとめて消えた、納品されたサイトに外部依存が残っていないか確認したい、という方は、お問い合わせからご相談ください。現在のHTMLから外部ホストへの参照を一覧にして、移すべきものと残してよいものを分けるところから対応します。