Niriakot Inc.

AIとITのコンサルティング

ジャービス計画 第四十四話:EC-CUBEとWordPressの運用担当をAIエージェントにする

EC-CUBEとWordPressの二つの運用卓をAIエージェントが点検し、人間が承認する卓上ミニチュア

J.A.R.V.I.S.計画 第四十四話

EC-CUBEとWordPressの運用担当をAIエージェントにする

更新候補の確認、投稿・商品情報の点検、障害検知、変更前バックアップ、人間承認、実行後のread-backまで。二つのWeb基盤を安全に運用する仕事を、一つの流れとして整理します。

1. EC-CUBEとWordPressの運用担当に必要な仕事を分解する

WordPressは記事・固定ページ・メディアを管理し、EC-CUBEは商品・価格・在庫・注文導線を支えます。担当者が見ている画面は違っても、安全な運用に必要な仕事は共通しています。現在状態を読み、変更候補を分け、影響を確認し、変更前に戻れる状態を作り、実行後に管理画面と公開画面を読み直すことです。

AIエージェントへ任せる時も、この順序は変わりません。むしろ、AIが操作できる範囲を広げるほど、「確認」と「変更」、「更新候補」と「更新承認」、「処理成功」と「公開画面の正常」を明確に分ける必要があります。

工程 AIエージェント 人間
確認・点検 版、公開状態、リンク、ログ、HTTP応答を収集して差分化 業務上の優先順位と許容停止時間を決める
変更前 対象、影響、バックアップ、検証、切戻しを整理 変更範囲と実行時刻を承認する
実行後 管理画面、公開画面、主要導線、ログをread-back 業務上の受入れと次工程を判断する

2. 実際の管理画面で現在状態と更新候補を分ける

2026年8月21日09:55 JST、認可済み環境のWordPress管理画面を読み取りで確認しました。公開用画像ではサイト名、ユーザー情報、最近の投稿などを不可逆マスクしています。画面下部からWordPress 7.1であることを確認できますが、現在版を確認できたことと、更新を実行してよいことは別です。

2026年8月21日に取得し、サイト名・ユーザー情報・投稿情報を公開用にマスクしたWordPress管理画面
WordPressの実管理画面。版情報は確認済み、サイト名・利用者情報・投稿内容は公開用にマスク済みです。

WordPressでは本体・テーマ・プラグインを別々に記録します。EC-CUBEでは本体、プラグイン、PHP、Composer依存関係、決済や配送など業務影響の大きい連携を分けます。更新候補が表示された場合、AIはすぐに更新ボタンを押すのではなく、互換性、変更履歴、バックアップ、停止時間、検証項目を先にそろえます。

「更新があります」は事実です。「今すぐ更新してよい」は承認です。AI運用では、この二つを同じ扱いにしません。

3. 投稿・商品情報をAIエージェントが点検する

WordPressでは、投稿と固定ページの公開状態、タイトル、抜粋、アイキャッチ、本文画像、内部リンク、canonical、noindex、メディアの代替テキストを点検します。EC-CUBEでは、商品名、公開状態、販売価格、在庫表示、商品画像、カテゴリ、カートまでの主要導線を点検します。

ここで重要なのは、AIに必要以上の情報を見せないことです。注文、会員、住所、電話番号、メールアドレス、決済情報は、商品表示や更新状態の点検には不要です。操作用アカウントも、読み取り対象と変更対象を分け、記事素材には個人情報を含まない画面だけを使います。

対象 確認項目 除外する情報
WordPress 投稿、固定ページ、画像、リンク、公開状態、SEO設定 ユーザー名、認証情報、非公開原稿、内部URL
EC-CUBE 商品、価格、在庫表示、画像、カテゴリ、購入導線 注文、会員、住所、メール、決済・配送の個人情報

4. 警告・ログ・公開画面から障害を検知する

管理画面の警告だけで障害を確定すると、正常な一時状態や更新案内まで緊急障害として扱ってしまいます。AIエージェントは、管理画面、アプリケーションログ、Webサーバーログ、HTTP応答、主要導線を照合し、現在も再現するか、利用者へ影響しているかを確認します。

  • 異常確定:現在も再現し、影響範囲と根拠を確認できた状態。
  • 要注意:警告や失敗履歴はあるが、公開画面や業務影響の追加確認が必要な状態。
  • 未確認:権限、画面、ログ、再現条件のいずれかが不足し、判断材料がそろっていない状態。

今回のEC-CUBE素材確認では、実際の管理画面の認証境界までは確認できましたが、管理画面内への認証は成立しませんでした。同じ方法で二度失敗したため再試行を止め、入力欄を不可逆マスクした画面だけを記録しています。商品・更新状態を確認済みとは書きません。

2026年8月21日に確認し、入力内容を公開用にマスクしたEC-CUBE管理画面の認証境界
EC-CUBEの実管理画面の認証境界。入力内容は公開用にマスク済み。管理画面内の商品・更新状態は未確認です。

認証に失敗した時、資格情報を推測して繰り返すのではなく、失敗回数を固定して停止し、正しい管理用認証情報または安全な試験環境を確認します。

5. 変更前バックアップと切戻し条件をそろえる

WordPressの変更前には、対象ファイル、データベース、アップロード画像、テーマ・プラグイン設定、現在版をそろえます。EC-CUBEでは、アプリケーション、データベース、Composer情報、環境設定、プラグイン、カスタマイズ、商品画像、決済・配送連携の設定を対象ごとに整理します。

バックアップ取得とバックアップ検証は別工程です。ファイルが作成されたことに加え、保存先、サイズ、ハッシュ、世代、読取り可否を確認します。切戻しでは、何を戻すか、データベースとファイルの時点をどう合わせるか、注文や投稿など作業中に増えたデータをどう扱うかを先に決めます。

確認 取得 検証 切戻し
対象・現在版 ファイル・DB・設定 ハッシュ・一覧・復元性 順序・停止条件・データ差分

6. 人間承認後にだけ変更を実行する

AIエージェントは、変更対象、目的、現在値、更新内容、影響、停止見込み、検証方法、切戻し方法を一つの計画にまとめます。人間はその計画を見て、範囲と時刻を承認します。承認後も、AIは承認された対象だけを一工程ずつ実行し、対象外へ広げません。

EC-CUBEとWordPressの更新確認から人間承認、変更実行、read-backまでを示す責任分界図
AIは確認・整理を担当し、変更は人間承認後だけ実行。完了判定は実行後のread-backまで含みます。

更新ボタンを押せる権限があっても、自動で押してよいとは限りません。技術上の権限と、業務上の承認を分けます。

7. 実行後に管理画面と公開画面をread-backする

コマンドやAPIが正常終了しても、利用者が見るページが正常とは限りません。WordPressでは管理画面、記事・固定ページ、画像、内部リンク、問い合わせ導線、canonical、noindex、sitemapを確認します。EC-CUBEでは管理画面、商品一覧、商品詳細、価格、在庫表示、画像、カート、主要導線、ログ、HTTP応答を確認します。

  1. 管理画面:新しい版、更新残件、警告、設定値を読み戻す。
  2. 公開画面:代表ページを実際に開き、表示・画像・リンクを確認する。
  3. ログと応答:HTTP状態、アプリ・Webサーバー・PHP・DBの異常を照合する。
  4. 差分報告:変更前後、確認済み事実、未確認点、残件を短くまとめる。

この一連の工程がそろって初めて、「更新しました」ではなく「業務上の確認まで完了しました」と報告できます。

8. ニリアコットAI特命室でWeb運用を一工程から任せる

最初から更新操作まで自動化する必要はありません。まずは更新候補の一覧化、公開ページのリンク確認、商品・投稿の点検、週次報告など、読み取り中心の一工程から始められます。証跡、停止条件、承認点が安定した工程から、バックアップや変更実行へ広げます。

ニリアコットAI特命室では、WordPressとEC-CUBEを別々のツールとして見るだけでなく、確認、保護、承認、実行、read-back、報告までを一つの運用として設計します。

Web運用のどこからAIへ任せるか整理しませんか

30分AI業務診断で、現在の更新確認、バックアップ、承認、公開後確認の流れを整理します。

ニリアコットAI特命室30分AI業務診断AI特命室自動見積問い合わせフォーム