Dockerコンテナに入る最も安全な方法は docker exec -it コンテナID /bin/bash です。現場で最も使われるコマンドであり、コンテナのメインプロセスに影響を与えずにシェルを起動できます。
本記事ではdocker attach・docker run -itとの違いも比較表付きで整理しました。
実はdocker attach中にCtrl+Cを押すと、シェルだけでなくコンテナのメインプロセスごと落ち、実行中の処理が消えてしまう事故が現場で頻発します。
その防ぎ方も含めて解説します。
この記事を読むと、以下の3点が3分でわかります。
docker exec/docker attach/docker run -itの違いと、どれを使えば安全か- コンテナに入れない時（No such container / permission denied）の具体的な対処
exitとCtrl+P → Ctrl+Q（detach）を事故なく使い分ける方法
最終更新: 2026年6月｜Docker Engine 29.x / Docker Compose v2.x を前提に記述
Dockerコンテナに入るとは？基本を理解しよう
まず、Dockerコンテナに「入る」という行為が、何を意味するのかを整理します。
Dockerコンテナの仕組みをざっくり解説
Dockerコンテナは、アプリケーションを実行するために必要なライブラリや設定ファイル、OSの一部などをひとまとめにした「独立した実行環境」です。
従来の開発では、自分のPCとサーバーでOSやライブラリのバージョンが違い、「ローカルでは動いたのに本番では動かない」という問題がよく起きていました。
Dockerは、この「環境」ごとパッケージ化して動かす技術です。
Dockerにより、どこでも同じようにアプリケーションを動作させられるようになりました。
コンテナは非常に軽量で、1台のマシン上でたくさんのコンテナを同時に動かせます。
コンテナに「入る」ことの意味とは
コンテナに「入る」とは、その独立した実行環境の中でコマンドを実行できる状態になることです。
具体的には、コンテナ内で「シェル」（bash や sh）を起動して、Nginxの設定ファイル（nginx.conf）が正しく読み込まれているかを確認したり、アクセスログの出力をリアルタイムで監視したりする操作を指します。
Dockerコンテナに入る3つの基本コマンド（exec / attach / run）
Dockerコンテナに入る方法は主に3つのコマンドで、以下の比較表のとおり用途が異なります。
| コマンド | 対象 | 主な用途 | 抜け方 | 初心者おすすめ度 |
|---|---|---|---|---|
docker exec -it | 起動中コンテナ | ログ確認・デバッグ（最頻出） | exit | ★★★ |
docker attach | 起動中コンテナのメインプロセス | フォアグラウンド出力の観察 | Ctrl+P → Ctrl+Q（detach） | ★（事故りやすい） |
docker run -it | 新規作成するコンテナ | イメージ検証・使い捨て環境 | exit（コンテナ停止） | ★★ |
迷ったら docker exec -it <コンテナID> /bin/bash（bashが無ければ /bin/sh）。 以下の3つのh3では、それぞれのコマンドを順に掘り下げます。
筆者環境での「入るまでの時間」実測（Docker Desktop 4.x / Apple Silicon Mac）
同じ ubuntu:24.04 イメージで、3コマンドそれぞれ「コマンド入力からプロンプト表示まで」の体感時間を5回計測した平均値です（あくまで筆者の環境での目安）。
| コマンド | プロンプト表示まで | 備考 |
|---|---|---|
docker exec -it（起動中） | 約 0.3 秒 | 最速。既存コンテナに割り込むだけ |
docker attach（起動中） | 約 0.2 秒 | メインプロセス出力に接続するのみ |
docker run -it（新規） | 約 1.2 秒 | コンテナ作成＋起動込み。イメージpullが必要な場合はさらに数秒〜数十秒 |
デバッグ頻度が多い現場で docker run -it を常用していると、1日あたり数十秒の待ち時間が積み上がります。
既存コンテナで対話シェルが必要な場合は docker exec が第一候補です（ログだけなら docker logs、状態確認なら docker inspect / docker stats の方が先）。
docker exec -it の意味とオプション一覧｜コマンド早見表
「docker exec」「docker exec -it」の意味だけを素早く知りたい方向けに、先に基本構文とオプションをまとめます。
コンテナに入る具体的な手順は次の見出しで解説します。
基本構文は次のとおりです。
docker exec [OPTIONS] CONTAINER COMMAND [ARG...]docker exec -it の -it は「対話的に（interactive）」「ターミナルを割り当てて（tty）」コンテナ内でコマンドを実行する、という意味です。
-i と -t を組み合わせた略記で、シェルを起動して操作したい場合はこの2つがほぼ必須になります。
| オプション | 意味 | よく使う場面 |
|---|---|---|
-i, --interactive | 標準入力を開いたままにする | キーボード入力をコンテナに送りたい時 |
-t, --tty | 擬似ターミナルを割り当てる | プロンプト表示など対話操作全般 |
-d, --detach | バックグラウンドで実行 | 結果を待たずに処理を投げたい時 |
-u, --user | 実行ユーザーを指定 | root以外のユーザーで検証したい時 |
-w, --workdir | 実行ディレクトリを指定 | 特定フォルダ配下でコマンドを実行したい時 |
-e, --env | 環境変数を渡す | 一時的に環境変数を変えて検証したい時 |
また、docker exec は「コンテナに入る（シェルを起動する）」だけでなく、コンテナに入らずに1コマンドだけ実行して結果を受け取る使い方もできます。
運用スクリプトなどではこちらの方が頻出です。
# コンテナに入らずファイル一覧だけ取得する例
docker exec my-container ls /app
# コンテナに入らずプロセス一覧を確認する例
docker exec my-container ps aux対話的にシェルへ入りたい場合は、次の見出しで解説する docker exec -it の具体的な使い方に進んでください。
docker exec でコンテナ内に入る方法
これが、起動中のコンテナに入るための最も一般的で安全な方法です。
docker exec コマンドは、すでに起動しているコンテナに対して、新しいコマンドを実行します。
コンテナ内で bash シェルを起動して対話的に操作するには、以下のコマンドを実行します。
docker exec -it [コンテナID または コンテナ名] /bin/bash- [コンテナID または コンテナ名]操作したいコンテナを指定します。docker ps コマンドで確認できます。
- -itこれは -i と -t の2つのオプションをまとめたものです。
-i(--interactive): 標準入力（キーボード入力）をコンテナに送れるようにします。-t(--tty): 仮想ターミナル（TTY）を割り当てます。これにより、コマンドプロンプトが正しく表示され、対話的な操作が可能になります。
- /bin/bashコンテナ内で実行するコマンドです。ここでは bash シェルを指定しています。
docker exec -it [コンテナID] /bin/bash を実行すると、コンテナ内のシェルが起動し、プロンプト（例: root@コンテナID:/#）が表示されます。
あとは通常のLinuxコマンド（ls や cd など）が使えます。
docker attach を使う場合の注意点
docker attach は、コンテナが起動時に実行したメインプロセス（標準入出力）に接続するためのコマンドです。
結論から言うと、初心者のうちは docker attach よりも docker exec を使うことを強く推奨します。
docker attach には大きな注意点があります。
具体的には、attach で接続中に Ctrl+C を押すと、SIGINT がメインプロセス（PID 1）に転送されます。
PID 1 が SIGINT をハンドリングせずに終了するタイプのプロセス（nginx、典型的なWebサーバー等）だと、そのままコンテナ停止につながります（独自にシグナルをトラップしているプロセスなら必ずしも終了しません）。
--sig-proxy=false を付ければシグナル転送を無効化できます。
メインプロセスが終了すると、Dockerはそのコンテナの役目が終わったと判断し、コンテナ自体が停止してしまいます。
デバッグのつもりが、サービスを停止させてしまう事故につながりかねません。
docker exec はコンテナ内で「新しいプロセス（シェル）」を起動するのに対し、docker attach は「既存のメインプロセス」に接続する、という根本的な違いがあります。
実際に docker attach でコンテナを止めてしまった時のログ
筆者が実際に踏んだ失敗例です。動作中の nginx コンテナに attach して、抜けようと Ctrl+C を押した結果、コンテナごと停止しました。
$ docker attach nginx-web
# 画面がプロンプトなしで止まる → 慌てて Ctrl+C
^C
# ホストに戻った後...
$ docker ps
CONTAINER ID IMAGE STATUS
# ← nginx-web が消えている
$ docker ps -a
CONTAINER ID IMAGE STATUS
xxxxxxxxxxxx nginx Exited (0) 5 seconds agoメインプロセスに送った SIGINT が nginx 本体を終了させた瞬間です。
以降は、ログ追跡なら docker logs -f <name>、シェルが欲しいなら docker exec -it <name> /bin/bash のどちらかに統一しています。
docker run -it で新しく入るパターン
docker run は、イメージから新しいコンテナを作成して起動するコマンドです。
docker run に -it オプションを付けてシェルを指定すると、コンテナの作成・起動と同時に「中に入る」ことができます。
実行例:
ubuntu イメージを使い、起動と同時に bash シェルで入る場合。
docker run -it ubuntu /bin/bashdocker run -it は、主に以下の2つのケースで使われます。
- OSイメージ（ubuntuやAlpineなど）を使って、一時的なデバッグ環境や検証環境として利用したい場合。
- 開発中のアプリケーションを起動するのではなく、イメージの中身を調査したい場合。
docker exec が「すでに動いているコンテナ」に入るのに対し、docker run -it は「これから新しく作るコンテナ」に入る、という違いがあります。
Docker Composeでコンテナに入る方法（docker compose exec）
実際の開発では docker-compose.yml で複数コンテナを束ねて動かすことが多く、このときコンテナIDではなくサービス名で入れるのが docker-compose exec です。
例えば web と db の2サービスがある場合:
# Compose v1（ハイフンあり）
docker-compose exec web /bin/bash
# Compose v2（2026年現在の推奨）
docker compose exec web bashdocker exec -it <コンテナID> bash と違い、毎回 docker ps でコンテナIDを調べる手間が不要なのが最大のメリットです。
Compose環境で開発している場合は、ほぼこのコマンドで事足ります。
docker exec で bash / sh どちらを指定すべきか
docker exec や docker run で指定するコマンドとして、/bin/bash や /bin/sh がよく使われます。
- /bin/bash (bash)多くのLinuxディストリビューションで標準となっている高機能なシェルです。コマンド履歴やタブ補完などが強力です。
- /bin/sh (sh)bash よりも機能がシンプルな、古くからあるシェルです。
ここで重要なのは、コンテナイメージによっては bash がインストールされていない場合があることです。
特に、Alpine Linux をベースにした軽量イメージでは、容量を節約するために bash が入っておらず、/bin/sh しか使えないことがよくあります。
docker exec -it [コンテナID] /bin/bash を実行して OCI runtime exec failed: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown といったエラーが出た場合は、bash が存在しない可能性が高いです。
その場合は、代わりに /bin/sh を試してみてください。
docker exec -it [コンテナID] /bin/sh現場で遭遇した「bashが使えないイメージ」リスト
筆者が実際に /bin/bash: no such file or directory を踏んだ代表的なイメージです。
/bin/sh または /bin/ash に切り替えれば入れます。
alpine系全般（node:alpine,python:alpine等）→/bin/shで入るdistroless系（gcr.io/distroless/*）→ シェル自体が無い。debugタグなら--entrypoint=/busybox/shでENTRYPOINTを上書きして入るscratchベース → シェル無し。docker cpで取り出すかdocker commit経由busybox→/bin/sh（bashは入っていない）
エラーが出たら「そのイメージはそもそも bash を同梱していない可能性」をまず疑うのが時短のコツです。
コンテナに入った後にできること｜操作例まとめ
無事にコンテナ内に入れたら、次に内部でどのような操作ができるのか、いくつかの例を紹介します。
ファイルの確認・編集方法
コンテナに入ると、Linuxコマンドが使えます。
- ファイルの確認ls -la でファイルやディレクトリの一覧を表示したり、cat /path/to/file でファイルの中身を表示したりできます。
- ファイルの編集vi や nano などのテキストエディタでファイルを編集することも可能です。
ただし、注意点があります。Alpine などの軽量イメージには、テキストエディタがインストールされていないことがほとんどです。
その場合、apt-get update && apt-get install -y --no-install-recommends vim（Debian/Ubuntu系）や apk add --no-cache vim（Alpine系）のように、コンテナ内でパッケージマネージャを使って一時的にインストールします。
※Dockerfileに書く場合は、Debian/Ubuntu系では --no-install-recommends 付与＋同一RUN内での rm -rf /var/lib/apt/lists/*、Alpine系では apk add --no-cache がイメージ肥大化を防ぐ公式推奨パターンです（apt-get には --no-cache オプションは存在しないので注意）。
しかし、本来コンテナは「イミュータブル（不変）」であることが推奨されます。
コンテナ内で直接ファイルを編集するのは、あくまで一時的なデバッグに留めるべきです。
恒久的な変更は、Dockerfileや設定ファイルを修正し、イメージを再ビルドする方法（後述）が望ましいです。
ログや設定ファイルのチェック
アプリケーションが期待通りに動かない時、まずログや設定ファイルを確認します。
- ホストからログを見る（推奨）コンテナ内に入らなくても、docker logs [コンテナID] コマンドでコンテナの標準出力を確認するのが基本です。
- コンテナ内でログを見るアプリケーションがファイルにログを出力している場合（例: /var/log/app.log）、tail -f /var/log/app.log のように tail コマンドでリアルタイムにログを監視できます。
- 設定ファイルの確認cat /etc/nginx/nginx.conf のように、設定ファイルが意図した通りに配置され、内容が正しいかを確認します。
アプリケーションの動作確認方法
コンテナ内でアプリケーションが正しく動作しているかを確認する基本的な方法です。
- プロセス確認ps aux コマンドを実行し、目的のプロセス（例: nginx や python app.py）が起動しているかを確認します。
- ネットワーク確認Webサーバーなどの場合、curl localhost:80 や curl 127.0.0.1:3000 のように、コンテナ内部から localhost (自分自身) に対してリクエストを送り、応答があるかを確認できます。（curl もインストールされていない場合は、apt install curl などで追加します）
Dockerコンテナから抜ける方法
コンテナ内での作業が終わったら、安全にコンテナから抜ける（セッションを終了する）必要があります。
安全にコンテナから抜けるコマンド
docker exec でコンテナに入った場合、exit コマンドを実行するのが最も安全で確実な方法です。
root@コンテナID:/# exitexit を実行すると、docker exec で起動したシェルプロセスだけが終了し、ホストOSのプロンプトに戻ります。
この操作でコンテナ本体（メインプロセス）が停止することはありません。
キーボードショートカットの Ctrl + D も、exit と同じ役割を果たします。
detachとexitの違いを理解する
docker exec で入った場合は exit を使うのが基本です。
一方で、docker attach で接続してしまった場合に、コンテナを停止させずに抜ける（切り離す）操作を「デタッチ (detach)」と呼びます。
デタッチの標準的なキー操作は Ctrl + P の後に Ctrl + Q を順番に押すことです。
exit や Ctrl+C はプロセスを「終了」させてしまいますが、Ctrl+P -> Ctrl+Q はプロセスを「動かしたまま切り離す」操作です。
attach を使ってしまった場合は、慌てずにこのデタッチ操作を思い出してください。
Dockerコンテナに入れない時の対処法｜エラー別の解決手順
docker exec を実行しても、エラーが出てコンテナに入れない場合があります。よくある原因と対処法をまとめます。
コンテナが停止している場合の確認方法
docker exec は、起動中 (Running) のコンテナに対してのみ有効なコマンドです。
「Error: No such container」や「Error response from daemon: Container ... is not running」といったエラーが出る場合、コンテナが停止している可能性があります。
対処法:
docker ps コマンドは、デフォルトでは起動中のコンテナしか表示しません。
docker ps -a（-a は --all）で、停止中のコンテナも含めて一覧表示します。
Docker 1.13（2017年1月）以降は docker container ls -a という管理コマンド形式（management commands）も使え、近年はこちらが推奨されています。
docker ps -aSTATUS カラムを見て、Exited と表示されていたら、そのコンテナは停止しています。
docker start [コンテナID] でコンテナを再起動してから、もう一度 docker exec を試してください。
停止中のコンテナに入る3つの方法
停止中のコンテナには docker exec が使えません。入るには以下の3通りがあります。
- 再起動してから exec で入る（推奨）:
docker start [コンテナID] && docker exec -it [コンテナID] /bin/bash（起動直後でメインプロセスの初期化が間に合わず "container is not running" になる場合は、短いsleepを挟むかヘルスチェック後に実行） - docker start -ai で1コマンドアタッチ:
docker start -ai [コンテナID]。起動と同時に標準入出力へアタッチできて手早いが、execと違いbashを新規に開くのではなくコンテナのメインプロセス（ENTRYPOINT）にそのまま接続する点に注意。メインプロセスがシェルでない場合はログ垂れ流しになるだけで操作できず、抜けるとコンテナ自体が停止してしまう（Ctrl+P → Ctrl+Qでデタッチすれば停止は回避できる） - コンテナ内のファイルだけ見たい場合: 起動せずに
docker cp [コンテナID]:/path/to/file ./でホストにコピーするのが第一候補。Docker Desktop 4.33以降ならdocker debug、Kubernetes環境ならkubectl debugも有力。docker commitで一時イメージ化する方法もあるが、イメージが履歴に残り汚染しやすいので最終手段
「停止中でも中を見たい」ケースはデバッグで頻出します。
docker commit を使った場合は、使用後に docker rmi でイメージを消しておきましょう（履歴の汚染を防ぐため）。
権限エラーが出るときの対処法
docker exec を実行した際に「permission denied」といった権限エラーが出ることがあります。
permission denied の主な原因は以下のいずれかです。一般ユーザーで動いているせい、と決めつける前に切り分けましょう。
- Docker daemon socket の権限（
Got permission denied while trying to connect to the Docker daemon socket）→ ホスト側でdockerグループにユーザーを追加する - 実行ファイル自体に execute 権限がない（
/bin/bash: permission denied）→chmod +xやイメージ側の権限を見直す - SELinux / AppArmor の制約（特にRHEL系・Ubuntu系の本番環境）→ ラベルやプロファイルを確認
- read-only ファイルシステムやマウントしたボリュームのownership→
--read-onlyや bind mount の権限を確認 - 非 root ユーザーで動いていてシェル実行権限がない（次節の
-u rootで回避できることが多い）
エラーメッセージの全文を確認すれば、どの原因かはおおむね判別できます。
筆者はまず docker exec ... 2>&1 でエラー出力をリダイレクトし、Got permission denied while trying to connect（Docker daemon側）なのか /bin/bash: permission denied（コンテナ内側）なのかを切り分けるようにしています。
この1ステップで対処の方向が即決まるため、原因不明のまま試行錯誤する時間を大幅に減らせます。
root権限で入るためのオプション
コンテナが一般ユーザーで起動している場合でも、root 権限で操作したい場合があります。
docker exec には -u (--user) オプションがあり、実行するユーザーを指定できます。
docker exec -it -u 0 [コンテナID] /bin/bashまたは
docker exec -it -u root [コンテナID] /bin/bash-u 0 または -u root と指定することで、コンテナ内に root ユーザーとして入り、デバッグ作業を行えます。
（ただし、コンテナイメージが root での実行を許可している必要があります）
Dockerコンテナ操作を効率化するTips
最後に、Docker操作の効率を上げるためのいくつかのヒントを紹介します。
よく使うコマンドをエイリアス化する
docker exec -it ... や docker ps -a はよく使うコマンドですが、毎回入力するのは面倒です。
ホストOS（LinuxやMac）のシェルの設定ファイル（.bashrc や .zshrc など）に、エイリアス（別名）を登録しておくと便利です。
設定例:
alias dps='docker ps'
alias dpsa='docker ps -a'
# 'dex'と打つだけで 'docker exec -it' になる
alias dex='docker exec -it'
# 直近100行のログをリアルタイム表示
alias dlog='docker logs -f --tail 100'
# 全コンテナ一括停止
alias dstop='docker stop $(docker ps -q)'このように設定しておけば、次からは dex [コンテナID] /bin/bash と入力するだけで済みます。
dlog と dstop は筆者が日常的に使っているエイリアスで、特に dlog はコンテナに入らずにログを確認できるため、docker exec の出番を減らせます。
Docker Composeで複数コンテナを管理する
実際の開発では、Webサーバー、アプリケーション、データベースなど、複数のコンテナを連携させて動かすことが一般的です。
Docker Compose は、複数のコンテナ構成を docker-compose.yml という設定ファイルで一元管理できるツールです。
Docker Compose を使うと、コンテナIDの代わりに docker-compose.yml で定義した「サービス名」でコンテナを指定できます。
# docker-compose exec [サービス名] [実行コマンド]
docker-compose exec web /bin/bash
# Compose v2（2026年現在の推奨・ハイフンなし）
docker compose exec web bashコンテナIDをいちいち docker ps で調べる手間が省けるため、開発効率が格段に上がります。
実運用でおすすめのコンテナ操作方法
コンテナに「入る」方法を解説してきましたが、実運用のコンテナに docker exec で入ってファイルを直接編集する行為は、原則として避けるべきです。
これは、Dockerの重要な考え方である「Immutable Infrastructure (イミュータブル・インフラストラクチャ / 不変なインフラ)」に反するためです。
コンテナは、一度作成したら変更しないことが理想です。
もし設定変更やコードの修正が必要になったら、docker exec で中をいじらず、次の手順で行います。
正しい手順:
- Dockerfile や
docker-compose.yml、アプリケーションのコードなど、大元の設定ファイルを修正します。 docker buildでイメージを再ビルド（再作成）します。- 古いコンテナを停止・破棄し、新しいイメージから新しいコンテナを起動（デプロイ）します。
Dockerfile修正→再ビルド→デプロイの流れを徹底することで、「誰がいつ何を編集したか分からない」という状態を防ぎ、環境の再現性を保てます。
docker exec でコンテナに入るのは、あくまで一時的なデバッグや状態確認（読み取り専用）のため、と割り切ることが重要です。
とはいえ、開発初期のプロトタイプ段階では exec でコンテナに入って直接設定を試行錯誤し、動くことを確認してからDockerfileに反映するサイクルが最も効率的です。
「本番はイミュータブル、開発中は exec で素早く検証」という使い分けが現実的な落としどころです。
よくある質問（FAQ）
docker exec と docker attach はどちらを使うべき？
docker exec を使ってください。docker exec はコンテナ内で新しいプロセスを起動するため、メインプロセスに影響を与えません。一方、docker attach はメインプロセスの標準入出力に直接接続するため、Ctrl+C でコンテナごと停止してしまうリスクがあります。
bashが入っていないコンテナに入るには？
/bin/sh を指定してください。Alpine Linux ベースのイメージなど、軽量イメージには bash が同梱されていません。docker exec -it コンテナID /bin/sh で入れます。distroless イメージの場合は debug タグを使うか、docker cp でファイルを取り出す方法があります。
停止中のコンテナに入れる？
docker exec は起動中のコンテナにしか使えません。docker start コンテナID で再起動してから docker exec するのが基本です。コンテナ内のファイルだけ確認したい場合は、起動せずに docker cp コンテナID:/path/to/file ./ でホストにコピーする方法もあります。
Docker Composeのコンテナに入るには？
docker compose exec サービス名 bash（Compose v2）で入れます。コンテナIDを調べる必要がなく、docker-compose.yml で定義したサービス名をそのまま使えるのが利点です。
コンテナに入ったらCtrl+Cで止まってしまった
docker attach で接続した場合に起こる事故です。Ctrl+C が SIGINT としてメインプロセスに送られ、コンテナが停止します。
docker start コンテナID で再起動できます。
今後は docker exec -it を使うか、docker attach --sig-proxy=false でシグナル転送を無効化してください。
まとめ：Dockerコンテナに入る操作をマスターしよう
Dockerコンテナに入る方法について、基本となる3つのコマンドと、関連する操作や注意点を解説しました。
docker exec は、開発やデバッグの現場でよく使うコマンドです。
まずは docker exec -it コンテナID /bin/bash を実行して、コンテナの中を覗いてみてください。
