コンテナの起動スクリプトが「マイグレーションツールを実行 → アプリを実行」のように別プロセスを順に起動する構成では、両者が同じ接続設定を別々の既定値で持つと、片方だけが失敗する。

失敗の型

アプリ側は本番で安全側の既定（TLS 要求）、ビルドツール側は開発都合の既定（TLS 無効）を持っていると、TLS を持たない内部ネットワークの DB に対してマイグレーションは成功し、アプリだけが起動に失敗する。ログを見ると「マイグレーション完了」の直後にアプリのクラッシュが出るため、DB 接続そのものは通っているように見え、原因の特定が遅れる。

判断基準

• 「両者が同じ環境変数を読むようにした」で終わらせない。未設定時にどちらへ倒れるかが揃っていなければ、同じ不整合が別の環境で再発する
• ビルドツール側の既定は開発の都合で決まっていることが多い。アプリ側の既定と同じ条件式（環境名による分岐など）を、ツール側の設定にも書く
• どちらか一方に寄せられないなら、既定を置かず両側で未設定を失敗にする。未設定が片側でだけ吸収される状態を残さない
• ビルドツールが変数を子プロセスへ一括エクスポートする設定になっていると、ツール経由で起動したアプリだけ設定が上書きされる経路が生まれる。これは「ツールを介さず直接起動する本番経路」では発現しないため、テストや手動確認でしか踏まない

検知方法

ツールに「実行せずコマンドだけ表示する」モードがあるなら、それを本番相当の環境名で走らせ、生成される接続文字列の該当項目がアプリ側の既定と一致することを検査するテストを置く。両者がずれた瞬間に落ちる。出力には資格情報が含まれるため、比較する項目だけを抽出し、失敗メッセージへ全体を出さない。

落とし穴

ビルドツールの「未定義なら代入」構文は、空文字で定義済みの環境変数には適用されないことがある。空文字を「未設定」として扱う言語側の実装と食い違うため、テストでは変数を空にするのではなく環境から取り除いて評価する。