WordPress サイトでプラグイン更新が失敗して、サイトが Fatal Error で真っ白になった。慌てて SSH で接続して WP-CLI を叩こうとすると、こんなエラーが返ってきます。
Fatal error: Uncaught Error: ... in /path/to/broken-plugin/main.php:42
直したい対象のプラグインが、直すための道具（WP-CLI）まで止めてしまう。これは矛盾しているように見えますが、仕組みを知ると納得できる挙動で、回避策もちゃんと用意されています。
なぜ WP-CLI 自身が落ちるのか
wp plugin install <name> --version=X --force のようなロールバック用コマンドを叩くと、WP-CLI は内部で WordPress 本体を起動（bootstrap）してから処理を実行します。プラグインの登録や設定の読み込みは WordPress のブート過程で行われるため、壊れているプラグインがそこで読まれて Fatal となり、プロセスごと死ぬわけです。
つまり、wp plugin install --force を実行した瞬間に：
- WP-CLI が WordPress を起動
- WordPress が active なプラグイン一覧をロード
- 壊れたプラグインが読まれて Fatal
- WP-CLI もろとも終了
直すための処理（PHAR をダウンロードしてプラグインディレクトリを上書きする部分）まで辿り着けません。
解決策 — 安全モードフラグ
WP-CLI には --skip-plugins と --skip-themes という起動フラグがあり、これを付けると WordPress のブート時にプラグインとテーマのロードを完全にスキップします。
wp plugin install <name> --version=X --force --skip-plugins --skip-themes
ファイル操作系のコマンド（PHAR ダウンロード・展開・ファイル置換）はプラグインの読み込みに依存しないので、これで問題なく動きます。壊れたプラグインが boot 時にロードされない → Fatal せずに、ターゲットだけを旧版に戻せる。
常用する価値があるか
「最初から全部のコマンドに付けておけばいいのでは」と思いますが、wp cache flush のようにオブジェクトキャッシュ系プラグインの hook を必要とするコマンドや、wp doctor のようにプラグインの診断情報を読むコマンドでは、付けないほうが正常に動きます。
自動化スクリプト内では「ファイル操作系のコマンドにだけ --skip-plugins --skip-themes を付ける」「キャッシュ系・診断系には付けない」と切り分けるのが現実的です。
これだけで「ロールバックしたい瞬間に WP-CLI が動かない」という最悪のシナリオは恒久的に避けられます。WP-CLI を保守自動化に組み込んでいる人にとっては、知らずに踏むと修復不能に近い罠なので、覚えておく価値のあるフラグです。