こんにちは！開発現場で日々、コードと格闘お疲れ様です。
マクロの記録や、決まりきったフォームの貼り付け作業から一歩抜け出し、「もっとスマートで拡張性の高いシステムを作りたい」と感じていませんか？
今回は、VB.NETの中上級者への登竜門であり、大規模な業務アプリケーション開発では必須のテクニックである「動的アドイン機構（プラグイン型アーキテクチャ）」の極意を伝授します。
「本体をいじらずに、あとから機能を追加・差し替えたい」
そんな現場の切実な願いを、`AssemblyName` と `Assembly.LoadFrom` を使って鮮やかに解決する方法を、一緒に見ていきましょう！ここをクリアすれば、あなたのVB.NETのスキルは間違いなくプロフェッショナル領域に到達しますよ。
—
なぜ「プラグイン型アーキテクチャ」が必要なのか？
皆さんが普段作っている業務アプリケーション、例えば「受発注管理システム」を想像してください。
ある日、上司からこう言われます。
「新しい形式のCSV出力機能を追加してほしいんだけど、本体のソースコードはテスト中だから触らないでよね。あと、来月になったら別のフォーマットも追加するかもしれないからよろしく！」
……本体のビルドとデプロイをやり直さず、追加したい機能だけを「独立したDLL」として後からポトッとフォルダに放り込むだけで、勝手に認識して動き出しくれたら最高だと思いませんか？
これを実現するのが、動的アセンブリ読み込みです。VB.NETのパワフルな .NET の世界では、これが驚くほどエレガントに実現できます。
—
全体像の把握：3つの要素
プラグイン機構を作るために必要な登場人物は、たったの3つです。
1. 共通インターフェイス（Contracts）: 本体とプラグインが守るべき「共通の契約書（お約束）」。
2. メインアプリケーション（Host）: プラグインを読み込み、実行する本体。
3. プラグイン（Add-in / DLL）: 実際の機能が詰まった独立したプロジェクト。
まずは、この関係性を頭に思い浮かべながら、コードを書いていきましょう。
—
ステップ1：お互いの共通言語「インターフェイス」を定義する
まずは、本体とプラグインの橋渡しをする共通の「設計図（インターフェイス）」を作ります。これは独立したクラスライブラリ（Class Library）としてプロジェクトを分け、双方が参照するようにします。
‘ 【プロジェクト名: PluginContract】
‘ 共通のインターフェイス定義
Public Interface IBusinessPlugin
‘ プラグインの表示名
ReadOnly Property PluginName As String
‘ 実行メイン処理
Sub Execute(ByVal contextData As String)
End Interface
> 💡 先輩からのワンポイントアドバイス
> このインターフェイスこそが命綱です。本体はこの `IBusinessPlugin` しか知りません。中身がどう書かれているかは気にせず、「`Execute` さえ叩けば動く」という信頼関係をここで結びます。
—
ステップ2：実際に動くプラグインを作る（別プロジェクト）
次に、先ほどのインターフェイスを実装した実際の機能（プラグイン）を別のプロジェクトで作ります。これがコンパイルされて `CoolPlugin.dll` というファイルになります。
‘ 【プロジェクト名: CoolPlugin (Class Library)】
‘ 参照設定に PluginContract.dll を追加しておくこと
Imports PluginContract
Public Class WonderfulExportPlugin
Implements IBusinessPlugin
‘ プラグイン名を返す
Public ReadOnly Property PluginName As String Implements IBusinessPlugin.PluginName
Get
Key = “超すばらしいCSV出力プラグイン”
Return Key
End Get
End Property
‘ 実際の処理
Public Sub Execute(contextData As String) Implements IBusinessPlugin.Execute
‘ ここに実際の業務ロジックを書く（ファイルの書き出しやAPI通信など）
Console.WriteLine($”[プラグイン実行] 受け取ったデータ処理中…: {contextData}”)
‘ 実際の現場ではここにファイル出力処理などを記述します
End Sub
End Class
—
ステップ3：本体（Host）でプラグインを動的にロードする！
いよいよ本丸です。メインのアプリケーション側で、指定したフォルダにあるDLLを探し出し、`Assembly.LoadFrom` を使ってメモリ上にロードします。
ここが今回のメインテーマ、AssemblyName と Assembly.LoadFrom の見せ場です！
‘ 【プロジェクト名: MainHostApp (Console / Windows Forms)】
‘ 参照設定に PluginContract.dll を追加（本体はPlugin自体のプロジェクトは参照しない！）
Imports System.IO
Imports System.Reflection
Imports PluginContract
Module MainModule
Sub Main()
‘ プラグインを格納するフォルダパス
Dim pluginDir As String = Path.Combine(AppDomain.CurrentDomain.BaseDirectory, “Plugins”)
If Not Directory.Exists(pluginDir) Then
Console.WriteLine(“プラグインフォルダが存在しません。”)
Return
End If
‘ フォルダ内のすべてのDLLファイルを検索
Dim dllFiles As String() = Directory.GetFiles(pluginDir, “.dll”)
Console.WriteLine($”{dllFiles.Length} 個のアセンブリ候補を発見しました。読み込みを開始します。”)
For Each dllPath As String In dllFiles
Try
‘ ★【極意】AssemblyNameを使って、ファイルを実行前に安全に検査する
‘ 実際にメモリにロードする前に、アセンブリのメタデータだけを覗き見ることができます。
Dim asmName As AssemblyName = AssemblyName.GetAssemblyName(dllPath)
Console.WriteLine($”-> 検査中: {asmName.Name} (Version: {asmName.Version})”)
‘ ★【極意】Assembly.LoadFromによる動的ロード
‘ ここで初めてDLLがメモリ上にロードされます
Dim loadedAssembly As Assembly = Assembly.LoadFrom(dllPath)
‘ アセンブリの中から「IBusinessPlugin」を実装している型（クラス）を探す
Dim pluginTypes = loadedAssembly.GetTypes().
Where(Function(t) GetType(IBusinessPlugin).IsAssignableFrom(t) AndAlso Not t.IsInterface AndAlso Not t.IsAbstract)
For Each pType In pluginTypes
‘ 動的にインスタンスを生成（遅延バインディングの極み）
Dim pluginInstance As IBusinessPlugin = CType(Activator.CreateInstance(pType), IBusinessPlugin)
Console.WriteLine($” [成功] プラグインをロードしました: {pluginInstance.PluginName}”)
‘ 実際に実行してみる！
pluginInstance.Execute(“本日の売上データ_20231025.csv”)
Next
Catch ex As Exception
Console.WriteLine($” [エラー] DLLのロードに失敗しました ({Path.GetFileName(dllPath)}): {ex.Message}”)
End Try
Next
Console.WriteLine(“すべての処理が完了しました。”)
Console.ReadLine()
End Sub
End Module
—
現場でありがちな「落とし穴」と回避の極意
この動的ロード機構を実装する際、プログラマが必ずと言っていいほどハマる「罠」があります。先輩として、あらかじめ回避策を授けておきますね。
1. `FileNotFoundException`（ファイルが見つかりません）の呪縛
プラグインDLLが、本体の実行ファイル（`.exe`）と同じ階層ではなく、離れた場所やサブフォルダにある場合、プラグイン内部で参照している別ライブラリ（例えば `PluginContract.dll` など）が見つからずにクラッシュすることがあります。
- 対策: プラグインが必要とする共通インターフェイスのDLLは、必ずメインアプリの実行フォルダ、またはプラグインと同じフォルダに配置するようにビルドイベントを工夫しましょう。
2. アンロード（解放）の難しさ
.NET Framework や初期の .NET Core では、一度 `Assembly.LoadFrom` で読み込んだアセンブリは、アプリケーションを終了するまでメモリからアンロードできません（ファイルがロックされ、上書き更新できない現象が発生します）。
- 対策: 最新の .NET (Core / 5 / 6 / 7 / 8) では `AssemblyLoadContext` という強力な仕組みを使い、プラグインごとに独立したコンテキストを作って「用事が済んだらメモリからきれいに消し去る（アンロードする）」ことが可能です。本番運用でDLLの動的差し替えを行いたい場合は、必ず最新の .NET 環境での `AssemblyLoadContext` の活用を検討してください。
—
まとめ
今回は、VB.NETによる「AssemblyName」と「Assembly.LoadFrom」を活用したプラグイン型アーキテクチャの構築法を解説しました。
- AssemblyName でファイルの素性を安全に検査し、
- Assembly.LoadFrom で動的にメモリへ取り込み、
- Interface を通じて型安全に実行する。
このパターンをマスターすれば、あなたの作るVB.NETアプリケーションは、単なる「動くプログラム」から、拡張性に満ちた「堅牢なプラットフォーム」へと生まれ変わります。
最初は難しく感じるかもしれませんが、コードを実際に組んで、新しいDLLを追加した瞬間に本体がそれを認識して動き出した時の感動はひとしおです。
ぜひ、あなたの開発現場でも試してみてくださいね。応援しています！
