この記事の監修：宮崎智広（Linux実務・教育歴20年以上・受講者3,100名超）
そう感じている方は多いのではないでしょうか。
私が初めてシェルスクリプトを書いてうまく動いた瞬間のことは、20年以上経った今でもはっきり覚えています。
画面に期待通りの出力が順番に流れてきた時、思わず「動いた！」と声を上げてしまいました。
この記事では、3,100名以上を指導してきた現役講師として、初めてシェルスクリプトに触れた日の体験と、
「小さな成功体験」がその後の学習をどれほど加速させるかを、正直にお伝えします。
この記事のポイント
・シェルスクリプトは「繰り返し作業に気づいた人」が自然に書き始める
・最初の1本は10行以内の単純な繰り返し処理で十分
・本番実行前は echo で動作対象を確認してから実行する習慣が安全につながる
・失敗ログがそのまま次の教材になる
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
私が初めてシェルスクリプトを書いた日のこと
SE時代の2003年頃、私は毎朝同じ作業を繰り返していました。複数のサーバーのログを確認して、ディスク使用量を調べて、結果をメモ帳に書き留める。
たった10分ほどの作業ですが、毎日のことなので地味に消耗していました。
そこで上司に「シェルスクリプトで自動化できますよ」と言われ、初めて書いてみることにしました。
最初に書いたのは、こんなシンプルなものです。
#!/bin/bash # 複数サーバーのディスク使用量を確認するスクリプト for HOST in web01 web02 db01; do echo "=== $HOST ===" ssh $HOST "df -h / /var" done
毎朝手でやっていた作業が、一瞬で終わった瞬間です。
「これが自動化か」と、腑に落ちた感覚がありました。
コマンドを手で打つ作業をファイルに書くだけで、何度でも同じことができる。
この当たり前の事実が、体感として初めて理解できた瞬間でした。
調子が出てきて、次はログのアーカイブ作業もスクリプト化してみました。
#!/bin/bash # archive_logs.sh: 前日のログファイルを日付付きでアーカイブする LOG_DIR="/var/log/myapp" ARCHIVE_DIR="/data/log_archive" YESTERDAY=$(date -d "yesterday" +%Y%m%d) # アーカイブ先ディレクトリを作成 mkdir -p "${ARCHIVE_DIR}/${YESTERDAY}" # 前日ログをコピー cp ${LOG_DIR}/*.log "${ARCHIVE_DIR}/${YESTERDAY}/" echo "[$(date)] ログアーカイブ完了: ${YESTERDAY}"
# crontab -e で登録 # 毎朝6時に自動実行し、実行ログを /var/log/archive.log に追記する 0 6 * * * /usr/local/bin/archive_logs.sh >> /var/log/archive.log
一度自動化の快感を覚えると、仕事の見え方が変わりました。
「これ毎日やってるな」「この確認、毎回同じだな」という視点が生まれ、
スクリプト化できそうな作業を自然に探すようになっていきました。
もっとも、当時の私はとにかく「動いた」ことが嬉しくて、実行前の確認をおろそかにしていました。
「安全に実行する習慣」は、後から指導する立場になって改めて伝えるようになったことです。
それについては後半の「よくある失敗とその対処法」で詳しく触れます。
シェルスクリプトの「初動作」が学習の転換点になる理由
私がセミナーで3,100名以上を指導してきた経験から言うと、シェルスクリプトを初めてうまく動かせた受講生は、その後の学習速度が明らかに変わります。
1. 「コマンドは道具」から「コマンドは材料」に変わる
コマンドラインを覚える段階では、各コマンドは「一つの道具」として使います。`ls` はファイルを表示する道具、`df` はディスクを確認する道具、という感覚です。
ところがシェルスクリプトを書き始めると、コマンドが「組み合わせる材料」に変わります。
`for` ループでコマンドを繰り返す、`if` 文で条件分岐させる。
この視点の転換が起きると、バラバラに覚えてきたコマンドが「つながる」のです。
「コマンドを覚えても現場でどう使えばいいか分からない」という声をよく聞きます。
シェルスクリプトを書いた瞬間、その答えが体感として見えてきます。
2. 「ちゃんと動く」が次の「もっとやってみたい」につながる
受講生からよく聞かれる質問が「シェルスクリプトはどこから学べばいいですか？」です。私がいつも答えるのは「今やっている手作業を一つ、スクリプトにしてみてください」です。
教材を探して勉強するより、自分の日常作業を自動化してみる方が圧倒的に定着します。
なぜなら、動いた時の達成感が「また書きたい」を生み出すからです。
「難しくなってから覚えよう」ではなく、「今の仕事を楽にするために書く」という動機が学習を加速させます。
学習の継続には、外からの強制より内側から湧く動機が必要です。
シェルスクリプトの初動作は、その動機を生み出す体験として非常に強力です。
3. 失敗した記録がそのまま学習材料になる
私が最初に書いたスクリプトは、もちろん一発では動きませんでした。`ssh $HOST "df -h / /var"` の部分で、SSH鍵の設定が必要なことを知らなかったのです。
Permission deniedが出て、調べて、解決する。
このプロセス自体が、SSHの仕組みを理解する最高の教材になりました。
シェルスクリプトを書く過程で出るエラーは、その時点の自分に必要な知識の欠如を教えてくれます。
20年以上サーバーを運用してきた経験から言うと、エラーを怖がらずに書いてみることが上達の近道です。
ただし一点だけ注意があります。「怖がらずに書く」と「確認せずに実行する」は別物です。
スクリプトを書いたら、実行前に「何をするか」を確認する習慣をつけてください。
そのための具体的な方法は、このあとのステップで説明します。
最初の1本を書くための3つのステップ
1. 自分が毎日手でやっている作業を1つ選ぶ
スクリプトで自動化するべき作業は「複雑なもの」より「繰り返しているもの」です。・毎朝確認しているログファイルを表示する
・ファイルをバックアップするコピーコマンドを打つ
・複数のファイルに同じ変更を加える
こういった「同じことを何度もやっている」作業が最適です。
「仕方ない」と受け入れている繰り返し作業こそ、スクリプト化の最良の候補です。
2. まず手でコマンドを打って、動くことを確認する
スクリプトを書く前に、コマンドを手で実行して期待通りに動くことを確認します。これが非常に重要です。スクリプト化する前に個々のコマンドが正しく動くことを確認しておけば、
問題が起きた時に「コマンド自体の問題」と「スクリプトの問題」を切り分けられます。
3. 動くコマンドをスクリプトファイルに書く
#!/bin/bash # スクリプトの1行目は必ず shebang で始める # コマンドをそのまま書いて実行する df -h / ls -lh /var/log/ | head -20
手で打つコマンドをファイルに書いて、`chmod +x` で実行権限を付けて、`./スクリプト名.sh` で実行する。
この流れを一度体験することが、すべての出発点です。
4. 実行前に echo で「何をするか」を先に確認する
コードが書けたら、すぐに本番実行しないことが大切です。特にファイルを削除したり移動したりするスクリプトは、実行対象を先に確認してから動かしてください。
具体的な方法は「echo dry-run」です。実際の処理コマンドをいったんechoに置き換えて、
「何をしようとしているか」を画面に表示させてから判断します。
# echo dry-run の例: 削除前に対象ファイルを確認する TARGET_DIR="/var/log/myapp" find ${TARGET_DIR} -mtime +30 -type f | while read FILE; do echo "削除予定: ${FILE}" # 確認できたら下の行のコメントを外して実行する # rm "${FILE}" done
この習慣は、セミナーで受講生に最初に教える安全な実行の「型」です。
思わぬファイルを削除してしまう前に、必ずこのステップを踏んでください。
シェルスクリプトが書けると現場で何が変わるか
私の現場経験では、シェルスクリプトを使えるエンジニアとそうでないエンジニアには、仕事の密度に大きな差が生まれます。
・手作業のミスが減る（スクリプトは毎回同じことをする）
・作業の再現性が高まる（スクリプトがそのまま手順書になる）
・後輩への作業引き継ぎが楽になる（動くスクリプトを渡せばいい）
さらに、自動化の感覚が身につくと「仕事の見え方」自体が変わります。
「この確認、毎回同じだな」「この手順、繰り返してるな」という視点が生まれ、
スクリプトを書くたびに変数・if文（条件分岐）・forループ（繰り返し処理）・関数と、
少しずつ力がついていきます。半年後には100行を超えるスクリプトも自然に書けるようになっていた、
という受講生は珍しくありません。
セミナーで受講生から「コマンドは覚えたけど、現場でどう活かせばいいか分からない」という声をよく聞きます。
その答えの一つがシェルスクリプトです。
個々のコマンドを「組み合わせて動かす」経験が、現場で即戦力になる土台を作ります。
そしてもう一つ、現場で「任せてもらえるエンジニア」と「そうでないエンジニア」を分けるのが、
「自分が書いたスクリプトを安全に実行できるか」という姿勢です。
実行前に確認する、止め方を把握した上で動かす——この基本が身についているかどうかが、
実務での信頼度を決めます。
よくある失敗とその対処法
実行権限がなくてエラーになる
# このエラーが出たら bash: ./backup.sh: Permission denied # chmod で実行権限を付ける chmod +x backup.sh ./backup.sh
文字コードの問題でスクリプトが動かない
WindowsのメモパッドやExcelでスクリプトを編集すると、改行コードがCR+LFになることがあります。Linuxのシェルスクリプトは改行コードがLFである必要があります。
# 改行コードを確認する file backup.sh # 「CRLF」と表示されたら変換が必要 # sedで変換する sed -i 's/\r//' backup.sh
変数の展開が意図通りにならない
# NG: シングルクォートでは変数が展開されない echo 'ホスト名は $HOSTNAME です' # 出力: ホスト名は $HOSTNAME です # OK: ダブルクォートで変数を展開する echo "ホスト名は $HOSTNAME です" # 出力: ホスト名は web01 です
エラーメッセージを読まずにコードだけ眺める
スクリプトを実行してエラーが出た時、「どこが悪いんだろう」とコードだけを眺めてしまう方が多いです。エラーメッセージは「どのファイルの何行目でどんなエラーが出たか」を教えてくれます。
# 実行してエラーが出た例 $ bash myscript.sh myscript.sh: line 5: /var/log/myapp: Is a directory # → 5行目で「ディレクトリをファイルとして扱おうとした」エラー # → ファイルパスを /var/log/myapp/app.log のように修正する
まずエラーメッセージを日本語に訳す習慣をつけてください。
自分のPCで動いたのに本番サーバーでエラーになる
自分のPCで動いたスクリプトを本番サーバーで実行したらエラーになる、というケースがあります。原因の多くは、環境によってPATHの設定が異なることです。
スクリプト内ではコマンドの絶対パス（
/bin/cp や /usr/bin/date）を使い、ファイルパスも決め打ちにしておくと、環境差異によるエラーを防げます。
確認せずに実行して取り返しのつかない状態になる
初心者が最もやってしまいやすいのが「動くことを確認したら、すぐ本番で実行する」です。削除系・移動系のスクリプトを確認なしで走らせると、取り消せない結果になることがあります。
必ず「echo dry-run」で対象を先に確認してから、本番の処理を実行してください。
rmやmvを使うスクリプトは特に注意が必要です。
# Step1: echo で削除対象を確認する（この段階では何も削除しない） find /var/log/myapp -mtime +30 -type f | while read FILE; do echo "削除予定: ${FILE}" done # Step2: 問題なければ rm に切り替えて実行する find /var/log/myapp -mtime +30 -type f | while read FILE; do rm -f "${FILE}" echo "[削除完了] ${FILE}" done
スクリプトが止まらなくなった時の対処法
while文の終了条件が間違っていたり、処理が終わらない状況になったりすると、スクリプトが止まらなくなることがあります。
慌てずに、以下の手順でプロセスを確認して止めてください。
# 別のターミナルで実行中のスクリプトを確認する ps aux | grep スクリプト名.sh # 出力例（2列目のPIDを確認する） # tomohiro 1234 98.0 0.1 12345 2345 pts/0 R 14:32 1:23 bash myscript.sh # PID（1234の部分）を指定して停止する kill 1234 # kill が効かない場合は強制終了する kill -9 1234
実行前から「何かあれば ps と kill で止める」と知っておくだけで、
余裕を持って実行できるようになります。
まとめ
シェルスクリプトに初めて触れることへの不安は、多くの人が感じます。でも、最初の1本が動いた時の感動は、その不安を一気に吹き飛ばします。
大切なのは「完璧なスクリプトを最初から書こうとしない」ことです。
手でやっている作業を1つ選んで、とにかく動かしてみる。
エラーが出たら調べて直す。そのサイクルを回すことが、確実な上達につながります。
そして「動いた！」の感動と同じくらい大切なのが、「安全に実行する習慣」です。
echo dry-run で確認する、止め方を知った上で実行する——この2つが身につくと、
現場でも信頼されるエンジニアとして動けるようになります。
| つまずきポイント | 対処法 |
|---|---|
| 実行できない | chmod +x スクリプト名.sh で権限を付ける |
| 変数が展開されない | シングルクォートをダブルクォートに変える |
| 改行コードのエラー | sed -i スクリプト名.sh で変換する |
| エラーを読んでいない | 「line N」と「エラー種別」を日本語に訳して行番号を確認する |
| 本番でのみ動かない | コマンドは絶対パス（/bin/cp等）で書く |
| 実行前に動作を確認したい | rmやmvをechoに置き換えてdry-runで対象を確認してから実行する |
| スクリプトが止まらない | ps aux | grep スクリプト名 でPIDを確認し kill PID で停止する |
| どこから始めればよいか | 今日やった手作業を1つスクリプト化してみる |
・Linuxシェルスクリプト入門｜初心者でも動かせる自動化の第一歩
・getoptsコマンドでbashスクリプトの引数を処理する方法
シェルスクリプトを書くための基礎、体系的に身につけていますか？
シェルスクリプトが上達するのは、コマンドの組み合わせ方を体系的に学んだ後です。ネットの断片情報を寄せ集めるより、まず土台となるLinuxサーバーの全体像を把握してください。
現場で通用する安全なLinuxサーバー構築の「型」を体系的に身につけたい方へ、『Linuxサーバー構築入門マニュアル（図解60P）』を完全無料でプレゼントしています。
「独学の時間がもったいない」「プロから直接、現場の技術を最短で学びたい」という本気の方には、2日で実務レベルのスキルが身につく【初心者向けハンズオンセミナー】も開催しています。
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 次のページへ：Linuxを職場の上司から「任せる」と言われた瞬間の話｜現役講師が語る責任の重さと成長の転換点
- 前のページへ：ローカルLLMの運用コストを試算する方法｜電気代・GPU・人件費から月額ゼロの裏側を検証
- この記事の属するカテゴリ：Linux学習ガイドへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます