Dockerコンテナに入る方法3選！基本と注意点を解説

Dockerを使い始めたばかりのころ、コンテナという「隔離された環境」の扱いに戸惑うことは多いです。私自身、開発中に「コンテナの中のログを見たい」「設定ファイルが正しく配置されているか確認したい」と思っても、その「中に入る」という具体的な操作方法が分からず、試行錯誤した経験があります。

特に docker exec と docker attach の違いを理解していなかったために、デバッグ中に関係のないコンテナを停止させてしまい、慌てたことも一度や二度ではありません。

この記事は、過去の私と同じように「Dockerコンテナの中に入る方法が知りたい」と悩んでいる方に向けて書きました。

この記事を最後まで読めば、以下の3つのことが分かります。

Dockerコンテナに「入る」とは、どういうことか。
docker exec をはじめとする、コンテナに入るための3つの基本コマンドの使い方。
コンテナに入れない時の対処法や、安全に抜ける方法。

基本的な操作をきちんと理解して、Dockerのデバッグ効率を上げていきましょう。

Dockerコンテナに入るとは？基本を理解しよう

まず、Dockerコンテナに「入る」という行為が、何を意味するのかを整理します。

Dockerコンテナの仕組みをざっくり解説

Dockerコンテナは、アプリケーションを実行するために必要なライブラリや設定ファイル、OSの一部などをひとまとめにした「独立した実行環境」です。

従来の開発では、自分のPCとサーバーでOSやライブラリのバージョンが違い、「ローカルでは動いたのに本番では動かない」という問題がよく起きていました。

Dockerは、この「環境」ごとパッケージ化して動かす技術です。これにより、どこでも同じようにアプリケーションを動作させられるようになりました。コンテナは非常に軽量で、1台のマシン上でたくさんのコンテナを同時に動かせます。

コンテナに「入る」ことの意味とは

コンテナに「入る」とは、その独立した実行環境の中でコマンドを実行できる状態になることです。

具体的には、コンテナ内で「シェル」（bash や sh といったコマンド入力の受付役）を起動し、コンテナ内部からファイルを見たり、プロセスを確認したりする操作を指します。

例えば、Webサーバーのコンテナ（Nginxなど）を起動した場合、「中に入る」ことで、Nginxの設定ファイル（nginx.conf）が正しく読み込まれているかを確認したり、アクセスログの出力をリアルタイムで監視したりできます。

仮想マシンとの違いを簡単に整理

Dockerとよく比較される技術に「仮想マシン」（VM）があります。

仮想マシン (VM):OS（WindowsやLinux）をまるごと仮想的に作り出す技術です。ホストOSの上にもう一つゲストOSが動くイメージで、起動が遅く、リソース（メモリやCPU）も多く消費します。
Dockerコンテナ:ホストOSの機能（カーネル）を利用しつつ、プロセスやファイルシステムだけを隔離します。OSをまるごと動かすわけではないため、非常に軽量で高速に起動するのが特徴です。

仮想マシンに「入る」のは、リモートデスクトップやSSHでOSに「ログイン」する感覚に近いでしょう。

一方、Dockerコンテナに「入る」のは、OSにログインするというよりも、起動中のコンテナ（プロセス）に対して、別のコマンド（シェル）を割り込ませる感覚に近いです。

Dockerコンテナに入る基本コマンド

Dockerコンテナに入る方法は、主に3つのコマンドパターンに分けられます。それぞれの特徴と使い方を理解することが重要です。

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 シェルを指定しています。

このコマンドを実行すると、コンテナ内のシェルが起動し、プロンプト（例: root@コンテナID:/#）が表示されます。あとは通常のLinuxコマンド（ls や cd など）が使えます。

docker attach を使う場合の注意点

docker attach は、コンテナが起動時に実行したメインプロセス（標準入出力）に接続するためのコマンドです。

結論から言うと、初心者のうちは docker attach よりも docker exec を使うことを強く推奨します。

docker attach には大きな注意点があります。

それは、attach で接続中に Ctrl+C などで抜けようとすると、接続先のメインプロセスが終了してしまうことです。

メインプロセスが終了すると、Dockerはそのコンテナの役目が終わったと判断し、コンテナ自体が停止してしまいます。デバッグのつもりが、サービスを停止させてしまう事故につながりかねません。

docker exec はコンテナ内で「新しいプロセス（シェル）」を起動するのに対し、docker attach は「既存のメインプロセス」に接続する、という根本的な違いがあります。

docker run -it で新しく入るパターン

docker run は、イメージから新しいコンテナを作成して起動するコマンドです。

docker run に -it オプションを付けてシェルを指定すると、コンテナの作成・起動と同時に「中に入る」ことができます。

実行例:

ubuntu イメージを使い、起動と同時に bash シェルで入る場合。

docker run -it ubuntu /bin/bash

この方法は、主に以下の2つのケースで使われます。

OSイメージ（ubuntuやAlpineなど）を使って、一時的なデバッグ環境や検証環境として利用したい場合。
開発中のアプリケーションを起動するのではなく、イメージの中身を調査したい場合。

docker exec が「すでに動いているコンテナ」に入るのに対し、docker run -it は「これから新しく作るコンテナ」に入る、という違いがあります。

よく使うシェル（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 を実行して「No such file or directory」といったエラーが出た場合は、bash が存在しない可能性が高いです。

その場合は、代わりに /bin/sh を試してみてください。

docker exec -it [コンテナID] /bin/sh

Dockerコンテナ内での操作例

無事にコンテナ内に入れたら、次に内部でどのような操作ができるのか、いくつかの例を紹介します。

ファイルの確認・編集方法

コンテナに入ると、Linuxコマンドが使えます。

ファイルの確認ls -la でファイルやディレクトリの一覧を表示したり、cat /path/to/file でファイルの中身を表示したりできます。
ファイルの編集vi や nano などのテキストエディタでファイルを編集することも可能です。

ただし、注意点があります。Alpine などの軽量イメージには、テキストエディタがインストールされていないことがほとんどです。

その場合、apt update && apt install vim (Debian/Ubuntu系) や apk add vim (Alpine系) のように、コンテナ内でパッケージマネージャを使って一時的にインストールする必要があります。

しかし、本来コンテナは「イミュータブル（不変）」であることが推奨されます。コンテナ内で直接ファイルを編集するのは、あくまで一時的なデバッグに留めるべきです。恒久的な変更は、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:/# exit

exit を実行すると、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 ps -a

STATUS カラムを見て、Exited と表示されていたら、そのコンテナは停止しています。

docker start [コンテナID] でコンテナを再起動してから、もう一度 docker exec を試してください。

権限エラーが出るときの対処法

docker exec を実行した際に「permission denied」といった権限エラーが出ることがあります。

これは、コンテナがセキュリティ上の理由から一般ユーザー（root ではないユーザー）で実行されており、そのユーザーにシェルの実行権限がない場合などに起こります。

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で作業効率を上げるコツ

最後に、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'

このように設定しておけば、次からは dex [コンテナID] /bin/bash と入力するだけで済みます。

Docker Composeで複数コンテナを管理する

実際の開発では、Webサーバー、アプリケーション、データベースなど、複数のコンテナを連携させて動かすことが一般的です。

Docker Compose は、複数のコンテナ構成を docker-compose.yml という設定ファイルで一元管理できるツールです。

Docker Compose を使うと、コンテナIDの代わりに docker-compose.yml で定義した「サービス名」でコンテナを指定できます。

# docker-compose exec [サービス名] [実行コマンド]
docker-compose exec web /bin/bash

コンテナIDをいちいち docker ps で調べる手間が省けるため、開発効率が格段に上がります。

実運用でおすすめのコンテナ操作方法

コンテナに「入る」方法を解説してきましたが、実運用のコンテナに docker exec で入ってファイルを直接編集する行為は、原則として避けるべきです。

これは、Dockerの重要な考え方である「Immutable Infrastructure (イミュータブル・インフラストラクチャ / 不変なインフラ)」に反するためです。

コンテナは、一度作成したら変更しないことが理想です。もし設定変更やコードの修正が必要になったら、docker exec で中をいじるのではありません。

正しい手順:

Dockerfile や docker-compose.yml、アプリケーションのコードなど、大元の設定ファイルを修正します。
docker build でイメージを再ビルド（再作成）します。
古いコンテナを停止・破棄し、新しいイメージから新しいコンテナを起動（デプロイ）します。

この流れを徹底することで、「誰がいつ何を編集したか分からない」という状態を防ぎ、環境の再現性を保てます。

docker exec でコンテナに入るのは、あくまで一時的なデバッグや状態確認（読み取り専用）のため、と割り切ることが重要です。

まとめ：Dockerコンテナに入る操作をマスターしよう

Dockerコンテナに入る方法について、基本となる3つのコマンドと、関連する操作や注意点を解説しました。

基本は docker exec -it: 起動中のコンテナに安全に入るための定番コマンドです。
docker attach は注意: メインプロセスに接続するため、コンテナを意図せず停止させるリスクがあります。
docker run -it は新規作成時: 新しくコンテナを作ってすぐに入る場合に使います。
安全な離脱は exit: exec で入った場合は exit か Ctrl+D で抜けます。
実運用での編集はNG: exec でのデバッグはOKですが、本番環境のファイル変更はDockerfileの修正と再デプロイで行いましょう。

docker exec は、開発やデバッグの現場で非常によく使うコマンドです。この記事で紹介したTIPSを活用し、コンテナ内での操作をマスターしてください。