ソースコードが無い .NET DLL を AI から呼び出せる形にした話
はじめに
前回の記事では、既存の .NET デスクトップアプリのソースコードを仕様書として扱い、AI から呼び出せる Agent / Skill に再構成する方法を紹介しました。
今回はその続編として、ソースが手元に無く DLL しか残っていない場合 にどう対処したかをまとめます。
現場でよくあるのは、こういうケースです。
- 外部ベンダー提供の DLL で、ソースが開示されていない
- 古いサブシステムでソース一式が紛失している
- ビルド環境が失われ、再コンパイルできない
動いてはいるのに中身を追えない DLL が、現役で使われ続けているという状況です。
方針：DLL を逆コンパイルして仕様書代わりにする
ソースが無いのなら、DLL 自体を仕様書にしてしまうというのが今回の発想です。
使ったのは OSS の ilspycmd。DLL から C# コードを復元できる CLI ツールで、メソッドのシグネチャだけでなく、内部の SQL 文やバリデーションロジックまで読み取れます。
前回の「ソースが AI の仕様書になる」を一段広げて、
逆コンパイル結果が AI の仕様書になる
という方針で進めました。
生成ユーティリティの位置づけ
前回紹介したユーティリティ Skill 群に、今回 DLL 専用の生成 Skill を追加しました。
| Skill | 入力 | 役割 |
|---|---|---|
| function-skill-creator | ソースコード | Skill を生成 |
| dll-skill-generator（新規） | DLL バイナリ | 逆コンパイル経由で Skill を生成 |
使い分けはシンプルです。
- ソースがある → function-skill-creator
- DLL しか無い → dll-skill-generator
成果物（SKILL.md + run.py）は両者とも同じ形式なので、ソースの有無を意識せずに Skill を扱えるのがポイントでした。
生成フロー
処理はおおまかに次の流れです。
DLL
↓ クラス一覧の取得
↓ 対象クラスをフィルタ（DataAccess / Service / DAL 等）
↓ クラス単位で C# に逆コンパイル
↓ メソッドのシグネチャ・内部ロジックを抽出
↓ テンプレートに流し込んで run.py を生成
↓ SKILL.md に逆コンパイル由来情報を付与
Skill 成果物
肝になるのは、クラスとメソッドのフィルタです。
DLL の中身を全部 Skill 化してしまうと、UI コードや内部ヘルパーまで候補に入って、AI が何を呼ぶべきか迷います。そこで、
- 対象にするのは 業務ロジックを持つクラス（DataAccess / Service / DAL 系）
- 対象にするのは public メソッド のみ（非同期ペアやプロパティは除外）
- デフォルトでは 取得系（Select / Get 系）のみ生成 し、更新系は明示指定が必要
というルールを置き、AI に見せる Skill の粒度を揃えるようにしました。
逆コンパイルからどこまで読めるか
シグネチャだけでなく、メソッドの中身も読めるのがこのアプローチの強みです。
- 埋め込まれた SQL 文 → どのテーブルを見ている Skill か分かる
-
if (string.IsNullOrEmpty(...))→ 必須パラメータが特定できる -
dt.Columns.Add(...)→ 戻り値のカラム一覧が推定できる
これらを SKILL.md の「内部動作」セクションに転記しておくと、AI が Skill を選ぶときの判断材料になります。
難読化されていない社内 DLL であれば、業務判断に必要な情報はほぼ拾えました。
生成される SKILL.md のイメージ
成果物には、逆コンパイル由来であることを明示しておきます。
## 対応する元コード
- 元言語: C#（ilspycmd で逆コンパイル）
- 元クラス: Sample.Namespace.SampleService
- 元メソッド: GetSampleInfo(...)
- DLL: SampleService.dll
将来ベンダーから正式なソースが提供されたときに、どの Skill を作り直すべきかを判定する目印にもなります。逆コンパイル由来の Skill は、あくまでソースが戻るまでのブリッジという位置づけです。
実行イメージ
DLL のパスと親 Agent を指定するだけで、中のクラス・メソッドを一括で Skill 化します。
生成完了: SampleService.dll
- 対象クラス: 2個
- 生成Skill: 5個（取得系のみ）
- 除外メソッド: 8個
DLL を放り込むだけで、その業務の取得系 API が自然言語から呼べる状態になるのが狙いです。
メリット
- ✅ ソース無しでも既存資産を活用できる
- ✅ function-skill-creator と成果物が揃う（後からソース版に差し替え可能）
- ✅ 更新系を安全側に倒せる（デフォルトは取得系のみ）
- ✅ 内部ロジックまで拾える（SQL・必須パラメータ・戻り値カラム）
注意点
難読化 DLL は対象外
クラス名・メソッド名が潰されていると、逆コンパイルできても意味が読み取れません。
取得系と更新系の線引き
業務インパクトが読み切れないため、デフォルトは取得系のみ。更新系を公開する場合は、認証・権限管理・確認プロンプトを必ず前段に置きます。
まとめ
- 前回：既存ソースを仕様書として Skill 化（function-skill-creator）
- 今回：既存 DLL を逆コンパイルして Skill 化（dll-skill-generator）
この 2 本立てで、ソースの有無に関わらず既存資産を AI の入り口につなげることができるようになりました。
長年運用されてソースが追いにくくなった DLL を抱える現場ほど、全面再構築に踏み込まずに AI 連携へ進められる選択肢として有効だと感じています。