はじめに
WordPressでテストサイトを作っては壊し、作っては壊し。
WordPressをやっていると、本サーバーやサブドメインにテスト用のWordPressが残り続ける。
今日、夕飯を食べながらふと思った。
「安全に一括削除するできんかなぁ…」
とはいえ「削除」は最もデリケートな操作。
間違えれば本番サイトが消える。
1つのデータベースに複数のWordPressが同居していることもある。
テーブルプレフィックスを間違えたら？
ファイル削除のパスを間違えたら？
考えるだけで背筋が凍る。
ちょっとClaudeの週間リミットが余りそうなこともあって、Claude Code（Anthropicの公式CLI）と、そのサブエージェント機能を使って、このデリケートなプログラムの設計・実装・監査を行った。
結論から言うと、AIサブエージェントを使えば想像以上にコードを確認できる時代が来ている。
そもそも何を作ったの？
作ったのは wp-cleanup.php というPHPファイル1つ。やることはシンプルで
- FTPでWordPressのフォルダにアップロード
- ブラウザでアクセス
- パスワードを入力
- 「このテーブルとファイルを消しますよ」って一覧が出る
- 最終確認でドメイン名を手入力
- 実行すると、対象のデータベーステーブルとWordPressファイルがまとめて削除される
- 最後にスクリプト自身も消える
……と書くと簡単そうだけど、「削除」ってプログラムの中で一番怖い処理なんです。
なぜ怖い？
例えば、レンタルサーバーで1つのデータベースに複数のWordPressを入れてる人、けっこういますよね。「本番は wp_ で、テストは test_ で」みたいに、テーブルの頭文字（プレフィックス）を変えて共存させてるパターン。
ここでテスト用だけ消したいのに、うっかり本番のテーブルまで消えたら……？
取り返しがつかない。
だから、このスクリプトにはいろんな安全装置を付けた。パスワード認証、有効期限（24時間で使えなくなる）、最終確認でドメイン名を打たせる、とか。
作ったのはAI。でも、いきなりコードは書かせない。
ここからが面白いところ。
このスクリプト、設計も実装もAI（Claude Code）にやってもらった。私は「こういうの欲しい」「こうしてほしい」と日本語で伝えて、出てきたものを確認しただけ。コードは1行も書いてない。
ただし、設計ができた時点でいきなりコーディングには入らなかった。
まずは仕様を4体にチェックさせた
Claude Codeには**「サブエージェント」**という仕組みがある。メインのAIとは別に、独立したAIを複数同時に動かせる機能だ。
コードを書く前に、まずこのサブエージェントを4体起動して、設計書（仕様）の段階でレビューをかけた。
「この手順で漏れはない？」「この方式で安全？」「想定してないケースはない？」
コードがまだ存在しない段階でのチェックだから、細かい書き方の話じゃなくて、**「そもそもの考え方に穴がないか」**を見てもらう形になる。
これが結構よかった。仕様の段階で問題を潰しておくと、あとからコードを書き直す「手戻り」が圧倒的に減る。家を建てる前に設計図をチェックしてもらうのと同じだ。
そしてコーディング、そしてまたチェック
仕様レビューのフィードバックを反映した設計をもとに、AIがコーディング。約1,100行のPHPファイルが完成した。
でも、AIが作ったコードをそのまま信用していいのか？
とくに今回は「削除」のプログラムだ。バグがあったら本番サイトを消してしまうかもしれない。
そこで、今度はコードに対してサブエージェントを投入した。
イメージとしては、会社でコードレビューを依頼するときに、セキュリティ担当、品質担当、使いやすさ担当……と別々の人にお願いするのに近い。それをAIがやってくれる。
6体の専門家チームを編成
今回は6体のサブエージェントを同時に起動した。それぞれの担当はこんな感じ：
| 担当 | 何をチェックするか | ざっくり言うと |
|---|---|---|
| PHP互換性 | いろんなバージョンのPHPで動くか | 「古いサーバーでも大丈夫？」 |
| 設定ファイル解析 | wp-config.phpの読み取りは正しいか | 「DB情報をちゃんと読めてる？」 |
| 削除ロジック | ファイルの消し方は安全か | 「余計なもの巻き込まない？」 |
| セキュリティ | 認証やセッション管理に穴はないか | 「悪い人に使われない？」 |
| UX | ユーザーが間違えやすい箇所はないか | 「うっかり事故は起きない？」 |
| コード品質 | 無駄な処理や非効率な箇所はないか | 「ちゃんと動き続ける？」 |
この6体が同時並行でコードを読んで、問題を探す。人間6人にレビューを頼んだら何日もかかるけど、AIなら数分で終わる。
見つかった問題が、思ったよりヤバかった
正直、「まあ細かい指摘がいくつか来るかな」くらいに思ってた。
ところが、致命的な問題がいくつも出てきた。以下、特にゾッとしたものを紹介する。
ゾッとした指摘 その1：「最終確認」が騙せる状態だった
スクリプトの最終確認画面では「本当に消しますか？ドメイン名を入力してください」と聞くようになっていた。例えば test.example.com と入力させて、合っていれば実行する。
ところが、この「正解のドメイン名」をブラウザのリクエストから取得していた。
何が問題かって、ブラウザから送られるドメイン名の情報はいくらでも偽装できるということ。つまり、攻撃者がリクエストを細工すれば、確認画面をすり抜けられてしまう。
修正後は、WordPressのデータベースに保存されているドメイン名（WordPress自身が「自分のドメインはこれ」と認識している値）を使うようにした。これなら外部から書き換えられない。
ゾッとした指摘 その2：消す順番が逆だった
当初の設計では、削除処理の一番最初にスクリプト自身を消していた。「PHPはファイルを消してもメモリ上で動き続けるから大丈夫」という理屈で。
確かにPHPの仕様上は動く。でも、もし途中でエラーが起きたら？
データベースのテーブルは消えた。でもファイルは途中で止まった。なのにスクリプトはもう消えてる。残されたのは中途半端に壊れたWordPress。復旧もやり直しもできない。
修正後はテーブル削除 → ファイル削除 → 最後にスクリプト自身を削除という順番に変えた。もし途中で止まっても、スクリプトが残っているから再実行できる。
ゾッとした指摘 その3：DBパスワードに記号が入ってると動かない
wp-config.phpからデータベースの接続情報を読み取る処理で、パスワードに '（シングルクォート）が含まれているとパースに失敗するケースがあった。
「いや、パスワードにシングルクォートなんて入れる？」って思うかもしれないけど、レンタルサーバーが自動生成するパスワードには記号が含まれることがある。そしてパースに失敗 ＝ DB接続できない ＝ テーブル一覧を取得できないということ。最悪、空のリストが返ってきて「テーブルはありません」と表示される可能性もあった。
ゾッとした指摘 その4：お隣のWordPressを巻き込む危険
WordPressにはちょっと変わった仕様がある。wp-config.phpを1つ上のフォルダに置けるというものだ。セキュリティ対策として使われることがある。
ところが、もし1つ上のフォルダに別のWordPressがインストールされていたら？ そのwp-config.phpを「自分のもの」だと誤認識して、隣のWordPressのDB情報で接続してしまう恐れがあった。
修正後は、親ディレクトリにWordPress本体のファイルがあるかどうかもチェックするようにした。
こんな指摘も出てきた
致命的ではないけど「なるほど」と思った指摘も多かった：
- マルチサイトの検出: WordPressのマルチサイト機能を使っている場合、1つのWordPressを消すと他のサイトも道連れになる。これを検出して警告を出すようにした
- 検索エンジンへの露出防止: 削除スクリプトのURLが万が一Google等に拾われないよう、HTTPヘッダで「インデックスしないで」と伝えるようにした
- エラーメッセージからの情報漏洩: データベースへの接続に失敗したとき、エラーメッセージにサーバー名やユーザー名が含まれていた。攻撃者にヒントを与えてしまうので、あいまいなメッセージに差し替えた
修正して、もう1回チェックさせた
6体のサブエージェントが見つけてくれた問題を、メインのAIに全部直してもらった。14箇所の修正。
ここで終わりにしてもよかったんだけど、ふと思った。
「直したって言うけど、本当にちゃんと直ってるの？」
そこで、もう1回6体のサブエージェントを起動した。今度は「前回あなたが指摘した問題について、修正後のコードを見て、ちゃんと直っているか確認してください」という指示付きで。
つまり、監査→修正→再検証の3ステップ。人間のプロジェクトでもやるダブルチェックを、AIでやったわけだ。
結果
| 件数 | |
|---|---|
| 完全に修正できた | 22件 |
| 一部対応（これ以上は技術的に難しい） | 4件 |
| 未対応（設計判断として許容） | 5件 |
再検証で見つかった細かい問題もさらに4件追加で修正して、最終版が完成した。
結局、私がやったこと
ここまでの流れで、私が実際にやったことを整理してみる：
- 「こういうものが欲しい」 と日本語で伝えた
- AIが出してきた設計案を読んで 「OK、それでいこう」 と言った
- コードを書く前に 「この仕様を4体でチェックして」 と指示した
- フィードバックを反映してからコーディングに入った
- できあがったコードに対して 「6つの視点でチェックして」 と指示した
- 出てきた指摘を読んで 「まっとうな指摘を優先度順に直して」 と言った
- 「直ったか確認して」 と再チェックを指示した
- 「残りの軽微な修正もやって」 と追加指示した
コードは1行も書いていない。プログラミング言語は1文字も打っていない。
それでも最終的に、6つの異なる専門視点で2回チェックされた、約1,100行のコードができた。
これの何が嬉しいの？
「いや、そもそもWordPressの削除スクリプトなんて自分には関係ないし……」と思ったかもしれない。
でもポイントはそこじゃなくて、「プログラムを書けなくても、AIに作らせたコードの品質を、AIにチェックさせることができる」 という事実。
例えばこんな場面を想像してみてほしい：
- functions.phpにカスタムコードを追加したい → AIに書いてもらう → 別のAIに「セキュリティ大丈夫？」とチェックさせる
- プラグインを自作してみた → 「この書き方でWordPressのバージョン上がっても動く？」とAIに聞く
- 外注先から納品されたコード → 「おかしなところない？」とAIに見てもらう
今まで「コードが読めないから品質がわからない」「レビューを頼める人がいない」という状況だった人にとって、AIのサブエージェントはもう1つの選択肢になりうる。
正直に言うと、コストはかかった
今回、6体のサブエージェントを2回動かしたので、APIの利用料金はそれなりにかかった。途中で自分でも「高くついたな……」とつぶやいたくらい。
でも考えてみてほしい。もしこの削除スクリプトにバグがあって、の本番サイトを吹っ飛ばしていたら？ その損害に比べれば、AIのレビュー代なんて誤差みたいなものだ。
「削除」のように取り返しのつかない処理を含むコードには、このくらいの品質チェックをかける価値がある。そしてAIなら、人間の専門家に依頼するよりずっと手軽に、ずっと速くできる。
まとめ
- WordPressの完全削除スクリプトを、AIと一緒に作った
- 「削除」は失敗が許されないから、仕様段階で4体、コード完成後に6体、合計3回のAIチェックを実施した
- 致命的なバグが複数見つかった（ドメイン確認の偽装可能性、削除順序の問題など）
- 監査→修正→再検証の3ステップで品質を確保した
- プログラミングスキルがなくても、AIを使えばコードの品質チェックができる時代になってきた
完成したスクリプトはGitHubで公開しています：
コードを書ける人も書けない人も、AIとの協業はもう「未来の話」じゃなくて「今日からできる話」になっている。削除という一番怖い処理を任せるスクリプトだからこそ、その実感は強い。
この記事は、Claude Code（Anthropic公式CLI）のサブエージェント機能を使った実際の開発・品質チェックの記録です。