プロフェッショナルな対応

WordPress の保守は、管理画面からの更新と、プラグインでのバックアップが中心になりがちです。WordPress の脆弱性の 9 割はプラグインにあり、更新とバックアップのやり方が、サイトの安全を左右します。
KEY SELECT は、AWS の仕組みとシステム開発のやり方で、WordPress を保守します。バックアップは AWS Backup で、セキュリティは AWS のセキュリティのサービスで、本体・プラグイン・テーマは Git と Composer でバージョンを管理します。
すべての作業を、セキュリティを意識して進めます。

WordPress の保守運用のご相談一般的な保守との違い

一般的な保守との違い

同じ「WordPress の保守」でも、やり方によって、守れる範囲と、問題が起きたときに戻せる確かさが大きく変わります。

項目	一般的な保守	KEY SELECT の保守
更新の管理	管理画面の更新のボタンで、そのつど更新する	Git と Composer で、本体・プラグイン・テーマのバージョンを固定して記録し、決めたバージョンだけを反映する
更新の確認	本番のサイトで更新し、表示を確かめる	検証環境で、自動テストと画面の確認をしてから、本番に反映する。問題があれば前のバージョンに戻せる
バックアップ	プラグインで、同じサーバーや同じ場所に保存する	AWS Backup で、別のアカウントとリージョンにコピーし、削除できない状態で保管する。復元も自動で試す
攻撃への備え	セキュリティのプラグインを入れる	AWS WAF の WordPress・PHP・SQL のルールで、攻撃を WordPress に届く前に止める。GuardDuty で不審な動きを検知する
設定の点検	担当者の経験による	Security Hub で、AWS の基準と CIS の基準に沿って、設定を自動で点検する
脆弱性の情報	プラグインの更新の通知を待つ	脆弱性のデータベースで、使っているプラグインの脆弱性を監視し、修正の有無を確かめる
管理画面	ID とパスワードでログインする	アクセスできる人と場所を限り、2 段階認証を使う。管理画面からのプラグインのインストールを止める
変更の記録	作業の報告	Git の履歴と CloudTrail で、いつ、誰が、何を変えたかを残す

保守の作業領域

一般的な WordPress の保守は、本体とプラグインの更新、バックアップ、監視が中心で、更新のあとの不具合の修正、PHP やサーバーの更新、改ざんからの復旧は、別料金や対象外のことが多くあります。KEY SELECT は、システム開発とインフラの運用も行う会社として、サイトが動く環境の全体をお引き受けできます。

作業の領域	KEY SELECT がお引き受けできること	一般的な保守での扱い
本体・プラグイン・テーマ	検証環境で確かめてから、本体、プラグイン、テーマ、翻訳のファイルを更新する	本体とプラグインは標準。テーマは別のことがある。更新が 2〜3 か月に 1 回のこともある
更新のあとの不具合	更新が原因の不具合は、カスタマイズのコードも含めて、原因を調べて直す	別のお見積もりのことが多い
PHP と動作環境	PHP、データベース、Web サーバーのバージョンアップと、古いコードの修正	標準と別料金が半々
サーバーと AWS	OS とミドルウェアの更新、AWS の構成と権限、費用の確認	対象外か、オプションのことが多い
バックアップと復元	AWS Backup で、別のアカウントとリージョンに、削除できない状態で保管し、復元を自動で試す	毎日 7 日間分など、曖昧な表記が多い
セキュリティ	AWS WAF、GuardDuty、Security Hub での点検と、使っているプラグインの脆弱性の監視	WAF はオプションのことが多い。脆弱性の情報の出どころを示しているところは少ない
監視	サイトの表示、SSL 証明書とドメインの期限、改ざん、AWS の費用	表示の監視は標準。証明書とドメインの期限の監視を示しているところは少ない
改ざんと障害の対応	調査、復旧、原因への対策、再発の防止、ご報告まで	内容によって別料金のことが多い
小さな改修	文言や画像の変更、フォームの項目の追加など。開発の担当が対応する	作業の時間や回数に枠があることが多い
ご報告と記録	毎月のご報告、Git の履歴、作業の記録	上位のプランで標準のことが多い

作業の領域は、サイトの内容とご予算に合わせて選べます。お見積もりの段階で、含む作業と含まない作業を明記します。
「一般的な保守での扱い」は、国内の WordPress の保守サービス 17 社が公開している情報を、KEY SELECT が調べたものです (2026 年 10 月)。

脆弱性の 9 割は、プラグインにある

WordPress の本体の脆弱性はわずかで、ほとんどはプラグインとテーマにあります。どのプラグインのどのバージョンを使っているかを正確に管理することが、保守の土台です。

2025 年に新たに見つかった、WordPress に関わる脆弱性 (11,334 件)91% がプラグイン、本体は 6 件だけ。

プラグイン91%
テーマ9%
本体6 件

Patchstack の報告書「State of WordPress Security In 2026」によります。前の年より 42% 増え、46% は公表の時点で修正が出ていませんでした。棒の長さは割合に比例しています。

修正が出ていない脆弱性もあるため、更新だけでは守りきれません。KEY SELECT は、使っているプラグインの脆弱性を監視し、修正がないものは、AWS WAF で攻撃を止めるか、代わりのプラグインへの置き換えをご提案します。

プラグインに任せないこと

WordPress には、本来は WordPress の外側で行うべきことを、WordPress の中で行うプラグインが多くあります。

守るためのプラグインが、脆弱性の入口になる: プラグインは WordPress と同じ権限で動くため、守るためのプラグインそのものが、脆弱性の入口になることがあります。
攻撃は、サイトに届いたあとでしか遮断できない: プラグインは、WordPress と PHP が動き出してから攻撃を判断します。

KEY SELECT は、守る仕組みを WordPress の外側に置きます。

ログイン、攻撃の遮断、ファイルの検査、バックアップを、WordPress の外側の仕組みに任せ、WordPress には本来の役割に集中させます。

役割	プラグインで行う場合	KEY SELECT の進め方
ログイン	セキュリティのプラグインで、2 段階認証やログインの試行の制限を加える	Microsoft Entra ID や Google Workspace などの外部のログイン (シングルサインオン) にし、多要素認証や退職した方の停止を、ID の管理とまとめて行う
攻撃の遮断	プラグインの WAF で、WordPress が動いてから攻撃を判断する	上流の AWS WAF で、攻撃を WordPress に届く前に止める。サーバーの負荷にもならない
アップロードされたファイルの検査	プラグインで、サーバーの中のファイルを検査する	ファイルを Amazon S3 に保存し、GuardDuty の S3 のマルウェアの検査で、置かれたファイルを自動で検査する
バックアップ	プラグインで、同じサーバーや同じ場所に保存する	AWS Backup で、別のアカウントとリージョンに、削除できない状態で保管する

出典: GuardDuty Malware Protection for S3(2026 年 10 月 27 日に確認)

AWS Backup でのバックアップ

サイトが改ざんされたり、ランサムウェアの被害を受けたりしたときに、確実に戻せることがバックアップの目的です。サイトと同じ場所に置いたバックアップは、サイトと一緒に消されるおそれがあります。

別のアカウント・リージョンへ

データベース (Aurora・RDS) と、画像などのファイル (S3) を、別の AWS アカウントと別のリージョンにコピーします。

削除できない保管

Vault Lock のコンプライアンスモードでは、保管の期間が終わるまで、管理者も AWS も、バックアップを変更・削除できません。

復元の自動テスト

復元テストの機能で、定期的に自動でバックアップから戻し、戻せることと、かかった時間を記録します。

時点を選んで戻す

Aurora と S3 は、継続バックアップで、指定した時点の状態に戻せます (保持は最大 35 日)。

バックアップの監査

Backup Audit Manager で、頻度、保持の期間、暗号化、ロックの有無が決めたとおりかを、毎日自動で点検します。

目標に合わせた設計

どこまでのデータを失ってよいか (目標復旧時点) と、どれだけの時間で戻すか (目標復旧時間) を決めてから、頻度と保持の期間を決めます。

AWS のセキュリティのサービス

WordPress の中のプラグインだけに頼らず、WordPress の外側で、攻撃を止め、不審な動きを見つけ、設定を点検します。AWS の Well-Architected フレームワークのセキュリティの考え方に沿って組み合わせます。

攻撃を手前で止める

AWS WAF

サイトの手前で、リクエストを点検し、攻撃を WordPress に届く前に止めます。AWS が管理するルールを使うため、新しい攻撃の手口にも追従できます。

WordPress、PHP、SQL インジェクションの、AWS が管理するルール
ログインのページへの大量の試行の制限
国や IP アドレスでの接続の制限

DDoS 攻撃への備え

AWS Shield Standard

大量の通信でサイトを止める DDoS 攻撃から、自動で守ります。追加の費用はかかりません。

すべての AWS の利用者に、自動で有効
CloudFront と組み合わせると、効果が高い

不審な動きの検知

Amazon GuardDuty

AWS の操作の記録と通信を分析し、乗っ取りや不審な通信を検知します。

Lambda の通信の監視 (暗号資産の採掘や、悪意のあるサーバーとの通信)
S3 のデータの持ち出しや削除の試み
データベースへの不審なログイン

設定の自動の点検

AWS Security Hub

AWS の設定が、セキュリティの基準に合っているかを自動で点検し、検知の結果をまとめて、対応の優先順位を付けます (AWS Security Hub で行うこと)。

AWS の基礎的なセキュリティのベストプラクティス (FSBP)
CIS AWS Foundations Benchmark
GuardDuty や Inspector の結果のとりまとめ

変更の記録

AWS CloudTrail・AWS Config

AWS の操作と、設定の変更の履歴を残し、問題が起きたときに、いつ、誰が、何を変えたかを調べられます。

AWS の操作の記録
設定の変更の履歴と、決めた設定に合っているかの評価

管理の権限を絞る

IAM Identity Center

AWS の管理は、個人ごとのアカウントと多要素認証で行い、作業に必要な権限だけを、必要な間だけ渡します。

個人ごとのアカウントと、一時的な権限
多要素認証 (パスキーを推奨)

AWS WAF の WordPress のルールは、xmlrpc.php などへのアクセスを止めます。XML-RPC を使う連携 (一部のアプリやサービス) がある場合は、事前に確かめてから設定します。

Git と Composer でのバージョン管理

本体、プラグイン、テーマのバージョンを、システム開発と同じように Git と Composer で管理します。どのサイトに何が入っているかが常に分かり、更新で問題が起きても、前の状態に戻せます。

バージョンの固定と記録

本体、プラグイン、テーマのバージョンを Composer で固定し、変更をすべて Git に残します。

管理画面からの変更を止める

管理画面からのプラグインのインストールや、ファイルの編集を止め、改ざんや意図しない変更の入口を減らします。

更新の自動の提案

Renovate や Dependabot が更新を提案し、検証環境とテストを通ったものだけを取り込みます。

検証環境と自動テスト

本番と同じ構成の検証環境で、主なページの表示と、フォームなどの操作を自動で確かめます。

決まった手順での反映

本番への反映は、CI から決まった手順で行い、個人の PC からの手作業の反映をなくします。

動作環境の管理

WordPress が推奨する PHP 8.3 以上、MySQL 8.0 以上 (または MariaDB 10.11 以上) に合わせて、動作環境も更新します。

技術者の方へ

Composer での管理と、wp-config.php の設定の例です。WordPress の公式に保守されているのは最新のバージョンだけで (2026 年 10 月 25 日時点で 7.1.3)、古いバージョンへの修正は好意で行われるものとされています。

Composer での管理 (Roots の Bedrock の構成)

{
  "repositories": [
    { "type": "composer", "url": "https://repo.wp-packages.org" }
  ],
  "require": {
    "roots/wordpress": "^7.1"
  }
}

本体は roots/wordpress(公式のソースから自動で作られるパッケージ) で入れます
プラグインとテーマは、Roots の WP Packages (wp-plugin/*、wp-theme/*) から入れます。WordPress の公式のディレクトリのプラグインとテーマを、Composer で扱えるようにしたものです
Bedrock では、本体は web/wp、プラグインとテーマは web/app に置き、データベースの接続の情報などは .env に書きます

wp-config.php の設定

define( 'DISALLOW_FILE_MODS', true );        // 管理画面からのプラグイン・テーマのインストールと更新、ファイルの編集を止める
define( 'AUTOMATIC_UPDATER_DISABLED', true ); // 自動の更新を止め、Composer と検証環境を通した更新だけにする

WordPress は、初期の設定では、本体のマイナーリリース (セキュリティの修正を含む) を自動で更新します。Composer で管理する場合は、自動の更新を止め、修正が出たらすぐに検証して反映する体制で保守します。

出典: Patchstack: State of WordPress Security In 2026、AWS Backup Vault Lock、AWS Backup restore testing、AWS WAF managed rule groups、Amazon GuardDuty、AWS Foundational Security Best Practices、Bedrock (Roots)、WP Packages (Roots)、wp-config.php (WordPress)、WordPress Requirements、WordPress Security(2026 年 10 月 25 日に確認)

ご相談・お問い合わせ

内容が固まっていない段階からご相談いただけます。各分野のプロフェッショナルがご対応いたします。ご相談・お見積もりは無料です。

KEY SELECT に相談するその他のお問い合わせ