【Spring Boot】環境ごとにapplication.propertiesを切り替える

Java
2025.10.21

こんにちは、かつコーチです。

前回の記事でjarファイルをサーバーにデプロイする方法を紹介しましたが、開発環境と本番環境でDBの接続先やログレベルが同じというアプリはまずありません。

かといって、デプロイのたびにapplication.propertiesを手動で書き換えるのは、書き換え漏れによる事故のもとです。

この記事では、Spring Bootのプロファイル機能を使って、環境ごとに設定を安全に切り替える方法を解説します。

プロファイルとは何か

環境ごとに設定ファイルを分ける仕組み

プロファイルとは、Spring Bootが提供する「複数の設定セットを名前付きで管理し、起動時に指定した名前の設定だけを読み込む」仕組みです。

application-{プロファイル名}.propertiesという命名規則でファイルを用意しておくと、起動時にどのプロファイルを使うか指定するだけで、対応する設定が自動的に読み込まれます。

なぜハードコードや手動書き換えを避けるべきか

DBのパスワードや外部APIキーのような機密情報をapplication.propertiesに直接書き込み、それをGitにコミットしてしまうと、リポジトリを見られただけで漏えいにつながります。

また、開発環境用の設定のまま本番にデプロイしてしまい、テスト用DBに接続しようとしてアプリが起動しない、といった事故も、手動での書き換え運用では起こりがちです。

プロファイルを使えば、「どの環境で動かすか」を起動時の1つのパラメータに集約できるため、こうした事故を構造的に防げます。

基本の書き方・実装手順

手順1：環境別のプロパティファイルを作成する

src/main/resources/配下に、環境ごとのファイルを用意します。

src/main/resources/
├── application.properties        # 共通設定
├── application-dev.properties    # 開発環境
├── application-staging.properties # ステージング環境
└── application-prod.properties   # 本番環境

# application-dev.properties
spring.datasource.url=jdbc:mysql://localhost:3306/blog_dev
spring.datasource.username=dev_user
spring.datasource.password=dev_pass
logging.level.org.springframework=DEBUG

# application-prod.properties
spring.datasource.url=jdbc:mysql://prod-db.example.com:3306/blog
spring.datasource.username=${DB_USERNAME}
spring.datasource.password=${DB_PASSWORD}
logging.level.org.springframework=WARN

application.properties本体には、環境に依存しない共通設定（アプリ名やタイムゾーンなど）だけを残します。

手順2：起動時にプロファイルを指定する

spring.profiles.activeでどのプロファイルを使うかを指定します。

# コマンドライン引数で指定
java -jar blog.jar --spring.profiles.active=prod

# 環境変数で指定
export SPRING_PROFILES_ACTIVE=prod
java -jar blog.jar

systemdのサービスファイルに組み込む場合は、Environmentディレクティブで指定するのが定番です。

[Service]
Environment=SPRING_PROFILES_ACTIVE=prod
ExecStart=/usr/bin/java -jar /opt/blog/blog.jar

手順3：機密情報は環境変数で注入する

application-prod.propertiesの${DB_PASSWORD}のような記法は、環境変数からの値の注入を表します。

export DB_USERNAME=blog_prod
export DB_PASSWORD=super-secret-password

これにより、パスワードそのものはリポジトリに残らず、サーバー側の環境変数として管理できます。

つまずきやすい設定・注意点

プロファイル固有の設定ファイルは、application.properties本体の設定を「上書き」するのであって、丸ごと置き換えるわけではありません。

共通設定と環境別設定で同じキーを両方に書いた場合、環境別設定の値が優先されるという優先順位を理解しておく必要があります。

よくあるつまずきポイント・エラー対処

❌ Before：プロファイルを指定し忘れて起動する

筆者は初めてステージング環境にデプロイした際、--spring.profiles.active=stagingを書き忘れたままアプリを起動してしまい、開発用のDB接続設定のままステージングが動くという事故を起こしたことがあります。

エラーは出ないため、動作確認をするまで気づけませんでした。

# プロファイル未指定 → application.propertiesのデフォルト設定で起動してしまう
java -jar blog.jar

✅ After：デフォルトプロファイルを明示し、起動確認を仕組み化する

application.properties側にspring.profiles.defaultを設定しておくと、プロファイル未指定時に何が使われるかが明確になります。

# application.properties
spring.profiles.default=dev

さらに、/actuator/envエンドポイント（spring-boot-starter-actuatorが必要）で、実際に有効なプロファイルを起動直後に確認する運用にしておくと、設定ミスに早く気づけます。

curl http://localhost:8080/actuator/env | grep activeProfiles

デプロイ手順書やCIスクリプトに「起動後にプロファイルを確認する」ステップを明記しておくことで、同じ事故の再発を防げます。

応用・一歩先の使い方

YAML形式でより見通しよく管理する

application.propertiesの代わりにapplication.ymlを使うと、1つのファイル内で---区切りによって複数プロファイルの設定をまとめて管理できます。

spring:
  config:
    activate:
      on-profile: prod
datasource:
  url: jdbc:mysql://prod-db.example.com:3306/blog
---
spring:
  config:
    activate:
      on-profile: dev
datasource:
  url: jdbc:mysql://localhost:3306/blog_dev

環境ごとの差分が近くに並ぶため、設定の見比べがしやすくなるのがYAML形式の利点です。

CI/CDパイプラインとプロファイルを連携する

GitHub ActionsのようなCI/CDツールでは、ブランチ名やデプロイ先環境に応じてSPRING_PROFILES_ACTIVEを動的に切り替えるのが一般的です。

- name: Deploy to production
  run: java -jar blog.jar --spring.profiles.active=prod
  env:
    DB_PASSWORD: ${{ secrets.PROD_DB_PASSWORD }}

機密情報をCIのSecrets機能で管理し、実行時にだけ環境変数として渡す構成にしておくと、パスワード類がコード上のどこにも残らない状態を維持できます。

まとめ

この記事のポイント

  • プロファイルは環境ごとの設定セットを名前付きで管理する仕組み
  • application-{プロファイル名}.propertiesを用意し、spring.profiles.activeで切り替える
  • 機密情報は設定ファイルに直書きせず、環境変数から注入する
  • プロファイル未指定時のデフォルトを明示し、起動後に有効プロファイルを確認する運用にする
  • YAML形式なら複数プロファイルの差分を1ファイルで見通しよく管理できる

次に読むべき記事

環境設定を切り替えられるようになったら、次はアプリケーションをコンテナ化してどの環境でも同じように動かす「Dockerでコンテナ化する基本」に進みましょう。

タグ: Spring Boot, 中級者向け, デプロイ

タイトルとURLをコピーしました