Javaのvarとは？型推論の基本と使える場所・注意点を実務解説

まず、Java 10で導入されたvarは、ローカル変数の宣言で型名を省略できる「ローカル変数型推論」です。右辺の初期化式からコンパイラが型を一意に決定し、コード量を減らしつつ表現を簡潔にできます。

しかし、varはJavaScriptのような動的型付けではありません。型はコンパイル時に確定し、以降は通常の静的型付けと同じルールで検査されます。したがって、使える場所・使えない場所、可読性への影響、チーム開発でのルールまで押さえることで、安全に使い分けられるようになります。

varでできること（型推論の仕組み）

まず、varは「型を書かない」のではなく「右辺から型が推論される」だけで、推論結果はコンパイル時に確定します。つまり、varは書き方の省略であって、Javaの静的型付けそのものは変わりません。

さらに、varはキーワードではなく「予約型名」です。そのため、既存コードで変数名やメソッド名にvarを使っていても基本的に影響はありません。一方で、クラス名・インターフェース名としてのvarは影響を受ける可能性があります。

例えば、右辺が文字列リテラルならString、整数リテラルならintといった具合に推論されます。ただし、数値はリテラルの書き方で推論型が変わるため、意図した型にしたい場合はサフィックスやキャストで右辺の型を明確にします。

var name = "Alice";   // String
var n1 = 10;           // int
var n2 = 10L;          // long
var x  = 3.14;         // double
var list = new java.util.ArrayList<String>();

一方で、実務的な利点としてリファクタリング耐性があります。右辺の戻り値型やnewするクラスを変更したときに、宣言側の型名を直し忘れる事故を減らせます。しかし、型が見えにくくなる代償もあるため、場面の選別が重要です。

varの基本的な書き方

まず、基本形はvar 変数名 = 初期化式;で、宣言と同時に初期化するのが前提です。したがって、var x;のような「宣言だけ」はできません。

さらに、varは型名の省略なので、変数名の付け方がより重要になります。例えば、var data = service.fetch();だとdataが何か分かりにくいため、var userList = ...のように役割と中身が想像できる名前にすると読みやすさが保てます。

また、学習中の方は「Javaそのものの基礎」を押さえると、varの位置づけも理解しやすくなります。あわせてJavaとは？基礎からメリット・学習の流れまで完全解説も参照すると、JDK/JVMやバージョン観点まで整理できます。

varが使える場所・使えない場所

まず、varは使えるスコープが厳密に決まっており、誤るとすぐにコンパイルエラーになります。結論として、varは「実装内部の書きやすさ」を上げるための機能で、インターフェースの明示性は守る、という思想で理解すると判断がぶれません。

varはローカル変数以外では使えない

まず、varが使えるのは、メソッド内や任意のブロック内で宣言するローカル変数です。さらに、for文のカウンタ変数、拡張forのループ変数、try-with-resourcesのリソース変数でも使えます。

一方で、クラスのフィールド、メソッドの引数、メソッドの戻り値型では使えません。これらは外部から見える契約になりやすく、型を省略するとAPIの意図が伝わりにくくなるためです。したがって、APIの境界は型を明示し、実装詳細の内部でだけ省略するのが安全です。

初期化が必要などコンパイルエラーになるケース

まず、varは必ず初期化が必要です。さらに、nullだけの代入は推論できません。また、複数同時宣言や、配列の初期化子だけの代入も制約があります。したがって、右辺で型が分かる形にするのが原則です。

// var x;                 // 初期化がないため不可
// var x = null;           // 型情報がなく不可
// var a = 1, b = 2;        // 複数同時宣言は不可
// var arr = {1, 2};        // 配列初期化子だけは不可

var ok1 = new int[]{1, 2};  // 右辺で型が分かるならOK
int startNull = 0;
String maybeNull = null;    // null開始にしたいなら型を明示

varは動的型付けではない（型はコンパイル時に決まる）

まず、varで宣言した変数も静的型付けです。宣言時点で型が確定し、後から別型を代入するとコンパイルエラーになります。したがって、varは型チェックを弱める機能ではなく、型安全性は維持されます。

var n = 10;     // int
// n = 10.5;     // doubleをintへ代入するのと同じなので不可

var s = "hi";   // String
// s = 100;      // Stringにintは代入不可

一方で、読み手が型を追いにくくなることがある、というのが実務上の論点です。したがって、型を隠すことで意図が薄れないかを基準に判断するのが現実的です。

var宣言のメリット

まず、型名が長い・ジェネリクスが複雑・右辺に型が明確に出ている場面で、varは記述量とノイズを減らします。特にジェネリクスが絡むと、左辺の型情報が長くなり、本質でない文字が増えがちです。

さらに、右辺にnewがあり型が明示されている場合は相性が良いです。したがって、処理の意図に視線が集中しやすくなります。

また、変更に強くなります。右辺の具体クラスやメソッド戻り値型を変えたとき、左辺の型名と不整合が起きにくく、修正漏れを減らせます。

var宣言のデメリット・注意点

しかし、型が見えにくくなることで誤読やレビューコストが増えることがあります。特に右辺がメソッド呼び出しだけだと、戻り値型を知らない限り判断できず、理解が止まります。

例えば、名前から型を勘違いするケースが典型です。ファイル名に見えるが実際はPath型、といったズレが起きると、バグよりも保守性の低下として効いてきます。したがって、短さより保守性を優先する判断が必要です。

varの使いどころ（可読性が上がるケース）

まず、「右辺を見れば型が分かる／推測しやすい」状況に絞ると、varは可読性を下げずに簡潔さを得られます。さらに、OpenJDKのスタイルガイドでも、推論の可読性を意識した使い分けが推奨されています。

• 右辺でインスタンス化している：var reader = new BufferedReader(...);
• リテラルで型が明確：var count = 1;、var message = "ok";
• 戻り値型が推測しやすい慣用API：例）LocalDateTime.now()

一方で、型推測に知識が必要なメソッドでは無理に使わないのが安全です。したがって、「型情報が価値になる場所では型を見せる」という基準を持つと運用が安定します。

推論される型を確認する方法

まず、varの不安は「結局何型か分からない」ことなので、型を素早く確認する実務的な手段を押さえます。したがって、varを使うなら、ツールで即確認できる状態にしておくのが現実的です。

IDEで型を表示する

まず、最も速いのはIDEの型表示です。変数にマウスを乗せる、カーソルを当てる、定義ジャンプする、といった操作で推論型が表示されます。さらに、インレイヒント（推論型の薄表示）を有効にすると、var多用時の読みにくさが大きく改善します。

コンパイラエラーや警告を活用する

一方で、型が分からないときは、型不一致エラーを手がかりにできます。ただし、エラーを出すための変更を入れるため、手元で素早く確認してすぐ戻す運用が前提です。したがって、常用は避けつつ「詰まったときの手段」として覚えておくと便利です。

静的解析ツールを利用する

さらに、大規模開発では、varの使い方を個人の好みに任せないのが重要です。例えば、複雑なメソッドチェーンの結果をvarで受けるのを禁止する、型が分かりにくい命名を禁止する、といった形でルール化できます。したがって、レビュー負荷を下げたいチームほど、静的解析で「揺れ」を減らすのが効果的です。

ラムダ式でのvar（Java 11〜）

まず、Java 11からラムダ式のパラメータにもvarが使えます。さらに、暗黙的に型付けされるラムダ式では、varを使うなら全パラメータに統一する必要があります。

特に重要なのは、ラムダ引数にアノテーションを付けたい場合です。型名を書く代わりにvarを使うことで、アノテーションと記法統一を両立できます。一方で、ラムダは短いほど読みやすいことも多いため、必要な場面に絞ると混乱しません。

java.util.function.Function<String, String> f1 = (var s) -> s.toUpperCase();

// 暗黙的型付きラムダでは、varを使うなら全引数で統一
java.util.function.BiFunction<String, String, String> f2 =
  (var a, var b) -> a + b;

また、ラムダの理解を深めたい場合は、Javaラムダ式を徹底解説｜基本構文・省略ルール・Stream連携までもあわせて読むと、文法と実務のつながりが整理しやすくなります。

try-with-resourcesとvar

まず、try-with-resourcesでもvarが使えるため、I/O周りの長い型名を省略できます。しかし、リソースの型は例外の種類や利用可能なメソッドに直結します。したがって、右辺のnewで型が明確か、リソース型が設計上の意味を持つか、という観点で判断すると安全です。

try (var in = new java.io.BufferedReader(new java.io.FileReader("input.txt"))) {
  var line = in.readLine();
  System.out.println(line);
}

大規模開発でのvar運用ルール（ベストプラクティス）

まず、チーム開発ではvarの使い方を揃えないと可読性が揺れます。したがって、利用基準・命名・レビュー観点をルール化します。

• 外部に見える境界（公開API、引数、戻り値、フィールド）は型を明示する
• 右辺がnewなどで型が明確ならvar可、推測しづらい戻り値は原則型を明示する
• varを使う場合は、変数名で役割と中身が想像できるようにする
• 長いメソッドチェーンの結果をそのままvarで受けない（中間変数で意図を分割する）

さらに、公式一次情報として、OpenJDKのLVTIスタイルガイドやOracleドキュメントをチームの共通参照にすると、判断の根拠が揃います。外部リンクとして以下も参照してください。

• OpenJDK: Local Variable Type Inference Style Guide
• Oracle Docs: Local Variable Type Inference

まとめ：Javaのvarを安全に使い分ける

まず、varはJava 10からのローカル変数型推論で、右辺から推論された型はコンパイル時に確定します。したがって、動的型付けではなく、型安全性は維持されます。

しかし、型が見えにくくなることで誤読やレビューコストが増える可能性があります。そこで、右辺を見れば型が明確な場面に絞って使い、推測が必要な場面では素直に型を明示するのが現実的です。

さらに、チーム開発ではIDE表示や静的解析も含めて運用を整えると、varのメリットを取り込みつつデメリットを抑えられます。結論として、可読性を最優先に、基準を決めて安全に使い分けましょう。