【動作確認済み環境】
・WordPress：6.5
・PHP：8.2
・確認日：2026年4月
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

「サイトの表示が少し遅い気がする」「セキュリティ対策は今のままで十分なのか不安がある」というご相談を、実際の保守案件の現場でも頻繁にいただきます。

Web制作において、高速化と堅牢なセキュリティ体制は表裏一体の課題です。過度な防御が速度を犠牲にすることもあれば、速度優先の構成が脆弱性を生むケースも少なくありません。

本記事では、10年以上のWeb制作実務の中で実際に採用し、安定稼働を続けている速度改善の計測手法から納品後の防御策までをシェアします。日々の運用や案件での判断基準としてお役立てください。

【この記事でわかること】
・表示速度の遅延原因を特定する計測手法と具体的な改善の手順がわかります
・実案件で導入しているセキュリティ対策の取捨選択の判断基準がわかります
・テーマ更新時のサイト崩れを防ぎ、安全に保守を行うための手順がわかります
・ブロックテーマ環境で不要なスクリプト読み込みを回避する方法がわかります
・納品後のトラブルを未然に防ぐための防御策の構築方法がわかります

1. 表示速度の遅延を解消するための具体的な計測手法と改善策

【動作確認済み環境】
・WordPress：6.4.3
・PHP：8.1
・確認日：直近の検証環境にて
・テーマ：Lightning
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

サイトの表示が遅いという相談は、実際の案件でも非常に多くいただきます。特に画像が多かったり、プラグインを多数追加しているサイトでは、表示に数秒かかってしまうケースも珍しくありません。表示速度の遅延は離脱率に直結するため、感覚ではなく正確な数値をもとに対策を立てる必要があります。

この記事のパートでは、以下の内容がわかります。
・表示速度を正確に計測するツールの選び方がわかります
・ボトルネックとなっている原因の特定方法がわかります
・実務で使える具体的な改善策の判断基準がわかります

表示速度を改善する際、まず行うべきは「現状の正確な把握」です。PageSpeed Insightsなどの計測ツールを使用し、現状のスコアと遅延の原因となるリソースを特定します。

よくある改善策として、画像の軽量化（WebP形式への変換など）や、ブラウザキャッシュの活用が挙げられます。たとえば、`.htaccess`（サーバーの動作を制御する設定ファイル）に以下のようなキャッシュ設定を記述することで、リピーターの表示速度を向上させることができます。

“`apache

ExpiresActive On
ExpiresByType image/jpeg “access plus 1 months”
ExpiresByType image/png “access plus 1 months”
ExpiresByType image/webp “access plus 1 months”
ExpiresByType text/css “access plus 1 weeks”
ExpiresByType application/javascript “access plus 1 weeks”

“`

この記述を追加する理由は、ブラウザ側に一度読み込んだファイルを記憶させることで、次回以降の通信量を減らし、サーバーの負担を軽減するためです。内部的には、サーバーがブラウザに対して「このファイルは指定した期間内なら再ダウンロードしなくてよい」という指示を出しています。

以前、画像が大量にあるコーポレートサイトの案件で、ページ読み込みに著しく時間がかかる問題に当たりました。その時の解決策が、上記のような適切なキャッシュ設定と、画像の遅延読み込み（Lazy Load）の併用です。手当たり次第にプラグインを入れるのではなく、サーバー側の設定を見直すことで、無駄な処理を減らし安定した速度改善を実現できました。

やりがちですが避けた方がよい方法として、複数のキャッシュプラグインを同時に入れることが挙げられます。プラグイン同士が競合してサイトの表示が崩れたり、逆に処理が重くなったりするトラブルを何度も見てきました。

キャッシュ設定や画像最適化を行う際の判断基準は以下の通りです。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| .htaccessでのキャッシュ | サーバーの直接操作が可能な場合 | 共有サーバーで編集権限がない場合 |
| キャッシュプラグインの導入 | 手軽に設定を管理したい場合 | すでにサーバー側でキャッシュ機能が有効な場合 |
| 画像のWebP化 | 新規アップロード画像が多い場合 | 古いブラウザからのアクセスが大半を占める場合 |

長期的に見て、WordPressの高速化はコア機能のアップデートに依存する部分も大きいです。メジャーアップデートによって標準機能で対応できる範囲が広がる傾向にあるため、過剰にサードパーティのプラグインに依存する設計は、保守性の観点から推奨できません。

迷ったときは、まず「画像サイズの最適化」と「不要なプラグインの削除」という、シンプルでリスクの少ない方法から試すと考えが整理しやすいです。正解は一つではないため、現状のサーバー環境とサイトの要件を照らし合わせて選択してください。

Web制作や保守運用に関するご相談はお気軽にeBIZクリエイトまでお問い合わせください。

2. 実務で採用しているセキュリティ対策の判断基準と設定手順

【動作確認済み環境】
・WordPress：6.4.3
・PHP：8.1
・確認日：最新
※環境によって動作が異なる場合があります。必ず検証環境でお試しください。

実際の案件で「セキュリティ対策はどこまでやればいいのか」というご相談をよくいただきます。サイトの規模や運用体制によって適切な対策レベルは異なりますが、実務において基準としている設定手順をシェアします。

管理画面へのアクセス制限（Basic認証とIP制限）

WordPressのセキュリティ対策として、まず検討するのが管理画面（wp-admin）やログインページ（wp-login.php）へのアクセス制限です。

以前、会員制サイトの案件で、海外からの不正アクセス（ブルートフォースアタック）が急増し、サーバーの負荷が跳ね上がったトラブルがありました。その時の解決策として、そして現在うちの案件のデフォルト設定として採用しているのが、`.htaccess`（サーバーの動作を制御する設定ファイル）を使ったアクセス制限です。

具体的な設定コード

以下のコードは、サーバーのドキュメントルートにある`.htaccess`に追記します。特定のIPアドレスからのみログイン画面へのアクセスを許可する設定です。

“`apache

Order Deny,Allow
Deny from all
Allow from 192.168.1.100

“`

この書き方が推奨される理由は、WordPressのシステム（PHP）が動く前の段階でサーバー（Apacheなど）が通信を遮断するため、サーバーリソースの消費を最小限に抑えられるからです。プラグインで防御する場合、一度WordPressを起動して判定するため、大量のアクセスがあると結局サーバーが重くなってしまいます。

XML-RPCの無効化

もう一つ、実務で標準的に行っているのがXML-RPC機能の無効化です。XML-RPCは外部のアプリからWordPressを操作するための機能ですが、現在ではREST API（外部からWordPressのデータにアクセスするための新しい仕組み）が主流となり、悪用のリスクが高まっています。

これも`.htaccess`に記述して遮断します。

“`apache

Order Deny,Allow
Deny from all

“`

導入時の判断基準と注意点

IP制限は非常に強力ですが、運用環境によっては適さない場合があります。以下に判断基準を整理しました。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| IPアドレス制限 | 会社の固定IPがある場合、更新担当者が限られている場合 | スマホから更新する場合、ノマドワークなどIPが頻繁に変わる場合 |
| Basic認証 | IPが固定できないが、関係者のみアクセスさせたい場合 | 会員がフロントエンドからログインする機能がある場合 |

スマホからの更新が必須なケースではIP制限が使えないため、ログインURLを変更する対策や、二段階認証を導入する方向に切り替えます。状況に合わせて使い分けることが重要です。

長期的な視点でのセキュリティ運用

長期的に見て、WordPressのコアファイルやプラグインを常に最新状態に保つこと以上のセキュリティ対策はありません。複雑な設定を重ねるよりも、まずは「不要なプラグインを入れない」「使っていないテーマは削除する」といった基本的な整理整頓が、メジャーアップデート時のトラブルを防ぎ、保守性を高めることにつながります。

迷ったときは、以下のように考えると整理しやすいです。

・固定IPがあるか確認する
・更新作業を行う場所とデバイスを洗い出す
・それに合わせてサーバーレベルの制限（IP制限・Basic認証）か、アプリケーションレベルの制限（二段階認証など）かを選択する

サイトの運用体制に合わない厳格なセキュリティは、結果的に日々の業務の妨げになってしまいます。運用とのバランスを見極めて設定を組み立ててみてください。

3. テーマのアップデート時にサイト崩れを防ぐための安全な保守手順

テーマのアップデート通知が来て、ボタンを押した途端にレイアウトが大きく崩れてしまった。そんな冷や汗をかくような経験はありませんか。保守運用のご相談をいただく際、非常に多く耳にするトラブルの一つです。

テーマを直接カスタマイズしていると、アップデートの際に元のファイルが上書きされ、追加したCSSやPHPの記述がすべて消えてしまいます。これを防ぐための安全な手順が、child theme（子テーマ：親テーマを継承しつつ独自のカスタマイズを安全に行う仕組み）の導入です。

正直に言うと、私自身も過去に直接親テーマのstyle.cssを編集してしまい、数カ月後のアップデートでデザインがリセットされてしまった失敗経験があります。それ以来、カスタマイズを加える案件では、必ず子テーマを作成することを実務のデフォルトにしています。

子テーマを正しく機能させるためには、子テーマのディレクトリ内に`style.css`と`functions.php`（テーマの機能を追加・カスタマイズするファイル）を用意します。以下は、親テーマのスタイルシートを安全に読み込むための基本的な記述例です。

“`php
get(‘Version’) // キャッシュ対策としてバージョンを付与
);
}
“`

この書き方が推奨される理由は、WordPressの標準的な読み込み順序に則っているためです。昔は子テーマの`style.css`内で`@import`を使って親テーマを読み込む方法がよく見られましたが、現在ではページの読み込み速度を低下させる要因となるため、非推奨とされています。高速化を考慮するなら、必ず`functions.php`の`wp_enqueue_scripts`フックを使用してください。

また、アップデート前に必ず検証環境（ステージング環境）でテストを行うことも重要です。本番環境で直接アップデートを行うのは、どれほど慣れた作業であってもリスクが伴います。

以下に、子テーマでのカスタマイズが向いているケースと向いていないケースを整理しました。迷ったときの判断基準として活用してください。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| 子テーマの利用 | 既存テーマのデザインや機能を少しだけ調整したい場合 | テーマの根本的な構造やHTMLタグから全面的に書き換えたい場合（独自テーマ開発の方が適切） |

サイトを長期的に安全に運用するためには、アップデートを恐れずに実行できる環境づくりが欠かせません。子テーマを活用し、検証環境でのテストを徹底することで、保守性は飛躍的に向上します。ぜひ、今後の制作やメンテナンスの軸として取り入れてみてください。

4. ブロックテーマ環境下における不要なスクリプト読み込みの回避法

フルサイト編集（FSE）に対応したブロックテーマを利用する案件が増えてきました。それに伴い、制作現場でよく直面するのが「使っていない標準ブロックのCSSやスクリプトまで全ページで読み込まれてしまう」という課題です。ページスピードインサイトなどの計測ツールで、使用していないリソースの除外を指摘された経験をお持ちの方も多いのではないでしょうか。

ブロックテーマは非常に便利ですが、初期状態ではWordPress本体が持つすべてのブロック用スタイルシート（wp-block-libraryなど）が出力される仕組みになっています。実務のコーポレートサイト制作などでは、独自のスタイルを適用するために標準のスタイルを無効化したいケースが多々あります。ここでは、不要なリソース読み込みを回避し、表示速度を向上させるための具体的なアプローチをシェアします。

以下のコードは、functions.php（テーマの機能を追加・カスタマイズするファイル）に記述して、フロントエンドでのみ不要なブロックスタイルを解除する方法です。

“`php
// functions.php に記述します
// フロントエンドでのみブロックスタイルを解除する
add_action( ‘wp_enqueue_scripts’, ‘remove_unused_block_styles’, 100 );
function remove_unused_block_styles() {
// 管理画面では解除しない（エディターの表示崩れを防ぐため）
if ( is_admin() ) {
return;
}

// WordPress標準のブロックライブラリCSSを解除
wp_dequeue_style( ‘wp-block-library’ );
wp_dequeue_style( ‘wp-block-library-theme’ );

// WooCommerceを使用している場合の標準ブロックスタイルも解除（不要なら削除可）
wp_dequeue_style( ‘wc-blocks-style’ );
}
“`

この書き方が推奨される理由は、管理画面（エディター側）のスタイルを維持しつつ、閲覧者側の表示速度だけを改善できるからです。WordPressの処理に割り込んで独自の処理を追加する仕組みであるhooks（フック）の中でも、スタイルやスクリプトを読み込むタイミングである`wp_enqueue_scripts`を使用しています。優先順位を`100`と遅めに設定することで、他のプラグインが読み込んだ後に確実に解除できるようにしています。

以前、表示速度改善の案件で、単純にすべてのブロックスタイルを無効化したところ、クライアントから「記事編集画面の見た目がおかしくなった」と連絡を受けたことがありました。エディター側のスタイルまで解除してしまったことが原因です。それ以降、`is_admin()`関数による条件分岐は必ずセットで行うようにしています。

また、やりがちな間違いとして、テーマのstyle.cssで`!important`を多用して標準スタイルを上書きしようとするアプローチがあります。これはCSSの記述量が増えるだけでなく、ブラウザのレンダリング負荷も上がるため推奨できません。根本から不要なファイルを読み込まない設計が、パフォーマンス最適化の基本となります。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| 標準ブロックスタイルの解除 | オリジナルのCSSでデザインを完全に制御したい場合 | コアブロックのデザインをそのまま活かして構築したい場合 |

長期的な視点で保守性や将来性を考えると、WordPressのアップデートによって標準ブロックのクラス名や構造が変更されるリスクは常に存在します。独自のスタイルで完全に制御しておけば、コアアップデートによる予期せぬ表示崩れを防ぐことにもつながります。

迷ったときは、サイト全体のデザイン方針を確認してください。「標準ブロックの見た目を活かして手軽に作る」なら解除せずそのまま使用し、「ピクセルパーフェクトでオリジナルデザインを再現する」なら思い切って解除する、という判断基準を持っておくと設計がスムーズになります。

5. 納品後のトラブルを未然に防ぐための堅牢な防御策の構築方法

Web制作の現場で納品後に起こるトラブルの中で、もっとも対応が難しく、クライアントの信頼を損ないかねないのがセキュリティインシデントです。実際の案件でも、納品から数ヶ月後に「サイトが改ざんされた」「身に覚えのないスパムメールが大量に送信されている」といったご相談をいただくことがあります。

ここでは、実案件で納品前に必ず実施している、堅牢な防御策の構築方法をシェアします。

ログイン画面の保護と二段階認証の導入

WordPressのデフォルトのログインURLは広く知られているため、ブルートフォース攻撃（総当たり攻撃）の標的になりやすいです。まずはログイン画面へのアクセスを制限し、二段階認証を導入することが基本となります。

実務では、プラグイン「Wordfence Security」を活用してログイン画面の保護を行っています。設定画面から二段階認証を必須にする項目を有効化することで、パスワードが流出した場合でも不正ログインを防ぐ仕組みを構築できます。

wp-config.phpと.htaccessのアクセス制限

WordPressの基本設定ファイルである「wp-config.php」や、サーバーの動作を制御する「.htaccess」には、データベースの接続情報などの重要なデータが含まれています。これらのファイルへの外部からのアクセスを遮断することは、セキュリティ対策の土台となります。

.htaccessファイルに以下のコードを追記し、wp-config.phpへのアクセスを拒否する設定を行います。

“`apache

Require all denied

“`
※.htaccessファイルの編集はサイト全体に影響を与えるため、必ず事前にバックアップを取得してから実施してください。

なぜこの設定が必要なのか

WordPressは世界中で利用されているため、攻撃の自動化スクリプトが多く存在します。攻撃者は常に脆弱性を探し、ログインの試行や設定ファイルへの直接アクセスを試みます。

「Require all denied」を記述することで、Webサーバー（Apacheなど）のレベルでアクセスを弾くことができます。アプリケーション層（WordPress内部）に到達する前に通信を遮断できるため、サーバーの負荷軽減にもつながり、高速化の観点でも有効な手段となります。

実案件での失敗談と対策

以前の案件で、海外からのアクセスを一律で制限するIP制限を導入したことがあります。しかし、クライアントが海外出張中にサイトの更新ができなくなるというトラブルが発生しました。

セキュリティを強固にすることは重要ですが、運用者の利便性を著しく損なう設定は、結果的に運用フローの破綻を招きます。この経験から、一律のIP制限ではなく、二段階認証の導入や、異常なログイン試行を検知して一時的にブロックする動的な防御策を採用するようになりました。

導入手法の向き・不向き

実務での状況に合わせて、適切な対策を選択できるように表に整理しました。

| 項目 | 向いているケース | 向いていないケース |
|——|—————-|——————|
| 二段階認証の導入 | 複数人でサイトを管理する場合 | 管理者が頻繁に入れ替わり、引き継ぎが困難な場合 |
| ファイルのアクセス制限 | すべてのWordPressサイト | サーバーの仕様で.htaccessの編集が禁止されている場合 |
| ログインURLの変更 | 特定の管理者のみがログインする場合 | 会員制サイトなどで、一般ユーザーもログイン画面を利用する場合 |

保守性と将来性から見た判断基準

WordPressの本体（コアファイル）やプラグインは定期的にアップデートされますが、セキュリティの脅威も日々進化しています。特定のプラグインの機能に依存しすぎると、そのプラグインの開発が停止した際に一気に無防備になるリスクがあります。

そのため、サーバーレベルでのアクセス制限（.htaccessの設定など）と、アプリケーションレベルの対策（プラグインによる二段階認証やファイアウォール）を組み合わせる多層防御の考え方が重要です。長期的な保守を見据えた場合、シンプルな設定ファイルによる制御は、メジャーアップデートの影響を受けにくく、将来にわたって機能し続ける信頼性の高い手法と言えます。

セキュリティ対策に終わりはありませんが、納品前の段階でこれらの基礎を固めておくことで、運用中のトラブルを大幅に減らすことができます。迷ったときは、運用者の利便性とシステムの安全性のバランスを考慮して設定を検討してみてください。