開発・本番で動きが違う？「環境ごとの設定分離」がプロジェクトの安定性を支える理由
システム開発において「開発環境では動いていたのに、本番ではうまく動かない」といった問題は、決して珍しいものではありません。その原因のひとつが、環境ごとの設定が適切に分離されていないことにあります。
この記事では、開発・ステージング・本番といった複数の環境に対応するための設定管理の重要性と、実装・運用における勘所を解説します。開発会社に依頼する立場でも、提案や見積もり段階でこの観点を押さえておくと、後々のトラブルを回避しやすくなります。
よくある課題：設定がハードコードされていて切り替えられない
開発初期はスムーズに進んでいたのに、本番リリース時に次のようなトラブルが発生することがあります。
- APIの接続先が開発用のままになっていた
- メール送信先がテストアカウントのまま本番に送信された
- ログ出力レベルが本番でもデバッグモードのまま
- パフォーマンスチューニングが未反映で本番だけ極端に遅い
これらは一見「ヒューマンエラー」に見えますが、実際には環境切り替えの設計が甘いことに起因しています。
環境ごとの設定管理で分離すべき代表的な項目
環境の違いに応じて切り替えるべき設定には、以下のような項目があります。
API接続情報
- 本番とテストで異なる外部APIのURLや認証キー
- サンドボックス環境と本番環境を明確に切り分ける
データベース接続先
- 開発用のDB、本番用のDB、CI/CD用のテストDBなどを明示的に分離
- 間違って本番DBを破壊する事故を防ぐ
認証・セッション管理
- OAuthやSSO設定のクライアントID・シークレットを環境別に管理
- Cookieドメインやセッション保持時間も環境に応じて変更
ログ設定・エラー通知
- 開発では詳細ログ、本番では最低限のログとエラーレポートを外部通知
- Slack通知やエラーレポートメールの送信先も分離
メール送信設定
- 本番でのみ外部ユーザーに送信されるように制御
- テストメールは開発者のみに限定
CORS・ドメイン制限
- APIの許可ドメイン、フロントエンドとの通信元を環境で切り替える
これらはすべて「動作環境に依存する設定」であり、コードとは分離して管理されるべき情報です。
設計・実装で押さえるべき管理手法
1. 環境変数による管理
.envファイルやシステム環境変数を活用して設定値を外部化- 機密情報（APIキーなど）もコードに含めず、セキュアな方法で読み込み
.env.production,.env.developmentなどで環境別にファイルを分離
2. ビルド・デプロイ時の自動切り替え
- CI/CDツール（GitHub Actions, GitLab CI, CircleCI など）で、環境に応じた設定ファイルを自動的に配置
- コンテナやVMの起動スクリプトで動的に環境変数を注入
3. 設定ファイルのバージョン管理
- 本番用の設定はGit管理しない（例：Gitの
.gitignoreに追加） - 代わりに
.env.exampleのようなサンプルファイルを共有して構成の雛形をチームで統一
4. 設定項目の「明示的な定義」
- 環境ごとに異なる値をどこで定義・読み込むかを明文化
- 値のデフォルトを明示し、未設定時の挙動を制御（例：警告ログを出す）
5. モニタリングとの統合
- 本番・ステージングのログやエラーを分離表示できるように設計
- SentryやDatadog、CloudWatchなどと連携し、環境タグを付与
開発会社の提案・見積もり時に確認すべき視点
開発を依頼する際、以下のようなポイントを確認すると、設定分離がきちんと考慮された設計かどうかを見極められます。
「環境ごとの設定」が設計書に含まれているか
- APIキーやDB設定が環境変数で管理される前提になっているか
- 設定変更時の反映方法（再起動要／即時反映）などが明記されているか
実装上の保守性とセキュリティ配慮
.envなどの機密設定ファイルをGitに含めない体制になっているか- 本番・開発の誤操作リスクを減らす工夫（例：環境表示ラベル）
CI/CDやデプロイフローでの切り替え方法
- 各環境への自動デプロイ時に設定が上書きされる仕組みがあるか
- 手作業によるコピー・編集ではなく、スクリプトで再現性のある手順になっているか
こうした設計が事前に組み込まれていれば、リリース前後のトラブルリスクが大きく軽減されます。
まとめ：設定の分離が“環境差異による事故”を防ぐ
「開発では動いていたのに…」という言葉は、多くの現場で聞かれるフレーズですが、その多くは設定の分離設計ができていないことに起因します。
開発を外部に依頼する立場であっても、環境変数や設定ファイルの構成に言及があるかを確認するだけで、品質とセキュリティのレベル感をある程度見極めることができます。
本番・開発・ステージングといった環境ごとの「差異」をコントロールできる設計は、結果的にリリース速度や障害対応力にも直結する重要な要素です。
ぜひプロジェクト初期段階から「環境ごとの設定分離」を前提とした設計体制を整えるようにしましょう。
