第1回: エラーログ解析でトラブルを即解決
📌 この記事の要点
- WordPress の復旧はエラーログを「読める」ことから始まる
- WP_DEBUG / WP_DEBUG_LOG / SCRIPT_DEBUG の使い分けと、Query Monitor / Xdebug で原因を絞り込む
- 真っ白画面(WSOD)はフローチャートと CLI 応急処置で順序通り復旧する
エラーログ解析は、白画面・PHP Warning・Fatal errorを感覚ではなく証拠で切り分けるための出発点です。この回では、最初に見るログ、次に疑う層、復旧前に残す記録を順番に固定します。
ログを開くと最初は呪文に見えますよね。でも行頭の u003ccodeu003e[error]u003c/codeu003e や u003ccodeu003eFatal error:u003c/codeu003e をパターン化すれば、9 割の事例は数行で当たりがつきます。最後まで読むと、その「最初の数行」が変わって見えるようにします。
WordPressで突然サイトが動かなくなったとき、多くの上級者は「原因がわからない」と頭を抱えます。
しかし、エラーログを活用すれば、その悩みは「すぐ」に「正確に」解消できるのです。
たとえば、真っ白画面(WSOD)や致命的なエラーが出た場合でも、ログを見れば一発で原因が特定できることがほとんど。
この記事では、初動対応として最も効果的なエラーログ解析の基本から、実践的なツール、そして状況別の診断法までを、上級者向けにわかりやすく解説します。
初心者向けの入門ではなく、現場で即戦力となるノウハウだけを厳選しました。
✅ なぜエラーログを見るべきなのか?
WordPressでエラーが起きた場合、エラー内容はPHPの内部で処理されており、画面上には表示されないことがほとんどです。
そのままでは原因が分からず、対処のしようがありません。
そんなとき、debug.logを確認すれば──
- 何が原因で
- どこで(ファイル・行番号)
- いつ発生したか
が明確にわかり、トラブル対応のスピードと正確さが一気に上がります。
WordPressトラブル解決: デバッグモードで原因を即特定
WordPressのトラブル解決において、デバッグモードは最初に頼るべき強力な味方です。
なぜなら、この機能を有効化することで、画面に現れないエラーの詳細を確実に把握できるからです。
たとえば、プラグインの競合やテーマの不具合でサイトがダウンしたとき、デバッグモードがなければ手探りで対応するしかありません。
ところが、wp-config.phpに数行のコードを追加するだけで、状況が一変します。
以下を設定してみましょう:
// wp-config.php に追記
define('WP_DEBUG', true); // 全体のデバッグモード
define('WP_DEBUG_LOG', true); // wp-content/debug.log に出力
define('WP_DEBUG_DISPLAY', false); // 本番では false 推奨
@ini_set('display_errors', 0); // エラーをブラウザに表示させない
define('SCRIPT_DEBUG', true); // 開発版CSS/JSを読み込むPHPこの設定により、エラーがwp-content/debug.logに記録され、たとえば「Fatal Error: Call to undefined function」のような具体的なメッセージが確認できます。
さらに、SCRIPT_DEBUGをオンにすることで、JavaScriptやCSSの圧縮版ではなく開発版が読み込まれます。
🧩 実際に出力されるログの例(抜粋)
[23-Mar-2025 09:15:42 UTC] PHP Fatal error: Uncaught Error:
Call to undefined function get_header() in
/home/example/public_html/wp-content/themes/yourtheme/index.php:1TeX🕵️♂️ これでわかること:
- いつ? → 2025年3月23日 9:15
- どこで? →
/themes/yourtheme/index.phpの1行目 - 何が? →
get_header()が呼べない(関数が未定義)
このように、原因の特定が一目瞭然です。
🛠 ワンポイント補足
以下のように「本番と開発で切り替えやすくする」工夫が一般的です。
define('WP_DEBUG', getenv('WP_ENV') !== 'production');
define('WP_DEBUG_DISPLAY', getenv('WP_ENV') !== 'production');PHP.envファイル:
WP_ENV=productionINIこうすることで、.env ファイルやサーバー設定によって環境を制御し、本番で誤って表示されることを防ぎます。
📌注意点
- WP_DEBUG_LOGがONでもfile_put_contents()でエラーが出る場合、ファイルパーミッションと所有者をチェック。
(例:www-data:www-data) - SCRIPT_DEBUGはChild Theme開発時のスタイル崩れ調査に便利。
このログを基に即座に問題ファイルを特定し、次のステップに進めるはずです。
ここまでの表面的な使い方は既に知られていますが、以下のような誤用・漏れが現場では多発しますので、上級者は十分な配慮をしましょう。
🧨 ありがちな落とし穴
| 症状 | 原因 | 対処法 |
|---|---|---|
debug.logが出力されない | wp-content の書き込み権限不足 | chown www-data:www-data -R wp-content/ などで修正 |
| 表示されたエラーが本番ユーザーに見えてしまう | WP_DEBUG_DISPLAY が true のまま | 本番では必ず false に設定する |
| 設定してもエラーが見えない | php.iniで display_errors=Off になっている | サーバー側設定も確認する |
🔧 チェックリスト
| 項目 | 確認内容 |
|---|---|
wp-contentの権限 | www-data:www-data, 755(or 750)※ www-dataはサーバー環境により変わります |
| php.iniの確認 | display_errors, log_errors, error_log の状態 |
| マルチサイト構成 | 各サブサイトの個別テーマでも debug 記録可能か検証 |
WordPressリアルタイム解析でトラブルを深掘り: Query MonitorとXdebug
デバッグモードで基本的なエラーは見つかりますが、もっと複雑なトラブルにはリアルタイム解析が必要です。
たとえば、ページが異常に遅いときや、ログに残らない不具合に遭遇したとき、処理の「今」を把握しなければ解決は難しい。
ページ読み込みが5秒を超えた場合、Query MonitorでSQLクエリを調べたら、重複したSELECTが原因と判明し、インデックス追加で即解決した例もあります。
そこで登場するのがQuery MonitorとXdebugです。
Query Monitor
Query Monitorは、WordPress専用の無料プラグインで、サイトの内部動作を詳細に可視化します(公式サイト)。
SQLクエリの実行時間や呼び出されたテンプレート、フックの発火状況を一目で確認でき、たとえば、あるページでクエリが100回以上走っているとわかれば、データベースの最適化が必要だとすぐ判断できます。
✅ Query Monitor:SQLクエリ過剰の診断例
あるECサイトで「商品一覧ページが6秒超え」の原因を調査。Query Monitorで
WP_Queryが大量に発生しており、pre_get_postsフィルターが無限ループを引き起こしていた。修正後は1秒未満に改善したという事例。
Xdebug
XdebugはPHPのデバッグ拡張機能で、コードの実行をステップ単位で追跡するツールです(公式サイト)。サーバーに導入すれば、ブレークポイントで処理を止めたり、スタックトレースでエラーの流れを解析したりできます。
たとえば、カスタムプラグインの関数がどこで止まっているのか、リアルタイムで追跡可能。これらを併用すれば、ログだけでは見えない「動的な挙動」を捉え、トラブル解決が格段に早まります。
✅ Xdebug:スタックトレースでのデッドロック特定
会員機能でログイン後にWSOD(真っ白画面)が表示された。Xdebugでブレークポイント設定→
custom_auth_check()内で別ファイルのrequire_onceが二重呼び出しされていた。修正後、WSOD(真っ白画面)が解決したという事例。
サーバーログで隠れたトラブルを解明: NginxとApacheの違い
WordPressはPHPアプリケーションですが、Webサーバーとの連携が不可欠です。
そのため、サーバーログを確認することで、WordPressのログでは見えない深い原因がわかる場合があります。
たとえば、PHPの致命的なエラーやパーミッション問題がサーバーログに記録されていることはよくあります。
ここでは、代表的なサーバーであるNginxとApacheのログ活用を解説します。
Apacheは、オープンソースのWebサーバーで、WordPressのホスティングによく使われます(公式サイト)。
そのエラーログは通常/var/log/apache2/error.logに保存され、PHPエラーや設定ミスを確認できますが、ログの場所はサーバー設定による場合があります。
一方、Nginxは軽量かつ高速なWebサーバーとして人気で(公式サイト)、ログは/var/log/nginx/error.logに記録されますが、これも環境次第で異なることがあります。
たとえば、503エラーが出た場合、ログを見ると「リソース制限超過」や「不正アクセス」が原因だと判明することがあります。
上級者なら、この情報を基にサーバーの設定を調整したり、不正アクセス対策を強化したりできるはず。
| サーバー | エラーログパス例 | ログに期待する情報 |
|---|---|---|
| Apache | /var/log/apache2/error.log | PHP Fatal、.htaccessエラーなど |
| Nginx | /var/log/nginx/error.log | 403, 503, 502, リクエスト数過多 |
ログにIPアドレスが頻出する場合、fail2banで自動ブロックを設定すると効率的です。
fail2banとは?
Linuxサーバー上でログを監視し、特定の条件を満たしたIPアドレスを自動でブロック(BAN)するセキュリティツールです。
✅ 一言でいうと:
「ログイン失敗や不審なアクセスがあったら、すぐIPをBANする番犬ツール」

WordPress単体では解決できないトラブルも、サーバーログを活用すれば一気に道が開けます。
PHP8アップデート後に連鎖的に発生するWordPressトラブルとその診断法
PHP8.xへのアップデートは、WordPressに大きなパフォーマンス向上や将来性をもたらす一方で、既存コードやシステム構成に連鎖的なトラブルを引き起こす可能性があります。
とくに非推奨関数の廃止や型の厳格化、MySQLとの接続仕様変更などが絡むことで、
表面的なエラーだけでなく、深い階層で問題が連続的に発生することも少なくありません。
ここでは、そんな「アップデート後に起きやすい典型的な連鎖トラブル」と「その診断法」を、実践的に解説します。
💥 第一の症状:コードが突然壊れる(PHP8互換性エラー)
PHP8.xでは以下のような大きな仕様変更があり、従来正常だったコードがエラーを吐くことがあります:
| 原因 | 代表的なエラー | 補足 |
|---|---|---|
| 非推奨関数の削除 | create_function() は廃止 | クロージャで代替 |
| 厳格な型チェック | TypeError: Argument must be of type... | null や arrayとの比較が原因 |
| count()使用時のnull | count(): Argument must be of type Countable, null given | 初期化されていない変数が対象 |
🔧 対応の第一歩:ログを読む
wp-config.phpでWP_DEBUGとWP_DEBUG_LOGを有効にし、wp-content/debug.logに出力されたエラーログから原因を特定しましょう。
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);PHPこの時点で問題を解消すればベストですが――
🧨 第二の波及:データベース接続エラーが発生
PHP8に合わせてサーバー構成やミドルウェア(MySQL等)も変更した場合、データベース接続エラーが連鎖的に発生することがあります。
❗ よくあるエラーメッセージ:
Error establishing a database connection
🧠 主な原因とチェックポイント:
| 原因カテゴリ | 詳細 | 解決方法 |
|---|---|---|
| 認証情報の不整合 | wp-config.php の DB_USER や DB_PASSWORD が誤っている | MySQL CLIでログイン確認 |
| MySQL認証方式 | MySQL 8.0 既定の caching_sha2_password を古い PHP/mysqli 構成が解釈できない | mysql_native_password に切り替え |
| ソケット or ポート | localhost指定でソケットエラーが起きる | 127.0.0.1に切り替えなど |
| PHPのMySQL拡張 | mysqliが未インストール、または設定不一致 | `php -m |
🛠 解決コマンド例:
-- MySQLで接続可能なユーザーを作り直す例
CREATE USER 'wp_user'@'localhost'
IDENTIFIED WITH mysql_native_password BY 'password';
GRANT ALL PRIVILEGES ON wp_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;SQLDB接続エラーは、PHP側の変更によってMySQLとの整合性が崩れた“結果”として現れることが多いため、単なる設定ミスと片付けず、「バージョン変更に伴う接続仕様の変化」を疑う視点が重要です。
🎯 上級者の視点:問題は“単体”ではなく“因果連鎖”で考える
解決への流れ
PHP8アップデート
↓
コード互換性エラー(Fatal / Deprecated)
↓
環境全体見直し(MySQL更新 or 設定変更)
↓
DB接続エラー発生(認証方式 or 拡張の問題)
このように、表面的なエラー修正で満足していると、すぐに別の階層からエラーが噴き出すのがアップデートの怖さです。
✅ 診断のベストプラクティス(参考)
| タイミング | アクション | 使用ツール・方法 |
|---|---|---|
| アップデート前 | 現在のPHPバージョンと互換性を確認 | サーバー管理画面の「PHPバージョン切り替え」機能で確認。WordPress管理画面の「サイトヘルス」でもPHPバージョンや推奨環境がチェック可能。 |
| エラー発生時 | エラーログを確認して原因を特定 | サーバーの「エラーログ表示」機能、またはFTP/SFTPで /log/ドメイン名/error_log を参照。DeprecatedやFatalなどのエラーが出力される。 |
| DB接続不可時 | wp-config.php内のDB設定を確認 | FTP経由でwp-config.phpを開き、DB_NAME, DB_USER, DB_PASSWORD, DB_HOSTをチェック。特にMySQLのホスト名に注意(例:localhostや127.0.0.1) |
| 環境整合チェック | WordPressのサイトヘルスでシステム状況を把握 | WordPress管理画面 > ツール > サイトヘルス で、PHP拡張・DB接続・HTTPS設定などを確認。 |
| プラグイン・テーマの互換性 | アップデート前に段階的にテスト | 更新前にバックアップを取り、問題発生時にロールバックできるようにしておく。テーマを一時的に公式デフォルト(例:Twenty Twenty-Five)に切り替えてエラー発生箇所を切り分ける。 |
💡補足ポイント:
- SSHやWP-CLIが使えない環境では、ログ・ファイル確認と管理画面操作が中心になります。
error_logは、ドメインごとに分かれていることが多く、場所は/virtual/アカウント名/log/ドメイン名/や/home/アカウント/logs/等、ホスティングにより異なります。- PHP Compatibility Checkerなどの診断系プラグインは本番環境では使わず、テストサイトでのみ使用をおすすめします。
🛡 PHPバージョン更新時の安全な手順
- WordPressサイトを複製
(ステージング環境やテスト用ドメインを用意) - テスト環境でPHPのバージョンを変更
- ログを確認し、互換性エラーが出るかをチェック
- 問題なければ本番環境でも切り替え
- 万が一に備えて、バックアップと復元手段を明確にしておく
WSOD(真っ白画面)を即解決するフローチャート
WordPressで最も厄介なトラブルの一つが「WSOD(White Screen of Death)」、つまり画面が真っ白になる現象です。しかし、慌てず次の流れで原因を潰していけます。
● ACTION(実行) ● CHECK(判定) ● RESOLVED(復旧)
STEP 1 · ACTION
サイトにアクセス → 真っ白(WSOD)
STEP 2 · ACTION
wp-config.php を編集してデバッグを有効化
<?php
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
PHPSTEP 3 · CHECK
/wp-content/debug.log にエラーは記録されているか?
Yes → エラーメッセージ(Fatal/Parse error)を確認 → 該当ファイルを修正
No → STEP 4 へ
STEP 4 · CHECK
サーバーの error_log を確認(FTP or コントロールパネル)
Yes → PHP エラー内容から修正箇所を特定
No → STEP 5 へ
STEP 5 · ACTION
プラグイン由来の不具合を疑い、全て無効化
/wp-content/plugins/ を plugins_old にリネーム
STEP 6 · CHECK
サイトは復旧するか?
Yes → plugins_old 内のプラグインを 1 つずつ戻して原因を特定
No → STEP 7 へ
STEP 7 · ACTION
テーマが原因か確認
/wp-content/themes/ の使用中テーマフォルダをリネーム → デフォルトテーマ(例: twentytwentyfive)を有効化
STEP 8 · CHECK
サイトは復旧するか?
Yes → テーマ内の functions.php やテンプレートを調査
No → STEP 9 へ
STEP 9 · ACTION
WP-CLI が使える場合
wp plugin deactivate --all
wp theme activate twentytwentyfive
BashSTEP 10 · ACTION
CLI が使えない場合
phpMyAdmin で wp_options テーブルの active_plugins を空配列 a:0:{} に書き換え
✓ RESOLVED
サイト復旧
原因ファイルに絞り込み、修正 or 差し替え
上級者Q&A: 実践的なトラブル解決法
Q1. ログが数GBに肥大化したらどうする?
WordPressが長期間稼働すると、debug.logが肥大化し、ディスクを圧迫します。サイトの速度低下を防ぐには、定期的な管理が必須。
そこで、Linuxのlogrotateを活用しましょう。設定例は以下:
/var/www/html/wp-content/debug.log {
weekly
rotate 4
compress
missingok
notifempty
create 640 www-data adm
}TeXこれでログを週ごとに分割し、4週間分を圧縮保存。ディスクを効率的に保てます。
Q2. XSSの原因をどうやって見つける?
管理画面で不審なJavaScriptが動く場合、XSS(クロスサイトスクリプティング)を疑います。原因は、入力が適切にサニタイズされていないこと。
たとえば、$_GET['input']を直接echoすると危険です。代わりに:
echo esc_html($_GET['input']); // 安全に出力PHPPOST/GETパラメータや$_REQUESTを確認し、esc_attr()やwp_kses()で保護。
さらに、WordfenceのようなプラグインでWAFログをチェックすれば、不審な挙動を即検知できます。
おまけ
不正アクセスを繰り返しているIPアドレスをログファイルから抽出し、ApacheやNginxで使えるブロックリストを自動生成するツールを作成しました。
後述のPHPコードの使い方は こちら の記事を参考にしてください。


コードを表示する(IPブロックリスト生成ツール)
<?php
// ユーザーのIPアドレスを取得
$userIp = $_SERVER['REMOTE_ADDR'] ?? '不明';
/**
* フォーム表示関数(オシャレなCSSとスピナー付き)
*/
function showForm($error = '') {
global $userIp;
if ($error) {
echo "<p style='color:red; text-align:center;'>$error</p>";
}
echo <<<HTML
<style>
body {
font-family: "Segoe UI", sans-serif;
background: #f4f7f9;
padding: 40px 20px;
color: #333;
}
.container {
max-width: 600px;
background: #fff;
margin: auto;
padding: 30px 40px;
border-radius: 16px;
box-shadow: 0 8px 20px rgba(0,0,0,0.05);
}
h1 {
text-align: center;
font-size: 1.8rem;
margin-bottom: 25px;
color: #007bff;
}
label {
font-weight: bold;
margin-top: 10px;
display: block;
}
input[type="file"],
input[type="number"],
input[type="text"],
select {
width: 100%;
padding: 10px 12px;
margin: 6px 0 16px;
border: 1px solid #ccc;
border-radius: 8px;
box-sizing: border-box;
font-size: 1rem;
}
button {
width: 100%;
background: #007bff;
color: white;
padding: 12px;
font-size: 1rem;
border: none;
border-radius: 8px;
cursor: pointer;
transition: background 0.3s;
}
button:hover {
background: #0056b3;
}
#loading {
display: none;
text-align: center;
margin-top: 30px;
}
.spinner {
border: 6px solid #f3f3f3;
border-top: 6px solid #007bff;
border-radius: 50%;
width: 50px;
height: 50px;
margin: 0 auto 15px;
animation: spin 1s linear infinite;
}
@keyframes spin {
0% { transform: rotate(0deg); }
100% { transform: rotate(360deg); }
}
</style>
<div class="container">
<h1>ブロックリスト生成ツール</h1>
<p>ログファイルをアップロードして不正アクセスの疑いがあるIPアドレスのブロックリストを生成します。</p>
<form method="POST" enctype="multipart/form-data">
<label for="logfile">アクセスログファイル(.log):</label>
<input type="file" name="logfile" id="logfile" accept=".log" required>
<label for="threshold">上位表示するIPアドレスの件数:</label>
<input type="number" name="threshold" id="threshold" value="10" min="1" required>
<label for="exclude_ip">除外したいIPアドレス:</label>
<p style="font-size:12px;color:red;margin: 5px 0;">あなたのIPアドレス → <strong>{$userIp}</strong></p>
<input type="text" name="exclude_ip" id="exclude_ip" value="{$userIp}" placeholder="xxx.xxx.xxx.xxx">
<button type="submit">解析開始</button>
</form>
<div id="loading">
<div class="spinner"></div>
<p>解析中です。しばらくお待ちください…</p>
</div>
</div>
<script>
document.addEventListener("DOMContentLoaded", function () {
const form = document.querySelector("form");
const loading = document.getElementById("loading");
form.addEventListener("submit", function () {
loading.style.display = "block";
});
});
</script>
HTML;
}
/**
* IPアドレスの国情報を取得
*/
function getIpCountry($ip) {
$details = @json_decode(file_get_contents("http://ip-api.com/json/{$ip}?fields=country,countryCode"));
return isset($details->country, $details->countryCode)
? ['country' => mb_convert_kana(trim($details->country), 'KV'), 'is_foreign' => $details->countryCode !== 'JP']
: ['country' => '不明', 'is_foreign' => false];
}
// フォーム送信時の処理(ここから本処理)
if ($_SERVER['REQUEST_METHOD'] === 'POST') {
// アップロードチェック
if (!isset($_FILES['logfile']) || $_FILES['logfile']['error'] !== UPLOAD_ERR_OK) {
showForm("ログファイルのアップロードに失敗しました。正しいファイルを選択してください。");
exit;
}
$fileTmpPath = $_FILES['logfile']['tmp_name'];
if (!is_uploaded_file($fileTmpPath)) {
showForm("アップロードされたファイルが無効です。");
exit;
}
$logLines = @file($fileTmpPath);
if ($logLines === false) {
showForm("ログファイルの読み込みに失敗しました。");
exit;
}
$excludeIp = $_POST['exclude_ip'] ?? '';
$serverType = $_POST['server_type'] ?? 'apache';
$threshold = isset($_POST['threshold']) ? max((int)$_POST['threshold'], 1) : 10;
$suspiciousPatterns = ['wp-login.php', 'xmlrpc.php', '.htaccess', 'index.php', '.php'];
$userAgentKeywords = ['curl', 'python', 'bot', 'wget'];
$ipCounts = [];
foreach ($logLines as $line) {
if (preg_match('/^(d{1,3}(?:.d{1,3}){3})/', $line, $ipMatch)) {
$ip = $ipMatch[1];
if ($excludeIp && $ip === $excludeIp) continue;
$lowerLine = strtolower($line);
$isSuspicious = false;
foreach ($suspiciousPatterns as $pattern) {
if (strpos($lowerLine, $pattern) !== false) {
$isSuspicious = true;
break;
}
}
foreach ($userAgentKeywords as $keyword) {
if (strpos($lowerLine, $keyword) !== false) {
$isSuspicious = true;
break;
}
}
if (preg_match('/s(403|404|500)s/', $line)) {
$isSuspicious = true;
}
if ($isSuspicious) {
$ipCounts[$ip] = ($ipCounts[$ip] ?? 0) + 1;
}
}
}
arsort($ipCounts);
echo "<h2>不正アクセスの疑いがあるIPアドレスの一覧(アクセス数上位 {$threshold} 件)</h2>";
echo "<h3>※日本国外のIPアドレスは赤文字です</h3>";
echo "<ol>";
$ipGeoCache = [];
$blockedIps = [];
$count = 0;
foreach ($ipCounts as $ip => $accessCount) {
if ($count >= $threshold) break;
if (!isset($ipGeoCache[$ip])) {
$ipGeoCache[$ip] = getIpCountry($ip);
}
$country = $ipGeoCache[$ip]['country'];
$isForeign = $ipGeoCache[$ip]['is_foreign'];
$style = $isForeign ? "style='color:red;'" : "";
echo "<li $style><strong>$ip</strong>:{$accessCount} 回({$country})</li>";
$blockedIps[] = $ip;
$count++;
}
echo "</ol>";
if (!empty($blockedIps)) {
echo "<h2>ブロックリストの出力形式を切り替え</h2>";
echo "<p style='font-size:1rem;margin: 5px 0;'>Apache / Nginx 切替</p>";
echo "<select id='formatToggle' onchange='toggleFormat()'>
<option value="apache">Apache (.htaccess)</option>
<option value="nginx">Nginx (nginx.conf)</option>
</select><br><br>";
echo "<p>Apacheの場合は .htaccess または httpd.conf に貼り付けること。通常は .htaccess が推奨です。</p>";
echo "<p>Nginxの場合は server または location ブロックに貼り付けること。<br>あと次のコマンドも忘れずに<br>「nginx -t / nginx -s reload」</p>";
echo "<div id='apacheBlock' style='display:block;'>n";
echo "<h4>Apache用ブロックリスト</h4><textarea rows='10' style='width:100%; font-family:monospace;'>n";
echo "# Apache 2.4 以降用設定n";
echo "<IfModule mod_authz_core.c>n<RequireAll>n Require all grantedn";
foreach ($blockedIps as $bip) {
echo " Require not ip $bipn";
}
echo "</RequireAll>n</IfModule>nn";
echo "# Apache 2.2 用設定n";
echo "<IfModule mod_authz_host.c>n Order allow,denyn Allow from alln";
foreach ($blockedIps as $bip) {
echo " Deny from $bipn";
}
echo "</IfModule>n";
echo "</textarea></div>n";
echo "<div id='nginxBlock' style='display:none;'>n";
echo "<h4>Nginx用ブロックリスト</h4><textarea rows='10' style='width:100%; font-family:monospace;'>n";
foreach ($blockedIps as $bip) {
echo "deny $bip;n";
}
echo "allow all;n";
echo "</textarea></div>n";
echo "<script>
function toggleFormat() {
var format = document.getElementById('formatToggle').value;
document.getElementById('apacheBlock').style.display = format === 'apache' ? 'block' : 'none';
document.getElementById('nginxBlock').style.display = format === 'nginx' ? 'block' : 'none';
}
</script>";
}
} else {
showForm();
}
?>PHPまとめ
WordPressのトラブル対応において、「エラーログ」は医者にとってのレントゲンのようなもの。
今後どれだけAIツールが進化しても、“ログを読む力”は現場に立つ人間に求められ続けるスキルです。
AI駆動のログ解析ツールが登場しつつあり、たとえばGrokのようなAIがエラーログから自動で解決策を提案する時代も近い。
今のうちに手動解析をマスターしておけば、未来のツールを最大限に活かせるでしょう。
あなたの最近のトラブルをログで解決したら、その体験をコメントでシェアしてほしい。
次回は
「プラグインとテーマのトラブル攻略」をお届けします。
プラグイン競合や表示崩れに悩んだ方に役立つ内容を扱います。
ここまで読んでも「どの行をどう読めば分からない」状態なら、それは知識の問題ではなく、手元の状況に合わせて誰かに案内してもらった方が早い段階かもしれません。30 分の無料相談で、あなたのログを一緒に見ます。
ご相談の手段を選んでください
どの窓口でも、最初のご相談は無料です。
- メールフォーム 24h 受付・キャンセル可
- Chatwork 個人事業主との直接やりとり
- Zoom(予約制) 30 分まで無料/本人確認も兼ねて
- ココナラ 累計 600+ 件 ・ 平均 ★4.9
- ウェブナラ(ストア) 公開実績一覧/ご相談 LP
⏱ 受付 24h/対応 平日 10:00-17:00
🚨 緊急時:当営業日内に一次回答






