Dockerコンテナが即座に終了する問題の解決方法【2026年最新版】

Dockerコンテナを起動した直後に「Exited (0)」「Exited (137)」などと表示されて終了してしまう問題は、Docker初心者から上級者まで多くの開発者を悩ませるトラブルです。本記事では、この問題の原因を徹底解説し、終了コード別の具体的な解決方法をご紹介します。

このエラーとは？発生する症状

Dockerコンテナが即座に終了する問題とは、docker runコマンドでコンテナを起動した直後、または数秒以内にコンテナが自動的に停止してしまう現象です。docker ps -aコマンドで確認すると、STATUSが「Exited」となっており、コンテナが正常に稼働していない状態が確認できます。

主な症状

この問題が発生すると、以下のような症状が見られます。

• コンテナ起動直後に終了: docker run実行後、すぐにコマンドプロンプトに戻ってしまう
• ステータスが「Exited」: docker ps -aで確認すると「Exited (0)」「Exited (1)」「Exited (137)」などと表示される
• サービスにアクセスできない: コンテナ内で動作するはずのWebサーバーやアプリケーションに接続できない
• ログが空または少ない: docker logsを実行しても、ほとんど出力がない場合がある

この問題は特にDocker初心者や、新しい環境でDockerを使い始めた際に頻繁に発生します。また、Docker Desktopのバージョンアップ後に挙動が変わり、以前は問題なく動いていたコンテナが突然終了するようになったというケースも2026年に入ってから報告が増えています。

このエラーが発生する原因

Dockerコンテナが即座に終了する原因は複数存在します。終了コード（Exit Code）を確認することで、原因を特定しやすくなります。

原因1: フォアグラウンドプロセスが存在しない（Exit Code 0）

最も一般的な原因です。Dockerコンテナは、メインプロセス（PID 1）が終了すると自動的に停止する仕組みになっています。Exit Code 0は「正常終了」を意味しますが、これはコンテナのメインコマンドが正常に完了した（つまり、やるべきことが終わった）ことを示しています。

例えば、以下のような場合にこの問題が発生します：

• シェル（bash）をデフォルトコマンドとして実行しているが、インタラクティブターミナルがアタッチされていない
• スクリプトがバックグラウンドでプロセスを起動し、スクリプト自体は終了してしまう
• echo "Hello"のような一瞬で完了するコマンドを実行している

原因2: メモリ不足による強制終了（Exit Code 137）

Exit Code 137は、コンテナがSIGKILLシグナルを受信して強制終了されたことを意味します。最も一般的な原因は、LinuxカーネルのOOM（Out of Memory）Killerによる強制終了です。

コンテナが許可されたメモリ量を超えて使用しようとした場合、カーネルはシステム全体を保護するためにそのプロセスを強制終了します。これは特に以下の状況で発生しやすくなります：

• コンテナにメモリ制限が設定されている
• ホストマシン自体のメモリが不足している
• アプリケーションにメモリリークがある

原因3: セグメンテーションフォルト（Exit Code 139）

Exit Code 139は、SIGSEGV（セグメンテーション違反）シグナルを受信したことを示します。これは、プログラムがアクセス権限のないメモリ領域にアクセスしようとした際に発生します。

主にC/C++で書かれたプログラムで発生しやすく、以下が原因となることが多いです：

• バッファオーバーフロー
• 解放済みメモリへのアクセス
• NULLポインタの参照

原因4: ENTRYPOINTまたはCMDの設定ミス

DockerfileのENTRYPOINTやCMDの設定が正しくない場合、コンテナは即座に終了します。具体的には：

• スクリプトに実行権限がない
• スクリプトのパスが間違っている
• シェル形式とexec形式の構文ミス

原因5: 必要な環境変数の不足

アプリケーションが起動時に必要とする環境変数が設定されていない場合、初期化に失敗してコンテナが終了します。データベース接続情報やAPIキーなどが典型的な例です。

解決方法1: フォアグラウンドプロセスを維持する（推奨）

Exit Code 0で終了する場合の最も基本的な解決策は、コンテナ内でフォアグラウンドプロセスを維持することです。

手順1: インタラクティブモードで実行する

シェルを使用したい場合は、-itフラグを付けて実行します：

docker run -it ubuntu:latest /bin/bash

-i（–interactive）はSTDINを開いたままにし、-t（–tty）は擬似TTYを割り当てます。この2つを組み合わせることで、コンテナ内でインタラクティブにコマンドを実行できます。

手順2: 長時間実行されるプロセスを使用する

本番環境でコンテナを常時起動しておきたい場合は、フォアグラウンドで実行し続けるプロセスを指定します：

# Webサーバーを実行する例
docker run -d nginx

# カスタムスクリプトを実行する場合
docker run -d my-image tail -f /dev/null

tail -f /dev/nullは何もしないが終了しないコマンドで、デバッグ目的でコンテナを起動したままにしておきたい場合に便利です。

手順3: Dockerfileを修正する

Dockerfileでは、CMDにフォアグラウンドで実行されるコマンドを指定します：

# 悪い例：バックグラウンドで実行してしまう
CMD ["service", "nginx", "start"]

# 良い例：フォアグラウンドで実行
CMD ["nginx", "-g", "daemon off;"]

注意点

• バックグラウンドでプロセスを起動するスクリプトは避ける
• プロセスマネージャー（supervisord等）を使用する場合は、supervisord自体がフォアグラウンドで実行されるよう設定する
• Docker Desktopの最新バージョンでは、以前と挙動が変わっている場合があるため、明示的に-itフラグを指定することを推奨

解決方法2: メモリ関連の問題を解決する（Exit Code 137）

Exit Code 137で終了する場合は、メモリに関連した問題を調査・解決します。

手順1: OOM Killerの発動を確認する

まず、本当にOOM Killerが原因かを確認します：

# コンテナの終了理由を確認
docker inspect --format='{{.State.OOMKilled}}' コンテナID

# ホストのカーネルログを確認
dmesg | grep -i "out of memory"
dmesg | grep -i "killed process"

OOMKilledがtrueの場合、メモリ不足が原因です。

手順2: メモリ使用量を監視する

リアルタイムでメモリ使用量を監視し、どの程度のメモリが必要かを把握します：

# コンテナのリソース使用状況をリアルタイムで確認
docker stats コンテナ名

# 特定のコンテナの詳細を確認
docker inspect コンテナID | grep -i memory

手順3: メモリ制限を調整する

コンテナに割り当てるメモリ量を増やします：

# メモリ制限を2GBに設定
docker run -m 2g my-image

# Docker Composeの場合
services:
  app:
    image: my-image
    deploy:
      resources:
        limits:
          memory: 2G

Docker Desktopを使用している場合は、設定画面からDocker全体に割り当てるメモリ量を増やすことも検討してください。

手順4: アプリケーションの最適化

根本的な解決のため、アプリケーション自体のメモリ使用量を最適化します：

• メモリリークがないか調査する
• 不要なキャッシュを削減する
• 適切なガベージコレクション設定を行う

解決方法3: デバッグと詳細調査（上級者向け）

原因が特定できない場合は、以下の高度なデバッグ手法を使用します。

手順1: コンテナのログを詳細に確認する

# 全てのログを表示
docker logs コンテナID

# 最新のログをリアルタイムで追跡
docker logs -f コンテナID

# タイムスタンプ付きで表示
docker logs -t コンテナID

手順2: 終了したコンテナの状態を保存してデバッグする

コンテナが即座に終了してしまい、シェルでアクセスできない場合は、docker commitを使用します：

# 終了したコンテナを新しいイメージとして保存
docker commit 終了したコンテナID debug-image

# 別のコマンドで起動してデバッグ
docker run -it --entrypoint /bin/bash debug-image

手順3: ENTRYPOINTをオーバーライドしてデバッグする

元のENTRYPOINTを無視してシェルで起動することで、コンテナ内部を調査できます：

docker run -it --entrypoint /bin/bash イメージ名

手順4: docker inspectで詳細情報を取得する

# 終了コードと終了時刻を確認
docker inspect --format='{{.State.ExitCode}} - {{.State.Error}} - {{.State.FinishedAt}}' コンテナID

# 全ての状態情報を表示
docker inspect コンテナID | jq '.State'

手順5: ホストシステムのログを確認する

# カーネルログでセグフォルトやOOMを確認
dmesg | tail -50

# journalctlでDockerデーモンのログを確認
journalctl -u docker.service --since "1 hour ago"

エラーを予防するには

コンテナの即時終了を未然に防ぐため、以下のベストプラクティスを実践しましょう。

ヘルスチェックを設定する

Dockerfileにヘルスチェックを追加することで、コンテナの状態を監視できます：

HEALTHCHECK --interval=30s --timeout=10s --start-period=5s --retries=3 \
  CMD curl -f http://localhost/ || exit 1

再起動ポリシーを設定する

コンテナが予期せず終了した場合に自動で再起動するよう設定します：

# 常に再起動
docker run --restart=always my-image

# 異常終了時のみ再起動（最大3回）
docker run --restart=on-failure:3 my-image

適切なリソース制限を設定する

メモリとCPUの制限を適切に設定し、リソース枯渇を防ぎます：

docker run -m 1g --cpus="1.5" my-image

ログの適切な管理

ログが肥大化してディスクを圧迫しないよう、ログドライバーとローテーションを設定します：

docker run --log-driver json-file --log-opt max-size=10m --log-opt max-file=3 my-image

まとめ

Dockerコンテナが即座に終了する問題は、原因を正しく特定することが解決への第一歩です。終了コード（Exit Code）を確認し、それに応じた対処を行いましょう。

重要ポイントの振り返り

• Exit Code 0: フォアグラウンドプロセスが存在しないことが原因。-itフラグの使用や、長時間実行されるプロセスの指定で解決
• Exit Code 137: メモリ不足（OOM Killer）が原因。メモリ制限の緩和やアプリケーションの最適化で対処
• Exit Code 139: セグメンテーションフォルト。アプリケーションのバグを修正する必要がある
• Exit Code 1: 一般的なエラー。ログを確認して具体的な原因を特定する

解決できない場合の次のステップ

上記の方法で解決できない場合は、以下を試してください：

1. Docker公式ドキュメントで最新の情報を確認する
2. Stack OverflowやDocker Community Forumsで類似の事例を検索する
3. 使用しているイメージのGitHub Issuesを確認する
4. 最小構成で問題を再現し、原因を切り分ける

2026年現在、Docker Desktopの挙動変更やコンテナランタイムのアップデートにより、以前とは異なる問題が発生することもあります。常に最新の情報をキャッチアップすることが重要です。

参考資料

• How to Fix “Container Exits Immediately” Issues in Docker – OneUptime Blog
• Understanding Docker Errors: A Developer’s Troubleshooting Handbook – Medium
• Why Docker Container Exit Code 137 and How to Fix It – DevToDevOps
• Exit Codes in Docker and Kubernetes: The Complete Guide – Komodor
• Docker Troubleshoot and Diagnose – 公式ドキュメント
• Why Does My Docker Container Stop? – Tutorial Works
• 6 Ways to Debug an Exploding Docker Container – HTTP Toolkit
• Troubleshooting Docker Container Exits Immediately – LabEx