Dockerコンテナ起動コマンドの使い分け｜run・start・execと起動しない時の対処

Dockerコンテナの起動でつまずく原因は、ほぼ一つに絞れます。「コンテナを作る」と「コンテナを動かす」が別の操作であることを知らずに、毎回 docker run を叩いてしまうことです。docker run は作成と起動をまとめて行うコマンドで、すでに存在するコンテナを動かすのは docker container start、動いているコンテナに入るのは docker exec と、役割がはっきり分かれています。ここを踏まえたうえで、起動しない場合の切り分け、停止・再起動・削除、ホスト再起動後の自動起動、Docker Compose での一括起動までをコマンド単位で整理します。

まとめ

• 新規に作って動かすなら docker run を使います（イメージからコンテナを作成し、そのまま起動します）。
• すでにあるコンテナを動かすなら docker container start です。docker create で作成だけ済ませ、起動を切り離すこともできます。
• 動いているコンテナの中で作業するなら docker exec -it <名前> bash です。start では中に入れません。
• 起動しないときは、まず docker ps -a でステータスと終了コード、次に docker logs を確認します。頻出するのは「メインプロセスが即終了」「ポート衝突」「デーモン未起動」の3つです。
• ホスト再起動後も自動で立ち上げたいなら --restart unless-stopped を指定します。稼働中のコンテナにも docker update --restart で後付けできます。
• 複数コンテナは docker compose up -d でまとめて起動します。

コンテナを起動する3系統のコマンド

Dockerのコンテナ操作は、イメージ→コンテナ（作成）→実行中（起動）というライフサイクルに沿っています。どの段階からどの段階へ動かしたいかで、使うコマンドが決まります。

docker run：イメージからの作成と起動

docker run は「イメージからコンテナを新規作成し、起動する」までを1コマンドで行います。裏を返すと、同じコマンドを2回叩けばコンテナが2つできます。既存のコンテナを再開する用途で使ってはいけません。

# nginxをバックグラウンド起動し、ホストの8080をコンテナの80へ転送
docker run -d --name web -p 8080:80 nginx:alpine

# 対話シェルで起動し、終了時にコンテナを自動削除
docker run -it --rm ubuntu:24.04 bash

実務で使う主なオプションは次の通りです。

--name を付けない場合、Dockerが eager_hopper のような名前をランダムに割り当てます。運用対象のコンテナには必ず名前を付けてください。名前がなければ以降のコマンドでコンテナIDを毎回調べることになります。

docker create ＋ docker container start：作成と起動の分離

作成だけ先に済ませ、起動は後から行いたい場合は docker create を使います。ポート設定やマウント設定は作成時にしか指定できないため、設定を固めたコンテナを用意しておき、必要なタイミングで start するという分離ができます。

# 作成のみ（ステータスは Created。まだ動いていない）
docker create --name batch -e TZ=Asia/Tokyo alpine:3.22 sleep 3600

# 起動する
docker container start batch

# 起動と同時に標準出力を接続してログを追う（-a）
docker container start -a batch

停止したコンテナを再開するときも同じ docker container start です。docker start は同じ意味の短い書き方で、どちらも同じ動作をします。

docker exec：起動中コンテナへの接続

「コンテナに入る」＝実行中のコンテナの中で追加のプロセスを起動することです。停止中のコンテナには入れないため、まず start してから exec します。

# 実行中のコンテナ web でシェルを開く
docker exec -it web bash

# alpine系などbashが無いイメージでは sh を使う
docker exec -it web sh

# 単発のコマンドだけ実行する
docker exec web nginx -t

混同されがちな docker attach は、コンテナのメインプロセス（PID 1）の入出力に接続するコマンドです。ここで Ctrl+C を押すとメインプロセスごと止まり、コンテナが停止します。コンテナを動かしたまま抜けるにはデタッチキー Ctrl-P Ctrl-Q を使います。そもそも作業目的なら exec を使ってください。

起動しない・すぐ終了するときの切り分け

「起動しない」と「起動したのに即終了する」は原因が違います。推測でコマンドを打ち直す前に、ステータスとログの2点を必ず確認します。

ステータスと終了コードの確認手順

# 停止中も含めて全コンテナを表示
docker ps -a

# 直近のログを表示（起動失敗の理由はほぼここに出る）
docker logs web

# 追跡表示
docker logs -f --tail 50 web

docker ps -a のSTATUS列に出る Exited (0) はエラーではなく、メインプロセスが正常に終わっただけです。コンテナはメインプロセスが終了すると同時に停止する仕様なので、docker run ubuntu のようにフォアグラウンドで動き続けるプロセスを指定しないコンテナは、起動直後に停止します。動かし続けたいなら -it でシェルを与えるか、サーバープロセスをフォアグラウンドで実行するイメージを使います。終了コードが0以外なら異常終了で、値ごとに原因の層が分かれます。

頻出エラー別の対処

Error response from daemon: No such container は、コンテナIDの先頭数文字を打ち間違えている場合と、--rm 付きで起動していて停止と同時に消えている場合が大半です。--rm を付けたコンテナは、停止した時点で docker ps -a にも残りません。

Docker Desktop自体が起動していない場合は、GUIを開かなくても docker desktop start で起動でき、docker desktop status で稼働状態を確認できます（Docker Desktop CLI）。Docker Desktopの前提スペックやインストール手順はDockerとは｜仮想マシンとの違い・必要スペック・インストール手順を解説【2026年版】で整理しています。

停止・再起動・削除の使い分けと猶予時間

停止と再起動の挙動

docker stop はコンテナのメインプロセスにSIGTERMを送り、猶予時間を過ぎるとSIGKILLで強制終了します。既定の猶予時間はLinuxコンテナで10秒、Windowsコンテナで30秒です（docker container stop）。DBなど終了処理に時間がかかるコンテナは、10秒で強制終了されるとデータ整合性を損なう可能性があるため、-t で猶予を延ばします。

# 猶予60秒で停止
docker stop -t 60 db

# 停止して起動し直す（stop + start と同じ）
docker restart web

# 実行中の全コンテナを停止
docker stop $(docker ps -q)

削除と一括クリーンアップ

コンテナは停止しても消えません。ディスクとコンテナ名を占有し続けるため、不要になったら削除します。

# 停止中のコンテナを削除
docker rm batch

# 実行中のコンテナを強制削除（内部で SIGKILL）
docker rm -f web

# 停止中のコンテナをまとめて削除
docker container prune

docker rm -f は猶予なしで落とすため、書き込み中のプロセスを持つコンテナには使わないでください。通常は docker stop → docker rm の順です。

再起動ポリシーによるホスト再起動後の自動起動

再起動ポリシー4種の挙動と選定基準

再起動ポリシーは docker run --restart で指定します。指定できる値は no、on-failure[:回数]、always、unless-stopped の4種類です（Start containers automatically）。

迷ったら unless-stopped を選んでください。always は「メンテナンスのために手で止めたコンテナが、ホスト再起動で勝手に復活する」という運用事故を起こします。再起動が繰り返される際は、100ミリ秒から始まり毎回2倍になる遅延（上限1分）が入り、コンテナが10秒以上動き続けるとこの遅延はリセットされます（docker container run）。クラッシュループでホストが即座に負荷飽和することは、この仕組みで防がれます。

稼働中コンテナへの後付け設定（docker update）

ポリシーを付け忘れて起動したコンテナも、作り直す必要はありません。docker update で停止せずに変更できます。

docker update --restart unless-stopped web

Docker Composeでの複数コンテナ一括起動

アプリとDBのように複数コンテナが必要な構成で、docker run を何本も並べるのは維持できません。compose.yaml に定義して docker compose up で起動します。現行はDocker CLIに統合された docker compose（V2、サブコマンド形式）です。ハイフン付きの docker-compose は旧V1の書き方で、V1は2023年7月にサポートを終了しています。

services:
  web:
    image: nginx:alpine
    ports:
      - "8080:80"
    restart: unless-stopped
    depends_on:
      - db
  db:
    image: postgres:18
    environment:
      POSTGRES_PASSWORD: example
    restart: unless-stopped

# バックグラウンドで一括起動
docker compose up -d

# 特定サービスだけ起動（依存サービスも一緒に起動する）
docker compose up -d web

# 状態確認・停止・破棄
docker compose ps
docker compose stop
docker compose down

depends_on が保証するのは起動順序だけで、依存先が受付可能になるまで待つわけではありません。DBが接続を受け付ける前にアプリが接続しにいって落ちる、という起動失敗はここが原因です。healthcheck と condition: service_healthy を組み合わせるか、アプリ側にリトライを実装します。docker compose down はコンテナとネットワークを破棄するコマンドなので、一時停止したいだけなら stop を使ってください。

docker runを再開コマンド代わりに使う運用が招く事故

入門記事の多くは docker run で話を終えます。しかし実際の障害対応で最も多いのは、停止したコンテナを再開するつもりで docker run を打ち直すケースです。これは再開ではなく新規作成なので、次の3つが同時に起きます。

• コンテナが増殖する：docker ps -a に Exited のコンテナが積み上がり、ディスクを消費する。
• 名前が衝突する：--name を固定していれば The container name is already in use で失敗し、固定していなければ別名のコンテナが増える。
• コンテナ内のデータが消える：前のコンテナの書き込み層は引き継がれない。ボリュームを設定していなければ、DBのデータもログも新しいコンテナには存在しない。

この事故を避ける設計判断は明確です。永続データを持つコンテナは --rm を使わず、名前を固定し、再開は docker container start で行う。逆に、CIやワンショットの検証など「1回動かして捨てる」用途では --rm を積極的に使い、コンテナを残さない。この2つを混ぜないことが要点です。

なお --restart と --rm は併用できず、指定するとエラーになります（docker container run）。自動再起動させたいコンテナは終了時に消えては困る、という当然の帰結です。「自動再起動もしてほしいし終了後は消えてほしい」という要求が出た時点で、そのワークロードはコンテナの使い方として矛盾しています。ジョブとして扱うなら on-failure と、後片付けの docker container prune に分けてください。

また、コンテナ起動が毎回遅い・ビルドが重いという場合は、起動コマンドではなくイメージ側に原因があることがほとんどです。レイヤ構成やキャッシュの効かせ方はDockerfileとは？書き方と主要命令・ベストプラクティスを実例で解説【入門〜実務】で扱っています。

よくある質問

docker run と docker start の違いは何ですか？

docker run はイメージから新しいコンテナを作成して起動します。docker container start はすでに存在する（Created または Exited の）コンテナを起動します。停止したコンテナを再開したいときに docker run を使うと、別のコンテナが新規に作られ、前のコンテナのデータは引き継がれません。

起動中のコンテナに入るにはどうすればよいですか？

docker exec -it <コンテナ名> bash を実行します。bash が含まれないAlpine系イメージでは sh を指定してください。停止中のコンテナには入れないため、先に docker container start で起動します。

Error response from daemon: No such container が出るのはなぜですか？

指定した名前・IDのコンテナが存在しないためです。docker ps -a で実際の名前を確認してください。--rm を付けて起動したコンテナは停止と同時に削除されるため、後から start や exec の対象にはできません。

コンテナ名や起動状態はどう確認しますか？

docker ps で実行中のみ、docker ps -a で停止中を含む全コンテナのNAMES列とSTATUS列を確認できます。docker ps -a --format "{{.Names}} {{.Status}}" を使えば、名前と状態だけを抽出できます。

Dockerデーモンやコンテナをホスト起動時に自動で立ち上げるには？

Linuxではデーモン自体を sudo systemctl enable --now docker で自動起動に設定し、コンテナ側には --restart unless-stopped を付けます。Docker Desktopの場合は設定画面のログイン時起動を有効にするか、docker desktop start で起動します。

関連記事

• Dockerとは｜仮想マシンとの違い・必要スペック・インストール手順を解説【2026年版】
• Dockerの仕組みを原理から理解する｜コンテナ隔離・アーキテクチャ・VMとの違い
• Dockerfileとは？書き方と主要命令・ベストプラクティスを実例で解説【入門〜実務】
• Dev Container（devcontainer）のメリットとは｜Dockerで開発環境を統一する仕組みと設定【2026年版】
• Apple container 1.0とは｜Docker Desktopとの違いと採用判断を解説