WordPress への攻撃は激化しています。AI の性能向上で今後さらに増え、防御側は構造的に不利。攻撃を防ぎ続けるより、狙われる面そのものを断つべき局面です。
AI で攻撃は自動化・高度化。防御は追いかけ続けるしかなく、割に合わなくなる。
重要な処理・データを公開網に置かない。狙われる面（攻撃面）を構造的に消す。
サーバーレスの静的配信へ。WeBase / Liberte の移設をご提案します。
7/13〜14 と比べ、アクセスログに占める攻撃の割合が増加。一方で通常通信は微減。「使われる」より「狙われる」方向へ傾いている。
サーバーの CPU が攻撃処理に取られ始めている。ここでCPU を増強しても、恩恵の多くは攻撃者側に渡る——増強＝防御ではなく、攻撃者の環境改善になりかねない。
※ 実数は別紙「アクセスログ／攻撃比率集計（7/13〜7/21）」に基づく。個別の増強・対処の延長線ではリスクは下がらない。
公開側に PHP もデータベースも置かず、静的HTMLだけを配信する仕組み。「動的処理を突く」攻撃面そのものが存在しません。
PHP・DB・管理画面が公開網に存在しない。wp2shell のようなコア脆弱性が出ても、公開サイトは影響を受けない。
脆弱性のたびの WAF 調整・パッチ・侵害調査という running cost が不要に。CPU を攻撃に奪われることもない。
静的配信は高速で改ざんに強い。編集内容は生成して配信するだけ。サーバー負荷も最小。
今のデザインを保ったまま移行。編集はバックエンドで行い、公開だけを静的に切り離す。
本番に影響を与えず、乗離URLへ当社がサイトを複製。状況をご提示したうえで、最適な管理方法をご提案します。
本番とは別のURLに、当社がサイトを複製。現行サイトは稼働したまま。
複製されたサイトの状態・表示を貴社にご確認いただきます。
運用実態に合わせて、2つの管理方法からご提案します。
SiteBase の管理ツールをご提供。公開・更新を SiteBase 上で完結させ、WordPress を完全に廃止できます。
WordPress をオリジンサーバとして残し、SiteBase が静的HTML化と公開機能を提供。公開面は静的のまま守られます。
国内のさくらインターネット基盤（オブジェクトストレージ＋ウェブアクセラレータ/CDN）で配信。サーバーを持たない、安定した公開基盤です。
2サイトの動的機能の棚卸し（フォーム等の有無を確認）
移設方針の合意（対象・代替手段・優先順位）
スコープ・体制・概算工数の詳細設計へ