Javaで定数を宣言する方法｜static finalの書き方と命名規則を解説

2026年3月6日2026年5月5日

基本文法・構文

Javaを用いたシステム開発において、プログラム内で変更されることのない「不変の値」を定義することは非常に重要です。

税率や最大接続数、エラーメッセージといった値をソースコード内に直接書き込む（マジックナンバー）のではなく、名前を付けた「定数」として管理することで、コードの可読性と保守性が劇的に向上します。

Javaには言語仕様として「const」キーワードが存在しますが、実際には static final を組み合わせて定数を表現するのが一般的です。

本記事では、Javaにおける定数宣言の基本から、現場で使われる命名規則、さらには不変性を担保するための高度なテクニックまでを網羅的に解説します。

目次 [ close ]

Javaにおける定数宣言の基本

Javaで定数を定義する際、最も標準的な方法は static 修飾子と final 修飾子を組み合わせて使用することです。

この2つのキーワードにはそれぞれ重要な役割があり、それらを組み合わせることで「クラス全体で共有され、かつ書き換え不可能な値」を実現します。

final修飾子の役割

final は、その変数に対して 一度しか値を代入できないこと を保証する修飾子です。

初期化された後に値を変更しようとすると、コンパイルエラーが発生します。

これにより、プログラムの実行中に予期せず値が書き換えられるリスクを排除できます。

static修飾子の役割

static は、その変数が「インスタンス（オブジェクト）」に属するのではなく、「クラス」そのものに属すること を示します。

定数を static にすることで、オブジェクトを生成（new）することなくどこからでも同じ値を参照できるようになり、メモリの節約にもつながります。

基本的な書き方の例

以下に、クラス内で定数を宣言する際の基本的なコード例を示します。

Java

public class AppConfig {
    // 消費税率を定数として定義
    public static final double TAX_RATE = 0.10;

    // システム名を定数として定義
    public static final String SYSTEM_NAME = "在庫管理システム";

    public static void main(String[] args) {
        // 定数の利用
        System.out.println("システム名: " + SYSTEM_NAME);
        double price = 1000;
        double tax = price * TAX_RATE;
        System.out.println("消費税: " + tax + "円");

        // TAX_RATE = 0.08; // ここで値を再代入しようとするとコンパイルエラーになります
    }
}

実行結果

システム名: 在庫管理システム
消費税: 100.0円

定数の命名規則（コーディング規約）

Javaでは、通常の変数名には「キャメルケース（camelCase）」が用いられますが、定数（static final）には「スクリーミング・スネークケース（SCREAMING_SNAKE_CASE）」を用いるのが一般的です。

これは、コードを読んだ瞬間に「これは定数である」と識別できるようにするための重要なルールです。

命名ルールの詳細

すべて大文字で記述する：アルファベットはすべて大文字を使用します。
単語の間をアンダースコア（_）で繋ぐ：複数の単語を組み合わせる場合は、アンダースコアで区切ります。
意味のある名前を付ける：値の内容がひと目でわかる名前を付けます。

種類	命名例	備考
定数	`MAX_RETRY_COUNT`	スクリーミング・スネークケース
変数	`retryCount`	ローワーキャメルケース
クラス	`RetryManager`	アッパーキャメルケース（パスカルケース）

なぜ命名規則が重要なのか

大規模な開発現場では、数百人規模のエンジニアが同じコードを読み書きします。

もし定数が taxRate のように通常の変数と同じ形式で書かれていた場合、誤って値を変更しようとしてしまう かもしれません（実際にはfinalがあればコンパイルエラーになりますが、可読性は低下します）。

TAX_RATE と書かれていれば、一目で「これは変更してはいけないグローバルな設定値である」と認識できるため、バグの混入を防ぐ効果があります。

定数を宣言する場所とスコープ

定数は、その用途に応じて宣言する場所を適切に選ぶ必要があります。

クラス定数（public static final）

外部のクラスからも参照させたい場合は、public アクセス修飾子を付けます。

共通の設定値などは、専用の定数クラスにまとめられることが多いです。

内部定数（private static final）

そのクラス内だけで使用し、外部に公開する必要がない定数は private にします。

これは カプセル化 の観点から非常に重要です。

不必要な情報を外部に見せないことで、クラス間の結合度を下げることができます。

ローカル定数（final）

メソッド内でのみ有効な定数を作る場合は、単に final を付けます。

メソッド内の計算で一時的に使用する固定値などに利用します。

この場合、static は付けられません。

また、命名規則も通常の変数と同じキャメルケースが使われることが一般的です。

Java

public void calculate() {
    final double discountRate = 0.05; // このメソッド内でのみ有効
    // ... 処理
}

参照型変数の定数（List, Mapなど）の注意点

Javaの定数宣言において、初心者が最も陥りやすい罠が「参照型変数の不変性」です。

プリミティブ型（int, doubleなど）やString型の場合、final を付ければその値は完全に固定されます。

しかし、ListやMap、配列などのオブジェクトの場合、final が保証するのは「変数に代入された参照（アドレス）」が固定されることだけであり、オブジェクトの中身（要素）は変更できてしまいます。

可変オブジェクトの罠

以下のコードは、final で宣言しているにもかかわらず、リストの内容が変更できてしまう例です。

Java

import java.util.ArrayList;
import java.util.List;

public class ConstantsTrap {
    // リストを定数として定義したつもり
    public static final List<String> COLOR_LIST = new ArrayList<>();

    static {
        COLOR_LIST.add("RED");
        COLOR_LIST.add("BLUE");
    }

    public static void main(String[] args) {
        // 定数なのに要素を追加できてしまう！
        COLOR_LIST.add("GREEN"); 
        System.out.println(COLOR_LIST);
    }
}

実行結果

[RED, BLUE, GREEN]

修正方法：不変リスト（Immutable List）の使用

中身も変更できない真の定数リストを作成するには、List.of()（Java 9以降）や Collections.unmodifiableList() を使用します。

Java

import java.util.List;

public class TrueConstants {
    // Java 9以降の不変リスト作成
    public static final List<String> COLORS = List.of("RED", "BLUE", "GREEN");

    public static void main(String[] args) {
        System.out.println("設定された色: " + COLORS);
        
        // 以下のコードを実行すると実行時に例外（UnsupportedOperationException）が発生します
        // COLORS.add("YELLOW"); 
    }
}

このように、参照型を定数にする場合は、中身の変更を禁止する仕組み を必ず導入するようにしましょう。

列挙型（Enum）による定数管理

関連する複数の定数をまとめる場合、static final を並べるよりも「列挙型（Enum）」を使う方が推奨されるケースが多くあります。

Enumを使用するメリット

型安全性（Type Safety）：int型の定数では、無関係な数値を代入できてしまいますが、Enumなら特定の型のみを許容できます。
コードの整理：関連する値を一つの「型」としてグループ化できます。
メソッドの定義：定数に関連する処理（ロジック）をEnum内に記述できます。

Enumの書き方例

Java

public enum DayOfWeek {
    MONDAY("月曜日"),
    TUESDAY("火曜日"),
    WEDNESDAY("水曜日"),
    THURSDAY("木曜日"),
    FRIDAY("金曜日"),
    SATURDAY("土曜日"),
    SUNDAY("日曜日");

    private final String japaneseName;

    // コンストラクタ
    DayOfWeek(String japaneseName) {
        this.japaneseName = japaneseName;
    }

    public String getJapaneseName() {
        return japaneseName;
    }
}

// 利用例
public class EnumSample {
    public static void main(String[] args) {
        DayOfWeek today = DayOfWeek.FRIDAY;
        System.out.println("今日は " + today.getJapaneseName() + " です。");
    }
}

実行結果

今日は 金曜日 です。

曜日、ステータス（未着手・進行中・完了）、権限レベルなど、「決まった選択肢の中から一つ選ぶ」 ような定数を扱う場合は、Enumの利用を第一に検討すべきです。

インターフェースでの定数定義は避けるべきか

かつてJavaの現場では、インターフェースに定数を定義し、それを各クラスで implements して利用する「インターフェース定数パターン」が使われていた時期がありました。

しかし、現代のJava開発においてこの手法は アンチパターン とされています。

なぜインターフェース定数は良くないのか

実装の詳細の漏洩: 定数を利用するためだけにインターフェースを実装すると、そのクラスの型情報に本来不要な情報が含まれてしまいます。
名前空間の汚染: サブクラスにおいて、定数名が衝突する原因になります。
バイナリ互換性の問題: 定数の値が変わった際、再コンパイルの範囲が不必要に広がることがあります。

現在では、定数は 「finalクラス（継承不可のクラス）」 に定義し、コンストラクタを private にしてインスタンス化を禁止するのがベストプラクティスです。

Java

public final class AppConstants {
    // インスタンス化を禁止
    private AppConstants() {}

    public static final String API_URL = "https://api.example.com/v1";
    public static final int TIMEOUT_MS = 5000;
}

定数を利用する際のベストプラクティス

より高品質なコードを書くために、定数運用におけるいくつかのポイントをまとめます。

1. マジックナンバーを排除する

ソースコード内に if (status == 1) のように直接数値を書くのは避けましょう。

1 が何を意味するのか、半年後の自分や他の開発者にはわかりません。

public static final int STATUS_ACTIVE = 1; と定義し、if (status == STATUS_ACTIVE) と書くことで、コードそのものがドキュメントの役割を果たします。

2. スコープを最小限にする

すべての定数を一つの GlobalConstants クラスに詰め込むのは避けましょう。

特定のロジックでのみ使用する定数は、そのクラス内に private で定義すべきです。

「影響範囲を限定する」 ことは、バグの少ないシステム開発の鉄則です。

3. static import の活用

特定のクラスで特定の定数を頻繁に使用する場合、static import を使うとコードをスッキリさせることができます。

Java

import static com.example.AppConstants.API_URL;

public class ApiClient {
    public void call() {
        // AppConstants.API_URL と書かずに直接参照できる
        System.out.println("Connecting to: " + API_URL);
    }
}

ただし、多用しすぎると「その定数がどこで定義されたものか」が分かりにくくなるため、チームの規約に従って適切に使用しましょう。