docker logs コマンド詳解：コンテナ障害を素早く特定する7つのテクニック

docker logs payment-service を実行した瞬間、画面には INFO レベルのログが何万行も流れ出す——本番の決済サービスが落ちた直後、その一行の ERROR は、どこに埋もれているのでしょうか。

ログが多すぎて読めない、リアルタイム監視、時間帯での絞り込み、エラーの素早い特定——有事の場では想像以上に手間がかかります。本記事では docker logs の実用的なテクニックを7つ、基本から応用まで紹介し、コンテナ障害の切り分けを速くします。

基本的なログ確認

1. いちばん基本的なログ表示

まずは基本形です。次のコマンドは見慣れているはずです。

docker logs <コンテナ名>
# またはコンテナ ID
docker logs abc123def456

起動から現在までのログがすべてターミナルに出力されます。一見便利ですが、実際にはログが滝のように流れ、読み取れないことが多いです。

初めてこの状況に当たったとき、コンテナは3日間稼働しており、ログは数万行。画面が高速スクロールし、ERROR 一行も掴めませんでした。あとから分かったのですが、この「裸の」コマンドはそういう場面向きではない、と。

ではいつ使うか？

正直、次の2パターンだけです。

• コンテナを起動したばかりで、ログがまだ少ない
• すべてのログをファイルにエクスポートしてバックアップしたい

それ以外は、別の方法を使いましょう。

2. 直近 N 行だけを見る

日常でいちばん使うのはこちらです。

docker logs --tail 50 my-container

--tail で最後の N 行だけを表示します。私はだいたい 50 行か 100 行から始めます。問題の手がかりが足りなければ、200 行へ——いきなり全量を見るより段階的に広げる方が速いです。

実践例：

先週、API サーバーの応答が突然遅くなりました。まず次を実行しました。

docker logs --tail 100 api-server

直近 100 行にデータベース接続タイムアウトの警告があり、原因はコードではなく DB 側だとすぐに絞れました。

Vultr - 高性能NVMeクラウドサーバー、世界32拠点、Dockerワンクリック展開対応

価格を見る →広告

コアは「まず直近のログで大まかな方向を決める」こと。足りなければ他の手段で深掘りします。

リアルタイム監視

3. ログストリームをリアルタイムで見る

デバッグで特に便利なのが、Linux の tail -f のようにログを追いかける方法です。

docker logs -f my-container

-f（follow）を付けると、新しいログが出るたびに画面に表示されます。

私がよく使う場面：

1. コンテナ起動時の監視
   新しいサービスをデプロイしたら、起動直後に -f でログを追います。設定ミスは起動ログにすぐ出るので、落ちてから調べるより早いです。

2. 再現しながら現場を押さえる
   特定操作でのみ出るバグなら、先に docker logs -f を開いてから操作を実行し、エラーをその場で捕まえます。

さらに実用的な組み合わせ：

docker logs -f --tail 100 my-container

直近 100 行を見たうえで、以降のログをリアルタイム追跡できます。

-f の前に、コンテナが動いているか docker ps で確認しておきましょう。同僚が半時間ログを眺え続けていたのですが、コンテナはすでに停止していて、新しい行は一切出ていませんでした。

精密なフィルタリング

4. 時間範囲で絞り込む

個人的にお気に入りの機能です。「昨夜3時にエラーが出た」と聞いて、朝にはさらに数千行ログが積み上がっている——その時間帯だけどう抜き出すか。

--since と --until を使います。

# 指定時刻以降のログ
docker logs --since "2025-12-18T03:00:00" my-container

# 時間範囲を指定
docker logs --since "2025-12-18T03:00:00" --until "2025-12-18T04:00:00" my-container

形式は ISO 8601 ですが、相対時間も使えます。

# 直近1時間
docker logs --since 1h my-container

# 直近30分
docker logs --since 30m my-container

# 過去24時間
docker logs --since 24h my-container

実例：

ある夜、注文サービスが4時頃に落ち、朝9時に調査したとき、ログは5時間分溜まっていました。次のように範囲を切りました。

docker logs --since "2025-12-18T03:30:00" --until "2025-12-18T04:30:00" order-service

障害前後1時間だけを見て、メモリ不足のスタックトレースにすぐ到達。全量を追っていたら、半日かかっていたかもしれません。

5. タイムスタンプを表示する

ERROR は見えたのに、いつ起きたか分からず監視データと突き合わせられない——そんなときはタイムスタンプが必要です。

docker logs -t my-container

-t で各行の先頭に時刻が付きます。

2025-12-18T10:23:45.123456789Z [INFO] Server started
2025-12-18T10:23:47.234567890Z [ERROR] Database connection failed

他のオプションと組み合わせるのがおすすめです。

# 直近30分＋タイムスタンプ
docker logs -t --since 30m my-container

# リアルタイム＋タイムスタンプ
docker logs -f -t my-container

性能分析では特に効きます。リクエストの入りから処理完了まで、どの段階が遅いか時系列で追えます。

6. grep でキーワードを絞る

INFO ばかりの中から ERROR だけ見たいときは grep です。

docker logs my-container | grep "ERROR"

ただし、grep が効かないことがあります。

初めて遭遇したときは困惑しました。コンテナには ERROR があるのに grep でヒットしない。理由は、ログが stderr に出ていて、パイプ | がデフォルトで stdout だけを渡すためです。

Railway - モダンなデプロイプラットフォーム、煩わしい運用から解放、数分で公開

今すぐ始める →広告

stderr を stdout にまとめます。

docker logs my-container 2>&1 | grep "ERROR"

2>&1 はファイル記述子2（stderr）を1（stdout）へリダイレクトし、grep がすべての行を拾えます。

さらに使える組み合わせ：

# ERROR の前後10行
docker logs my-container 2>&1 | grep -C 10 "ERROR"

# 大文字小文字を無視
docker logs my-container 2>&1 | grep -i "error"

# 直近20件のエラー
docker logs -t my-container 2>&1 | grep -i "error" | tail -20

-C 10 はマッチ行の前後10行も出すので、エラー一行だけでは分からない流れを追うのに向いています。

応用テクニック

7. ログファイルの実体の場所を確認する

コンテナのログは、ホスト上の実ファイルとしても保存されています。場所は次で分かります。

docker inspect --format='{{.LogPath}}' my-container

出力例：

/var/lib/docker/containers/abc123.../abc123...-json.log

用途：

1. ファイルを直接読む
   ログが巨大で docker logs が Docker デーモンに負荷をかけるときは、ファイル直読みの方が速いこともあります。

   sudo tail -f /var/lib/docker/containers/abc123.../abc123...-json.log

2. バックアップ

   sudo cp /var/lib/docker/containers/abc123.../abc123...-json.log ./backup/

3. エディタで分析
   vim などで開けば、高度な検索も使えます。

なお、このファイルは JSON 形式で1行1レコードなので、読みづらい場合は docker logs の方が楽です。

プレーンテキストでエクスポート：

docker logs my-container > container.log

人が読みやすいテキストとして保存・共有できます。

本番環境のベストプラクティス

8. ログローテーションの設定（ディスク満杯を防ぐ）

本番で見落とされがちですが、いちばん重要な設定の一つです。

実際にあった話：

数ヶ月動き続けたコンテナのログが肥大化し、ホストのディスクを使い切りました。サーバー上のコンテナが一斉に停止し、DB も書き込めず、サイトがダウン。2時間調査して、やっとログが原因だと分かった——そういう事故です。

防ぎ方：ログローテーション

/etc/docker/daemon.json に次を追加します。

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

意味：

• max-size：1ファイル最大 10MB
• max-file：最大3ファイル保持

コンテナあたり最大 30MB 程度に抑えられ、10MB に達すると新ファイルを作り、3ファイルを超えた古いものは削除されます。

Alibaba Cloud - 開発者向けクラウドの第一候補、Lighthouse サーバー15%OFF、プロジェクトの迅速な立ち上げを支援

15%割引を入手 →広告

反映：

daemon.json 変更後は Docker を再起動します。

sudo systemctl restart docker

注意： 再起動ですべてのコンテナも再起動するため、本番ではメンテナンス枠で実施してください。

単一コンテナだけ設定する場合：

docker run -d \
  --log-opt max-size=10m \
  --log-opt max-file=3 \
  my-image

他のコンテナには影響しません。

9. 本番環境のログ管理方針

docker logs を使い続けると、ログ量が増えるほどコマンドが遅くなり、ターミナルが固まることもあります。デーモンへの負荷が原因です。

規模別の目安：

• 小規模（コンテナ1〜10個）

  • docker logs ＋ ログローテーションで十分
  • 追加インフラ不要でシンプル

• 中〜大規模（10個超、マイクロサービス）

  • 集中ログ基盤がほぼ必須
  • 例：ELK（Elasticsearch + Logstash + Kibana）、Loki、Fluentd、Splunk

大規模で docker logs だけでは足りない理由：

1. 性能：多数コンテナを同時に追うとデーモン負荷が高い
2. 横断：1リクエストが10サービスをまたぐと、ログが10コンテナに分散
3. 履歴：コンテナ再起動後、古いログは docker logs では追えない場合がある
4. 協業：全員がサーバーに SSH してコマンドを打つのは現実的でない

私の提案：

• Docker を学び始めたばかり → docker logs を押さえる
• 個人・小チーム → ローテーションを設定し、docker logs で運用可
• 本番でコンテナ10個超 → 集中ログを本気で検討
• マイクロサービス → 集中ログは「あったら便利」ではなく必須に近い

まとめ

冒頭の「深夜3時、決済サービスが落ちた」場面を、今なら次の3ステップで進めます。

1. docker logs --tail 100 payment-service で直近を確認
2. 手がかりがなければ時間範囲：docker logs --since "2025-12-18T03:00:00" --until "2025-12-18T03:30:00" payment-service
3. タイムスタンプ＋grep：docker logs -t payment-service 2>&1 | grep -i "error" | tail -20

多くても2分程度で切り分けが終わります。

docker logs の価値は、すべてのオプションを暗記することではなく、その場面に合う組み合わせを選べることにあります。

最後にもう一度——本番で動かしているなら、今すぐログローテーションを設定してください。数行の設定が、ディスク満杯の夜を救います。

クイックリファレンス

# 基本
docker logs <コンテナ名>                    # 全ログ
docker logs --tail 50 <コンテナ名>         # 直近50行

# リアルタイム
docker logs -f <コンテナ名>                # 追跡
docker logs -f --tail 100 <コンテナ名>     # 直近100行＋追跡

# 時間フィルター
docker logs --since 1h <コンテナ名>        # 直近1時間
docker logs --since "2025-12-18T03:00:00" <コンテナ名>  # 指定時刻以降

# 検索
docker logs -t <コンテナ名>                           # タイムスタンプ付き
docker logs <コンテナ名> 2>&1 | grep -i "error"      # エラー検索
docker logs <コンテナ名> 2>&1 | grep -C 10 "error"   # 前後コンテキスト付き

# 応用
docker inspect --format='{{.LogPath}}' <コンテナ名>   # ログファイルの場所
docker logs <コンテナ名> > log.txt                   # エクスポート

次にコンテナで困ったときは、このカードを手元に置いて対応してください。