顧客のWordPressサイトをAIで管理・監視する環境を作る方法｜初心者向け導入手順【実践編】

WordPressサイトを複数管理していると、「更新できているか」「サイトが止まっていないか」「記事や設定を安全に確認・変更できるか」を毎回それぞれの管理画面で確認するのは大きな負担になります。

そこで今回は、実際のWordPressサイトを使って、中央の管理環境から顧客サイトを安全に管理・監視できる状態まで設定した手順を、初心者向けに順番に解説します。

重要：この記事ではパスワードや秘密鍵などの認証情報は掲載しません。実際の運用でも、認証情報を記事・チャット・共有資料へそのまま貼り付けないことが基本です。

H2-1　今回作った「顧客サイト管理・監視環境」とは

今回の目的は、AIにWordPressを好き勝手に操作させることではありません。中央の管理環境から、顧客サイトの状態を確認し、必要な操作だけを安全な手順で実行できる仕組みを作ることです。

• サイトが正常に応答しているか確認する
• WordPressやPHPなどの基本情報を確認する
• プラグインや記事などを読み取る
• 必要な変更を準備する
• 人が内容を確認・承認してから変更する
• 変更後にもう一度読み取り、正しく反映されたか検証する

今回の実証では、実際に運用中のサイトを1サイト選び、接続・READ・承認付きWRITE・変更後の検証まで一通り確認しました。

H2-2　作業を始める前に確認するもの

H3-1　WordPressとPHPのバージョンを確認する

最初にWordPress本体とPHPのバージョンを確認します。特にPHPは重要です。新しいプラグインが古いPHPでは動作しないことがあるため、先に確認しておくと「インストールできたのに有効化できない」という事故を減らせます。

今回の実証サイトはPHP 7.4系だったため、PHP 7.4互換版の管理プラグインを使用しました。PHP 8系のサイトと同じファイルを無条件に配布しないことがポイントです。

H3-2　バックアップと管理者権限を確認する

本番サイトを扱う場合は、作業前にバックアップの有無を確認します。また、プラグイン追加やApplication Passwordの発行には管理者権限が必要です。

H2-3　管理に必要なプラグインを準備する

今回の構成では、中央管理側と顧客サイト側に役割を分けています。顧客サイト側には、接続・安全な操作・スニペット管理などを担当する管理用プラグインを配置します。

H3-1　依存プラグインを先に確認する

ここは今回、実際につまずいたポイントです。管理プラグインを先に有効化しようとしても、必要な依存プラグインが入っていないと正常に動きませんでした。

そのため「本体を入れる→エラーを見る」ではなく、依存関係を確認→必要なプラグインを導入→管理プラグインを有効化の順にします。

H3-2　今回使用した4つの管理コンポーネント

今回の実証では、次の4つを顧客サイト側の基本構成として使用しました。

1. Code Snippets：スニペットを保存・実行する土台。
2. APICE Deployment Bootstrap：管理環境を導入・更新するときの入口となる仕組み。
3. APICE Ability Manager：AIから利用するREAD・WRITE機能、安全確認、承認フローなどを管理する層。
4. APICE WordPress Control：WordPressサイトを管理環境から扱うための制御・接続を補助する層。

Code SnippetsそのものをAPICE製プラグインへ置き換えるのではありません。Code Snippets＝実行・保存基盤、APICE側＝安全な管理・運用層と役割を分けています。

H3-3　導入は依存関係を考えて順番に行う

初心者が迷わないよう、基本的には「環境確認 → Code Snippets確認・有効化 → Bootstrap導入 → Ability Manager導入・有効化 → WordPress Control導入・有効化 → Health確認」の順で進めます。

ただし、PHP 7.4など古いPHPを使用しているサイトでは互換版が必要になる場合があります。別サイトで動いたZIPをそのまま入れるのではなく、先にPHPバージョンを確認してください。

H2-4　Application Passwordで安全に接続する

外部の管理環境からWordPressへ接続するときは、通常のログインパスワードを共有するのではなく、WordPressのApplication Passwordを利用します。

H3-1　Application Passwordを発行する

1. WordPress管理画面へログインします。
2. ユーザーのプロフィール画面を開きます。
3. Application Passwordの欄を確認します。
4. 管理用途が分かる名前を付けて発行します。
5. 中央管理環境側の安全な認証設定へ登録します。

発行された文字列はパスワードと同じ機密情報です。公開記事や作業メモへ記載しないでください。

H3-2　Basic認証・HTTP Authとの競合に注意する

今回の実証では、サイト側のHTTP Auth設定がApplication Password認証と干渉しました。Application Passwordの設定画面が期待どおりに出ない場合は、Basic認証やHTTP Auth系の設定・プラグインを確認します。

ただし、セキュリティ目的で設定されているBasic認証を理由なく解除してはいけません。運用責任者と確認し、代替の防御方法も含めて判断します。

H2-5　中央管理環境へ顧客サイトを登録する

次に中央管理環境のサイト台帳へ、管理対象サイトを登録します。最低限、サイトを識別する名前、WordPressのURL、環境区分（本番・開発など）、認証方式を管理します。

ここで大切なのは、AIがURLを推測して接続するのではなく、登録済みの管理対象サイトだけを操作できる構造にすることです。

H2-6　最初はWRITEせずREADで接続確認する

接続した直後に記事を書き換えたり、プラグインを更新したりしてはいけません。最初はREADだけで確認します。

• サイト情報を取得できるか
• HTTP 200で応答するか
• WordPressのバージョンを取得できるか
• プラグイン一覧を取得できるか
• テーマ情報を取得できるか
• 記事数・固定ページ数などを取得できるか
• robots.txtやサイトマップが正常に取得できるか

今回の実証でも、まずHealth Probeと各種READを行い、正常に接続できることを確認してからWRITE試験へ進みました。

H2-7　WRITEは「準備→人の承認→実行→再確認」にする

顧客サイト管理で最も重要なのがWRITEの安全設計です。AIが判断した瞬間に本番サイトを書き換える構成にはしません。

今回採用した基本フローは次の4段階です。

1. Prepare：何を変更するのかを準備する
2. Approval：人間が変更内容を確認して承認する
3. Execute：承認済みの変更だけを実行する
4. Verify：変更後に再READし、結果を検証する

実証では、テスト用スニペットを「無効」の状態で作成し、作成結果まで再確認しました。これにより、本番環境でコードが突然実行されることなくWRITE経路を試験できます。

H2-8　管理開始前の最終チェックリスト

• □ WordPress・PHPバージョンを確認した
• □ PHPに合った管理プラグインを使用している
• □ 必要な依存プラグインが揃っている
• □ Application Passwordで認証できる
• □ READでサイト情報を取得できる
• □ HealthチェックがHTTP 200になる
• □ robots.txt・サイトマップを確認できる
• □ WRITEに人間の承認工程がある
• □ WRITE後に再READして検証できる
• □ 認証情報を記事や共有メモへ残していない

H2-9　どこまで確認できれば「環境設定完了」なのか

プラグインを入れただけでは完了ではありません。今回の実証では、次の4段階をすべて通過した時点を「顧客サイト管理・監視環境の設定完了」としました。

1. Health：サイトが正常に応答し、Health ProbeがHTTP 200になる。
2. READ：中央管理環境からサイト情報、プラグイン、記事などを読み取れる。
3. SAFE WRITE：変更内容をPrepareし、人間の承認後にテスト変更を実行できる。
4. VERIFY：変更後に再READし、意図した結果になったことを確認できる。

この4つが通れば、日常の管理・監視を開始できる状態です。一部の高度な機能に未対応や互換性課題が残っていても、Health・基本READ・安全なWRITE・Verifyが成立しているかを分けて判断します。

H2-10　今回実際に起きたトラブルと対処法

H3-1　管理プラグインを有効化できない

依存プラグイン不足を確認します。今回もCode Snippetsを先に有効化することで先へ進めました。

H3-2　Application Passwordがうまく使えない

HTTP AuthやBasic認証との競合、WordPress側のHTTPS設定、ユーザー権限を確認します。

H3-3　同じプラグインなのに別サイトで動かない

PHPバージョン差を確認します。特に古いPHPを使っている顧客サイトでは、互換版が必要になる場合があります。

H3-4　一部の管理機能だけエラーになる

「接続全体が壊れている」と決めつけず、Health、サイト情報、記事READなどを個別に確認します。一部機能だけが互換性や登録方法の問題で失敗している場合があります。

H2-11　この仕組みを顧客サイト管理へ広げる

1サイトで接続できただけでは、顧客サイト管理サービスとはいえません。今後はこの手順を標準化し、新しい顧客サイトでも同じチェックリストで導入できるようにします。

• 死活監視・Healthチェック
• WordPress・PHP・プラグインの状態確認
• サイトマップ・robots.txtの確認
• 記事やSEO設定の確認
• 安全な承認付き変更
• 変更履歴・作業履歴の記録
• 異常時の通知と対応フロー

重要なのは「AIに操作させること」ではなく、AIが状況を確認し、人が必要な判断を行い、承認された操作だけを安全に実行できる運用基盤を作ることです。

H2-12　まとめ

顧客のWordPressサイトをAIで管理・監視する場合は、いきなり自動化を目指すより、①環境確認、②必要プラグインの準備、③安全な認証、④READ確認、⑤承認付きWRITE、⑥再READによる検証、という順番で構築するのが安全です。

今回の実証では、この一連の流れを実際の運用サイトで確認できました。今後はこの構成を標準手順として整理し、複数の顧客サイトを同じ考え方で管理・監視できる仕組みへ発展させていきます。