VB.NETで「止まらないシステム」を創る：AppDomainを活用した動的プラグインアーキテクチャの極意
業務自動化の現場において、「機能追加のたびにアプリケーションを再起動する」という制約は、もはや技術的な怠慢と言わざるを得ません。
真に堅牢で拡張性の高いツールは、稼働中にDLLを読み込み、不要になれば即座にメモリから解放する「プラグイン構造」を備えています。今回は、VB.NETにおける動的アセンブリ読み込みの聖域、`AppDomain`を用いた安全かつプロフェッショナルな設計手法を伝授します。
—
1. なぜ「そのままのロード」ではいけないのか？
初学者が陥る最大の罠は、`Assembly.LoadFrom`を無邪気に使い、メインドメインにDLLを直結させることです。
- アンロード不可の呪縛: .NETにおいて、一度メインのドメインにロードされたアセンブリは、プロセスを終了するまでメモリから解放できません。
- ファイルロックの弊害: DLLが掴まれたままになり、後からプラグインを更新しようとしても「ファイルが使用中です」と怒られます。
我々エンジニアが目指すべきは、「AppDomainという隔離された砂場（サンドボックス）で動かし、用が済んだら砂場ごと消し去る」という高潔なライフサイクル管理です。
—
2. 堅牢なプラグイン設計の要点
プラグイン構造を設計する際、以下の3点を遵守してください。
1. インターフェースの分離: ホスト側とプラグイン側は、必ず共通の「契約（Interface）」を通じた通信を行うこと。DLLの具体的な型に依存してはいけません。
2. 型安全性と疎結合: `Reflection`を乱用せず、必要なメソッドだけをインターフェース経由で呼び出すことで、実行時エラーを最小化します。
3. AppDomainの切り離し: プラグイン専用の`AppDomain`を作成し、そこにロードさせることで、物理的なメモリ領域を分離します。
—
3. 実装：プラグインホストの極限コード
以下は、プロダクション環境でも耐えうる動的読み込みの骨子です。
ステップ1: 共通インターフェース定義 (SharedLibrary.dll)
まずはホストとプラグインの両方が参照する共通プロジェクトを作成します。
Public Interface IPlugin
Function Execute(input As String) As String
End Interface
ステップ2: ホスト側のローダー実装
ここが心臓部です。`AppDomain`を生成し、プラグインを隔離実行します。
Imports System.Reflection
Public Class PluginLoader
Public Sub LoadAndRun(dllPath As String)
‘ 1. 新しいAppDomainを作成（隔離領域）
Dim domainSetup As New AppDomainSetup()
Dim pluginDomain As AppDomain = AppDomain.CreateDomain(“PluginDomain”, Nothing, domainSetup)
Try
‘ 2. AppDomain内でプラグインをインスタンス化
Dim plugin As IPlugin = DirectCast(pluginDomain.CreateInstanceFromAndUnwrap(dllPath, “MyPlugin.Worker”), IPlugin)
‘ 3. 実行
Dim result As String = plugin.Execute(“業務データ”)
Console.WriteLine($”プラグインの実行結果: {result}”)
Finally
‘ 4. 砂場ごと破棄（これでDLLのロックが解除される）
AppDomain.Unload(pluginDomain)
End Try
End Sub
End Class
—
4. プロダクション環境における「守りの技術」
ファイルアクセスとデータベース連携の注意点
- 例外のバブルアップ: プラグイン内で発生した例外は、AppDomainの境界を越えてホスト側に伝播します。`Try-Catch`を適切に配置し、プラグインのエラーがホストを道連れにしないよう設計してください。
- シリアライゼーション: `AppDomain`を跨いでオブジェクトを渡す場合、そのオブジェクトは`Serializable`であるか、`MarshalByRefObject`を継承している必要があります。ここを疎かにすると、境界越えの際に「型不一致」という悪夢に遭遇します。
パフォーマンスへの配慮
頻繁にロード/アンロードを繰り返すと、`AppDomain`の生成コストが無視できなくなります。プラグインのライフサイクルは、業務の単位（例：1バッチ処理ごと）に合わせるのが最適解です。
—
チーフアーキテクトからの助言
「動けばいい」というコードは、数ヶ月後の自分自身を殺します。
今回紹介した`AppDomain`による隔離は、単なる機能拡張のためだけではありません。「不良プラグインからメインプロセスを護る」という、堅牢な防御壁としての役割も果たします。
VB.NETは古い言語だなどと誰が言ったのでしょうか。正しく設計されたVB.NETのコードは、現代のどの言語よりも読みやすく、そしてパワフルに業務を自動化します。このアーキテクチャを武器に、あなたのシステムを「止まらないエンジン」へと進化させてください。
健闘を祈ります。
