レンタルサーバー×Bashで解決できること｜WP-CLI・cronで“面倒”を自動化

メール運用やWordPress更新に追われがちでも、レンタルサーバーでBashとWP-CLI、cronを使えば日々の作業を自動化して安定運用に近づけます。

本記事は「SSHが使えるか不安」「まだGUIしか触っていない」という方でも、レンタルサーバー上で今すぐ始められる最短ルートを示します。

レンタルサーバーについての限界についても取り扱っていますが、自分が求めている物と違う場合にはVPSでのBash学習についても参照してみてください。

レンタルサーバーの概要：SSH/cronの位置づけ
Bashで“今すぐ解決できること”｜代表タスクとコマンドの型
1. 更新・バックアップ・置換を一気通貫（WP-CLI＋cronの最短レシピ）
2. 原因追跡と復旧の初動（ログ診断：grep/awk、権限整理：find＋chmod）
共有環境の“できない/制約”と安全運用のコツ
1. root不可・常駐不可・IO制限の壁／rsync不可時のSFTPバッチ代替
2. 鍵認証・PATH/タイムゾーン・ジョブ間隔の設計（他ユーザー影響を避ける）
まとめ｜最初の3手と次アクション（学びながら時短する）
1. ①SSH鍵→②WP-CLI導入→③DB＋uploadsの毎日バックアップcron
2. もっと効率化：検索置換・画像再生成・ログの自動アラートへ拡張
レンタルサーバー×Bashで解決できること｜WP-CLI・cronで“面倒”を自動化の深掘り記事
関連記事

レンタルサーバーの概要：SSH/cronの位置づけ

レンタルサーバーとは、事業者が運用するサーバーの一部を月額で借りて使うサービスで、もっとも一般的なのは複数ユーザーで1台を共有する「共用サーバー」です。

サーバーの監視・パッチ適用・ハード交換といった保守は事業者側が担うため、利用者は安く、かつサーバー管理不要で始められます。WordPressの設置や、独自ドメインでのメール運用まで揃えられるのが定番の使い方です。

この共用型でも、プラン次第でSSHログインとcron（時刻指定の自動実行）が使えます。SSHは安全な遠隔接続の仕組みで、BashやWP-CLIなどのコマンド操作を可能にします。cronは毎日／毎週などのスケジュールでスクリプトを自動実行できる仕組みで、バックアップや更新の定期実行に最適です。

未契約の方は「SSH対応・cron対応・WP-CLIが動くPHP/CLI環境」の3点を満たすプランを選ぶのが近道です。既契約の方はまずコントロールパネルでSSHを有効化し、鍵認証を設定してから、WP-CLIとcronを順に整えると、レンタルサーバーでもBash前提の時短運用に踏み出せます。

Bashで“今すぐ解決できること”｜代表タスクとコマンドの型

最短で効果が出るのは更新・バックアップ・検索置換の自動化です。レンタルサーバーでもBash＋WP-CLIで1本のスクリプトにまとめ、cronに登録すれば、WordPressの更新忘れや手動バックアップの手間が消えます。まずは小さく作って毎日回すのがコツです。ここで挙げる型は、そのまま貼り付けて動かしながら調整できます（WP-CLIはwpコマンドが動く前提）。

更新・バックアップ・置換を一気通貫（WP-CLI＋cronの最短レシピ）

以下は「プラグイン/テーマ/コアの更新→DBバックアップ→アップロードの差分アーカイブ→任意の文字列置換」を1本化した最短例です。/home/USER/www/public_htmlなど自身のドキュメントルートに合わせてパスを調整してください。

#!/bin/bash
set -euo pipefail

SITE_DIR="$HOME/www/public_html"
BACKUP_DIR="$HOME/backups/$(date +%F)"
mkdir -p "$BACKUP_DIR"
cd "$SITE_DIR"

# 1) メンテ前のキャッシュ無効化（使っていれば）
# wp cache flush || true

# 2) 更新（必要に応じて限定）
wp plugin update --all --quiet
wp theme update --all --quiet
wp core update --quiet || true
wp core update-db --quiet || true

# 3) DBバックアップ（軽量・互換性高）
wp db export "$BACKUP_DIR/db.sql" --quiet

# 4) アップロード差分をアーカイブ（直近7日分など）
find wp-content/uploads -type f -mtime -7 -print0 | tar -czf "$BACKUP_DIR/uploads-week.tgz" --null -T -

# 5) 任意の置換（例：ドメイン変更や表記統一）
# wp search-replace 'http://example.com' 'https://example.com' --all-tables --precise --quiet

# 6) 仕上げ（権限調整は環境に応じて最小限）
# find wp-content -type d -exec chmod 755 {} \;
# find wp-content -type f -exec chmod 644 {} \;

echo "OK: $(date) updates & backup done" >> "$BACKUP_DIR/run.log"

実行権限を付与し、深夜に回す例（毎日3:10）です。

chmod +x $HOME/bin/wp_maint.sh
(crontab -l; echo "10 3 * * * $HOME/bin/wp_maint.sh >/dev/null 2>&1") | crontab -

ポイントはwp db exportでDBを確実に取り、uploadsは差分だけを固めてIO負荷を抑えること。置換は--dry-runで安全確認してから本番実行に切り替えます（--dry-runを付けると変更は行われません）。

原因追跡と復旧の初動（ログ診断：grep/awk、権限整理：find＋chmod）

不調時は「再現→ログ→一次対処」の順でBashの定型を叩くと早いです。エラーログはホストにより場所が異なりますが、error.logやphp_error.logが典型です。

# 直近の致命的エラーを時系列で確認
tail -n 200 /path/to/logs/error.log | grep -E "Fatal|PHP Fatal|PHP Parse" | awk '{print $1" "$2" "$3" "$0}'

# プラグイン別エラー件数の大まかな傾向
grep -h "PHP Fatal" /path/to/logs/error.log* | awk -F'PHP Fatal error: ' '{print $2}' | awk -F'in ' '{print $2}' | awk -F'/' '{print $3}' | sort | uniq -c | sort -nr | head

権限崩れは「ディレクトリ755／ファイル644」がまずの目安です。闇雲に全体変更せず、wp-content配下に限定して最小修正に留めます。

# 危険な777を洗い出し
find wp-content \( -type d -o -type f \) -perm -o+w -print

# ディレクトリ/ファイルを安全側に寄せる（要確認）
find wp-content -type d -exec chmod 755 {} \;
find wp-content -type f -exec chmod 644 {} \;

これらの「観測→仮説→最小手当て」の定型をlogs_scan.shなどにまとめ、cronで毎日サマリを自分宛にメールするだけでも早期検知につながります。レンタルサーバーでもWP-CLIと軽いgrep/awkの組み合わせで十分に回せます。

共有環境の“できない/制約”と安全運用のコツ

共用のレンタルサーバーではroot不可・常駐不可・I/O制限が前提です。Bashの設計は「短時間で終わる・重い処理は分割・ジョブが重ならない」を軸にします。WP-CLIは強力ですが、更新や置換は深夜帯に小さく回すのが基本です。

root不可・常駐不可・IO制限の壁／rsync不可時のSFTPバッチ代替

systemctlや常駐デーモンは使えません。長時間のnohup放置もプロセス監視で落とされがちです。大きな処理は分割し、I/Oが重いtar -czfは対象を絞る／日次差分→週次フルに分ける方が安全です。外部退避でrsyncが使えない環境は、SFTPのバッチで代替できます。

# SFTPバッチでバックアップを退避（鍵認証を前提）
BACKUP_DIR="$HOME/backups/$(date +%F)"
REMOTE="backup-user@backup.example.com"
sftp -i "$HOME/.ssh/id_ed25519" -b - "$REMOTE" <<'EOF'
mkdir -p backups/2025-10-06
put -p /home/USER/backups/2025-10-06/db.sql backups/2025-10-06/
put -p /home/USER/backups/2025-10-06/uploads-week.tgz backups/2025-10-06/
bye
EOF

容量制限が厳しい場合は分割＋世代管理を使います。

# 2GBを超える可能性があるアーカイブを分割して転送
tar -czf - wp-content/uploads | split -b 500m - "$BACKUP_DIR/uploads_full.tgz.part_"

鍵認証・PATH/タイムゾーン・ジョブ間隔の設計（他ユーザー影響を避ける）

鍵認証は必須です。~/.ssh/configにホスト定義を置くとジョブからの接続が安定します。

Host backup
  HostName backup.example.com
  User backup-user
  IdentityFile ~/.ssh/id_ed25519
  ServerAliveInterval 30
  ServerAliveCountMax 3

cronは環境変数が薄いので、先頭にSHELL/ PATH / TZを明示し、ロックで重複実行を防ぎます。

# crontab -e の上部に記載
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin:$HOME/bin
TZ=Asia/Tokyo
MAILTO=you@example.com

# 3:10に実行。flockで重複回避、WP-CLIに明示パス
10 3 * * * /usr/bin/flock -n /tmp/wp_maint.lock \
  bash -lc 'cd $HOME/www/public_html && wp --path=$PWD plugin update --all --quiet && $HOME/bin/wp_maint.sh' \
  >/dev/null 2>&1

他ユーザーへの影響を避けるため、次を徹底します。

間隔の最小化：重い処理は週次、軽い処理を日次。開始時刻に**±数分のジッター**を入れ、同時集中を避ける。
オーバーラップ防止：flockまたはロックファイル、pgrepで前回残りを検知してスキップ。
PATHの固定：/usr/local/binにwpが無い環境もあるため、which wpで絶対パスを解決するか--pathを毎回付ける。
タイムゾーンの明示：ログと実行時刻のズレ防止にTZ=Asia/Tokyoをcron先頭で指定。

この設計により、BashとWP-CLIの自動処理が共用環境の制約下でも安定して回り、ほかの利用者やサーバー全体への負荷を抑えながら安全運用が可能になります。

まとめ｜最初の3手と次アクション（学びながら時短する）

未契約の方はBash前提のおすすめレンタルサーバーを確認し、レンタルサーバーでの運用基盤を固めてください。BashとWP-CLIを軸にすれば、小さな自動化でも日々の手作業を確実に減らせます。

①SSH鍵→②WP-CLI導入→③DB＋uploadsの毎日バックアップcron

最優先はSSH鍵認証の有効化。

次にwp --infoが通る状態までWP-CLIを導入し、紹介したスクリプトをcronで毎日深夜に回します。DBはwp db exportで日次、uploadsは差分を週次フルと併用するとI/Oと容量を抑えられます。実行はflockで重複防止、TZ=Asia/Tokyoで時刻のズレを避けると安定します。

もっと効率化：検索置換・画像再生成・ログの自動アラートへ拡張

運用が回り始めたら、wp search-replace --dry-runでの安全な一括置換、wp media regenerateの夜間バッチ、grep/awkでのエラーログ集計メールを段階的に追加します。導線は小さく、失敗しても戻せる粒度で。WP-CLIのコマンドセットはWP-CLIの始め方から確認・横展開してください。

レンタルサーバーの制約がマッチしない方はVPSで解決できることも参照してみてください。