Dockerコンテナに入る（exec）コマンドの使い方｜bashがないとき・入れないときの対処

動いているDockerコンテナの中に入るには docker exec -it コンテナ名 bash を使います。bashが入っていない軽量なイメージでは sh に置き換え、Composeで管理しているなら docker compose exec サービス名 bash と書けます。この記事では、exec の基本とオプション、ユーザーや作業ディレクトリの指定、入れないときのエラー別の対処、WordPressのコンテナでの使い方、中に入って作業するときの注意点を説明します。

コマンドの出力やエラーの文面は、Docker Engineのバージョンによって少しずつ異なります。ここでは現行の安定版（2026年10月現在）で見られる形で書いています。

基本の使い方

# 動いているコンテナの名前を確認
docker ps

# コンテナに入る（シェルを起動する）
docker exec -it web bash

# 抜けるとき
exit

-i は標準入力を開いたままにするオプション、-t は端末（TTY）を割り当てるオプションで、対話的にシェルを使うときは2つをまとめて -it と書きます。どちらかが欠けると、プロンプトが出ない、矢印キーやCtrl+Cが効かない、といった状態になります。

exec は、既に動いているコンテナの中で 新しいプロセスを1つ追加で起動する コマンドです。exit で抜けても終わるのはそのシェルだけで、コンテナ自体は動き続けます。似たコマンドとの違いは次のとおりです。

• docker run：イメージから新しいコンテナを作って起動します。中に入るのではなく、別のコンテナができます。
• docker attach：コンテナのメインプロセス（PID 1）の入出力につなぎます。この状態でCtrl+Cを押すとメインプロセスが止まり、コンテナが終了することがあるため、調査目的なら exec を使います。

入らずにコマンドだけ実行する

シェルに入らず、1つのコマンドを実行して結果だけ受け取ることもできます。この場合は -it は不要です。

docker exec web ls -la /etc/nginx/conf.d
docker exec web nginx -t
docker exec web cat /etc/os-release

設定ファイルの構文チェックや、ファイルの有無の確認など、ちょっとした調査はこの形が手早くて記録にも残しやすいです。パイプやリダイレクトをコンテナ内で解釈させたい場合は、sh -c で包みます。

docker exec web sh -c 'ls /var/log/nginx | wc -l'

sh -c で包まずに docker exec web ls /var/log/nginx | wc -l と書くと、| wc -l はホスト側で実行されます。

よく使うオプション

# ユーザーを指定する（root、または名前・UID）
docker exec -it -u root web bash
docker exec -it -u www-data wordpress bash

# 作業ディレクトリを指定する
docker exec -it -w /var/www/html wordpress bash

# 環境変数を追加して実行する
docker exec -e APP_DEBUG=1 web printenv APP_DEBUG

-u を省略すると、イメージの USER で指定されたユーザーで入ります。非rootユーザーで動くイメージでパッケージを入れたいときなどに -u root を使えますが、コンテナの中でrootとして作業すると、作ったファイルの所有者がrootになり、アプリから書き込めなくなる原因になります。ファイルを作る作業は、アプリと同じユーザー（WordPress公式イメージなら www-data）で行うと、後で権限の問題が起きにくくなります。

入れないときのエラー別の対処

bashが見つからない

OCI runtime exec failed: exec failed: unable to start container process: exec: "bash": executable file not found in $PATH

イメージにbashが入っていません。AlpineベースのイメージやBusyBox系のイメージでよくあります。sh で入り直します。

docker exec -it web sh

sh もない場合は、distrolessや scratch を土台にした、シェルを含まないイメージです。この場合は、同じプロセス空間とネットワークを共有する調査用のコンテナを横に起動する方法があります。

docker run --rm -it --pid=container:web --network=container:web busybox sh

この中で ps を実行すると対象コンテナのプロセスが見え、wget などでコンテナ内のポートに接続して確認できます。対象のファイルシステムは /proc/<PID>/root から参照できる場合がありますが、権限によっては見えません。Docker Desktopには調査用のシェルを付ける機能もありますが、提供範囲は契約やバージョンで異なるため、公式ドキュメントで確認してください。

コンテナが動いていない

Error response from daemon: container ... is not running

exec は動いているコンテナにしか使えません。docker ps -a で状態を確認し、すぐ終了してしまうコンテナなら、まず docker logs コンテナ名 で終了の理由を見ます。中身を調べたいだけなら、同じイメージからエントリーポイントを差し替えて起動する方法が使えます。

docker run --rm -it --entrypoint sh イメージ名

この方法は元のコンテナとは別の新しいコンテナなので、元のコンテナで書き込まれたファイル（ボリューム以外）は見えない点に注意します。

the input device is not a TTY

CIのジョブやcron、パイプの途中など、端末がない場所で -t を付けると出ます。-t を外し、標準入力を渡す必要があれば -i だけを付けます。docker compose exec は既定で端末を割り当てるため、同じ状況では -T を付けて割り当てを止めます。

Windowsのコマンド環境でパスがおかしくなる

Git Bashから docker exec -it web /bin/bash を実行すると、/bin/bash がWindowsのパスに変換されてしまい、見つからないというエラーになることがあります。bash とパスを付けずに書くか、//bin/bash と書く、または MSYS_NO_PATHCONV=1 を前に付けると回避できます。PowerShellやWSLのターミナルではこの問題は起きません。

Docker Composeでの使い方

Composeでは、コンテナ名ではなく compose.yaml に書いたサービス名で指定します。

docker compose exec wordpress bash
docker compose exec -u www-data wordpress bash
docker compose exec -T db sh -c 'exec mysqldump -uroot -p"$MYSQL_ROOT_PASSWORD" wordpress' > backup.sql

3行目はデータベースのダンプをホストのファイルに保存する例です。出力をリダイレクトするので -T で端末の割り当てを止めています。パスワードは $MYSQL_ROOT_PASSWORD をシングルクォートの中に書くことで、ホストではなくコンテナ内の環境変数から読み込まれます。コマンドの引数にパスワードを直接書くと、シェルの履歴に残るので避けます。MariaDBの新しいイメージでは、クライアントのコマンド名が mariadb や mariadb-dump になっている場合があるため、mysqldump が見つからないときは置き換えてください。

WordPressのコンテナでよく行う作業

# PHPのバージョンと読み込まれている拡張を確認
docker compose exec wordpress php -v
docker compose exec wordpress php -m

# 設定値の確認
docker compose exec wordpress php -i | grep -E "upload_max_filesize|memory_limit"

# エラーログの末尾を見る（WP_DEBUG_LOGを有効にしている場合）
docker compose exec wordpress tail -n 50 /var/www/html/wp-content/debug.log

WP-CLIを使いたい場合、公式の wordpress イメージ（Apache版など）にはWP-CLIが入っていません。WP-CLI入りの公式イメージ（wordpress:cli 系のタグ）を別のサービスとして用意し、同じボリュームとデータベースにつないで docker compose run --rm で実行するのが一般的な構成です。プラグインの一括更新や検索置換など、データベースを書き換える操作の前にはバックアップを取ってください。

中で作業するときの注意点

exec で入ってファイルを編集したりパッケージを入れたりした変更は、そのコンテナの中にしか残りません。docker compose up -d などでコンテナが作り直されると、ボリュームに置いたもの以外は消えます。調査のための一時的な変更にとどめ、残したい変更はDockerfileやComposeの設定、ボリュームに反映させます。

本番のコンテナに入るときは、何をしたかを残しておくと後で原因を追いやすくなります。また、コンテナの中から設定ファイルを直接書き換えて直した場合、次のデプロイで元に戻って同じ障害が再発します。応急処置をしたら、同じ修正をイメージや設定ファイルにも入れておきます。

まとめ

• コンテナに入るのは docker exec -it コンテナ名 bash、bashがなければ sh。Composeでは docker compose exec サービス名 bash です。
• 1つのコマンドを実行するだけなら -it は不要です。パイプをコンテナ内で使うときは sh -c で包みます。
• -u でユーザー、-w で作業ディレクトリを指定できます。ファイルを作る作業はアプリと同じユーザーで行います。
• シェルのないイメージは調査用コンテナを --pid と --network で横付けし、止まっているコンテナは docker logs と --entrypoint sh で調べます。
• 中で加えた変更はコンテナを作り直すと消えます。残す変更はDockerfileや設定ファイルに反映させます。

• Dockerの基本コマンド一覧と使い方
• Docker ComposeでWordPress環境を作る方法