Scalaで実行中のオブジェクトやコードの挙動を書き換える方法とは？安全なリフレクションの使い方を徹底解説

Scalaでは、実行中のオブジェクトやクラスの構造を調べたり、通常のコードでは直接触れにくいメンバーへアクセスしたりできます。
こうした仕組みを支えるのがリフレクションです。
デバッグ、フレームワーク開発、シリアライザー、テスト用モック、プラグイン機構などでは強力な選択肢になりますが、使い方を誤ると、型安全性の低下や実行時エラー、保守性の悪化を招きます。

「実行中のオブジェクトの値を書き換えたい」「特定のメソッドを動的に呼び出したい」「クラスの情報を取得して処理を切り替えたい」
このような要件に対して、Scalaではどこまで安全に対応できるのでしょうか。
JavaのリフレクションAPI、Scala 2のランタイムリフレクション、Scala 3のより明示的な仕組みには、それぞれ得意分野と注意点があります。

本記事では、リフレクションの基本概念から、フィールドやメソッドの取得、アクセス制御を越えた操作、実行時におけるオブジェクトの状態変更までを整理して解説します。
単に「動くコード」を紹介するのではなく、次の観点を重視します。

コンパイル時の型安全性が失われる箇所
例外やバージョン差異が発生しやすい箇所
可視性、イミュータブル設計、並行処理への影響
リフレクションを使わずに解決できる代替設計

リフレクションは、通常の設計を置き換える万能の手段ではありません。
しかし、適切な境界を設け、入力を検証し、失敗を明示的に扱えば、動的な処理を実現するための有効な道具になります。
Scalaで実行中のコードやオブジェクトの挙動を書き換えるとき、何ができて、何をすべきではないのか。
その判断基準を、具体例とともに確認していきます。

Scalaのリフレクションとは？実行中のオブジェクトを動的に操作する仕組み
Scalaでリフレクションを使うメリットと注意点
JavaリフレクションAPIとScalaのリフレクションの違い
Scalaでクラスやオブジェクトの情報を取得する方法
Scalaのリフレクションでフィールドやプロパティを読み取る方法
Scalaで実行中のオブジェクトの値を書き換える方法
privateメンバーやアクセス制御を越えて操作する際のリスク
Scalaでメソッドを動的に呼び出す方法と引数の扱い
Scala 2とScala 3におけるリフレクションの違い
安全なリフレクション実装のための設計と例外処理
リフレクションを使わずに解決するScalaの設計パターン
Scalaのリフレクションを安全に使うためのまとめ

Scalaのリフレクションとは？実行中のオブジェクトを動的に操作する仕組み

Scalaのリフレクションとは、プログラムの実行中にクラスや型、メソッド、フィールドなどの情報を調べ、それらを通常の静的なコードとは異なる形で動的に扱う仕組みです。
一般的なScalaプログラムでは、コンパイラーが型を検査し、呼び出すメソッドや参照するメンバーをあらかじめ決定します。
一方、リフレクションを使うと、実行時に得られた型情報や名前を手がかりにして、オブジェクトを生成したり、メンバーへアクセスしたり、メソッドを呼び出したりできます。

たとえば、設定ファイルに書かれたクラス名から実装クラスを生成するプラグイン機構、複数のデータ型を共通形式へ変換するシリアライザー、テスト対象の内部状態を確認するデバッグツールなどが代表例です。
コンパイル時点では具体的なクラスやメソッドが決まっていなくても、実行時に名前や型を解決して処理できる点が特徴です。
Scala公式ドキュメントでも、ランタイムリフレクションは型の検査、オブジェクトの生成、メンバーへのアクセスや呼び出しなどに利用できる仕組みとして説明されています。
citeturn0search0。

ただし、「動的に操作できる」という説明は、「どのようなコードでも安全に書き換えられる」という意味ではありません。
リフレクションが主に扱うのは、実行中のオブジェクトが保持している状態や、呼び出し可能なメンバーの情報です。
すでにコンパイルされ、実行されているメソッドの命令列そのものを、通常のScalaリフレクションだけで自由に置き換える機能ではありません。

この違いを理解しておくことが重要です。
たとえば、あるオブジェクトのフィールド値を変更する処理と、メソッドの本体を別の実装へ差し替える処理は、見た目にはどちらも「実行中の挙動を変える」操作に見えます。
しかし、前者はJVMのフィールドやScalaのメンバーを反射的に取得して変更する処理であり、後者はクラスローダー、プロキシ、バイトコード変換、エージェントなど、別の仕組みが関係します。
リフレクションの適用範囲を混同すると、実現できない要件に対して複雑で不安定な実装を選びかねません。

Scalaでリフレクションを考えるときは、まず次の三つを区別すると整理しやすくなります。

コンパイル時リフレクションは、マクロなどでコンパイル中の型や構文木を分析・生成する仕組みです
ランタイムリフレクションは、実行中に型やオブジェクトの構造を調べ、インスタンス生成やメンバー呼び出しを行う仕組みです
JVMリフレクションは、java.lang.reflectを通じてクラス、フィールド、コンストラクター、メソッドを扱う仕組みです

Scala 2では、scala.reflect.runtime.universeを利用するランタイムリフレクションが提供され、Scalaの型やジェネリック型を含む情報を扱うためのAPIが用意されていました。
ランタイムリフレクションの入口として、型やシンボルを表す情報と、実際のオブジェクトを結び付けるミラーという概念が使われます。
これにより、単なるJavaのクラス情報だけでなく、Scala側の型表現やメンバー情報を調べられます。
citeturn0search0。

一方、Scala 3のリフレクションは、主にクォートやマクロの文脈でTyped ASTを分析・構築するための仕組みとして位置付けられています。
Quotesからreflect APIへアクセスし、構文木、シンボル、型表現などを扱います。
これはコンパイル時メタプログラミングに強い仕組みですが、Scala 2のランタイムリフレクションをそのまま置き換えるものではありません。
Scala 3で実行時にクラス名から任意のScalaオブジェクトを調べる設計を行う場合は、Javaリフレクション、明示的な登録表、型クラス、外部ライブラリなどを検討する必要があります。
citeturn0search1turn0search2。

また、JVM上ではジェネリック型の情報が実行時に消去される、いわゆる型消去にも注意が必要です。
コンパイル時にはList[String]とList[Int]を区別できても、実行時に単純なクラス情報だけを調べると、どちらもListとして見える場合があります。
Scala 2には、コンパイル時の型情報を実行時へ持ち運ぶためのTypeTagや、消去後のクラス情報を扱うClassTagがありました。
両者は保持する情報量が異なるため、リフレクションでジェネリック型を扱うときは、必要な情報の粒度を先に決めることが大切です。
citeturn0search2。

リフレクションの処理では、名前のスペルミス、想定外の可視性、引数型の不一致、存在しないコンストラクター、クラスローダーの違いなどが、コンパイルエラーではなく実行時エラーとして現れます。
さらに、privateメンバーへのアクセスや不変オブジェクトの内部状態の変更は、カプセル化や設計上の前提を壊す可能性があります。
したがって、リフレクションを使う場合は、入力されたクラス名やメソッド名を無条件に信頼せず、許可された型や操作だけを明示的に検証する設計が必要です。

実務では、リフレクションをアプリケーション全体へ広げるよりも、動的な境界を限定する方法が現実的です。
たとえば、外部設定から読み込めるクラスをホワイトリストで管理し、リフレクションを呼び出す処理を一つのアダプターに閉じ込めます。
取得結果はOptionやEitherで返し、失敗理由を呼び出し側が扱えるようにすれば、動的処理による不確実性を局所化できます。
通常のビジネスロジックでは、インターフェース、型クラス、関数の注入、代数的データ型などを優先する方が、コンパイル時の検査を活用しやすくなります。

つまり、Scalaのリフレクションは、実行中のプログラムを無制限に改造する機能ではありません。
実行時に型やメンバーの情報を取得し、あらかじめ想定した範囲でオブジェクトの生成や状態の参照、メソッドの呼び出しを動的に行うための仕組みです。
何を調べるのか、どこまで変更を許可するのか、失敗時にどう復旧するのかを設計したうえで使うことが、安全なリフレクションの第一歩になります。

Scalaでリフレクションを使うメリットと注意点

Scalaのリフレクションには、通常の静的なコードだけでは扱いにくい処理を、実行時またはコンパイル時に柔軟に実現できるというメリットがあります。
クラス名やメソッド名が実行時まで決まらない場合でも、型やメンバーの情報を調べて処理を組み立てられるため、汎用的なライブラリやフレームワークの基盤として役立ちます。
特に、アプリケーション本体が利用者の拡張コードや設定ファイルを受け入れる設計では、事前にすべての具象クラスを直接参照せずに動作させられる点が重要です。

代表的なメリットは、次のとおりです。

実行時にクラスやオブジェクトの型情報を調べられます
クラス名からインスタンスを生成する仕組みを作れます
メソッドやフィールドを名前で検索し、共通的な処理へ組み込めます
シリアライズ、依存性注入、テスト支援、プラグイン機構などの汎用機能を実装できます
コンパイル時リフレクションやマクロと組み合わせれば、定型コードの自動生成も可能です

たとえば、プラグインを追加するたびにアプリケーション本体へ条件分岐を追加する設計では、拡張対象が増えるほどコードの依存関係が複雑になります。
そこで、共通インターフェースを実装したクラスだけを許可し、設定に記述されたクラス名から生成する方式を採用すれば、呼び出し側の変更を抑えられます。
利用可能なクラスを明示的に登録し、生成後に期待するインターフェースへ適合するかを確認すれば、動的な柔軟性と最低限の安全性を両立できます。

また、リフレクションはフレームワークのように「利用者が書いたコードを、フレームワーク側が一律に扱う」場面で特に効果を発揮します。
すべてのデータ型について個別の変換コードを書く代わりに、フィールドの名前や型を調べて共通の変換処理へ渡す、といった設計です。
Scala 3では、inline、マクロ、クォート、TASTyリフレクションなど、コンパイル時にコードを分析・生成するための仕組みも用意されています。
公式ドキュメントでは、Scala 3のリフレクションAPIはTyped ASTを詳しく調べ、コード生成や静的な分析に利用できる仕組みとして説明されています。
citeturn1search0turn1search2。

しかし、リフレクションには明確な代償があります。
最大の問題は、コンパイラーが通常検出してくれる誤りの一部が、実行時まで発見できなくなることです。
メソッド名を文字列で指定した場合、その名前が間違っていてもコンパイルは成功します。
実行時に対象のメソッドが見つからなければ、例外が発生して初めて問題が判明します。
引数の数や型が合わない場合、コンストラクターが存在しない場合、クラスがクラスパスに存在しない場合も同様です。

さらに、リフレクションでは次のような問題が発生しやすくなります。

コンパイル時に検証できないため、テストされていない経路で障害が発生します
文字列による名前指定が増えると、リファクタリングツールの恩恵を受けにくくなります
privateメンバーへのアクセスは、カプセル化や不変性という設計上の前提を壊します
JVMやScalaのバージョン、コンパイラー設定、クラスローダーの違いに影響されます
呼び出し処理や型変換のコストにより、直接呼び出すコードより遅くなる場合があります
何を呼び出すかがコードから読み取りにくく、保守やレビューの負担が増えます

とりわけ注意したいのが、リフレクションによる状態変更と並行処理の組み合わせです。
実行中のオブジェクトのフィールドを書き換える処理は、通常のsetterやコンストラクターを通らないため、値の検証や不変条件の維持をすり抜ける可能性があります。
そのオブジェクトを複数のスレッドが共有している場合、あるスレッドが変更途中の状態を読み取ったり、変更が期待どおりに可視化されなかったりする危険もあります。
Scala 2の公式ドキュメントでも、ランタイムリフレクションはスレッドやアクターと組み合わせる場合に注意が必要であり、スレッドセーフではない状況があると説明されています。
citeturn1search3。

安全に使うには、リフレクションの範囲を限定することが基本です。
外部入力から任意のクラス名やメソッド名を受け取り、そのまま実行する設計は避けてください。
対象をホワイトリストで管理し、許可する操作、引数の型、戻り値の型を検証します。
失敗し得る処理は例外だけに依存せず、EitherやOptionなどで結果を表現すると、呼び出し側が異常系を意識しやすくなります。
ログにはクラス名やメソッド名を残しつつ、機密情報や不要な引数値を出力しない配慮も必要です。

リフレクションを採用する前に、型クラス、関数の注入、明示的なファクトリ、パターンマッチ、登録表などで解決できないかを検討することも大切です。
これらの方法なら、依存関係や利用可能な操作がコード上で明確になり、コンパイラーの型検査を活用できます。
特に、実行時の柔軟性が不要で、コンパイル時に対象の型が分かっているなら、Scala 3のinlineや導出、マクロによるコード生成の方が適切な場合があります。
コンパイル時に型を検証して生成されたコードは、実行時リフレクションよりも予測しやすく、性能面でも有利になりやすい設計です。
citeturn1search1turn1search14。

判断の基準は、「リフレクションでなければ実現できないか」だけではありません。
動的性、実行時コスト、型安全性、保守性、障害時の復旧方法を総合的に評価します。
たとえば、プラグインの発見や外部ライブラリとの接続部分ではリフレクションを許容し、その結果を型付きのアダプターへ変換した後は通常のScalaコードで処理する方法が有効です。
動的な処理をシステムの境界に閉じ込める設計です。

リフレクションは、使うこと自体が悪い技術ではありません。
問題になるのは、型安全性を失う範囲を把握しないまま、アプリケーションの中心ロジックへ広げてしまうことです。
利用目的を明確にし、対象を制限し、例外とバージョン差異をテストし、代替手段と比較する。
この手順を守れば、Scalaのリフレクションは、汎用性が求められる場面で有効な道具になります。

JavaリフレクションAPIとScalaのリフレクションの違い

Scalaのリフレクションを理解するには、まずJVM標準のJavaリフレクションAPIとの関係を整理する必要があります。
ScalaはJVM上で動作するため、Javaのクラス、メソッド、フィールド、コンストラクターを基本的に利用できます。
そのため、Scalaからjava.lang.reflectを呼び出して実行時のクラス情報を調べることも可能です。
一方で、ScalaにはScala固有の型表現や構文、シングルトンオブジェクト、型パラメーターなどを扱うための独自のリフレクション機構も存在します。
両者は重なる部分を持ちながら、見ている対象と得意な処理が異なります。

JavaリフレクションAPIの中心となるのは、Class、Field、Method、Constructorなどの型です。
ロード済みクラスを表すClassからメンバーを検索し、フィールドの値を取得・設定したり、メソッドを呼び出したり、コンストラクターからインスタンスを生成したりします。
Javaの公式APIでも、リフレクションはロードされたクラスのフィールド、メソッド、コンストラクターに関する情報を取得し、それらを通じて対応するオブジェクトを操作する仕組みと説明されています。
操作はカプセル化やセキュリティ上の制約を受けるため、常に任意の内部実装へアクセスできるわけではありません。
citeturn2search2turn2search3。

Javaリフレクションの特徴は、JVM上の実体に直接近いことです。
Javaクラスとしてコンパイルされた構造を対象にするため、Javaで作られたライブラリや標準APIと連携しやすく、Scalaからも比較的安定して利用できます。
特に、外部ライブラリがJavaの型を返す場合や、フレームワークがJavaのアノテーションを基準に動作する場合は、Javaリフレクションを使う方が自然です。

一方、Scala 2のランタイムリフレクションは、JavaのClassだけでは表現しにくいScala固有の情報を扱えるように設計されています。
scala.reflect.runtime.universeを入口として、型、シンボル、メンバー、モジュールなどをScala側の概念として取得します。
さらに、クラスローダーとScalaのシンボル情報を結び付けるランタイムミラーを利用し、インスタンスミラー、メソッドミラー、フィールドミラー、モジュールミラーなどを通じて反射的な操作を行います。
ScalaのAPIドキュメントでも、ランタイムミラーはクラスローダーを使ってScalaのリフレクション情報とJVMクラスを結び付け、フィールドの取得・設定やメソッド呼び出しを可能にすると説明されています。
citeturn2search0turn2search4。

両者の違いを整理すると、次のようになります。

観点	JavaリフレクションAPI	Scalaのリフレクション
主な対象	JVM上のクラス、フィールド、メソッド、コンストラクター	Scalaの型、シンボル、モジュール、構文や型情報
主な入口	`Class`と`java.lang.reflect`	Scala 2の`universe`やランタイムミラー、Scala 3の`Quotes.reflect`
得意な用途	Javaライブラリ連携、汎用的な実行時操作	Scala固有の型解析、マクロ、コード生成、Scalaオブジェクトの扱い
情報の性質	実行時にJVMへロードされた構造	実行時情報またはコンパイル時のScalaプログラム構造
バージョンの注意	JDKの仕様やモジュール境界の影響	Scala 2とScala 3でAPIや思想が大きく異なる

ScalaからJavaリフレクションを使う場合、クラスの取得やメソッド検索は比較的単純です。
実行時にクラス名を読み込み、指定した名前と引数型に一致するメソッドを探します。
その後、取得したMethodを対象オブジェクトへ適用します。
ただし、Scalaのメソッドはコンパイル後にJavaから見える形へ変換されるため、ソースコード上の見た目とJVM上のシグネチャーが一致しない場合があります。
デフォルト引数、演算子記法、可変長引数、暗黙の引数、コンパニオンオブジェクトなどが関係すると、Javaリフレクションから見えるメソッド名や引数構成を正確に把握しなければなりません。

たとえば、Scalaのケースクラスやコンパニオンオブジェクトは、Scala開発者にとっては一つのまとまりに見えます。
しかしJVM上では、クラス本体とシングルトンオブジェクトが異なる構造として表現されます。
JavaリフレクションだけでScalaのコンパニオンオブジェクトを自然に扱おうとすると、生成されたクラス名や静的フィールドなど、実装に依存した知識が必要になることがあります。
Scala 2のリフレクションでは、モジュールというScala固有の概念を使って、このようなシングルトンオブジェクトを扱いやすくできます。

ただし、Scala 2のランタイムリフレクションは、Scala 3へそのまま移行できるAPIではありません。
Scala 3では、主にマクロやクォート式の中で、コンパイル時のTyped ASTを分析・生成するためのリフレクションが中心です。
Quotesから取得したリフレクションAPIを通じて、シンボルや型、メソッド、構文木を調べます。
Scala 3のメタプログラミングは、inlineやマクロなどを組み合わせ、コンパイル時に処理を確定させる方向へ整理されています。
公式の移行ガイドでも、Scala 3ではより原則的で安定性を意識したメタプログラミングの方式が導入されたと説明されています。
citeturn1search0turn1search1。

ここで重要なのは、「Scalaのリフレクション」という言葉が、実行時操作とコンパイル時メタプログラミングの両方を指し得る点です。
実行中のオブジェクトを調べたいなら、JavaリフレクションやScala 2のランタイムリフレクション、あるいは専用ライブラリを検討します。
コンパイル中に型を分析してコードを生成したいなら、Scala 3のQuotes.reflectやマクロを検討します。
目的が違うのに同じAPIを探し続けると、設計判断を誤ります。

実務上の選択基準は明確です。
Javaクラスのフィールドやメソッドを単純に操作するなら、Javaリフレクションで十分な場合があります。
Scala 2の型情報、モジュール、シンボルを扱う必要があるなら、Scala 2のランタイムリフレクションが候補になります。
Scala 3でコンパイル時に型を解析し、定型コードを生成するなら、Scala 3のメタプログラミング機構を優先します。
実行時に柔軟性が必要ないのにランタイムリフレクションを使うと、型安全性と保守性を不必要に失うためです。

結局のところ、JavaリフレクションはJVMのクラス構造を直接扱う汎用的な低レイヤーAPIであり、ScalaのリフレクションはScalaの型やプログラム構造をより深く扱うための仕組みです。
ScalaコードからJavaリフレクションを利用することは可能ですが、Scala固有の機能まで正確に扱えるとは限りません。
対象がJVMの実体なのか、Scalaの型表現なのか、コンパイル時の構文木なのかを切り分けることが、適切なAPIを選ぶ第一歩になります。

Scalaでクラスやオブジェクトの情報を取得する方法

Scalaでリフレクションを使う第一歩は、対象がどのような型で、どのクラスローダーから読み込まれ、どのメンバーを公開しているのかを確認することです。
実行時のオブジェクトからクラス情報を取得するだけなら、JVM標準のgetClassを使う方法が最も簡単です。
取得したClassオブジェクトから、完全修飾クラス名、単純名、スーパークラス、実装インターフェース、宣言されたフィールドやメソッドなどを調べられます。

たとえば、実行中の値がどの具象クラスのインスタンスなのかを確認したい場合、静的な変数の型ではなく、実際のオブジェクトが持つクラス情報を取得します。
変数がインターフェースや抽象クラスとして宣言されていても、getClassから得られるのは実際に生成された具象クラスです。
依存性注入やプラグイン機構のデバッグでは、この違いが重要になります。

val value: Any = "Scala"
val runtimeClass = value.getClass

println(runtimeClass.getName)
println(runtimeClass.getSuperclass)

ただし、getClassから得られる情報は、基本的にJVMのクラス構造です。
Scalaのソースコードに書かれた型エイリアス、型パラメーター、コンパニオンオブジェクト、暗黙の変換などが、そのまま同じ形で見えるとは限りません。
Scalaの抽象的な型表現を調べたい場合は、Javaリフレクションだけでなく、Scalaの型情報を扱う仕組みが必要です。

JavaリフレクションAPIを使う場合、クラスのメンバーを取得するためにgetDeclaredFields、getDeclaredMethods、getDeclaredConstructorsなどを利用します。
getDeclaredMethodsは対象クラス自身が宣言したメソッドを取得しますが、継承したメソッドは含みません。
一方、getMethodsはpublicメソッドを対象とし、継承されたpublicメソッドも含みます。
フィールドについても、getDeclaredFieldsとgetFieldsには同様の違いがあります。
OracleのAPI仕様でも、宣言されたメンバーと継承されたメンバー、public以外の可視性を区別して説明されています。
citeturn3search0turn3search2。

この違いを意識せずにメンバー検索を行うと、「存在するはずのメソッドが見つからない」という問題が起きます。
親クラスから継承したメソッドを探すならgetMethodsやスーパークラスの走査が候補になります。
反対に、対象クラスの内部で宣言されたprivateメソッドまで調査したいならgetDeclaredMethodsを使います。
ただし、privateメンバーを見つけられることと、正当にアクセスしてよいことは別問題です。
可視性を越えた操作は、カプセル化を壊し、JDKのモジュール境界や実行環境の設定によって失敗する可能性があります。

クラスの構造を一覧表示する用途では、メンバーの名前だけでなく、修飾子、戻り値、引数型、宣言元クラスも確認すると有用です。
メソッド名だけで検索すると、オーバーロードされた複数のメソッドを区別できないためです。
Scalaのソース上では同じ名前のメソッドでも、引数の型や個数が異なる場合があります。
呼び出し対象を選ぶときは、名前、引数の個数、引数の実行時クラス、必要に応じて戻り値の型を組み合わせて検証する必要があります。

Scala 2でScala固有の型情報を取得する場合は、scala.reflect.runtime.universeを使う方法があります。
代表的な入口がtypeOfとruntimeMirrorです。
typeOfはコンパイル時に分かっている型をScalaのリフレクション上の型表現として取得し、runtimeMirrorはクラスローダーを通じて実行時のクラスやオブジェクトとScalaのシンボル情報を結び付けます。
ScalaのAPIには、クラスやトレイトの定義を表すClassSymbolなどの型が用意されています。
citeturn3search3turn2search0。

この方法を使うと、単なるJavaのクラス名だけではなく、Scalaの型引数、親クラス、基底型、メンバーシンボルなどを調べられます。
たとえば、List[Int]のような型について、型コンストラクターと型引数を区別して扱いたい場合に、Scala側の型表現が役立ちます。
ただし、実行時には型消去の影響があるため、すべてのジェネリック型情報が自動的に保持されるわけではありません。
必要な型情報を実行時まで残したい場合は、TypeTagやClassTagなどの仕組みを要件に応じて検討します。

Scalaのシングルトンオブジェクトを調べる場合も注意が必要です。
objectはクラスのインスタンスを一つだけ作るというScalaの抽象ですが、JVM上では通常のクラスとは異なる形で表現されます。
Javaリフレクションで単純にクラスを探すと、ソースコード上で意図したオブジェクトではなく、コンパイラーが生成した実装上のクラスを扱うことがあります。
Scala 2のリフレクションでは、モジュールシンボルやモジュールミラーを利用して、Scalaのシングルトンオブジェクトを概念に沿って取得できます。

一方、Scala 3でリフレクションを使う場合は、目的をより明確に分ける必要があります。
Scala 3のQuotes.reflectは、主にマクロやクォート式の中で、コンパイル時のTyped AST、シンボル、型表現を分析・生成するためのAPIです。
実行中の任意のオブジェクトをScala 2と同じ方法で調査するためのAPIではありません。
実行時にクラス情報を取得する用途では、Javaリフレクション、明示的な登録機構、型クラス、ライブラリ固有の導出機能などを選ぶことになります。
Scala 3のリフレクションは、プログラム構造をコンパイル時に扱うための仕組みとして整理されています。
citeturn0search1turn0search6。

実務でクラスやオブジェクトの情報を取得するときは、次の順序で考えると安全です。

取得したい情報がJVMの実行時情報なのか、Scalaのコンパイル時型情報なのかを決めます
実行時情報だけで足りるなら、まずgetClassやJavaリフレクションを検討します
Scala固有の型やモジュールが必要なら、対象バージョンに合ったScalaのリフレクション機構を選びます
メンバー名や引数型を検証し、取得に失敗した場合の結果をOptionやEitherで扱います
取得した反射情報をアプリケーション全体へ漏らさず、専用のアダプターや境界層に閉じ込めます

リフレクションで得られる情報は、あくまで実行環境やコンパイル結果に依存するメタデータです。
ソースコードの意図や設計上の契約まで自動的に保証してくれるわけではありません。
クラス名が取得できたとしても、期待するインターフェースを実装しているとは限らず、メソッドが見つかっても安全に呼び出せるとは限りません。
したがって、情報の取得と操作の許可を分離し、取得後に型や契約を検証する設計が重要です。

まとめると、実行中のオブジェクトを確認するだけならgetClass、JVMのフィールドやメソッドを扱うならJavaリフレクション、Scala 2固有の型やモジュールを扱うならScalaのランタイムリフレクション、Scala 3でコンパイル時に型や構文木を操作するならQuotes.reflectが基本的な選択肢です。
目的に合わないAPIを選ばず、取得できる情報の範囲と、実行時に失われる情報をあらかじめ把握しておくことが、安定した実装につながります。

Scalaのリフレクションでフィールドやプロパティを読み取る方法

Scalaのリフレクションでフィールドやプロパティを読み取る場合、最初に理解しておきたいのは、Scalaのソースコード上の「フィールド」と、JVM上で実際に存在するフィールドやアクセサーメソッドが、必ずしも一対一に対応しないことです。
Scalaではvalやvar、ケースクラスのコンストラクター引数、計算プロパティ、privateメンバーなどが、コンパイル後にフィールドやgetter、setterとして表現されます。
そのため、名前だけを頼りにアクセスするのではなく、どの情報を読み取りたいのかを明確にする必要があります。

最も簡単な方法は、JavaリフレクションのFieldを利用することです。
対象オブジェクトからgetClassを取得し、getDeclaredFieldやgetDeclaredFieldsでフィールドを検索します。
取得したFieldに対してgetを呼び出すと、指定したインスタンスに格納された現在の値を読み取れます。
Javaの公式APIでは、Fieldはクラスまたはインターフェースの単一フィールドに関する情報と動的アクセスを提供し、get(Object)によって対象オブジェクトのフィールド値を返すと説明されています。
プリミティブ型の値は、リフレクションAPIからは適切なラッパー型として返されます。
citeturn4search0turn4search2。

val target = new java.util.Date()
val field = target.getClass.getDeclaredField("fastTime")

println(field.getType.getName)
println(field.get(target))

ただし、上のような処理がすべてのScalaクラスでそのまま動くとは限りません。
対象フィールドがprivateである場合、Javaのアクセス制御によって読み取りが拒否されることがあります。
古い環境ではsetAccessible(true)によってアクセス制御を緩和できる場合もありますが、現在のJDKではモジュール境界や強いカプセル化の影響を受けます。
さらに、ライブラリ内部の実装フィールドへ依存すると、ライブラリの更新によってフィールド名や構造が変わっただけで処理が壊れます。
privateフィールドの読み取りは、デバッグや限定的なテストなど、目的を明確にした場面に限定するのが安全です。

getDeclaredFieldとgetFieldの違いも重要です。
前者は対象クラスが宣言したフィールドを、可視性に関係なく検索します。
ただし、親クラスから継承したフィールドは対象外です。
後者はpublicフィールドを対象にし、継承されたpublicフィールドも含めて検索します。
すべてのフィールドを一覧表示したい場合でも、取得結果が「対象クラスに直接定義されたもの」なのか「継承されたものを含むもの」なのかを確認しなければなりません。
フィールドの一覧を使って自動変換やJSON出力を行う処理では、この差が結果の欠落につながります。

Scalaでは、valやvarをJavaリフレクションで直接フィールドとして扱えるとは限りません。
publicなvalは、JVM上でprivateフィールドとアクセサーメソッドの組み合わせとして表現されることがあります。
Scalaのプロパティとして値を読み取りたい場合は、内部フィールドを探すよりも、getterに相当するメソッドを利用した方が安定する場合があります。
特に、値が計算によって返されるプロパティや、親クラスから継承されたアクセサーを扱う場合、フィールドではなくメソッドを調べる方がソースコード上の意味に近い処理になります。

ケースクラスでは、コンストラクター引数とproductElementを利用する方法もあります。
ケースクラスはProductとして扱えるため、フィールド名や型を個別にJavaリフレクションで解析しなくても、要素数や位置による値の取得が可能です。
ただし、位置に依存した処理は、フィールドの追加や順序変更に弱いという性質があります。
名前と値を対応させたい場合は、ケースクラスのコンパニオンやライブラリの導出機能を使う方が、汎用的なシリアライザーを設計しやすいことがあります。

Scala 2のランタイムリフレクションでは、Scala固有のフィールドやアクセサーをより明示的に扱えます。
基本的な流れは、ランタイムミラーを取得し、対象インスタンスをインスタンスミラーへ変換し、対象メンバーのシンボルからフィールドミラーを作るというものです。
InstanceMirror.reflectFieldは、フィールドシンボルを反射し、値の取得や、適切な場合には設定に使えるFieldMirrorを返します。
ScalaのAPIドキュメントでは、private[this]のvalやvarへアクセスする場合にもフィールドミラーが利用できる一方、それ以外の用途ではアクセサーを経由する方が望ましいと説明されています。
citeturn4search3turn4search4。

この点は、安全性を考えるうえで非常に重要です。
privateな実装フィールドを直接読むと、カプセル化された状態を外部へ露出させることになります。
また、lazy val、遅延初期化、同期処理、計算プロパティなどは、単純なフィールド読み取りでは本来の意味を再現できない可能性があります。
アクセサーメソッドには、値の計算、検証、同期、変換などのロジックが含まれているかもしれません。
したがって、「現在メモリーに保持されている内部値」が必要なのか、「公開APIを通じて得られる論理的な値」が必要なのかを分けて考える必要があります。

実行時に名前からScalaのプロパティを読み取る場合は、対象メンバーを検索した後に、読み取り可能なgetterかどうかを確認します。
Scala 2のリフレクションでは、メンバーシンボルの種類やアクセサー属性を調べ、フィールドとして直接扱うべきか、メソッドとして呼び出すべきかを判断します。
Javaリフレクションでも、対象名に対応するメソッドをgetDeclaredMethodなどで検索し、引数なしのgetterを呼び出す方法があります。
いずれの場合も、見つかった名前だけで処理を進めず、戻り値の型や可視性、静的メンバーかインスタンスメンバーかを検証することが大切です。

読み取り処理を汎用化するなら、結果をAnyのまま返さない設計が望ましいです。
呼び出し側が期待する型を受け取り、実際の値がその型へ安全に変換できるかを確認します。
変換に失敗する可能性があるなら、例外をそのまま外へ投げるのではなく、Either[ReflectionError, A]のような結果型に変換すると、失敗理由を明示できます。
対象フィールドが存在しない、アクセスが拒否された、値の型が一致しない、getterの呼び出しで例外が発生した、といった異常系を区別できるためです。

また、フィールドの値を読み取る処理では、静的フィールドとインスタンスフィールドを区別します。
静的フィールドに相当する値を読む場合は対象インスタンスが不要になることがありますが、通常のインスタンスフィールドでは正しい対象オブジェクトをgetへ渡さなければなりません。
対象クラスと実際のオブジェクトの型が一致しない場合や、別のクラスローダーでロードされた同名クラスを扱う場合、見た目の名前が同じでも型が異なるため、アクセスに失敗します。

リフレクションは、ログ出力、テスト用の状態確認、汎用シリアライザー、ORM、設定値のバインディングなどに役立ちます。
しかし、通常のアプリケーションロジックで値を読むだけなら、公開getter、パターンマッチ、ケースクラスのunapply、型クラスなどを優先するべきです。
リフレクションを使うのは、コンパイル時に対象の型が決まらない、複数の型を共通処理したい、フレームワークの境界で動的な解決が必要、といった理由がある場合に限定します。

安全にフィールドやプロパティを読み取るための要点は、次のとおりです。

内部フィールドと公開プロパティを区別します
getDeclaredField、getField、getterの違いを理解します
privateメンバーへのアクセスを常用しません
メンバー名だけでなく、型、可視性、宣言元クラスを検証します
Anyから期待する型への変換を明示し、失敗を結果型で扱います
リフレクション処理を専用の境界層へ閉じ込めます

フィールドの読み取りは、リフレクションの中では比較的単純な操作に見えます。
しかし、Scalaの抽象化とJVMの実装表現の差を理解しないまま利用すると、privateフィールド、アクセサー、継承、型消去、コンパイラー生成コードの影響を受けます。
値の内部表現を覗きたいのか、オブジェクトが公開する論理的なプロパティを取得したいのかを最初に決め、その目的に合ったAPIを選ぶことが、壊れにくい実装につながります。

Scalaで実行中のオブジェクトの値を書き換える方法

Scalaで実行中のオブジェクトの値を書き換える方法としては、JavaリフレクションのField#setを使う方法と、Scala 2のランタイムリフレクションでFieldMirrorを使う方法があります。
どちらも、対象クラスのフィールドを実行時に特定し、対象インスタンスへ新しい値を設定する仕組みです。
ただし、これは通常のScalaコードが持つ型安全性やカプセル化を意図的に迂回する操作です。
実装できることと、設計上許容すべきことは別問題として扱わなければなりません。

最初に押さえておきたいのは、リフレクションで書き換えられる対象は、原則としてオブジェクトが保持しているフィールドの値だという点です。
実行中のメソッドの命令列を直接置き換えたり、すでにコンパイルされた処理の本体を任意のコードへ差し替えたりする機能ではありません。
メソッドの挙動を変えたい場合は、状態を変更して分岐結果を変える方法、プロキシやデコレーターを使う方法、依存性を差し替える方法、バイトコード変換やJavaエージェントを使う方法などを別途検討します。

Javaリフレクションでフィールドを書き換える基本的な流れは、次のとおりです。

対象オブジェクトからClassを取得します
フィールド名を指定してFieldを取得します
型、修飾子、宣言元クラスなどを検証します
必要なアクセス権があることを確認します
対象インスタンスと新しい値をsetへ渡します
書き換え後の状態が不変条件を満たすか確認します

概念を示すための最小例は次のようになります。

final class RuntimeConfig(private var endpoint: String) {
  def currentEndpoint: String = endpoint
}

val config = new RuntimeConfig("https://old.example")
val field = classOf[RuntimeConfig].getDeclaredField("endpoint")

if (!field.getType.equals(classOf[String])) {
  throw new IllegalArgumentException("unexpected field type")
}

field.setAccessible(true)
field.set(config, "https://new.example")

println(config.currentEndpoint)

この例では、privateなフィールドを取得し、アクセス制御を緩和してから値を設定しています。
しかし、実際のアプリケーションで同じ処理を無条件に使うのは危険です。
setAccessible(true)は、Java言語レベルのアクセスチェックを抑制するための機能であり、どの環境でも必ず成功するとは限りません。
Javaのモジュールシステムによるパッケージ境界、対象クラスの公開状態、実行元モジュールの権限によっては、アクセス拒否やInaccessibleObjectExceptionが発生します。
AccessibleObjectは、フィールド、メソッド、コンストラクターなどの反射対象に対するアクセスチェックを抑制する機能を提供しますが、権限やモジュール境界そのものを無効にする機能ではありません。
citeturn5search1turn5search2。

Scala 2では、Scalaのランタイムリフレクションを使ってフィールドを書き換える方法もあります。
ランタイムミラーから対象オブジェクトのインスタンスミラーを作り、フィールドまたはアクセサーに対応するシンボルを探し、それをreflectFieldへ渡してFieldMirrorを取得します。
Scalaの公式ドキュメントでは、FieldMirrorがインスタンスフィールドの取得や設定に使われる反射オブジェクトとして説明されています。
citeturn5search0turn5search3。

Scala 2の概念的な流れは、次のようになります。

import scala.reflect.runtime.universe._

final class Settings(private var retries: Int) {
  def currentRetries: Int = retries
}

val settings = new Settings(3)
val mirror = runtimeMirror(settings.getClass.getClassLoader)
val instanceMirror = mirror.reflect(settings)
val fieldSymbol = typeOf[Settings].decl(private newTermName("retries"))

if (fieldSymbol.isTerm && fieldSymbol.asTerm.isVar) {
  instanceMirror.reflectField(fieldSymbol.asTerm).set(5)
}

ただし、Scalaのバージョンやコンパイラーが生成するメンバー構造によって、フィールド名の扱いは変わり得ます。
private varがソースコード上の名前のままJVMフィールドとして存在するとは限らず、アクセサーや名前修飾されたメンバーとして現れる場合もあります。
したがって、文字列で内部フィールド名を直接組み立てるより、ScalaのリフレクションAPIからシンボルを検索し、対象の種類を検証する方が適切です。

valの書き換えは、特に慎重に扱う必要があります。
valはScalaコード上では再代入できない値として設計されており、オブジェクトの不変性や初期化後に状態が変化しないという前提を支えています。
JVMでは、コンパイル結果やフィールドの性質によっては、リフレクションによる変更が試みられる場合があります。
しかし、finalフィールドを深いリフレクションで変更する動作は、実行環境のバージョンやモジュール設定に強く依存します。
JDK 26では、finalフィールドのリフレクションによる変更に対して、標準設定で警告が発生する方向へ制限が強化されています。
将来のJDKでは、必要な有効化設定がない限り変更が拒否される可能性も示されています。
citeturn5search4turn5search5turn5search6。

たとえ書き換えに成功しても、プログラム全体が変更後の値を一貫して見るとは限りません。
コンパイラーやJVMは、finalや不変であることを前提に最適化する場合があります。
別スレッドから同じオブジェクトを参照しているなら、可視性や順序性の問題も発生します。
あるスレッドでは変更後の値が見え、別のスレッドでは古い値が見える可能性を完全に排除するには、適切な同期や安全な公開が必要です。
リフレクションによる書き換えは、単なる代入ではなく、メモリモデルとオブジェクト設計を壊す操作になり得ます。

さらに、フィールドの値だけを変更しても、オブジェクト全体の不変条件が維持されるとは限りません。
たとえば、開始時刻が終了時刻より前であること、数値が一定範囲に収まること、複数のフィールドが同じ状態を表すことなど、通常はコンストラクターやsetterで検証されている条件があります。
リフレクションはそれらの検証を迂回するため、内部状態だけが不正になります。
値を書き換えるなら、対象クラスが公開する通常の更新メソッドを使うか、新しいインスタンスを生成して状態を置き換える方が安全です。

実務でどうしても書き換えが必要な場合は、対象を限定し、許可するフィールドを明示的に管理します。
外部入力から任意のフィールド名を受け取ってそのまま設定する設計は避けてください。
設定ファイルやリクエストにフィールド名が含まれる場合は、ホワイトリスト、値の型検証、範囲検証、監査ログを組み合わせます。
失敗時には、対象が見つからない、アクセスできない、値の型が違う、検証に失敗した、という原因を区別して返すと運用しやすくなります。

また、並行処理中のオブジェクトを書き換える場合は、リフレクション処理そのものを排他制御の対象にします。
ただし、単にsetの呼び出しをsynchronizedで囲むだけでは不十分なことがあります。
読み取り側が同じロックを取得していなければ、変更の可視性を保証できないためです。
共有状態の更新が必要なら、AtomicReference、不変オブジェクトの再生成、メッセージパッシング、アクターなど、変更を前提に設計された仕組みを優先します。

リフレクションによる書き換えの代替としては、次のような設計が考えられます。

copyを持つケースクラスで、新しい状態のオブジェクトを生成します
状態を保持するクラスへ、検証付きの更新メソッドを追加します
インターフェースや型クラスを使い、実装を差し替え可能にします
テストでは依存性注入やテスト専用のファクトリを利用します
挙動の差し替えには、デコレーター、プロキシ、関数の注入を使います

結論として、Scalaで実行中のオブジェクトの値を書き換えることは、JavaリフレクションのField#setやScala 2のFieldMirrorによって技術的には可能です。
しかし、privateメンバー、val、finalフィールド、モジュール境界、並行処理、不変条件を同時に考慮する必要があります。
デバッグや限定的なテスト、フレームワークの境界など、用途を狭く定義できる場合にだけ採用し、通常のビジネスロジックでは不変オブジェクトの再生成や明示的な更新APIを優先するのが堅実です。

privateメンバーやアクセス制御を越えて操作する際のリスク

Scalaのリフレクションでは、通常のコードから参照できないprivateメンバーや、パッケージ内に限定されたメンバーを検索し、条件によっては読み取りや書き換えを試みることができます。
しかし、技術的にアクセスできることと、アクセスしてよいことは同じではありません。
アクセス制御は単なる文法上の制限ではなく、クラスの責務、データの整合性、APIの公開範囲、セキュリティ境界を維持するための設計要素です。
それを越えて操作する処理には、明確な目的と厳格な制約が必要です。

Javaリフレクションでは、Field、Method、Constructorなどの反射対象に対して、setAccessible(true)や関連するAPIを使い、通常の言語レベルのアクセスチェックを抑制する場合があります。
AccessibleObjectは、private、package-private、protectedなどのメンバーに対するアクセスチェックを抑制するための仕組みを提供します。
ただし、その利用可否は対象が属するモジュールやパッケージの公開状態にも左右されます。
すべてのprivateメンバーへ無条件にアクセスできる機能ではありません。
citeturn6search0turn6search2。

とくにJDK 9以降のモジュールシステムを前提にすると、古い解説にある「setAccessible(true)を呼べば何でも操作できる」という理解は危険です。
JDK 17以降では、JDK内部APIなどの非公開パッケージへ反射的にアクセスする処理が、デフォルト設定で許可されない場合があります。
特定のパッケージを開くために--add-opensが必要になることもありますが、これは実行環境のカプセル化を緩和する設定です。
問題を解決するために安易に全体公開へ変更すると、モジュール境界を設けた意味が失われます。
citeturn6search3turn6search4。

リスクの一つ目は、カプセル化の破壊です。
クラスがprivateフィールドを持つのは、その値を外部から直接変更させない理由があるからです。
入力値の検証、状態遷移の制御、関連フィールドの同時更新、監査ログの記録、キャッシュの無効化などが、通常のメソッドにまとめられている可能性があります。
リフレクションでフィールドへ直接値を設定すると、これらの処理をすべて迂回します。
結果として、クラスの内部状態は変更されても、クラスが想定する不変条件は壊れるかもしれません。

たとえば、次のような状態を持つクラスを考えます。

final class Account private (private var balance: BigDecimal) {
  def withdraw(amount: BigDecimal): Either[String, Unit] =
    if (amount <= 0) Left("amount must be positive")
    else if (amount > balance) Left("insufficient balance")
    else {
      balance -= amount
      Right(())
    }

  def currentBalance: BigDecimal = balance
}

このクラスでは、残高を減らす前に正の金額か、残高を超えていないかを検証しています。
リフレクションでbalanceへ負数や過大な値を直接設定すれば、withdrawが守っていたルールを無効化できます。
以後の処理は、残高が負になる、請求額と残高の関係が崩れる、監査処理が実際の変更を把握できない、といった不整合を引き起こします。
privateメンバーへの直接操作は、単一の値を変更するだけに見えて、クラス全体の契約を破壊する操作なのです。

二つ目のリスクは、信頼できない入力によるリフレクションインジェクションです。
外部から受け取ったクラス名、フィールド名、メソッド名を検証せずに使うと、攻撃者が本来想定していなかった型や操作を指定できる可能性があります。
たとえば、設定ファイルやHTTPリクエストに含まれる名前を使って任意のクラスをロードし、任意のメソッドを呼び出す設計は危険です。
OWASPは、入力を適切に検証せずにリフレクション対象を選択する問題を、unsafe use of reflectionとして扱っています。
citeturn6search5turn6search7。

危険な設計では、処理の流れが次のようになります。

外部入力からクラス名やメソッド名を受け取ります
Class.forNameやリフレクションAPIで対象を解決します
引数の内容を検証せずにメソッドを呼び出します
privateメンバーへのアクセスまで有効化します

この構造では、攻撃者がクラス名を差し替えたり、意図しないメソッドを選択したり、内部状態を書き換えたりする余地が生まれます。
対策として、外部入力をクラス名やメソッド名として自由に解釈しないことが基本です。
必要な候補をコード側のホワイトリストへ登録し、外部からは短い論理名だけを受け取り、登録済みの実装へ変換します。
メソッドも許可された操作だけを明示的に対応付け、任意の名前を直接検索しない設計が望まれます。

三つ目のリスクは、依存ライブラリやJDKの更新による破綻です。
privateメンバーの名前、コンパイラーが生成するフィールド、Scalaのアクセサー、JVMのシグネチャーは、公開APIとして保証されていない限り変更される可能性があります。
Scalaのvalやvarがどのようなフィールドやメソッドへコンパイルされるかは、ソースコードの見た目だけから完全には判断できません。
内部実装へ依存するリフレクションは、コンパイルが通っても実行時にフィールドが見つからず、NoSuchFieldExceptionやNoSuchMethodExceptionを発生させることがあります。

四つ目は、性能とデバッグ容易性の低下です。
直接呼び出しなら、コンパイラーが型、引数、戻り値を検証し、IDEも参照関係を追跡できます。
リフレクションでは、名前の解決、アクセス検査、引数の検証、ボックス化や型変換などが実行時に発生します。
単発の初期化処理なら問題にならなくても、リクエストごと、レコードごと、ループごとに反射処理を実行すると、不要なコストが積み重なります。
キャッシュを使う場合でも、クラスローダーの寿命やキャッシュのキー設計に注意が必要です。

五つ目は、並行処理との相性です。
privateフィールドを直接変更すると、通常の同期機構を通らずに共有状態が変化します。
複数スレッドが同じオブジェクトを参照している場合、変更の可視性、読み取りと書き込みの競合、複数フィールドの更新順序が問題になります。
単一フィールドの書き換えが原子的に見えても、オブジェクト全体の状態遷移が安全になるとは限りません。
リフレクションを使う場合は、変更対象を共有しない、変更前後を同じロックで保護する、不変オブジェクトを再生成するなど、状態管理の方法を別途設計します。

valやfinalフィールドの変更は、さらに慎重に扱う必要があります。
これらは、初期化後に値が変わらないという前提をコンパイラーやJVMが利用する可能性があります。
仮に反射による変更が成功しても、すべてのコードが変更後の値を読み取るとは限りません。
JDK 26では、finalフィールドの深いリフレクションによる変更を制限する方向の警告と設定が導入されています。
将来のJDKで動作しなくなる可能性を考えると、finalや不変性を破壊する実装を通常の機能として採用するべきではありません。
citeturn5search4turn5search6。

安全にアクセス制御を扱うための判断基準は、次のように整理できます。

対象が自分の管理するクラスか、外部ライブラリのクラスかを確認します
公開APIや更新メソッドで解決できないかを最初に検討します
外部入力からクラス名やメンバー名を直接受け取りません
操作対象、引数型、戻り値、許可する修飾子をホワイトリストで制限します
setAccessibleや--add-opensを常用せず、使用箇所を限定します
JDK、Scala、依存ライブラリの更新を想定した統合テストを用意します
反射処理の失敗を握りつぶさず、監査可能なログと明確なエラーへ変換します

テストやデバッグでは、リフレクションによるprivateメンバーへのアクセスが便利な場合もあります。
しかし、テストが内部実装のフィールド名に強く依存すると、正しい振る舞いではなく実装詳細を検証するテストになります。
可能であれば、公開された観測結果、戻り値、イベント、ログ、状態遷移を検証し、どうしても内部状態が必要な場合だけ、テスト専用の補助機構を採用します。

privateメンバーやアクセス制御を越えるリフレクションは、強力であるほど責任の重い技術です。
利便性だけを理由に使うのではなく、カプセル化、入力検証、モジュール境界、バージョン互換性、並行処理、監査性を一つずつ確認してください。
リフレクションを使わずに明示的なAPIや不変オブジェクトで表現できるなら、その方法を選ぶ方が、長期的には安全で保守しやすいScalaコードになります。

Scalaでメソッドを動的に呼び出す方法と引数の扱い

Scalaでメソッドを動的に呼び出すには、実行時にメソッド名や引数の情報を解決し、JavaまたはScalaのリフレクションAPIへ対象オブジェクトと引数を渡します。
通常のコードでは、コンパイラーがメソッドの存在、引数の個数、引数型、戻り値の型を検証します。
しかし、メソッド名を文字列から取得するリフレクションでは、その多くが実行時の責任になります。
呼び出し自体は数行で書けても、安全に運用するには、対象の選定、引数変換、例外処理、アクセス制御を別々に設計する必要があります。

JVM上のScalaコードから最も直接的に利用できるのは、Javaのjava.lang.reflect.Methodです。
まず対象クラスからメソッドを検索し、取得したMethodに対してinvokeを呼び出します。
インスタンスメソッドの場合は第一引数に対象オブジェクトを渡し、staticメソッドの場合は対象をnullにします。
その後ろに、呼び出すメソッドの引数を順番どおりに渡します。
Javaの公式チュートリアルでも、Method.invokeは対象インスタンスとメソッド引数を受け取り、対象メソッドが投げた例外はInvocationTargetExceptionに包まれると説明されています。
citeturn7search0turn7search1。

final class Greeter {
  def greet(name: String, repeat: Int): String =
    List.fill(repeat)(s"Hello, $name").mkString(" / ")
}

val target = new Greeter
val method = classOf[Greeter].getMethod(
  "greet",
  classOf[String],
  java.lang.Integer.TYPE
)

val result = method.invoke(target, "Scala", Int.box(2)).asInstanceOf[String]
println(result)

この例で重要なのは、メソッド名だけでなく、引数の型を指定して検索している点です。
JavaのgetMethodやgetDeclaredMethodは、名前と引数型の組み合わせでメソッドを特定します。
オーバーロードされたメソッドが複数存在する場合、名前だけでは呼び出し対象を一意に決められません。
Scalaのソースコードでは同じメソッド名を自然に使えていても、JVM上では引数の型と個数を含むシグネチャーとして区別されています。

invokeへ渡す引数は、メソッドの宣言順に並べなければなりません。
引数の個数が合わない、型が一致しない、nullをprimitive型へ渡す、といった場合は、呼び出し時にIllegalArgumentExceptionが発生します。
JavaのMethod.invokeは、primitive型に対応するラッパー値のアンボックス化や、許可される範囲のメソッド呼び出し変換を行いますが、任意の型変換を自動的に実施するわけではありません。
公式APIでも、拡大変換は許可される一方、縮小変換が必要な場合はIllegalArgumentExceptionになると説明されています。
citeturn7search2turn7search3。

Scalaから呼び出すときは、Int、Long、Booleanなどの値型と、Javaリフレクションが期待するprimitive型やラッパー型の関係に注意します。
ScalaのIntはJVM上では通常primitiveのintに対応しますが、リフレクションAPIの引数はObjectとして扱われます。
多くの場合は自動的に処理されますが、引数を動的に組み立てる場合はInt.box、Long.boxなどで明示的にボックス化すると意図が分かりやすくなります。
逆に、文字列から数値へ変換する処理は自動では行われないため、呼び出し前に自分で検証と変換を実施します。

可変長引数も、リフレクションでは混乱しやすい部分です。
Scalaのdef log(values: String*)は、JVM上では通常の配列引数に近い形へコンパイルされます。
ソースコードで複数の文字列を個別に渡していたとしても、反射呼び出しでは対象メソッドが期待する配列やシーケンスの表現を確認しなければなりません。
デフォルト引数や名前付き引数も、リフレクションがScalaの呼び出し構文をそのまま再現してくれるわけではありません。
名前付き引数はコンパイル時の構文上の機能であり、実行時に引数名だけを渡して解決する仕組みとは異なります。

Scala 2のランタイムリフレクションでは、MethodSymbolからMethodMirrorを作成し、applyでメソッドを呼び出します。
一般的な流れは、ランタイムミラーを取得し、対象オブジェクトをInstanceMirrorへ変換し、型情報から目的のメソッドシンボルを探し、reflectMethodで呼び出し用のミラーを取得するというものです。
Scala公式ドキュメントでは、ランタイムリフレクションにおけるミラーが、メソッドやコンストラクターの反射呼び出しを実現する入口として説明されています。
citeturn7search4turn7search5。

import scala.reflect.runtime.universe._

final class Calculator {
  def add(left: Int, right: Int): Int = left + right
}

val calculator = new Calculator
val mirror = runtimeMirror(calculator.getClass.getClassLoader)
val instanceMirror = mirror.reflect(calculator)
val methodSymbol = typeOf[Calculator].decl(TermName("add")).asMethod
val methodMirror = instanceMirror.reflectMethod(methodSymbol)

val result = methodMirror(10, 5).asInstanceOf[Int]
println(result)

Scala 2のMethodMirrorは、Scala側の型やシンボルを基準にメソッドを扱える点が利点です。
ただし、対象メソッドのオーバーロード、継承、暗黙の引数、型パラメーターがあると、シンボルの選択が複雑になります。
メソッド名だけでdeclから取得するのではなく、取得した候補の引数リストを確認し、期待するパラメーター型と一致するものだけを選ぶ必要があります。
候補が一つもない場合や複数ある場合は、曖昧なまま呼び出さず、エラーとして扱うべきです。

メソッドの戻り値にも注意が必要です。
Javaリフレクションのinvokeは常にObject相当の値を返すため、Scala側ではAnyとして受け取ることになります。
asInstanceOfで即座にキャストすると、型が違う場合にClassCastExceptionが発生します。
安全性を高めるなら、期待するクラスを検証してから変換するか、パターンマッチで結果を確認します。
戻り値がUnitの場合や、primitive型を返す場合にも、JVM上の表現とScalaの型の対応を考慮します。

例外処理は、動的呼び出しで最も重要な部分の一つです。
リフレクションAPI自体が投げる例外と、呼び出したメソッド本体が投げる例外を区別してください。
対象メソッドが投げた例外は、通常InvocationTargetExceptionの内部にラップされます。
運用上はラッパーだけをログへ出力するのではなく、getCauseから元の例外を取り出し、機密情報を含めない範囲で原因を記録します。
Scala 2のMethodMirror.applyでも、対象メソッドが失敗する可能性は残るため、反射呼び出しの境界で例外をEitherなどへ変換すると扱いやすくなります。

安全な動的呼び出しでは、外部入力をそのままリフレクションAPIへ渡しません。
クラス名、メソッド名、引数値を自由に指定できる設計は、意図しない処理の実行や内部機能の露出につながります。
操作名を限定した列挙型やホワイトリストへ変換し、各操作に対応するメソッドと引数スキーマをコード側で管理します。
引数の個数、型、範囲、nullの可否を確認してから反射呼び出しへ進みます。

さらに、同じメソッドを繰り返し呼び出す場合は、名前解決や引数検証の結果をキャッシュする方法があります。
ただし、キャッシュされたMethodやミラーを異なるクラスローダーのオブジェクトへ適用することはできません。
プラグイン環境やアプリケーションサーバーではクラスローダーが複数存在するため、キャッシュのキーへクラスローダーや対象クラスを含める必要があります。
キャッシュの解放を誤ると、古いクラスローダーを保持してメモリーリークを起こす可能性もあります。

リフレクションでメソッドを呼び出すか判断するときは、次の観点を確認します。

実行時までメソッドが決まらない本当の理由があるかを確認します
メソッド名と引数型をホワイトリストで管理します
オーバーロードや可変長引数を含むシグネチャーを検証します
primitive型、null、ボックス化、文字列からの変換を明示的に扱います
戻り値を無条件にasInstanceOfでキャストしません
InvocationTargetExceptionの原因例外を区別して処理します
反射情報のキャッシュとクラスローダーの寿命を設計します

通常のビジネスロジックで呼び出し対象がコンパイル時に分かっているなら、リフレクションは避けるべきです。
関数を値として渡す、型クラスを使う、インターフェースに依存する、明示的なコマンドとハンドラーを登録する、といった設計なら、コンパイラーの型検査とIDEの支援を利用できます。
リフレクションは、プラグイン、汎用フレームワーク、外部設定との接続など、動的解決が本質的に必要な境界へ閉じ込めるのが理想です。

Scalaでメソッドを動的に呼び出す処理は、名前を見つけて実行するだけではありません。
対象の選定、JVM上のシグネチャー、引数の変換、戻り値の型、例外のラッピング、セキュリティ境界までを一つの契約として設計する必要があります。
動的であることによる柔軟性を活かしながら、呼び出せる操作を限定し、失敗を明示的に扱うことが、安全なリフレクション実装の基本です。

Scala 2とScala 3におけるリフレクションの違い

Scala 2とScala 3では、同じ「リフレクション」という言葉を使っていても、対象とする処理、APIの構成、設計思想が大きく異なります。
Scala 2には、実行時にScalaの型やシンボル、モジュール、メソッド、フィールドを扱うためのランタイムリフレクションが用意されていました。
一方、Scala 3ではScala 2のscala-reflectがそのまま移植されておらず、主にマクロやクォート式の中で、コンパイル時のTyped ASTを分析・生成するためのリフレクションへ整理されています。

この違いを理解しないままScala 2のコードをScala 3へ移行すると、scala.reflect.runtime.universe、TypeTag、Manifest、Mirrorなどを使っていた箇所でコンパイルエラーが発生します。
Scala 3の移行ガイドでは、Scala 2のscala-reflectはScala 2コンパイラー内部の仕組みに依存しているため、そのままScala 3へ移植されないと説明されています。
該当する機能が必要な場合は、Javaリフレクション、Scala 3のメタプログラミング機能、または目的に合ったライブラリへ置き換える必要があります。
citeturn8search2。

両バージョンの違いを整理すると、次のようになります。

観点	Scala 2	Scala 3
主なリフレクション	ランタイムリフレクションとコンパイル時リフレクション	クォート、スプライス、マクロを中心としたコンパイル時リフレクション
代表的なAPI	`scala.reflect.runtime.universe`、`TypeTag`、`Mirror`	`scala.quoted.*`、`Quotes.reflect`、`TypeRepr`、`Symbol`
実行時のオブジェクト操作	Scala固有のミラーで型やメンバーを操作	Scala 2と同じランタイムAPIは利用できない
主な用途	実行時の型検査、モジュール取得、メソッド呼び出し	Typed ASTの分析、コード生成、導出、マクロ
移行時の対応	既存APIを利用可能	Javaリフレクションや新しいメタプログラミングへ再設計

Scala 2のランタイムリフレクションでは、runtimeMirrorを起点にして、クラスローダーとScalaの型情報を結び付けます。
typeOf[T]で型表現を取得し、TypeSymbolやTermSymbolからクラス、メソッド、フィールドなどを調べます。
対象インスタンスに対してInstanceMirrorを作成し、reflectMethodやreflectFieldでメンバーを呼び出したり、値を取得・設定したりできます。
Scalaのシングルトンobjectを表すモジュールシンボルを扱える点も、JVMのClassだけを使うJavaリフレクションとの違いです。

ただし、Scala 2のランタイムリフレクションは、Scalaのコンパイラーや内部表現に強く結び付いています。
型情報を詳しく扱える反面、APIの理解が難しく、コンパイラーのバージョンやライブラリの組み合わせに注意が必要です。
scala-reflectを依存関係へ追加して利用する必要があり、Scala 2.12向けにコンパイルされたライブラリをScala 2.13やScala 3でそのまま使えるとは限りません。
フレームワークが内部でTypeTagやManifestを要求している場合は、移行前に依存ライブラリの対応状況を確認する必要があります。

Scala 2でよく使われたTypeTagは、型消去の影響を受けるジェネリック型の情報を実行時へ持ち込むための仕組みでした。
たとえば、コンパイル時にList[String]とList[Int]を区別できても、実行時のクラス情報だけでは両方がListに見える場合があります。
TypeTagはこのような型表現を保持する目的で使われましたが、Scala 3へは同じ形で移行できません。
実行時のクラス判定だけでよいならClassTag、型安全な値の抽出や検査が必要ならTypeable、コンパイル時の型解析が必要ならTypeやTypeReprなど、目的に応じて代替手段を選びます。

Scala 3のリフレクションは、主にscala.quotedのコンテキスト内で利用します。
マクロでは、コードを値として扱うクォートと、生成したコードを埋め込むスプライスを組み合わせます。
Quotes.reflectを使うと、型付きの構文木であるTyped ASTを調べたり、新しい定義や式を生成したりできます。
Scala 3の公式APIでは、リフレクションモジュールがASTベースのメタプログラミングの低レベルAPIを提供すると説明されています。
citeturn8search0turn8search1。

概念的には、Scala 3のマクロは次のような処理に向いています。

型に応じて異なるコードをコンパイル時に生成します
ケースクラスや列挙型から変換処理を自動導出します
式の型やシンボルを検査し、誤りをコンパイル時に報告します
ボイラープレートコードを生成し、実行時の反射処理を減らします
コンパイル時に利用可能なメンバーを確認して最適な実装を作ります

Scala 3での簡単なマクロ例を考えると、マクロ実装側でTypeReprから型の親クラスやメンバーを確認し、条件に応じた式を生成します。
ここで操作しているのは、実行中のオブジェクトではなく、コンパイル中のプログラム構造です。
つまり、Scala 2のランタイムリフレクションが「実行時に対象を探して動かす」仕組みだったのに対して、Scala 3のQuotes.reflectは「コンパイル時に対象を分析してコードを作る」仕組みだと考えると整理しやすくなります。

Scala 3で実行中のオブジェクトを動的に操作したい場合、まずJavaリフレクションを検討します。
JVMのクラス、フィールド、メソッド、コンストラクターを扱うだけなら、Class、Field、Method、Constructorで目的を達成できます。
Scala固有のケースクラスや型クラスを扱う場合は、Mirrorによる導出、型クラスインスタンスの明示的な登録、コンパイル時生成、専用のシリアライザーライブラリなどを組み合わせます。
Scala 2のAPIを無理に再現するより、必要な機能を型安全な境界へ再設計した方が保守しやすい場合が多いです。

移行時に特に注意したいのが、ランタイムリフレクションとコンパイル時リフレクションを混同しないことです。
Scala 2のコードがTypeTagを使っていても、実際の目的が単純な実行時クラス判定なのか、ジェネリック型の解析なのか、マクロでのコード生成なのかによって移行先は変わります。
機械的にAPI名を置き換えるのではなく、まずリフレクションを使っていた理由を分解します。

移行方針は、次のように決めると実践的です。

実行時のクラスやメソッドを名前で探しているなら、Javaリフレクションを検討します
コンパイル時に型を検証してコードを生成しているなら、Scala 3マクロへ移行します
型の自動変換やシリアライズが目的なら、Mirrorや型クラスによる導出を検討します
TypeTagで実行時型を持ち運んでいるなら、必要な情報をClassTag、Typeable、Typeへ分解します
内部ライブラリがscala-reflectへ依存しているなら、Scala 3対応版への更新や別実装を確認します

Scala 3では、コンパイル時に解決できる処理をできるだけコンパイル時へ移す設計が有効です。
実行時リフレクションは、クラス名やメソッド名の誤り、アクセス制御、実行環境の差異によって障害が発生しやすくなります。
一方、マクロや導出によって生成されたコードは、型検査を通過した状態で実行されます。
もちろん、マクロも複雑にしすぎると可読性やビルド時間に問題が出るため、すべてをマクロへ置き換える必要はありません。
動的な要件が本当に存在する部分だけをランタイム処理として残し、それ以外を通常の型付きコードへ戻す判断が重要です。

結論として、Scala 2のリフレクションは、Scala固有の型やオブジェクトを実行時に扱える強力な仕組みでした。
Scala 3のリフレクションは、Quotes.reflectを中心に、Typed ASTをコンパイル時に分析・生成するための仕組みへ再設計されています。
Scala 2からScala 3へ移行する際は、APIを置換するのではなく、実行時操作なのか、型解析なのか、コード生成なのかを見極めてください。
そのうえで、Javaリフレクション、Scala 3のマクロ、Mirrorによる導出、型クラスなどを使い分けることが、型安全で長期的に維持しやすい設計につながります。

安全なリフレクション実装のための設計と例外処理

Scalaでリフレクションを安全に使うには、反射APIの呼び出し方を覚えるだけでは不十分です。
実行時に何を解決し、どの操作を許可し、失敗した場合にどの情報を返すのかを、通常のアプリケーション設計と同じレベルで定義する必要があります。
リフレクションはコンパイラーによる型検査の一部を実行時へ移すため、動的な境界を無制限に広げるほど、障害の発見が遅れ、原因の追跡も難しくなります。

安全性を高める基本方針は、リフレクションをアプリケーション全体へ散在させず、専用の境界層へ閉じ込めることです。
たとえば、設定ファイルに記述されたプラグイン名を解決するPluginLoader、外部データをオブジェクトへ変換するReflectiveMapper、テスト用の内部状態取得を担うTestAccessorなど、役割を限定したコンポーネントを用意します。
ビジネスロジック側は、反射APIやMethod、Fieldを直接扱わず、型付きのインターフェースだけを利用する設計です。

リフレクションの境界では、次の情報を明示的に管理します。

利用を許可するクラスまたは論理名
呼び出しを許可するメソッドや読み取りを許可するプロパティ
各操作が受け付ける引数の個数と型
戻り値として保証する型
privateメンバーやアクセス制御の緩和を許可するかどうか
解決失敗、引数不一致、実行失敗を区別するエラー種別

とくに重要なのが、外部入力をリフレクション対象へ直接変換しないことです。
HTTPリクエスト、設定ファイル、メッセージキュー、データベースの値などからクラス名やメソッド名を受け取り、その文字列をClass.forNameやgetMethodへそのまま渡す設計は避けます。
入力値が許可された候補かを確認し、論理名からコード側の登録情報へ変換します。
OWASPも、検証されていない入力によってリフレクション対象のクラスやメソッドを選択する問題を、unsafe use of reflectionとして扱っています。
citeturn6search5turn6search7。

安全な設計では、次のように「外部入力」と「反射対象の解決」を分離します。

sealed trait Operation
object Operation {
  case object Health extends Operation
  case object Reload extends Operation

  def fromName(value: String): Option[Operation] =
    value match {
      case "health" => Some(Health)
      case "reload" => Some(Reload)
      case _        => None
    }
}

この例では、外部から受け取った文字列を任意のメソッド名として扱わず、許可された操作の一つへ変換しています。
実際の処理では、このOperationとあらかじめ登録したハンドラーを対応付けます。
リフレクションが必要な場合でも、外部入力はクラス名やメソッド名ではなく、限定された論理名として扱うのが基本です。

クラスの解決についても、ホワイトリストを使います。
たとえば、プラグイン名と実装クラスの対応をコードまたは信頼できる設定で管理し、利用可能なクラスを最初から限定します。
クラスが指定したインターフェースを実装しているか、必要なアノテーションを持っているか、許可されたパッケージに属しているかを検証します。
パッケージ名の接頭辞だけで安全性を判断するのではなく、登録済みクラスとの一致を確認する方が確実です。

メソッドを検索するときは、名前だけをキーにしないでください。
オーバーロードされたメソッドが存在する場合、名前だけでは対象が決まりません。
次の項目を組み合わせて検証します。

メソッド名
引数の個数
引数の実行時クラスまたは期待する型
staticメソッドかインスタンスメソッドか
publicなどの許可された可視性
戻り値が期待するインターフェースや型に適合するか

引数の変換も、リフレクション層の責任として明示します。
文字列をIntへ変換する、JSONの数値をBigDecimalへ変換する、nullを許可する、列挙型名を値へ変換する、といった処理を、invokeへ渡す直前に暗黙的に行うのではなく、独立した変換処理として設計します。
変換に失敗した場合は、呼び出しそのものを実行せず、引数エラーとして返します。
これにより、対象メソッドの内部で発生したエラーと、入力形式のエラーを区別できます。

結果型には、Eitherが適しています。
左側に反射処理の失敗理由、右側に変換済みの戻り値を格納します。

sealed trait ReflectionError
final case class ClassNotAllowed(name: String) extends ReflectionError
final case class MethodNotFound(name: String) extends ReflectionError
final case class InvalidArguments(message: String) extends ReflectionError
final case class InvocationFailed(cause: Throwable) extends ReflectionError
final case class UnexpectedResult(expected: String) extends ReflectionError

実際の呼び出し処理では、これらのエラーを適切に生成し、呼び出し側へ返します。
Optionだけでも「見つかったか、見つからなかったか」は表現できますが、クラスが存在しないのか、メソッドがないのか、引数が不正なのかを区別できません。
運用や障害対応が必要なシステムでは、エラーの種類を表現できる代数的データ型の方が有用です。

JavaのMethod.invokeを使う場合は、反射API自体が投げる例外と、呼び出されたメソッド本体が投げる例外を分けて処理します。
対象メソッドが例外を投げると、リフレクション層は通常その例外をInvocationTargetExceptionでラップします。
OracleのAPI仕様では、InvocationTargetExceptionは呼び出されたメソッドやコンストラクターが投げた例外をラップする例外であり、元の例外はgetCause()で取得できると説明されています。
citeturn9search0turn9search1。

import java.lang.reflect.InvocationTargetException

def invokeSafely(
    method: java.lang.reflect.Method,
    target: AnyRef,
    args: Seq[AnyRef]
): Either[ReflectionError, Any] =
  try {
    Right(method.invoke(target, args: _*))
  } catch {
    case error: InvocationTargetException =>
      Left(InvocationFailed(Option(error.getCause).getOrElse(error)))
    case error: IllegalArgumentException =>
      Left(InvalidArguments(Option(error.getMessage).getOrElse("invalid arguments")))
    case error: ReflectiveOperationException =>
      Left(InvocationFailed(error))
    case error: SecurityException =>
      Left(InvocationFailed(error))
  }

ここで重要なのは、InvocationTargetExceptionそのものだけをログへ出力しないことです。
ラッパー例外のメッセージだけでは、実際に失敗した処理の原因が分かりません。
getCause()から元の例外を取得し、業務上必要な情報だけをエラーへ変換します。
ただし、元の例外メッセージにパスワード、トークン、個人情報、SQL文、入力データが含まれる可能性もあるため、そのまま外部レスポンスへ返してはいけません。

例外処理では、少なくとも次の層を分けると設計しやすくなります。

解決エラーは、クラスやメソッドが許可されていない、または存在しない場合に返します
検証エラーは、引数の個数、型、値の範囲、戻り値の契約が不正な場合に返します
アクセスエラーは、可視性やモジュール境界によって操作できない場合に返します
実行エラーは、呼び出されたメソッド内部で発生した例外として記録します
環境エラーは、クラスローダー、依存関係、JDK設定の差異による失敗として扱います

privateメンバーへアクセスする場合は、さらに明示的な制限を設けます。
setAccessible(true)を呼び出せる場所を一箇所へ限定し、アプリケーションの任意コードから利用できないようにします。
外部ライブラリのprivateメンバーへ依存する処理は、ライブラリの更新で壊れやすく、JDKのモジュール境界によっても拒否されます。
アクセスを許可するなら、対象クラスのバージョン、フィールド名、型、用途をドキュメント化し、更新時に検証するテストを用意します。

並行処理にも注意が必要です。
Scala 2のランタイムリフレクションには、バージョンによって初期化やシンボル解決のスレッド安全性に関する注意事項があり、公式ドキュメントでもランタイムリフレクションをスレッドやアクターと組み合わせる場合の危険性が説明されています。
複数スレッドから反射情報を共有する場合は、使用するScalaバージョンの仕様を確認し、初期化を一度だけ行う、反射メタデータを安全にキャッシュする、共有状態の書き換えを避けるなどの対策を取ります。
citeturn9search2turn9search3。

性能面では、リフレクション情報を毎回検索しない設計が有効です。
Methodや変換関数をキャッシュできますが、クラスローダーの違う同名クラスを混同しないようにします。
キャッシュキーには、対象クラス、メソッド名、引数型、クラスローダーなどを含めます。
プラグインの再読み込みがある環境では、古いクラスローダーをキャッシュが保持してメモリーリークを起こさないよう、ライフサイクルに合わせてキャッシュを破棄します。

テストでは、正常系だけでなく、反射固有の失敗を網羅します。
クラスが未登録の場合、メソッド名が誤っている場合、オーバーロードが曖昧な場合、引数型が違う場合、privateアクセスが拒否された場合、対象メソッドが例外を投げた場合、戻り値が期待型と違う場合を確認します。
JDKとScalaの対象バージョンを変えたテストも用意し、開発環境だけでなく本番の実行条件に近い環境で検証します。

リフレクションは、汎用性を高めるための技術である一方、型安全性を失う境界でもあります。
安全な実装に必要なのは、例外を握りつぶすことではなく、どの段階で何が失敗したのかを明確にすることです。
入力をホワイトリストで制限し、引数と戻り値を検証し、アクセス制御を安易に緩和せず、元の例外を正しく取り出し、反射処理を型付きの境界へ変換する。
この設計を守れば、Scalaのリフレクションを限定的かつ予測可能な形で活用できます。

リフレクションを使わずに解決するScalaの設計パターン

Scalaのリフレクションは、実行時に型やメソッドを解決する必要がある場面で役立ちます。
しかし、対象がコンパイル時に分かっているにもかかわらず、文字列でクラス名やメソッド名を指定しているなら、設計を見直せる可能性があります。
リフレクションを使わない設計では、コンパイラーの型検査、IDEの補完やリファクタリング支援、明示的な依存関係、テストのしやすさを活用できます。
結果として、実行時エラーを減らし、コードを読んだ人が処理の流れを追いやすくなります。

まず検討したいのが、インターフェースと依存性注入です。
複数の実装を切り替えるために、設定値からクラス名を読み込み、リフレクションでインスタンスを生成する設計はよくあります。
しかし、実装候補がアプリケーションのコンパイル時に分かっているなら、共通のtraitとコンストラクター引数で依存性を渡す方が明確です。

trait MessageSender {
  def send(message: String): Either[String, Unit]
}

final class ConsoleSender extends MessageSender {
  def send(message: String): Either[String, Unit] = {
    println(message)
    Right(())
  }
}

final class NotificationService(sender: MessageSender) {
  def notify(message: String): Either[String, Unit] =
    sender.send(message)
}

val service = new NotificationService(new ConsoleSender)
service.notify("completed")

この構造では、NotificationServiceが具体的なクラス名を知らず、MessageSenderという契約だけに依存します。
テストではMessageSenderのテストダブルを渡せるため、privateフィールドを書き換えたり、リフレクションでメソッドを差し替えたりする必要がありません。
実装の選択を設定で変更したい場合も、起動時のファクトリや明示的な登録表で対応できます。

実装が複数ある場合は、論理名とファクトリ関数を明示的に対応付ける方法が有効です。
外部入力をそのままクラス名として解釈する代わりに、許可された名前を列挙型や代数的データ型へ変換し、コード側で定義した関数からインスタンスを生成します。
これにより、利用できる実装がコード上に一覧化され、未知の値を受け取った場合もコンパイル時または起動時に検出できます。

sealed trait SenderKind
object SenderKind {
  case object Console extends SenderKind
  case object Memory extends SenderKind

  def parse(value: String): Option[SenderKind] =
    value match {
      case "console" => Some(Console)
      case "memory"  => Some(Memory)
      case _         => None
    }
}

def createSender(kind: SenderKind): MessageSender =
  kind match {
    case SenderKind.Console => new ConsoleSender
    case SenderKind.Memory  => new MemorySender
  }

次に有効なのが、関数を値として渡す設計です。
動的に呼び出したいメソッドが、実際には「処理を後から選びたい」という要件であれば、メソッド名を文字列で持つ必要はありません。
String => ResultやRequest => Either[Error, Response]のような関数型を受け取り、実行時には関数を呼び出します。
関数の引数と戻り値はコンパイル時に検査されるため、リフレクションよりも契約が明確です。

final case class Command(name: String, run: () => Either[String, String])

val commands: Map[String, Command] = Map(
  "status" -> Command("status", () => Right("ok")),
  "reload" -> Command("reload", () => Right("reloaded"))
)

def execute(name: String): Either[String, String] =
  commands.get(name) match {
    case Some(command) => command.run()
    case None          => Left(s"unknown command: $name")
  }

この方法は、CLIコマンド、HTTPの操作ルーティング、イベント処理、バッチ処理などに向いています。
外部から受け取った文字列は、登録された関数を検索するキーにとどまり、任意のメソッド名やクラス名として実行されません。
引数を取る処理でも、関数の型を明示し、入力を関数へ渡す前に検証できます。

データの更新では、不変オブジェクトとcopyを優先します。
実行中のオブジェクトのprivateフィールドを書き換える代わりに、変更後の値を持つ新しいインスタンスを生成する設計です。
Scalaのケースクラスは、コンストラクター引数が基本的に不変の値として扱われ、copyによって一部のフィールドだけを変更した新しいインスタンスを作れます。
Scala公式ドキュメントでも、ケースクラスは不変データのモデル化に適しており、copyで変更後のインスタンスを生成できると説明されています。
citeturn10search3turn10search4。

final case class UserProfile(id: Long, name: String, enabled: Boolean)

val before = UserProfile(10L, "Alice", enabled = false)
val after = before.copy(enabled = true)

この方式では、元のbeforeが変更されないため、参照を共有していても状態の変化を追跡しやすくなります。
スレッド間で不変オブジェクトを受け渡す場合も、途中で内部値が書き換えられる前提がないため、同期処理を減らせる可能性があります。
もちろん、copyは浅いコピーなので、内部にmutableなコレクションや可変オブジェクトを保持している場合は、その部分の設計も見直す必要があります。

状態遷移を明示的に扱うなら、代数的データ型も有効です。
複数の状態を一つのmutableなオブジェクトへ詰め込み、リフレクションで状態フィールドを書き換えるのではなく、状態ごとに型やケースを定義します。

sealed trait JobState
object JobState {
  case object Pending extends JobState
  final case class Running(progress: Int) extends JobState
  final case class Completed(result: String) extends JobState
  final case class Failed(reason: String) extends JobState
}

def describe(state: JobState): String =
  state match {
    case JobState.Pending          => "待機中"
    case JobState.Running(progress) => s"実行中: $progress%"
    case JobState.Completed(result) => s"完了: $result"
    case JobState.Failed(reason)    => s"失敗: $reason"
  }

この設計なら、どの状態が存在するかが型として明確になり、パターンマッチによって処理漏れを検出できます。
リフレクションで文字列から状態クラスを生成するより、状態遷移のルールをコード上で検証しやすくなります。
状態が増えた場合も、コンパイラーの警告を利用して対応箇所を確認できます。

汎用的な変換やシリアライズが目的なら、Scala 3の型クラス導出とMirrorを検討します。
Scala 3のMirrorは、ケースクラス、列挙型、sealedな代数的データ型などについて、型レベルで構成要素やラベルの情報を提供します。
公式ドキュメントでは、Mirrorのインスタンスは型の構成要素やラベル情報を提供し、型クラス導出の基盤として利用できると説明されています。
citeturn10search0turn10search1。

たとえば、型ごとに手作業でシリアライザーを登録する代わりに、Encoder[T]のような型クラスを定義し、基本型やケースクラスの構造からコンパイル時にインスタンスを導出します。
これにより、実行時にフィールド名を検索する処理を減らし、存在しないフィールドや未対応の型をコンパイル時に検出できます。
ライブラリが提供する導出機能を利用できる場合は、独自にリフレクションを実装する前に確認するとよいでしょう。

型クラスは、型に対する操作を外部から追加する設計にも向いています。
たとえば、既存クラスへシリアライズ用のメソッドを追加できない場合でも、Encoder[A]やValidator[A]を別途定義し、型ごとの処理をgivenインスタンスとして提供できます。
処理対象を型で選択するため、メソッド名を文字列で指定する必要がありません。

trait Renderer[A] {
  def render(value: A): String
}

given Renderer[Int] with {
  def render(value: Int): String = value.toString
}

def renderValue[A](value: A)(using renderer: Renderer[A]): String =
  renderer.render(value)

このような設計では、利用可能な処理が型の解決によって決まります。
適切なgivenが存在しない場合はコンパイルエラーになるため、実行時に「メソッドが見つからない」という障害が起きにくくなります。
Scala 3の型クラス導出では、単純な条件を満たす型に対してgivenインスタンスを自動生成できるため、定型的なリフレクション処理をコンパイル時の導出へ移せます。
citeturn10search0turn10search2。

依存性注入についても、必ずしもリフレクションベースのDIコンテナが必要とは限りません。
コンストラクターインジェクションで依存関係を明示し、アプリケーションの起動箇所でオブジェクトグラフを組み立てます。
依存関係が少ないシステムでは、手動で生成する方が、どの実装が使われるかを追跡しやすく、起動時エラーも減ります。
依存性が大規模で手動配線が難しい場合でも、型安全なDIライブラリやコンパイル時生成を検討し、実行時に任意のクラスを探索する範囲を限定します。

リフレクションを使わない設計を選ぶときは、次のように要件を分類すると判断しやすくなります。

実装を切り替えたい場合は、trait、ファクトリ、依存性注入を使います
呼び出す処理を選びたい場合は、関数値、コマンド登録、パターンマッチを使います
オブジェクトの状態を更新したい場合は、ケースクラスのcopyや不変データを使います
状態の種類を表したい場合は、sealed traitやenumを使います
型ごとの共通処理を自動生成したい場合は、型クラス導出やMirrorを使います
コンパイル時にコードを分析・生成したい場合は、Scala 3のマクロを使います

もちろん、リフレクションを完全に排除できるとは限りません。
外部プラグイン、JVM上の未知のクラス、実行時に追加されるモジュール、既存フレームワークとの連携などでは、動的な解決が本質的に必要な場合があります。
その場合は、リフレクションを境界層だけで使い、解決後の値を型付きのtraitやデータ型へ変換します。
動的な処理を内部へ持ち込まないことがポイントです。

リフレクションを使わない設計の目的は、柔軟性を捨てることではありません。
柔軟性の表現場所を、文字列と実行時探索から、型、関数、登録表、代数的データ型、コンパイル時導出へ移すことです。
そうすれば、処理の許可範囲、依存関係、状態遷移、データ変換の契約をコード上で明示できます。
結果として、コンパイル時に見つけられる誤りが増え、リフレクション特有の例外やアクセス制御の問題を減らせます。

最終的には、「実行時に決める必要があるもの」と「コンパイル時に決められるもの」を分離することが重要です。
前者には限定的なリフレクションを使い、後者にはtrait、型クラス、関数注入、不変データ、Mirror、マクロなどを適用します。
この切り分けができれば、Scalaの静的型付けを活かしながら、必要な拡張性と保守性を両立できます。

Scalaのリフレクションを安全に使うためのまとめ

Scalaのリフレクションは、実行時にクラスやメソッドを解決したり、コンパイル時に型や構文木を分析したりできる強力な仕組みです。
プラグイン機構、シリアライザー、ORM、テスト支援、コード生成など、通常の静的なコードだけでは実現しにくい機能を構築できます。
一方で、型検査、アクセス制御、カプセル化、不変性の一部を実行時へ移すため、使い方を誤ると実行時エラーやセキュリティ上の問題、バージョン更新による破綻を招きます。

まず、リフレクションを使う目的を明確にしてください。
実行中のオブジェクトを調べたいのか、メソッドを動的に呼び出したいのか、フィールドを書き換えたいのか、コンパイル時に型を分析してコードを生成したいのかによって、選ぶべき技術は異なります。
Scala 2のランタイムリフレクション、Javaのjava.lang.reflect、Scala 3のQuotes.reflectは、似た名前を持っていても対象とする処理が同じではありません。

判断の出発点は、次の切り分けです。

JVM上のクラス、フィールド、メソッドを実行時に扱うなら、Javaリフレクションを検討します
Scala 2固有の型、シンボル、モジュールを実行時に扱うなら、Scala 2のランタイムリフレクションを検討します
Scala 3でコンパイル時に型やTyped ASTを分析・生成するなら、Quotes.reflectやマクロを検討します
コンパイル時に対象が決まっているなら、trait、型クラス、関数注入、パターンマッチを優先します

Scala 2のランタイムリフレクションは、runtimeMirror、typeOf、InstanceMirror、MethodMirror、FieldMirrorなどを通じてScalaの型やオブジェクトを扱えます。
Scala固有のシングルトンオブジェクトやシンボルを扱える点が利点ですが、Scala 3へAPIをそのまま移行できるわけではありません。
Scala 3では、主にscala.quotedとQuotes.reflectによるコンパイル時メタプログラミングへ整理されています。
実行時の動的操作が必要なら、Javaリフレクションや型安全な登録機構などへ再設計する必要があります。

安全性の面で最も重要なのは、リフレクションの境界を限定することです。
アプリケーションのあらゆる場所でgetDeclaredFieldやMethod.invokeを直接呼び出すと、処理の依存関係と失敗条件が見えにくくなります。
専用のアダプターやローダーへ反射処理を閉じ込め、通常のビジネスロジックには型付きの値だけを渡してください。
リフレクションの結果をAnyのまま広い範囲へ流さず、検証済みのtrait、ケースクラス、代数的データ型へ変換する設計が有効です。

外部入力の扱いにも細心の注意が必要です。
リクエストや設定ファイルに含まれるクラス名、メソッド名、フィールド名を、そのままリフレクションAPIへ渡してはいけません。
許可するクラスや操作をホワイトリストで明示し、外部から受け取った論理名を登録済みの実装へ変換します。
OWASPの入力検証ガイドでも、許可される値を明示し、それ以外を拒否するallowlist方式が推奨されています。
citeturn11search0。

たとえば、次のような項目をコード側で管理します。

利用を許可するクラスと実装インターフェース
呼び出しを許可するメソッド名と引数の型
読み取りや書き換えを許可するプロパティ
引数の個数、値の範囲、nullの可否
戻り値として保証する型
privateメンバーやモジュール外のメンバーを操作する可否

メソッドを動的に呼び出す場合は、名前だけでなく、引数の個数と型を必ず検証します。
オーバーロードされたメソッドを名前だけで検索すると、意図しない候補を選択する可能性があります。
primitive型とラッパー型、可変長引数、Scalaのデフォルト引数、暗黙の引数、戻り値の型消去も考慮してください。
実行時に文字列から数値や列挙型へ変換する場合は、変換処理を明示し、失敗した時点で呼び出しを中止します。

例外処理では、反射API自体の失敗と、呼び出したメソッド内部の失敗を分けます。
クラスやメソッドが見つからない場合、引数が一致しない場合、アクセスが拒否された場合は、解決または検証のエラーです。
一方、呼び出し対象のメソッドが投げた例外は、Javaリフレクションでは通常InvocationTargetExceptionにラップされます。
元の原因はgetCause()で取得できるため、ラッパーだけを記録せず、原因を分類して扱います。
OracleのAPI仕様でも、InvocationTargetExceptionは呼び出されたメソッドやコンストラクターの例外をラップするものと説明されています。
citeturn9search0turn9search1。

反射処理の結果は、OptionやEitherなどで表現すると安全性が高まります。
Optionは単純な「存在するかどうか」の表現に向いていますが、実務では「クラスが許可されていない」「メソッドがない」「引数が不正」「アクセスできない」「実行対象が失敗した」などを区別したい場面が多くあります。
その場合は、独自のエラー型を定義したEither[ReflectionError, A]を使うと、呼び出し側が異常系を明示的に処理できます。

privateメンバーやval、finalフィールドの操作は、原則として避けるべきです。
privateメンバーには、入力検証や不変条件の維持、監査ログ、キャッシュ更新などの処理を迂回してはいけない理由があります。
リフレクションで直接値を書き換えると、クラスが想定する状態契約を壊す可能性があります。
JDK 26では、finalフィールドを深いリフレクションで変更した場合に警告を出す仕組みが導入され、将来のリリースでは明示的な許可なしに拒否される方向が示されています。
citeturn11search1turn11search2。

リフレクションを使う前に、代替設計も確認してください。
実装を切り替えるだけならtraitと依存性注入、処理を動的に選ぶだけなら関数値やコマンド登録、状態を更新するだけなら不変オブジェクトの再生成、型に応じた変換なら型クラスや導出が候補になります。
Scala 3では、Mirrorや型クラス導出によって、ケースクラスや代数的データ型に対する定型処理をコンパイル時に生成できます。
公式ドキュメントでも、型クラス導出は一定の条件を満たす型に対してgivenインスタンスを自動生成する仕組みとして説明されています。
citeturn10search0turn10search1。

実行時の柔軟性が本質的に必要な場合にだけ、リフレクションを採用します。
プラグインの追加や外部クラスのロードなど、コンパイル時に対象を確定できない部分では有効です。
ただし、反射処理の直後に型付きのアダプターへ変換し、動的な値をシステム内部へ広げないことが重要です。
リフレクションはアプリケーション全体の設計ではなく、動的な境界を実装するための局所的な技術として扱います。

導入後は、実行時エラーだけでなく、JDK、Scala、依存ライブラリ、クラスローダーの違いもテストします。
フィールド名やメソッド名の変更、アクセス制御の変更、モジュール境界、オーバーロード、戻り値の型変更、privateメンバーの削除などを検出できる統合テストが必要です。
反射情報をキャッシュする場合は、クラスローダーの寿命やプラグインの再読み込みにも注意します。
古いクラスローダーをキャッシュが保持すると、メモリーリークにつながる可能性があります。

最終的な判断基準は、「使えるか」ではなく「使い続けても契約を維持できるか」です。
リフレクションは便利ですが、型安全性、カプセル化、不変性、可読性、性能、セキュリティ、将来の互換性を犠牲にする可能性があります。
目的、対象、許可範囲、失敗時の振る舞い、代替設計を文書化し、必要最小限の場所でだけ利用してください。

Scalaのリフレクションを安全に使う要点は、次の五つに集約できます。

実行時操作とコンパイル時メタプログラミングを区別します
外部入力をホワイトリストで制限し、任意のクラスやメソッドを実行させません
引数、戻り値、可視性、クラスローダーを検証します
例外を分類し、ラッパーの原因を正しく取り出します
リフレクションでなくても解決できる部分は、型付きの設計へ置き換えます

リフレクションは、Scalaの型システムを否定するための機能ではありません。
型システムだけでは表現しにくい動的な境界を実装し、その境界の外側では再び型安全なコードへ戻るための道具です。
用途を限定し、入力と結果を検証し、失敗を明示的に扱う。
この原則を守れば、リフレクションの柔軟性を活かしながら、保守性と安全性を両立できます。