Dockerコンテナは「作成 → 起動 → 停止 → 削除」という状態をたどり、それぞれに対応するコマンドがあります。この記事では docker run・docker start・docker stop・docker rm などを状態の流れに沿って整理し、データを失わない止め方、停止しないときの原因の見方、不要なコンテナの片付け方までを説明します。コマンド例は Linux 上の Docker Engine を前提にしていますが、Docker Desktop でも同じように使えます。
コンテナの状態を押さえる
コンテナには主に次の状態があります。docker ps -a の STATUS 列や docker inspect で確認できます。
- created: 作成されたがまだ一度も起動していない
- running: 実行中
- paused: 一時停止中（プロセスが凍結されている）
- restarting: 再起動ポリシーによって再起動している途中
- exited: 停止した。コンテナの設定と書き込み層は残っている
- dead: 削除に失敗するなどして壊れた状態
大事なのは、停止（exited）と削除は別物だという点です。停止したコンテナはディスク上に残り、docker start で再び起動できます。削除すると、コンテナ内に書き込んだファイルは失われます。
docker ps # 実行中のコンテナだけ
docker ps -a # 停止中も含めてすべて
docker inspect --format '{{.State.Status}} {{.State.ExitCode}}' web起動する: docker run / create / start
新しくコンテナを作って起動するのが docker run です。イメージの取得（ローカルに無い場合）、コンテナの作成、起動をまとめて行います。
docker run -d --name web -p 8080:80 nginx:1.27-dはバックグラウンドで実行します。付けないと端末がコンテナの出力に占有されます。--nameを付けておくと、以降のコマンドで ID の代わりに名前で指定できます。同じ名前のコンテナが既にあるとエラーになるので、作り直すときは先に削除します。- イメージのタグ（
1.27など）は例です。latestに頼らず、使うバージョンを明示すると環境の再現性が上がります。
docker create は作成だけを行い、docker start で後から起動します。停止中のコンテナを再開するのも docker start です。docker run を繰り返すと、そのたびに新しいコンテナが増えていくので、「前と同じコンテナを動かしたい」ときは docker start web を使います。
docker create --name web2 -p 8081:80 nginx:1.27
docker start web2
docker start -a web2 # -a で出力を端末に表示停止する: docker stop / kill / pause
通常の停止は docker stop です。コンテナのメインプロセス（PID 1）に SIGTERM を送り、既定では10秒待っても終わらなければ SIGKILL で強制終了します。データベースのように終了処理に時間がかかるものは、待ち時間を延ばします。
docker stop web
docker stop -t 60 db # 最大60秒待つ
docker restart web # 停止してから起動docker kill は既定で SIGKILL を即座に送ります。書き込み途中のデータが壊れるおそれがあるため、docker stop で止まらないときの最後の手段にとどめます。docker pause / docker unpause はプロセスを凍結・再開するだけで、停止とは違いメモリ上の状態はそのまま残ります。
docker stop に時間がかかる・すぐ止まらないとき
毎回ちょうど10秒かかって止まる場合、アプリが SIGTERM を受け取れていない可能性が高いです。よくある原因は次の2つです。
- Dockerfile の CMD がシェル形式:
CMD node server.jsのように書くと、PID 1 はシェルになり、シグナルがアプリに届かないことがあります。CMD ["node", "server.js"]のような exec 形式に直します。 - PID 1 として動くアプリがシグナルを処理していない:
docker run --initを付けると、小さな init プロセスが PID 1 になり、シグナルの中継と子プロセスの後始末をしてくれます。
止まったあとの終了コードも手がかりになります。137 は SIGKILL（128+9）で終了したことを表し、docker kill やタイムアウト、メモリ不足による強制終了で見られます。143 は SIGTERM（128+15）で終了したことを表します。メモリ不足かどうかは docker inspect --format '{{.State.OOMKilled}}' web で確認できます。
削除する: docker rm と片付け
停止したコンテナは docker rm で削除します。実行中のコンテナは削除できないので、先に止めるか、-f で強制的に停止・削除します。
docker rm web
docker rm -f web # 実行中でも強制削除（SIGKILL 相当）
docker rm -v web # 匿名ボリュームも一緒に削除削除前に考えたいのが データの置き場所 です。コンテナ内に直接書き込んだファイルは、docker rm で消えます。データベースのデータやアップロードファイルは、名前付きボリュームかバインドマウントに置いておくと、コンテナを作り直しても残ります。名前付きボリュームは docker rm では削除されず、docker volume rm で明示的に消すまで残ります。
停止済みのコンテナをまとめて片付けるには docker container prune を使います。確認なしで実行する -f は、何が消えるかを docker ps -a --filter status=exited で先に見てから使ってください。
docker ps -a --filter status=exited
docker container prune
docker system df # イメージ・コンテナ・ボリュームの使用量docker system prune は停止中のコンテナ、未使用のネットワーク、タグの無いイメージなどをまとめて削除します。--volumes を付けると使われていないボリュームも対象になり、データベースのデータを消してしまう事故につながります。本番サーバーでは対象を確認しながら、個別のコマンドで片付けるほうが安全です。
一時的な作業用コンテナなら、docker run --rm で起動すると、終了時に自動で削除されて後片付けが要りません。
docker run --rm -it ubuntu:24.04 bashDocker Composeで管理している場合
docker compose で起動したコンテナは、個別の docker stop よりも Compose のコマンドで操作するほうが整合が取れます。
docker compose stop: コンテナを停止するだけで、削除しないdocker compose start: 停止したコンテナを再開するdocker compose down: コンテナとネットワークを削除する。-vを付けると名前付きボリュームも削除されるので注意docker compose up -d: 定義に合わせて作成・起動し、設定が変わっていれば作り直す
「docker compose down -v を実行したら WordPress のデータベースが空になった」という事故は珍しくありません。ボリュームを消す操作の前には、docker exec で mysqldump を取るなど、データのバックアップを取ってから実行してください。
サーバー再起動後も動かしたい場合
docker stop で手動停止したコンテナは、ホストを再起動しても自動では起動しません。サーバー再起動後に自動で起動させたいときは、再起動ポリシーを設定します。
docker update --restart unless-stopped webunless-stopped は「手動で止めた場合を除いて再起動する」、always は「手動で止めても Docker デーモンの再起動時には起動する」という違いがあります。運用中のコンテナにどれが設定されているかは、docker inspect --format '{{.HostConfig.RestartPolicy.Name}}' web で確認できます。各オプションの細かな挙動はバージョンで変わることがあるため、使用中のバージョンの公式ドキュメントも確認してください（2026年10月現在）。
まとめ
- コンテナは created → running → exited → 削除 の流れをたどる。停止と削除は別物
- 新規作成と起動は
docker run、停止中の再開はdocker start。runを繰り返すとコンテナが増える - 停止は
docker stop（SIGTERM → 既定10秒後に SIGKILL）。止まりにくいときは exec 形式の CMD や--initを確認する - 終了コード 137 は SIGKILL、143 は SIGTERM。メモリ不足は
OOMKilledで確認できる - 削除は
docker rm。データは名前付きボリュームやバインドマウントに置き、pruneやdown -vの前にはバックアップを取る