開発効率化

Mac miniを起点にWordPress運用を安定させる方法。SSHとwp-cliでXserverを回す

WordPress を共有サーバで運用していると、wp-admin だけで回すやり方に限界を感じる場面が出てきます。設定変更の履歴を追いにくいし、下書き量産もやりにくいし、保守と執筆がきれいに分かれません。

今回、Xserver 上の ichigoro.com を Mac mini + SSH + wp-cli で回せる形に整理しました。結論から言うと、共有サーバの WordPress はローカルを運用の起点にした方がかなり安定します。記事を増やしたい人にも、AI を絡めたい人にも向いていました。

Obsidian と Codex で記事案を作り、Mac mini から SSH と wp-cli で Xserver 上の WordPress を運用する流れを示した図解
Mac mini を起点にすると、メモ、AI 執筆、サーバ運用、下書き投入を 1 本の流れにまとめやすい。

この記事で書くこと

  • なぜ Mac mini を WordPress 運用の中継点にすると強いのか
  • Xserver 上の WordPress を安全に触るためにやったこと
  • 実際にハマったポイントと、その直し方
  • 最終的にどういう運用フローになったか

先に要点だけ言うと、共有サーバ上の WordPress でも、ローカル側に運用の起点を寄せた方が再現性はかなり上がります。特に、保守作業と記事作成を同じ流れに乗せたい人には向いています。

なぜ Mac mini を WordPress 運用の中継点にしたのか

理由は単純で、ブラウザだけに依存しない運用にしたかったからです。

比較項目 wp-admin 中心 Mac mini + SSH + wp-cli
再現性 低め 高い
記事量産 やや不向き 向いている
AI との相性 弱い 強い
保守作業のしやすさ 限定的 高い

wp-admin は便利ですが、次のような作業はやりにくいです。

  • 設定変更の履歴を追う
  • 同じ作業を何度も繰り返す
  • 複数の保守コマンドを定型化する
  • 記事の下書きを自動で流し込む

一方で、Mac mini 側に作業の入口を寄せると、SSH 接続、wp-cli、ローカルメモ、Obsidian、AI エージェントをひとつの流れにまとめやすくなります。

Xserver の WordPress を触る前に確認したこと

まず確認したのは、Xserver に SSH で入れるかどうかと、WordPress の設置場所、そして wp-cli が使えるかどうかです。

ここで分かったのは、サーバに最初から入っていた wp-cli がかなり古いということでした。

  • サーバ標準の /usr/bin/wp は WP-CLI 2.4.0
  • CLI のデフォルト PHP は 5.4.16
  • WordPress 本体は新しめなので、そのままでは相性が悪い

この時点で、共有サーバの標準環境をそのまま信用すると後で詰まると分かりました。表向きは動いていても、CLI の入口が古いだけで更新や自動化がかなり不安定になります。

Mac mini から Xserver の WordPress を安定運用するためにやったこと

1. WordPress の基本的なセキュリティ設定

  • display_errors を無効化
  • FORCE_SSL_ADMIN を有効化
  • DISALLOW_FILE_EDIT を有効化
  • xmlrpc.php を遮断
  • 不要なテーマと公開不要ファイルを整理

2. プラグインと WordPress 本体の更新

更新前にバックアップを取り、プラグインを先に整理しました。WordPress 本体は 6.7.1 から 6.7.5 に上げています。

ただし、古い wp-cli ではコア更新中に互換性エラーが出ました。ここは少しハマったポイントです。

3. 自前の wp-cli を持つようにした

最終的には、サーバの共有 wp-cli を使うのをやめて、ホーム配下に新しい WP-CLI 2.12.0 を置きました。

その上で、毎回同じ方法で安全に使えるように、~/bin/wp82 というラッパーを作りました。

~/bin/wp82 core version
~/bin/wp82 plugin list
~/bin/wp82 post list

これで、PHP 8.2 と新しい wp-cli を前提に、安定して WordPress を触れるようになりました。

4. 記事下書き用コマンドを追加

記事を量産しやすくするために、ローカルの本文ファイルから WordPress に draft を作るコマンドも追加しました。

~/bin/ichigoro-new-draft "記事タイトル" /path/to/content.html

これで、AI がローカルで本文を作って、そのまま WordPress に下書きを入れる運用ができるようになりました。

この構成が効いた理由

今回のポイントは、Mac mini 自体が特別というより、ローカルに作業の基準点を作ったことです。手元のメモ、スクリプト、下書き、接続情報、運用手順が 1 台にまとまると、毎回同じ流れで再現しやすくなります。

  • メモと実作業が分断されない
  • サーバ側の古い初期環境に引っ張られにくい
  • AI を作業フローへ組み込みやすい
  • 定型コマンドを残しやすい

PHP を上げたあとに一番ハマったポイント

一番ややこしかったのは、PHP を上げたあとに Safari でトップページが真っ白に見えたことです。

最初はサーバ側の障害を疑いましたが、実際には次の状態でした。

  • サーバは 200 OK を返している
  • HTML も本文の最後まで返っている
  • Chrome では見える
  • Safari だけ真っ白

原因は Safari 側のキャッシュでした。キャッシュを削除したら正常に表示されました。

この件で学んだのは、ランタイム変更の直後に表示がおかしくなっても、いきなりサーバ障害と決めつけない方がいいということです。HTTP ステータス、返却 HTML、別ブラウザでの表示を先に切り分けた方が早いです。

今の運用フロー

今は次のような流れで回せる状態です。

  1. Mac mini でメモや記事本文を作る
  2. Obsidian に試行錯誤の記録を残す
  3. SSH で Xserver に接続する
  4. wp82 で WordPress の状態を確認する
  5. ichigoro-new-draft で記事を draft 投入する
  6. 必要なら wp-admin で最終確認して公開する

この形にしておくと、単なる投稿作業ではなく、Mac mini を中心にした知識管理と公開運用の基盤になります。

この運用で注意した方がいいこと

共有サーバの標準環境を前提にしない

最初に入っている PHP や wp-cli が古いことは珍しくありません。自分のサイトが今の WordPress バージョンと合う入口になっているか、最初に確認した方が安全です。

wp-cli の成功だけで安心しない

保存できたことと、ブラウザで正常に表示されることは別です。特にテーマやキャッシュが絡むと、`wp-cli` 上は正しくても見た目が崩れることがあります。

記事制作と保守作業を同じ場所で扱う

サーバ運用と記事執筆を完全に別物にすると、途中で手順が分断されやすいです。今回のように Mac 側へ寄せると、公開までの流れがかなり見通しやすくなります。

Mac mini を WordPress 運用の中継点にするメリット

  • 作業が再現しやすい
  • AI と組み合わせやすい
  • 記事作成と保守運用を同じ流れにまとめられる
  • Obsidian のメモをそのまま記事ネタに育てられる

個人的に一番大きかったのはここです。手元のメモ、実験ログ、サーバ運用が分断されなくなりました。

この運用が向いている人

  • WordPress を共有サーバで運用している人
  • 記事制作と保守運用をまとめたい人
  • Obsidian やローカルメモを記事ネタの母艦にしたい人
  • AI を使って下書きを増やしたい人

よくある質問

Mac mini がなくても同じ運用はできますか

できます。要点は Mac mini そのものより、ローカル環境を運用の起点にすることです。普段使っている Mac が 1 台あれば十分です。

wp-admin はもう使わなくていいですか

そうではありません。本文作成や保守はローカルと wp-cli に寄せた方が楽ですが、最終確認や細かい見た目調整は wp-admin が便利です。

共有サーバでもここまで自動化できますか

できます。ただし、標準で入っている PHP や wp-cli が古いことがあるので、最初にそこを確認した方が安全です。

記事制作だけなら wp-admin 中心でも十分ですか

記事数が少なく、保守作業もほぼ発生しないならそれでも回ります。ただ、記事を継続して増やしたい、AI と組み合わせたい、保守を再現可能にしたい、という条件があるなら、ローカル起点の方が伸びやすいです。

まとめ

Mac mini + SSH + wp-cli で WordPress を運用すると、単に投稿しやすくなるだけでなく、保守、再現性、AI 連携まで含めた基盤が作れます。

特に共有サーバでは、標準で入っている古いツールをそのまま使うより、自分で安全な入口を整えた方が圧倒的に安定します。

今後はこの運用をベースにして、Obsidian の記録から記事を作り、WordPress に下書きを入れる流れをさらに整えていくつもりです。

次にやること

この構成をさらに使いやすくするなら、記事下書き、画像アップロード、公開前 preview の確認までを一連の手順として固定すると効きます。共有サーバの上でも、かなり安定したブログ運用に寄せられます。

関連記事

実際にその運用で記事をどう作っているかは、WordPress 記事をローカルで書いてから下書き投入する方法 にまとめています。本文作成と公開作業を分けると、AI との相性もかなり良くなります。

AI を実際の運用フローへどう組み込むかは、Codex と wp-cli でブログ運用を自動化する考え方 もあわせて読むとつながります。記事制作だけでなく、公開までの役割分担をどう作るかを整理しています。

-開発効率化