「密結合」という名の負債を断て：VB.NETにおけるインターフェース分離型プラグインアーキテクチャの極意
業務アプリケーションの開発現場で、よくある「失敗のシナリオ」を想像してみてほしい。
「新しい帳票形式を追加してください」「新しい計算ロジックを組み込んでください」……。その依頼が来るたびに、あなたは本体のソースコードを書き換え、`Select Case` 文に新しい条件を追加し、巨大なプロジェクトを丸ごと再ビルドしているのではないか？
もしそうなら、君の設計は「密結合（Tight Coupling）」という名の致命的な負債を抱えている。
真にプロフェッショナルなエンジニアが作るシステムは、本体（Host）を一行たりとも書き換えることなく、外部のDLLを特定のフォルダに放り込むだけで機能が拡張される。これこそが、「プラグインアーキテクチャ」の真髄だ。
本稿では、VB.NETにおいて `Assembly.LoadFrom` を駆使し、インターフェース（契約）による分離を実現する、堅牢で拡張性の高い設計手法を伝授する。
1. なぜ「If文の羅列」ではいけないのか
多くの開発者が陥る罠は、以下のような実装だ。
' 【アンチパターン：これではプロとは言えない】
Public Sub ExecuteModule(moduleType As String)
Select Case moduleType
Case "ExcelExport"
Dim exporter As New ExcelExporter()
exporter.Export(data)
Case "PdfExport"
Dim exporter As New PdfExporter()
exporter.Export(data)
' 新しい機能が増えるたびに、ここを書き換え、再ビルドが必要になる...
End Select
End Subこの設計の欠点は明白だ。新機能（`CsvExport`など）を追加するたびに、本体プログラムのソースコードを修正し、テストし、再配布しなければならない。これは「Open/Closed Principle（開放閉鎖の原則）」に真っ向から反する。
目指すべきは、「本体は『何ができるか（インターフェース）』を知っているが、『誰がどうやるか（実装）』は知らない」という状態だ。
2. 三層構造の設計戦略
堅牢なプラグインシステムを構築するには、プロジェクトを以下の3つに分離する必要がある。
1. Contract Project (共通インターフェース層): 本体とプラグインが共有する「契約書」。
2. Plugin Project (実装層): 実際の業務ロジックを記述するDLL。
3. Host Application (本体層): DLLを動的に読み込み、実行するメインプログラム。
Step 1: Contract Project（契約の定義）
まず、本体とプラグインが共通して参照する、軽量なクラスライブラリを作成する。ここにはロジックは書かない。「型」の定義のみを行う。
' Project: MyApp.Contract (Class Library)
Public Interface IPlugin
''' <summary>
''' プラグインの識別名を取得する
''' </summary>
ReadOnly Property PluginName As String
''' <summary>
''' 実行可能な機能のカテゴリ（例：帳票出力、計算など）
''' </summary>
ReadOnly Property Category As String
''' <summary>
''' メインの処理を実行する
''' </summary>
''' <param name="inputData">処理対象のデータ（汎用的なObject型、または共通のDTO）</param>
''' <returns>実行結果のステータス</returns>
Function Execute(inputData As Object) As PluginResult
End Interface
''' <summary>
''' プラグインの実行結果を格納する構造体
''' </summary>
Public Class PluginResult
Public Property IsSuccess As Boolean
Public Property Message As String
Public Property ErrorDetails As Exception
End Class> Architect’s Note: 戻り値に `String` ではなく `PluginResult` クラスを使うのがプロの作法だ。エラー内容や成否を構造化して返すことで、本体側でのエラーハンドリングが劇的に容易になる。
Step 2: Plugin Project（実務ロジックの実装）
次に、実際の機能を持つDLLを作成する。このプロジェクトは `MyApp.Contract` を参照する。
' Project: MyApp.Plugins.Excel (Class Library)
Imports MyApp.Contract
Public Class ExcelExportPlugin
Implements IPlugin
Public ReadOnly Property PluginName As String Implements IPlugin.PluginName
Get
Return "Excel帳票出力モジュール"
End Get
End Property
Public ReadOnly Property Category As String Implements IPlugin.Category
Get
Return "Export"
End Get
End Property
Public Function Execute(inputData As Object) As PluginResult Implements IPlugin.Execute
Try
' --- ここに実際の業務ロジック（Excel操作など）を記述 ---
Console.WriteLine("Excel出力処理を実行中...")
' 擬似的な成功処理
Return New PluginResult With {
.IsSuccess = True,
.Message = "Excelファイルの出力に成功しました。"
}
Catch ex As Exception
' プラグイン内部のエラーは、本体を落とさずに捕捉して返す
Return New PluginResult With {
.IsSuccess = False,
.Message = "Excel出力中にエラーが発生しました。",
.ErrorDetails = ex
}
End Try
End Function
End ClassStep 3: Host Application（動的読み込みの心臓部）
いよいよ本体だ。ここでは `System.Reflection` を使い、フォルダ内のDLLをスキャンして `IPlugin` を実装しているクラスを探し出す。
' Project: MyApp.Host (Windows Forms / Console)
Imports System.Reflection
Imports System.IO
Imports MyApp.Contract
Public Class PluginLoader
''' <summary>
''' 指定されたディレクトリからプラグインを読み込む
''' </summary>
''' <param name="pluginDirectory">DLLが格納されているパス</param>
''' <returns>見つかったIPluginのリスト</returns>
Public Function LoadPlugins(pluginDirectory As String) As List(Of IPlugin)
Dim plugins As New List(Of IPlugin)()
If Not Directory.Exists(pluginDirectory) Then
Directory.CreateDirectory(pluginDirectory)
Return plugins
End If
' ディレクトリ内の全てのDLLファイルを走査
Dim dllFiles = Directory.GetFiles(pluginDirectory, "*.dll")
For Each dllPath In dllFiles
Try
' Assemblyを動的にロード
Dim assembly As Assembly = Assembly.LoadFrom(dllPath)
' Assembly内の全型をチェック
For Each type In assembly.GetTypes()
' IPluginインターフェースを実装しており、かつインターフェース自体ではないクラスを探す
If TypeOf type IsOf(GetType(IPlugin)) AndAlso Not type.IsInterface AndAlso Not type.IsAbstract Then
' インスタンスを生成してリストに追加
Dim pluginInstance As IPlugin = DirectCast(Activator.CreateInstance(type), IPlugin)
plugins.Add(pluginInstance)
End If
Next
Catch ex As Exception
' 特定のDLLが壊れていても、他のプラグインの読み込みを継続させる
Debug.WriteLine($"Failed to load DLL: {dllPath}. Error: {ex.Message}")
End Try
Next
Return plugins
End Function
' 型判定の補助（VB.NETの型チェック用）
Private Function IsOf(Of T)(targetType As Type) As Boolean
Return GetType(T).IsAssignableFrom(targetType)
End Function
End Class3. 実務で運用するための「極限の知見」
このアーキテクチャを実戦投入する際、君が直面するであろう壁と、その回避策を伝えておく。
① エラーの隔離（Isolation）
プラグインは「外部の人間が書いたコード」だと疑え。プラグイン内で `NullReferenceException` が発生したとき、本体（Host）のメインループまで巻き込んでクラッシュさせてはいけない。
必ず `Execute` メソッド内は `Try…Catch` で囲い、エラーを `PluginResult` に封じ込めて返却する設計を徹底せよ。
② DLL Hell（依存関係の地獄）への対策
プラグインが別のライブラリ（例：`Newtonsoft.Json`）に依存している場合、本体のディレクトリにそのDLLがないと、`Assembly.LoadFrom` は失敗する。
- 対策: プラグインの配布時には、依存するDLLも全て同じフォルダに同梱する運用ルールを徹底するか、`AppDomain`（.NET Frameworkの場合）による隔離を検討せよ。
③ ファイル・データベース連携の注意点
プラグインにデータベース接続文字列を直接渡してはいけない。それはセキュリティ上の脆弱性であり、保守性を下げる。
- 推奨: `Execute(inputData As Object)` の `inputData` に、あらかじめ接続情報や権限情報を含めた「コンテキストオブジェクト」を渡す設計にせよ。プラグインが勝手にDB構成を弄ることを防ぐため、データアクセスは抽象化されたインターフェース経由で行わせるのが理想だ。
結論：設計は「未来の自分」への贈り物である
今回紹介した `Assembly.LoadFrom` を用いた設計は、一見するとコード量が増えて面倒に感じるかもしれない。しかし、一度この「型による契約」を確立してしまえば、ビジネス要件がどれほど激変しようとも、君の本体プログラムは揺るぎない安定性を保ち続ける。
「変更に強いコード」とは、変更を拒絶するのではなく、変更を「外側」から受け入れるコードのことだ。
このアーキテクチャをマスターし、単なるプログラマーから、システムの「設計者（アーキテクト）」へと昇華してほしい。
