AIエージェント

2026-02-08 — LibraStudio開発記 #1 背景なぜまた別の.NET IDEなのか .NETエコシステムにおけるIDEの選択肢は、実はそれほど広くありません。Visual Studioは強力ですがWindows専用であり、Community Editionでさえ商用利用に制約があります。VS Code + C# Dev Kitの組み合わせも優れていますが、C# Dev Kitがプロプライエタリライセンスである点は変わりません。結局、重要な部分でベンダーロックインが発生し、その上に構築したツールチェーンとワークフロー全体が特定ベンダーの意思決定に依存してしまいます。かつてはSharpDevelopがWindowsで、MonoDevelop（Xamarin Studio）がクロスプラットフォームでその役割を担っていました。しかしSharpDevelopは2017年に開発が停止し、MonoDevelopはXamarinに統合された後、事実上スタンドアロンIDEとしての役目を終えました。それ以降、最新の.NET（Core以降）開発環境を適切にサポートするオープンソースでリベラルライセンスのクロスプラットフォームIDEは登場していません。この点がずっと惜しいと感じていました。そこでLibraStudioを始めました。ElectronやVS Codeベースではなく、純粋な.NETネイティブIDEを目指します。一人でVisual Studioレベルのものを作ろうというわけではありません。しかし2026年にはAIベースのコードエディタの力を借りることができます。AIエージェントにフレームワークAPIの探索、ボイラープレートの生成、繰り返しの実装を委任すれば、一人でカバーできる範囲は過去とはまったく異なります。 UIフレームワークにはAprillz.MewUIを使用しています。NativeAOTに対応し、XAMLなしでC#コードだけでUIを構築する軽量フレームワークです。このフレームワークは、私と同じく韓国の代表的な.NET開発者コミュニティであるDotNetDev（.NET Dev、https://forum.dotnetdev.kr/）で活動しているソン・ヨンジェ氏のオープンソースプロジェクトです。 AIが知らない新生フレームワークという難関 MewUIはまったく新しいコンセプトの新生UIフレームワークです。XAMLベースのWPFやAvaloniaUIとは異なり、純粋なC# fluent APIでUIを構築する独自の設計を持っています。当然、公式ドキュメントが豊富ではなく、Stack Overflowに関連する質問が蓄積されてもいません。これに.NETというプラットフォーム自体の問題も重なります。大規模言語モデルの学習データにおいて、.NET/C#はJavaScriptやPythonに比べて相対的に学習頻度が低いです。メジャーフレームワークであるWPFやWinFormsでさえ不正確なコードを生成することがあるのに、学習データにほとんど含まれていないMewUIのAPIを正確に当てる可能性は極めて低いです。このような状況でAIコーディングエージェントに「最小限のタブベースのテキストエディタを作ってください」と依頼すると、何が起こるでしょうか。一般的なアプローチ：推測と反復通常のAIコーディングエージェントのワークフローは次のとおりです：学習データから類似のAPIを思い出してコードを書きますビルドしますエラーが出たらエラーメッセージを見て修正します 2〜3を繰り返しますこの方式は、学習データに豊富に含まれているメジャーフレームワーク（WPF、React、SwiftUIなど）ではうまく機能します。しかし、MewUIのようにまったく新しいコンセプトの新生フレームワーク――しかも相対的に学習頻度が低い.NETベース――では、推測の精度が極めて低くなります。メソッド名、パラメータの順序、オーバーロードの有無、イベントシグネチャ――すべてが外れる可能性があります。別のアプローチ：アセンブリを直接覗く今回の作業では、私自身が開発したHandMirror MCPを使用しました。HandMirrorは、NuGetパッケージのコンパイル済みアセンブリを直接検査するMCP（Model Context Protocol）サーバーです。 Webドキュメントを検索する代わりに、実際の.dllを分析し、次の情報を返します。注目すべきは、HandMirrorが一般的な.NETリフレクション（System.Reflection）ではなくMono.Cecilを使用している点です。Cecilは.NETアセンブリのメタデータをランタイムロードなしに直接読み取るため、検査対象アセンブリの.NETランタイムバージョンに影響されません。.NET Framework 4.x用ライブラリでも.NET 10対象でも同様に分析できます：すべての名前空間と型の一覧各型のコンストラクタ、プロパティ、メソッド、イベントのシグネチャ Extension methodがどの名前空間にあるか継承階層構造実際に得られた情報 Aprillz.MewUI v0.9.1を検査した結果： 178個のパブリック型、14個の名前空間 MultiLineTextBoxがTextBaseを継承し、Text、Placeholder、AcceptTab、Wrap、IsReadOnlyなどのプロパティを持つこと TabControl.SelectionChangedがAction<int>であること（ドキュメントがなければAction<TabItem>と推測していたでしょう――実際そうでした） FileDialog.OpenFile()がOpenFileDialogOptionsを受け取り、Title、Filter、Ownerなどのプロパティを持つこと Menu.Item()とContextMenu.Item()のオーバーロードが異なること――Menu.Itemにはショートカット文字列パラメータがない ObservableValue<T>がSubscribe()、NotifyChanged()、Set()メソッドを持つことこの情報だけで、エディタのコアコードをほぼ正確に記述できました。結果：初回ビルドでエラー3個コード全体を書き上げた後、初回ビルドで発生したエラーはわずか3個でした：エラー原因 Menu.Item("text", "shortcut", action) — オーバーロードなし ContextMenu.ItemにしかないショートカットパラメータをMenu.Itemでも使用 BorderThickness(0, 1, 0, 0) — 4パラメータのオーバーロードなし実際にはBorderThickness(double)の単一パラメータのみ存在 SelectionChangedの型不一致 HandMirrorがAction<int>と教えてくれたが、コードで誤ってAction<TabItem>を使用 3つ目は純粋に読み取った情報をコードに誤って反映したミスでした。HandMirrorが提供した情報自体は正確でした。 ...