画像だけ表示されないときは403を疑う｜404との違いと、公開作業で権限が変わる仕組み
画像だけ表示されないときは403を疑う｜404との違いと、公開作業で権限が変わる仕組み
「サイト自体は普通に見られるのに、一部の画像だけ表示されない」。ホームページの運用をしていると、いつかは出会うトラブルです。文字は出ている、レイアウトも崩れていない、でもトップの写真だけが壊れたアイコンになっている——この状態になったとき、多くの人はキャッシュを消したり、画像をアップし直したり、ファイル名を確認したりと、思いつく順に手を打ってしまいます。
結論から書きます。最初にやることはひとつだけです。ブラウザの開発者ツールで、その画像のステータスコードが「404」なのか「403」なのかを確認する。この2つは見た目こそ同じ「画像が出ない」ですが、原因がまったく違います。ここを確認せずに作業を始めると、原因と関係のない場所を延々と直し続けることになります。
404と403は「別の病気」
- 404 Not Found ＝ そのURLにファイルが存在しない。パスの書き間違い、アップロード漏れ、ファイル名の大文字小文字違いなど、「置き場所」の問題です
- 403 Forbidden ＝ ファイルは存在するが、Webサーバーに読む権限がない。「置き場所」は合っていて、「読ませ方」の問題です
404なら、直すのはHTML側のパスか、アップロード作業のやり直しです。一方403なら、ファイルはもうサーバーにあるので、何度アップし直しても、キャッシュを何回消しても直りません。403で疑うべきはファイルのパーミッション（権限設定）です。
確認の方法は簡単です。Chromeなら画像の出ないページで右クリック→「検証」→「Network」タブを開いてページを再読み込みし、赤くなっている行のStatus列を見るだけ。あるいは画像のURLを直接ブラウザのアドレスバーに貼って開いても、403ならその旨のエラー画面が出ます。
403を見つけたら：同じフォルダ内の「混在」を確認する
403だと分かったら、次に見るのは「同じフォルダにある他の画像は表示されているか」です。
同じディレクトリの中で、表示される画像と403の画像が混在している場合、フォルダ単位のアクセス制限（.htaccessなど)ではなく、ファイル1枚ごとのパーミッションの問題だと絞り込めます。サーバーにSSHやFTPで入って確認すると、こういう状態になっています。
-rw------- photo_a.png ← 600：所有者しか読めない → 403
-rw-r--r-- photo_b.png ← 644：誰でも読める → 200（正常表示）Webサーバー（nginxやApache）は多くの場合、ファイルの所有者とは別のユーザーとして動いています。パーミッションが600（所有者のみ読み書き可）だと、Webサーバーはそのファイルを読めず、閲覧者には403が返ります。644（所有者は読み書き、他は読み取りのみ)になっていれば正常に配信されます。
なぜ「公開作業」で権限が変わるのか
ここが本題です。画像のパーミッションは、手元のパソコンでファイルを作った瞬間に決まり、公開までの経路によっては、その権限がそのまま本番サーバーまで運ばれます。
Macなどで新規に作成・書き出したファイルは、作られ方によってパーミッションが600になっていることがあります。手元で見る分には何の問題もないので、この時点では誰も気づきません。問題は転送方法です。
- FTPでアップロードする場合：サーバー側の設定（umask）が効いて、着地時に644へ整えられるのが一般的です。手元が600でも、本番では正常に表示されます
- rsyncの標準的な使い方（
rsync -a）で転送する場合：-a（アーカイブモード）はパーミッションを保持したまま運ぶのが仕様です。手元で600だったファイルは、本番でも600のまま着地し、403になります
つまり、FTP運用のあいだは一度も起きなかった事故が、rsyncを使った自動デプロイに切り替えた瞬間から発生するようになるわけです。しかも切り替え直後は「移行が成功したか」に注意が向いているので、一部の画像だけが403になっていることは見落とされがちです。
実際に弊社が制作を担当した名古屋の医療系サイトでも、この構造のリスクが現実になったことがあります。ヘッドレス構成への切り替えに伴い、FTPからサーバー内rsyncのデプロイへ移行したところ、素材取り込み時点で600だったファイル46件が、そのままの権限で本番に着地していました。トップページの一部イラストと人物写真だけが表示されない状態が、切り替えから数日間続いていたのです。サイト全体は正常に見えていたため、発見はサイトを見た関係者からの指摘でした。
このとき原因を確定できた決め手は、経路の各段階で600のファイル数を数えたことでした。手元のパソコンで46件、サーバー上の同期先で46件、ビルドの生成物で46件、本番の公開フォルダで46件。全段で数が一致したことで、「どこかで権限が壊れた」のではなく「最初から600のものが、一度も直されずに最後まで運ばれた」ことが証明できました。403の調査では、このように経路を上流までさかのぼって、どの段階から権限が同じかを見るのが確実です。
正しい対処：直す場所は「全部」、そして再発防止を仕込む
403の原因がパーミッションだと確定したら、対処は3段構えです。
1. デプロイのrsyncに権限矯正オプションを付ける（恒久対策）
rsync -a --chmod=F644,D755 dist/ 転送先/--chmod=F644,D755 は「ファイル（F）は644、ディレクトリ（D）は755に矯正して転送する」という指定です。これを付けておけば、手元のファイルがどんな権限であっても、本番には常に正しい権限で着地します。デプロイスクリプトを組むときは、最初からこのオプションを入れておくのが正解です。
2. すでに600で着地しているファイルを直す（即時対応）
事後の一括修正はfindコマンドが確実です。
# 他者が読めないファイルを644に
find 対象ディレクトリ -type f ! -perm -o+r -exec chmod 644 {} +このとき重要なのは、本番だけ直して終わりにしないことです。手元のソース、サーバー上の中間フォルダ、ビルド生成物、本番——経路上のすべてで直します。本番だけ直しても、上流に600のファイルが残っていれば、次のデプロイでまた600に戻ります。「直したはずなのに再発した」の典型パターンです。
3. 直した後に、デプロイを1回流して実証する
スクリプトを修正しただけで安心してはいけません。実際にビルドとデプロイを1回走らせて、600のファイルが0件のままであることを確認するところまでやって、はじめて対策完了です。先ほどの医療系サイトの例では、修正後に強制ビルドを流し、生成された全ページの画像453枚すべてが200を返すことを機械的に確認しました。
デプロイ後の検証は「全画像のステータス確認」を型にする
再発防止のもう一段上として、デプロイ後の検証を仕組みにしておくことをおすすめします。やることはシンプルで、ページのHTMLから画像URLをすべて抽出し、1件ずつHTTPステータスを確認するだけです。
この検証の良いところは、404（アップ漏れ）だけでなく403（権限）も同じ網で引っかけられる点です。目視チェックだと「なんとなく全部出ている気がする」で通してしまいますが、全件のステータス確認なら、ページ下部の1枚だけが403、といった見落としやすいケースも拾えます。
なお、403には権限以外の原因もあります。たとえば国内のレンタルサーバーには、セキュリティ設定として国外IPからのアクセスを403で弾くものがあり、海外のサービスからサイトのAPIを呼ぶと403になる、といったケースです。「ブラウザからは見えるのに、外部ツールからは403」という症状なら、パーミッションではなくアクセス制限側を疑います。今回のように「特定の画像だけ、誰から見ても403」ならパーミッション、と覚えておくと切り分けが速くなります。
まとめ：チェックの順番
画像だけが表示されないときの手順を整理します。
- 開発者ツールでステータスコードを見る。404か403かで原因の系統がまったく違う
- 404ならパスとアップロード作業を確認する
- 403なら同じフォルダ内で表示されるものと混在していないかを見る。混在していればファイル単位のパーミッション
- 600のファイルを見つけたら、本番だけでなく経路上のすべてで644に直す
- デプロイのrsyncには
--chmod=F644,D755を付けて、以後どんな権限のファイルが来ても本番が正しくなるようにする - 修正後は実際にデプロイを1回流して、再発しないことを確認する
とくに注意したいのは、FTP運用からrsyncによる自動デプロイへ移行するタイミングです。FTP時代には表面化しなかった権限の問題が、移行した瞬間から発生しうる、という構造を知っているだけで、「切り替え後は全画像のステータスを機械的に確認する」という一手が打てるようになります。
制作会社にサイト運用を任せている経営者の方であれば、この記事の内容をそのまま知る必要はありません。ただ、画像が表示されないトラブルが起きたときに「404ですか、403ですか」と聞けるだけで、調査はぐっと速くなります。逆に、キャッシュクリアや再アップロードを繰り返すだけで数日経っているようなら、切り分けの順番が違うのかもしれない、と考えてみてください。
graciautoでは、ホームページの制作だけでなく、公開後の運用設計——デプロイの自動化や、こうしたトラブルを未然に防ぐ検証の仕組みづくりまで含めてサポートしています。「画像が表示されない」「サイトの挙動がおかしいが原因が分からない」といったお困りごとがあれば、お気軽にご相談ください。