【WordPress】画像アップロードできない・403エラーが出る時の対処法3ステップ｜40代ブロガー実録

「画像をアップしたら 403 Forbidden が返ってくる」 「ファイル名や内容には何も問題ないはずなのに、特定の画像だけ通らない」 「WordPress 管理画面でも REST API でも同じエラー」

もしそう思っているなら、この記事は完全にあなたのためのものです。

筆者は北海道で建設業をやっている40代の現場マン（非エンジニア）。副業のアフィリエイトブログ（ConoHa WING＋WordPress）で、画像をREST API経由でアップロードしている最中、突然 403 Forbidden（閲覧できません） が頻発するようになりました。

最初は「サーバー障害？」「ConoHa停止？」と疑いましたが、原因はWAF（Web Application Firewall）のバイナリ判定でした。本記事では、3ステップで確実に復旧させた手順を、実体験ベースで解説します。

この記事はこんな方向け

• WordPress に画像アップで 403 エラーが出ている人
• ConoHa / エックスサーバー のWAFで詰まったブロガー
• REST API で記事を一括投稿しているClaude Code ユーザー
• 「どこに原因があるか分からない」状態でググり倒している人

※ 本記事は Claude Code（筆者が使用中のAIアシスタント）が筆者の実体験を元に執筆しています。

---

🎙 この記事に登場するキャラ

• 社長 — 筆者本人（北海道・建設業41歳・副業ブロガー）
• 策 — Claude Code（参謀AI・REST API実装担当）
• 凛 — Claude.ai（秘書AI・調査担当）

社長：「画像アップしたら403。サーバーダウンかと思って慌てた。」

凛：「実はWAFの誤検知よ。画像のバイナリパターンで弾かれることがある。」

策：「3ステップで通せます。順番が大事。」

---

1. 【問題提起】WordPress 画像アップで403が出るのはなぜ？

1-1. 結論：WAFが画像のバイナリ内容で誤判定している

403エラーの99%は WAF（Web Application Firewall）の誤検知。レンタルサーバーが標準で入れている「SiteGuard」や「ConoHa独自WAF」は、画像のバイナリパターンを見て「不正アクセスっぽい」と判定すると一律で弾きます。

1-2. ありがちな誤判定パターン

筆者の実体験では、以下のパターンで403が出ました：

パターン	推定原因
ファイル名に “video” “creators” 等を含む	WAFのキーワード検知
200KB超のJPEG	サイズ閾値での判定
AI生成画像（特に文字焼き込みあり）	OCRっぽいバイナリパターン
同じ画像名で連続アップ	重複検知

1-3. レート制限ではない

最初は「レートリミット（短時間に大量アクセスでブロック）」を疑いました。しかし、

• アップロード間隔を sleep で5秒入れても変わらず
• 1枚目で403、2枚目で成功、3枚目でまた403、というランダム性
• ConoHa管理画面のログを見ても「Rate limit exceeded」ではなく「WAF rejection」

→ WAFバイナリ判定で確定。

策：「レートリミットならsleepで解決。WAF誤検知なら、画像そのものを変えるしかありません。」

---

2. 【3ステップ復旧フロー】こうやれば必ず通る

2-1. ステップ1：ファイル名を変える

最も簡単な対策。WAFが「キーワードで弾く」傾向があるため、別名にして再アップロードします。

❌ NG例	✅ OK例
videoproc-eyecatch.jpg	media-creator-toolset.jpg
creators-japan-banner.jpg	online-school-pickup.jpg
7step-flow.jpg	process-overview.jpg

ポイント：ありふれた英単語の組み合わせに変える。具体的なサービス名・カテゴリ名は避ける。

2-2. ステップ2：JPEGの quality を下げる

ファイル名で通らない場合、画像のバイナリ自体を変える。Pillowで再エンコードすると、内部のメタデータ・ハフマン符号が変わり、WAFの判定パターンを外せることが多い。

from PIL import Image
img = Image.open(src)
if img.mode == "RGBA":
    img = img.convert("RGB")
img.save(dst, "JPEG", quality=82, optimize=True, progressive=True)

quality を 88 → 85 → 82 → 75 と段階的に下げる。75まで下げれば9割通るのが筆者の経験則。

2-3. ステップ3：256×256 の小サイズに縮小

最終手段。画像そのものを256×256のサムネイルサイズにすると、ほぼ確実に通ります。

img.thumbnail((256, 256), Image.LANCZOS)
img.save("temp_thumb.jpg", "JPEG", quality=85)

WAFの「特定サイズ／特定パターン」検知から外れるためです。いったん256で通してから本サイズで再アップする裏技も有効。

2-4. 順番が大事

順序	試すこと	通る確率
1	ファイル名変更	50%
2	JPEG quality 下げ	75%
3	256×256 縮小	95%
最終手段	ConoHa管理画面でWAFを一時OFF	100%（ただし非推奨）

2-5. 筆者の最近の実例

直近の記事執筆で、ChatGPT Images 2.0 で生成した「7ステップフロー図解」がこのパターンに該当：

[1回目] distrokid-flow-7step-blog.jpg → 403
[2回目] music-distribution-process.jpg → ✓ 成功

→ ステップ1（リネーム）だけで突破できた成功例。

---

3. 【ありがちな失敗】WAFを完全OFFにするのはNG

3-1. 「WAFを切れば全部解決するのでは？」

ConoHa管理画面でWAFを完全OFFにすれば、確かに画像403は完全消滅します。しかし非推奨。

3-2. WAFを切ると失う守備力

• 不正ログイン試行を弾けなくなる
• ブルートフォース攻撃が素通り
• コメントスパムBOTが侵入
• WordPressプラグイン脆弱性を突いた攻撃に無防備

3-3. 正しい付き合い方

WAFはONのまま、画像側を調整するのが正解。「画像を3ステップ加工 → アップ → 通れば完了、通らなければ次」のループを回せばOK。

策：「WAFは家のセキュリティドア。画像が引っかかるたびに外すのではなく、ノックの仕方を変えるのが正攻法です。」

---

4. 【じゃあどうやる？】Claude Code でフォールバック処理を仕込む

4-1. 自動リトライ処理のサンプル

毎回手動で対処するのは面倒。Claude Code で自動フォールバック関数を組んでおくと、楽です。

def upload_with_waf_fallback(src, base_name, auth, base_url):
    """WAF 403 が返ったら、リネーム→quality下げ→縮小の順でリトライ"""
    attempts = [
        {"name": f"{base_name}-v1.jpg", "w": 1196, "q": 88},
        {"name": f"{base_name}-blog.jpg", "w": 1180, "q": 85},
        {"name": f"image-{base_name}.jpg", "w": 1100, "q": 82},
        {"name": f"thumb-{base_name}.jpg", "w": 256, "q": 85},
    ]
    img = Image.open(src).convert("RGB")
    for opt in attempts:
        out = process_image(img, opt["w"], opt["q"])
        resp = post_to_wp(out, opt["name"], auth, base_url)
        if resp.ok:
            return resp.json()
    raise Exception("全試行失敗")

4-2. このコードがやってくれること

• 1回目：通常パラメータでアップ
• 失敗したら自動でリネーム＋quality下げで再試行
• それでも失敗したら縮小版で再試行
• 4回目（256サイズ）でほぼ通る

筆者は20件以上の記事更新でこのコードを回していますが、95%が3回以内で通っています。

4-3. Claude Code に依頼する具体的な日本語

（Claude Code への指示）
WP REST API 画像アップロードで 403 が返った時に、
リネーム→quality下げ→256縮小の順でリトライする
upload_with_waf_fallback 関数を作って。

→ 3分でテスト済みコードが上がってきます。

---

5. よくある質問（FAQ）

Q1. ConoHa以外のサーバーでも同じ手順？

A: エックスサーバー / さくら / X10 系もSiteGuardを入れているケースが多いので、同じ3ステップで通ることが多いです。

Q2. 全部の画像が403になる場合は？

A: 個別の画像問題ではなく、サイト全体のWAF設定が厳しすぎます。ConoHa管理画面で「WAFカスタムルール」を確認、またはサポートに連絡して例外設定をしてもらうのが早いです。

Q3. 一括投稿スクリプトで毎回引っかかるのが嫌……

A: 4-1のフォールバック関数を最初から組み込んでおく。1回作れば一生使えるので投資効果◎。

Q4. ConoHa独自WAFと SiteGuard の違いは？

A: ConoHa標準は両方ON。ConoHa独自WAFは商用攻撃パターン特化、SiteGuardは WordPress特化。両方をくぐり抜ける必要があります。

Q5. AI生成画像が特に弾かれやすいって本当？

A: 筆者の体感ではその傾向あり。文字焼き込み・特定の色配置・粒子エフェクトが判定パターンに引っかかることがあります。JPEG再エンコードで大半は通ります。

---

6. まとめ｜伝えたかったこと

長くなりましたが、伝えたかったのは一つだけ。

WAFの403は、画像側を3ステップで調整すれば必ず通せます。

WAFを切るのは最終手段。まずリネーム → quality下げ → 256縮小の順でリトライ。これを Claude Code でフォールバック関数化すれば、今後一生詰まらないブログ運用になります。

40代非エンジニアでも、Claude Code に依頼すれば3分で実装できます。403で挫折しかけている人は、ぜひ今日試してください。

次に読むべき記事