docker compose restartで反映される変更、反映されない変更

運営・編集: 村上祥太（公式ドキュメント・一次情報の確認と構成をもとに編集。有償VPSでの比較実測はまだ実施していません）

docker compose restart は、既存コンテナを止めて起動し直す操作であり、compose.yaml の変更を取り込む操作ではない。Docker公式も、Compose設定や環境変数を変えてもrestartでは反映されないと明記している。設定を直したのに挙動が変わらない場面では、この差を先に疑う。

次の区分はDocker公式のコマンド仕様と本番デプロイ案内から作った確認表である。特定アプリでの実行結果ではない。確認日: 2026年9月12日。Docker公式: docker compose restart

restartが向く場面

プロセスが一時的に不調で、設定もイメージも変えていない場合はrestartが候補になる。対象サービスだけを指定できるため、依存サービスをむやみに止めずに済む。ただし、アプリがデータベース接続を掴み直せるか、再起動によって進行中のジョブがどうなるかはアプリごとに違う。

再起動の前に、失敗時刻、対象サービス、直前の設定変更、保留中のジョブを残す。AI APIへの実行を含む処理は、途中で切れた要求を再送すると二重送信や二重登録につながることがある。再実行してよい単位を決めずに、コンテナだけ再起動しない。

設定変更は再作成として扱う

環境変数、ポート、マウント、依存関係を変えたなら、restartで見た目だけ直そうとしない。Docker公式の本番向け案内は、アプリコードを変えた場合、イメージを再ビルドしてコンテナを再作成する流れを示している。サービス単位で更新する場合も、依存関係をどう扱うかを先に決める。Docker公式: Composeを本番で使う

以下のコマンド例は、ここでは実行していない。サービス名 app の例なので、自身のComposeファイルに定義したサービス名へ置き換える。DB移行を含む更新には使わない。実施前には、次を照合する。

1. 変更対象のファイルと、値を変えた理由を記録したか。
2. 秘密情報を表示せずに設定を確認できるか。
3. 採用するイメージのバージョンまたはダイジェストを記録したか。
4. データベース移行があるなら、先にバックアップとロールバック方針を決めたか。
5. 更新後に通す最小限の実処理を決めたか。

設定を検証するには、対象サービスの更新前に次を実行する。

docker compose config --quiet
docker compose up -d app

イメージをレジストリから更新する場合は、採用する固定タグまたはダイジェストを変更履歴で確認したうえで、次の順にする。

docker compose pull app
docker compose up -d app

Dockerfileやアプリのソースを変えた場合は、pullの代わりに docker compose build app を使う。DBスキーマ移行を伴う更新は、アプリとDB製品が案内する移行手順、バックアップ、ロールバック方針を別に確認してから行う。運用メモでは「全サービス」か「対象サービスのみ」かを明記し、実行前に対象名を確認する。

更新後に見る順番

コンテナの起動表示だけでは完了にしない。アプリがHTTPで応答するか、依存するDBがhealthyか、Webhookから一件の処理が通るか、失敗通知が出るかを順に確認する。APIキーの値そのものや認証ヘッダーをログへ出して確認しないことも、手順に含める。

この確認を通せない更新は、変更前に戻す判断がしやすいよう、変更前のイメージ識別子とComposeファイルを保管しておく。復旧とはコンテナがrunningへ戻ることではなく、必要な処理が意図した結果を一度返せる状態まで戻すことだ。

参考資料

• Docker公式: docker compose restart（確認日: 2026年9月12日）
• Docker公式: Composeを本番で使う（確認日: 2026年9月12日）