WordPressディレクトリ構造のセキュリティを高めるために「wp-includes」フォルダへの直接アクセスを制限する際、最も安全な方法はフォルダ全体を盲目的にブロックするのではなく、内部のPHPファイルの外部実行とディレクトリリスト表示を遮断することです。wp-includesはWordPressコアの動作に不可欠なJavaScriptやCSS、その他の静的ファイルを含んでいるため、フォルダ全体のアクセスを遮断するとサイトデザインやエディター、プラグイン機能に不具合が生じる可能性があります。正しいアプローチは、Apacheなら.htaccessルール、Nginxならserver blockのlocationルールでPHPの実行を遮断し、その後403/404レスポンスや重要ページの動作を確認することです。
WordPressのセキュリティ対策で最もありがちなミスは、強力なパスワードやセキュリティプラグイン導入だけで満足してしまうことです。実際、攻撃者はコアファイルのあるディレクトリや古いプラグイン、誤ったファイル権限、ディレクトリリスト表示の開放状況を調査します。wp-includesもその標的となる場所の一つです。本記事では、実際のホスティング環境で実践可能なwp-includesアクセス制限方法、サイトを壊してしまうリスクのあるルール、Apache/Nginxでの具体設定例、テスト手順、メンテナンスチェックリストを紹介します。より安全なWordPressサイト運用のために WordPressホスティング や全体的な保護層として SSL証明書 の導入もご検討ください。
wp-includesフォルダとは?なぜ保護が必要なのか
wp-includesはWordPressコアの主要なライブラリを格納するディレクトリです。テーマ構造、ブロックエディター、REST API、メディア処理、クラスや関数群、さらに様々なJavaScriptファイルがここに含まれています。言い換えると、wp-includesはWordPressの「エンジンルーム」のような存在であり、ユーザーが直接訪問する必要のない部分です。
通常ユーザーはsite.com/wp-includes/にアクセスすることはありません。しかし、ページのソースコードにはwp-includes配下の静的ファイルへの参照が存在することがあります。例えば、WordPressの標準スクリプト、絵文字スクリプトやエディター関連のリソースがこのディレクトリから読み込まれる場合があります。そのため、セキュリティ設定時には静的ファイルの動作を妨げず、PHPファイルへのWeb経由の直接アクセスだけを遮断することが重要です。
この区別こそが、プロフェッショナルなWordPressディレクトリ構造セキュリティの基本です。フォルダを無差別に閉じると一時的には安全そうに見えますが、実稼働サイトだと「ホワイトページ」や管理画面の不具合、ブロックエディターやテーマの崩れなど致命的な問題が発生します。目的はWordPressが必要とするファイルを守りつつ、攻撃面を最小化することです。
wp-includesアクセス制限のメリット
wp-includesフォルダ内のPHP実行を遮断しても、全ての攻撃を防げるわけではありませんが、攻撃対象を大幅に狭めることができます。特に、マルウェア感染したサイトでは攻撃者がアクセス可能なディレクトリに悪意あるPHPファイルをアップロードしたり、既存ファイルを呼び出そうとします。wp-includes配下のPHPファイルをWeb経由で直接実行させないことで、一層の防御壁が築けます。
この対策による主な利点は以下の通りです:
- コアPHPファイルへの直接URL呼び出しを制限できる
- ディレクトリリスト表示が有効な場合、内部内容の公開を防げる
- 自動ボットによるスキャンから余計な情報漏洩を抑制できる
- セキュリティプラグインがなくてもWebサーバレベルで防御できる
- WAF、SSL、最新PHP、適切なファイル権限と組み合わせることで多層防御が強化できる
ここで重要なのは、これはあくまでセキュリティ層の1つであるという点です。古いプラグインや弱い管理者パスワード、乗っ取られたFTPアカウントがある場合、wp-includesのルールだけでは不十分です。セキュリティ対策とは、ホスティング基盤・アプリケーション・ユーザー管理・定期的なメンテナンスの総合力です。安全な基盤構築には 安全なウェブホスティング やドメイン管理の追加保護として ドメインセキュリティ も参考にしてください。
wp-includes制限時によくあるミス
フォルダ全体のブロック
最も多いミスが、wp-includesフォルダへの全てのHTTPリクエストを403で遮断してしまうことです。一見理にかなっていそうですが、WordPressはこのフォルダから静的リソースを読み込むため予期しない不具合が発生します。例えばブロックエディターが開かない、JavaScriptが読み込まれない、デザインが崩れるなどの問題につながります。
テストせず本番投入
.htaccessやNginx設定のミスは、わずかな誤記でも500 Internal Server Errorを引き起こします。特にアクセス数の多いサイトでは、ルールを即時本番化するのは危険です。事前にバックアップを取り、可能ならステージング環境で検証し、その後慎重に本番反映しましょう。ホスティングによってはステージングやバックアップ機能がある場合、ウェブホスティングバックアップ の内部リンクも自然です。
セキュリティプラグイン依存
プラグインは有効ですが、Webサーバレベルのルールはより早い段階で機能します。PHPに到達する前にApacheやNginxで遮断できれば、サーバリソース消費も抑えられます。したがって、プラグイン導入後も基本的なサーバ設定を怠らないことが重要です。
実施前のチェックリスト
wp-includesアクセス制限前に準備をしておくと、予期せぬトラブルのリスクを大幅に軽減できます。特に本番稼働しているWordPressサイトでは以下のチェックリストを推奨します:
- 現状の.htaccessまたはNginx設定ファイルのバックアップを取得
- WordPressコア、テーマ、プラグインを最新版に更新
- PHPバージョンがサポート&安全なものか確認
- ファイル権限の確認:フォルダは通常755、ファイルは644
- wp-config.phpや.htaccessなど重要ファイルの書き込み権限を無駄に開放しない
- キャッシュ、CDN、セキュリティプラグイン導入時は変更後のキャッシュクリアを計画
- 管理画面、トップページ、記事ページ、問い合わせフォーム、決済ページなど重要部分のテストリスト作成
これらの準備は10~15分程度で完了しますが、ミスによる数時間~数日の障害を未然に防げます。企業サイトなどではアクセスが少ない時間帯に実施するのがより安全です。
Apacheで.htaccessを用いたwp-includes PHP制限
Apache系の共有ホスティングでは、.htaccessファイルでの設定が一般的です。WordPressルートにある.htaccessにルールを追加することで、wp-includes内の特定PHP実行を遮断できます。作業前に必ずファイルのコピーをローカルに保存、もしくはホスティングのファイルマネージャーでバックアップを作成しましょう。
推奨.htaccessルール
以下の設定は、wp-includes配下のPHPへの直接アクセスのみをブロックし、静的ファイルの動作は維持します:
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule ^wp-includes/.*[.]php$ - [F,L]
</IfModule>
このルールは「URLがwp-includesで始まり、.phpで終わる場合はアクセス拒否する」仕組みです。これによりwp-includes内のPHPファイルはブラウザから直接呼び出せません。一方で、.jsや.css、.png、.svgなどの静的ファイルは引き続きアクセス可能です。WordPressフロント・管理画面の安定運用に最適なバランスです。
ディレクトリリスト表示の無効化
重要な設定の一つがディレクトリリスト表示の遮断です。サーバでディレクトリリスト表示が許可されていると、フォルダ内のファイル構成が見えてしまうことがあります。ルート.htaccessに以下を追加するだけでOKです:
Options -Indexes
この一行で、indexファイルがないディレクトリでファイルリストが表示されなくなります。最近のホスティングでは初期設定で無効化されていることも多いですが、念のため確認するのは良い習慣です。
設定後のテスト
ルール追加後は以下のテストを行いましょう:
- site.com/wp-includes/にアクセスしてディレクトリリストが表示されないか確認
- wp-includes配下の既知PHPファイルを直接呼び出して403/404になるか確認
- トップページ、記事ページ、管理画面が正常動作するかチェック
- ブラウザの開発者ツール(Console/Network)で404や403リソースエラーが出ていないか確認
- キャッシュやCDN導入サイトはキャッシュをクリア
テストが全て合格なら設定を本番運用して問題ありません。万が一500エラーが出た場合は、追加した記述を削除してバックアップの.htaccessに戻すことで迅速に復旧できます。
Nginxでwp-includesのPHP実行制限
Nginx系のVPSや専用サーバ、マネージドサーバ環境では.htaccessが使えません。設定はNginxのサイト構成ファイル(server block)内に追加します。SSHアクセスと設定ファイルの編集権限が必要なので、自信がない場合はホスティングのサポートへ相談するのが安全です。
推奨Nginx locationルール
基本ルールは以下のように記述します:
location ~* ^/wp-includes/.*[.]php$ {
deny all;
}
このルールでwp-includes配下のPHPへのリクエストを拒否できます。設定変更後は必ず構文チェックを行いましょう:
nginx -t
テスト合格後はNginxをリロードします:
systemctl reload nginx
reloadはrestartよりも接続を切らずに設定反映できるため、クリティカルなサイトでは推奨されます。やはりアクセスが少ない時間帯に実施するのが安全です。
Nginx運用時の注意点
- 正しいserver blockにルールを追加しているか確認(複数サイトある場合要注意)
- CDNやリバースプロキシ利用の場合、キャッシュクリア後に実際のテストを行う
- PHP-FPM設定で不要なファイルまで処理していないか確認
- ログファイル(access.log/error.log)でルールミスがないかチェック
Nginx環境ではlocationの順序ミスが予期せぬ挙動を招くことがあるため、WordPressパーマリンクやPHP処理ブロックと競合しないように注意しましょう。
各方法の比較
wp-includesアクセス制限に利用される主な手法を以下の表にまとめます:
| 方法 | 適用環境 | メリット | 注意点 |
|---|---|---|---|
| .htaccessルール | Apache/LiteSpeedホスティング | 設定が簡単、共有環境でも利用可能 | 構文ミスで500エラー発生リスク |
| Nginx locationルール | VPS/専用/マネージドサーバ | サーバレベルで強力・高パフォーマンス | SSHと設定知識が必要 |
| セキュリティプラグイン | 技術知識が少ないユーザー | UIから簡単管理 | 全てのルールがサーバレベルで適用されるとは限らない |
| WAF/CDN | 高トラフィック/攻撃対象サイト | Botや悪質リクエストを早期フィルタ | ルールミスで正規ユーザーが排除される場合あり |
| ファイル権限設定 | 全WordPressサイト | 基本的なセキュリティ衛生 | URLアクセス自体は遮断できない |
実際には複数の方法を組み合わせることで最大の効果が得られます。例:Apache環境で.htaccessルール+適切なファイル権限+最新WordPressコア+SSL+定期バックアップを組み合わせれば多層防御が完成します。ホスティング基盤のファイアウォールや隔離も重要なので、法人ホスティング の選択が重要なケースもあります。
ファイル権限と所有権設定
wp-includesアクセス遮断は、ファイル権限が不適切だと効果が弱まります。WordPressにおける一般的な推奨権限はフォルダ755、ファイル644です。これはWebサーバがファイルを読み込める一方、無駄な書き込み権限を減らす目的です。特殊なホスティング環境ではユーザーやグループ構成が異なる場合もあるので、管理パネルの推奨値も確認してください。
特に777権限は重大なリスクです。誰でも書き込み可能な状態は、悪意あるファイルアップロードを容易にします。wp-content/uploadsなど書き込みが必要なディレクトリでも、PHP実行は必ず制限しましょう。wp-includesは通常、WordPressアップデート以外でユーザーが書き込む必要はありません。
セキュリティチェック時には以下を確認:
- wp-includesフォルダ:通常755
- wp-includes内PHPファイル:通常644
- wp-config.php:可能なら600やホスティング構成に合わせた制限権限
- .htaccess:通常644、編集後は無駄な書き込み権限を外す
これらの設定はサーバ環境によって挙動が異なる場合があります。権限ミスはアップデート不可やファイル読込不可につながることも。変更後はWordPressのヘルスチェックやエラーログを必ず確認しましょう。
セキュリティプラグインが自動で対応する?
WordfenceやiThemes Securityなどのセキュリティプラグインは、一定のハードニングルールを自動適用することがあります。これらのプラグインはブルートフォース対策、ファイル変更監視、マルウェアスキャン、ログイン保護など多くの機能が便利ですが、wp-includesアクセス制限については実際に何をしているか要確認です。
一部プラグインは.htaccessへ自動ルール追加しますが、アプリケーションレベルでのみ保護する場合もあります。アプリケーションレベルの保護は、リクエストがWordPressまで到達してから機能するため、サーバレベルの遮断ほど早期ではありません。そのため、プロフェッショナルな運用ではプラグイン+サーバ設定を併用するのが理想です。
プラグイン利用時は以下をチェック:
- .htaccessやNginxルールを追加しているかどうか確認
- 同じ保護ルールが複数重複しないか確認
- プラグインアップデート後にセキュリティ設定が変化していないか確認
- キャッシュやサーバリソース使用量への影響も監視
複数のセキュリティプラグインを併用すると、ファイアウォールやログイン、リライトルールが競合し、パフォーマンス低下や誤ブロックにつながることがあるため注意しましょう。
wp-includes保護のテスト:実践シナリオ
設定成功かどうかは単にサイトが表示されるだけでは判断できません。以下7ステップの実践テストは、中小企業サイトからECサイトまでほとんどのWordPress環境で活用できます:
- 1. トップページをシークレットウィンドウで開き、デザイン崩れがないか確認
- 2. ブログ記事、カテゴリページ、検索結果ページを巡回
- 3. 管理画面(wp-admin)ログイン後、ブロックエディターやメディアライブラリを開く
- 4. ブラウザ開発者ツールのConsoleをチェック
- 5. Networkでwp-includes配下の静的ファイルが正しく読み込まれているか確認
- 6. wp-includes配下のPHPファイルを直接呼び出し、403または404レスポンスを期待
- 7. サーバエラーログに新規・繰返しエラーがないか確認
このテストは約5分で完了し、設定ミスを迅速に発見できます。特にWooCommerceなど決済機能付きサイトではカート・決済・ユーザーアカウントページも追加テスト推奨。動作しないJavaScript一つでもコンバージョンに影響するので細心の注意を払いましょう。
追加のWordPressディレクトリ構造セキュリティ対策
wp-includes保護は出発点ですが、WordPressセキュリティは全体的な視点が重要です。以下の追加対策で攻撃面をさらに縮小できます:
- WordPressバージョンの隠蔽よりコアの最新版維持を優先
- 未使用テーマやプラグインは完全に削除
- 管理ユーザー名は推測困難なものに
- 二要素認証を導入
- XML-RPCを利用しないならアクセス制限
- wp-login.phpへレートリミットや追加認証を設定
- 日次バックアップと復旧テストの実施
- サイト全体にHTTPS適用(SSL未導入は認証情報漏洩リスク)
SSLはwp-includesアクセス制限自体には直接関係しませんが、ユーザーセッションやフォーム送信、管理画面通信の基本的な保護となります。WordPressセキュリティガイドではSSLが必ず最初の層として推奨されるため、SSL証明書購入 や 無料SSLインストール のリンクも自然な流れで設置できます。
プロのサポートが必要なタイミング
単純なApache環境で.htaccessルールを追加するだけなら多くのユーザーが自己対応可能です。しかし、特殊なNginx構成やマルチサイトネットワーク、WooCommerceストア、高トラフィックニュースサイト、企業ポータルの場合は専門家のサポートを推奨します。セキュリティルールは技術的に正しいだけでなく、業務継続性も考慮した上で安全に適用される必要があります。
以下のケースでは専門家による支援を検討しましょう:
- サーバ上で複数のWordPressサイトを運用している場合
- Nginx/Varnish/CDN/WAFを併用している場合
- 設定変更後に403/404/500エラーが急増した場合
- 過去にマルウェア感染経験がある場合
- 決済や会員管理、個人情報を扱うシステムの場合
安全なホスティング基盤、適切な隔離、定期バックアップ、専門家サポートはWordPressセキュリティの不可視ながら重要な要素です。ホスティング選定時は単なるディスク容量だけでなく、バックアップ・ファイアウォール・PHPバージョン対応・SSL管理・サポート品質もチェックしましょう。Hostragons ホスティングパッケージ や WordPressサイト移行 の記事も参考になります。
まとめ
WordPressディレクトリ構造のセキュリティ対策としてwp-includesフォルダのアクセス制限を行う際、フォルダ全体の遮断ではなく、wp-includes内のPHPファイルへのWeb経由の直接アクセス遮断とディレクトリリスト表示の無効化が正解です。Apacheなら.htaccess、Nginxならlocationルールで短時間で対応可能ですが、毎回バックアップ取得と管理画面・フロントの動作テストを忘れずに。
要点:静的ファイルを壊さず、PHPアクセスを制限し、ディレクトリリスト表示を遮断、ファイル権限を確認、定期更新を徹底。より安全で管理しやすいWordPress運用のため、Hostragonsのホスティング・ドメイン・SSLソリューションも検討し、必要に応じて専門家のサポートを活用しましょう。
よくある質問
wp-includesフォルダを完全に遮断するのは安全ですか?
基本的には推奨されません。wp-includesにはWordPressが必要とするJavaScriptやCSS、静的ファイルが含まれる場合があります。完全遮断するとサイト表示や管理画面が崩れる恐れがあります。より安全な方法は、このフォルダ内のPHPファイルへの直接アクセスだけを制限することです。
.htaccessルール追加後に500エラーが出た場合の対処法は?
まず追加したルールを削除するか、バックアップの.htaccessを復元してください。その後、構文ミスがないか再確認します。エラーが解消しない場合はホスティングのエラーログをチェックし、技術サポートに相談しましょう。
Nginx環境で.htaccessは使えますか?
いいえ。.htaccessはApacheやLiteSpeedでのみ有効です。Nginxサーバでは同様の制限をserver block内のlocationルールで設定し、nginx -tで構文チェックを行う必要があります。
この対策だけでWordPressサイトは完全に安全になりますか?
いいえ。wp-includesのPHPアクセス遮断は重要な防御層ですが、単独では十分ではありません。コア・プラグイン・テーマの更新、強力なパスワード、二要素認証、SSL、バックアップ、ファイアウォール、適切なファイル権限も併用してください。
セキュリティプラグイン導入時にもwp-includes制限ルールを追加すべきですか?
プラグインによって設定内容が異なります。一部は.htaccessルールを追加しますが、アプリケーションレベルのみ保護するものもあります。競合しない範囲でサーバレベルのPHPアクセス遮断を設けるのが、より強力な対策となります。