「List<String>はよく使うけれど、<?>や<T>が出てくると、とたんに難しく感じる…」
現役でJavaエンジニアとして開発に携わっている私ですが、キャリアの浅い頃はジェネリクスが苦手でした。Object型で何でもかんでも扱ってしまい、実行時エラーであるClassCastExceptionに何度も泣かされた経験があります。
しかし、ジェネリクスを正しく理解してからは、コードの安全性が劇的に向上し、バグが大幅に減少しました。コンパイルの時点でエラーを発見できるようになったからです。
この記事は、過去の私と同じように悩んでいる「Javaのジェネリクスについて知りたい方」に向けて書きました。
この記事を読めば、あなたは以下の悩みを解決できます。
- ジェネリクスがなぜ必要なのかがわかる
<T>や<?>といった記号の意味と使い分けが明確になる- 実際のコードでどのように活用すれば良いか具体的にイメージできる
Javaのジェネリクスの基本から注意点までを網羅的に解説するので、ぜひ最後まで読んで、ジェネリクスをあなたの武器にしてください。
ジェネリクスとは?

Javaにおけるジェネリクスとは、クラスやメソッドで扱うデータ型を、インスタンスを生成する時まで決めずに、パラメータとして外部から指定できるようにする仕組みです。
一言でいうと「型をパラメータ化する技術」ですね。
これだけだと難しいので、魔法のコップを例に考えてみましょう。
- 普通のコップ: 「水専用コップ」「ジュース専用コップ」のように、中に入れられるものが最初から決まっています。
- ジェネリクスなコップ: 飲み物を注ぐときに「これは水を入れるコップ」「これはジュースを入れるコップ」と決められます。一度決めると、それ以外のものは入れられません。
このように、使う直前になってから「このクラスはString型を扱います」「このメソッドはInteger型を扱います」と指定できるのが、Javaジェネリクスの大きな特徴です。
なぜジェネリクスが必要なのか
ジェネリクスが必要な理由は、主に2つあります。
ジェネリクスを使う最大のメリットは、コンパイル時に型チェックを行える点です。意図しないデータ型の混入を防ぎ、プログラムの安定性を高めます。また、Stringを扱うリストだとList<String>と書くことで、コードを読む人が一目で何を扱うものなのか理解できるようになります。
登場の背景(Java 5以前との違い)
ジェネリクスは、Java 5から導入された比較的新しい機能です。それ以前は、さまざまな型のオブジェクトを格納するためにObjectクラスが使われていました。
例えば、ArrayListにString型のデータを入れる場合、以前は以下のように書いていました。
// Java 5以前のコード
List list = new ArrayList();
list.add("こんにちは");
list.add(123); // 本来は文字列を入れたいのに、間違えて数値も入ってしまう
String message = (String) list.get(0); // キャストが必要
// String wrongData = (String) list.get(1); // ここで実行時エラー(ClassCastException)が発生するこのコードには2つの問題点があります。
そして最大の問題は、間違った型のデータを取り出してキャストしようとした場合、コンパイル時にはエラーが出ず、プログラムを実行して初めてClassCastExceptionというエラーが発生することです。
「型安全性」を確保する仕組みとは
ジェネリクスは、この問題を解決します。先ほどのコードをジェネリクスを使って書き換えてみましょう。
// ジェネリクスを使ったコード
List<String> list = new ArrayList<>();
list.add("こんにちは");
// list.add(123); // この行はコンパイルエラーになる!
String message = list.get(0); // キャストが不要List<String>と宣言することで、このリストにはString型しか追加できない、とコンパイラに伝えることができます。そのため、間違って123のようなInteger型を追加しようとすると、コンパイルの段階で「型が違いますよ」とエラーを教えてくれるのです。
これにより、実行時エラーの危険性を未然に防ぎ、プログラムの安全性が飛躍的に高まります。これが「型安全性が確保される」ということです。
ジェネリクスの基本構文

それでは、Javaジェネリクスの具体的な書き方を見ていきましょう。山括弧<>を使い、その中に「型パラメータ」を記述するのが基本です。
<T>の意味と使い方
ジェネリクスでよく見かける<T>のTは、型パラメータ(Type Parameter) と呼ばれるものです。これは、特定の型を表すのではなく、「ここには何らかの型が入りますよ」ということを示すプレースホルダーの役割を果たします。
TはTypeの頭文字で、慣習的に使われることが多いです。他にも以下のような型パラメータがよく使われます。
E: Element(コレクションの要素)K: Key(マップのキー)V: Value(マップの値)N: Number(数値型)
これらはあくまで慣習なので、MyTypeのように自分で分かりやすい名前を付けることも可能です。
クラス・メソッド・インターフェースでの使い方の違い
ジェネリクスは、クラス、メソッド、インターフェースのそれぞれで定義できます。
ジェネリクスクラス
クラス名の直後に<T>を付けて宣言します。クラス内部のフィールドやメソッドの戻り値、引数で型パラメータTを使用できます。
// Boxクラスは、Tという任意の型を扱える
class Box<T> {
private T item;
public void set(T item) {
this.item = item;
}
public T get() {
return item;
}
}
// 使い方
Box<String> stringBox = new Box<>(); // Stringを扱うBoxを生成
stringBox.set("Hello, Generics!");
String content = stringBox.get();
Box<Integer> integerBox = new Box<>(); // Integerを扱うBoxを生成
integerBox.set(100);
int number = integerBox.get();ジェネリクスメソッド
メソッドの戻り値の型の前に<T>を付けて宣言します。そのメソッド内でのみ有効な型パラメータを定義したい場合に使います。
class Util {
// Tという任意の型の配列を受け取って、その内容を表示するメソッド
public static <T> void printArray(T[] array) {
for (T element : array) {
System.out.printf("%s ", element);
}
System.out.println();
}
}
// 使い方
String[] stringArray = { "A", "B", "C" };
Integer[] integerArray = { 1, 2, 3 };
Util.printArray(stringArray); // String型で呼び出し
Util.printArray(integerArray); // Integer型で呼び出しジェネリクスインターフェース
クラスと同様に、インターフェース名の直後に<T>を付けて宣言します。このインターフェースを実装するクラスは、具体的な型を指定するか、型パラメータを引き継ぐ必要があります。
// Tという型を扱うインターフェース
interface DataProcessor<T> {
void process(T data);
}
// String型を扱うように実装するクラス
class StringDataProcessor implements DataProcessor<String> {
@Override
public void process(String data) {
System.out.println("Processing string: " + data);
}
}複数の型パラメータを使う場合
型パラメータは、カンマで区切って複数指定することも可能です。Map<K, V>がその代表例ですね。
// KeyとValue、2つの型を扱うPairクラス
class Pair<K, V> {
private K key;
private V value;
public Pair(K key, V value) {
this.key = key;
this.value = value;
}
public K getKey() { return key; }
public V getValue() { return value; }
}
// 使い方
Pair<String, Integer> userAge = new Pair<>("Yamada", 30);
String name = userAge.getKey();
Integer age = userAge.getValue();ワイルドカード(?)の使い方

ワイルドカード<?>は、「未知の型」を表すために使います。主にメソッドの引数などで、より柔軟にさまざまなジェネリクス型を受け入れたい場合に使用します。<T>が型の「宣言」だとしたら、<?>は型の「参照」に近いイメージです。
? extendsと ? superの違い
ワイルドカードには、境界を設ける「境界ワイルドカード」があります。これが少しややこしい部分です。
上限境界ワイルドカード (? extends T)
<? extends Number>と書いた場合、「Numberクラス、またはNumberクラスを継承した何らかのクラス」という意味になります。IntegerやDoubleはNumberを継承しているので、この型に当てはまります。
このワイルドカードを使ったリストからは、要素の読み取りはできますが、新たな要素の追加(null以外)はできません。なぜなら、List<? extends Number>が具体的にList<Integer>なのかList<Double>なのかコンパイラには判断できず、安全に追加できる型が特定できないからです。
public void processNumbers(List<? extends Number> list) {
for (Number num : list) { // 読み取りはOK(Numberとして扱える)
System.out.println(num.doubleValue());
}
// list.add(123); // コンパイルエラー!
}下限境界ワイルドカード (? super T)
<? super Integer>と書いた場合、「Integerクラス、またはIntegerクラスの親クラス」という意味になります。Integer、Number、Objectが当てはまります。
こちらはextendsとは逆に、要素の追加はできますが、読み取りには注意が必要です。Integer型とその親クラスなら安全に追加できることが保証されますが、取り出した要素が具体的にどの型なのかはObject型であることしか保証されません。
public void addIntegers(List<? super Integer> list) {
list.add(10); // 書き込みはOK(Integerは安全に追加できる)
list.add(20);
// Object obj = list.get(0); // 読み取りはObject型としてしか保証されない
}PECS原則(Producer Extends, Consumer Super)とは
extendsとsuperの使い分けには、PECS原則という有名な経験則があります。
- Producer Extends: ジェネリクス構造が値を生産(提供)する(=読み取りがメイン)場合は、
extendsを使う。 - Consumer Super: ジェネリクス構造が値を消費する(=書き込みがメイン)場合は、
superを使う。
例えば、あるコレクションから別のコレクションへ要素をコピーするメソッドを考えてみましょう。
public static <T> void copy(List<? super T> dest, List<? extends T> src) {
for (T elem : src) { // srcはProducer(要素を提供する)なので extends
dest.add(elem); // destはConsumer(要素を消費する)なので super
}
}この原則を覚えておくと、どちらを使うべきか迷ったときの助けになります。
ワイルドカードの使用例と注意点
ワイルドカードは、APIをより柔軟にするために非常に役立ちます。例えば、数値のリストの合計値を計算するメソッドを考えます。
// ジェネリクスだけだと、Integerのリストしか受け取れない
public double sum(List<Integer> list) { /* ... */ }
// ワイルドカードを使えば、IntegerやDoubleのリストも受け取れる
public double sumWithWildcard(List<? extends Number> list) {
double total = 0;
for (Number num : list) {
total += num.doubleValue();
}
return total;
}注意点として、ワイルドカード<?>は、主にメソッドの引数のように「型を参照する」場面で使います。new ArrayList<?>()のように、インスタンス生成時に使うことはできません。
実際のコード例で学ぶジェネリクス

理論だけでなく、実際のコードでjavaジェネリクスがどのように役立つかを見ていきましょう。
リストで型を固定する例(List<String>など)
これは最も身近なジェネリクスの使用例です。String型のリストを安全に操作するコードです。
List<String> names = new ArrayList<>();
// 安全な追加
names.add("Alice");
names.add("Bob");
// names.add(100); // コンパイルエラー
// 安全な取得(キャスト不要)
for (String name : names) {
System.out.println(name.toUpperCase());
}ジェネリクスのおかげで、namesリストにはStringしか入っていないことが保証され、安心してtoUpperCase()のようなStringのメソッドを呼び出せます。
ジェネリクスメソッドを定義する例
2つの値を交換する、古典的なswapメソッドをジェネリクスで定義してみましょう。
public class Swapper {
// 任意の参照型の2つの値を交換するジェネリクスメソッド
public static <T> void swap(T[] array, int i, int j) {
T temp = array[i];
array[i] = array[j];
array[j] = temp;
}
}
// 使い方
String[] languages = {"Java", "Python", "Go"};
Swapper.swap(languages, 0, 2);
// languagesは {"Go", "Python", "Java"} になる
Integer[] numbers = {10, 20, 30};
Swapper.swap(numbers, 0, 1);
// numbersは {20, 10, 30} になるこのswapメソッドは、Stringの配列でもIntegerの配列でも、どんな参照型の配列でも再利用できます。これがジェネリクスの力です。
バウンディッド型パラメータを使った応用例
「境界付き型パラメータ」を使うと、型パラメータに制約を加えられます。例えば、「比較可能(Comparable)な要素の中から最大のものを探す」メソッドを考えてみましょう。
// TはComparableインターフェースを実装した型でなければならない、という制約
public static <T extends Comparable<T>> T findMax(T[] array) {
if (array == null || array.length == 0) {
return null;
}
T max = array[0];
for (int i = 1; i < array.length; i++) {
if (array[i].compareTo(max) > 0) {
max = array[i];
}
}
return max;
}
// 使い方
Integer[] nums = {34, 67, 23, 89, 54};
System.out.println(findMax(nums)); // 89
String[] words = {"apple", "orange", "banana"};
System.out.println(findMax(words)); // "orange"T extends Comparable<T>という制約を設けることで、compareToメソッドを持つ型しかこのメソッドに渡せないようにコンパイル時にチェックできます。
ジェネリクスの制限と注意点

Javaジェネリクスは万能ではありません。いくつかの重要な制限と、その背景にある仕組みを理解しておく必要があります。
プリミティブ型(intなど)は使えない理由
ジェネリクスの型パラメータには、intやdoubleのようなプリミティブ型を指定できません。
// List<int> list = new ArrayList<>(); // これはコンパイルエラーこれは、ジェネリクスが内部的にObject型として扱われる仕組み(後述の型消去)に基づいているためです。Objectはすべてのクラスの親ですが、プリミティブ型はオブジェクトではないので扱えません。
この問題を解決するためには、ラッパークラス(Integer, Doubleなど)を使用します。
List<Integer> list = new ArrayList<>(); // これはOK型消去(Type Erasure)とは何か
Javaジェネリクスには「型消去」という重要な仕組みがあります。これは、コンパイル時にジェネリクスの型情報が消去され、実行時にはその情報が残らないというものです。
例えば、List<String>はコンパイルされた後、Javaのバイトコード上では単なるListとして扱われます。型パラメータはObject(または境界で指定した型)に置き換えられます。
// コンパイル前
List<String> list = new ArrayList<>();
list.add("test");
String s = list.get(0);
// コンパイル後(型消去によって内部的にこう解釈される)
List list = new ArrayList();
list.add("test");
String s = (String) list.get(0); // コンパイラが自動でキャストを挿入型消去は、ジェネリクスが導入される前の古いJavaコードとの互換性を保つために採用されました。
実行時に型情報が失われることの影響
型消去があるため、実行時にはジェネリクスの型情報を利用できません。これにはいくつかの影響があります。
instanceofでの型チェックができないList<String> list = new ArrayList<>(); // if (list instanceof List<String>) { ... } // コンパイルエラー実行時にはList<String>かList<Integer>かの区別がつかないため、このようなチェックはできません。- 型パラメータでのインスタンス生成ができない
class MyClass<T> { // T item = new T(); // コンパイルエラー }実行時にTが何の型か分からないため、インスタンスを生成することは不可能です。
よくあるエラーと対処法

Javaジェネリクスを使っていると、いくつか特有のエラーや警告に遭遇します。ここでは代表的なものとその対処法を紹介します。
型推論がうまく働かないケース
Java 7から導入されたダイヤモンド演算子<>のおかげで、多くの場合、型パラメータを省略できます。
Map<String, List<String>> map = new HashMap<>(); // 型推論が働くしかし、メソッドの引数などで複雑なジェネリクスを使う場合、コンパイラが型を正しく推論できないことがあります。その場合は、明示的に型を指定する必要があります。
// 例: Collections.emptyList() は型を推論できない場合がある
List<String> list = Collections.emptyList();
// 明示的に型を指定する
List<String> list = Collections.<String>emptyList();「Unchecked cast」警告の意味と回避策
ジェネリクスを使っていない古いコードと連携する際に、「未検査キャスト」の警告が出ることがあります。
List names = new ArrayList();
names.add("Taro");
List<String> genericNames = (List<String>) names; // ここで警告が出るこれは、「namesが本当にStringのリストであるか実行時に保証できませんよ」というコンパイラからの親切な警告です。
このコードが安全であると確信できる場合は、@SuppressWarnings("unchecked")アノテーションを付けて警告を抑制できます。ただし、これは問題の先送りに過ぎない可能性もあるため、使用は慎重に行うべきです。
@SuppressWarnings("unchecked")
List<String> genericNames = (List<String>) names; // 警告が抑制されるジェネリクスと配列を一緒に使うときの注意点
ジェネリクスと配列は相性があまり良くありません。例えば、ジェネリックな配列を作成することはできません。
// T[] array = new T[10]; // コンパイルエラーこれは型消去が原因で、実行時に安全な配列を作成できないためです。このような場合は、ArrayListのようなコレクションを使うのが一般的です。
まとめ|ジェネリクスを使いこなすポイント
この記事では、Javaジェネリクスの基本から応用、注意点までを解説しました。最後に、ジェネリクスを効果的に使いこなすための3つのポイントをまとめます。
型安全性を守る
ジェネリクスの最大の目的は型安全性です。面倒でも型をきちんと指定することで、コンパイル時に多くのバグを防げます。実行時エラーを減らし、安定したアプリケーションを作るための第一歩です。
共通化・再利用性を意識する
ジェネリクスメソッドやジェネリクスクラスを作ることで、特定の型に依存しない、再利用性の高いコードを書けます。同じような処理を異なる型で行っている場合は、ジェネリクスで共通化できないか考えてみましょう。
無理に使わない勇気も大事
ジェネリクスは強力ですが、乱用するとかえってコードが複雑になることもあります。特にワイルドカードの多用は、可読性を損なう原因になりかねません。本当にジェネリクスが必要な場面かを見極め、シンプルに書けるのであれば無理に使わない判断も重要です。
Javaのジェネリクスは、最初は少しとっつきにくいかもしれませんが、一度理解すればあなたのコードをより安全で、より洗練されたものにしてくれる強力な味方です。