WordPressのフォーム、外部連携、REST API、画像やファイルの送信で「415 Unsupported Media Type」と表示されることがあります。URLは正しく、認証も通っているように見えるのに、POSTやPUTを送った瞬間に拒否される症状です。
415は、対象URLとHTTPメソッドに対して、送信内容の形式が対応していない状態です。確認するのはファイル拡張子だけではありません。Content-Type、Content-Encoding、実際の本文、multipartの境界、API仕様を分けて見ます。
拡張子を書き換えたり、すべてのMIMEタイプを許可したり、WAFの検査を全面停止したりしないでください。対象エンドポイントが受け付ける形式を確認し、送信側と受信側の一方だけを必要な範囲で合わせます。
先に結論：415エラーは8段階で確認する
- 投稿本文やフォーム入力、送信元ファイルを退避する
- 完全なURL、HTTPメソッド、時刻、HTTP 415を記録する
- 要求のContent-TypeとContent-Encodingを確認する
- ヘッダーが示す形式と実際の本文が一致するか確認する
- 対象APIが受け付けるJSON・フォーム・ファイル形式を確認する
- WordPress、プラグイン、CDN・WAFのどこが415を返したか絞る
- 送信形式か対象エンドポイントを一か所だけ修正する
- 復旧後に非対応形式が引き続き拒否されることも確認する
GETは通るのにPOSTだけ失敗する場合でも、まずHTTPメソッド自体が拒否された405か、本文形式が拒否された415かを分けます。詳しくはWordPressの405 Method Not Allowedを確認する手順も参照してください。
415 Unsupported Media Typeとは？
RFC 9110の415 Unsupported Media Typeは、対象リソースのそのメソッドで対応していない形式の内容が送られたため、オリジンサーバーが要求を拒否した状態です。
形式の問題は、要求ヘッダーのContent-Type、圧縮などを示すContent-Encoding、または本文を実際に調べた結果から判断されます。つまり「ヘッダーだけ直せば必ず通る」「ファイル名だけ変えればよい」とは限りません。
サーバーは、対応するメディアタイプをAccept、対応する内容符号化をAccept-Encodingで応答に示す場合があります。ただし、毎回これらが返るとは限らないため、APIやプラグインの公式仕様も確認します。
Content-Type・Accept・Content-Encodingの違い
| ヘッダー | 主な役割 | 415で確認する点 |
|---|---|---|
| Content-Type | 今回送る本文の形式 | JSON、URLエンコード、multipart等が実データと一致するか |
| Accept | クライアントが受け取りたい応答形式 | 要求本文の形式指定と混同していないか |
| Content-Encoding | 本文へ施した圧縮など | サーバーがgzip等の符号化を受け付けるか |
| Accept-Encoding | 受け付ける内容符号化の候補 | 応答側のヒントとして返っているか |
「JSONを返してほしい」ためにAccept: application/jsonを付けても、送信本文がJSONであることは示せません。JSON本文を送るなら、対象APIの仕様に従ってContent-Type: application/jsonを使い、本文自体も正しいJSONにします。
400・405・406・415・422の違い
| 表示 | 主な意味 | 最初に見るもの |
|---|---|---|
| 400 Bad Request | 要求の構文や内容を処理できない | URL、ヘッダー、JSON構文、本文 |
| 405 Method Not Allowed | 対象URLでそのメソッドが非対応 | URL、GET・POST等、Allow |
| 406 Not Acceptable | Accept条件に合う応答を提供できない | Accept、言語、応答形式 |
| 415 Unsupported Media Type | 送信内容の形式が非対応 | Content-Type、Content-Encoding、実本文 |
| 422 Unprocessable Content | 形式と構文は理解したが内容の指示を処理できない | 項目値、意味上の検証、APIエラー本文 |
同じ設定ミスでも、実装によって400、415、422など異なるステータスが返る場合があります。番号だけで原因を決めず、応答本文のエラーコード、対象URL、メソッド、要求ヘッダーを一組で確認します。
WordPressでは必ず415になるとは限らない
WordPressのWP_REST_Requestは、要求のContent-Typeを取得し、JSON形式かどうかを判定して本文パラメータを解析します。ただし、不正なJSONや必須項目不足に対して、WordPressコアやプラグインが必ずHTTP 415を返すわけではありません。
たとえばJSONとして解釈できない本文は400系の別エラー、登録されていないRESTルートは404、メソッド不一致もWordPressの実装では404相当になる場合があります。実際のステータスと応答本文を確認し、415という文字だけを探さないことが大切です。
メディアライブラリで「このファイルタイプは許可されていません」と表示される場合も、画面のエラーとHTTP 415は同じとは限りません。WordPressは拡張子、申告されたMIME、実ファイルの種類を別に検査します。
最初の10分で行う安全な初動
1．送信内容を退避して再試行を止める
ブロックエディターの本文、フォーム入力、JSON、送信元ファイルを手元へ保存します。外部APIの場合は、認証情報を除いたテスト用の要求を用意し、本番データを何度も再送しないようにします。
本文保存で「正しいJSONレスポンスではありません」も出る場合は、WordPressのJSONレスポンスエラーを直す確認順も使い、415とHTMLエラーページ、WAF拒否、PHP警告を分けます。
2．要求と応答を一組で記録する
- 完全なURLとHTTPメソッド
- 発生日時とタイムゾーン
- Content-TypeとContent-Encoding
- AcceptとAccept-Encoding
- 本文がJSON、フォーム、multipart、バイナリのどれか
- 送信ファイル名、拡張子、実際の形式
- HTTP 415と応答本文のエラーコード
- CDN・WAF・プロキシの識別情報
Authorization、Cookie、APIキー、個人情報、ファイル本文は公開記録へ貼りません。ヘッダー名と形式は残し、秘密の値だけを伏せます。スクリーンショットを共有する場合も同じです。
3．公式仕様と成功例を確認する
対象APIの最新版仕様で、URL、メソッド、認証、Content-Type、本文例を確認します。以前動いたコードがあれば、秘密情報を除いたヘッダーと本文構造を比較します。一度に複数項目を変えず、違いを一つずつ戻せるように記録します。
外部サービスの仕様変更が疑われる場合は、更新履歴と廃止予定を確認します。ブログ記事や古いコード例より、現在のAPIリファレンスとレスポンスのエラー本文を優先してください。
どの層が415を返したか特定する
415はWordPressコアだけでなく、プラグインのRESTルート、外部API、CDN・WAF、リバースプロキシ、Webサーバー、アプリケーションゲートウェイから返る可能性があります。エラー画面のデザインではなく、応答ヘッダーと同時刻ログを見ます。
| 確認場所 | 見るもの | 判断の手がかり |
|---|---|---|
| ブラウザ・APIクライアント | Request Headers、Payload | 送った形式と実本文が一致するか |
| CDN・WAF | イベント、ルール、応答ヘッダー | 形式検査で中継層が拒否したか |
| WordPress REST API | ルート、メソッド、エラーコード | 対象エンドポイントへ届いたか |
| プラグイン・テーマ | 更新履歴、独自ルート、ログ | 対応形式やバージョンが変わったか |
| 外部API | API仕様、リクエストID | WordPress外で拒否されたか |
同じURLへGETするとJSONが返っても、POST本文の形式が正しい証明にはなりません。GETの表示確認、POSTのメソッド確認、POST本文の形式確認を分け、要求ごとのNetwork情報を保存します。
原因別の安全な直し方
1．JSON本文なのにContent-Typeが違う
JSONを送るAPIでは、仕様に従ってContent-Type: application/jsonを設定し、本文を正しいJSONとしてエンコードします。JavaScriptオブジェクトをそのまま文字列化せず送ったり、JSON本文にフォーム形式のヘッダーを付けたりしないようにします。
WordPress REST APIのリファレンスは、APIの要求・応答形式としてJSONを使用します。対象ルートのスキーマ、必須項目、認証、メソッドも同時に確認してください。
2．フォーム形式とJSON形式を混ぜている
通常のHTMLフォームは、初期状態ではapplication/x-www-form-urlencodedで送られることがあります。JavaScriptでJSON送信へ変更したのに、受信側がフォーム本文だけを読む実装なら、送信側か受信側の仕様を統一します。
WordPress REST API HandbookのRequestsでは、本文パラメータとファイルパラメータの渡し方が分けて説明されています。プラグイン独自APIは同じとは限らないため、そのプラグインの仕様を優先します。
3．multipart/form-dataのboundaryが壊れている
ファイルとフォーム項目を同時に送るときは、通常multipart/form-dataを使います。この形式には各パートを区切るboundaryが必要です。ブラウザのFormDataを使う場合、Content-Typeを手作業で固定すると、ブラウザが生成するboundaryを失うことがあります。
まず利用ライブラリの推奨方法に戻し、ヘッダーを自動生成させます。サーバー側で受け取った生のContent-Typeと、本文の区切りが一致するかを確認します。実ファイルを公開ログへ保存しないよう注意してください。
4．Content-Encodingが受信側に対応していない
クライアントや中継ツールが要求本文をgzip等で圧縮し、受信側がその符号化に対応していないと415になる場合があります。応答のAccept-Encoding、API仕様、中継設定を確認し、未対応なら要求本文の圧縮を外すか、対応する符号化だけを使用します。
HTTP圧縮、ZIPファイル、画像圧縮は別の概念です。Content-Encoding: gzipはHTTP本文へ施した変換を示すため、ZIPファイルを送るだけで自動的に指定するものではありません。
5．ファイルの拡張子・MIME・実データが一致しない
WordPressのwp_check_filetype_and_ext()は、ファイル名の拡張子と実際のファイル種別を確認します。拡張子だけを許可形式へ書き換えても、中身が別形式なら正しく解決しません。
正しいアプリケーションで対応形式へ書き出し直し、元ファイルを保管してからアップロードします。許可されていない形式を追加する必要がある場合は、利用者権限、保存後の配信方法、ブラウザ実行リスクまで確認します。
通常のメディア追加で失敗する場合は、WordPressの画像アップロードエラーを確認する手順も使い、容量、権限、画像処理、MIME検査を分けてください。
6．対象APIのバージョンや仕様が変わった
外部APIやプラグインが新しいバージョンでXMLを廃止してJSONのみへ変更するなど、受け付ける形式が変わる場合があります。現在のエンドポイントとバージョン、廃止日、移行ガイドを確認し、古い形式を無理に許可しません。
WordPress本体、プラグイン、テーマの更新後だけ再現するなら、更新履歴と既知問題を確認し、WordPressテスト環境で旧版・新版と標準状態を比較します。本番で無計画にダウングレードしないでください。
7．CDN・WAF・APIゲートウェイが形式を拒否する
中継層が特定のContent-Type、圧縮本文、multipart要求を制限する場合があります。同時刻のイベントログ、ルールID、対象パスを確認し、誤検知なら対象URL・メソッド・形式へ限定した例外を検討します。
サイト全体でMIME検査やWAFを止めると、実行可能ファイルや不正な本文まで通す危険があります。非対応形式が拒否されることは正常な防御でもあるため、正しい要求を通す最小変更にとどめます。
415対応でやってはいけないこと
- ファイルの中身を変えず拡張子だけを書き換える
- すべてのMIMEタイプやContent-Typeを許可する
- Content-TypeとAcceptを同じ役割だと思って変更する
- FormDataのboundaryを理解せず手入力する
- CDN・WAF・認証をサイト全体で停止する
- 秘密のAPIキーや要求本文をそのままログへ残す
- URL、メソッド、形式を同時に変えて原因を見失う
415は、受信側が対応しない形式を拒否しているという意味であり、拒否自体が不具合とは限りません。対象仕様にない形式を無理に通すより、送信側を正しい契約へ合わせるほうが安全です。
復旧後に確認すること
- 正しいURL・メソッド・Content-Typeで一度だけ成功する
- 本文形式とヘッダーが一致している
- JSONやフォームの必須項目が正しく処理される
- ファイルが意図したMIMEと拡張子で保存される
- 非対応形式や危険なファイルは引き続き拒否される
- CDN・WAF・認証・権限が有効なまま
- 公開ページと管理画面に別のエラーが出ていない
公開URL自体が継続的に415を返す場合は放置しません。GoogleのHTTPステータス資料では、429を除く4xxを返すURLの内容は検索処理に使われず、既存URLも時間とともに扱われなくなると説明されています。
開発会社・サービス提供元へ伝える情報
- 発生日時とタイムゾーン
- 完全なURL、APIバージョン、HTTPメソッド
- Content-Type、Content-Encoding、Accept
- 本文形式とファイル形式
- HTTP 415と応答本文のエラーコード
- 直前のWordPress・プラグイン・クライアント更新
- CDN・WAF・プロキシの利用状況
- 秘密情報を除いた要求ID・応答ヘッダー
「415を解除してください」ではなく、「このURLのPOSTはapplication/jsonを受け付けるか」「multipart/form-dataのファイル項目名は何か」「Content-Encodingは対応しているか」を確認すると、仕様と実装のずれを早く見つけられます。
よくある質問
Content-Typeをapplication/jsonにすれば直りますか？
対象APIがJSONを受け付け、本文も正しいJSONなら直る可能性があります。フォームやファイル用エンドポイントへJSONを送る場合は逆に不一致になるため、API仕様を確認してから変更します。
画像の拡張子をjpgへ変えればアップロードできますか？
名前だけを変更しても実データは変わりません。WordPressは拡張子と実際のファイル種別を確認するため、画像編集ソフトで対応形式へ正しく書き出し直してください。
415と「このファイルタイプは許可されていません」は同じですか？
同じ形式問題が関係することはありますが、必ず同じHTTPステータスではありません。ブラウザのNetworkで実際の応答を確認し、WordPressのMIME検査、APIのContent-Type、WAF拒否を分けます。
Acceptにapplication/jsonを設定すればよいですか？
Acceptは主に受け取りたい応答形式を示します。今回送る本文の形式はContent-Typeで示すため、両者を混同しないでください。どちらが必要かは対象APIの仕様で確認します。
REST APIを無効化すれば415は消えますか？
REST APIを止めても正しい送信形式にはなりません。ブロックエディターや各種機能がREST APIへ依存するため、サイト全体の無効化ではなく、対象ルート、メソッド、Content-Type、認証を確認してください。
まとめ
WordPressの415 Unsupported Media Typeは、対象URLとメソッドに対して、送信内容の形式が対応していない状態です。Content-Type、Content-Encoding、実際の本文、multipartのboundary、ファイルの実形式を分けて確認します。
要求と応答を保存し、公式仕様の成功例と比較し、一か所だけを正しい形式へ合わせることが安全な復旧方法です。非対応形式を拒否する防御は残し、拡張子変更や全許可で問題を隠さないでください。