個人的な目線でのdotnet-runtimeの動向
>100 Views
May 30, 26
スライド概要
2026/05/29に開催された「超dotnet new」の登壇資料になります。
プログラミングが好きな一般C#er。
関連スライド
Meta XR SDK(V66-74)でQuestアプリを開発
あうぜん
1.2M
各ページのテキスト
個人的な目線でのdotnet/runtimeの動向 超dotnet new 2026/05/29 prozolic 1
自己紹介 prozolic（プロゾリック） 業務アプリケーションエンジニア/一般C#er GitHub: @prozolic 最近の趣味: ウォーキング 2
.NET Contributor（2025年9月～） 主にLibrariesの最適化やバグ修正 最近はSystem.Text.Jsonのバグ修正に挑戦 3
話す内容 dotnet/runtimeにマージされたPRの状況 個人的に気になった動向 System.Text.Json - union サポート unsafeからSpanへの移行 ※あくまで個人的な目線での見解です。 4
2026年にdotnet/runtimeのマージされたPRは どれくらいあると思いますか 5
マージされたPRの状況 マージされたPR数は2,945件（PR Digest.NETのデータを用いて集計） JITコンパイラとWASMの対応が活発 NativeAOT関連も活発 6 https://prozolic.github.io/PRDigest.NET
マージPRの状況 - ラベル別TOP10 PR Digest.NETから集計 https://prozolic.github.io/PRDigest.NET/ 7
マージPRの状況 - AI Agentの活用 マージされたPRの約21パーセントは、GitHub Copilotが作成者 （2026/05/26時点） GitHub Copilotで作成したPRをレビューするパターンが多い area-skills ラベルの追加など AI Agentに対するサポートも充実 8
個人的に気になっている動向 9
System.Text.Json の union 対応
.NET 11 preview4 では未対応
エラーは発生しないけど結果がおかしい
public union Result(int, string);
// .NET11 preview 4では、{"Value":"hello"}でシリアライズ
var resultStr = JsonSerializer.Serialize<Result>(new Result("hello"));
// .NET11 preview 4では、Value = null（エラーも発生しない！？）
var deserializedResultStr = JsonSerializer.Deserialize<Result>(resultStr);
10
System.Text.Json の union 対応 mainブランチには対応PRがマージ済 unionの内部値をそのままシリアライズする動作 .NET 11 preview 6に追加される見込み public union Result(int, string); // "hello" var resultStr = JsonSerializer.Serialize<Result>(new Result("hello")); // Result.Value = "hello" var deserializedResultStr = JsonSerializer.Deserialize<Result>(resultStr); 11
unsafeからSpanへ切り替える 2026年4月から、unsafeベースの処理を Span/BitConverter/BinaryPrimitivesなどに変更する対応が増加 reduce-unsafeラベルから追跡可能 12
unsafeからSpanへ切り替える
基本的にSpanの安全なループパターンに変更している
unsafeによるループ
spanベースのループ
ReadOnlySpan<byte> value;
ReadOnlySpan<byte> value;
ref byte pos = ref MemoryMarshal.GetReference(value);
ref byte end = ref Unsafe.Add(ref pos, value.Length);
while (value.Length >= sizeof(int))
{
Add(BitConverter.ToInt32(value));
value = value.Slice(sizeof(int));
}
while (Unsafe.ByteOffset(ref pos, ref end) >= sizeof(int))
{
Add(Unsafe.ReadUnaligned<int>(ref pos));
pos = ref Unsafe.Add(ref pos, sizeof(int));
}
https://github.com/dotnet/runtime/pull/127382
13
unsafeからSpanへ切り替える 切り換える理由を推測すると JITコンパイラでの最適化で、Spanのループパターンがunsafeと同等のコー ド生成できるようになったから C# 16にリリース予定のunsafeの再設計に対する準備のため （これが本命？） 14 https://devblogs.microsoft.com/dotnet/improving-csharp-memory-safety/
インライン化の予算の条件付き拡張 見た目は普通のunsafeを取り除くPR https://github.com/dotnet/runtime/pull/127845 その中に、Hardware Intrinsicsが存在するとコンパイラ側のインライン化の 予算（time budget）を5倍に増加する対応も追加されている 15
インライン化の予算の条件付き拡張 Spanの呼び出しが増加したことで、インライン化の予算が不足し、 ベンチマークが遅くなった 今後のunsafeを取り除く対応で同様のインライン化の予算が不足する可能性 がある if (Vector128.IsSupported || Vector256.IsHardwareSupported) { // こういうケース } 16
まとめ JITコンパイラとWASM（WebAssembly）の対応が活発 AI Agentとの利用が活発 System.Text.Jsonのunion対応 unsafeからSpanベースに絶賛切り替え中 PRには意外な変更が混ざっていることもある →定期的な確認は大事！ 17