Javaの業務プロジェクトでよく出てくる「値の管理方法」は大きく3パターンある。
それぞれ実装方法・反映方法・向いている場面が違うので整理しておく。
Javaクラスで定義（定数クラス）
主な特徴
public static finalでクラスに直接定義- 値はコードに固定 → 変更にはビルド＆デプロイが必要
- JVM内で参照されるだけなので処理は最速
実装例
public class Const {
public static final int MAX_ITEM = 100;
public static final String SYSTEM_MODE = "PROD";
}よく使う場面
- 無効／有効などの固定フラグ
- 数値による種別コード
- if文などで分岐する画面タイプ定義
LocalDateTime.now().plusDays(Const.LIMIT_DAYS)みたいな日数・期間定義
不向きな場面
- 設定変更のために毎回コードを変更したくないもの
- 本番・開発など環境別で値が異なるもの
設定ファイル（application.properties / yml）
主な特徴
- Spring Boot標準の外部設定ファイル
- 再起動すれば値変更が反映される（Javaコード変更なし）
実装例①
app:
mode: prod
max-items: 100
external-api-url: https://api.example.com@Value("${app.mode}")
private String mode;
@Value("${app.max-items}")
private int maxItems;実装例②
gacha:
base-rare-rate: 0.07
pity-threshold: 30@Component
@ConfigurationProperties(prefix = "gacha")
@Getter @Setter
public class GachaConfig {
private double baseRareRate;
private int pityThreshold;
}@Service
public class GachaService {
private final GachaConfig gachaConfig;
public GachaService(GachaConfig gachaConfig) {
this.gachaConfig = gachaConfig;
}
public void draw() {
double rate = gachaConfig.getBaseRareRate();
int pity = gachaConfig.getPityThreshold();
System.out.println("今は：" + rate);
}
}よく使う場面
- 環境ごとに変わるURL
dev用とprod用で別URL
- メール送信スイッチ
mail.enabled=falseにして開発環境では送らない
- 外部連携のID・Token類
- ログ出力レベルなど実行時には変わらないが、環境で違うもの
不向きな場面
- 頻繁に値を変更したい機能（変更ごとに再起動が必要）
- 動的に制御したいケース（例：バナー表示有無を運用側で切り替えたい）
DBのパラメータテーブルで管理
主な特徴
- 値をDBに保存し、実行時に取得
- 値を変更するためにコード・再起動は不要
- 管理画面と組み合わせれば運用しやすい
DB構造例
CREATE TABLE config_param (
param_key VARCHAR(100) PRIMARY KEY,
param_value VARCHAR(255)
);Javaから取得（DAO）
public interface ConfigParamDao {
String getParam(String key);
}String limitDays = configParamDao.getParam("LIMIT_DAYS");よく使う場面
- キャンペーンのON/OFF制御
- 画面文言の切替
- 表示件数やページサイズを動的に変える
- アラート条件の閾値設定
- 通知時間帯・バッチの実行タイミング
不向きな場面
- 小規模・単純なプロジェクト（DAOやキャッシュが不要な場合）
- 一度も値が変わらない定義（無駄にDBアクセスが発生）
比較まとめ
| 管理方法 | 特徴 | 代表的な使用例 | 注意点 |
|---|---|---|---|
| Java定数 | 値をコードに固定 | フラグ・種別コード・列数定義など | 変更は再ビルド必須 |
| 設定ファイル | ソース変更なし、再起動で反映 | 環境差（URL/API）、ログ設定、ON/OFF制御 | 頻繁な変更には不向き |
| DB | 実行時変更OK、UI対応も可能 | キャンペーン、通知設定、画面切替条件など | 初期設計・DAOが必要 |
コメント