息の長い.NETプログラミングフルグラフ対応

MaguyvaのC#対応: .NETコードベースをより安全にリファクタリング

MaguyvaはAST解析とシンボル抽出によりC#に対応しており、AIエージェントは.NETサービス、LINQを多用したビジネスロジック、共有ライブラリ、そして長期運用されているエンタープライズリポジトリを横断して作業できます。

成熟した.NETコードベースで重要なこと

AIツールを使うチームの多くは、グリーンフィールドのJavaScriptではなく.NETの世界に住んでいます。APIがあり、ワーカープロセスがあり、共有モデルがあり、社内ライブラリがあり、そして何年分ものビジネスロジックがあります。問題はLLMがC#の構文を出力できるかどうかではありません。1つの誤った編集がサービス、モデル、共有の抽象化へと波及しかねないリポジトリの中で、根拠を保ち続けられるかどうかです。

だからこそ、C#のページは「対応しています」よりも具体的である必要があります。

MaguyvaがC#で実際に抽出するもの

Maguyvaはusingインポートを正規化し、?や[]のようなnullableや配列のサフィックスを定義から取り除き、コンストラクタ的な呼び出しノードをジェネリック括弧を除去した上でインスタンス化として扱います。これらはクラス中心のC#リポジトリにおいて有用な処理であり、実際のドメイン型を中心にグラフをすっきりさせます。

この設定は、BCLとLINQのノイズも大量にフィルタリングします。これは見た目以上に重要です。成熟した.NETコードベースでは、フレームワーク呼び出しに支配されたグラフはあまり役に立ちません。役立つグラフとは、リポジトリ固有のコントローラー、サービス、DTO、ヘルパークラスがなお際立つグラフです。

.NETコードベースに役立つMCPワークフロー

実践的な流れは、たいてい次のように始まります。

find_symbol — コントローラー、サービス、DTO、モデルの名前が分かっているとき。
dependency_search — 広く参照されている可能性のある共有サービスや型を編集する前に。
get_task_context — 「このリクエストをコントローラーからリポジトリまで追う」のようなプロンプトで、パスが複数の層にまたがるとき。

このページが役立つ場面

このページは、単なるおもちゃのプロジェクトではなく、実際の.NETコードベースの中でAI支援を求めるチームのためのものです。周囲のシステムが.NETよりもJVM寄りである場合は、Javaと比較してください。C#層がより大きなポリグロットシステムの一部にすぎない場合は、隣接するTypeScriptのページも参考になるはずです。

最適な用途

>Webエンドポイント、ジョブ、共有ライブラリが混在する、ASP.NET、ワーカーサービス、社内プラットフォームのリポジトリ。
>LINQ、非同期フロー、フレームワークの抽象化によって実際の実行パスが見えにくくなっている、成熟した.NET資産を保守するチーム。
>ビジネスロジックを書き換える前に、エージェントが階層化された.NETコードの中で根拠を保ち続けられるかを検証するチーム。

エージェントワークフロー

>ビジネスロジックを編集する前に、コントローラー、サービス、リポジトリのパスをたどる。
>モデル、DTO、共有ユーティリティがリポジトリ全体のどこでインスタンス化されているかを調べる。
>エージェントに何かを書き換えさせる前に、周囲のLINQや非同期パターンを理解する。

エンジンの詳細

>importでは `using` プレフィックスが正規化され、シンボル定義からは `?` や `[]` のようなnullableや配列のサフィックスが除去されます。
>インスタンス化は呼び出しノードにジェネリック括弧の除去を適用して扱われるため、グラフ上でコンストラクタ的な使用箇所が読みやすくなります。
>設定では大量のBCLやLINQのノイズを明示的にフィルタリングしており、リポジトリ固有のサービスやモデルを見つけやすくしています。

役立つMCPエントリーポイント

find_symbol
これから触れるcontroller、サービス、DTO、または共有型の名前が分かっているときに使用してください。
dependency_search
アプリケーション全体で使われるコアサービスやモデルを編集する前に、incomingトラバーサルを使用してください。
get_task_context
レイヤー化された.NETコードベースにおいて、「このリクエストをcontrollerからrepositoryまで追跡する」といったプロンプトに便利です。