Ownership
どの機能がログイン、通信、フォーム、ファイルを制御するかを一つずつ把握する。
防御機能が多いほど安全とは限りません。同じ領域を複数の機能が制御すると、原因の特定と変更が難しくなり、正規の問い合わせまで止める可能性があります。役割を調べ、主軸を決め、業務機能と一緒に検証できる構成を検討します。
WordPressのセキュリティを、機能の追加数ではなく、誰が構成を把握し、競合を特定し、業務を止めずに調整できるかで設計できるか。
既存WordPressでは、AIOSとSiteGuardを含む複数のセキュリティ機能が確認されました。
ログイン制御、アクセス制限、Bot対策などの役割が重なり、どの設定が挙動へ影響しているかを追跡しにくい状態でした。2026年6月9日の調査では、ログイン画面へ到達できない挙動についてAIOS側の影響を確認し、SiteGuard停止だけでは状況が変わらないことも確認しました。
その後、AIOSを主軸として構成を整理しました。しかし7月6日には、AIOSのREST API保護がContact Form 7の正規送信を403で止める問題が発生しました。セキュリティを統一した後も、業務機能との両立を検証・調整する必要がありました。
設定を増やせば遮断対象は増えますが、同時に構成理解、原因特定、更新、例外管理の負荷も増えます。少人数で保守する環境では、防御と運営の両方を確認できることが必要です。
どの機能がログイン、通信、フォーム、ファイルを制御するかを一つずつ把握する。
同じ役割を複数のプラグインへ持たせず、主軸と補助の境界を決める。
防御設定だけで確認せず、ログイン、フォーム、外部連携を実際に動かす。
403、警告、ログ、スキャン結果から、影響元を追跡できる状態を残す。
分析上の結論:保守できるセキュリティとは、すべてを遮断する構成ではありません。守る対象と正規の業務通信を区別し、問題発生時に影響元を特定して修正できる構成です。
プラグイン、サーバー機能、ログイン、API、フォームの制御主体を洗い出す。
重複する役割の主軸を決め、不要な制御と管理対象を減らす。
ログイン、表示、フォーム、外部連携を実際に動かして影響を確認する。
警告や通信失敗の原因を特定し、必要な通信だけが通るよう再設定する。
PHP、プラグイン構成、セキュリティ設定、更新・保守状態を確認し、改善対象を整理しました。
利用状況、更新状態、重複機能、削除候補、保守上の注意を記録しました。
SiteGuardだけを止めても挙動が変わらず、AIOSを停止すると標準ログイン画面が表示されることを確認し、重複制御の影響元を調査しました。
セキュリティ機能をAIOSへ整理し、ログインURL、ファイアウォール、REST API、ハニーポット、管理画面からのPHP編集、404監視、重要ファイル権限などを確認・設定しました。
未使用テーマと不要プラグインを整理し、緊急復旧用の標準テーマは一系統残しました。権限スキャンとダッシュボード警告の状態も確認しました。
Contact Form 7のREST API通信が403となる原因をAIOSの保護設定へ特定し、一般利用者のTurnstile、Ajax送信、完了表示が成立するよう設定を修正しました。
重複する制御を調査し、AIOSを中心に管理する構成へ整理した実施記録があります。
Evidence: 取引メッセージ・WordPress保守管理資料 / 2026-06-09〜06-13
利用状況と役割を確認したうえで削除対象を整理し、標準テーマは復旧用として一系統残しました。
Evidence: WordPress保守管理資料 Version 1.2 / 2026-06-13
ダッシュボード上のファイアウォール警告解消、重要ファイル権限、ファイル/ディレクトリスキャンの確認が記録されています。
Evidence: WordPress保守管理資料 Version 1.2 / 2026-06-13
403の原因をAIOSのREST API保護へ特定し、調整後に一般利用者によるTurnstile、Ajax送信、完了表示を確認しました。
Evidence: Contact Form 7送信不具合調査・修正記録 / 2026-07-06
同じ入口を複数機能で守ると、障害時の影響元が分からなくなります。
一つの管理面から設定を追跡できることが、継続保守につながります。
スコアや警告だけでなく、ログインと問い合わせを実際に通します。
正規のAPI通信が止まった場合、無効化で終えず、用途を確認して制御を調整します。
| 主張 | 品質区分 | 根拠・処理 |
|---|---|---|
| AIOSとSiteGuardの重複を調査した | 調査事実 | 取引メッセージ・設定確認記録、2026-06-09 |
| AIOS停止時にログイン画面が表示された | 切り分け結果 | 障害調査記録、2026-06-09。公開時は実URLを非掲載。 |
| AIOSを主軸に統一した | 判断・実施事実 | 取引メッセージ・保守管理資料、2026-06-09〜06-13 |
| ログイン・API・Bot・権限等を設定・確認した | 実施・確認事実 | WordPress保守管理資料 Version 1.2、2026-06-13 |
| AIOSのREST API保護がCF7通信を403にした | 障害原因 | 送信不具合調査記録、2026-07-06 |
| 調整後に一般利用者の送信を確認した | 修正・利用確認 | 同記録。Turnstile→Ajax→送信→完了表示。 |
| 管理対象の統合が保守性を高める | 分析 | 重複調査、主軸決定、障害特定、再調整の事実から導いた解釈 |
| 完全に安全になった | 立証不能 | 絶対的安全性を主張しない。 |
| サーバーWAFを全面的に再設計した | 未確認 | WordPress側調整とサーバー側確認を混同しない。 |
重要な識別:CASE STUDY 17は問い合わせ受付とTurnstileを含むフォーム運営を研究します。本記事は、その正規通信を止めないためのセキュリティ構成と保守判断を研究します。
研究上の核心:AIOSへの統一後に起きた403を隠さず扱うことで、「統一すれば完成」ではなく、業務機能との継続検証までがセキュリティ運営であることを示します。
公開許可:2026年2月16日の実績公開許可と、2026年6月10日のPROJECT全体公開許可を確認しています。
判定:重複調査、影響元切り分け、AIOSへの統一、構成整理、警告・権限確認、CF7障害原因、再調整後の送信確認まで追跡でき、絶対的安全性と未確認のサーバー設定を除外したPublication Readyです。