Dockerのコンテナのログは docker logs コンテナ名 で確認でき、-f で追いかけ表示、--since や --tail で範囲を絞れます。一方で、標準の設定のままではログファイルに上限がなく、長く動かしているサーバーではディスクを使い切る原因になります。この記事では、ログの見方と絞り込み方、ログがどこに保存されているか、daemon.json やComposeでのローテーション設定、WordPressのコンテナでエラーを探すときの考え方までを説明します。
内容はLinux上のDocker Engineの安定版（2026年10月現在）を前提にしています。Docker Desktopでも docker logs の使い方は同じですが、ログファイルはDesktopが管理する仮想マシンの中にあるため、ファイルを直接触る手順は当てはまりません。
Dockerのログは「標準出力と標準エラー」
docker logs で見えるのは、コンテナのメインプロセス（PID 1）が標準出力（stdout）と標準エラー（stderr）に書き出した内容です。アプリがコンテナ内のファイルにだけログを書いている場合、docker logs には何も出ません。
公式のnginxイメージは、アクセスログとエラーログを /dev/stdout と /dev/stderr へのシンボリックリンクにしているため、そのまま docker logs で見えます。自作のイメージでは、アプリのログ出力先を標準出力にするか、同じようにリンクを張るのが基本です。「コンテナは動いているのに docker logs が空」というときは、まずログの出力先を疑ってください。
docker logsの基本と絞り込み
# すべて表示
docker logs web
# 追いかけ表示（Ctrl+Cで抜ける。コンテナは止まらない）
docker logs -f web
# 末尾100行だけ、時刻付きで
docker logs --tail 100 -t web
# 直近30分、または時刻で範囲指定
docker logs --since 30m web
docker logs --since 2026-10-18T09:00:00 --until 2026-10-18T10:00:00 web-t（--timestamps）を付けると、Dockerが受け取った時刻が各行の先頭に付きます。アプリ自身のログに時刻がない場合や、タイムゾーンが分からない場合に役立ちます。表示される時刻はUTCなので、日本時間と9時間ずれる点に注意します。
grepで探すときは 2>&1 を付ける
docker logs は、コンテナのstderrに出た行を、ホスト側でもstderrとして出力します。そのため次のように書くと、エラーログがgrepを素通りして画面に全部出てしまいます。
# stderrの行がgrepに渡らない
docker logs web | grep -i error
# stdoutとstderrをまとめてからgrepに渡す
docker logs web 2>&1 | grep -i error「grepしたのに絞り込まれない」という症状のほとんどはこれが原因です。
Composeの場合
Docker Composeで動かしている場合は、サービス名で指定できます。
docker compose logs -f wordpress
docker compose logs --tail 50 --since 1h db
docker compose logs -f # 全サービスを色分けして表示複数のサービスをまとめて追いかけられるので、「Webサーバーのエラーと同じ時刻にDBで何が起きていたか」を見比べるときに便利です。
ログはどこに保存されているか
ログの保存方法は「ログドライバー」で決まります。Docker Engineの既定は json-file で、ログは1行ずつJSONとして次の場所に保存されます。
# ログファイルの場所を調べる
docker inspect --format '{{.LogPath}}' web
# サイズを確認する
sudo du -h "$(docker inspect --format '{{.LogPath}}' web)"
# 使っているログドライバーを確認する
docker inspect --format '{{.HostConfig.LogConfig.Type}}' web
docker info --format '{{.LoggingDriver}}'多くの環境では /var/lib/docker/containers/<コンテナID>/<コンテナID>-json.log です。このファイルは、ログの上限を設定しない限り増え続けます。サーバーのディスクがいっぱいになって調べてみたら、特定のコンテナのログが数十GBになっていた、という事態はよく起こります。
ローテーションを設定してログ肥大化を防ぐ
サーバー全体の既定値を変える（daemon.json）
/etc/docker/daemon.json に既定のログ設定を書きます。ファイルがなければ作ります。既にある場合は、他の設定を消さないように項目を追記してください。
{
"log-driver": "json-file",
"log-opts": {
"max-size": "10m",
"max-file": "3"
}
}この例では、1ファイル10MBに達したら新しいファイルに切り替え、最大3ファイル（コンテナあたり約30MB）まで残します。max-file などの値は数値でも文字列として "3" のように書く必要があり、引用符を忘れるとDockerが起動しなくなります。
書き換えたら、構文を確認してからDockerを再起動します。
sudo python3 -m json.tool /etc/docker/daemon.json
sudo systemctl restart docker注意点は二つあります。一つは、systemctl restart docker で動いているコンテナも再起動されることです（live-restore を有効にしている場合を除く）。本番サーバーでは作業時間を決め、事前にバックアップを取ってから行います。もう一つは、この設定が反映されるのは これから作るコンテナだけ という点です。既存のコンテナは作り直す（Composeなら docker compose up -d --force-recreate）まで以前の設定のままです。
ログドライバーを local にする方法もあります。local ドライバーは既定でローテーションと圧縮を行う形式で、docker logs もそのまま使えます。ただし保存形式が json-file と異なるため、ログファイルを直接読む別のツールを使っている場合は影響を確かめてから切り替えてください。
サービスごとに設定する（Compose）
特定のサービスだけ上限を変えたい場合は、compose.yaml の logging に書きます。
services:
wordpress:
image: wordpress:php8.3-apache
logging:
driver: json-file
options:
max-size: "10m"
max-file: "5"docker run なら --log-opt max-size=10m --log-opt max-file=3 で同じ指定ができます。
いま大きくなっているログをどうするか
ローテーションを設定しても、既存のコンテナの肥大化したファイルは自動では小さくなりません。手っ取り早いのはコンテナを作り直すことです。どうしても作り直せないときは sudo truncate -s 0 ログファイルのパス で中身を空にする方法がありますが、それまでのログは失われ、Dockerが管理しているファイルを外から触ることになります。必要な部分を先にコピーして保存し、最終手段と考えてください。ログファイルを rm で消すのは、ディスク容量が解放されないことがあるので避けます。
journaldや外部サービスに送る場合
systemdのjournalにまとめたい場合は journald ドライバーを使い、journalctl CONTAINER_NAME=web のように絞り込めます。この場合の保存期間やサイズはjournald側の設定で決まります。
FluentdやクラウドのログサービスへDockerから直接送るドライバーもあります。以前はこれらのドライバーにすると docker logs が使えませんでしたが、Docker Engine 20.10以降は「デュアルロギング」により、手元にも一時的なキャッシュが残って docker logs で読めるようになっています。送信先が止まったときにアプリの動作がどうなるか（ログを捨てるのか、待つのか）はドライバーの設定で変わるため、各ドライバーの公式ドキュメントで確認してください。
WordPressのコンテナでエラーを探す
公式wordpressイメージ（Apache版）では、Apacheのアクセスログとエラーログ、PHPのエラーは標準出力・標準エラーに出るため、docker compose logs -f wordpress で確認できます。画面が真っ白になったときは、まずここで PHP Fatal error の行を探します。
docker compose logs --since 10m wordpress 2>&1 | grep -E "PHP (Fatal|Warning)"wp-config.php で WP_DEBUG_LOG を有効にした場合、ログは標準出力ではなく wp-content/debug.log に書かれます。この場合は docker compose exec wordpress tail -n 50 /var/www/html/wp-content/debug.log のようにコンテナ内のファイルを見ます。debug.log は外から読める場所にできるため、調査が終わったら設定を戻し、ファイルも削除しておきます。
データベースのコンテナ（MySQLやMariaDB）では、起動時の初期化エラーやパスワードの不一致が docker compose logs db に出ます。WordPress側に「データベース接続確立エラー」が出たら、WordPressとDBの両方のログを同じ時間帯で見比べると原因を絞り込めます。
まとめ
docker logsに出るのはコンテナのstdoutとstderr。空のときはアプリのログ出力先を確認します。-f・--tail・--since・-tで絞り込み、grepに渡すときは2>&1を付けます。Composeではdocker compose logs サービス名が使えます。- 既定の
json-fileは上限がないため、daemon.jsonかComposeのloggingでmax-sizeとmax-fileを設定します。値は文字列で書きます。 - 既定値の変更は新しく作るコンテナから反映されます。既存のコンテナは作り直しが必要です。
- WordPressは公式イメージならApacheとPHPのエラーが
docker logsに出ます。debug.logを使ったときは調査後に設定とファイルを片付けます。