先に要点
docker runは、イメージから コンテナ を作って起動するコマンドです。「作る」と「起動する」を同時にやる点が、docker startやdocker execと決定的に違います。- 最初によく使うのは
-p-d--rm-it-vあたりです。 -pはポート公開、-dはバックグラウンド実行、--rmは終了後に自動削除、-itは対話シェル、-vはボリュームや bind mount に使います。- つまずきやすいのは
-pの向きを逆にしたときと、run/exec/startの取り違えです。どちらも本文で「現象→原因→確認→回避」まで整理します。
Docker を触り始めると、まず出てくるのが docker run です。
ただ、オプションがいきなり多く見えて、「結局どれを覚えればいいの？」で止まりやすいです。
この記事では、2026年6月時点で Docker Docs の CLI reference と quickstart 系の公開情報を確認しながら、docker run とは何か、最初にどのオプションから押さえるとよいかを初心者向けに整理します。あわせて、初心者が必ずと言っていいほど踏む「-p の向きの逆転」と「run と exec と start の取り違え」を、実際に出るエラーメッセージ付きで扱います。
Docker の全体像から先に見たいなら、Dockerとは？コンテナで何がうれしい？初心者向けに仕組み・メリット・使いどころを解説 から読むと流れがつかみやすいです。
docker runとは何か
docker run は、イメージから新しいコンテナを作って起動するコマンドです。
Docker Docs でも「Create and run a new container from an image」と説明されています。
ここで大事なのは、これが「既存のコンテナをただ起動するコマンド」ではないことです。
イメージをもとに、新しいコンテナを作って、そのまま動かすところまでをまとめてやります。内部的には docker create(コンテナを作る)と docker start(作ったコンテナを起動する)を続けて実行しているのに近い、と捉えると後で start との違いがすっきりします。
たとえば、
docker run nginx
なら、nginx イメージを使ってコンテナを新しく作り、起動します。
ローカルにイメージが無ければ、先に docker pull 相当の取得もしてくれます。実行すると、以下のように取得ログのあとログが流れ始めます。
Unable to find image 'nginx:latest' locally
latest: Pulling from library/nginx
...
/docker-entrypoint.sh: Configuration complete; ready for start up
まず押さえたい基本の形
基本形はこうです。
docker run [OPTIONS] IMAGE [COMMAND] [ARG...]
意味としては、
OPTIONS: 動かし方の指定(ポート、削除、対話など)IMAGE: 何のイメージから作るかCOMMAND: 起動時に実行するコマンドを上書きしたいときに使う
です。
最初は OPTIONS + IMAGE だけ見られればだいぶ十分です。
最初によく使うオプション
1. -p: ポートを公開する
Web サーバー系を試すときにかなりよく使います。
docker run -p 8080:80 nginx
これは、ホスト側の 8080 番を、コンテナ側の 80 番へつなぐ指定です。
Docker Docs でも publish オプションとして -p が説明されています。書式は ホスト:コンテナ の順で固定です。コロンの左がブラウザや curl から叩く番号、右が「コンテナの中で実際にプロセスが Listen している番号」だと覚えると、後述の事故を避けられます。
初心者向けには、「ブラウザからアクセスできるようにするための窓口を開ける」と考えると分かりやすいです。
2. -d: バックグラウンドで動かす
docker run -d nginx
-d は detached mode です。
端末を占有せず、バックグラウンドでコンテナを動かしたいときに使います。実行するとコンテナ ID が1行返ってきて、すぐにプロンプトへ戻ります。
3f9a1c0b2e4d5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0b
サーバー系コンテナではかなりよく使います。
3. --rm: 終了後に自動削除する
docker run --rm hello-world
一時的に試すだけのコンテナではかなり便利です。
終わったあとに残骸(停止済みコンテナ)を残しにくいので、検証用途ではよく使います。--rm を付けないと docker ps -a に Exited 状態のコンテナが溜まっていきます。
4. -it: 対話的に入る
docker run -it alpine sh
-i は標準入力を開いたままにする、-t は疑似TTYを割り当てる、という意味です。
ふつうはセットで -it と書かれることが多いです。
初心者向けには、「コンテナの中に入って手で触るときの形」と覚えるとかなり分かりやすいです。
5. -v: ボリュームや bind mount をつなぐ
docker run -v mydata:/var/lib/mysql mysql:8.4
または
docker run -v ./:/app node:22-alpine
-v は、ボリューム や bind mount をつなぐときに使います。
データを残したい、ローカルコードを見せたい、といった場面で重要です。
左側がパス(例 ./ や /home/user/app)ならホストのディレクトリを直接見せます。開発中のコード反映に向きます。
迷ったら
「消えてほしくないデータ」はボリューム、「いま編集しているソース」は bind mount、と用途で分けると混乱しにくいです。
最初に試しやすい例
例1: nginx をブラウザで見る
docker run --rm -p 8080:80 nginx
これなら、使っている間だけ起動して、終わったら消しやすいです。
http://localhost:8080 へアクセスすると、nginx の初期画面が見えます。
例2: Alpine Linux に入ってみる
docker run --rm -it alpine sh
これは「軽い Linux に入って shell を触る」例としてかなり分かりやすいです。
コンテナの中へ入る感覚をつかみやすいです。exit で抜けると、--rm によりコンテナは自動で消えます。
例3: ローカルコードをコンテナから見る
docker run --rm -it -v ./:/app -w /app node:22-alpine sh
この形だと、手元のディレクトリをコンテナ内 /app に見せながら入れます。
開発でよく出る使い方に近いです。
失敗例1: -p の向きを逆にして「つながらない」
ここが初心者の事故ナンバーワンです。-p の左右を取り違えると、エラーは出ずにコンテナは起動するのに、ブラウザだけがつながらない、という分かりにくい状態になります。
nginx はコンテナ内で 80 番を Listen しています。正しくは次です。
docker run --rm -p 8080:80 nginx
これを、よくある勘違いで「自分がアクセスしたいのは 8080 だから右に書こう」として逆にすると、こうなります。
docker run --rm -p 80:8080 nginx
現象: コンテナは普通に起動し、docker ps にも出ます。ところがアクセスすると失敗します。
curl -I http://localhost:80
# curl: (56) Recv failure: Connection reset by peer
あるいは、左に空きポートを書いた場合は接続自体が拒否されます。
curl -I http://localhost:8080
# curl: (7) Failed to connect to localhost port 8080: Connection refused
原因: -p 80:8080 は「ホストの 80 番を、コンテナの 8080 番へ転送する」という意味になります。ところが nginx はコンテナ内で 8080 ではなく 80 を Listen しているので、転送先に誰もいません。ホストの 80 番までは届いても、その先のコンテナ 8080 番が空っぽなので接続がリセットされます。
確認手順:
回避: コロンの右側は必ず「コンテナ内でプロセスが待ち受けている番号」にそろえます。nginx は 80、多くの Node アプリは 3000、Flask の開発サーバーは 5000、というように、イメージごとの Listen ポートに合わせます。左側(ホスト側)だけは好きな空きポートに変えてよい、と整理すると間違えにくいです。
# 正: ホスト 8080 -> コンテナ 80(nginx の待ち受けに一致)
docker run --rm -p 8080:80 nginx
# 正: ホスト側だけ変えるのは OK
docker run --rm -p 9000:80 nginx
なお、左側のホストポートに既に何かが使っていると、向きが正しくても起動時に bind: address already in use ではじかれます。これは「逆転」ではなく「ホスト側ポートの衝突」なので、左の番号を空いているものへ変えれば解決します。
失敗例2: run と exec と start を取り違える
「コンテナの中に入りたい」「もう一度動かしたい」というときに、毎回 docker run を打ってしまうのもよくある事故です。3つのコマンドは目的が別物です。
| コマンド | 何をする | 対象 | 典型的な使い所 |
|---|---|---|---|
docker run |
イメージから新しいコンテナを作って起動 | イメージ | はじめて立てる / 毎回まっさらにしたい |
docker start |
停止済みコンテナを再起動 | 既存コンテナ | 一度作ったコンテナをそのまま使い続ける |
docker exec |
動いているコンテナの中で追加のコマンドを実行 | 起動中コンテナ | 動作中のコンテナにシェルで入って調査 |
つまずき(1): 中に入ろうとして run を使ってしまう
動いているコンテナを調べたいのに docker run image bash を打つと、「いま動いているそのコンテナ」ではなく、まったく別の新しいコンテナが立ち上がります。元のコンテナの中身(書き込んだファイルやプロセス)はそこには見えません。
正しくは、動作中のコンテナに対して exec を使います。
# まず対象コンテナの ID/名前を確認
docker ps
# 動いているコンテナの中へ入る
docker exec -it <container> bash # bash が無いイメージなら sh
つまずき(2): 停止したコンテナに exec しようとする
止まっているコンテナに exec を打つと、次のエラーになります。
docker exec -it myapp sh
# Error response from daemon: Container <id> is not running
原因: exec は「動いているプロセス空間にもう1つコマンドを差し込む」仕組みなので、停止中のコンテナには使えません。
回避: 先に docker start で起動してから exec します。
docker start myapp
docker exec -it myapp sh
つまずき(3): 同じ名前で run し直してしまう
--name myapp を付けて作ったコンテナを停止したあと、また同じ docker run --name myapp ... を打つと、こうはじかれます。
docker run --name myapp nginx
# docker: Error response from daemon: Conflict. The container name "/myapp"
# is already in use by container "<id>". You have to remove (or rename)
# that container to be able to reuse that name.
原因: 名前は再利用できないため、停止済みでも同名が残っていると衝突します。
回避: 再利用したいなら作り直さず docker start myapp、まっさらに作り直したいなら先に docker rm myapp で消してから run します。検証用なら最初から --rm を付けておくと、終了時に消えるのでこの衝突自体が起きにくくなります。
実務でよくある使い方
単体コンテナの動作確認
Redis、nginx、MySQL などを単体で試したいときに便利です。 いきなり Compose を組む前に、まず 1 個だけ試す入口としてかなり使いやすいです。
一時的な検証
「このイメージの中身を軽く見たい」「このコマンドだけ走らせたい」といったときに向いています。
--rm と組み合わせると、かなり気軽です。
コンテナの中へ入って調査する
動作中のコンテナを調べるなら、前述のとおり docker run ではなく docker exec -it を使います。
ただし、再現したい変更は手で直して終わりにせず、後で Dockerfile や設定へ戻す方が実務では大事です。
いつ Docker Compose の方が向いているか
docker run は単体ならかなり便利ですが、複数サービスになるとコマンドが散りやすいです。
アプリ、DB、Redis のように複数コンテナをまとめて扱いたいなら、Docker Compose の方がかなり分かりやすいです。
つまり、
- 単体を試す:
docker run - 構成を残して共有する: Docker Compose
くらいで考えると入りやすいです。
ローカル検証で「nginx の初期画面だけ見たい」「Redis を単体で立ててみたい」なら docker run がかなり手軽です。一方で、Laravel アプリ + MySQL + Redis のように複数を毎回立ち上げるなら、最初から Compose に寄せた方が管理しやすいです。さらに、docker run に長いオプション列(-p や -v や -e をいくつも)を毎回打っている状態は、Compose ファイルへ移すサインです。
初心者がよくハマる点(まとめ)
ポート指定の向き
-p 8080:80 の順番は ホスト:コンテナ です。右側はコンテナ内の Listen ポートに必ず合わせます。逆にすると、起動はするのにつながらない、という気づきにくい状態になります(詳細は失敗例1)。
--rm で消えるものを意識する
一時検証には便利ですが、コンテナ自体は終了後に消えます。 必要なデータを残したいなら、ボリューム や bind mount を分けて考える必要があります。
-it と -d を同時につけた意味
場面によっては併用もありますが、初心者のうちは「中に入って触るなら -it」「裏で動かすなら -d」と分けて考える方が分かりやすいです。
docker runに関するよくある質問
Q. -p と -P の違いは何ですか？
A. -p 8080:80 は明示的に「ホスト:コンテナ」のポートを指定します。-P(大文字)は Dockerfile の EXPOSE で公開されているポートを、すべてランダムなホストポートへマッピングします。どのポートに割り当てられたかは docker ps の PORTS 列で確認します。実務では番号を固定できる -p が定番です。
Q. -p の左右を間違えたかどうかは、どう見分けますか？
A. docker ps の PORTS 列に出る 0.0.0.0:ホスト->コンテナ/tcp の右側(コンテナ側)と、コンテナ内で実際に Listen しているポートが一致しているかを見ます。一致していなければ向きの誤りです。コンテナが起動しているのにブラウザだけ Connection reset / refused になるのが典型的な症状です。
Q. docker run と docker start はどう違いますか？
A. docker run は新しいコンテナを作って起動、docker start は既存の(停止済み)コンテナを再起動します。一度作ったコンテナを再利用したいなら docker start、毎回まっさらに作りたいなら docker run --rm です。同名で run し直すと name conflict になる点にも注意します。
Q. コンテナの中に入って操作するには run と exec のどちらですか？
A. すでに動いているコンテナには docker exec -it <container> bash(無ければ sh)を使います。docker run を使うと別の新しいコンテナが立ち上がってしまい、今動いているコンテナの中身は見えません。停止中なら先に docker start が必要です。
Q. -e で環境変数を渡す場合、機密情報は安全ですか？
A. docker inspect で値が見えてしまうため、シークレットには向きません。本番ではシークレット管理(Docker Secrets、Vault、Secrets Manager など)を使い、-e は開発・テスト用に留めます。
Q. コンテナを停止したのに勝手に再起動するのはなぜですか？
A. --restart unless-stopped や --restart always を設定していると、停止後も自動で起動します。止めたいなら docker stop に加えて docker update --restart=no <container> を組み合わせます。
Q. docker run で起動したコンテナのログはどこで見られますか？
A. docker logs <container> で確認できます。-f でフォロー、--tail 100 で末尾100行だけ、--since 1h で過去1時間、のように絞れます。-d で起動して画面に何も出ないときの第一手として有効です。
Q. メモリや CPU の制限はかけられますか？
A. かけられます。--memory 512m、--cpus="1.5" のように指定します。本番でリソースを食い潰すコンテナを抑止するのに有効です。
まとめ
docker run は、イメージから新しい コンテナ を作って起動するコマンドです。
最初に押さえたいのは -p -d --rm -it -v の5つで、これだけでもかなり実用的です。
事故が多いのは、-p の向き(必ずホスト:コンテナ、右はコンテナの Listen ポート)と、run/exec/start の取り違えです。中に入るなら exec、再起動なら start、作り直すなら run、と用途で分けて覚えると、出てくるエラーメッセージも読み解けるようになります。
単体コンテナの試行や一時検証にはかなり便利ですが、複数サービスをまとめて残したいなら Docker Compose の方が向いています。 続けて読むなら、Docker Composeとは？複数コンテナをまとめて動かす基本を初心者向けに解説 や bind mountとは？ボリュームとの違いと開発で便利な理由を解説 もかなりつながりやすいです。
参考リンク
- Docker Docs: Docker CLI reference
- Docker Docs: docker run
- Docker Docs: docker exec
- Docker Docs: docker start
- Docker Docs: Getting started with containers