Claude Logo
コンピューター

WordPress プラグイン削除を Claude Code のスキル化して安全に再現可能にした話

このスキルは、ローカルでプラグインをインストール・アップデートし、本番環境へデプロイすることで発生する問題に対応するために作成した。

WordPress のプラグインを「ちゃんと」削除するのは、実は思ったより手順が多い。一度手でやって覚えてもすぐ忘れるし、手順を間違えると DB 残骸が残ったり、他プラグインを巻き込んだりする。これを Claude Code のスキルとして固めたら、次回からは「/wp-plugin-remove <slug>」一発で安全に削除できるようになった。

実装と思想の記録。

なぜスキル化したか

直前に gutenberg プラグイン（ベータ版・開発者用）と classic-editor プラグイン（未使用）を削除する作業をした。その時の手順がこれ：

  1. プラグインの本体ファイルをリポジトリから削除（git rm）
  2. 翻訳ファイル（code/wp-content/languages/plugins/<slug>-*）も削除
  3. リポジトリのコミット → push → GitHub Actions が rsync で本番から削除
  4. ローカル DB に残った設定オプションを wp option delete で掃除
  5. 本番 DB に残った設定オプションも同様に掃除
  6. サイト健全性確認

ここに落とし穴がいくつもある。

落とし穴 1: 翻訳ファイルを忘れる

code/wp-content/plugins/<slug>/ を消しても、翻訳ファイルは code/wp-content/languages/plugins/<slug>-*.json に別パスで存在する。これを消さないとリポジトリにゴミが残る。

落とし穴 2: 他プラグインの同名ファイルを巻き込む

例えば classic-editor を消そうとして git ls-files | grep classic-editor すると、Jetpack が内部的に持っている jetpack/.../classic-editor.asset.php や classic-editor.js までヒットする。これらは Jetpack の一部なので消してはいけない。

git rm のパスを plugins/classic-editor と languages/plugins/classic-editor-* に厳密に限定する必要がある。

落とし穴 3: uninstall.php が走らないので DB 残骸が残る

git rm でファイルを消すだけだと、WordPress の本来のアンインストールフローを通らない。プラグインが定義している uninstall.php やアンインストールフックは実行されない。

結果、wp_options に残骸が残る。例えば：

  • classic-editor → classic-editor-allow-users, classic-editor-replace
  • gutenberg → gutenberg_version_migration

これは無害だが綺麗じゃない。wp option delete で別途掃除する必要がある。

落とし穴 4: slug の表記揺れで検索漏れ

オプション名はハイフン区切り（classic-editor-replace）とアンダースコア区切り（gutenberg_version_migration）が混在する。検索する時に両方試さないと残骸を見つけ損ねる。

wp option list --search='gutenberg*'
wp option list --search='gutenberg_*'

落とし穴 5: active なプラグインを git rm するとフックが走らない

active なまま消すと、deactivation フックも走らない。先に wp plugin deactivate してから削除する方が綺麗。

これらを毎回思い出すのは現実的じゃない。手順をスキル化して再現可能にすることにした。

Claude Code スキルとは

Claude Code（Anthropic 公式の CLI ベース AI コーディングツール）には「スキル」という再利用可能な指示セットがある。.claude/skills/<name>/SKILL.md に Markdown でやることを書いておくと、/<name> で呼び出せる。

スキルの中身はざっくり：

  • frontmatter（name, description）でいつ呼ばれるかをトリガー定義
  • 本文に手順を書く（Claude が読んで実行する）

つまり「やりたいことを言語で書いたら、それが実行可能なツールになる」というもの。複雑な手順を 1 コマンド化できる。

スキルの設計方針

安全第一の設計

このプラグイン削除スキルは「破壊的操作」を含む。git rm、wp option delete、本番 DB の書き換えが入る。なので以下を守る：

  1. dry-run で対象を表示してからユーザー確認を取る（消す前に必ず一覧確認）
  2. DB 操作の前にバックアップを取る（WP-DBManager の日次とは別に作業直前スナップ）
  3. 本番 DB は「目視で特定した該当オプションだけ」を限定削除（ワイルドカード削除はしない）
  4. 巻き込みチェックを必須化（他プラグイン配下に同名ファイルがないか）

「全自動で消す」スキルじゃなく「手順を1 つずつ追って、危ない所では確認を取る」スキルにした。

9 ステップ構成

実装した手順は以下：

  1. 事前確認：本番でプラグインの status を確認、active なら deactivate
  2. 安全網：本番 DB バックアップを取る（gzip）
  3. dry-run：削除対象の規模と巻き込み有無を表示してユーザー確認
  4. DB 残骸調査：ローカル・本番それぞれで残骸オプションを洗い出し（slug 表記揺れ両対応）
  5. ファイル削除：git rm で本体＋翻訳を削除、staged が削除(D)のみであることを検証
  6. ローカル DB 掃除：手順 4 で特定したオプションを削除＆確認
  7. コミット & デプロイ：commit → push 前にユーザー確認 → push → デプロイ監視
  8. 本番 DB 掃除：手順 4 で特定したオプションを削除＆確認
  9. 検証：サイト健全性、プラグイン残存無し、主要セキュリティ回帰なし

各ステップで前ステップの結果を確認してから次に進む。

引数の柔軟性

スキルは引数あり/なしの両方に対応した：

  • /wp-plugin-remove gutenberg → そのスラグを処理
  • /wp-plugin-remove → wp plugin list を表示して inactive を「削除候補」としてハイライト、対話で選択

「これ消そうかな」と思っている段階でも呼べて、何を消すか決まっていれば直接指定できる。

SKILL.md の構造（抜粋）

---
name: wp-plugin-remove
description: WordPressプラグインをこのプロジェクトの正しい手順で
  安全に削除するスキル。ローカルでファイル削除→GitHub Actionsデプロイ
  →ローカル/本番のDB残骸オプション掃除→サイト健全性検証まで
  一貫実行する。プラグイン削除・除去・アンインストール時に使う。
  停止確認・翻訳ファイル削除・他プラグイン巻き込み防止・dry-run確認の
  安全チェック込み。
---

# wp-plugin-remove

WordPressプラグインを「repo駆動デプロイ＋DB残骸も完全掃除」で
安全に削除するスキル。

このプロジェクトのプラグイン削除は以下の事情で多段階：
- デプロイは `rsync --delete` で `code/` を本番にミラー
  → ファイルはrepoから消すのが正
- `git rm` だけだとプラグインの uninstall.php が走らない
  → DB残骸が残る
- 翻訳ファイル（`code/wp-content/languages/plugins/<slug>-*`）
  も同時に消す必要あり
- Jetpack等が同名ファイルを内包していることがある
  → 巻き込み事故注意

破壊的操作（git rm前 / push前 / DB削除前）の各ポイントで
対象を表示してユーザー確認を取りながら進める。

## 環境前提
...

## 手順
### 手順1：事前確認
...

ポイントは description フィールドに「いつ呼び出されるか」を詳しく書くこと。Claude はこの description を見て「このスキルを使うべきか」を判断する。トリガー語（「削除」「除去」「アンインストール」）を入れておくと、ユーザーが何気なく言った時にもスキルが提案される。

スキルの動作確認

実装後、wp-fastest-cache プラグイン（実在・active）を仮想的な対象として dry-run まで実行してみた。

=== 本体: code/wp-content/plugins/wp-fastest-cache/ ===
3.1M    code/wp-content/plugins/wp-fastest-cache
  追跡ファイル数: 180

=== 翻訳: code/wp-content/languages/plugins/wp-fastest-cache-* ===
         3
    code/wp-content/languages/plugins/wp-fastest-cache-ja.l10n.php
    code/wp-content/languages/plugins/wp-fastest-cache-ja.mo
    code/wp-content/languages/plugins/wp-fastest-cache-ja.po

=== 他プラグイン配下の同名ファイル（巻き込み事故チェック・残るべき） ===
（該当なし）

意図通り：

  • 本体・翻訳とも対象を正しく把握できた
  • 他プラグインへの巻き込みリスクが無いことを確認できた
  • 実際の git rm は走らせていない（dry-run 段階で止めた）

スキル化したことで何が変わったか

1 回コマンドで全手順が安全に再生される

次に不要プラグインを消したくなったら、/wp-plugin-remove <slug> だけで上記 9 ステップが順に進む。各ステップでの確認も自動的に挟まる。

「またあの手順を思い出す」コストがゼロになる

数ヶ月後に同じ作業をする時、絶対に手順を忘れている。スキルがあれば思い出す必要がない。

チーム化した時に再現性がある（個人開発でも未来の自分というチーム）

スキルはリポジトリ内（.claude/skills/）に置けば、他の人（or 未来の自分の別マシン）も同じ手順で実行できる。手順書として README に書くより、実行可能な手順書として残る。

新しい落とし穴を見つけたら追記できる

将来「あの落とし穴も入れておけば良かった」と気づいたら、SKILL.md に追記すればいい。手順のバージョン管理が自然にできる。

「3 回以上やった作業は自動化」よりも前倒しでスキル化していい

「3 回以上やった作業は自動化を検討」というのが昔からの定石だけど、Claude Code のスキルは 3 回未満でも安全性が必要なら作る価値がある。今回のプラグイン削除は実質 2 回目だったが、落とし穴の数を考えるとスキル化して正解だった。

まとめ

  • WordPress プラグイン削除は手順が多く、落とし穴が複数ある
  • Claude Code のスキル化で「言語で書いた手順を実行可能な 1 コマンド」にできる
  • 破壊的操作を含むスキルは「dry-run + ユーザー確認 + バックアップ」を組み込む
  • スキルはリポジトリで管理できるので、未来の自分が救われる

「やったことのある作業を 2 度とゼロから思い出さなくていい」という体験は、思った以上に精神衛生に良い。

Home » コンピューター » WordPress プラグイン削除を Claude Code のスキル化して安全に再現可能にした話

WordPressのソースコード管理にBitbucketを使う WordPressのソースコード管理にBitbucketを使う2 WordPressのログインページのURLを変更する BitbucketからAWS EC2にリポジトリをクローン AWS EC2のサーバーにApacheをインストール AWS EC2のサーバーにMySQLをインストール