密結合の呪縛を解け：VB.NETによる「AppDomain」を活用した堅牢なプラグイン機構の設計論
業務自動化の現場において、クライアントや現場部門から「追加の出力形式が欲しい」「特定の業務フローだけカスタマイズしたい」という要望が絶え間なく舞い込む。これに対し、その都度メインアプリケーションのソースコードを修正し、再コンパイルして、巨大な実行ファイルを配布し直しているとしたら……。
断言しよう。それはエンジニアリングではなく、単なる「作業」だ。
大規模な業務システムにおいて、コアロジック（本体）と拡張機能（プラグイン）を完全に分離する設計は、保守コストを劇的に下げ、システムの寿命を延ばすための「絶対条件」である。本稿では、VB.NETにおけるリフレクションと`AppDomain`を駆使し、本体を一切変更せずに機能を動的に追加・削除できる、プロフェッショナル仕様のプラグイン機構の設計パターンを伝授する。
1. なぜ「ただのリフレクション」では不十分なのか
多くの開発者が、`System.Reflection`を使ってDLL内の型をインスタンス化するだけで満足してしまう。しかし、実務レベルではそれだけでは致命的な欠陥を抱えることになる。
致命的な問題点：DLLのロックとメモリリーク
デフォルトの`AppDomain`（アプリケーションドメイン）にDLLをロードすると、そのDLLはアプリケーションが終了するまでメモリに居座り続け、ファイルへのアクセス権（ロック）を保持し続ける。
「新しいプラグインを適用したいから、DLLを差し替えよう」と思っても、アプリを落とさない限りファイルは上書きできない。これが、長期間稼働し続ける業務ツールにおいて、運用を阻害する最大の要因となる。
解決策：AppDomainによる「隔離」と「アンロード」
真に優れた設計とは、プラグインを専用の`AppDomain`に閉じ込め、不要になった瞬間にそのドメインごと「破棄（Unload）」できる設計である。これにより、DLLのロックを解除し、メモリを完全に解放することが可能になる。
2. アーキテクチャ設計：3つのレイヤー
プラグイン機構を構築するには、以下の3つのプロジェクト（またはDLL）を定義する必要がある。
1. Contract Library (共通インターフェース層): 本体とプラグインが「共通言語」として話すための契約書。
2. Plugin Implementation (プラグイン層): 実際の業務ロジックを実装する外部DLL。
3. Host Application (コアアプリケーション層): プラグインをロードし、実行する本体。
3. プロダクションコード実装例
それでは、具体的な実装を見ていこう。ここでは「データの処理を行う」という単純な機能を例にする。
ステップ1：Contract Library（共通インターフェース）
本体とプラグインの両方が参照する、最も重要な「契約」だ。
' --- Project: MySystem.Contract ---
Imports System
''' <summary>
''' プラグインが実装すべき共通インターフェース。
''' AppDomainを跨ぐため、MarshalByRefObjectを継承させるのが鉄則。
''' </summary>
Public MustInherit Class PluginBase
Inherits MarshalByRefObject
''' <summary>
''' プラグインの識別名を取得する
''' </summary>
Public MustOverride ReadOnly Property PluginName As String
''' <summary>
''' メインの実行ロジック
''' </summary>
''' <param name="inputData">処理対象のデータ</param>
''' <returns>処理結果</returns>
Public MustOverride Function Execute(inputData As String) As String
End Classステップ2：Plugin Implementation（外部モジュール）
これ単体でビルドされ、`Plugins`フォルダなどに配置される。
' --- Project: MySystem.Plugins.ExcelExport ---
Imports MySystem.Contract
''' <summary>
''' Excel出力機能をシミュレートしたプラグイン
''' </summary>
Public Class ExcelExportPlugin
Inherits PluginBase
Public Overrides ReadOnly Property PluginName As String
Get
Return "Excelエクスポート・プラグイン"
End Get
End Property
Public Overrides Function Execute(inputData As String) As String
' ここに実際の複雑なロジック（Excel操作、DB連携など）を記述する
Return $"[Excel出力完了] データ: {inputData}"
End Function
End Classステップ3：Host Application（コア本体）
ここが設計の肝となる。`AppDomain`を生成し、リフレクションを用いてプラグインを呼び出す。
' --- Project: MySystem.Core ---
Imports System.Reflection
Imports System.IO
Imports MySystem.Contract
Public Class PluginLoader
''' <summary>
''' 指定されたDLLからプラグインをロードし、実行する
''' </summary>
Public Sub RunPlugin(dllPath As String, input As String)
Dim domain As AppDomain = Nothing
Dim remotePlugin As PluginBase = Nothing
Try
' 1. AppDomainの作成設定
Dim setup As New AppDomainSetup()
setup.ApplicationBase = AppDomain.CurrentDomain.BaseDirectory
' プラグイン専用のディレクトリを指定することで、依存関係の衝突を防ぐ
setup.PrivateBinPath = Path.GetDirectoryName(dllPath)
' 2. 隔離されたAppDomainを生成
domain = AppDomain.CreateDomain("PluginDomain", Nothing, setup)
' 3. AppDomain内でプラグインをインスタンス化するためのプロキシを作成
' 注意: 直接Newするのではなく、CreateInstanceを介してリモートオブジェクトとして取得する
Dim assemblyName As New AssemblyName(Path.GetFileNameWithoutExtension(dllPath))
' ここでは、プラグインクラス名を特定するためにリフレクションを使用
' 本来は設定ファイル等からクラス名を読み込むのがベスト
Dim pluginTypeName As String = "MySystem.Plugins.ExcelExport.ExcelExportPlugin"
remotePlugin = DirectCast(domain.CreateInstance(pluginTypeName, GetType(PluginBase)), PluginBase)
' 4. 実行
Console.WriteLine($"Loaded: {remotePlugin.PluginName}")
Dim result = remotePlugin.Execute(input)
Console.WriteLine($"Result: {result}")
Catch ex As Exception
Console.WriteLine($"エラー発生: {ex.Message}")
Finally
' 5. 重要：AppDomainをアンロードしてリソースを解放する
' これにより、DLLのロックが解除される
If domain IsNot Nothing Then
AppDomain.Unload(domain)
Console.WriteLine("AppDomainをアンロードしました。")
End If
End Try
End Sub
End Class4. 実務でバグを生まないための「極限の知見」
設計図が書けたとしても、実装には落とし穴が潜んでいる。私が数々の現場で見てきた「失敗パターン」を共有しておく。
① `MarshalByRefObject` を忘れるな
`AppDomain`を跨ぐ場合、オブジェクトは「実体」ではなく「参照（プロキシ）」としてやり取りされる。これを忘れて通常のクラスを継承させると、`SerializationException`が発生して即死する。インターフェース層は必ず `MarshalByRefObject` を継承させること。
② DB接続とファイル操作のライフサイクル
プラグイン内でデータベース接続を開いたままにすることは、絶対的な禁忌である。
- NG: プラグイン内で `SqlConnection` を開きっぱなしにする。
- OK: 接続文字列だけを本体から渡し、プラグインの `Execute` メソッド内で `Using` ブロックを用いて確実にクローズする。
プラグインがクラッシュした際、`AppDomain.Unload` が走っても、外部リソース（DBセッションやファイルハンドル）の解放が不完全だと、システム全体に悪影響を及ぼす。
③ 例外処理の「二段構え」
プラグイン内のエラーは、本体のプロセスを巻き込んで落とすべきではない。
1. プラグイン内部: `Try…Catch` で詳細なログを記録し、適切なエラー情報を返す。
2. 本体側: `PluginLoader` 内でも `Try…Catch` を行い、プラグインの異常を検知して `AppDomain` を安全に破棄する。
結びに代えて
プラグイン機構の構築は、一見するとオーバーエンジニアリングに見えるかもしれない。しかし、システムが成長し、カスタマイズの要求が爆発したとき、この設計の有無が「開発チームの生存」を分けることになる。
「コードを書き換える」のではなく、「新しい部品を差し込む」。
この思想を、君たちのコードに刻んでほしい。
