dotInsights 2026年9月号から見える.NET開発の現在地
JetBrainsの.NET開発者向けニュースレター「dotInsights」2026年9月号では、.NET 11の性能改善、ASP.NET Coreの認証とCSRF対策、Blazorや.NET MAUI、Kubernetes運用に加えて、AIコーディングエージェントを開発プロセスへ組み込むための話題が取り上げられています。
今回の内容で特に注目したいのは、AIがコードを生成できるかどうかではありません。AIエージェントを、既存の.NET開発環境やレビュー、セキュリティ、運用プロセスの中で、どの範囲まで安全に動かせるかという点です。
AIエージェントは「自動実装」ではなく「開発環境との接続」が焦点
ニュースレターでは、RiderがAIエージェントにリファクタリングエンジンへのアクセスを提供する話題や、Cursor、Antigravity、AIファーストのエディターと組み合わせた.NETワークフローが紹介されています。
ここから得られる実務上の示唆は、AIエージェントの品質がモデルの性能だけで決まらないということです。エージェントが次のような開発環境の情報や機能を利用できるほど、単なるテキスト生成から、リポジトリを理解した作業へ近づきます。
- ソリューション全体のプロジェクト構成
- C#の型情報や参照関係
- コンパイラーや静的解析の結果
- リファクタリングなどIDEが提供する構造化された操作
- テスト、ビルド、フォーマッターの実行結果
C#コンパイラーであるRoslynはオープンソースで、コードの解析や生成に利用できるAPIを公開しています。こうした既存の開発基盤とAIエージェントが連携すれば、AIが文字列としてコードを出力するだけでなく、コードベースの構造を踏まえた変更を提案しやすくなります。
ただし、AIにリファクタリング権限を与えることは、便利さと同時に変更範囲の拡大も意味します。実務では、次のような段階的な導入が現実的です。
- まずは読み取りと変更案の作成に限定する
- テストと差分レビューを人間が確認する
- 影響範囲の小さいリファクタリングから自動適用する
- 本番設定や認証関連コードは、別の承認フローを設ける
MCP連携では「何を呼び出せるか」を管理する
「Consuming MCP Servers from .NET」では、.NETアプリケーションがMCPサーバーのクライアントになるケースが扱われています。MCPを使うと、AIやアプリケーションから外部のツールやデータソースへ接続する構成を考えやすくなります。
一方で、接続できること自体が価値になるわけではありません。重要なのは、エージェントやアプリケーションにどの操作を許可するかです。たとえば社内システムや開発環境へ接続する場合、次の観点を設計に含める必要があります。
- 利用可能なツールを用途ごとに限定する
- 読み取り操作と書き込み操作を分離する
- 実行者、呼び出したツール、引数、結果を監査できるようにする
- 秘密情報をプロンプトやツール結果へ不用意に含めない
- 失敗時やタイムアウト時の再実行方針を決める
MCP連携は、AIに社内のあらゆる操作権限を渡す仕組みではありません。AIが利用できる能力を、通常のアプリケーションAPIと同じように設計・認可・監視することが、導入時の基本になります。
複数のコーディングエージェントを使うなら役割分担を先に決める
複数のコーディングエージェントを同時に扱う方法も、今回のニュースレターで取り上げられています。複数のエージェントを使えば作業量を増やせる可能性がありますが、単純に人数を増やすような感覚で導入すると、競合や重複作業が発生します。
運用する際は、エージェントごとに責務を分けると管理しやすくなります。
- 仕様を整理し、受け入れ条件を作るエージェント
- 実装を担当するエージェント
- テストや静的解析を担当するエージェント
- 差分のリスクと設計上の問題を確認するエージェント
同じファイルを複数のエージェントが同時に変更する運用は避け、作業ブランチや対象ディレクトリを分離することも重要です。最終的なマージ判断は、CIの結果と人間によるレビューを前提にすべきです。
AIエージェントの導入効果を測る場合も、生成行数ではなく、次のような指標を見る方が実務に適しています。
- レビューで修正された変更の割合
- テスト失敗やビルド失敗の件数
- 手戻りに要した時間
- リリース後の不具合やロールバックの件数
- 開発者が要件整理や設計に使えるようになった時間
.NET 11の性能改善は、ベンチマークと運用コストで判断する
ニュースレターには「.NET 11 Performance Edition」や、C#におけるIPアドレス解析の高速化、オブジェクト初期化子の可読性と性能、Kubernetes環境でのメモリ使用量削減といった話題も含まれています。
これらは、AIエージェントとは別の話に見えます。しかし実際には、AIを活用してコード変更を増やすほど、性能検証とリソース管理の重要性は高まります。AIが生成したコードをそのまま採用するのではなく、アプリケーションのボトルネックを計測し、変更前後で比較する必要があります。
特にコンテナ環境では、メモリ使用量の増加がインスタンス数や再起動頻度に影響します。性能改善を検討する際は、単一のベンチマーク結果だけでなく、次の観点を組み合わせて評価します。
- 実際の入力データに近いベンチマーク
- レイテンシーとスループット
- GCや割り当て量
- Kubernetes上でのメモリ使用量と再起動状況
- クラウド環境での実行コスト
「速くなったコード」を作ることより、どの条件で、どの程度の効果があり、運用コストがどう変化したかを説明できることが重要です。
認証・CSRF対策はAI生成コードのレビュー対象にする
ASP.NET Core Authenticationの内部動作や、Fetch Metadataヘッダーを利用した自動CSRF保護も紹介されています。認証やCSRF対策は、AIに実装を任せやすい一方で、誤った前提が重大な問題につながりやすい領域です。
AIが生成した認証コードをレビューする際は、実装の見た目だけでなく、アプリケーションの通信方式と脅威モデルを確認します。
- Cookieベースの認証か、トークンベースの認証か
- ブラウザーから送信される認証情報の扱い
- クロスサイトリクエストをどのように判定するか
- API、画面、外部連携で異なる保護要件がないか
- 認証失敗時に機密情報を返していないか
Fetch Metadataヘッダーを利用する保護も、アプリケーションの構成や対応クライアントを踏まえて設計する必要があります。認証・認可・CSRF対策は、AIにコードを書かせる場合でも、セキュリティ設計とテストケースを人間が定義する領域です。
.NET開発チームが今取り組むべきこと
今回のdotInsightsから見えるのは、AIと.NETが別々に進化しているのではなく、IDE、コンパイラー、テスト、認証、クラウド運用までを含む開発体験全体が変化しているということです。
導入を検討するチームは、まず次の順序で小さく始めるとよいでしょう。
- 対象をドキュメント作成、テスト生成、局所的なリファクタリングに限定する
- リポジトリの機密情報や本番操作をAIの対象外にする
- CIでビルド、テスト、静的解析を必須にする
- RiderなどIDEの解析結果とAIの提案を比較する
- MCPや外部ツールの接続は、読み取り専用から始める
- 品質、手戻り、レビュー負荷を計測して継続判断する
AIエージェントは、開発者の代わりに責任を負う存在ではありません。Riderのリファクタリング機能、Roslynの解析基盤、.NET 11の性能改善、ASP.NET Coreのセキュリティ機能を組み合わせ、人間がレビューしやすく、失敗を検出しやすい開発プロセスを作るための補助役として位置づけるのが現実的です。
.NET開発における次の競争力は、AIを使ってどれだけ大量にコードを生成できるかではなく、生成された変更をどれだけ安全に検証し、チームの知識と運用へ組み込めるかによって決まります。
出典： JetBrains Blog