この記事を3行で解説
- Webサイトの表側が正常に表示されていても、管理画面だけが動作を停止するケースがあります。
- 2026年8月26日に発生した事例では、SEOプラグインの処理がサーバーのメモリ1GBを使い切ったことが原因でした。
- エラーログの一時的な記録と検証により、特定の投稿タイプでのみ処理を停止させる対策が有効です。
Webサイト公開後の点検における盲点と管理画面の不具合
Webサイトを公開した後の点検において、ユーザーが見る表側のページだけを確認する手法には盲点が存在します。表側のページが正常に表示されていても、管理画面などの裏側のシステムだけが動作を停止している場合があるためです。このような事象が発生すると、サイトの閲覧者には影響がないように見えますが、運営者が新しい情報を発信できなくなるという問題が生じます。
2026年8月26日、Miravitaのサイトにおいて、記事の編集画面を開こうとした際に画面が表示されず、「このページは動作していません」というエラーメッセージが表示される事象が発生しました。このとき、表側のページであるトップページ、一覧ページ、個別の記事ページは、確認した範囲においてすべて正常に表示されていました。このように、表側と裏側で挙動が異なる不具合は、表側の点検だけでは検知できません。公開後の点検では、管理画面の動作確認も必須の項目となります。
管理画面の不具合が発生した原因と背景
この不具合の原因は、SEOプラグインである「All in One SEO」が管理画面向けのデータに追加している項目にありました。この項目は、記事を「いま表示している記事」に差し替えたうえで、ページの頭の中身を丸ごと組み立てる仕様となっていました。この処理が「実績」と「記事」の2つの投稿タイプにおいて終了せず、サーバーが使用できるメモリの上限である1GBを使い切ってしまい、システムが停止していました。
一方で、標準の投稿や固定ページではこの事象は発生していませんでした。特定の投稿タイプにおいてのみ、メモリを過剰に消費する処理が走っていたことが原因です。また、調査の過程でWordPressの設定ファイルにメモリの上限を40MBとする記述があることも判明しました。しかし、WordPressは設定ファイルの値が現在の上限より大きいときしか適用しない仕様であるため、サーバー側のメモリ上限が1GBであるこの環境では、40MBの記述は影響していませんでした。
原因を特定するための検証手順
このような不具合を解決するためには、原因を特定するための論理的な手順が求められます。今回の検証では、表側のページと管理画面が使用するデータの入口を並べて確認し、データの項目を1つずつ指定して、動作が停止する箇所を探す方法を採用しました。闇雲に設定を変更するのではなく、データの流れを比較することで、問題のある箇所を絞り込むことが可能です。
具体的な手順としては、一時的にエラーの記録を残す設定を導入し、エラーログから原因を特定しました。原因の特定が完了した後は、セキュリティやサーバー容量への影響を考慮し、設定を元の状態に戻し、記録されたログファイルも消去しています。検証時の設定変更は、作業完了後に元へ戻すことが運用の基本です。
具体的な解決策として、プラグイン側が用意している差し込み口を利用し、「実績」と「記事」の2つの投稿タイプにおいてのみ、該当する処理を実行させないように記述を修正しました。この修正により、表側に出る内容は修正前と修正後で変化させることなく、管理画面の不具合を解消することに成功しました。Webサイトの構築や運用の進め方については、サービス紹介ページで詳しく解説しています。
公開後の点検体制と管理画面の重要性
Webサイトの運用においては、公開後の点検を多角的に行うことが重要です。表側の表示確認に加えて、管理画面の動作確認も点検項目に含める必要があります。今回の事例のように、特定の投稿タイプだけでメモリを使い切るような不具合は、実際に管理画面を操作しなければ発見できません。不具合が発生した際には、エラーログの活用とデータの入口の比較検証により、原因を特定して適切な対策を講じることが可能です。
過去の対応事例については、実績紹介ページに掲載しています。また、Webサイトの不具合や運用に関するご相談は、お問い合わせページよりご連絡ください。
よくある質問
Q. 表側のページが正常であれば、管理画面の不具合は放置しても問題ありませんか？
A. 放置すると記事の編集や更新ができなくなるため、早急な対応が必要です。表側が正常であっても、管理画面が動作しない場合はサイトの運用に支障をきたします。
Q. メモリ上限を40MBとする記述が効かなかったのはなぜですか？
A. WordPressの仕様により、設定ファイルに記述された値が現在の上限より大きいときしか適用されないためです。サーバー側のメモリ上限が1GBである環境では、40MBの記述は適用されません。
Q. 不具合の調査時に記録したエラーログはそのままでよいですか？
A. 原因特定後はエラー記録の設定を元に戻し、記録されたログも消去することが推奨されます。不要なログを残すことは、サーバー容量の圧迫やセキュリティ上の懸念につながるためです。
