Linuxでシェルスクリプトを使った運用自動化の実践例｜日常業務を効率化するための具体パターンを詳しく整理

Linux運用では、定期バックアップ、ログ整理、ディスク使用量の監視、プロセス監視、ファイル連携、障害検知、定期レポート作成など、繰り返し発生する作業が数多くあります。こうした定型業務は、シェルスクリプトを使って自動化することで、作業漏れや人的ミスを減らし、対応速度と再現性を高めやすくなります。特に小規模から中規模のサーバー運用では、Bashを中心としたシェルスクリプトが今でも非常に強力な選択肢です。ここでは、Linuxでシェルスクリプトを活用した運用自動化を行う際の考え方、基本構文、実践例、cron連携、ログ管理、異常通知、注意点までを、実務で使いやすい形でまとめます。

なぜLinux運用でシェルスクリプト自動化が有効なのか

Linuxの運用現場では、同じ操作を何度も繰り返す業務が発生します。たとえば、毎日のバックアップ、不要ファイルの削除、ログの監視、特定サービスの稼働確認、ディスク容量のチェック、転送ファイルの存在確認などです。これらを手作業で続けると、対応者ごとのばらつき、実行忘れ、コマンド打ち間違い、対応記録の不足が起こりやすくなります。

シェルスクリプトを使うことで、複数コマンドを1つの手順にまとめられます。さらに、条件分岐、繰り返し、終了判定、ログ出力、通知連携まで組み込めるため、単なる作業短縮だけでなく、運用ルールそのものをコード化しやすいのが大きな利点です。Linux標準コマンドとの親和性も高く、追加ソフトをほとんど入れずに始めやすい点も現場向きです。

シェルスクリプト自動化でよくある対象業務

運用自動化の対象としてよく挙がるものには、次のようなものがあります。

・バックアップ処理の定期実行
・ログファイルの圧縮、退避、削除
・ディスク使用率の監視
・プロセス死活監視
・Webやバッチの実行結果チェック
・ファイル到着監視
・日次レポートの生成
・障害時のメール通知
・古い一時ファイルの掃除
・設定ファイルや証明書期限の確認

このような業務は、手順が明確で条件化しやすいため、シェルスクリプトとの相性が良い分野です。

まず押さえたいシェルスクリプトの基本形

Linuxでよく使われるシェルはBashです。基本的なスクリプトは、シバン、変数、コマンド、終了コード確認、条件分岐、繰り返しなどで構成されます。

最小構成のサンプル

echo “処理を開始します”

DATE=$(date ‘+%Y-%m-%d %H:%M:%S’)
echo “現在時刻: $DATE”

echo “処理を終了します”

実行権限を付けて実行します。

chmod +x sample.sh
./sample.sh

運用スクリプトでは、単に動けばよいのではなく、異常時の終了、ログへの記録、可読性、再実行時の安全性まで考えることが重要です。

運用スクリプトで最初に入れておきたい基本設定

実務では、予期しない失敗を早く検知するための設定を入れることが多くあります。代表的なのは、エラー時終了、未定義変数の検知、パイプ失敗時の検知です。

安全性を高める基本設定例

#!/bin/bash
set -euo pipefail

SCRIPT_NAME=$(basename “$0”)
LOG_FILE=”/var/log/${SCRIPT_NAME}.log”

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) 開始” >> “$LOG_FILE”

# ここに処理を書く

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) 終了” >> “$LOG_FILE”

set -e はエラー時に即終了、set -u は未定義変数参照時にエラー、pipefail はパイプ途中の失敗も拾うための設定です。運用自動化では、失敗しているのに正常終了したように見える状態を防ぐことが重要になります。

実践例1 バックアップを自動化する

もっとも代表的な自動化対象がバックアップです。ここでは、特定ディレクトリを日付付きで退避し、一定期間を過ぎたバックアップを削除する例を示します。

バックアップスクリプト例

#!/bin/bash
set -euo pipefail

SRC_DIR=”/var/www/html”
BACKUP_DIR=”/backup”
DATE=$(date ‘+%Y%m%d_%H%M%S’)
ARCHIVE_FILE=”${BACKUP_DIR}/html_${DATE}.tar.gz”
LOG_FILE=”/var/log/backup_html.log”

mkdir -p “$BACKUP_DIR”

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) backup start” >> “$LOG_FILE”

tar -czf “$ARCHIVE_FILE” “$SRC_DIR”

find “$BACKUP_DIR” -name ‘html_*.tar.gz’ -type f -mtime +7 -delete

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) backup complete: $ARCHIVE_FILE” >> “$LOG_FILE”

この例では、tarで圧縮バックアップを作成し、findで7日より古いバックアップを削除しています。バックアップ作成だけで終わらず、世代管理まで含めるのが実務的です。

実践例2 ディスク使用率を監視してしきい値超過時に通知する

容量監視も定番の自動化対象です。ファイルシステム使用率がしきい値を超えたら通知するようにしておくと、ログ肥大化や一時領域枯渇に早く気づけます。

ディスク監視スクリプト例

#!/bin/bash
set -euo pipefail

THRESHOLD=80
LOG_FILE=”/var/log/disk_check.log”

df -P | awk ‘NR>1 {print $5 ” ” $6}’ | while read -r usage mountpoint
do
percent=${usage%\%}

if [ “$percent” -ge “$THRESHOLD” ]; then
echo “$(date ‘+%Y-%m-%d %H:%M:%S’) WARNING: ${mountpoint} usage is ${percent}%” >> “$LOG_FILE”
fi
done

このままでもログ蓄積には使えますが、mailコマンドやSlack Webhook、Chat通知などと組み合わせることで、実際の運用監視に近い構成になります。

実践例3 特定プロセスの死活監視を行う

常駐プロセスやアプリケーションが落ちていないかを確認し、停止していたらログ出力や再起動まで行うスクリプトもよく使われます。

プロセス監視スクリプト例

#!/bin/bash
set -euo pipefail

PROCESS_NAME=”nginx”
LOG_FILE=”/var/log/process_check.log”

if pgrep -x “$PROCESS_NAME” > /dev/null; then
echo “$(date ‘+%Y-%m-%d %H:%M:%S’) ${PROCESS_NAME} is running” >> “$LOG_FILE”
else
echo “$(date ‘+%Y-%m-%d %H:%M:%S’) ERROR: ${PROCESS_NAME} is not running” >> “$LOG_FILE”
systemctl start “$PROCESS_NAME”
echo “$(date ‘+%Y-%m-%d %H:%M:%S’) ${PROCESS_NAME} restart attempted” >> “$LOG_FILE”
fi

このような処理は便利ですが、自動再起動を行う場合は、なぜ停止したのかの記録も残す必要があります。単純再起動だけでは根本原因を見逃しやすくなるためです。

実践例4 ログファイルの整理と古いファイル削除を自動化する

ログは放置するとディスクを圧迫します。一定日数を超えたファイルの圧縮や削除を自動化しておくことで、運用が安定しやすくなります。

ログ整理スクリプト例

#!/bin/bash
set -euo pipefail

TARGET_DIR=”/var/log/myapp”
LOG_FILE=”/var/log/log_cleanup.log”

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) cleanup start” >> “$LOG_FILE”

find “$TARGET_DIR” -type f -name ‘*.log’ -mtime +30 -exec gzip {} \;
find “$TARGET_DIR” -type f -name ‘*.gz’ -mtime +90 -delete

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) cleanup end” >> “$LOG_FILE”

本番では、削除前に対象件数を確認したり、別領域へ退避してから削除する方式も検討されます。いきなりdeleteする処理は、対象パスの誤りが致命傷になりやすいため、最初はechoで確認する段階を設けると安全です。

実践例5 ファイル到着監視と連携処理を自動化する

他システムから受信するCSVやテキストファイルを検知し、到着したら所定フォルダへ移動したり、取り込み処理を起動したりする業務もよくあります。

ファイル到着監視の例

#!/bin/bash
set -euo pipefail

WATCH_DIR=”/data/incoming”
DONE_DIR=”/data/processed”
LOG_FILE=”/var/log/file_watch.log”

mkdir -p “$DONE_DIR”

for file in “$WATCH_DIR”/*.csv
do
[ -e “$file” ] || continue

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) processing $file” >> “$LOG_FILE”

mv “$file” “$DONE_DIR”/

echo “$(date ‘+%Y-%m-%d %H:%M:%S’) moved to $DONE_DIR” >> “$LOG_FILE”
done

この種の処理では、ファイル名規則、重複受信、転送途中ファイルの扱い、ゼロバイトファイルへの対応、異常時の退避先なども考える必要があります。

実践例6 定期レポートを生成して保存する

サーバー状態や処理結果を日次で残す用途でも、シェルスクリプトは非常に扱いやすいです。たとえば、CPU、メモリ、ディスク、稼働時間を1つのレポートにまとめることができます。

日次レポート作成例

#!/bin/bash
set -euo pipefail

REPORT_DIR=”/var/reports”
DATE=$(date ‘+%Y%m%d’)
REPORT_FILE=”${REPORT_DIR}/daily_report_${DATE}.txt”

mkdir -p “$REPORT_DIR”

{
echo “===== Daily Report $(date ‘+%Y-%m-%d %H:%M:%S’) =====”
echo
echo “[hostname]”
hostname
echo
echo “[uptime]”
uptime
echo
echo “[disk usage]”
df -h
echo
echo “[memory]”
free -h
} > “$REPORT_FILE”

このようなレポートは、障害時の比較材料としても有効です。毎日同じ形式で残すことで、異常傾向を追いやすくなります。

実践例7 エラー発生時だけ通知を送る仕組みを入れる

自動化では、常に通知を飛ばすよりも、異常時だけ通知する設計の方が運用しやすいことが多くあります。正常時通知を毎回送ると、やがて見られなくなるためです。

メール通知の簡易例

#!/bin/bash
set -euo pipefail

LOG_FILE=”/var/log/check_service.log”
TO=”admin@example.com”
SERVICE_NAME=”nginx”

if ! systemctl is-active –quiet “$SERVICE_NAME”; then
MESSAGE=”$(date ‘+%Y-%m-%d %H:%M:%S’) ${SERVICE_NAME} is inactive”
echo “$MESSAGE” >> “$LOG_FILE”
echo “$MESSAGE” | mail -s “Service Alert: ${SERVICE_NAME}” “$TO”
fi

mailコマンドが使えない環境では、sendmail、msmtp、Webhook連携、監視製品へのイベント送信などに置き換える構成も多くあります。

cronと組み合わせて定期実行する

シェルスクリプトは、手動実行だけでなく、cronやsystemd timerと組み合わせて定期実行することで真価を発揮します。古くから使われているのはcronです。

cronの設定例

crontab -e

0 2 * * * /usr/local/bin/backup_html.sh
*/10 * * * * /usr/local/bin/disk_check.sh
*/5 * * * * /usr/local/bin/process_check.sh

たとえば、毎日2時にバックアップ、10分ごとにディスク監視、5分ごとにプロセス監視という設定です。cron実行時は、対話シェルとは環境変数が異なるため、PATH依存やカレントディレクトリ依存の記述は避ける方が安全です。

ログ出力の設計を甘くしないことが重要

運用自動化スクリプトでは、正常終了したか、どこで失敗したか、何を対象に処理したかが追えることが非常に重要です。ログが不十分だと、自動化したはずなのに、トラブル時に何も分からない状態になります。

ログには少なくとも以下を残すと扱いやすくなります。

・開始時刻
・終了時刻
・対象ファイルや対象ホスト
・エラー内容
・終了コード
・再実行の有無
・退避先や出力先

終了コードとエラー処理を明確にする

Linux運用では、処理が失敗したことを外部から判定できるように、終了コードを意識することが大切です。cron、他スクリプト、監視ツールから呼ばれる場合、標準出力だけでなく exit ステータスが重要になります。

終了コードを返す例

#!/bin/bash
set -euo pipefail

TARGET_FILE=”/tmp/test.txt”

if [ -f “$TARGET_FILE” ]; then
echo “file exists”
exit 0
else
echo “file not found” >&2
exit 1
fi

正常終了を0、異常終了を1以上で返すことで、呼び出し元が結果を判定しやすくなります。

運用スクリプトで特に注意したい落とし穴

シェルスクリプトは便利ですが、雑に書くと運用事故につながります。注意点としては次のようなものがあります。

・rm や find -delete の対象パス誤り
・ワイルドカードの意図しない展開
・スペースを含むファイル名未対応
・未定義変数の利用
・失敗しても次へ進む構造
・同時実行による競合
・ログ肥大化
・権限不足による失敗
・cron実行時だけ動かない問題
・相対パス依存

特に危険なのは削除系処理です。最初は削除せずに対象だけ表示し、確認後に本削除へ切り替える段階を踏む方が安全です。

同時実行を防ぐ仕組みも実務では重要になる

5分ごと実行の監視や、長時間かかるバッチ処理では、前回処理が終わる前に次回実行が重なることがあります。これを防ぐにはロック制御が必要です。

flockを使った多重起動防止例

#!/bin/bash
set -euo pipefail

LOCK_FILE=”/tmp/my_batch.lock”

exec 200>”$LOCK_FILE”
flock -n 200 || {
echo “already running”
exit 1
}

echo “start batch”
sleep 30
echo “end batch”

このようにしておくと、既に同一処理が動いている場合に二重起動を防げます。連携処理やバッチ処理ではかなり重要な設計要素です。

実務で使いやすい運用スクリプトの書き方

読みやすく保守しやすいスクリプトには共通点があります。

・冒頭に用途を書く
・変数名を分かりやすくする
・パスは絶対パスで書く
・ログファイルを決めておく
・異常時に終了させる
・関数化して処理を分ける
・本番前に検証環境で試す
・削除処理は慎重にする
・cron実行前に手動実行で確認する

短いスクリプトでも、数か月後には他人が触る可能性があります。誰が見ても意図を追える構成にしておくことが、結果的に運用コストを下げます。

まとめ

Linuxでのシェルスクリプト運用自動化は、バックアップ、監視、ログ整理、ファイル連携、レポート作成など、定型作業の品質と速度を大きく改善しやすい方法です。Bashと標準コマンドだけでもかなり広い範囲を自動化でき、cronや通知と組み合わせれば、小規模な監視基盤のような役割まで持たせることができます。重要なのは、動くスクリプトを書くことではなく、失敗時に分かること、安全に止まること、ログが残ること、再実行しても事故になりにくいことまで含めて設計することです。運用を安定させるための仕組みとしてシェルスクリプトを位置付けることで、Linux管理の負担を着実に減らしやすくなります。