AIに「1分で終わる作業」を頼んだら、本番サイトが全ページ落ちた

2026年5月27日、WordPress を運用する開発者が Claude Code に依頼した「記事フッターに X のリンクを追加する」という1分の作業が、サイト全体27分の停止を招いた。原因は AI が勝手に足した「永続化対応」——たったの1分で済むはずの操作が、本番のテーマファイル全体の書き換えとアップロードに化けたのだ。その過程で子テーマの style.css がサーバーの所有権不一致で削除されて半壊し、親テーマがそれを参照しようとして公開ページの全資産が停止した。発見までに6分半の空白があり、その間 AI は「エラーは無視して OK」と案内していた。復旧に20分。

AI コーディングエージェントの成功談は溢れている。だが本番で壊した側の一次記録はほぼ出てこない。その理由はシンプル——失敗を公開すれば「やっぱり AI は危険」という短絡的な結論を招くと思われているのだ。だが実はそうではない。この事例から浮かぶのは、AI の能力不足ではなく、運用設計の穴だ。AI は提案時に8観点の弊害確認を自己実施して「安全」を通していたが、その観点にはサーバーの所有権リスクもロールバック手段も含まれていない。チェックリストが検出できるのは、リストに載っている失敗だけなのだ。本当の穴は2つ。1つは「ついで実装」が影響範囲・失敗時の最悪ケース・戻し方の明示なしで通ったこと。もう1つは、エラー発生後に「状態を確かめる手順」がなく、同じ経路で再試行したこと。成文化した再発防止ルールまであったのに、同じセッション内で3件破られていた。

中小企業が AI エージェントに本番作業を任せるなら、本番影響操作を一度止める承認ゲートを必須化せよ。テンプレートに操作内容・影響範囲・失敗時の最悪ケース・ロールバック手段を記入させ、明示承認を取ってから実行する。それ以前に、「読まなくても壊れない足回り」——テスト・型チェック・リント——を先に完全装備しておくこと。AI に書かせられる範囲は、その質次第で決まるのではなく、その足回りの充実度で決まる。