Dockerでコンテナ内のシェルを操作する際、最も頻繁に使われるのが docker run と docker exec です。「コンテナに入って中身を確認したい」「テスト環境を一時的に立ち上げてコマンドを試したい」という場面でどちらを使うべきか迷う方も多いのではないでしょうか。
結論として、「新しいコンテナを立ち上げて入る」なら docker run -it --rm、「すでに動いているコンテナに入る」なら docker exec -it を使います。
本記事では、docker run と docker exec によるBash起動の使い分けから、コピペで使える必須オプション（ボリュームマウント・ポート公開・root権限指定など）、Alpine等の軽量コンテナで /bin/bash が見つからないエラーの対処法、ホストとのパーミッション競合対策まで網羅してわかりやすく解説します。
Docker全体の基本構造を復習したい方はDockerとは？初心者向け完全ガイド：コンテナの基礎から環境構築・デプロイまで、CLIコマンド全般の仕様はdocker – コンテナ/イメージを操作する Docker CLI の基底コマンドもあわせてご覧ください。
【1秒早見表】docker run と docker exec の使い分け
コンテナ内でBashを起動する2大コマンドの違いを一覧で整理しました。
| コマンド | コンテナの状態 | 主な目的・用途 | exit 後の挙動 |
|---|---|---|---|
docker run -it --rm <image> /bin/bash |
新規に作成・起動 | 使い捨ての検証環境作成、一時的なツール実行 | コンテナは終了し自動削除される |
docker exec -it <container_id> /bin/bash |
既にバックグラウンドで稼働中 | WebサーバーやDBの調査、設定確認、デバッグ | コンテナ本体は稼働したまま維持される |
・「UbuntuやPythonの環境をサクッと立ち上げてBashで動作検証したい」→
docker run・「
docker compose up や docker run -d で起動済みのコンテナに入りたい」→ docker exec
方法1: docker run で新しいコンテナを起動してbashに入る
イメージから新しいコンテナを起動し、そのままBashシェルに対話ログインする手順です。
基本構文と必須オプション（-it と –rm）
docker run -it --rm ubuntu /bin/bash
このコマンドを実行すると、ローカルに ubuntu イメージがなければ自動的にDocker Hubからダウンロード（pull）され、コンテナ内でBashが起動してプロンプトが表示されます。
ここで指定しているオプションの意味は次の通りです：
-i（--interactive）: 標準入力を開き続け、キーボード入力をコンテナに渡します。-t（--tty）: 擬似端末（TTY）を割り当て、色付き文字の表示やコマンドライン操作を通常のターミナル同様に行えるようにします。--rm: コンテナ終了時（exit時）にコンテナを自動削除します。これをつけることで不要な停止コンテナがディスクを圧迫するのを防ぎます。ubuntu: 使用するDockerイメージ名。/bin/bash: 起動するシェル（イメージによってはbashだけでOK）。
-i と -t は必ずセットで -it として指定します。-i だけだとプロンプトが表示されず、-t だけだとキー入力を受け付けません。
主要なベースイメージ別の起動コマンド例
開発でよく使われるイメージごとの起動コマンドです：
# Ubuntu（バージョン指定）
docker run -it --rm ubuntu:22.04 /bin/bash
# Debian
docker run -it --rm debian:bookworm-slim /bin/bash
# Python環境
docker run -it --rm python:3.11 /bin/bash
# Node.js環境
docker run -it --rm node:20 /bin/bash
実務でよく使う docker run オプション一覧
Bashで作業環境を作る際、併用する頻度が高いオプションをまとめました：
| オプション | 役割 | 指定例 |
|---|---|---|
-v /ホスト:/コンテナ |
ホストとコンテナでディレクトリを共有（バインドマウント） | -v $(pwd):/workspace |
-w /パス |
コンテナ起動時の作業ディレクトリ（カレントディレクトリ）を指定 | -w /workspace |
-p ホスト:コンテナ |
ポートフォワーディング（ポート転送） | -p 8080:80 |
-e KEY=VAL |
環境変数を設定 | -e ENV=development |
--name 名前 |
コンテナに任意の識別名を付与 | --name test-bash |
-u UID:GID |
実行ユーザーを指定（パーミッション対策） | -u $(id -u):$(id -g) |
実践例：カレントディレクトリをマウントして開発・検証を行う
ホスト側のソースコードをコンテナ内に持ち込み、コンテナ側のLinux環境でビルドやテストを行う鉄板のコマンド例です：
# 現在のフォルダをコンテナの /workspace に同期して作業ディレクトリに設定
docker run -it --rm -v "$(pwd)":/workspace -w /workspace ubuntu:22.04 /bin/bash
方法2: docker exec で稼働中のコンテナにbashログインする
すでにバックグラウンド（デタッチモード -d）で動いているコンテナや、docker compose で立ち上げたコンテナに入って設定変更やログ確認、デバッグを行う場合は docker exec を使用します。
起動中コンテナに入って操作する手順
ステップ1: 稼働中コンテナの確認
docker ps
出力例：
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a1b2c3d4e5f6 nginx:latest "/docker-entrypoint.…" 2 minutes ago Up 2 minutes 0.0.0.0:8080->80/tcp my-web-server
ステップ2: コンテナ名またはIDを指定してBashログイン
# コンテナ名で入る場合
docker exec -it my-web-server /bin/bash
# コンテナID（先頭数文字でOK）で入る場合
docker exec -it a1b2c3 /bin/bash
コンテナから抜けるときの注意点（exit vs デタッチ）
docker execで入った場合：exitまたは Ctrl + D で抜けても、コンテナ自体は稼働を続けます（追加で起動したBashプロセスだけが終了するため）。docker run -itで起動した場合：exitするとコンテナのメインプロセスが終了するため、コンテナ自体が停止（または--rmにより削除）されます。コンテナを動かしたまま抜けたい場合は、キーボードで Ctrl + P に続いて Ctrl + Q を押す（デタッチ）必要があります。
Docker Compose環境でコンテナに入る詳細なテクニックはDocker Composeでexec bashを使いこなそう！効率的なコンテナ操作ガイドおよびDocker Execコマンドでコンテナ内のBashを利用する方法と注意点をご覧ください。
root権限で入る方法（-u 0 / –user root）とパーミッション設計
Node.jsやPostgres、非特権ユーザー設定されたコンテナでは、通常ログインすると一般ユーザー権限になり、パッケージの追加（apt install 等）やシステム設定ファイルの編集が拒否されることがあります。
1. docker exec でroot権限ログインする
-u 0 または --user root を指定することで、コンテナ内のroot（UID 0）ユーザーとしてBashセッションを開始できます。
# rootユーザーとしてコンテナに入る
docker exec -u 0 -it my-web-server /bin/bash
# またはフルネームで指定
docker exec --user root -it my-web-server /bin/bash
rootで入れば、デバッグに必要な curl や vim、net-tools などを一時的にインストールして調査することが可能です。
2. ホスト側ファイルのパーミッション問題と解決策（-u $(id -u):$(id -g)）
docker run でボリュームマウント（-v $(pwd):/workspace）した際、コンテナ内でファイルを作成するとホスト側でファイルの所有者が root:root になり、ホストの一般ユーザーで編集・削除できなくなる問題が頻発します。
このトラブルを防ぐには、ホスト側のユーザーID/グループIDをコンテナ起動時に引き渡します：
# ホストの現在のユーザーID/GIDでコンテナを実行
docker run -it --rm -u $(id -u):$(id -g) -v "$(pwd)":/workspace -w /workspace ubuntu:22.04 /bin/bash
Linux環境でのファイル権限の仕組みや所有者の修正については、chmodコマンドの使い方とパーミッションの仕組み、chownコマンドの使い方完全ガイド、および権限エラーが出たらこれ！chown・chmodの基本と安全な直し方、コンテナとroot権限の設計思想については「rootで慣れる前に」：Docker時代でも効く Linux 権限設計と sudo の原則で詳しく解説しています。
Alpine等で /bin/bash がない場合のエラー対処法（shフォールバック）
軽量ベースイメージとして広く使われる Alpine Linux や、最小構成のイメージでは bash がプリインストールされていません。
発生するエラーメッセージ
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: "/bin/bash": stat /bin/bash: no such file or directory: unknown.
あるいは docker exec 時に：
OCI runtime exec failed: exec failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown
対処法1: /bin/sh を指定して起動する（最も確実）
Alpine Linuxには標準で軽量シェル sh（Ash）が搭載されているため、コマンド末尾を sh に変更します。
# docker run の場合
docker run -it --rm alpine sh
# docker exec の場合
docker exec -it my-alpine-container sh
対処法2: どうしてもBashが必要な場合はインストールする
Bash特有の配列構文やスクリプトを動かしたい場合は、コンテナ内で apk パッケージマネージャーを使ってBashをインストールします。
# 一時コンテナでbashをインストールして起動するワンライナー
docker run -it --rm alpine sh -c "apk add --no-cache bash && exec bash"
本番で恒常的にBashを使う場合は、Dockerfile側で RUN apk add --no-cache bash を定義しておくのがベストプラクティスです。Dockerfileの書き方はDockerfileでBashを実行する方法｜RUN・CMD・ENTRYPOINTの使い分けをご参照ください。
実務で役立つコンテナ内Bash操作の応用テクニック
1. インタラクティブに入らずワンライナーを実行する（bash -c）
端末に対話ログインせず、コンテナ内でコマンドを実行して結果（標準出力）だけをホスト側に取得したい場合は bash -c を使います。
# docker run でワンライナーを実行して即終了
docker run --rm ubuntu bash -c "uname -a && df -h"
# 稼働中コンテナ内のログファイル末尾を確認
docker exec my-web-server bash -c "tail -n 20 /var/log/nginx/access.log"
2. ホスト側のスクリプトやパイプをコンテナに流し込む（-i のみ利用）
ホスト側にある setup.sh をコンテナ内にコピーすることなく直接コンテナ内のBashで実行したい場合、-t を外し -i（標準入力）だけでパイプ渡しします。
# ホスト側のスクリプトをコンテナの標準入力に流し込んで実行
cat ./my-script.sh | docker exec -i my-web-server bash
# または docker run で実行
docker run -i --rm ubuntu bash < ./my-script.sh
GitHub Actionsやcronなどの非対話環境で
-t を付けると the input device is not a TTY エラーが発生します。スクリプトやパイプによる自動処理では必ず -t を除外して -i だけを指定しましょう。
よくあるトラブルと解決Q&A
Q1. コンテナに入ろうとすると即座に終了（Exit）してしまう
A. コンテナ内に常駐プロセス（フォアグラウンドプロセス）が存在しない場合、コンテナは直ちに停止します。バックグラウンドで起動しておいて後から入る場合は、以下のようにダミーの待ちコマンドで起動します：
docker run -d --name my-test ubuntu sleep infinity
docker exec -it my-test bash
Q2. Windows環境（PowerShell/WSL2）からコンテナを動かす際の注意点は？
A. WindowsでDocker Desktopを使用している場合、パス指定（-v）に注意が必要です。WSL2内のパス（/home/user/project）またはGit Bashのパス（/c/Users/...）を使用するか、WSL2バックエンドを有効にしてWSL2ターミナル上からDockerを実行するのが最もスムーズです。
WindowsでのBash環境整備についてはWindowsでBashを使う3つの方法（WSL2 / Git Bash / PowerShell比較）で詳しく解説しています。
Q3. 本番コンテナに手動で入る際のセキュリティ上のリスクは？
A. 運用中のコンテナに直接入って手動でファイルを修正すると、インフラの再現性（Infrastructure as Code）が失われ、コンテナ再起動時に変更が消失します。調査目的に限定し、恒久対応はDockerfileや設定ファイルの修正・デプロイで行いましょう。本番サーバーの選定や運用基盤についてはVPSおすすめ比較｜初心者〜開発者まで安心して使える高速サーバー3選も参考にしてください。
まとめ：コンテナ内Bash操作のベストプラクティス
Dockerコンテナ内でのBashログイン・操作のポイントをまとめます：
- 新規検証:
docker run -it --rm <image> /bin/bashを基本とする（使い捨て運用） - 稼働中コンテナ調査:
docker exec -it <container> /bin/bashを使用する - 権限不足:
docker exec -u 0 -it ...でrootログインして対処 - ホストファイル共有:
-v $(pwd):/app -u $(id -u):$(id -g)で所有者不一致を防ぐ - Alpine Linux:
/bin/bashの代わりにshを指定する
コンテナ内で利用する基本コマンドを再確認したい方はLinuxコマンド一覧｜用途別に整理した初心者向け完全ガイド、環境構築のロードマップは14日で基礎固め｜Linux & Bash独学ロードマップをぜひチェックしてみてください。
コメント