【失敗談】Claude Code で自分のブログを3分間ダウンさせた話｜WP REST API を2時間で30回叩いた事件

2026-06-132026-09-25

2026年9月17日改稿：初稿はClaude Codeが執筆しました。今回、ChatGPTで本文を改稿し、WordPressとConoHa WINGの公式資料を確認しました。原因を断定していた記述は、障害ログで裏づけられないため改めています。

AIにWordPressの一括更新を任せた際、筆者の記録ではサイトが約3分間応答しなくなりました。ただし、その直前にREST APIを多く使ったことと、WAFが原因だったことは同じではありません。タイムアウト、サーバー負荷、プラグイン、認証、防御機能などをログで切り分けなければ原因は決められません。この失敗から得た実務上の教訓は、書き込みを小分けにし、1件ごとに結果を照合し、異常時は止めることです。

WordPress REST APIは、記事やメディアを外部プログラムから扱うための窓口です。AIがコマンドを作っても、実際の更新はWordPressとサーバーの設定に依存します。WordPress公式は記事の更新にPOSTエンドポイントを用意していますが、サイト共通の「1時間30回」や「必ず2秒間隔」という上限を定めてはいません。WordPress公式：記事更新API。

社長：更新をまとめて走らせた直後にサイトが開けなくなった。原因はWAFだったのか？

凛：時間が近いだけでは、まだ断定できないわ。

策：発生時刻、HTTP応答、WAFとサーバーのログを合わせて確認します。

当時の記録で確認できること、できないこと

筆者の作業記録では、2026年4月30日の夜に記事の一括更新と画像アップロードを進め、22時18分ごろサイトが開けず、22時21分ごろ再び開けました。「2時間で30回以上のPOST」「約3分の停止」はこの記録の数字です。ただし、要求ごとの時刻・応答コード・サーバーログをそろえた原本は確認できていません。そのため、停止時間も件数も運用の普遍的な限界値としては扱いません。

作業記録には「突然504になった」「管理画面にも入れなかった」とあります。原因としてはWAFやサーバーの処理枠の不足も考えられますが、WAFログに一致する遮断記録があり、同時刻の別の原因も除外できたときに初めて、WAFを有力な原因と呼べます。現時点では原因未確定の一時的な障害として記録します。

ConoHa WINGは、コントロールパネルでWAFの遮断ログを確認できると案内しています。当時の障害を調べるなら、同時刻のWAFログとアクセスログ、PHPやWordPressのエラーログ、実行したスクリプトの記録を照合する必要があります。1つのHTTPコードだけで「サーバーが弱い」「WAFが悪い」と決めないでください。ConoHa WING公式：WAFログの確認。

社長：504という表示だけで原因を決めたのがまずかったな。

凛：エラー表示は手掛かり。でも犯人の名前ではないのよ。

策：同じ時刻のログと更新結果を並べ、再現する条件を慎重に確認します。

一括更新で先に守るべき4つの順序

1. 対象記事と変更前データを保存する

更新する記事IDだけでは不十分です。ドメイン、slug、現在の公開状態、タイトル、本文を取得し、変更前のコピーを残します。似た名前の記事や別ブログの記事を誤って更新しないためです。1記事だけを戻す場合の考え方は、記事単位のバックアップ手順にまとめています。バックアップがあることと、戻せることは別なので、復元の経路も事前に決めてください。

2. まず少数件で試して事後GETを行う

1件を更新したら、成功応答だけで済ませず、記事を読み直して期待した本文・状態か確認します。要求がタイムアウトした場合は、書き込みが実際には完了している可能性があります。同じPOSTを無条件に再送すると、画像や本文の重複・想定外の上書きにつながります。結果が不明なときは一度止め、読み取りで現物を照合してください。WordPress公式の記事APIの更新・取得仕様が基本です。

3. サイトに合った処理量を測る

「2秒空ける」「1時間30回まで」のような数字は、全サイト共通の安全値ではありません。画像のサイズ、プラグイン、サーバー契約、同時アクセス、キャッシュなどで負荷は変わります。少数件から始め、応答時間・エラー率・管理画面の動作を見て、処理量を上げるか決めます。画像アップロードと記事更新を同時に大量投入しないのは実務上の予防策ですが、それだけで障害ゼロにはなりません。

4. 異常が出たら新しい書き込みを止める

エラーが連続したときは、原因が分かるまで追加のPOSTを止めます。まずサイトと管理画面が閲覧できるかを確認し、影響が出た記事IDと時刻を控えます。WAFログに一致する記録があるかは確認できますが、WAFをサイト全体で無効化するのを最初の手順にしません。ConoHa WING公式はログ確認と個別の除外設定を案内しています。公式：遮断ログと除外設定。

復旧後は、問題が起きた時刻の前後に更新した記事を一覧にし、変更前のバックアップと公開画面を比べます。エラーが出た要求だけでなく、直前に成功と表示された要求も確認します。一部の処理だけ保存されていた場合、そこから再開すると重複や順番の取り違えが起きるからです。サーバーへの問い合わせが必要なら、発生時刻、対象URL、HTTP応答、再現条件をまとめます。認証情報や読者の個人情報はそのまま相談文に貼らないでください。

社長：タイムアウトしたら、同じ操作をもう一度送ればいいと思っていた。

凛：それが一番怖いところ。先に記事が変わっていないか見よう。

策：応答が途切れても保存済みの可能性があります。GETで現状を確認してから次を判断します。

AIに渡す指示は「止まる条件」まで書く

AIへ「全部更新して」とだけ伝えると、対象範囲と失敗時の扱いが曖昧です。実際に使う前には、次のように範囲を限定します。以下は指示文の想定例で、当時このまま実行したコマンドではありません。

対象サイトと記事slugを先に照合。変更前本文を保存し、最初の1件だけ更新。更新後に記事を再取得し、本文・status・slugを確認する。不一致、タイムアウト、連続エラーが出たら次の書き込みを止め、結果不明と報告する。WAFや認証設定を勝手に変更しない。

一括処理が必要でも、1件を通してから少数件ずつ進めると、どの操作から異常が出たか追いやすくなります。変更内容の検算は、一括置換とAI検算の実例も参考になります。画像だけ403になる場合は、REST API 403の切り分けを別に読んでください。403と504を同じ障害として処理しないことも大事です。

AIに管理を任せるほど、処理した件数、成功・失敗、変更前後の差分を人が確認できる形に残す必要があります。特に公開記事の本文は読者にすぐ届きます。タイムアウト後の再送、誤ったslugへの書き込み、同じ画像の二重アップロードは、後から直すのに時間がかかります。効率化の目標はAPIを速く叩くことではなく、ミスを早く発見して止められることです。

社長：AIへの指示にも「失敗したら止まれ」を入れておく。

凛：それなら、私が後で確認する範囲も分かりやすいわ。

策：対象、バックアップ、1件試行、事後照合、停止条件をひと組みにします。

よくある質問

WAFをオフにすれば更新できる？

遮断がWAF由来だと確認できていない段階では、無効化しないでください。まずログの時刻と対象URLを見ます。ConoHa WING公式は個別の除外設定も案内していますが、防御を弱める変更なので、必要性と影響範囲を確認してから判断します。

何秒の間隔なら安全？

万能な秒数はありません。サイト構成と処理内容で変わります。最初は少数件で応答を観察し、失敗時は停止する設計にします。「30回でWAF」「2秒あれば安全」は、この体験から証明された規則ではありません。

エラーが出た記事をすぐ再送していい？

まず読み取りで現状を確認します。応答は失敗しても、WordPress側では書き込みが終わっている場合があります。予定した変更と一致しているなら再送不要です。一致しない場合も、原因と差分を見てから対処します。

一括更新は、止め方を決めてから始めるのが基本です。たとえば「エラーが1件でも返ったら次へ進まない」「始める前に対象記事の本文を丸ごと保存しておく」「最初の1本だけ反映して、公開ページで見た目を確かめてから残りに進む」の3つを決めておけば、途中でサイトが重くなっても、どこまで反映されたかをあとから確かめられます。急いでいるときほど、1回に動かす本数を減らすほうが、結果的に早く終わります。

まとめ：原因を断定せず、1件ずつ検証する

筆者の記録では、AIに一括更新を任せた夜、サイトが約3分間応答しなくなりました。ただし、この記録だけで「WAFが遮断した」「POST30回が閾値だった」とは言えません。障害時は書き込みを止め、時刻とHTTP応答を控え、サーバー側ログと記事の現物を確認します。普段から対象を絞ってバックアップし、1件ごとに事後GETを行うのが再発時の被害を小さくする方法です。

次に一括更新を計画するなら、最初の1件だけをテスト対象にして、成功時の照合結果と停止条件を書き出してください。記事単位の退避はバックアップ記事、エラーの切り分けは403記事に分けています。このページをサーバー一般の制限値として引用しないでください。