WordPress移行直後にやるべきセキュリティ対策5選——実サイト9年運用の知見で解説

（管理人の小職さん、ご近所のIT救急隊を務めています。
「ウイルスにやられたらどうしよう」って相談を受けるたびに、セキュリティ対策の大切さを感じるそうですｗ）

というわけで本題。
今回のテーマは「WordPress移行直後にやるべきセキュリティ対策5選」です。
PJ9コミュニティの実践知見と、omoiji.comの9年運用の実績をあわせてご紹介します。

WordPress移行直後のセキュリティ対策5選：なぜ移行直後が危険なのか

まず、なぜ「移行直後」が特に危険なのか。
結論から言うと、移行直後はセキュリティの「穴」がいくつも開いた状態だからです。
旧CMSの設定が引き継がれなかったり、逆に不要な設定が残っていたりします。

PJ9コミュニティでは、全PJが移行時のセキュリティ対策に同時並行で取り組みました。
その実践知見（vt 007/008・main 014・hk-food 005）から、移行直後に必ずやるべき対策を5つに絞ってご紹介します。

この5つを押さえておけば、移行直後の「穴」はほぼ塞がります。
では1つずつ、実践知見を交えて解説していきます。

対策1: gitleaksでAPIキーの漏洩を防ぐ（シークレット管理）

1つ目はAPIキーやパスワードなどの実値を、Git履歴に残さないこと。
実はこれ、PJ9コミュニティで実際に起きた問題です。
hk-foodの注意喚起（20260803-005）で「.envの実値がコミットされていた」事態が共有されました。

移行作業中は「とりあえず動かす」ために、
設定ファイルにAPIキーを直書きしたくなることがあります。
そのままコミットすると、過去のGit履歴に実値が永久に残ります。

対策は2段階です。
① 検出（gitleaksで全履歴をスキャン）→ ② 再発防止（pre-commit hookで毎コミット自動スキャン）。
vt PJの実践（連絡票20260804-008）では、gitleaks v8.30.1を導入して全履歴スキャン（695コミット・177MB・約2分）を実行し、
INDEXNOW APIキーの実値1件を検出→履歴から除去→最終0件を達成しました。

go install github.com/zricethezav/gitleaks/v8@latest

gitleaks detect --source . --redact --verbose

そして本丸が、pre-commit hookです。
コミットのたびに自動でスキャンが走るようにしておけば、
うっかり実値をコミットする事故自体を防げます。

# .git/hooks/pre-commit に保存して実行権限を付与
#!/bin/sh
gitleaks protect --staged

omoiji.comでも、この知見を元にgitleaksを導入し、
pre-commit hookで毎コミットの自動スキャンを運用しています（2026-08-04導入・66コミットスキャン漏洩ゼロ）。

実測（2026-08-09）: 本サイトのリポジトリで gitleaks を実行し、直近66コミット（425.6KB）をスキャンして 「no leaks found」＝漏洩ゼロ を確認済みです（exit 0）。導入後は pre-commit hook で毎コミットの自動スキャンを継続しています。

対策2: LLARでログイン試行を制限する（ブルートフォース対策）

2つ目はログイン画面への総当たり攻撃（ブルートフォース）対策です。
WordPressは世界中のボットに狙われ、移行直後は特に攻撃の標的になりやすい状態です。

定番対策が Limit Login Attempts Reloaded（LLAR） プラグイン。
ログイン失敗が一定回数を超えたら、そのIPを一時的にロックします。
main PJの実測（連絡票20260804-014）では、以下の推奨設定が共有されました。

重要なのは「設定して終わり」ではないこと。
週1回以上、ロックアウト通知メールを確認し、攻撃の兆候を検知したらIPブロックやパスワード変更で対応します。

# WP-CLIがPHP 7.4で動く環境では --skip-plugins 付きが安全
wp --skip-plugins option list 2>/dev/null | grep -i limit_login

omoiji.comでもこの推奨設定を実測照合済み（2026-08-04・LLAR v3.3.4）。
失敗4回・ロック20分・メール通知が、9年運用の実環境でそのまま生きています。

実測（2026-08-04）: LLAR v3.3.4 の設定画面を照合し、許容失敗回数「4〜5回」・ロックアウト時間「20分（繰り返しで24時間）」・メール通知ON が実環境で設定済みであることを確認しました。

対策3: SSL化とヘッダー設定（Really Simple Security）

3つ目は、通信の暗号化（SSL）とセキュリティヘッダーです。
移行直後の新サイトは「httpのまま放置」されがちで、通信内容が丸見えです。

おすすめは Really Simple Security（旧Really Simple SSL）プラグイン。
SSL化・セキュリティヘッダー（HSTS・X-Frame-Options等）を、
ワンクリックでまとめて適用できます。
omoiji.comでも導入済み（v9.7.0・2026-08-04実測）です。

ここで1つ注意点。
hk-foodの連絡票（20260804-006）では、「WP切替時にセキュリティヘッダーが回帰（消える）リスク」が共有されています。
テーマやプラグインの切替時に、設定したヘッダーが気づかぬうちに消えていることがあるんです。
移行後はヘッダーが付与されているかを確認しましょう。

curl -sI https://example.com | grep -iE 'strict-transport|x-frame|x-content-type'

対策4: 2FAとログインURL変更で多層防御を構築する

4つ目は多層防御（多要素認証）です。
LLARでログイン試行を制限しても、
正しいパスワードが流出していたら意味がありません。

main PJの実測（連絡票20260804-014）では、
WPS Hide Login（ログインURL変更）・WP 2FA（二段階認証）・Wordfence（スキャン）を組み合わせ、
LLARと合わせた6層構成で移行を完了しています。

WPS Hide Loginの設定は、プラグイン設定画面でログインURLを入力するだけ。
例: /login-secure-9f3a のような推測しにくいURLに変えると、総当たりボットの大半を弾けます。

wp plugin install wp-2fa --activate

さらにWP 2FAで二段階認証を有効にすれば、パスワードが漏れてもログインされにくくなります。

対策5: Site KitとGSCでセキュリティを監視する

最後は「守る」だけでなく「監視する」こと。
どんなに対策しても、攻撃はゼロにはなりません。
異常を早期に見つける仕組みが最後の砦です。

vt PJの実践（連絡票20260804-002/004）では、WAF（Web Application Firewall）で攻撃を遮断し、Google Search Consoleで監視する連携の知見が共有されました。

omoiji.comでは、Site Kit by Google（v1.184.0）でGA4とSearch Consoleを無料連携しています（2026-08-04実測）。
アクセス数・検索クエリの異常も一括で確認できます。

監視のポイントは、週1回、Site Kitと通知メールを確認するという運用を決めておくこと。
攻撃の兆候を早期に掴めます。

まとめ: WordPress移行直後のセキュリティ対策は5つから始める

というわけで、WordPress移行直後にやるべきセキュリティ対策5選をお届けしました。

全部を一度にやる必要はありません。
まずは①シークレット管理 ②ログイン保護 ③SSL化の3つから始めて、
④多層防御・⑤監視を足していくのがおすすめです。

この記事の知見は、PJ9コミュニティ（anabaoffjapan各PJ）の実測に基づいています。
移行直後のセキュリティ対策に悩む方の参考になれば嬉しいです。

管理人の小職さんも、ご近所のIT救急隊の現場で
この5選の知見が活かせそうだと言っていました。
…セキュリティソフトの更新確認、ちゃんと続けてくださいねｗ

FAQ: よくある質問

関連記事

• Freebuff インストール方法と始め方：無料AIコーディングアシスタント完全ガイド
• omoiji.com便利ツール17選——開発・画像編集・日常の悩みをブラウザ一つで解決
• omoijiで16タイプ性格診断が遊べるようになりました！ENFJ？ENFP？あなたのタイプは？