起動中のDockerコンテナに入るには docker exec -it コンテナ名 bash を使います。bashがないイメージは sh、Docker Composeなら docker compose exec サービス名 bash です。
メインプロセスに影響せず新しいシェルを起動できるため、現場で最も使われます。一方、docker attach はメインプロセスそのものに接続するので、Ctrl+C でコンテナごと停止することがあります。
この事故の防ぎ方まで含めて、次の3点が3分でわかります。
この記事でわかること
docker exec/docker attach/docker run -itの違いと、どれを使えば安全か- コンテナに入れない時（No such container / permission denied）の具体的な対処
exitとCtrl+P → Ctrl+Q（detach）を事故なく使い分ける方法
PARTS LIST ／目次
Dockerコンテナに入るとは？基本を理解しよう
まず、Dockerコンテナに「入る」という行為が、何を意味するのかを整理します。
Dockerコンテナの仕組みをざっくり解説
Dockerコンテナは、アプリケーションを実行するために必要なライブラリや設定ファイル、OSの一部などをひとまとめにした「独立した実行環境」です。
従来の開発では、自分のPCとサーバーでOSやライブラリのバージョンが違い、「ローカルでは動いたのに本番では動かない」という問題がよく起きていました。
Dockerは、この「環境」ごとパッケージ化して動かす技術です。
Dockerにより、どこでも同じようにアプリケーションを動作させられるようになりました。
コンテナは軽量で、1台のマシン上でたくさんのコンテナを同時に動かせます。
コンテナに「入る」ことの意味とは
コンテナに「入る」とは、その独立した実行環境の中でコマンドを実行できる状態になることです。
私も初めてDockerに触れたときは、「コンテナに入る」と言われてもいまひとつ実感が湧かず、別のサーバーにSSH接続するような感覚で捉えていた。実際には同じホストの中で名前空間を区切って動いているだけで、どこか別の場所に移動しているわけではない、という理解に落ち着くまで少し時間がかかった。
具体的には、コンテナ内で「シェル」（bash や sh）を起動する操作を指します。例えば、Nginxの設定ファイル（nginx.conf）が正しく読み込まれているかを確認したり、アクセスログの出力をリアルタイムで監視したりできます。
docker exec -it実行中のコンテナ内で新しいプロセス（bash など）を起動して入る。exit してもコンテナは動き続けるdocker attachコンテナの元の主プロセスに接続する。終了操作によっては主プロセスごと止まることがあるDockerコンテナに入る3つの基本コマンド
Dockerコンテナに入る方法は主に3つのコマンドで、以下の比較表のとおり用途が異なります。
迷ったら docker exec -it <コンテナID> /bin/bash（bashが無ければ /bin/sh）。 各コマンドの使いどころは、このあと順に解説します。
「入るまでの時間」実測（Docker Desktop / Mac）
同じ ubuntu:24.04 イメージで、3コマンドそれぞれ「コマンド入力からプロンプト表示まで」の体感時間を5回計測した平均値です（あくまで私の環境での目安。絶対値はマシンや Docker の実行環境で数倍変わるので、3つの順番の目安として見てください）。
デバッグ頻度が多い現場で 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つがほぼ必須です。
また、docker exec は「コンテナに入る（シェルを起動する）」だけでなく、コンテナに入らずに1コマンドだけ実行して結果を受け取る使い方もできます。
運用スクリプトなどではこちらの方が頻出です。
# コンテナに入らずファイル一覧だけ取得する例
docker exec my-container ls /app
# コンテナに入らずプロセス一覧を確認する例
docker exec my-container ps aux対話的にシェルへ入りたい場合は、ここまでのオプションを組み合わせて docker exec -it を使います。
docker exec -it bashでシェルに入る方法
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 の使い方と注意点（exec との違い）
docker attach は、コンテナが起動時に実行したメインプロセス（標準入出力）に接続するためのコマンドです。
使い方はコンテナ名かIDを渡すだけです。exec と違って -it は付けず、新しいシェルは起動しません。
docker attach コンテナ名
# Ctrl+Cで止まらないようにシグナル転送を切る
docker attach --sig-proxy=false コンテナ名docker attach よりも docker exec を使うことを強く推奨します。
docker attach には大きな注意点があります。
⚠️ 重大な注意点attach で接続中に Ctrl+C を押すと、SIGINT がメインプロセス（PID 1）に転送されます。nginx のようなWebサーバーはこのシグナルで終了し、コンテナ自体が停止してしまいます。
コンテナ内のPID 1は、シグナルハンドラを登録していないとSIGINTを無視するLinuxの仕様があるため、停止するかどうかはプロセス次第です。nginxのようにハンドラで終了処理を行うプロセスは、そのままコンテナ停止につながります。
--sig-proxy=false を付ければシグナル転送を無効化できます。
メインプロセスが終了するとコンテナも役目を終えて止まるため、デバッグのつもりがサービス停止になりかねません。
docker exec はコンテナ内で「新しいプロセス（シェル）」を起動するのに対し、docker attach は「既存のメインプロセス」に接続する、という根本的な違いがあります。
exitCtrl+C--sig-proxy=false を付ければシグナルは転送されません。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とbash/shの選び方
ここまでの3つの基本コマンドに加え、実際の開発ではComposeで複数コンテナを束ねて動かすことが多いため「サービス名で入る」操作も欠かせません。また、イメージによってはそもそもbashが入っていないこともあるため、docker exec・docker runのどちらでも関わる「bashかshか」の判断基準も合わせて押さえておきます。この2点はexec・attach・runのどれを使う場面でも共通して関わるため、まとめて確認しておくと迷いが減ります。
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を調べる手間が不要なのが最大のメリットです。
bashがないイメージ（Alpineなど）では、サービス名のあとを sh に変えるだけで入れます（docker compose exec web sh）。
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 failed: unable to start container process: exec: "/bin/bash": stat /bin/bash: no such file or directory: unknown といったエラーが出た場合は、bash が存在しない可能性が高いです。
その場合は、代わりに /bin/sh を試してみてください。
docker exec -it [コンテナID] /bin/shbash がないだけでなく、sh 自体が存在しないイメージもあります。2026年10月24日時点、Docker Engine 26.1.5（Docker CLI 27.4.1-rd）で検証しました。gcr.io/distroless/static-debian12 イメージに対して docker run --rm gcr.io/distroless/static-debian12 sh を実行すると、次のエラーでコンテナの起動自体に失敗します。
docker: Error response from daemon: failed to create task for container:
failed to create shim task: OCI runtime create failed: runc create failed:
unable to start container process: exec: "sh": executable file
not found in $PATH: unknown.distroless 系イメージには docker exec で入り込むためのシェルがそもそも同梱されていないため、下の表の対処法（debug タグや docker cp）を最初から使う必要があります。
現場で遭遇した「bashが使えないイメージ」リスト
私が実際に /bin/bash: no such file or directory を踏んだ代表的なイメージです。
多くは /bin/sh または /bin/ash に切り替えれば入れますが、シェル自体がないイメージもあります。
エラーが出たら「そのイメージはそもそも bash を同梱していない可能性」をまず疑うのが時短のコツです。
コンテナに入った後にできること｜操作例まとめ
無事にコンテナ内に入れたら、次に内部でどのような操作ができるのか、いくつかの例を紹介します。
ファイルの確認・編集方法
コンテナに入ると、Linuxコマンドが使えます。
- ファイルの確認：
ls -laでファイルやディレクトリの一覧を表示したり、cat /path/to/fileでファイルの中身を表示したりできます。 - ファイルの編集：
viやnanoなどのテキストエディタでファイルを編集できます。
ただし、注意点があります。Alpine などの軽量イメージには、vim や nano などのエディタが入っていないことがほとんどです（Alpine は BusyBox の vi だけ使えます）。
その場合、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サーバーなどの場合、コンテナ内部から localhost (自分自身) にリクエストを送り、応答を確認します。コマンド例は curl localhost:80 や curl 127.0.0.1:3000 です。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 を順番に押すことです。
ただしこのキー操作が使えるのは、コンテナを -i と -t を付けて起動した場合（docker run -it など）に限られます。docker run -d で起動した nginx のように -it なしのコンテナでは使えず、attach 中の Ctrl+C がメインプロセスへのシグナルになります。
exit や Ctrl+C はプロセスを「終了」させてしまいますが、Ctrl+P -> Ctrl+Q はプロセスを「動かしたまま切り離す」操作です。
attach を使ってしまった場合は、慌てずにこのデタッチ操作を思い出してください。
Dockerコンテナに入れない時はどうする？
docker exec を実行しても、エラーが出てコンテナに入れない場合があります。よくある原因と対処法をまとめます。
コンテナが停止している場合の確認方法
docker exec は、起動中 (Running) のコンテナに対してのみ有効なコマンドです。
停止中のコンテナに docker exec すると「Error response from daemon: container <ID> is not running」と表示されます。一方、「Error response from daemon: No such container: 名前」は意味が異なります。その名前のコンテナが存在しない（名前の打ち間違い・削除済み）という意味であり、停止中という意味ではありません。
対処法:
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。メインプロセスがすぐ終了するコンテナ（シェルだけを起動するイメージを-itなしで動かした場合など）は、start してもすぐ止まります。そのため "container ... is not running" になり、exec できません。その場合は次のdocker start -aiでメインプロセスに接続するか、コンテナが動き続ける設定にしてください。 - 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 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 ユーザーとして入り、デバッグ作業を行えます。
（イメージの USER 指定や --user で一般ユーザーとして起動しているコンテナでも、-u root を付ければ root として入れます）
再起動を繰り返すコンテナに入るには
再起動ポリシー（restart: always 等）を設定したコンテナが起動直後にクラッシュすると、再起動を繰り返す状態になります。この状態では docker exec を実行しても、コンテナが再起動するタイミングと競合して「is not running」エラーになりがちです。
まず docker logs <コンテナ名> でクラッシュ直前のログを確認し、原因を推測します。あわせて docker inspect --format="{{.State.ExitCode}}" <コンテナ名> で直前の終了コードも見ておくと切り分けが早くなります。
中を確認したい場合は、一時的に再起動ポリシーを止めてしまうのが安全です。
docker update --restart=no <コンテナ名>
docker start <コンテナ名>
docker exec -it <コンテナ名> /bin/bash再起動ポリシーを止めておけば、クラッシュ直後に再起動されず、落ち着いてシェルから原因を調査できます。確認が終わったら、元の再起動ポリシーに戻すのを忘れないようにしてください（docker update --restart=always <コンテナ名> 等）。
Dockerコンテナ操作を効率化するTips
ここでは、コマンドのエイリアス化とDocker Composeでの複数コンテナ管理という、日々の操作を少しだけ速くする2つの工夫を紹介します。
よく使うコマンドをエイリアス化する
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-compose（v1）は2023年6月にサポートが終了しているため、新しい環境では docker compose を使ってください。
実運用でおすすめのコンテナ操作方法
コンテナに「入る」方法を解説してきましたが、実運用のコンテナに docker exec で入ってファイルを直接編集する行為は、原則として避けるべきです。
Dockerには「Immutable Infrastructure（イミュータブル・インフラストラクチャ／不変なインフラ）」という考え方があります。コンテナ内を直接編集する行為は、この考え方に反します。
コンテナは、一度作成したら変更しないことが理想です。
もし設定変更やコードの修正が必要になったら、docker exec で中をいじらず、次の手順で行います。
- Dockerfile や
docker-compose.yml、アプリケーションのコードなど、大元の設定ファイルを修正します。 docker buildでイメージを再ビルド（再作成）します。- 古いコンテナを停止・破棄し、新しいイメージから新しいコンテナを起動（デプロイ）します。
Dockerfile修正→再ビルド→デプロイの流れを徹底することで、「誰がいつ何を編集したか分からない」という状態を防ぎ、環境の再現性を保てます。
docker exec でコンテナに入るのは、あくまで一時的なデバッグや状態確認（読み取り専用）に留めましょう。本番環境の変更はDockerfileの修正と再ビルドで行うのが安全です。
とはいえ、開発初期のプロトタイプ段階では話が別です。exec でコンテナに入って直接設定を試行錯誤し、動くことを確認してからDockerfileに反映するサイクルが最も効率的です。
「本番はイミュータブル、開発中は exec で素早く検証」という使い分けが現実的な落としどころです。
よくある質問（FAQ）
Dockerコンテナに入る操作について、読者からよく聞かれる質問をまとめました。exec と attach の選び方、bashが無いイメージへの対処、停止中のコンテナやComposeでの入り方など、ここまでの本文で扱った論点を短くまとめています。細かい手順や根拠は各見出しの本文もあわせて確認してください。
Q1. docker execとdocker attachはどちらを使うべき？
A1. docker exec を使ってください。docker exec はコンテナ内で新しいプロセスを起動するため、メインプロセスに影響を与えません。一方、docker attach はメインプロセスの標準入出力に直接接続するため、Ctrl+C でコンテナごと停止してしまうリスクがあります。
Q2. bashが入っていないコンテナに入るには？
A2. /bin/sh を指定してください。Alpine Linux ベースのイメージなど、軽量イメージには bash が同梱されていません。docker exec -it コンテナID /bin/sh で入れます。distroless イメージの場合は debug タグを使うか、docker cp でファイルを取り出す方法があります。
Q3. 停止中のコンテナに入れる？
A3. docker exec は起動中のコンテナにしか使えません。docker start コンテナID で再起動してから docker exec するのが基本です。コンテナ内のファイルだけ確認したい場合は、起動せずに docker cp コンテナID:/path/to/file ./ でホストにコピーする方法もあります。
Q4. Docker Composeのコンテナに入るには？
A4. docker compose exec サービス名 bash（Compose v2）で入れます。コンテナIDを調べる必要がなく、docker-compose.yml で定義したサービス名をそのまま使えるのが利点です。
Q5. Ctrl+Cでコンテナが止まったときの対処は？
A5. docker attach で接続した場合に起こる事故です。Ctrl+C が SIGINT としてメインプロセスに送られ、コンテナが停止します。
docker start コンテナID で再起動できます。
今後は docker exec -it を使うか、docker attach --sig-proxy=false でシグナル転送を無効化してください。
Q6. docker attachはどんなときに使う？
A6. 起動中のコンテナのメインプロセスが出力するログを、リアルタイムでそのまま観察したいときに使います。ただし、Ctrl+C を押すとメインプロセスにシグナルが届きコンテナごと停止する恐れがあるため、通常のデバッグには docker exec を使い、docker attach は観察用途に限定するのが安全です。
まとめ：Dockerコンテナに入る操作をマスターしよう
Dockerコンテナに入る方法について、基本となる3つのコマンドと、関連する操作や注意点を解説しました。
ポイント
- 基本は
docker exec -it: 起動中のコンテナに安全に入るための定番コマンドです。 docker attachは注意: メインプロセスに接続するため、コンテナを意図せず停止させるリスクがあります。docker run -itは新規作成時: 新しくコンテナを作ってすぐに入る場合に使います。- 安全な離脱は
exit:execで入った場合はexitかCtrl+Dで抜けます。 - 実運用での編集はNG:
execでのデバッグはOKですが、本番環境のファイル変更はDockerfileの修正と再デプロイで行いましょう。 - 再起動を繰り返すコンテナ: 一時的に
docker update --restart=noで再起動ポリシーを止めてからexecすると、落ち着いて調査できます。
docker exec は、開発やデバッグの現場でよく使うコマンドです。
まずは docker exec -it コンテナID /bin/bash を実行して、コンテナの中を覗いてみてください。
| REV. | DATE | 内容 |
|---|---|---|
| 8 | 2026-10-24 | Docker実機検証で記述を裏付け、最終更新月を更新し装飾を追加 |
| 7 | 2026-10-15 | 図解を描き直し（図面のデザインにそろえた） |
| 6 | 2026-10-14 | 一人称と言い回しの表記をそろえた。雰囲気だけの挿絵を外した |
| 5 | 2026-10-04 | 2026年10月時点の情報で全体を見直し |
| … ほか3回の改訂 | ||
| 1 | 2025-11-08 | 初版 |