2026年8月16日

WordPressでPHPのFatal error「Class not found」が出るときの原因と解決法

エラー・白い画面

「Class "〇〇" not found」は、PHPがあるクラスを使おうとした時点で、そのクラスの定義がまだ読み込まれていない（またはどこにも無い）ことを示す致命的エラーです。WordPressでは、プラグインのファイル欠け、依存する親プラグインの停止、読み込み順の誤り、PHP拡張モジュールの不足のどれかで起きることがほとんどです。この記事では、エラー文から原因の候補を読み取り、サイトを復旧させてから根本的に直すまでを順に説明します。

エラーメッセージの読み方

ログや画面には、次のような形で記録されます。

PHP Fatal error:  Uncaught Error: Class "Vendor\Package\Client" not found in /home/user/public_html/wp-content/plugins/sample-plugin/includes/api.php:42

PHP 8系ではクラス名がダブルクォートで、PHP 7系ではシングルクォートで囲まれますが、意味は同じです。読み取るべき点は2つあります。

見つからないクラス名：Vendor\Package\ のような名前空間付きならComposerなどで同梱したライブラリ、WooCommerce や WC_Product のような名前なら別プラグインのクラス、ZipArchive や SoapClient のような名前ならPHPの拡張モジュールのクラスです。
発生した場所：in の後ろのパスが、そのクラスを使おうとしたファイルです。wp-content/plugins/ 以下ならそのプラグイン、wp-content/themes/ 以下ならテーマが関係しています。

画面には「このウェブサイトに重大なエラーが発生しました。」とだけ表示されることが多く、詳細はログでしか分かりません。

ステップ1：まずサイトを復旧させる

作業の前に、可能であればファイルとデータベースのバックアップを取ります。そのうえで、原因のプラグインやテーマを止めてサイトを動く状態に戻します。

リカバリーモードを使う

WordPressは致命的エラーを検知すると、管理者のメールアドレスに「リカバリーモード」に入るためのリンクを送ります。そのリンクから管理画面に入ると、エラーの原因になったプラグインやテーマが表示され、そのセッションでは一時停止された状態で操作できます。メールが届いていれば、ここから該当プラグインを無効化するのが手軽です。

ファイル名の変更やWP-CLIで止める

メールが届かない場合は、FTPやサーバーのファイルマネージャーで、エラーのパスに出ていたプラグインのフォルダ名を変えます（例：sample-plugin を sample-plugin.off に）。WordPressはそのプラグインを読み込めなくなり、自動で無効化されます。

WP-CLIが使える場合は、問題のプラグインを読み込まずに無効化できます。

wp --skip-plugins plugin deactivate sample-plugin

--skip-plugins を付けないと、WP-CLI自身の起動時にも同じ致命的エラーが起きて操作できないことがあります。テーマが原因の場合は --skip-themes も付け、wp --skip-plugins --skip-themes theme activate twentytwentyfive のようにデフォルトテーマへ切り替えます。テーマ名は、インストール済みのデフォルトテーマに合わせて変更してください。

ステップ2：ログで状況を詳しく確認する

復旧後、原因を詳しく調べるために wp-config.php で次を設定し、wp-content/debug.log に記録させます。

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

ステージング環境があれば、そちらで問題のプラグインを再度有効化してエラーを再現させると、本番に影響を出さずにログを集められます。Fatal error の直前に Warning が出ていれば、それが本当の原因であることもあります（例：require_once の対象ファイルが見つからないという警告）。調査が終わったら WP_DEBUG を false に戻し、debug.log は削除します。

原因別の解決法

プラグインの更新が途中で失敗し、ファイルが欠けている

自動更新や手動更新が通信切れ・容量不足などで途中終了すると、クラスを定義したファイルや vendor フォルダが欠けた状態になります。更新直後にエラーが出始めた場合はこの可能性が高いです。

対処は、プラグインの入れ直しです。管理画面の「プラグイン」→「新規プラグインを追加」→「プラグインのアップロード」から、公式サイトなどから入手した同じプラグインのZIPをアップロードすると、既存のものを置き換えるかどうかを選べます。WP-CLIなら、WordPress.org で配布されているプラグインを次のように再インストールできます。

wp plugin install sample-plugin --force

設定はデータベースに保存されているため、通常はファイルを入れ直しても設定は消えません。ただし、プラグインのフォルダ内に独自のファイルを置いている場合は、入れ直しで消えるので事前に退避します。

依存する親プラグインが無効になっている

WooCommerceの拡張機能や、特定のページビルダー用のアドオンなどは、親プラグインのクラスを前提に動きます。親プラグインを無効化・削除したのにアドオンだけ有効のまま残っていると、Class "WooCommerce" not found のようなエラーになります。親プラグインを有効にするか、不要ならアドオン側も無効化します。

読み込み順の誤り（自作コードの場合）

自作のテーマやプラグインで別プラグインのクラスを使う場合、プラグインファイルが読み込まれた直後に書くと、相手のプラグインがまだ読み込まれていないことがあります。plugins_loaded フック以降で、class_exists() を使って存在を確認してから使います。

add_action( 'plugins_loaded', function () {
	if ( ! class_exists( 'WooCommerce' ) ) {
		add_action( 'admin_notices', function () {
			echo '<div class="notice notice-error"><p>'
				. esc_html__( 'このアドオンを使うには WooCommerce を有効にしてください。', 'my-addon' )
				. '</p></div>';
		} );
		return;
	}
	require_once __DIR__ . '/includes/class-my-addon.php';
} );

親プラグインが無い環境でも致命的エラーにならず、管理画面に案内が出るだけになります。

名前空間やファイル名の大文字・小文字の違い

自作コードで名前空間を使っている場合、use 文の書き漏れや、先頭のバックスラッシュの有無で、PHPが別の名前空間のクラスを探しに行ってしまうことがあります。エラーに表示されたクラス名が、意図した完全な名前（名前空間込み）になっているかを確認します。

また、ローカル環境（WindowsやmacOSの標準設定）ではファイル名の大文字・小文字が区別されないのに対し、多くのLinuxサーバーでは区別されます。PSR-4のオートローダーは、クラス名とファイル名・フォルダ名が一致していることを前提にしているため、ローカルでは動いて本番だけ「Class not found」になる場合は、ここを疑います。

Composerのオートロードが古い、または vendor が無い

Gitなどでデプロイしていて vendor フォルダを管理対象から外している場合、本番で composer install を実行しないとクラスが見つかりません。クラスを追加・改名したあとにオートロードの定義を作り直していない場合も同様です。プラグインのフォルダで次を実行します。

composer install --no-dev
composer dump-autoload -o

あわせて、プラグインのメインファイルで vendor/autoload.php を require_once しているかを確認します。デプロイ直後だけ古い状態が残る場合は、PHPのOPcacheが古いファイル情報を保持していることがあるため、PHP-FPMの再起動やサーバーのOPcacheリセット機能で解消できるか試します。

PHPの拡張モジュールが入っていない

ZipArchive（zip拡張）、SoapClient（soap拡張）、Imagick（imagick拡張）、DOMDocument（dom拡張）、IntlDateFormatter（intl拡張）など、PHPの拡張モジュールが提供するクラスが見つからない場合は、コードではなくサーバーの設定の問題です。管理画面の「ツール」→「サイトヘルス」→「情報」タブにある「サーバー」の項目などで、読み込まれている拡張モジュールを確認できます。レンタルサーバーではコントロールパネルのPHP設定で有効化できることがあり、VPSでは該当するパッケージを追加してPHP-FPMを再起動します。

直ったあとの確認

修正後は、停止していたプラグインを有効化し直し、フロントと管理画面の両方でエラーが出ないことを確認します。debug.log に同じ Fatal error が記録されていないかも見ておきます。メニュー名や画面の表記はWordPressのバージョンで変わることがあります（2026年10月現在）。

まとめ

「Class not found」は、使おうとしたクラスの定義が読み込まれていない状態。エラー文のクラス名と発生場所で原因の方向が分かる
まずリカバリーモード、フォルダ名の変更、wp --skip-plugins で原因を止めてサイトを復旧させる
更新失敗ならプラグインの入れ直し、親プラグイン停止なら有効化、PHP拡張のクラスならサーバー設定で対応する
自作コードは plugins_loaded と class_exists() で依存を確認し、名前空間・ファイル名の大文字小文字・Composerのオートロードを見直す