【入門編】Mavenの「プロファイル」機能を極める！環境依存のビルド切り替えをスマートに管理する方法 – ビルド・パッケージ管理ツール生産性向上バイブル

こんにちは！開発現場で毎日のようにビルドツールと格闘していると、「ローカルでは動くのに、ステージングや本番環境のサーバーに載せたら設定ミスで動かない……」という冷や汗をかく瞬間に出会いませんか？

Javaの世界では、長年ビルドツールのデファクトスタンダードとして君臨する Apache Maven が使われています。今回は、このMavenが持つ隠れた（しかし最強の）武器である 「プロファイル（Profiles）機能」 を徹底的に解剖します。

これをマスターすれば、`dev`（開発）、`stg`（ステージング）、`prod`（本番）といった環境ごとの設定地獄から完全に解放され、コマンド一発で安全かつスマートにビルドを切り替えられるようになります。毎日のコーディングとデプロイ作業が劇的に楽になりますよ。一緒にその仕組みの本質を紐解いていきましょう！

—

1. Mavenのプロファイル（Profiles）とは何か？なぜ必要なのか

まずは、「なぜプロファイルが必要なのか」という根本的なアーキテクチャの話から始めましょう。

Javaアプリケーションを開発していると、環境ごとに変化する要素がたくさんありますよね。

• データベースの接続先URLや資格情報
• ログの出力レベル（開発時は `DEBUG`、本番は `INFO`）
• 外部APIのエンドポイント
• デプロイ先のバイナリリポジトリURL

素朴な開発者は、ソースコードや設定ファイル（`application.properties` や `pom.xml`）を環境ごとに手動で書き換えたり、デプロイの直前にシェルスクリプトで無理やり置換したりしがちです。しかし、これは「ヒューマンエラー」を誘発する最大の温床です。

Mavenプロファイルの正体

Mavenのプロファイル機能とは、「ビルドのコンテキスト（状況）に応じて、`pom.xml` の中身を動的に書き換える（オーバーライドする）仕組み」 です。

Mavenの内部では、`pom.xml` を読み込んだ後に、有効化されたプロファイルの設定（プロパティ、依存関係、プラグインなど）をマージ・上書きして、最終的なビルド設計図を作り上げます。これにより、ソースコードの変更を一切行わずに、環境に最適化された成果物（JARやWAR）をクリーンに生成できるのです。

—

2. 【基本セットアップ】環境依存設定の分離設計

それでは、実際に手を動かしながら、`dev` / `stg` / `prod` の3つの環境をスマートに切り替えるプロジェクト構成を作ってみましょう。

ここでは、最も王道である 「プロパティ（properties）の動的切り替え」 を実装します。

プロジェクトのディレクトリ構成

まずは、次のような標準的なMavenプロジェクトの構成をイメージしてください。リソースファイル（`application.yml` など）を環境ごとに分けるのがポイントです。

my-app/
├── pom.xml
└── src/
└── main/
├── java/
│ └── com/
│ └── example/
│ └── App.java
└── resources/
├── application.yml <-- 共通設定 └── profiles/ ├── dev/ │ └── application.yml <-- 開発環境用設定 ├── stg/ │ └── application.yml <-- ステージング環境用設定 └── prod/ └── application.yml <-- 本番環境用設定

魔法の `pom.xml` 設計

それでは、環境ごとにプロパティを切り替えるための `pom.xml` の核心部分を見ていきましょう。ここが今回の記事で最も重要な設計図になります。

この設定の何がすごいのか？

Mavenの `true` という設定がミソです。これにより、ビルド時に `src/main/resources` 内にあるファイルをスキャンし、後述するプレースホルダー（変数）を、選択されたプロファイルの値に自動的に置き換えて `target/classes` に出力してくれます。

—

3. 精度高い「Hello World」的動作確認

それでは、この仕組みが正しく動くかを「Hello World」形式で確認してみましょう。

リソースファイルの準備

`src/main/resources/application.yml` を次のように作成します。変数を囲む記号には `@` を使うのがMavenの標準的で安全な作法です（Spring Bootの `${…}` と競合するのを防ぐためです）。

共通アプリケーション設定
spring:
application:
name: my-app

Mavenプロファイルによって動的に置き換えられる変数
environment: @env@
database:
url: @db.url@
username: @db.username@
logging:
level:
root: @log.level@

動作確認コマンドの実行とログ

ターミナルを開き、Mavenコマンドを叩いてプロファイルを切り替えてみましょう。

① デフォルト（開発環境：dev）でビルドする場合

何も指定しない場合、`true` が効いているため `dev` プロファイルが選択されます。

$ mvn clean package -Pdev

【内部の動きと期待される結果】
`target/classes/application.yml` を覗いてみると、変数が美しく置換されていることが分かります。

environment: dev
database:
url: jdbc:postgresql://localhost:5432/app_dev
username: dev_user
logging:
level:
root: DEBUG

② 本番環境（prod）の成果物を作りたい場合

コマンドライン引数に `-Pprod` を渡すだけで、一瞬にして本番用の設定が埋め込まれたバイナリが生成されます。CI/CDパイプライン（GitHub ActionsやGitLab CIなど）ではこのコマンドを叩くだけです。

$ mvn clean package -Pprod

【期待される結果（`target/classes/application.yml`）】

environment: prod
database:
url: jdbc:postgresql://prod-db.internal:5432/app_prod
username: prod_user
logging:
level:
root: WARN

これぞ、手動ミスの入る余地がないスマートなビルド管理の世界です！

—

4. 【実践知見】OSごとの設定分岐や高度なプロファイル発動条件

ここからが、普通の解説記事を超えた「DevOpsリードチーフエンジニア」としての真骨頂です。実務では、単なる `dev/stg/prod` だけでなく、さらに高度なプロファイルの制御が求められます。

① OSごとにプラグインや依存関係を切り替える

「開発メンバーの一人はMac（ARM64）、別のメンバーはWindows（x64）」というチームで、ネイティブライブラリを伴うビルドを行う際などに、OSごとのプロファイル自動切り替えが力を発揮します。