Claude Codeで作るWordPressセキュリティ・保守監視システム構築手順

こんにちは、AIシステムズです。
この記事は、代表コバが現場で蓄積してきた知見をもとに、AIを活用して構成・執筆し、弊社にて最終チェックを行ったものです。

弊社では、保守契約をいただいている複数の WordPress サイトを1 画面で監視・点検する社内ツールを、Claude Code でフルスクラッチ構築しています。
基本の発想はシンプルで、各サイトのバックアッププラグインが Dropbox に投げた WordPress 一式を、社内サーバーで自動的に取り込み、本物の WordPress として動かして検査するというものです。本番に触らずに、テンプレートやプラグインの不具合、SSL の状態、リンク切れ、WordPress 本体の更新状況まで一括点検できます。
本記事では、同じ仕組みを Claude Code で組み立てるための手順を、実装単位で整理します。

複数 WP サイトの保守を 1 画面で回せるダッシュボード設計
「プラグイン → Dropbox → 社内サーバー」の自動同期パイプライン
WP 本体・プラグイン・SSL・リンク切れの一括ヘルスチェック
cron で運用に乗せる際の注意点

このシステムをどう作ったか（全体像）
解決したい課題と要件
アーキテクチャと使用技術
手順1：各 WP サイトの自動バックアップ設定
手順2：rclone で Dropbox から自動同期
手順3：取り込んだバックアップを WordPress として展開
手順4：ヘルスチェック cron の実装
手順5：本番URL死活監視
手順6：リンクエラー検出
手順7：ダッシュボードと通知
Claude Code に任せるときのコツ

このシステムをどう作ったか（全体像）

全体の流れは次のとおりです。

各 WordPress サイトに無料バックアッププラグインを入れ、定期的に .wpress 形式で Dropbox 連携フォルダへエクスポート
社内サーバーから rclone で Dropbox 上のバックアップを取得
取得した .wpress をローカルの /backup/ 配下に展開し、社内サーバー上で動く WordPress として再構成
PHP で書いた cron が、展開されたサイトを 1 つずつ走査して WP バージョン・プラグイン・トップページ・管理画面・SSL・リンクなどを点検
結果を MySQL に保存し、社内向けの管理ダッシュボードで一覧表示

肝は「本番サーバーに一切ログインせず、点検をクローン側で完結させる」という設計です。本番に negative impact を出さずに、WordPress 本体・プラグインの更新状態や、改ざんの兆候まで確認できます。

解決したい課題と要件

複数の WordPress サイトを保守していると、現場ではこういう困りごとが必ず出ます。

サイトごとに WP 本体やプラグインのバージョンがバラバラで、把握しきれない
古い WP のままで放置されているサイトが、いつの間にか改ざんされる
SSL 証明書の期限切れに気づくのが事故発生後
本番にログインして点検するたびに、ログイン履歴やセッションが汚れる
「不具合の有無を毎月 1 度確認する」運用を、人手でやると抜けが出る

これらをまとめて解消する要件として、次の機能をシステム化しました。

各サイトを 毎日 1 回、社内側で複製して点検する
WP 本体・プラグインのバージョンを取得して、最新版との差分を表示
本番サイトの HTTPS・HTTP ステータス・タイトル変化を 3 時間ごとに監視
サイト内リンク切れを毎日スキャン
バックアップが Dropbox に届いているかを監視（届いていない＝サイト停止の予兆）
すべての結果を 1 ダッシュボードで色付き表示

アーキテクチャと使用技術

WordPress バックアッププラグイン：無料の汎用エクスポートプラグインを使用（.wpress ファイルを生成し Dropbox に送信）
クラウドストレージ：Dropbox（プラグイン側が対応していれば Google Drive など他でも可）
同期ツール：rclone（Dropbox API トークンでフォルダ単位の差分同期）
サーバー：VPS 上の Linux + Apache + PHP + MySQL／MariaDB
WP-CLI：取り込んだサイトの調査・URL書換え・キャッシュフラッシュ
cron：PHP スクリプトを定時実行（同期・点検・リンクチェック）
ダッシュボード：PHP（プレーン）で SPA を避けた素朴な構成、CSRF・ログイン・ロール分離だけ実装

ダッシュボードを React や Vue にしなかった理由は、保守担当が変わってもメンテしやすく、サーバーの依存関係を増やしたくないからです。Claude Code に「シンプルな PHP テンプレートで、JS は最小限に」と先に伝えておくと、過剰な構成にされません。

手順1：各 WP サイトの自動バックアップ設定

各 WordPress サイトに、エクスポート→クラウド送信に対応するバックアッププラグインを入れます。

バックアップ先：Dropbox（または同等のクラウドストレージ）
頻度：毎日 1 回（深夜帯）
保存形式：.wpress など、プラグイン純正の単一ファイル形式
世代管理：3〜7 世代を保持し、古いものは自動削除
必ずサイト単位でフォルダを分ける：Dropbox 側で /サイト識別子/ のように整理しておくと、同期側で扱いやすい

この段階でやってはいけないのは、「全サイトのバックアップを Dropbox 上の同じ場所に置く」ことです。後工程で取り違えが起きるリスクが上がるので、サイトごとにフォルダを分けるルールを決めておきます。

手順2：rclone で Dropbox から自動同期

社内サーバー側で rclone を導入し、Dropbox のバックアップフォルダ全体を毎日 1 回ローカルへ同期します。

rclone config で Dropbox をリモートとして登録
同期コマンド：rclone sync (Dropbox上のフォルダ) (ローカル上のフォルダ)
cron で深夜帯に実行
差分同期なので、初回以外は短時間で終わる
同時に rclone lsjson でファイル一覧を取り、サイトごとに ファイル数・合計サイズ・最終更新日時を集計して DB に保存

このタイミングで、「予定どおりバックアップが届いているか」もチェックできます。最終更新日時が古いままのサイトは、プラグイン停止か WP 本体の停止が起きている可能性が高く、ダッシュボードで黄色／赤の警告として表示します。

手順3：取り込んだバックアップを WordPress として展開

.wpress はそのままでは動かないので、社内サーバー側で WordPress として復元します。

各サイト用に DB を 1 つずつ用意
Apache のバーチャルホストで /backup/{サイト識別子}/ をドキュメントルートに設定
プラグインのインポート機能、または wpress 展開ツールでファイルを展開
wp-config.php の DB 接続情報を社内サーバー用に書き換える
WP-CLI で wp search-replace を実行し、本番 URL → 社内点検用 URL に置換

ここを Claude Code に書かせると、展開→DB差し替え→URL置換→キャッシュ削除までを 1 つのシェル／PHP スクリプトにまとめてくれます。ただし初回は必ず手動で 1 サイト分通してから自動化します。コマンド組合せは環境差が出やすく、自動化前に必ず動作確認するのが安全です。

手順4：ヘルスチェック cron の実装

取り込みが完了したら、点検フェーズです。PHP スクリプトを cron に登録し、/backup/ 配下を再帰走査して各サイトを 1 件ずつ点検します。点検項目は次のとおりです。

WP バージョン：wp-includes/version.php から取得し、wordpress.org API の最新版と比較
プラグイン一覧：wp-content/plugins/ を走査し、各プラグインの version／active 状態を取得
テーマ：同上、テーマディレクトリを走査
トップページ HTTP チェック：HTTPS 接続、ステータスコード、タイトル、サイズ
管理画面の到達性：/wp-login.php の応答コードと、不審なリダイレクトの有無
WP-CLI チェック：wp core verify-checksums でコアファイルの改ざん検知
debug.log の中身：致命的エラー・PHPワーニング・データベースエラーの行数を集計

これを 1 サイトずつ実行し、結果を sites テーブルに upsert します。WP コアの改ざん検知は WP-CLI の標準機能で確実に取れるので、毎日回す価値があります。

手順5：本番URL死活監視

取り込んだコピー側だけ見ていると、本番がダウンしていることに気づけません。別 cron で 3 時間ごとに本番 URL を直接叩いて確認します。

HTTPS の証明書有効期限を取得し、残り日数を DB に保存（30 日切ったらダッシュボードで警告）
ステータスコードと応答時間を記録
連続 3 回失敗したら、メールまたは Slack 通知（運用ポリシーに合わせて変更可）
本番 URL は sites テーブルに保持された値を使用、外部サイト（バックアップ対象外で死活だけ見たいサイト）にも同じ枠組みを使える

手順6：リンクエラー検出

毎日 1 回、全サイトに対して内部リンクのスキャンを走らせます。

トップページから 2〜3 階層分のリンクを再帰収集（深すぎる再帰は時間がかかるので制限する）
各リンクに HTTP HEAD リクエストを送り、4xx・5xx を記録
結果は link_errors テーブルに保存、ダッシュボードでサイトごとに件数表示
同じ URL は前日と比較し、新しく発生したエラーだけ強調表示

ここでも Claude Code に対しては「1 サイトあたり最大 N リンクで打ち切る」「外部リンクは対象外」「robots.txt 尊重」など、暴走しないための制約を最初に書き渡します。

手順7：ダッシュボードと通知

社内ダッシュボードは「1 画面で全部わかる」が要件です。次の情報を 1 行 1 サイトでまとめます。

サイト名 / 本番URL / 管理会社
WP本体バージョン（最新版との差分つき）
プラグイン更新待ち件数
SSL 残日数
直近 3 時間以内の死活ステータス
リンクエラー件数（前日比）
Dropbox バックアップ最終日時とファイル数
「更新テスト」ステータス（人がプラグイン更新を試した結果を保存）

通知は「赤色ステータスがある時だけ」に絞ります。毎朝サマリーが届くと、最初の数日は読みますが、すぐに無視されるからです。異常が起きた時だけ通知するのが、長期的な運用の鉄則です。

Claude Code に任せるときのコツ

このシステム特有の落とし穴を整理しておきます。

1 サイト単位で完結する関数を書かせる：collect_site_info($path) のように、サイトのパスを渡せば全情報を返す関数に切る
外部リクエストにはタイムアウトを必ず設定：1 サイトの応答が遅いだけで cron 全体が止まると致命的
upsert で書く：1 サイト 1 行、結果は UPDATE か INSERT のどちらかで終わるように
ロックファイルを噛ませる：cron の多重起動防止。同じ cron が前回まだ走っている時に起動すると、DB が壊れたり Dropbox API のレート制限に引っかかる
ログを 1 行 1 イベントで書く：「サイト名｜処理内容｜結果」の形式で揃えると、後でジョブ失敗を grep しやすい
大量データを扱う前に必ずバックアップ：構造変更がある DB 改修は、改修前に mysqldump で必ずスナップショット

特に「外部 API（Dropbox／wordpress.org／HTTPS 接続）のタイムアウト管理」は、Claude Code に明示しないと書き忘れがちです。要件に「すべての外部リクエストに 8 秒タイムアウト」と書くだけで、品質が変わります。

まとめ

WordPress の保守監視システムを Claude Code で構築する流れは、以下のとおりでした。

各サイトにバックアッププラグインを入れ、Dropbox に毎日エクスポート
社内サーバー側で rclone を使い差分同期
取り込んだバックアップを社内サーバー上の WordPress として展開
cron で WP・プラグイン・SSL・リンク・改ざんを毎日点検
結果をダッシュボードに集約し、異常時のみ通知

保守業務は、「異常が起きた時に最速で気づける状態」を作ることが最大の価値です。月数千〜数万円の保守費を頂いているなら、人が毎月見に行く運用ではなく、自動点検が走っているうえで人がレビューする運用に切り替えるのが、結果的にコストと品質の両面で正解になります。

本記事は代表コバの現場知見をもとに AI で構成し、弊社にて最終確認を行っています。

「自社で保守している WP サイトを一元監視したい」「保守業務の自動化を検討している」など、相談ベースでも対応しています。費用感だけ知りたい方も、お気軽にご相談ください。

AI Systemsへの無料相談はこちら

「何から始めればいいか分からない」段階からでも、お気軽にご相談ください。
まずは、お話を聞かせていただくだけでも大丈夫です。

無料で相談する

コバ

AI活用 / Web制作 / 業務自動化支援

中小企業さま向けに「お手頃に・早く・成果が出る」開発支援を行っています。AI・Web・自動化の3分野を、まとめてサポートしています。