WordPressで使えるmysqliとPHP拡張機能の導入と対処法（今すぐ確認）

※この記事内の一部リンクにはアフィリエイトリンク（PR）が含まれます。

はじめに：なぜWordPressでmysqliとPHP拡張機能が必須なのか（表示できない原因とベネフィット）

WordPressが突然「動かない」「白い画面」や「Your PHP installation appears to be missing the MySQL extension which is required by WordPress.」という致命的メッセージを出したとき、多くの人はテーマやプラグインのせいだと考えがちです。しかし本質的には PHP のデータベース拡張（特に mysqli）がサーバーで有効になっていないことが原因であるケースが非常に多く、まずはここを確認するのが最短ルートです。¹

mysqli が適切に動作していれば、WordPressはデータベースと安全かつ効率的にやり取りできます。プリペアドステートメントやトランザクションの利用、mysqlnd（ネイティブドライバ）によるパフォーマンス改善などの恩恵を受けられるため、安定運用やセキュリティ向上に直結します。²

環境を確認する最初の一手：phpinfoとCLIでmysqliが有効か簡単チェック

まずは「サーバーのどのPHPが使われているか」を確認します。ブラウザから phpinfo() を実行して Web（FPM/Apache）側の情報を見て、サーバー上で php -m や php -v を実行して CLI 側の情報を比較してください。これで「Web側では無効だけどCLIでは有効」といった設定差が分かります。³

確認の第一歩は簡単です。WordPress 管理画面に入れないなら、ドキュメントルートに test.php を置き中に <?php phpinfo(); ?> を入れてブラウザで表示します。mysqli の項目が表示されていれば Web 側は有効ですし、表示されなければ有効化またはホスティング会社への問い合わせが必要です。¹

phpinfo()で見るべき箇所とスクリーンショット例での確認ポイント

phpinfo() を見たら「mysqli」という見出し、mysqlnd のバージョン、Client API version（MySQL クライアントのバージョン）をチェックします。ここに情報が出ていれば PHP は mysqli 拡張を読み込んでおり、詳細な設定やドライバ情報も確認できます。²

スクリーンショットの例で言えば「mysqli support => enabled」「Client API library version => 8.x.x」などが目安です。表示がなければ php.ini に extension=mysqli.so（Windowsならphp_mysqli.dll）が無効化されている可能性が高く、次に紹介する手順で有効化を試してください。

CLIとWeb（FPM/Apache）のPHPが異なるときの見分け方と原因

サーバーで php -v や which php を実行して出るパスと、Web サーバが読み込んでいる PHP（phpinfo()の「Loaded Configuration File」など）が異なることがあります。特に共有ホスティングや複数バージョンを切り替え可能な環境では、CLI 側は新しい PHP を参照していても Web 側は古い（または別の）PHP を使っていることがよくあります。²

違いを見分けるには、phpinfo() の「Configuration File (php.ini) Path」「Loaded Configuration File」と CLI の php -i の出力を照合してください。差があるなら Web サーバ（php-fpm/Apache）を再起動するか、ホスティングの PHP 設定画面で正しいバージョンに合わせましょう。³

代表的なエラーメッセージと原因別切り分け（短時間で解決する7つのステップ）

代表的なエラーは冒頭の「Your PHP installation appears to be missing the MySQL extension which is required by WordPress.」です。このメッセージは mysqli などの PHP 拡張が無効もしくは存在しない場合に表示されますが、原因は複数考えられます（拡張未導入・php.ini 設定ミス・CLI/Web の不一致・テーマやプラグインの干渉など）。⁴

短時間での切り分けの流れは次のとおりです：1) phpinfo()で確認、2) サーバーでphp -m実行、3) php.iniのextensionの行確認、4) php-fpm/Apache再起動、5) 全プラグイン停止で再検証、6) エラーログ確認、7) ホスティングサポートへ連絡。これらを順に実施すると原因の大半は数時間で特定できます。¹

「Your PHP installation appears to be missing…」の意味と即効対応

このメッセージは「WordPressが必要とするMySQL拡張がPHP側で見つからない」ことを示します。即効対応としては、まずブラウザで phpinfo() を確認して mysqli の項目がないかを確認し、無ければホスティングの PHP 拡張一覧で mysqli を有効化するか、VPSならパッケージをインストールします。⁴

共有ホスティングならコントロールパネルでの切り替えやサポート依頼が早いです。VPS なら apt や yum コマンドで php-mysql の該当パッケージを入れて php-fpm を再起動してください（コマンド例は後述）。²

拡張未導入／無効化／設定差異／プラグイン干渉の見分け方

拡張未導入は phpinfo に「mysqli」項目が無いことで判別できます。無効化は php.ini に ;extension=mysqli のようにコメントアウトされている状態なので、該当行を有効化して再起動が必要です。CLI と Web の差は前節で述べた比較で判明します。²

プラグイン干渉は稀ですが、プラグインやテーマが独自に DB ラッパーを読み込むなどのカスタム実装が原因で mysqli コールが上手く動かないケースがあります。その場合は全プラグインを一時停止し、デフォルトテーマで動作確認して切り分けてください。³

サーバー別：mysqliを有効化する実践手順（共有ホスティング・VPS・Windows・Docker対応）

環境によって手順が変わりますが、基本は「該当PHPに対してmysqli拡張をインストール／有効化→設定反映のため再起動」です。共有ホスティングではコントロールパネル（cPanel, Plesk 等）から拡張をオンにするかサポートへ依頼するのが最短です。¹

VPS など自分で管理できる場合はパッケージマネージャで該当パッケージを入れ、php-fpm や Apache を再起動します。Docker 環境では Dockerfile に php-mysqli 相当のパッケージを追加したイメージを作るなどの対応になります。具体例は次のサブセクションで示します。

共有ホスティング（cPanel/Plesk）：管理画面で今すぐ有効化する方法

cPanel の場合は「Select PHP Version」や「PHP Extensions」から mysqli（または php-mysql）にチェックを入れ保存するだけで有効化されることが多いです。有効化後に必要ならWebサーバの再起動（多くはコントロールパネルで自動）を行います。できない場合はサポートへ「mysqliを有効にしてほしい」と依頼してください。¹

Plesk でも同様に PHP 設定画面から拡張をオンにできます。管理画面の操作に不安がある場合はスクリーンショットを添えてサポートに問い合わせると迅速です。共有環境では自分で直接 php.ini を編集できないことが多い点に注意してください。

Debian/Ubuntu（apt）・CentOS/RHEL（dnf/yum）：パッケージ名と再起動コマンド

Debian/Ubuntu 系では php のバージョンに合わせて例: apt install php8.1-mysql を実行し、systemctl restart php8.1-fpm を行います。CentOS 系では dnf install php-mysqlnd や yum install php-mysqlnd を使い、systemctl restart php-fpm（またはhttpd）で反映します。²

インストール後に php -m や phpinfo() で mysqli が表示されるか確認してください。パッケージ名はディストリ・バージョンにより異なるため、パッケージ検索（apt search php | grep mysql など）で正確な名前を確認するのが安全です。

Windows/XAMPPとDocker環境での設定と注意点

Windows / XAMPP 環境では php.ini にある ;extension=mysqli をコメントアウト（先頭の ; を削除）して Apache を再起動すれば有効になります。XAMPP 特有のパスやバージョン差に注意してください。⁵

Docker を使っている場合は Dockerfile に必要パッケージを追加してイメージをビルドし直します。公式 PHP イメージをベースにしているなら RUN docker-apt-get install -y php-mysqli（正確なパッケージ名はディストリに依存）などで対応します。コンテナは再起動で反映されます。

PHPバージョン別の互換性と注意点（PHP 8.x 系で起きやすい落とし穴）

PHP のメジャーバージョンアップでは、拡張のデフォルト挙動や内部実装が変わることがあり、mysqli 関連の不具合が発生する場合があります。アップグレード後に WordPress が「mysqli が無い」と誤検出される報告もあるため、アップデートは慎重に行ってください。⁶

WordPress の公式推奨 PHP バージョン（管理画面や公式サイトで確認）に合わせるのが無難です。どうしても新しいバージョンを使う必要がある場合はステージング環境で事前検証を行い、問題が出たらロールバック手順を準備しておきましょう。⁴

mysqlndとmysqliの違い、WordPress推奨バージョンの考え方

mysqlnd（MySQL Native Driver）は PHP に組み込まれるドライバで、メモリ管理やパフォーマンス、プロファイリングの挙動に影響します。一方 mysqli は PHP の拡張 API（関数群）で、mysqlnd を使うか libmysqlclient を使うかで挙動やパフォーマンスが変わることがあります。²

WordPress は一般的に mysqlnd を推奨するケースが多く、ホスティング側でも mysqlnd を有効にした PHP ビルドを提供していることが多いです。運用中のサイトでは WordPress の互換性情報や推奨環境に従い、極端に新しい PHP バージョンの導入は段階的に行うのが安全です。

バージョンアップ後に発生する問題の切り分けと安全なロールバック方法

バージョンアップで問題が出たらまずログ（PHP エラーログ、Web サーバログ、MySQL のログ）を確認してエラー内容を把握します。エラーメッセージに基づき拡張モジュールの有無や互換性の問題を切り分けます。⁷

ロールバックは事前にステージング環境で検証しておくことが最も安全です。実運用での緊急ロールバックはホスティングの PHP バージョンダウングレード機能を利用するか、パッケージを旧バージョンに戻して php-fpm を再起動する手順になります。

WordPress上でできるデバッグと便利プラグイン（実務で役立つ3選）

mysqli がらみの問題はサーバー側の拡張が原因であることが多いですが、WordPress 側で状況を可視化することで原因特定が速くなります。代表的なプラグインには Query Monitor、Debug Bar、Log Viewer などがあり、クエリ実行や接続エラー、PHP エラーを確認できます。¹

診断プラグインで問題が「WordPress 側のコードか」「サーバー側か」を切り分けられれば、次のアクション（サーバー設定修正 or プラグイン修正）が明確になります。まずは Query Monitor を使って DB クエリの失敗やエラー発生箇所を確認しましょう。

Query Monitorで見るべき場所とmysqli関連の読み取り方

Query Monitor はクエリ実行時間、失敗したクエリ、発生箇所（プラグインやテーマ）を表示します。mysqli の未導入であればクエリ自体が実行されずエラーが出るため、ここで「DB connection error」や該当エラーのトレースが見られます。これにより「WordPress 側の問題ではない」と判断できます。¹

Query Monitor でエラーがテーマやプラグインに紐づく場合はそのプラグインを無効化して再確認します。逆にクエリが全く走らない場合はサーバーの mysqli 状態を疑うタイミングです。

移行やバックアップ時に注意するプラグイン（Duplicatorなど）のポイント

移行プラグイン（Duplicator 等）を使う際は、移行先サーバーの PHP 拡張要件を事前に確認してください。移行先で mysqli が有効でないと移行プロセスが途中で止まり、サイトが復旧しないことがあります。⁴

移行の前には phpinfo() と php -m で環境差を確認し、不足があればホストで事前対応を行いましょう。バックアップは必ず稼働中に取得し、移行テストはステージングで実施してください。

カスタム開発が必要なケースとメリット（既存プラグインで無理ならここを検討）

標準のWordPressや既存プラグインでは対応できない特殊な要件（外部MySQLクラスタへの独自接続、接続リトライや専用キャッシュ、WPDBの拡張、非同期バッチ処理など）はカスタムプラグインで解決できます。サーバー制約を回避するためのラッパーや、独自ロジックでmysqliの存在を安全に検出する仕組みも作成可能です。

既存プラグインで叶わない仕様があるなら、要件定義から設計・実装・テスト・デプロイまで対応するカスタム開発がおすすめです。私のサービスではWordPress専用のプラグイン開発を受け付けており、既存プラグインでは無理な機能の実装も対応可能です。詳しくは下記リンクからご依頼ください：WordPress専用プラグインを開発します 既存プラグインで無理な機能を実装します | ココナラ

こんなときはカスタム：特殊DB接続・リトライ・外部クラスタ対応など

たとえば可用性の高い外部クラスタへのフェイルオーバー、認証付きの特殊DB接続、API 経由で別ストレージに書き出すような要件は標準 WPDB や汎用プラグインだけでは扱いづらいことがあります。こうした場面では WPDB を拡張した安全な接続ラッパーが有効です。

また、接続エラーをトランザクション制御しつつ自動でリトライするロジックや、大量データ処理時のバッチ処理・キュー実装は、カスタムプラグインで効率よく組み込めます。要件に応じてセキュリティ・負荷試験も含めて設計します。

私のサービス案内：WordPress専用プラグインを開発します（既存で無理な機能を実装）

既存プラグインで実現できない機能は「作ればいい」の精神で対応します。要件整理、設計、実装、テスト、納品後のサポートまで一貫して受け付けていますので、「できるだけ早く確実に動くものがほしい」方はぜひご相談ください。ご依頼はこちらから：WordPress専用プラグインを開発します 既存プラグインで無理な機能を実装します | ココナラ

事前にログや環境情報（phpinfo のスクリーンショット、php -v と php -m の出力、エラーログ）をお渡しいただければ、より正確な見積もりと短納期で対応できます。まずは簡単な事前診断から承ります。

表：表タイトルを考える

ここでは「短時間で復旧するための優先ステップ表」を用意しました。これを見れば48時間以内に復旧するための作業優先順が一目でわかります。

各ステップは実行順に並べ、所要時間とコマンド例／注意点を付記しています。必要に応じて自サーバーに合わせて調整してください。

実践チェックリスト：今日やるべき10項目（短時間で復旧させる優先順位付き）

ここでは優先度順に10のチェック項目を示します。まずは上から順に実行すれば問題の大半は解決か原因特定できます。時間の無い場合は STEP1〜STEP4 をまず実施してください。

チェックリストはシンプルに：1 phpinfo、2 php -m、3 php.ini の extension 行、4 再起動、5 プラグイン停止、6 ログ確認、7 ホスティング問合せ、8 ステージングで再現、9 バックアップの取得、10 必要ならカスタム開発依頼、の順です。

STEP1：環境確認 → STEP2：拡張有効化 → STEP3：再起動 → STEP4：再検証 の流れ

優先フローは非常に単純です。まず環境を把握（phpinfo と php -m）→ 拡張が無ければ有効化 or インストール → Web サーバ再起動 → WordPress の表示確認、という流れを速やかに回します。これで多くのケースは1〜2時間で復旧可能です。

もしここで解決しない場合はログの詳細解析や、プラグイン・テーマの切り分け、あるいはカスタム対応の検討（私のサービスが役立ちます）へ移行してください。カスタムが必要ならこちらからご相談いただけます：カスタムで対応するなら：WordPress専用プラグインを開発します（詳細はこちら）

よくある質問（Q&A形式）— 検索で来た人が知りたい疑問に即回答

読者が最初に検索で来る疑問を短くまとめ、即答できるようにしています。疑問の多くは「できるか」「どのログを見れば良いか」「プラグインで解決できるか」の3点に集中します。

以下に代表的なQ&Aを挙げます。個別の環境差や要件によって最適回答が変わることがあるため、長引く場合はログ情報を添えて相談するのが確実です。

Q：プラグインでmysqliは追加できますか？

A：できません。mysqliはPHPの拡張であり、プラグインはWordPress（PHP）レベルのコードなのでサーバーに存在しない拡張を後から追加することはできません。プラグインでできるのは診断や回避ロジックの追加くらいです。²

代替策としては、診断用プラグイン（Query Monitor等）で原因を特定し、ホスティングで拡張を有効にしてもらうか、必要な処理を代替手段（外部APIなど）で実装するカスタムプラグインを作る方法があります。

Q：CLIで有効なのにWebで無効 → なぜ？

A：CLIとWebのPHP設定は別々に管理されることがあります。php.ini のパスやロードされる拡張が異なるためです。確認は phpinfo()（Web）と php -i / php -m（CLI）を比較してください。³

解決は Web 側の php.ini を編集するか、ホスティングの PHP バージョン切替で合わせることです。FPM のプール設定や Apache の設定ファイルでロードされる PHP が異なるケースが多いので注意してください。

Q：PHPを上げたら急にWordPressが動かない → まず見るログは？

まずは PHP のエラーログと Web サーバのエラーログ（例：/var/log/php-fpm.log、/var/log/apache2/error.log）を確認してください。mysqli のロード関連エラーや関数未定義のエラーが出ていれば拡張または互換性の問題です。⁷

次に phpinfo() で現在の PHP 構成（有効拡張、ロードされている php.ini）を確認し、問題が互換性に起因するなら一時的に旧バージョンにロールバックするか、ステージングで調査してください。

導入後の運用アドバイスとセキュリティ上の注意点（安定稼働のために必ずやること）

安定運用のためには定期的な確認が欠かせません。最低でも月次で phpinfo() のスクリーンショット保存、php -m の出力保管、PHP と WordPress のバージョン更新履歴を記録しておくと、問題発生時に原因追跡が速くなります。

セキュリティ面では、不要な拡張を有効にしない、PHP のエラーメッセージを公開しない、必ず最新版のセキュリティパッチを適用することが重要です。mysqlnd の設定や接続情報の扱いは特に攻撃対象になりやすいため、資格情報は環境変数や wp-config.php の適切なアクセス制限で保護してください。

定期的に確認するログとモニタリング、mysqlndのチューニング簡易ガイド

週次や月次でチェックする項目は：PHP エラーログ、MySQL エラーログ、Query Monitor の異常検知、サーバーリソース（CPU/メモリ）です。mysqlnd のチューニングは必要に応じて行いますが、まずは接続の持続時間やバッファサイズをログで確認することから始めます。²

過負荷やメモリリークが疑われる場合は mysqlnd のパラメータ（expose_php のような設定やバッファサイズ）を見直し、ステージングで負荷試験を実行してから本番に反映してください。

カスタム対応のご案内（要件定義〜実装まで代行します）／事例と料金目安

要件の複雑さによりますが、簡単なラッパー実装や接続リトライの追加なら短期で対応可能です。大規模な外部クラスタ対応や独自キュー実装、負荷試験を含む案件は要件定義に時間を頂きます。詳細はお問い合わせください。

すぐに相談したい方は下のサービスページからご依頼いただけます。要件に応じた見積り・納期・サポート内容を提示します：WordPress専用プラグインを開発します 既存プラグインで無理な機能を実装します | ココナラ

相談フロー：事前診断→見積もり→開発→検証→納品の流れ（納期とサポート例）

通常の流れは、まず事前診断（ログ・環境情報の共有）、次に要件を詰めて見積もり、開発（ステージングでの実装）、検証（テスト計画実行）、納品・導入サポート、という段階を踏みます。小規模案件なら数日〜2週間、大規模案件は数週間〜数ヶ月が目安です。

納品後のサポート（バグ修正、ホスティング調整、追加要件対応）もオプションで提供します。事前にどこまで含めるかを明確にすることでトラブルを減らせます。まずは簡易診断からご依頼ください。

まとめ：今すぐ試すべきことと失敗しないための最短ルート（緊急対応版）

緊急時の最短ルートは次の順です：1 phpinfo()でWeb側確認 → 2 php -m でCLI確認 → 3 php.iniのextensionチェック → 4 php-fpm/Apache再起動 → 5 ログ確認 → 6 ホスティングに問い合わせ。これで多くのケースは48時間以内に復旧可能です。

もし既存プラグインやサーバー設定だけで解決できない特殊要件があるなら、カスタム開発で確実に対応できます。既存プラグインで無理な機能は作ればいいのです。まずはお気軽にご相談ください：WordPress専用プラグインを開発します 既存プラグインで無理な機能を実装します | ココナラ