AIが作ったWordPress変更をPlaygroundで安全に検証する手順

AIが作ったWordPress変更をPlaygroundで安全に検証する手順:記事内容を表したイメージ(実物製品の写真ではありません)

公式情報+WORK EDITローカル隔離試験 / 2026年7月18日確認

AIに作らせたプラグインやテーマ変更を、本番へ入れてよいか迷っている小規模サイト運営者向けです。

標準結論:Playgroundだけで本番反映を決めない。 有効化と表示を確かめる第一ゲートにし、合格した変更だけをステージングと復元確認へ送ります。

  • 分かること:TEST/DEFER/REJECTの判断基準
  • 最大の注意点:本番サーバーとの環境差
  • 読む価値:同一条件の実測表と再利用できる6項目チェックリスト

本番前の判定チェックリストへ移動同じ記事内のTEST/DEFER/REJECT表を確認します

先に決める:Playgroundは第一ゲートであって本番許可ではない

WordPress公式は、Playgroundでプラグインやテーマを試し、WordPressとPHPの対象バージョンを変えられると案内しています。Blueprintを使えば、バージョンや有効化手順をJSONで記録できます。つまり「自分の画面で一度動いた」ではなく、同じ条件をもう一度作れるのが利点です。

ただし、ここで得られるのは隔離環境の証拠です。AIが生成したコードは、依頼していない外部通信、広すぎる権限、削除処理、環境依存のSQLを含む可能性があります。有効化できたという一点だけでは、これらを否定できません。

編集命題:Playgroundで再現可能な有効化・表示検査を通し、環境差・権限・バックアップ・復元の証拠が不足する変更は本番へ入れません。読者が決めるのは「安全かどうか」ではなく、「次の検証段階へ進めるだけの証拠があるか」です。

今回の検証条件と2回の結果

WORK EDITでは、外部通信を切ったWordPress Playground CLI 3.1.44へ無害なテスト用プラグインをmountし、同じ条件で2回起動しました。fixtureはフッターへ識別用の文字列を出すだけで、資格情報、本番URL、staging URLを使いません。

項目 1回目 2回目 判断
WordPress 7.0.2 7.0.2 条件一致
PHP 8.3 8.3 条件一致
プラグイン有効 true true PASS
フロント応答 200 200 PASS
表示marker 確認 確認 PASS
外部通信 無効 無効 PASS

この結果から言えるのは、記録したfixtureが、このPlayground条件で2回とも有効化され、公開画面へmarkerを出したことです。本番サーバー、MySQL、実権限、メール、cron、外部API、性能、rollbackまで合格したとは言えません。

追試用の条件記録

記事だけで追試条件が分かるよう、実行条件を固定します。@wp-playground/cli 3.1.44、PHP 8.3、WordPressは検証日時点のlatest(実測7.0.2)、networking=false、fixtureのSHA-256(UTF-8・末尾改行を含む)は3042e1e37041c0bee112d6dc31a542715a4309ebbbd3aa35c28588ecca97e1e0です。

検証用プラグインは、以下の文字列から復元できる形で掲載します。次のコマンドは記事内の文字列を復号し、検証に使ったものと同じバイト列のPHPファイルを作ります。復号後は上記SHA-256を照合し、本番ではなく検証用WordPressで試してください。

python3 -c "import base64,pathlib; pathlib.Path('work-edit-ai-change-preflight.php').write_bytes(base64.b64decode('PD9waHAKLyogUGx1Z2luIE5hbWU6IFdPUksgRURJVCBBSSBDaGFuZ2UgUHJlZmxpZ2h0IEZpeHR1cmUgKi8KYWRkX2FjdGlvbiggJ3dwX2Zvb3RlcicsIGZ1bmN0aW9uICgpIHsKICAgIGVjaG8gJzxkaXYgaWQ9IndvcmstZWRpdC1haS1jaGFuZ2UtcHJlZmxpZ2h0Ij5QbGF5Z3JvdW5kIHByZWZsaWdodCBmaXh0dXJlIGFjdGl2ZTwvZGl2Pic7Cn0gKTsK'))"

fixtureディレクトリを/wordpress/wp-content/plugins/work-edit-ai-change-preflightへmountし、BlueprintのactivatePluginでwork-edit-ai-change-preflight.phpを有効化します。2回とも次の4項目を保存します。

front_status, plugin_active, marker_visible, WordPress/PHP version
200, true, true, 7.0.2/8.3

コードと条件を変えず2回実行し、1項目でも違えばTESTにせずDEFERにします。これは追試可能な最小例であり、実運用コードを安全と判定するテンプレートではありません。

6つのゲートでTEST/DEFER/REJECTを決める

上から順に確認し、ひとつでも「証拠なし」なら本番へ進めません。Playgroundで確認できない項目は、同等構成のステージングへ送ります。

ゲート 残す証拠 TEST DEFER REJECT
変更差分 変更ファイルと目的 必要な差分だけ 説明不足 無関係な権限・外部送信・難読化を含む
隔離 本番URL・資格情報を使っていない記録 完全分離 分離を確認できない 本番へ直接接続する設計
有効化 PHP fatal 0、plugin active 再現して合格 依存不足で未確認 fatalまたは意図しない出力
主要表示 対象画面、Console、Network 期待結果と一致 実データが必要 管理画面・REST・公開画面を破壊
環境差 PHP、WordPress、DB、サーバー機能 差の影響なし MySQL・cron・メール・外部APIをstagingで確認 必要条件を再現できない
復元 backup、rollback手順、復元確認 戻せる 復元未確認 不可逆または完全削除が前提

最終ルール:すべてTESTなら「ステージングへ進める」。DEFERが1つでもあれば証拠を補い、REJECTが1つでもあれば変更を本番候補から外します。

Playgroundでは結論を出せない変更

最大の欠点は環境差です。MySQL固有のSQL、cron、メール、外部API、Webhook、支払い、ファイル権限、サーバー設定、実ユーザー権限、高負荷性能、不可逆なデータ変更のどれかに当てはまるなら、Playgroundの合格だけで判断せずDEFERにします。

代替は、同等構成のローカルWordPressまたはnoindexのステージングです。WordPress公式のE2E例はwp-envとPlaywrightを使い、プラグインやテーマを入れた環境で公開画面まで確認しています。Playgroundと競合する手段ではなく、確認範囲を広げる次工程です。

3段階で進める実行手順

  1. 差分を読む。 AIへの依頼内容と変更ファイルを照合します。新しい外部送信、権限追加、削除、難読化があれば、動かす前にREJECTまたは人間確認へ送ります。
  2. Playgroundで再現する。 本番資格情報を渡さず、WordPress/PHPバージョン、プラグイン、テーマ、テスト内容を記録します。有効化、対象画面、REST、Console、Network、PHPエラーを確認します。
  3. ステージングと復元へ送る。 TESTになった変更だけを同等環境へ入れ、バックアップ、Canary、主要画面、rollbackを確認します。書き込みゲートが閉じている、またはEmergency Stopが有効なら開始しません。

向いている人・向いていない人

向いている人

  • AI支援で小さなWordPressプラグインやテーマ変更を作る人
  • 無料の隔離環境で差分を絞りたい人
  • Blueprint、チェックリスト、ログを残して再現性を上げたい人

向いていない人

  • Playgroundの合格だけで無人の本番反映を許可したい人
  • 実サーバー固有の性能、メール、cron、MySQL挙動まで一度に保証したい人
  • バックアップやrollbackを用意しない人

結論が変わる条件

標準結論は「Playgroundだけで本番反映を決めない」です。表示だけで完結し、外部通信、永続データ、cron、メール、サーバー固有機能、権限変更を使わない小さな変更なら、Playgroundの結果に置く比重は上げられます。それでも差分レビューと復元準備は残します。

実データやサーバー機能へ触れる変更は、Playgroundで動いてもDEFERです。同等環境のステージングで条件を再現し、rollbackまで通過したときにだけ本番候補へ進めます。

次に行うこと

本番前の判定チェックリストをもう一度確認TEST/DEFER/REJECTを1つ選びます

TESTになった変更は、ステージング環境が必要な理由とバックアップの復元確認へ進んでください。AI自動化全体の停止条件はWordPress自動化で最初に用意すべき安全対策で確認できます。

出典

  1. WordPress Playground: Test
  2. Blueprint data format
  3. Troubleshoot and debug Blueprints
  4. Programmatic Usage of Playground CLI
  5. Getting started writing WordPress E2E Tests with Playwright
  6. WordPress Playground for Everyone