WP-CLIのエラー「This does not seem to be a WordPress installation」の解決方法

beginner📝 WordPress2026-06-14| Linux (Ubuntu/Debian/CentOS), macOS, Windows (WSL), WP-CLI 2.x, WordPress 5.0+

Error Message

Error: This does not seem to be a WordPress installation.
#wp-cli#wordpress#devops#トラブルシューティング

問題の概要

ターミナルを起動して wp plugin listwp core update を素早く実行しようとした際、通常の出力の代わりに「Error: This does not seem to be a WordPress installation.」という素っ気ないメッセージが表示され、実行が拒否されることがあります。これは、WP-CLIがサイトのコアファイルを見つけられず、場所を見失っているときによく発生する一般的な障害です。

WP-CLIが混乱する理由

WP-CLIは、wp-includes/version.php を探すことで、そこが有効なインストールディレクトリであるかを判断します。検索パス内にこのファイルが見つからない場合、ツールは自身が間違ったディレクトリにいると判断します。これには通常、いくつかの特定の原因があります。

  • ディレクトリの間違い: 実際のルートである /var/www/html/ ではなく、/var/www/ でコマンドを実行している。
  • パスの不一致: --path フラグで指定したフォルダにコアファイルが含まれていない。
  • カスタム構成: Roots Bedrockのようなボイラープレートを使用しており、WordPressコアが /web/wp/ サブフォルダに格納されている。
  • 権限不足: ユーザーに wp-load.phpwp-includes フォルダへの読み取り権限がない。

クイック修正:現在の場所を確認する

多くの場合、成功まであと一歩(ディレクトリ一つ分)のところにいます。pwd を使用して、ファイルシステム上の現在地を正確に確認してください。次に、WordPressのローダーファイルが存在するか確認します。

# 現在のパスを確認
pwd

# コアファイルが実際に存在するか確認
ls -la | grep wp-load.php

ファイルが見当たらない場合は、正しいディレクトリに移動してください。標準的な Ubuntu のセットアップでは、多くの場合 /var/www/html です。

cd /var/www/html
wp core version

--path パラメータの使用

デプロイスクリプトやcronジョブなど、WordPressフォルダの外からコマンドを実行する必要がある場合があります。その場合は、--path フラグを使用して、ファイルが存在する場所を絶対パスで明示的に指定する必要があります。

wp plugin list --path=/var/www/my-site.com/public_html

パスの末尾にスラッシュを追加しないようにしてください。/var/www/html/ よりも /var/www/html と記述する方が、内部的なパスエラーが発生しにくく、スマートです。

Bedrockやカスタム構成向けの解決策

BedrockではWordPressコアがサブディレクトリに移動されるため、構成が異なります。プロジェクトルートでコマンドを実行するとWP-CLIは失敗するため、具体的に web/wp フォルダを指定する必要があります。

# Bedrockでの標準的なコマンド実行
wp plugin list --path=web/wp

wp-cli.yml で時間を節約する

毎回手動でパスを入力するのは面倒です。これを自動化するには、プロジェクトのルートに wp-cli.yml ファイルを作成します。この設定ファイルにより、コマンドを実行するたびにWP-CLIがそのプロジェクトのどこを探すべきかを指定できます。

wp-cli.yml に以下の内容を記述します。

path: public_html
# または Bedrock ユーザーの場合:
# path: web/wp

これで、プロジェクトフォルダ内にいる限り、追加のフラグなしで wp コマンドを実行できるようになります。

権限の競合を解決する

正しいフォルダにいるのにエラーが解消されない場合は、ファイルの所有権を確認してください。WP-CLIは環境を起動するためにコアファイルを読み取る必要があります。ファイルが www-data 所有(権限644)で、別のユーザーとしてログインしている場合、アクセスがブロックされる可能性があります。

# ファイルの所有権を確認
ls -l wp-load.php

# 現在のユーザーを確認
whoami

不一致がある場合は、Webサーバーユーザーとしてコマンドを実行してください。これは、ファイル権限をグローバルに変更するよりも安全な代替手段です。

sudo -u www-data wp plugin list --path=/var/www/html

最終確認

すべてが正常に戻ったか、簡単なバージョンチェックを実行して確認します。6.4.3 のようなバージョン番号が表示されれば、WP-CLIがサイトに正常に再接続されています。

wp core version

まとめチェックリスト

  • wp-load.php が含まれるフォルダの中にいますか?
  • --path フラグに末尾のスラッシュなしの絶対パスを使用していますか?
  • ユーザーは wp-includes ディレクトリの読み取り権限を持っていますか?
  • Bedrockを使用している場合、パスを /wp サブフォルダに指定しましたか?

Related Error Notes