AIでWordPressサイトを実装するときの使い方

AIでWordPressを実装するときは、コードを書く前に既存のtheme、plugin、block、build環境を確認し、変更するlayerと機能範囲を決めます。AI生成のPHPやJavaScriptが動いても、WordPressの権限、nonce、入力検証、出力escape、更新耐性に合うとは限りません。WordPressの公式APIと既存projectの規則を使い、小さな差分で検証してください。

最初にサイトの構成と編集可能な範囲を確認する

管理者や開発担当から、WordPressとPHPのversion、theme、子theme、使用plugin、custom post type、block editor、build tool、staging有無を確認します。既存の変更がどこにあるか分からなければ、コードを生成する前にrepositoryや管理画面で調べます。AIにサイト全体の新しい構成を選ばせたり、既存pluginを交換させたりしません。

要求を画面・データ・操作に分けます。例えば投稿一覧の絞り込みなら、対象投稿型、query条件、権限、URL、件数、0件表示、管理画面かpublicかを決めます。「一覧を便利にする」だけでは仕様が不足しています。曖昧な前提をAIが勝手に埋めたら、実装ではなく確認事項として残します。

変更するlayerを選び、Coreを直接改変しない

WordPress本体のファイルを書き換えると、更新で変更が消えたり、保守できなくなる可能性があります。機能追加・表示変更の責務に応じて、theme、child theme、plugin、block、template等の適切な場所を選びます。どこに入れるかは既存サイトの設計と運用を確認して決めます。既存plugin内の機能を直す場合、vendor codeか自作コードかも見分けます。

変更前には、対象ファイル、影響するroute、管理画面とpublicの差、依存先を一覧にします。AIへは「変更可能な場所」と「触れないファイル」を明示し、必要な差分だけを作らせます。独自のautoload、build script、npm packageを加えるなら理由と更新方法を確認します。既存の配置場所が不明な場合、生成されたコードを適当にfunctions.phpへ追加せず、サイト担当者に確認します。

WordPress APIとsecurityの境界を守る

ユーザー入力、URL parameter、form、REST requestなどは信用せず、目的に応じて検証・sanitizeします。出力するときはHTML、attribute、URLなどのcontextに合ったescapeを行います。WordPress Developer Resourcesは、入力をsanitize / validateし、出力を適切にescapeする考え方を案内しています。AIに関数名を出させた場合も、実際の入力・出力のcontextに合っているか公式資料で確かめてください。

表は横にスクロールできます

操作	確認すること	省略した場合の問題
入力	型、許容値、長さ、欠損	想定外の値が保存・処理される
権限	対象actionに必要なcapability	権限のない利用者が実行
nonce	requestが意図した操作か	CSRF対策の不足
保存	validate / sanitizeの順	不正形式のデータを保持
表示	文脈に合うescape	HTML / attributeへの混入
DB query	WordPress APIや準備済みquery	injectionや誤検索

nonceだけで認証・認可の代わりにはなりません。データの変更前に利用者のcapabilityを確認し、requestの検証、保存時の型、表示時のescapeをそれぞれ行います。REST APIなら公開範囲、permission callback、返すfieldを確認します。client側で入力制御をしても、server側の検証を省略しないでください。

既存データとAPI契約から実装を組み立てる

投稿、taxonomy、meta、option、user等のどの保存領域が正本か確認します。既存schemaやqueryを読まずに同じ値を別metaへ保存すると、表示と編集が分裂します。使うWordPress関数、hook、query、block APIを公式資料とprojectのversionに合わせます。SQLを直接書く必要がある場合は、対象DB、準備済みquery、権限、更新範囲を確認し、独自queryの必要性を説明できる場合に限定します。

依頼例：

「このrepositoryで使われているWordPress/PHP version、既存の投稿型、権限確認、nonce、sanitize/escape patternを先に探してください。投稿一覧にstatus filterを追加します。既存queryとUIを維持し、core file、vendor plugin、DB schemaは変更しないでください。実装前に変更ファイルと入力値の契約を示し、候補差分を小さく作成。通常値・不正値・権限なし・0件の確認を追加し、既存のlint/test/buildを実行してください。不足情報があればコードを書かずに列挙してください。」

これは依頼の例で、実際のsite仕様や権限を定めるものではありません。AIが読み込んだ既存コードと、実際の変更が合っているかをレビューします。

PHP・JavaScript・blockの差分を小さくする

機能ごとに、hook、template、block、REST endpointなど必要な場所を分けます。一度にPHP、CSS、JavaScript、DB更新を混在させず、各差分の役割を確認します。WordPress Coding Standardsに合わせた書式や命名も、既存projectの規則を優先します。共有する関数に副作用がないか、hookが重複登録されないか、theme変更時に機能が失われないかを確認します。

AIが作るコードに直接本番データを更新させず、まずstagingやローカルの複製で試します。activation hookやmigrationが必要な場合は、再実行時の安全性、失敗時の復旧、既存データとの互換性を別に確認します。広範なschema変更や大量データ更新は、ここで即興に行わず、専用のmigration設計とGateへ分けます。

機能を利用者の操作でQAする

型やlintだけでは、ログイン状態、権限、nonce、フォーム送信、管理画面とpublic画面の違いは確認しきれません。実際の操作に沿って、ログイン前、権限なし、権限あり、正常入力、不正入力、0件、保存後の再表示を確認します。表示メッセージが内部情報や個人情報を出しすぎないかも見ます。

表は横にスクロールできます

ケース	期待する動作
未ログイン	公開仕様にない管理操作は拒否
権限不足	更新せず、適切な応答を返す
nonce不正	変更を拒否
正常入力	保存し、再表示が一致
不正値	適切なvalidation error
二重送信	重複登録・二重処理を防止
update後	PHP/WordPress更新で壊れないか確認

ブラウザでconsole、network、フォームのerror、mobile表示も調べます。実データが必要なテストは、利用許可のあるstagingデータを使います。実装者が試していないケースを「確認済み」と書かず、範囲を記録します。

AIものさしの判断

WordPressでAIを使うなら、コードの生成速度より、既存構成への適合と安全な入力・権限・出力の扱いが重要です。対象のlayer、API、受け入れ条件が分かり、小さな差分をstagingで確認できるなら、AIを下書きと反復作業に使えます。既存データの保存先、権限、migration、core/pluginの所有者が不明なら、コードを増やす前にその責任者へ確認してください。

失敗時は層ごとに切り分ける

画面に値が出ない場合は、保存処理、query、template、権限条件、cacheの順に確認します。form submit後に変化がない場合は、browser network、server response、nonce、validation messageを見ます。403やpermission errorを隠すためにcheckを外すのではなく、利用者の権限と要求されたactionの設計を確認します。問題の範囲を小さくし、最後に変更した差分から追うと、既存機能への影響を見つけやすくなります。

表は横にスクロールできます

症状	確認先	安全な対応
管理画面だけ動かない	capability、nonce、admin hook	権限契約とrequestを確認
表示が古い	cache、query、保存値	cacheだけでなくsource dataも確認
保存値が崩れる	sanitize、型、DB/API	元値と期待値を比較し再保存を止める
表示にmarkupが混ざる	output contextとescape	context適合のescapeを確認
update後に消える	変更layer、vendor/core編集	正しい拡張layerへ移す案を検討

引き継ぎと保守のための記録

AI生成コードを採用する前に、変更目的、対象hook/API、受け入れ条件、確認したWordPress/PHP version、実行したtestをレビュー記録へ残します。特にsecurityやdata changeでは、誰が承認し、stagingで何を試したかを明記します。将来の担当者がコードの意味を読めるよう、コメントは処理の理由や制約を説明し、コードの各行を言い換えるだけの注釈を増やさないようにします。

本番反映後も、WordPress、PHP、theme、pluginの更新前に互換性を確認します。更新手順やrollback方法が決まっていない機能は、公開完了として扱いません。