「画像をアップしたら 403 Forbidden が返ってくる」 「ファイル名や内容には何も問題ないはずなのに、特定の画像だけ通らない」 「WordPress 管理画面や REST API で403が出る」
403の原因を決めつけず、確認する順番を整理します。
筆者は40代の会社員（非エンジニア）。副業のアフィリエイトブログ（ConoHa WING＋WordPress）で、画像をREST API経由でアップロードしている最中、突然 403 Forbidden（閲覧できません） が頻発するようになりました。
当時はConoHa WINGの遮断ログを手掛かりにWAFの影響を疑いました。ただし、403だけで原因を特定することはできません。この記事の再試行例は当時の記録であり、どの環境でも成功する手順ではありません。
この記事はこんな方向け
- WordPress に画像アップで 403 エラーが出ている人
- ConoHa WINGなどのサーバーで原因を調べたいブロガー
- REST API で記事を一括投稿しているClaude Code ユーザー
- 「どこに原因があるか分からない」状態でググり倒している人
※ 本記事は Claude Code（筆者が当時使用していたAIアシスタント）が筆者の実体験を元に執筆しています。
🎙 この記事に登場するキャラ
- 社長 — 筆者本人（40代・副業ブロガー）
- 策 — AIアシスタント（当時のClaude Code、現在の編集協力はChatGPT）
- 凛 — 秘書AI（当時はClaude.ai）
社長：「画像アップしたら403。サーバーダウンかと思って慌てた。」
凛：「403だけでは原因は分からないわ。失敗時刻とログを照合しましょう。」
策：「認証・権限と遮断ログを確認してから、対策を選びます。」
📌 目次（クリックでジャンプ）
2026年9月16日追記：この記事の403対処を公式情報で再確認しました。403だけでWAFが原因と断定できません。ConoHa WINGのWAF設定・遮断ログとWordPress REST APIの認証を参照し、原因を確認してから対処してください。会話・説明の一部をChatGPTが編集しました。
2026年10月2日確認：ConoHa WINGの公式ガイド（WAFの画面・遮断ログ・除外設定）とSiteGuard WP Pluginの紹介ページを再確認し、3-3とQ4に出典を追記しました。WordPress REST APIの認証方法（Cookie認証・アプリケーションパスワード）の説明も公式ドキュメントと食い違いがないことを確かめました。上記以外の箇所は再確認していません。
1. WordPress 画像アップで403が出るのはなぜ？
社長：403が出たら、すぐWAFが原因と決めていい？
策：いいえ。WordPressの認証・権限と、同時刻のWAF遮断ログを照合します。403だけでは原因は確定しません。
凛：失敗時刻と対象URLを控えてから、ログを見てね。
1-1. まず403の発生箇所と遮断ログを確認する
403はアクセス拒否を示しますが、WAF遮断とは限りません。REST APIでは認証やユーザー権限も確認が必要です。ConoHa WINGを使っている場合は、失敗した時刻・URLを控え、管理画面のWAF遮断ログに該当する記録があるか照合します。
1-2. 以前の推定を見直す
当時の個別の失敗例は残していますが、それだけではサーバー側の遮断条件は判断できません。
以前の版では、ファイル名・容量・AI生成画像をWAFの判定条件として表にまとめていました。しかし、各条件が原因と示す遮断ログや比較検証を確認できないため撤回します。画像ごとに成否が違っても、別の条件が変わった可能性があります。
1-3. レート制限や認証との切り分け
短時間の連続送信、認証情報、ユーザー権限、WAF遮断など、原因の候補を一つずつ照合します。403の表示だけでレート制限でもWAFでもないと断定しません。
- 失敗時刻と対象URLを控える
- REST APIの認証・権限を確認する
- ConoHa WINGを使う場合は同時刻のWAF遮断ログを確認する
当時の遮断ログはWAFを疑う根拠になります。ただし、どの検査条件が反応したかはログで確認しない限り断定できません。
策：同じ403でも原因は複数あります。レスポンスと権限、同時刻のWAFログを先に確認しましょう。
2. 【当時の3試行】原因確認より先に繰り返さない
社長：画像の名前や画質を変えれば、必ず直る？
策：保証できません。原因が認証なら画像を変えても同じです。WAFの遮断記録がある場合だけ、その内容に合う対策を考えます。
凛：元画像は残し、試すなら変更点を一つずつ記録しましょう。
2-1. 当時の試行1：ファイル名を変える
ファイル名の変更は、筆者が当時試した切り分けの一つです。403の原因が認証や権限なら効きません。元ファイルを保存し、変更点を一つずつ記録してください。
当時はファイル名を変えた直後に通った例がありました。ただし、その前後でほかの条件も変わり得るため、ファイル名が遮断条件だったとは断定できません。
ファイル名だけで対処できると考えず、WAFログとWordPress側の権限を先に確認します。
2-2. 当時の試行2：JPEGを再エンコードする
JPEGの再エンコードも、当時の試行結果です。成功を保証する方法ではなく、画質が変わる可能性があります。原因確認より先に大量の変換と再送を繰り返さないでください。
再エンコードが必要な場合は、元画像を残し、表示サイズと画質を確認してから1回ずつ試します。
画質を段階的に落とすほど通りやすい、という一般的な根拠はありません。本番画像の視認性を犠牲にしないでください。
2-3. 当時の試行3：小さなテスト画像で切り分ける
小さなテスト画像で応答の違いを見ることはできます。ただし、256×256は本文用の画像として小さすぎます。成功率の保証もありません。
テストした場合も、本番画像に置き換えず、どの条件が変わったかを記録します。
256×256への縮小は表示品質を大きく落とします。切り分け用の小さなテストに限り、本番のアイキャッチや挿絵として使わないでください。通過してもWAFが原因と確定したことにはなりません。
2-4. 試行順より原因の確認が大事
「名前変更50%・再圧縮75%・縮小95%・WAF停止100%」という確率は測定根拠を確認できないため撤回します。最初に認証・権限とWAF遮断ログを照合し、原因に合う対策だけを選んでください。
2-5. 筆者の当時の実例
当時の記事執筆で、AIで作った図解画像をアップしたときの記録です（ファイル名は一部伏せ、似た形の名前に置き換えています）：
[1回目] flow-7step-blog.jpg → 403
[2回目] process-flow.jpg → 成功
当時、名前を変えた後の再送で成功した一例です。ファイル名が原因だったと証明するものではありません。
3. 【ありがちな失敗】WAFを完全OFFにするのはNG
社長：WAFを丸ごと止めて試すのは？
策：保護を弱めます。ConoHa WINGには遮断ログと除外設定があるので、まず該当する記録と範囲を確認します。
凛：不要な除外は戻せるよう、設定前後をメモしてね。
3-1. 「WAFを切れば全部解決するのでは？」
WAFを全面的にOFFにしても、認証・権限など別の原因なら403は残ります。保護を弱めるため、原因未確認のまま常用する対処法にはしません。
3-2. WAFを切ると失う守備力
- WAF全体をOFFにすると、本来遮断していた通信も通すおそれがある
- WAFだけで全ての攻撃を防げるわけではないため、ほかの対策も維持する
- 該当する遮断を確認した場合のみ、必要な範囲の除外を検討する
3-3. 正しい付き合い方
まず失敗時刻とURLをWAFログに照合します。該当する遮断が確認できた場合は、ConoHa WINGの公式手順に従って必要な範囲だけ除外を検討し、再テスト後に不要な除外を解除します。ログに無ければ認証や権限など別の原因を調べます。
ConoHa WINGの公式ガイドによると、WAFの画面は「サイト管理」→「サイトセキュリティ」→「WAF」タブにあります。表示を「ログ」に切り替えると遮断されたアクセスの記録が見られ、ログの「除外」から除外を設定できます。設定した除外は「除外中」タブで確認し、「除外解除」で元に戻せます（ConoHa WING WAF設定ガイド・2026年10月2日確認）。画面の名前や並びは変わることがあるため、実際の画面と公式ガイドで確かめてください。
策：WAFの保護は維持し、遮断ログを確認してから必要な範囲だけ設定を見直します。
4. 403で止めて原因を記録する
社長：403でも自動で何度も再送した方がいい？
策：いいえ。認証や遮断が原因なら再送しても直りません。停止して時刻・URL・HTTP状態を記録し、人が原因を確認します。
凛：同じ失敗を繰り返す前に、ログで切り分けましょう。
4-1. 原因不明の403は自動再送しない
自動化するなら、403を受けた時点で停止し、時刻・対象URL・レスポンスの状態を記録して人に確認を求めます。画像の再圧縮と再送を繰り返す処理は、原因を隠すため推奨しません。
403 を受けたら停止する 失敗時刻・対象URL・レスポンス状態を記録する WordPress の認証・権限と WAF 遮断ログを照合する 原因を確認してから、必要な対策だけを試す
4-2. 自動化で守ること
- 1回だけアップロードし、結果を記録
- 403なら自動再送せず停止
- WAFの遮断ログとWordPressの認証・権限を照合
- 原因と影響範囲を確認してから対策を試す
当時の個別の試行は、現在の成功率や他サイトでの再現率を示しません。アップロードが継続して失敗する場合は、同じ条件で再送し続けず原因を切り分けます。
4-3. AIに依頼する具体的な日本語
WP REST API の画像アップロードで403が出たら自動再送しないで停止して。 失敗時刻、対象URL、HTTPステータスを記録し、秘密情報はログに残さないで。 認証・権限とConoHa WINGのWAF遮断ログの確認項目を提示して。
AIが提示した対処は、ステージングまたは影響を限定した環境で検証してから使います。所要時間は環境によって変わります。
同じ403でも、AIに自動投稿させたときは「文章は通るのに画像だけ弾かれる」という出方をします。その切り分けはWordPress REST APIが403になる原因にまとめました。
5. よくある質問（FAQ）
Q1. ConoHa以外のサーバーでも同じ手順？
A : サーバーごとに管理画面と防御設定が異なります。403だけで原因を決めず、利用中のサーバーの公式手順と遮断ログを確認してください。表示側の別問題はWordPressでXのタイムラインが表示されない原因と対処手順にまとめています。
Q2. 全部の画像が403になる場合は？
A : すべての画像が403なら、WordPressの認証・ユーザー権限、プラグイン、サーバーの遮断ログを順に調べます。WAFログに該当する遮断があれば、必要な範囲の除外やサポートへの相談を検討してください。
Q3. 一括投稿スクリプトで毎回引っかかるのが嫌……
A : 403の原因を確認せず再送する関数は組み込まないでください。失敗時に停止し、HTTP状態・時刻・対象URLを記録して通知する方が安全です。
Q4. ConoHa独自WAFと SiteGuard の違いは？
A : ConoHa WINGのWAFはサーバー側の保護機能、SiteGuardはWordPressのプラグイン（SiteGuard WP Plugin）です。WordPress.orgの紹介ページでは、ログイン保護や管理ページへのアクセス制限などの機能が挙げられています（SiteGuard WP Plugin・2026年10月2日確認）。両方の有無や設定はサイトごとに異なるため、管理画面で実際の状態を確認します。
Q5. AI生成画像が特に弾かれやすいって本当？
A : AI生成画像が特に弾かれやすいという比較データは確認できません。画像の種類だけで原因を決めず、実際の遮断ログとレスポンスを確認してください。
6. まとめ｜伝えたかったこと
長くなりましたが、伝えたかったのは一つだけ。
403が出ても、画像の加工だけで解決するとは限りません。まず認証・権限とサーバーの遮断ログを照合し、原因に合った対策を選びます。
WAFを安易にOFFにせず、ログで該当する遮断を確認してから対処します。原因が分からない403では自動処理を停止し、人が確認できる記録を残してください。
AIに切り分けを補助させる場合も、生成された手順やコードは人が確認してから使ってください。403で困っている方は、まず失敗時刻とWAFログを見比べるところから始めましょう。
次に読むべき記事
▶ あわせて読みたい
— AUTHOR —
社長（このブログの運営者）
40代会社員の副業ブロガー。本業のかたわら、AIツールを使った副業の実験を記録しています。
※ 記事はAI（Claude Code）が筆者の実体験・運営データをもとに執筆。AI執筆を隠さず、ツールの実力を体感できる実演サンプルとしています。
📌 副業の全体像をまだ見ていない方へ
Claude Code 副業の始め方｜40代非エンジニアが13ヶ月で組み上げた “ひとり事業部制” の全体マップ
この記事は副業全体マップの「枝」です。13ヶ月の試行錯誤を1ページにまとめた幹の方も合わせてどうぞ。
2026年10月15日更新（見直し）：決まった型の見出しラベル（問題提起・じゃあどうやる？）を外し、中身を表す見出しに直しました（目次も同じ）。それ以外の箇所は今回確認していません。
