「WP-CLI が動かない」を 4 ホスト実機調査して見えた、業界の構造問題

WordPress の保守自動化を組み立てていくと、必ず一度は突き当たるのが「WP-CLI を起動できない」というレンタルサーバー固有の壁です。本来であれば、サーバーに WP-CLI 本体のファイルを 1 本置いてコマンドとして使えるようにするだけの単純な作業のはずなのに、ホストごとに違う形で詰まる。

この記事は、ConoHa WING / Xserver / さくらインターネット / Heteml の 4 ホストに対して、SSH 越しの読み取り専用診断を実機で走らせて得た観測データから、「WP-CLI が動く／動かない」の境目には何があるのかをまとめたものです。

「1 行で入る」が成り立たない

WP-CLI 公式の手順は、UNIX 系のサーバーであればおおむね同じ手順で動くことを前提にしています。

curl -O https://raw.githubusercontent.com/wp-cli/wp-cli/v2.12.0/phar/wp-cli.phar
chmod +x wp-cli.phar
sudo mv wp-cli.phar /usr/local/bin/wp
wp --info

上から順に「WP-CLI の本体ファイル（PHAR と呼ばれる単一実行ファイル）をダウンロード」→「実行可能フラグを立てる（chmod +x）」→「全ユーザーが使える /usr/local/bin/ に管理者権限で配置」→「動作確認」という流れです。

ところが共有レンタルサーバーでは、この通りに動きません。sudo（管理者権限でコマンドを実行する仕組み）はそもそも使えませんし、/usr/local/bin/ には書き込めない設計のことも多い。次善策として「自分のホームディレクトリの中に ~/bin/（~ はホームディレクトリを表す省略記号）を作って、そこに置く」というやり方が定番ですが、これもホストによっては成立しません。

「コマンドを名前だけで起動するための検索パス（PATH 環境変数）に ~/bin が入っているか」「その PATH の中に php 本体があるか」「PHAR の 1 行目で『どのインタプリタで動かすか』を指定する shebang（#!/usr/bin/env php のような行）が解決できるか」「デフォルトのシェルが bash か csh か」といった前提が、ホストごとにまったく違うのです。

読み取り専用で 4 ホストを観測する

ホスト側に副作用を残さないため、診断は SSH 越しに which wp（コマンドの実体パスを調べる）／ command -v php（同様に php の所在を調べる）／既知パスでの動作試行のみを行うシェルスクリプトにしました。書き込みは $HOME/.wpmm_diag_test_$$（プロセス番号付きの一時ファイル）を一瞬作って即削除する書き込み権限テストだけ。13 項目の観測を 4 ホストで実機実行した結果が、以下の表です。

4 ホスト 4 アーキテクチャ。同じ「WP-CLI を起動する」というだけの動作に対して、ホストごとに別の方法論が必要であることが見えてきます。

4 ホスト 4 アーキテクチャの内訳

ConoHa WING — 自分で ~/bin/wp を配置するスタイル

システム側に WP-CLI は入っていません。~/bin/ がホームに最初から存在し、PATH にも含まれているため、ここに wp を置けば wp 単体で動きます。

ただし注意点が 1 つ。コントロールパネルのファイルマネージャー経由でアップロードした PHAR が「broken signature（壊れた署名）」というエラーで起動できなくなる事故が、実機で何度か確認できました。原因は、ブラウザ経由のアップロードでは転送途中にファイルの中身がうっすら書き換えられてしまうことがあるため。手元のファイルと見比べてサイズも MD5（中身が一致するかを確認する短い文字列）も同じなのに、起動すると PHAR が自分自身を検証して「壊れている」と判断して止まる、というやっかいな現象です。SSH でサーバーにログインしてから curl コマンドで直接ダウンロードする経路に切り替えれば、この途中での書き換えが入らないので確実に避けられます。

Xserver — システムプリインストールあり

/usr/bin/wp に root 所有の WP-CLI PHAR が標準で配置されています（タイムスタンプから推測すると 2023 年版で、やや古い）。which wp で /usr/bin/wp がそのままヒットするので、追加の設定なしで使えます。

さくらインターネット — シェルラッパー方式

/usr/local/bin/wp に 70 byte の小さなシェルスクリプト（ラッパー＝本体の前に挟まって、適切な PHP を選んで起動を仲介する短いプログラム）が置かれています。wp を呼ぶと、このラッパーが内部で適切な PHP 実行環境を自動的に選んで本体を起動してくれる設計。これも wp 単体で動きます。

ただし、さくらは Linux ではなく FreeBSD という別系統の UNIX 系 OS を採用しているため、細かい部分で他 3 ホストと違いがあります。たとえばログイン時に立ち上がるシェル（コマンドを受け付ける対話プログラム）が一般的な bash ではなく csh だったり、ファイルのチェックサムを計算するコマンドが md5sum ではなく BSD 流の md5 だったり。Linux 用に書かれた自動化スクリプトをそのまま持ち込むと止まってしまうので、UNIX 共通の最低限の書き方（POSIX 仕様と呼ばれる範囲）に揃え直す必要があります。

Heteml — php が PATH にない

ここが一番厄介です。~/bin/ は実在し、PHAR を置くこともできる。けれど which php が空。/usr/local/bin/ を見ると php8.3 のようなバージョン番号付きエイリアスしかなく、素の php が存在しません。

WP-CLI の PHAR の 1 行目には先に触れた shebang が書かれていて、その内容は #!/usr/bin/env php ──つまり「PATH から php を探して、それで動かしてくれ」という指示です。Heteml では PATH から php が見つからないので、この自動解決が失敗してしまう。代わりに、PHP の本体ファイル（php8.3 のようにバージョン番号が付いたフルパス）をこちらから明示的に指定して起動する必要があります。

/usr/local/bin/php8.3 ~/bin/wp --info

つまり Heteml では、自動化ツールに登録する「WP-CLI を起動するコマンド」を、wp 単体ではなく「PHP の実体（バージョン番号入りのフルパス）」と「WP-CLI 本体のパス」を半角スペースでつなげた 1 行として指定する必要があります。具体的には /usr/local/bin/php8.3 ~/bin/wp のような書き方です。

4 段階の検出フロー

4 ホストの違いを 1 本のロジックで吸収するため、検出は以下の 4 段階の優先順位で行うのが現実的でした。

Step 1: which wp で見つかる              → wp_cli_path = "wp"
Step 2: ~/bin/wp が直接実行できる        → wp_cli_path = "~/bin/wp"
Step 3: ~/bin/wp はあるが PATH に php が
        いない                            → バージョン入り php のフルパスを探し出して
                                          wp_cli_path = "<php のフルパス> ~/bin/wp"
Step 4: いずれもダメ                      → 自動インストール候補

Step 1 で大半（ConoHa / Xserver / さくら）が解決し、Step 3 で Heteml 型を救済し、Step 4 だけがゼロからの導入となります。それぞれの段で wp --info を走らせて、その終了ステータス（コマンドが成功したか失敗したかを表す番号・成功なら 0）と出力内容を検証し、「動作確認済み」の最終判定はハッシュ照合ではなく必ず wp --info が成功することで行う、というのが今回の調査で得た確信でもあります。

ハッシュは「ファイルが書き換わっていない」ことの確認用にとどめる。MD5 が一致しても broken signature を起こすケースが実機にあったためです。

まとめ — 観測ベースで「最も確からしい設定」を出す

「WP-CLI が動かない」は、たいていの場合は固有の事故ではなく、ホスト側のアーキテクチャに合った設定が当たっていないだけ、というのが今回の 4 ホスト調査で見えた構図でした。

観測項目を増やして場合分けを精密にしていくよりも、SSH 越しの読み取り専用観測で「最も確からしい設定」を high / medium / low の信頼度ラベル付きで提案する方向のほうが、運用上は現実的です。確証ではなく参考目安として扱い、最終的な確認は wp --info の動作で取る。書き込みの副作用は持ち込まない。

レンタルサーバーは多様で、その多様性自体を受け入れるしかありません。それを前提に、観測 → 推定 → 検証の三段で「動かない」を一つずつ崩していくのが、保守作業の安定運用に近づく道だと考えています。