C#の現在地 進化の歴史と、AI時代の.NET Everywhere 2026-09-19 C# Kaigi 2026 Yoshifumi Kawai / Cysharp, Inc. 

About Speaker 河合 宜文 / Kawai Yoshifumi / @neuecc Cysharp, Inc. - CEO/CTO 株式会社Cygamesの子会社として2018年9月19日設立 C#関連の研究開発/OSS/コンサルティングを行う Microsoft MVP for Developer Technologies(C#) since 2011 CEDEC AWARDS 2022エンジニアリング部門優秀賞 .NETのクラスライブラリ設計 改訂新版 監訳 50以上のOSSライブラリ開発(UniTask, R3, MessagePack for C#, etc..) C#では世界でもトップレベルのGitHub Star(合計70000+)を獲得 

Origin of C# 

C#の始まり 2002 C# 1.0正式リリース 

C#の始まり Anders Hejlsberg(Creator of TypeScript)入社 1996 Visual J++(魔改造Java)の開発を始める 2002 

C#の始まり 1996 1997 Sun Microsystems(当時のJava開発元)に 魔改造はライセンス違反だと怒られる 2002 

C#の始まり 1996 1997 1999 COOL(C like Object Oriented Language)開発開始 2002 

C#の始まり C#の名前が初めて世に出る C++++でC# 1996 1997 1999 2000 2002 

C#の始まり C# 1.0正式リリース 誕生の経緯から特に影響ある言語がPascal, Java, C++ 1996 1997 1999 C#は命名規則にPascalCaseを採用 AndersがMicrosoft入社以前に作成していた言語 環境「Turbo Pascal, Delphi」の血を感じる (J++ではJava流儀のためcamelCaseだった) 2000 2002 // camelCase public void fooMethod() { } // PascalCase public void FooMethod() { } 

Evolution of C# 

C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span Source Generators Union 

C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2005 C# 2.0 2012 C# 5.0 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2017 C# 7.x 2020 C# 9.0 C# 1.0で何が最も大事だったかと考えると、値型に思える。当時のオ Source Generics async/await Span Generators ブジェクト指向の風潮として邪道とされていたものが、「ゲーム」と いった高性能を要求するユースケースでの適用や、後のパフォーマン ス強化のキーとなっていった。とはいえ最初期はGenericsもないため、 そこまで有効活用できるわけではなかった。 2026 C# 15 Union 

C#の進化 C#のGenerics導入はすごい。というのも1.0から2.0で、いき なりのランタイムごと作り直しでReified genericsを導入し た(JVMは互換性を重視しtype erasure)。これにより値型が 真価を発揮し、現在まで続くパフォーマンスの基盤となっ 2019 2025 2007 2015 C# 8.0 C# 14 た。なおGenericsの設計はDon Syme(Microsoft Research、 C# 3.0 C# 6.0 Nullable Extension 後にF#を設計する)が主導した。 2002 C# 1.0 ValueType LINQ Roslyn / Analyzer reference types members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span Source Generators Union 値型は特殊化、参照型はコード共有という特性があ り、パフォーマンスチューニング(後述)で、その違 いを意識するのが非常に重要になる。 

C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2005 C# 2.0 2012 C# 5.0 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Source Generics async/await Span Union C# 1.0のデリゲート（これも当時、値型と並んで邪道とされて Generators いた）がラムダ式に進化し、オブジェクト指向と関数型の融 合を果たした。これが有用なことは現代では当たり前ですが、 当時の主要言語では大胆な導入であり、LINQはReactive Extensionsというバリエーションも生み様々な言語に移植され ていくなど、C#の先進性をこれでもかというほどに示した。 

C#の進化 言わずもがなのasync/awaitの発祥はC#（それ以前にも同じような 挙動をする仕組みがないわけではないが、特性や、そのネーミン 2019 2025 グなど、以降への他言語への影響はC#が大元になっている） 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer C# 8.0 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span Source Generators Union 初期は非同期I/Oを実現はするものの、必ずしもパフォーマン スに優れていたわけではなかったが、度重なる改修で、どん どん性能は良くなっていった。最新のC# 15/.NET 11でも Runtime Asyncが導入され、更なる進化を果たしている。 

C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span Source Generators Union 2012年 TypeScript生誕 Anders Hejlsberg離脱 (Roslynの設計までは関わる) 

C#の進化 2002 C# 1.0 2007 C# 3.0 2019 TypeScript生誕秘話 2015 C# 6.0 C# 8.0 2025 C# 14 Nullable Extension Andersのもとに、JavaScriptの開発環境が辛い、C#のツール類(高機能なIDE、デ ValueType LINQ Roslyn / Analyzer reference types members バッガー、型チェックなど)をJavaScript開発で使いたいからScript#というC# to JavaScriptトランスパイラを作っている、見てくれ。という相談が来た。それな 2005 2012 2017 2020 2026 ら、そもそもJavaScriptを直せばいいのでは？という発想になり、そこから C# 2.0 C# 5.0 C# 7.x C# 9.0 C# 15 TypeScriptが生まれた。つまり、ただたんに言語作者が同じというだけではなく、 Source Generics async/await Span Union C#のお陰でTypeScriptが生まれたというっても過言ではない！！！（？） Generators 2012年 TypeScript生誕 Anders Hejlsberg離脱 (Roslynの設計までは関わる) 

C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2005 C# 2.0 2012 C# 5.0 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2017 C# 7.x 2020 C# 9.0 Source Generics async/await Span C#コンパイラーがC#で書かれる（かなり難産で時間かかった模 Generators 様）。コンパイラーAPIが公開されて、コンパイルパイプライン に乗っかる形でユーザーが自由に構文木を解析して、アプリケー ション固有のLintが書ける基盤となるAnalyzerや、構文木から コードを生成するSource Generatorをもたらした。のちの NativeAOTや、AI時代にめちゃくちゃ意味のある超重要な一手。 2026 C# 15 Union 

C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span Source Generators Union .NET Core(クロスプラットフォーム化)と連動して、 ここから怒涛のパフォーマンス強化が始まった。 その最も重要な基盤がSpan 

C#の進化 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer 2005 C# 2.0 2012 C# 5.0 2019 C# 8.0 2025 C# 14 Nullable reference types Extension members 2017 C# 7.x 2020 C# 9.0 Source null安全性を後付けで気合で追加しきった。型にせよnull安全性にせよ、 Generators Generics async/await Span オプショナルな後付けは、付与されていないものがいると意味をなさなく なるが、.NETの場合は数年かけてランタイム内部の100%付与(2021 年, .NET 6)を実現した。3rd Party libもそれに引きずられて、付与率はとて も高いので、もう後付けでも違和感はない、はず。 2026 C# 15 Union 

番外編 C# 4.0 Dynamic、当時、時代は動的言語みたいな風潮 があったので追加されたけど、もはや負債。C#初期は 神がかった奇跡の連鎖で、現代でも成立する基盤が整 備されていますが、たまには失敗もある……！ 2019 2025 2002 C# 1.0 2007 C# 3.0 2015 C# 6.0 ValueType LINQ Roslyn / Analyzer C# 8.0 C# 14 Nullable reference types Extension members 2005 C# 2.0 2012 C# 5.0 2017 C# 7.x 2020 C# 9.0 2026 C# 15 Generics async/await Span Source Generators Union 10~13、色々追加されてはいますが、そ こまで大きなものはないので割愛（言語 的には成熟している、ともいえる） 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR Miguel de Icaza(Ximian)により2001年に始まったOSS Linux対応、後にXamarinとしてiOS/Android対応を支える 現在はWineの下でProton(SteamOS)の.NET Fx互換を支えている 

ランタイムの進化 C#の一般層向けアプリケーションや、若年層ユー ザーを支えるゲームエンジン。特にモバイル向けで のシェアが高いがコンソール向けも頑張ってます。 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 膨大なソースコード・ドキュメント公開だけでなく、 意思決定もGitHub上で行う/残すようになった。これ がAI時代に強力な武器となっていく……！ 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 独自のAOT基盤、これが早期のiOS対応だけ でなくコンソールゲーム機対応などにも繋 がっていく。現在も(Unity 7 CoreCLRでも)使 われ続けている。 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR C#はWindowsだけじゃない！と堂々と言えるように なった基盤。パフォーマンス比較がLinuxの同一ハー ドウェア上で平等に行えることになったこともよし。 現代ではC#サーバーは普通にLinuxで動かしてます。 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 乱立するターゲットフレームワーク(netframework, netcore, netstandard, xamarin, etc...)がnet5.0に統一さ れた。大統一.NET時代の幕開け。ただし実行環境 (CoreCLR)はまだ統一されていない。 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 特にコールドスタートアップに効くので、アプリケーションや、そしてAI のためのCLIで活きる……！対応プラットフォーム増加速度は思ったよりも ゆったりだが、.NET 11でようやくモバイル対応が完全完了。なお、後付け のAOTは苦しいところもある、が、やれないことはない、はず……。 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR WASM(.NET 11ではMono、.NET 12で対応予定)とコンソールゲーム機 対応(公式では多分やらなさそう)まで行けばCoreCLRが完全制覇になる のだけれど……！ 

ランタイムの進化 2026 .NET 11 2002 .NET Framework 2005 Unity 2015 Unity IL2CPP 2020 .NET 5 Windows Game iOS One .NET CoreCLR for iOS/Android 2004 Mono 2014 .NET OSS 2016 .NET Core 2022 .NET 7 2027 Unity 7 Linux on GitHub Cross Platform NativeAOT CoreCLR 長いことMonoのままだったランタイムがついにCoreCLRに 移行する……！CoreCLR Player(JIT: Desktop/Editor)とIL2CPP Player(AOT: Mobile/Console)になる模様。 フレームワークは.NET 10/C# 14予定。 

AI時代のC# 

AI時代に最適な言語は「***」です！！ 

AI時代に最適な言語は「***」です！！ と、自分の推し言語を好きに入れて語られがち 

AI時代に最適な言語は「***」です！！ その発言が許されるのはRustとPythonとTypeScriptだけ！ 

C#とは エディターフレンドリーな 静的型付け言語 エディター支援を強く念頭においた言語仕様により 入力補完やリアルタイムエラー検出の精度が高い 型のメリット ・リアルタイムのコンパイルエラー検出 ・入力補完 ・リファクタリング支援(名前一括置換など) 

でも、もう手書きしないよね？ C#はツールを重視してきた 言語レベルで意識されたIDEとの連携 今では(TypeScriptを経由して)LSPとして様々な言語にもたらせている ものも、源流はC#にあるといっても過言ではない しかし手でコードを書く時代ではない 使わないわけではないが、重要視するほどでもない というのが現実 その傾向はこの先もますます広がっていくだろう C#のエディターフレンドリーは強みと言えるのだろうか？ 

コードエディット 実行（テスト、デバッガー、ベン チマーク、プロファイラー）して 確認してコード編集に戻る これだけだと回転に時間かかる 実行 

コードエディット Humanは静的型付けと強力なIDE連携 によるコードエディット時のリアル タイムエラーでループを回していた 

静的型付けだったらここでエラーが あったらエディットに戻れる＋解決 のための詳細な診断情報を渡せるの で、より正確に素早く解決しやすい コードエディット コンパイル 型はHumanのためだけでは なく、AIのためでもある 実行 

AIのためのエディターフレンドリー エディターフレンドリー = 高速なLint リアルタイムに出せているぐらいだから、とても高速なのだよ！ Humanのための高速な仕様が、AIにとっても活きる！ 放置するから遅くてもいい、などということはなく、結局イテレー ション速度は大事、速ければ速いほど、より回転する Analyzer Driven Development C#にはコンパイルパイプラインと統合された、構文木を使ってアプ リケーション固有のLintを作るシステムが2015年に追加された Humanのための代物だったが、むしろAIに最適なシステム 

AIのためのエディターフレンドリー エディターフレンドリー = 高速なLint 自然文の指示では従われないこともあるし、早 い段階でのループで誤りを検出できないが、 Analyzerによりロジックエラーがコンパイルエ リアルタイムに出せているぐらいだから、とても高速なのだよ！ ラーになることで確実に検出、かつ、修正のた Humanのための高速な仕様が、AIにとっても活きる！ めの適切なガイドも同時に出せる 放置するから遅くてもいい、などということはなく、結局イテレー ション速度は大事、速ければ速いほど、より回転する Analyzer Driven Development C#にはコンパイルパイプラインと統合された、構文木を使ってアプ リケーション固有のLintを作るシステムが2015年に追加された Humanのための代物だったが、むしろAIに最適なシステム 

[MessagePackObject]には[Key]が public memberに必要だよエラー state.Enter()したらstate.Exit()もしない とダメだよ警告 

37個もAnalyzerが定義されている！ 

AI時代のAnalyzer AIにより量産が容易になった 構文木の解析は通常馴染みがない、かつ、言語構文を網羅しなけれ ばならないため漏れが出やすい、難易度だけではなく、慣れてる人 でも面倒くさい代物であった そのため、どうしても必要なところだけ最小限定義、になりがち ところがAIは構文木の解析がめちゃくちゃ得意 やりたいことを自然文で書くだけで一瞬で実装してくれる Analyzerの民主化時代到来 （同種のSource Generatorの実装もAIは非常に得意） 

こういうの網羅できる気しないので、AIにやらせる よりほかはない、Analyzer(Source Generator)に関し ては、手書きすべきではない、とまで言える 

ところでMessagePack for C# v4 超絶速くて安全でバージョニング耐性が高い • Performant by default • Secure by default • Version-tolerant by default MessagePack for C# v4、まもなく出ます！ (9月中にpreview出す予定) v3と比較しても2~10倍高速になる！ Human x AI AIは大局的なアーキテクチャ造りはまだ苦手 また、世の中にない新しいアーキテクチャを造るのも苦手 10年以上のシリアライザー造りの経験による、長年温めていた究極 の新アーキテクチャ＋AIによるブラッシュアップで性能が限界突破 

array(default)で398.2nsで他の2倍以上と いう圧倒的パフォーマンス！ mapでも479.5nsと他を圧倒して速い！ 

パフォーマンスを生み出す新しいフォーマッター定義 

Deserialize(int)の解析 最もミニマムな箇所を計測することで、エントリー ポイントの必要経費がどのぐらいかを明らかにする v3比で4.86倍の改善 

Deserialize(int)の解析 BenchmarkDotNetでのmeanだけではなくて、JIT Disassembleも行うことで、機械語レベルでの徹底的 な分析と改善作業をする 全体構造に関わるので、Agent Loopだけの自律的な改善 は難しい。(v4の場合はv3との互換性のトレードオフなど、 重要な判断も多数含まれるので、より難しい）。中身を Humanが理解して読み取って、大局的な視点で最適な アーキテクチャを構築する必要がある 

Deserialize(int)の解析 lastEntryキャッシュ(最後のDeserializeのConverterだけ フィールドに置いておく）はただのベンチマークハックで良くな い。実際の利用シーンでそんなことはほとんどないはず。同種の コードはSystem.Text.Jsonにもある(このasm解析で発覚した）が、 そういうのはやめるべきだ。また、分岐予測ミスのコストは無料 ではないので、一般的ケースでの性能悪化も招く。 

ちょっとした単純な改善事例紹介 public static class MessagePackSerializer { static readonly ConcurrentDictionary entries = new(); public static byte[] Serialize(Type type, object? value) { var entry = entries.TryGetValue(type, out var existingEntry) ? existingEntry : SlowPath(type); return entry.Serialize(value); Typeをキーにした辞書引き (NonGenericのSerialize/Deserializeに使う) [MethodImpl(MethodImplOptions.NoInlining)] static NonGenericEntry SlowPath(Type type) { return entries.GetOrAdd(type, new NonGenericEntry()); } } } Genericsの場合はもっと高速なパスを通るが、 NonGenericsも改善したい……！ 

ConcurrentDictionary entries = new(); ConcurrentDictionary entries = new(ReferenceEqualityComparer.Instance); Keyがstructの場合はGenericsの特殊化 により性能が改善する可能性がある // type.TypeHandleで取れるstruct ConcurrentDictionary entries = new(); 改善されたといえばそうだけど、もう少し行きたい 

そもそも、この状況では、かなり実装内容が 絞られた状態なので、特化実装してもコンパ クトな内容に抑えられるはず 実装が複雑になる場 合は、たとえAIに実 装させるとしても、 多少の性能改善程度 では避けたほうがい い。今回は条件を絞 れているので実装も シンプルにできる見 込みがあるのでGo 

sealed class TypeKeyHashTable where TValue : class { struct Entry { public Type? Type; public TValue? Value; } Entry[] entries; int count; Fibonacci Hashing static int GetIndex(nint key, int mask) => unchecked((int)(((ulong)key * 0x9E3779B97F4A7C15UL) >> 32)) & mask; public bool TryGetValue(Type type, [NotNullWhen(true)] out TValue? value) { var key = type.TypeHandle.Value; キーはメソッドテーブルのアドレス var table = entries; var mask = table.Length - 1; for (var i = GetIndex(key, mask); ; i = (i + 1) & mask) { ref var slot = ref table[i]; var slotType = Volatile.Read(ref slot.Type); if (ReferenceEquals(slotType, type) { Type == Typeは内部でis RuntimeType value = slot.Value!; return true; が余計に含まれるので使わない } if (slotType is null) { value = null; return false; } } } 

素のConcurrentDictionaryと 比較して2.8倍高速 

AIはC#をよく知っている！ 2014年OSS化、GitHub上での開発の効果 アルゴリズムの知識が（私よりも遥かに）ある アセンブラの知識が（私よりも遥かに）ある C#の知識がある（私ぐらいに←？） .NETの知識が（私よりも遥かに）ある なぜなら、C#はインターネットに膨大なコードが存在しているから 膨大なdotnet/runtimeの良質なコード ディスカッション過程が全て残っていることによる理屈付け MicrosoftのTier1言語であることによるプロダクションコード公開 Stackoverflow質問数言語#3 GitHubランキングでも(LLM以前の年代で)#5 • • • • 

Humanの知識も大事 AIは出力をブーストする MessagePack for C# v4の圧倒的な 性能向上は、AIがあっても、私に しか作れなかっただろう AIは確かに自分より賢い、が、全体的視点は（まだ）ない コードの取捨や、さらに追及するかどうかの押し引きは、幅広いコ ンテキストを見ているHumanに委ねられている つまり、油断すればす 自身の力 x AIアシステッド力 = 出力 ぐに追いつかれる、先 ベースがなければ増幅される幅も限られてしまう 行者利益などない純粋 AIは知識をブーストする な実力の世界 無限に質問できる、最高のインタラクティブな教材がそこにある 新しい知識の習得速度が従来の比じゃないほど加速している つまり、やる気さえあれば、誰でもすぐに追いつくことができる 

AI Optimization Optimized Architecture 自己改善のためのコンテキストを与える C#はIL、マイクロベンチマーク、そしてJIT Disassemblyを容易に出力 可能なAIにとって最適な環境がある AI自身の知識＋的確な情報を与えることで、改善ループが走る 知識と能力のないAIには、いくら情報を与えても無駄。 Fable以降の世代でようやく実用的になった（のでそれ以 前の世代にコードは書かせない） AIが最適化しやすいアーキテクチャにする コード上でも依存関係を切った最小限のコンテキストで済むもの つまり小さな静的メソッドの集合体が最も改善しやすい 

public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) { buffer.Advance(UnsafeWriteInt32(ref buffer.GetReference(5), value)); } 静的メソッドと、小さなインスタンスメソッドの集合体で構成 それぞれを切り離して最適化しやすい構造 つまり関数型スタイル が、めちゃくちゃ書きづらい！ 

Martin Odersky(Creator of Scala): すべてが本質的にオブジェクトである ということは、全体の構造に染み込ん でいます。得られるものの一つは、 Simon Peyton Jonesが「ドットの力」 と呼んだものだと思います。非常に便 利で、オブジェクトがあってドットを 打つと、環境がそのオブジェクトのメ ソッドやフィールドを即座に教えてく れて、使うことができる。 https://www.developing.dev/p/creatorof-scala-comparing-languages 関数型言語のえらい人たちいわく、オ ブジェクト指向とはドット記法のこと である。使いやすさは正義。 Simon Peyton Jones(Creator of Haskell, Creator of Verse) https://www.microsoft.com/en-us/research/wp-content/uploads/2016/07/ECOOP-July09.pdf 

public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) { buffer.Advance(UnsafeWriteInt32(ref buffer.GetReference(5), value)); } Bad Feeling public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) { buffer.WriteInt32(value); } Good Feeling 

public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) { buffer.Advance(UnsafeWriteInt32(ref buffer.GetReference(5), value)); } extension(ref TWriteBuffer buffer) where TWriteBuffer : struct, IWriteBuffer, allows ref struct { /// Writes an int32 in the smallest msgpack format. [MethodImpl(MethodImplOptions.AggressiveInlining)] public void WriteInt32(int value) { buffer.Advance(UnsafeWriteInt32(ref buffer.GetReference(MaxInt32Length), value)); } extension(C# 14)で、AI向きの静的メソッドの集合体を、 public void Serialize(ref TWriteBuffer buffer, ref SerializeState state, int value) Human向きのドット記法スタイルに変換する { buffer.WriteInt32(value); } 

Conclusion 

.NET Everywhere? C#は器用貧乏、か とはいえ、大統一された場合のスムーズさも大き な利点。結合箇所は大きなコンテキストになりAI が把握しづらくなるので、その点では大統一化が 可能なC#の万能さは有利でもある。また、最終的 には人間の把握しやすさも重要なので、大量コー ド生産時代だからこそ、単一アーキテクチャが人 のために活きるともいえる。 何でもできる、は、何もできない AI時代は言語の乗り換え、アーキテクチャの同期が容易になった 求められているのは最高のパフォーマンス、最高のUX そこでC#は戦えるのか？ エコシステムは最高だけど性能面に過大(JavaScript) ネイティブを探そう 性能面は最高だけどエコシステムに過大(Rust) ConsoleApp <- C#のNativeAOTは十分戦える Web <- フレームワーク/エコシステム/性能、バランスは良い Game <- 現実的にはまだゲームエンジンが必須、Unityは強み Windows App <- 文句なしのネイティブ WASM/Mobile <- がんばれ！ 

C#はAI時代に最適な言語の一つ 自信をもって言い張ろう！ 型付き・高速なコンパイル・統合されたAnalyzerは圧倒的な強み そしてC#のパフォーマンスの高さは、ネイティブパワーが求められ るAI時代において大きな武器となる AIパワーとの掛け合わせで基盤ライブラリもますます強力になる 改めて、AIで自身をブーストしよう！ C#がAIに最適だというなら、そこには最高の教材がある 実際、私は今年、ものすごく成長した 必要なのはC#への情熱だけ！ この波乱の時代を最高の形で乗りこなしましょう！ 

No content