本記事にはアフィリエイト広告を含みます。
前回、「401エラーの沼にハマった話」を書いたとき、あちこちWAF(サイトを守る警備員のような仕組み)を疑ったんだけど、最終的にはWAFは犯人じゃなかったの。だから「WAFのせいじゃなかった」で話が終わったつもりだったんだけど……実はその後、別の場面で今度こそ本当にWAFに止められてたことが、ログという証拠付きで分かったんだよね。
今回はその話をするよ。記事の削除だけがなぜか失敗する→WAFログを見たら本当に止められていた→でもWAFを切らずに解決できた、という一部始終を見せるね。「AIに自動投稿させてたら、一部の操作だけなぜか失敗する」——もしあなたも同じ状況にハマっているなら、きっと参考になるはず。WAFログのどこを見ればいいか、削除がダメでも投稿・更新はなぜ通るのか、が具体的に分かるはずだよ。
※本記事にはアフィリエイト広告を含みます。
この記事でわかること
ブログの記事を自動で投稿できたのに、削除だけが失敗する。そんなとき、サイトの入口にいる警備員(WAF)の記録を見て、原因をつかむ方法がわかります。警備員を休ませずに、削除をうまく通せた工夫も持ち帰れます。
前提の「そもそもConoHaでの自動投稿の仕組み」は前回記事にまとめてあるので、まだの人はそちらもどうぞ。
→ WordPress自動投稿、401エラーの沼にハマった話
事の発端:記事の削除だけが403で失敗した
きっかけは、Claude Codeで「WordPressの記事を直接修正できる機能」を作っていたとき。テスト用に作った下書きをゴミ箱に移そうとしたら、403エラーで止まったの。同じ仕組みで記事の新規作成や更新はできてたから、「あれ、削除だけ?」って引っかかった。
パソコンからWordPressに何かを頼むとき、そのお願いには封筒のラベルみたいな種類が付いてるんだ。「見せてください」がGET、「これを受け取ってください(新しく作る・更新する)」がPOST、「これを消してください」がDELETE。この「ラベルの種類」のことを、正式にはHTTPメソッドと呼ぶんだよ。
WAFログで確認したら、本当に「削除のラベル」で止められていた
おかしいと思ったから、ConoHaの管理画面でWAFのログを見てみたの。コントロールパネルの「サイト管理」→対象サイト→「サイトセキュリティ」→「WAF」の「ログ」タブね。そうしたら、削除しようとした時刻とぴったり同じタイムスタンプ(2026-09-24 14:49:06)に、宛先が/wp-json/wp/v2/posts…で、攻撃内容が「WebDAVなどで利用するメソッドの拒否(PUT、COPYなど)」という検知が、ちゃんと記録されてた。
サーバーの入口にはWAFという警備員が立ってるんだけど、ConoHaの警備員には「DELETEやPUTのラベルが付いた封筒は、誰が持ってきても入口で断る」というルールがあるんだ。これらのラベルは、昔からサーバーのファイルを外から消したり書き換えたりする攻撃によく使われてきたから、念のため一律にお断りにしてる。警備員は封筒の中身も差出人も見ずに、ラベルだけで機械的に判断するから、本人からの正しい削除のお願いでも、ラベルがDELETEだった時点で門前払いになってたんだ。一方、POST(新規作成・更新)は普段から大量に使われるラベルだから、そのまま通る。更新は通って削除だけ止まった理由は、まさにこれ。
回避策:WAFを切らずに「伝票」で本当のお願いを伝える
じゃあWAFを一時的にOFFにすればいいのかっていうと、それはやりたくなかった。画像アップロードの件(後述)もあって、WAFはできるだけONのままにしておきたかったから。
そこで使ったのが、WordPress REST APIが公式に用意してる「メソッドオーバーライド」って機能。封筒のラベルはPOSTのままにして、中に入れた伝票に「削除してください」と書く。これが_method=DELETEってパラメータ。警備員は外のラベルしか見てないから、POSTとしてそのまま通す。封筒が中に入ったあと、WordPress自身が伝票を読んで、あらためて削除として処理してくれるんだ。
POST /wp-json/wp/v2/posts/681?_method=DELETE
これはズルじゃないよ。WordPressが公式に用意してる機能で、DELETEをそのまま通さないサーバーでも動くように最初から準備されてる仕組みなんだ。警備員を通り抜けたあとも、WordPressの中でもう一度「この人に削除する権限があるか」をパスワードで確認するから、誰でも記事を消せるようになったわけじゃない。WAFのルール自体も変えてないから、本物の攻撃はこれまで通り防がれる。
この方法をpost_to_wordpress.pyに--trash-idオプションとして組み込んで、今は1コマンドでゴミ箱移動ができるようになった。
ビフォーアフター:削除操作が毎回403で失敗し、WordPress管理画面から手動でゴミ箱に移していた状態から、Claude Codeからのコマンド1回でゴミ箱移動が完了する状態に変わった。
注意点:WAFの「除外設定」(検知ルールそのものを無効化する機能)は使わなかった。除外するとその種類の攻撃も一緒に通りやすくなるため、今回は「WAFはそのまま・自分側でメソッドを変える」方法を選んだ。
もう一つ止められていたもの:画像アップロード
実はもう一つ、以前「画像だけアップロードできない」ことがあって、画像アップロードのときだけWAFを一時的にOFFにする運用にしてた時期があったの。この話は前に「Claude Codeで作るWordPress自動下書き投稿の仕組み」でも触れたんだけど、今回はその続きとして、WAFログを宛先URL「media」で検索してみたら、/wp-json/wp/v2/media宛ての検知が4件見つかった。
削除のときはラベル(POST自体)は問題なかったんだけど、画像のときは逆で、ラベルはPOSTのままセーフ。その代わり警備員が封筒の中身(画像データそのもの)までのぞいて、怪しい文字の並びがないかチェックしてたんだ。警備員は「こういう並びは攻撃っぽい」という要注意リストを何種類も持っていて、画像データの中の記号の並びが、どれかにたまたま似ていると止めてしまう。ログに出ていた検知名は、以前の4件がSQLインジェクションやXSS(クロスサイトスクリプティング)、この記事を投稿したときの1件がXPathインジェクション。どれも、データベースやページに悪い命令を紛れ込ませる攻撃の正式な名前なんだ。画面に写っている文字が原因なんじゃなくて、ファイルの中のデータの並びの問題だから、同じ手順でも画像によって通ったり止まったりしてたんだ。
つまり「アップロード手順が悪い」んじゃなくて「その画像のデータの並びがたまたま怪しく見えた」だけ、ってこと。これまで「画像アップロードのときだけWAFを一時OFFにする」運用にしてたのは、理にかなってたんだなって納得できた。
実はこの記事を投稿するときも、1枚目のスクショ(削除が403で失敗した画面)のアップロードが止められたの。WAFログには「XPathインジェクション試行の可能性」という検知が残ってた。結局そのときも、WAFを一時的にOFFにしてアップロードして、終わったらすぐONに戻したよ。
注意点:画像アップロードについては、削除のような決定的な回避策はまだ見つかっていない。今のところ「止まったらWAFを一時OFF→アップロード→すぐONに戻す」で対応している。
どんな人に役立つか:WordPressの自動投稿・自動更新の仕組みを自分で作っていて、「一部の操作だけなぜか失敗する」「画像だけ時々失敗する」という状態にハマっている人に向けた内容。
つまずきやすいポイントまとめ
- 投稿・更新は通るのに削除だけ失敗するときは、まずWAFログで同じ時刻の検知を探す
- WAFログは宛先URLで絞り込める(例:「media」で検索)ので、操作の種類ごとに調べると原因が特定しやすい
- WAFの「除外設定」は使わず、
_method=DELETEのようなアプリ側の回避策があるなら、そちらを優先する - 画像アップロードの失敗は「手順」ではなく「その画像の中身」が原因のことがあるので、同じ手順でも画像を変えると通ることがある
- WAFログは表示できる件数・期間に限りがあるので、気づいたら早めにスクショなどで残しておく
まとめ
前回は「疑ったけど結局WAFじゃなかった」って話だったけど、今回はログという証拠付きで、正真正銘WAFが原因だったケースだったね。
そう。しかもWAFを切らずに解決できたのが、自分でも一番納得できたところ。同じように自動投稿・自動更新を試してる人の助けになったらうれしいな。
前回の「401エラーの沼にハマった話」もあわせてどうぞ。
→ WordPress自動投稿、401エラーの沼にハマった話
※本記事にはアフィリエイト広告を含みます。
ちなみに私が使ってるのはConoHa WING。こういう込み入った設定も管理画面内で完結できるところは気に入ってる。実はサーバー選び自体も一度ちゃんと比較していて、その話は「AI自動投稿の土台に。レンタルサーバー5社を比較した話」にまとめてある。
コメント