WordPress 7.1時代のAI支援開発を安全に進める：本番へ影響させない実務手順

この記事はWordPress.orgの公開情報を基にした手順解説で、本番サイトでの実機検証報告ではありません。WordPress 7.1「Mary Lou」は2026年8月19日に正式公開されました。AIには調査、変更案、差分説明、テスト補助を任せ、本番の変更は対象と復旧手段を確かめてから承認する前提です。

WordPress公式の7.1リリース告知では、Site Editorのレスポンシブ編集やメディア編集、Abilities APIの整備などが案内されています。新機能が利用できることと、自分のサイトで安全に変更できることは別です。以下では、変更範囲を限定して試す手順に絞ります。

したがって、小規模運営者が先に整えるべきものは「AIに何でも操作させる接続」ではありません。AIが触れてよい対象と、人間の承認が必要な操作を分けた変更工程です。以下では、その工程を本番に影響させない順序へ落とし込みます。

最初に決める3つの境界

対象境界：変更してよいプラグイン、テーマ、設定、投稿IDを列挙する。
操作境界：読み取り、提案、ローカル編集、ステージング反映、本番反映を別の権限として扱う。
合格境界：変更前に、確認する画面、HTTP応答、エラーログ、権限、ロールバック条件を決める。

AIへ「問題を直して」とだけ指示すると、修正範囲と完了条件が曖昧になります。代わりに、「対象ファイル」「変更してはいけない場所」「再現手順」「期待結果」「実行可能なテスト」「本番書き込み禁止」を一つの依頼に含めます。

図1：AI支援変更を本番から分離する承認フロー

対象・禁止事項・合格条件を固定する
バックアップと復旧手順を確認する
隔離環境で再現する
AIに変更案を作らせる
自動・手動検査を行う
人間が差分を承認する
限定反映して監視する
異常時は停止して復旧する

手順1：復旧できる状態を先に作る

WordPress公式ドキュメントは、更新前のバックアップを案内しています。また、サイトのバックアップにはデータベースとファイルの両方があると説明しています。^（2）^（3）

ただし、バックアップファイルが存在するだけでは十分ではありません。保存場所、取得時刻、対象範囲、復元担当者、復元に必要な認証手段を記録し、可能なら本番とは別の環境で復元確認を行います。復元確認をしていない場合は「復旧可能」ではなく「バックアップ取得済み・復元未検証」と記録してください。

手順2：本番と分離した環境でWordPress 7.1を試す

WordPress Playgroundはブラウザ内でWordPressを動かせる隔離環境で、実際のサイトとは分離されています。ただし、恒久的なサーバーではなく、外部サービスへの接続などに制約があります。^（4）

PlaygroundのBlueprintは、WordPressやPHPのバージョン、プラグイン、実行手順をJSONで記述できます。公式ドキュメントでは、JSON Schemaによる検証や、順序が重要な場合に明示的なstepsを使う方法が案内されています。^（5）

本番固有のデータ、ホスティング設定、外部API連携まで確認する必要がある場合は、Playgroundだけで合格とせず、個人情報や秘密情報を適切に処理したステージング環境でも検証します。

手順3：AIへの依頼を「変更契約」にする

表1：AIへ許可する操作の判断表

操作	AIの役割	最終判断
公開情報整理	実行可	人間が出典確認
コード変更	隔離環境のみ	人間が差分承認
本番書き込み	既定で禁止	個別承認

WordPressの権限確認では、ユーザーの役割名ではなく、実行しようとする操作に対応したcapabilityを確認する方法が推奨されています。^（6） AI連携用の処理でも、管理者かどうかという粗い判定だけに依存せず、操作ごとの権限を確認します。

手順4：コードと結果を別々に検査する

入力値は可能なら許可形式に一致するか検証し、それが難しい場合は用途に応じて無害化します。画面へ出力するときは、HTML本文、属性、URLなどの文脈に合う関数で、出力直前にエスケープします。^（7）^（8）

Nonceはリクエスト意図の確認に使えますが、認証や権限確認の代替にはなりません。書き込み処理ではNonce確認とcapability確認を分けて実装します。^（9）

図2：AIが返すべき検査結果の記録テンプレート

変更対象: 記入
禁止対象: 記入
PASS／FAIL／未実施： PHP構文
PASS／FAIL／未実施： capability確認
PASS／FAIL／未実施： nonce確認
PASS／FAIL／未実施： 入出力処理
本番書き込み: 0件
判定: 承認待ち

手順5：小さく反映し、停止条件を監視する

人間が差分を承認した後も、変更を一度に広げないようにします。低トラフィック時間帯の選定、キャッシュ影響の確認、主要ページと管理画面の疎通、PHP・JavaScriptエラー、フォーム送信、ログイン、バックアップ取得処理など、サイト固有の重要導線を監視対象にします。

「エラー率が基準を超えた」「重要導線が失敗した」「ログに新しい致命的エラーが出た」など、停止条件を変更前に数値または観測可能な状態で定義してください。異常時にAIへ追加修正を連続実行させず、まず反映を止め、既知の状態へ戻して原因を切り分けます。

公開・反映前の再現可能チェックリスト

□ WordPress 7.1の現在の公開段階と対象バージョンを記録した
□ 変更対象と変更禁止対象を明記した
□ データベースとファイルのバックアップを確認した
□ 復元の担当者・手順・所要時間を記録した
□ Playground、ローカルまたはステージングで問題を再現した
□ AIが生成した差分を人間が読んだ
□ capability、Nonce、入力処理、出力処理を検査した
□ 未実施テストを未実施のまま記録した
□ 本番反映前のProduction write countが0件である
□ 監視項目、停止条件、ロールバック条件を決めた

まとめ

WordPress 7.1時代のAI支援開発で重要なのは、AIの性能だけではありません。変更できる範囲を狭くし、隔離環境で再現し、検査結果を明示し、人間が差分を承認してから段階的に反映する運用です。利用するAPIの仕様と、自サイトのテーマ・プラグインとの組み合わせを確認してから設計へ組み込んでください。