同じWP-CLIなのに、レンタルサーバーが違うと別物になる

「SSH と WP-CLI が使えるレンタルサーバーなら、運用はだいたい同じだろう」と思って手を出すと、意外と毎回つまずきます。

ポート番号・鍵の形式・wp コマンドの場所・CLI 側で呼ばれる PHP のバージョン、このあたりがサーバーごとに別物で、Xserver で動いたスクリプトを ConoHa WING にそのまま持っていっても、いきなり接続段階で詰まる、ということが普通に起きます。

マトリクス（実測ベース）

項目	Xserver	さくらインターネット （スタンダード以上）	Heteml	ConoHa WING
SSH ポート	10022	22	22	8022
公開鍵の形式	任意（コンパネ発行は OpenSSH）	PKCS#8（ECDSA-521） が新発行のデフォルト	任意	.pem（ダウンロード形式）
wp コマンドの場所	/usr/bin/wp	標準搭載で wp 直叩き可	/usr/local/bin/wp	未搭載（自分で ~/bin/wp に配置）
PATH に wp が通っているか	はい	はい	はい	~/bin 経由で通る
php コマンド（素）の有無	あり（ただし古い 7.x がデフォルト）	あり	なし（php8.3 のような版番付きのみ）	あり
CLI 側 PHP のデフォルト	PHP 7.0 系（Web 側と別管理）	サイトの PHP に追従	サイトの PHP に追従	サイトの PHP に追従
自動化時の推奨 wp コマンド	/opt/php-8.3/bin/php /usr/bin/wp	wp（または絶対パス）	/usr/local/bin/php8.3 /home/users/0/<user>/bin/wp	/home/<user>/bin/wp
「そのままで WP-CLI が動くか」	動くが古い PHP で Parse error 多発	だいたい動く	php: command not found で動かない	wp: command not found で動かない

※ Xserver for WORDPRESS は Xserver と同じ系統です（ポート 10022・CLI 側 PHP 別管理）。

このマトリクスは「結果」だけを並べたものですが、4ホストに対して SSH 越しの読み取り専用診断で 13 項目を観測した生データと、なぜここまで構造が違うのか（FreeBSD ベースのさくら、shebang が解決できない Heteml、CLI 側 PHP が別管理の Xserver 等）の考察は別記事に書きました：「WP-CLI が動かない」を 4 ホスト実機調査して見えた、業界の構造問題

並べて初めて見える4つの差

差① SSH ポートが共通じゃない

22 を前提に書いた接続スクリプトを使い回そうとすると、Xserver（10022）と ConoHa WING（8022）でいきなり詰まります。エラーがただのタイムアウトなので、原因がポート番号だけだとなかなか気づけない。

# Xserver
ssh -p 10022 [e-mail]

# さくら / Heteml
ssh -p 22 [e-mail]

# ConoHa WING
ssh -p 8022 [e-mail]

サイト管理ツールやスクリプトを書くなら、「SSH ポート」はサーバー単位の設定項目として持っておく前提でいた方が安全です。

差② 鍵の形式が違う ── 特にさくらの新発行

ここが意外と新しい問題で、さくらインターネットの新コンパネが発行する秘密鍵は PKCS#8（ECDSA-521）形式になっています。

冒頭が -----BEGIN PRIVATE KEY----- で始まるので、慣れていれば一目で分かるんですが、見た目だけだと OpenSSH 形式と紛らわしい。古めの paramiko / Fabric / PuTTYgen だと「OPENSSH private key file ではない」「鍵を読み込めない」というエラーで弾かれます。

サーバー	発行される鍵	対応上の注意
Xserver	コンパネ発行は OpenSSH 形式	通常運用なら問題なし
さくら（新コンパネ）	PKCS#8 / ECDSA-521	古い paramiko 等は読めない・形式変換が必要なケースあり
Heteml	OpenSSH 形式	通常運用なら問題なし
ConoHa WING	.pem（OpenSSH 互換）	macOS は chmod 600 を忘れない

paramiko 系を使うなら、最低でも cryptography バックエンドの新しめのバージョン（PKCS#8 ECDSA に対応した世代）を使う必要があります。

差③ wp コマンドの位置が4社4様

これが一番効いてくる差です。

# Xserver
/usr/bin/wp plugin list

# さくら
wp plugin list                # PATH に通っているので直叩き可

# Heteml
/usr/local/bin/wp plugin list

# ConoHa WING
/home/c1234567/bin/wp plugin list

しかも ConoHa WING は初期状態で wp が無いので、自分で配置するところから始まります。~/bin/wp に置けば PATH には通るんですが、自動化スクリプトから非対話シェルで実行すると .bashrc が読まれず PATH が切れていることがあるので、自動化では絶対パスで呼ぶのが事故が少ない。

複数サーバーを束ねる自動化を書くなら、サイト or サーバー単位で「wp コマンドのフルパス」を持っておく構造にしておくと運用が安定します。

差④ CLI 側 PHP のバージョンが Web 側と別

これは特に Xserver で踏み抜きます。

サーバーパネルで PHP 8.3 を選んでいるサイトでも、SSH から wp を叩いたときに使われる PHP は別で、Xserver はデフォルトが PHP 7.0 系。WP-CLI 自体や WordPress 側のコードが PHP 8.x 構文を使っていると、コマンドを叩いた瞬間に Parse error で死にます。

$ /usr/bin/wp --info
PHP Parse error: ...

これを Web 側と揃えるには、PHP 実行ファイルを明示的に指定して wp を呼ぶ書き方になります。

# Xserver で PHP 8.3 のサイトに対して
/opt/php-8.3/bin/php /usr/bin/wp plugin list

# Heteml で PHP 8.3 のサイトに対して
/usr/local/bin/php8.3 /home/users/0/<user>/bin/wp plugin list

さくらと ConoHa WING は CLI 側 PHP がサイトに自動追従するので、ここはあまり気にしなくて済みます。Xserver と Heteml は要注意、というのが現場感覚です。

同じサーバー内で「複数 PHP バージョンが混在」しているとさらに面倒

複数サイトを面倒見ていると、「同じ Xserver アカウント内に PHP 7.4 のサイトと 8.3 のサイトが混在している」みたいなことが普通に起きます。

このときはサーバー共通のデフォルトとしては主に使われているバージョンを置きつつ、例外サイトだけサイト単位で別の PHP を指す、という二段構えで持つのが現実的です。サーバー単位の wp 設定とサイト単位の wp 設定、両方を扱えるデータ構造になっていないと、サイトを増やすたびに接続設定を複製する羽目になります。

mixhost / ロリポップ / その他は？

このマトリクスは Xserver・さくら・Heteml・ConoHa WING の4社で実機確認した内容です。mixhost・ロリポップ等の他社は SSH や WP-CLI の提供有無自体がプラン依存で、かつ手元で十分な検証ができていないので、ここでは正直に「未確認」と書いておきます。

少なくとも次の4点を最初に確認すれば、ほぼどのサーバーでも事情が掴めます。

1. SSH ポートは何番か（コンパネの SSH 設定画面に書いてある）
2. 発行される秘密鍵の形式は何か（head -1 keyfile で先頭行を見る）
3. which wp で wp がどこにあるか（command not found なら自分で配置）
4. php --version と wp --info の PHP バージョンが揃っているか（揃っていなければ絶対パス併記）

まとめ

「SSH + WP-CLI 対応サーバー」と一括りで言っても、実際に運用に組み込もうとすると、ポート・鍵形式・wp コマンド位置・CLI 側 PHP バージョンの4軸で全部違います。

最低限この4つはサーバー or サイト単位で持てる構造にしておくこと。逆にここをハードコードして書いてしまうと、サーバーを1つ増やすたびにコードを書き直すことになります。

「同じ WP-CLI を叩いている」と思っているのは手元の自分だけで、向こう側の事情は4社4様。並べて初めて、その当たり前がはっきり見えてきます。