C# Weekly #1: Blazor AIコンポーネントとAG-UIプロトコルの登場、NetWasmによるブラウザ単体ランタイムの模索

C# · Weekly #1

C# Weekly #1: Blazor AIコンポーネントとAG-UIプロトコルの登場、NetWasmによるブラウザ単体ランタイムの模索

csharpC#ウィークリーAgentic UIWebAssembly

データソース:GitHub Releases + 官方博客 + HN

📦 リリース動向

現行の最新安定バージョンは .NET 10.0.12(2026年9月8日リリース)です。既存システムの保守やアップグレードを検討中の企業向けには、前メジャーバージョンの変更点をまとめた C# 14コア機能の解説 もあわせてご参照ください。

また、.NET 11 Release Candidate 1 (RC 1) が2026年9月8日に公開されました(公式ブログは9月24日に最終更新)。本バージョンには商用サポートライセンス(Go-Live)が付与されており、本番環境への投入が正式に許可されています。RC 1における主な強化ポイントは以下の通りです。

変更点実環境への影響
低レイヤーのJITおよびGC最適化よりアグレッシブなインライン展開戦略とメモリ割り当てロジックを導入。高トラフィックなマイクロサービスにおけるコールドスタート時間とメモリ断片化率が大幅に改善され、リソース制約の厳しいコンテナ環境で絶大な効果を発揮します。
C# 15 の機能確定拡張されたパターンマッチング(Pattern Matching)とより柔軟な型推論の仕様が最終確定し、大量のボイラープレートコード(Boilerplate)を削減可能に。複雑なドメインモデルのマッピングやビジネスルールエンジンの保守コストが大幅に低下します。
.NET SDK ツールチェーンの強化MSBuildおよびNuGetの依存関係解決速度が劇的に向上。50以上のプロジェクト依存を持つ大規模ソリューションにおいて、CI/CDパイプラインのビルド時間が約15〜20%短縮されます。

📝 ピックアップ解説

1. AG-UI .NET SDKが正式リリース:AIエージェント対話の標準化

概要:.NETチームはCopilotKitと協業し、AGUI.Server および AGUI.Client ライブラリ(MITライセンス)をNuGet公式フィードで公開しました。このSDKは、従来のMicrosoft Agent Framework(MAF)の通信基盤を標準プロトコルであるAgent-User Interaction(AG-UI)へと置き換えるものです。

なぜ重要か:これまでAIエージェントの開発では、利用するモデルやフロントエンドフレームワークごとに異なるストリーミング形式(Streaming Format)への個別対応が必要でした。AG-UIプロトコルは言語非依存のイベントストリーム規格を提供し、長寿命接続におけるエージェントの振る舞いを RUN_STARTED、TEXT_MESSAGE_CONTENT、STATE_DELTA といった標準イベントへと抽象化します。中核となる ToChatRequestContext や AsAGUIEventStreamAsync メソッドには、複雑な双方向シリアライズや中断処理があらかじめ組み込まれています。

影響範囲:クロスプラットフォームなAIバックエンド開発者。IChatClient をベースにした単一のC# ASP.NET Coreバックエンドを構築するだけで、.NETクライアントのみならずTypeScript(React/Vue)などのフロントエンドエコシステムからもシームレスに利用できるようになります。

参照リンク:AG-UI Protocol now has a first-class .NET SDK

2. Blazor AIコンポーネント:アプリ内のAIインタラクション(Agentic UI)を刷新

概要:最新の .NET 11 RC 1 SDK に合わせ、マイクロソフトは実験的なUIパッケージ Microsoft.AspNetCore.Components.AI を発表しました。中核コンポーネント <ChatPage Agent="_agent" Placeholder="Ask me anything…" /> を配置するだけで、バックエンドで動作する UIAgent の状態ストリームを直接描画・操作できます。

なぜ重要か:単なるテキストベースのチャットUIでは、複雑な業務フローをカバーしきれません。現代のユーザーは、エージェントが実行している中間ステップを可視化し、共有状態(Shared State)を双方向で編集できるインターフェースを求めています。Blazor AIは ContentBlock 機構を備えており、対話内容、ツール呼び出し(Tool Calls)、権限承認アクションなどを具象的なRazorコンポーネントへとマッピングします。背後のエージェントインターフェースは Microsoft.Extensions.AI と直接連携できるほか、AGUIChatClient でラップして前述のリモートエンドポイントと接続することも可能です。

影響範囲:フルスタックBlazor開発者。複雑でバグの温床になりがちなWebSocketやSSEの状態同期ロジックを手書きすることなく、C#の型安全なコンポーネントモデルを活かしてエンタープライズ品質のCopilot画面を低コストに構築できます。

参照リンク:Build Agentic UI with the new Blazor AI components

3. NetWasm登場:わずか82.5KBのブラウザ単体で動く軽量.NETランタイム

概要:Hacker Newsに独立系プロジェクト「NetWasm」が登場し話題を集めています。ブラウザ内で完結する純粋なWebAssembly版.NETコンパイラおよびランタイムを提供しており、コンパイル後の最小「Hello World」C#モジュールのファイルサイズはわずか82.5KBという驚異的な軽量さを誇ります。

なぜ重要か:マイクロソフト公式のNative AOT技術は優れた実行性能を持つ反面、ピュアなフロントエンド環境においてはベースライブラリによるバイナリサイズの肥大化や重量級のビルドツールチェーンがボトルネックとなっていました。NetWasmはサーバーサイドでの重厚なコンパイルを完全にバイパスし、ブラウザ内で軽量な csc コンパイルを実行して極小のWasmモジュールを出力・実行します。

影響範囲:バンドルサイズにシビアなフロントエンド開発者やWebAssemblyのギーク層。現時点ではプロトタイプ段階(式ツリーやWeb Workersによるマルチスレッドは未実装)ですが、C#を用いた軽量フロントエンドプラグイン開発において極小ランタイムの実現可能性を実証しました。

参照リンク:NetWasm Playground | HN 討論

4. C#ネイティブでのプロセスダンプ(Memory Dump)生成とモダン相互運用

概要:.NETチームは、通常のログ記録では追跡が極めて困難な「スレッドプールの枯渇(Thread Pool Saturation)」などの障害に対処するため、C#コード内部から自動的にメモリダンプをトリガーする自己診断メカニズムの解説記事を公開しました。

なぜ重要か:従来、メモリダンプの取得はSysinternalsのProcDumpやLinuxの管理者権限コマンドなど、外部ツールに依存するのが一般的でした。今回紹介された手法では、独立した ThreadPoolWatcher スレッドを走らせてバックグラウンド Task の遅延時間を定期計測。遅延がしきい値を超えた瞬間に、Windows環境では dbghelp.dll(MiniDumpWriteDump)、Linux環境では組み込みの createdump ユーティリティを自動呼び出しし、125MB〜800MB規模のダンプを保存します。あわせて、コード例のディスカッションでは、旧来の [DllImport] とモダンなC#のソースジェネレーター(Source Generator)を用いた [LibraryImport] の性能面での使い分けについても議論が交わされました。

影響範囲:バックエンド/マイクロサービスアーキテクトおよびSRE・運用エンジニア。この「自己トリガー型診断」パターンを導入することで、本番障害発生時の調査データ収集が自動化され、デッドロックやリソース枯渇トラブルにおける平均復旧時間(MTTR)を大幅に削減できます。

参照リンク:Creating a memory dump in C#

🔥 コミュニティの話題

1. 軽量独自ランタイム vs 公式Native AOT:Wasm戦略を巡る対立

NetWasmのShow HN(5 points / 4 comments)を契機に、WebAssemblyエコシステムにおけるC#の進化方針について議論が巻き起こりました。 主な対立点:

  • フルスペック追従派:サードパーティ製ランタイムであっても最新のC#言語仕様を忠実に実装すべきと主張。バックエンドやデスクトップ向けの既存コードを修正なしでブラウザへ持ち込める言語の一貫性こそが最大の価値であるとする立場。
  • 徹底スリム化派:ブラウザのサンドボックス環境において完全な互換性を求める必要はないと反論。Wasmのメモリモデルに最適化した「C#の軽量サブセット」を策定し、オブジェクト指向の歴史的オーバーヘッドを切り捨ててでも初期ロードとパース速度を極限まで追求すべきとする立場。

参照リンク:Show HN: NetWasm

2. Yengi:個人ゲーム開発者が生み出した「自己修復型」AI開発環境

教職出身の個人開発者が、.NET 8をベースに構築したAI 3Dゲーム制作ツール「Yengi」をオープンソースで公開(HN 2 points、RedditやGitHubでも注目)。 注目されたコアアーキテクチャ:

  • Unityエディタと低レイヤーのTCPソケット通信で常時接続し、独自設計の「Self-Healing Repair Agent Loop(自己修復エージェントループ)」を組み込んでいる点が最大の特徴です。
  • 一般的な静的コード生成とは異なり、AIが生成したC#スクリプトに構文エラーや実行時例外が発生した場合、ホスト環境がスタックトレースを即座にキャプチャしてLLMへ直接フィードバック。その場で自律修正とホットリロードを実行します。C#の強型付けリフレクションとRoslynの動的コンパイルを融合させたこのAgentic Workflowは、個人開発者の試行錯誤に伴うイテレーションコストを劇的に引き下げています。

参照リンク:GitHub - Yengi | HN 討論

来週の注目トピック

.NET 11の正式版は、今年11月に開催される「.NET Conf 2026」にてリリースされる予定です。それに先立ち、最後のプレビュー版となるRC 2が今後2週間以内に登場する見通しです。最終盤のRC 2フェーズでは最優先のバグ修正のみが適用され、パブリックAPIの変更は原則として凍結されます。各開発チームにおかれましては、現在のRC 1を活用して基幹業務ライブラリ(Entity Framework Coreやリフレクションを多用する外部gRPCライブラリなど)の回帰テストを速やかに進め、11月の本番移行に向けた準備を進めることを推奨します。