Bash エラーメッセージのリダイレクト

JPKODA 編集部 May 11, 2026

Bash においてエラーメッセージをリダイレクトすることは、堅牢で管理しやすいスクリプトを記述するための必須スキルです。標準出力（stdout）がコマンドの正常な実行結果を処理するのに対し、標準エラー出力（stderr）はプログラムが診断メッセージ、警告、エラーを送信する場所です。

これら2つのデータストリームを分離することで、異なるタイプのコマンド出力に対してより精密なコントロールが可能になります。これはシステムのログ記録、コードのデバッグ、そして中断のないオートメーションプロセスを構築する上で極めて重要です。

1. 標準エラー出力 (stderr) の深い理解

デフォルトでは、Bash で実行されるすべてのコマンドは2種類の出力ストリームを生成する可能性があります：

標準出力 (stdout): プログラムが正常に実行された際の結果を書き込む場所です。ファイル記述子 1 で表されます。
標準エラー出力 (stderr): プログラムがエラーメッセージ、警告、または診断情報を書き込む場所です。ファイル記述子 2 で表されます。

通常、stdout と stderr はどちらもターミナル画面に直接表示されます。しかし、これらを分離することはスクリプトの信頼性とメンテナンス性を高めるために不可欠です。

例えば、ログファイルを処理するスクリプトを考えてみましょう。処理結果を stdout に出力しつつ、読み取り権限のないファイルに遭遇した際のエラーを stderr に出力します。もし stderr を独立したエラーログファイルにリダイレクトしていれば、通常の出力結果をエラーメッセージで汚すことなく、問題を簡単にトラブルシューティングできます。

簡単な ls コマンドでファイルを表示する例を見てみましょう：

ls existing_file.txt（存在するファイル）を実行すると、内容（ファイル名）は stdout に送られます。
ls non_existent_file.txt（存在しないファイル）を実行すると、エラーメッセージ "ls: cannot access 'non_existent_file.txt': No such file or directory" は stderr に送られます。

2. エラーリダイレクトの基本

stderr をリダイレクトする主な方法は、ファイル記述子 2 とリダイレクトオペレータ >` を組み合わせて使用することです。

2.1 stderr をファイルにリダイレクトする

コマンドのエラー出力のみを特定のファイルに送るには、2> の後にファイル名を指定します。

# 例 1: stderr のみをリダイレクト
# 'ls' コマンドが存在しないファイルをリストしようとします。
# そのエラーメッセージはターミナルではなく 'error.log' に送信されます。
ls non_existent_file.txt 2> error.log

# もし 'existent_file.txt' が存在する場合、その出力は依然として stdout に入り（ターミナルに表示され）ます。
ls existent_file.txt non_existent_file.txt 2> error.log
# ターミナルには "existent_file.txt" が表示されます。
# 一方、"non_existent_file.txt" に関するエラーは静かに error.log に書き込まれます。

# error.log の内容を確認
cat error.log

この例では、2> によってファイル記述子 2（標準エラー出力）からのデータのみがリダイレクトされることを保証しています。標準出力（ファイル記述子 1）は、明示的にリダイレクトされない限り、依然としてコンソールにプリントされます。

2.2 stdout と stderr をそれぞれ別のファイルにリダイレクトする

実際のアプリケーションでは、成功した出力とエラーの出力を分けて別々のファイルに保存するのが非常に一般的です。

# 例 2: stdout を一つのファイルへ、stderr を別のファイルへ
# このコマンドは existing.txt (成功) と non_existent.txt (失敗) をリストします。
ls existing.txt non_existent.txt 1> output.txt 2> error.log

# output.txt を確認
cat output.txt
# 期待される結果: existing.txt

# error.log を確認
cat error.log
# 期待される結果: ls: cannot access 'non_existent.txt': No such file or directory

ここで、1> output.txt は stdout を output.txt へ送り、2> error.log は stderr を error.log へ送っています。1> と 2> の記述順序は通常問いませんが、コードの可読性のために一貫した習慣を保つことが推奨されます。

3. 標準出力と標準エラー出力の統合

場合によっては、stdout と stderr の両方を同じ目的地（一つの統合ログファイルなど）に送りたいことがあります。これにはいくつかの方法があります。

3.1 stderr を stdout の出力先にリダイレクトする

2>&1 という構造は、ファイル記述子 2 (stderr) をファイル記述子 1 (stdout) が現在指している場所にリダイレクトします。

極めて重要な点は、両方をファイルに書き込む場合、2>&1 は必ず 1>（または省略形の >）の後ろに置かなければならないということです。これは Bash が左から右へリダイレクトを解析するためです。

# 例 3: stdout と stderr を統合して一つのファイルにリダイレクト
# 存在するファイルと存在しないファイルをリストします。
# 成功した出力とエラーメッセージの両方が 'all_output.log' に入ります。
ls existing.txt non_existent.txt > all_output.log 2>&1

# 内容を確認
cat all_output.log
# 期待される結果:
# existing.txt
# ls: cannot access 'non_existent.txt': No such file or directory

このプロセスの解析：

> all_output.log がまず stdout (1) をファイル all_output.log に向けます。
2>&1 が次に stderr (2) を、現在の stdout (1) が指している場所、つまり all_output.log に向けます。

アンチパターン（失敗例）： もし 2>&1 > all_output.log と書くと、「まず stderr を stdout に追随させ（この時点ではまだターミナル画面）、その後に stdout をファイルに向ける」という意味になります。結果として、正常な情報だけがファイルに入り、エラーメッセージは依然としてターミナルに表示されてしまいます！

3.2 統合リダイレクトの短縮構文 (Bash 4+)

利便性のために、Bash 4 以降では &> という非常にシンプルな記号が導入されました。これを使うと stdout と stderr を一括で同じファイルにリダイレクトできます。

# 例 4: '&>' を使用した統合リダイレクト
# これは '> all_output.log 2>&1' と全く同じ効果があります
ls existing.txt non_existent.txt &> combined_output.log

# 内容を確認
cat combined_output.log

すべての情報を一つの目的地にまとめたい場合、この短縮記法はコードがクリーンになるため、通常はこちらが推奨されます。

4. Linuxの「ブラックホール」へのリダイレクト：/dev/null

/dev/null は Unix ライクなシステムにおける特殊なデバイスファイルで、よく「空デバイス」や「データブラックホール」と呼ばれます。/dev/null にリダイレクトされたデータはすべて破棄され、跡形もなく消え去ります。

特定の出力（特に関心のないエラーメッセージや、発生が予想されるエラー）を抑制したい場合、この機能は極めて有用です。

4.1 stderr を静かに破棄する

# 例 5: エラーメッセージの抑制
# 'ls non_existent_file.txt' が生成するエラーは直接破棄されます。
ls non_existent_file.txt 2> /dev/null

# コマンドに正常な stdout がある場合、正常な内容は依然としてターミナルに表示されます。
ls existing.txt non_existent_file.txt 2> /dev/null
# 期待される結果: ターミナルには existing.txt のみが表示され、エラーメッセージは見えません。

これは、無害な警告を生成する可能性のあるコマンドを実行する場合や、失敗する可能性があるもののユーザーに通知する必要がない操作をスクリプトで意図的に試行する場合に非常に価値があります。

4.2 stdout と stderr の両方を同時に破棄する

# 例 6: 完全なサイレント化（すべての出力を抑制）
# 成功してもエラーになっても、出力は一切表示されず、ログも残りません。
ls existing.txt non_existent_file.txt > /dev/null 2>&1

# あるいはモダンな短縮記法を使用:
ls existing.txt non_existent_file.txt &> /dev/null

これはバックグラウンドでのサイレントタスク（インタラクティブなフィードバックが不要なもの）や、単に $? でコマンドの終了ステータスコードを確認したいだけで、出力を画面に出したくない場合によく使われます。

5. リダイレクト出力の追記

標準出力を処理する時と同様に、2>> を使用して stderr の内容を既存ファイルの末尾に追記（append）できます。これは蓄積されていくエラーログを作成するのに非常に実用的です。

# 例 7: stderr をログファイルに追記
echo "--- スクリプト起動 ---" >> application_errors.log
date >> application_errors.log

# 1回目の実行でエラーが発生
ls non_existent_file_1.txt 2>> application_errors.log

# 2回目の実行で別のエラーが発生
ls non_existent_file_2.txt 2>> application_errors.log

# 内容を確認
cat application_errors.log
# 期待される結果:
# --- スクリプト起動 ---
# <現在の日時>
# ls: cannot access 'non_existent_file_1.txt': No such file or directory
# ls: cannot access 'non_existent_file_2.txt': No such file or directory

これにより、時間の経過とともにエラー情報を蓄積していくことができます。長時間実行されるプロセスや、毎日自動実行されるスケジュールタスク (Cron jobs) にとって、すべての問題を一箇所で追跡することは極めて重要です。

6. 実践ケーススタディ：システムバックアップスクリプトでのエラー処理

第1章では、システム管理タスクのオートメーションに関する実戦ケースを紹介しました。非常に典型的なタスクの一つがファイルのバックアップです。

リスト内のファイルをバックアップディレクトリにコピーしようとするスクリプトを想定します。もしスクリプト実行前に一部のファイルが削除されていた場合、cp コマンドは stderr エラーを生成します。これらのエラーをキャプチャしてエラーログに記録しつつ、スクリプトの実行を中断させないようにする必要があります。

シナリオ: バックアップスクリプトがファイルリストをループします。一部のファイルは存在しない可能性があります。

#!/bin/bash

BACKUP_DIR="/tmp/backup_$(date +%Y%m%d%H%M%S)"
ERROR_LOG="backup_errors.log"
SOURCE_FILES=("file1.txt" "file2.txt" "non_existent_file.txt" "another_file.txt")

echo "バックアッププロセスを開始します..."

# テスト用のダミーファイルを作成
touch file1.txt file2.txt another_file.txt
mkdir -p "$BACKUP_DIR"

# エラーログにタイムスタンプ付きの区切り線を追加
echo "--- バックアップエラーログ $(date) ---" >> "$ERROR_LOG"

for file in "${SOURCE_FILES[@]}"; do
    # コピーを試行し、エラーメッセージをエラーログに追記する
    if cp "$file" "$BACKUP_DIR" 2>> "$ERROR_LOG"; then
        echo "バックアップ成功: $file"
    else
        echo "バックアップ失敗: $file (詳細は $ERROR_LOG を確認してください)"
    fi
done

echo "バックアッププロセスが終了しました。$ERROR_LOG をチェックして異常がないか確認してください。"

# テスト用ファイルとディレクトリのクリーンアップ
rm -f file1.txt file2.txt another_file.txt
rm -rf "$BACKUP_DIR"

コード解析:

cp "$file" "$BACKUP_DIR" 2>> "$ERROR_LOG": この行が核心です。ファイルのコピーを試みます。もし cp がエラー（例：ファイルが存在しない）に遭遇した場合、そのエラーメッセージは backup_errors.log に追記されます。
if 文が cp の終了ステータスコードをチェックします。成功すれば成功メッセージをプリントし、失敗（非ゼロのステータスコード）した場合は失敗のヒントを表示してユーザーをエラーログへと誘導します。

このパターンにより、個別のファイルバックアップに失敗してもスクリプトは続行して後続のタスクを完了でき、同時に明確なエラー追跡レコードを保持できます。これこそが、オートメーションシステムスクリプトが持つべき堅牢性（ロバストネス）です。