リフレクション(リフレクション)とは | 意味や読み方など丁寧でわかりやすい用語解説

リフレクションとは、プログラムの実行中に、そのプログラム自身やその構成要素（クラス、メソッド、フィールドなど）の構造や振る舞いを調べたり、操作したりする仕組みである。通常、プログラミング言語では、コードがコンパイルされる際に、呼び出すメソッドやアクセスするフィールドなどが固定される。しかし、リフレクションを利用すると、プログラムが実行されている最中に、オブジェクトの型情報を取得したり、その型が持つメソッドを動的に呼び出したり、フィールドの値を読み書きしたり、さらには新しいインスタンスを生成したりすることが可能になる。これは、まるでプログラムが自分自身の「鏡像」を見て、その内部構造を自己分析・自己操作しているようなイメージである。これにより、コードの柔軟性や汎用性が大幅に向上し、様々な高度なプログラミングテクニックを実現するための基盤となる。特に、コンパイル時にはどのようなクラスやメソッドが存在するか分からないような状況、あるいは実行時に初めてそれらを特定し、操作する必要がある場合に非常に有効な機能である。

リフレクションの具体的な機能には、大きく分けて以下のようなものがある。まず、実行中のオブジェクトのクラスやインターフェースに関する情報を取得できる。例えば、あるオブジェクトがどのようなクラスのインスタンスであるか、そのクラスがどのようなスーパークラスを継承しているか、どのようなインターフェースを実装しているかなどを知ることが可能である。次に、クラスが持つメンバー、つまりフィールド（変数）やメソッドに関する情報を取得できる。特定のクラスがどのような名前のフィールドを持ち、その型は何か、どのような名前のメソッドを持ち、どのような引数をとり、どのような戻り値を返すのかといった詳細な情報が実行時に取得できる。

これらの情報を取得するだけでなく、取得した情報に基づいて動的な操作も行える。例えば、取得したメソッド情報を元に、そのメソッドを動的に呼び出すことができる。通常、メソッド呼び出しはobject.methodName(args)のように直接記述するが、リフレクションを使えば、メソッド名を文字列として指定し、その文字列に対応するメソッドを実行時に探し出して呼び出すことが可能になる。同様に、フィールド名を文字列で指定して、そのフィールドの値を動的に読み取ったり、新しい値を設定したりすることもできる。さらに、クラスのコンストラクタ情報を使って、そのクラスの新しいインスタンスを実行時に動的に生成することも可能である。これらの機能により、コンパイル時には知り得ない、あるいは特定できないコード要素を、実行時に発見し、操作するという非常に高度なプログラミングが可能となる。

リフレクションは多岐にわたる場面で利用される。最も代表的なのが、JavaのSpring FrameworkやC#の.NETにおけるASP.NET Coreのようなフレームワーク内部である。これらのフレームワークでは、開発者が定義したクラスやメソッドを、フレームワークが実行時に自動的に検出し、連携させたり、特定のルールに基づいて処理を呼び出したりする。例えば、アノテーション（Java）や属性（C#）でマークされたメソッドを自動的に処理するような仕組みは、リフレクションなくしては実現できない。また、依存性注入（DI: Dependency Injection）コンテナもリフレクションを多用する。コンテナは、オブジェクトの生成や依存関係の解決を実行時に動的に行い、必要なオブジェクトを適切に注入するために、クラスのコンストラクタやフィールドの情報をリフレクションで取得する。

その他にも、データベースとオブジェクトのマッピングを行うORM（Object-Relational Mapping）ライブラリもリフレクションを利用して、データベースのテーブルとオブジェクトのフィールドを対応付けたり、SQLの実行結果をオブジェクトにマッピングしたりする。テストフレームワークでは、テスト対象のクラスやメソッドを動的に探し出し、実行するために利用される。デバッガや統合開発環境（IDE）も、実行中のプログラムの状態を検査したり、ステップ実行中に変数の値を表示したりする際に、内部的にリフレクションの機能を利用している場合が多い。オブジェクトの内容をシリアライズ（直列化）してファイルに保存したり、ネットワーク経由で送信したりする際にも、オブジェクトの内部構造をリフレクションで調べて必要な情報を取り出すことがある。

しかし、リフレクションにはいくつかのデメリットと注意点がある。第一に、パフォーマンスのオーバーヘッドである。リフレクションは、コンパイル時に確定する通常のメソッド呼び出しやフィールドアクセスと比較して、実行時の処理が多くなるため、一般的に性能が低下する傾向がある。特に頻繁にリフレクションを利用する箇所では、その影響が無視できない場合がある。第二に、コンパイル時チェックの恩恵を受けられない点である。リフレクションを使ったコードは、メソッド名やフィールド名を文字列で指定するため、タイプミスなどがあってもコンパイル時にはエラーにならず、実行時になって初めてエラーが発覚することが多い。これは、コードの安全性を低下させる要因となる。第三に、コードの可読性や保守性が低下する可能性がある。リフレクションを使ったコードは、何を実行しているのかが一見して分かりにくく、通常のコードパスを追うのが難しくなるため、デバッグや保守が複雑になる傾向がある。第四に、セキュリティ上のリスクである。リフレクションを使うと、通常はアクセスが制限されているプライベートなフィールドやメソッドにアクセスできてしまうことがある。悪用されると、意図しない形でプログラムの内部状態が変更されたり、セキュリティを侵害されたりする可能性がある。

これらの理由から、リフレクションは必要不可欠な場面でのみ利用するのが賢明であるとされている。設計パターンやフレームワークの内部では強力なツールとなる一方で、アプリケーションロジックの単純な部分で安易に利用することは避けるべきである。可能な限り、通常の静的な型付けによるコードを利用し、動的な操作が必要な場合に限定してリフレクションの利用を検討すべきである。

Javaではjava.lang.reflectパッケージが、C#ではSystem.Reflection名前空間がリフレクション機能を提供する。Pythonのような動的型付け言語では、元々オブジェクトが持つ属性（__dict__、getattr()、setattr()など）を使って、リフレクションに似た操作を比較的容易に行える。これらの言語や環境ごとに、リフレクションの具体的なAPIや利用方法は異なるが、その根底にある「実行時にプログラム自身を検査・操作する」という概念は共通している。