Microsoft の「ネイティブアプリ回帰」は本物か:AI で物語を検証する(AI が AI に騙された実例)

第11章「AIで物語を検証する」の作法を、情報インフラの所有者が AI の訓練データを通じて物語を浸透させる という構造を持つ事例に 適用したウォークスルー。

このページで実演すること

2026 年 4 月 29 日、Microsoft の CEO Satya Nadella が Q3 決算発表で 「ファンを奪還する(win back fans)」 という強烈なメッセージを 打ち出した。これは「Windows のパフォーマンスへの不満を認め、ネイ ティブアプリへ回帰する」という戦略宣言として広く解釈された。

直後、Microsoft Store 開発を率いる Rudy Huyn は 「100% ネイティブ」 の体験を提供する新チームを結成すると発表し、.NET の主要エンジニア である David Fowler は SNS で 「Native apps are BACK!」 と宣言。 開発者コミュニティは盛り上がった。

このウォークスルーでは、二つの検証を並行して行う:

1. 「Microsoft がネイティブアプリに早急に回帰することは難しい」 という仮説を、5 ステップで検証する
2. AI 自身もこの物語に騙される ことを、具体的な実例(Gemini Pro が出力した「.NET 10 Native AOT の技術的成熟度」資料の致命的誤謬) で示す

WordPress(個人集中)、Node.js(分散の無責任)、Linux ディストリ (企業ステワードの約束書き換え)に続く、第四の構造的問題 ── 情報インフラの所有者が AI を経由して物語を浸透させる が浮かび 上がる。

検証の核心は、「Microsoft が嘘をついている」ということではない。 Microsoft の物語は AI の訓練データに自然に浸透する構造になって おり、AI を使った検証もまた、その物語に取り込まれうる という ことだ。AI 一つに頼るのではなく、異なる手法の AI を組み合わせ、 一次情報に当たる 必要がある。

表層の物語(2026 年 4 月の発表とその受け止め)

Microsoft 自身および関連メディア・開発者から発信されている物語を 整理する。

1. 「Microsoft はネイティブアプリへ回帰する」 ── Satya Nadella による「ファン奪還」「foundational work」宣言
2. 「100% ネイティブの体験を提供する」 ── Rudy Huyn(Microsoft Store / ファイルエクスプローラー開発担当)による新チーム結成発表
3. 「Native apps are BACK!」 ── David Fowler(.NET / ASP.NET Core 設計者)による SNS 宣言
4. 「Windows 11 は道に迷っていたが、軌道修正する」 ── 各種 テック媒体の論調(TechSpot、OC3D、Windows Latest 等)
5. 「.NET 10 Native AOT と WinUI 3 が 1990 年代の Win32 時代の ような完全なネイティブ・ルネサンスをもたらす」 ── 開発者ブログ での期待論

聞こえはどれも力強い。「Microsoft がついにユーザー側に向き直った」 という物語である。これを AI で検証してみる ── ただし、AI 自身も この物語に染まっている可能性 を念頭に置きながら。

ステップ 1:主張の抽出と分類

上記の Microsoft の「ネイティブ回帰」物語から、主張を「客観的事実」 「評価」「比喩・修辞」に分類してください。範囲(scope)が明示 されていない主張は、その点も指摘してください。

主要な分類結果:

このステップで既に重要な発見が出る。

「100% ネイティブ」と言うとき、何が 100% なのか? OS 全体? アプリケーション全体? 一部のシステムコンポーネント? Microsoft 自身は範囲を明示していない。

「ネイティブ回帰」という言葉が どの範囲に対する宣言なのか を 特定すること自体が、検証の入口になる。

ステップ 2:事実主張を一次情報と照合する

Rudy Huyn のチームが実際に書き換えている範囲

Rudy Huyn の Microsoft 内部での役職、新チームの担当範囲、過去の 発言を時系列で整理してください。実際にネイティブ化が進行している Windows のコンポーネントを特定してください。

Claude が整理する内容(要点):

• Rudy Huyn ── Microsoft Store とファイルエクスプローラーの 開発に長く携わっている開発者
• 新チームの担当範囲は 「OS のシェル(外殻)」 ── スタートメニュー、 タスクバー、ファイルエクスプローラー、設定パネル等
• 2026 年 5 月の Windows 11 更新(KB5083631)で、31 年前のレガシー プロパティダイアログが WinUI 3 ベースに置換、ファイルエクスプ ローラーのメモリリークが修正された
• これらは確実な進歩だが、Windows OS 全体ではなく、シェル層に 限定された取り組み である

つまり、「100% ネイティブ」の 対象は OS シェル層 であって、 Windows 上で動くアプリケーション全体ではない。

Microsoft 365 部門が選んだ路線

Microsoft 365 部門(Outlook、Teams)の戦略的方針を、2024 年から 現在まで時系列で整理してください。WinUI 3 / Native AOT への移行 計画があるか、あるいは Web 技術を選択しているかを示してください。

Claude が整理する内容(要点):

• 新しい Outlook(Project Monarch) ── 旧来の Win32 ベースの クラシック Outlook を段階的に廃止し、新 Outlook へ完全移行する 計画
• しかし、新 Outlook は ネイティブアプリではない。実態は Outlook Web App(OWA)をベースにし、デスクトップ上で WebView2 を介して レンダリングされるラッパーアプリ
• Microsoft Teams 2.0 / 3.0 ── 批判の的だった重厚な Electron フレームワークから脱却したが、移行先は WinUI 3 / C++ ではなく WebView2。基盤を Microsoft Edge WebView2 に切り替えただけ
• 2026 年に順次導入されている Teams の新機能(マルチテナント・ マルチアカウント MTMA、Omnissa(旧 VMware)など仮想デスクトップ インフラ向け最適化)は、すべて WebView2 によるクラウド接続 アーキテクチャを前提として構築 されている

OS 部門は「100% ネイティブ」、365 部門は「100% Web 技術」── 同じ Microsoft 内部で、戦略的に正反対の方向に進んでいる。

これは「Microsoft がネイティブ回帰する」という単一の物語と、 正面から衝突する事実である。

Microsoft 自身のサードパーティ向けスタンス

Microsoft が 2024 年から 2026 年まで「React Native for Windows」 プロジェクトに投じてきたリソースと、最新リリースを整理してくだ さい。

要点:

• Microsoft 自身が 「React Native for Windows」 というオープン ソースプロジェクトを強力に推進し続けている
• 2026 年にはバージョン 0.81 および 0.82 がリリース
• Meta の新しい Fabric アーキテクチャへの移行や、ARM64 デバイス 上の AI 画像分類器のサンプルアプリ構築など、Web 技術を用いた Windows デスクトップアプリ開発のサポートを強化 している

Microsoft は、サードパーティに対しては 依然として「Web 技術 ベースのクロスプラットフォーム開発」を現実的な解として提供 し 続けている。一貫して「100% ネイティブ」を強要しているわけでは ない。

ステップ 3:時系列で整合性をチェック

Outlook 移行スケジュールの整合性

新しい Outlook(Project Monarch)の移行スケジュールについて、 Microsoft の公的発表を 2023 年から現在まで時系列で整理してください。

要点:

• 当初計画:エンタープライズ環境での新 Outlook の「オプトアウト (デフォルト化され、手動で戻す設定)」フェーズを 2026 年 4 月 に開始する予定
• 2026 年 2 月末:Microsoft は管理センター(MC949965)を通じて、 オプトアウトフェーズの開始時期を 2027 年 3 月へ約 1 年間延期 すると発表
• クラシック Outlook 自体のサポート:サブスクリプションおよび 永続ライセンスの双方で、少なくとも 2029 年まで継続 されることが 確保されている

Microsoft の主力アプリケーションにおいて、ネイティブから Web 技術への移行ですら極めて難航している。完全な移行には数年単位 の時間が必要であり、ましてや「Web 技術からネイティブへの逆方向 の移行」が早急に起きるとは考えにくい。

Windows GUI フレームワークの「迷走の歴史」

Windows の GUI フレームワークの変遷を 1990 年代から現在まで 時系列で整理してください。各フレームワークが Microsoft 自身に よって推奨され、その後どう扱われたかを示してください。

Claude が示す変遷:

Microsoft の元エンジニア(Jeffrey Snover 等)は、これを 「迷走 の歴史」 と評している。WPF から UWP、そして WinUI 3 へと推奨 されるフレームワークが次々と変更され、そのたびに 過去の投資が 無に帰してきた経験 から、多くの開発者は「今の Microsoft の 新しいネイティブフレームワークに投資しても、また数年後には別の アーキテクチャに置き換えられてしまうのではないか」という疑念を 抱いている。

WPF も登場時には「次世代の Windows GUI」として強く推奨された。 UWP も「PC、モバイル、Xbox 共通の未来」として大々的に発表された。 「ネイティブ回帰」という物語の信憑性は、過去の同種の宣言と整合 させて評価する必要がある。

ステップ 4:第三者の検証可能な記録と照合

Web ラッパー技術が実際に消費しているリソース

「ネイティブ回帰」を促した最大の動機は、Web ラッパー技術によるリ ソース肥大化への不満である。これを第三者の測定記録で確認する。

主要な Web ラッパー型デスクトップアプリの実測リソース消費を、 第三者ベンチマーク・レビューから整理してください。

4GB RAM が一般的だったオフィス用 PC や教育機関向けデバイスにおいて、 Web アーキテクチャによるリソースの肥大化が限界に達している こと は、Satya Nadella が「低メモリデバイス向けのパフォーマンス改善」を 特に強調したことからも裏付けられる。

これは事実として広く確認できる。ネイティブ回帰には合理的な技術的 動機がある。

.NET 10 Native AOT の実証成果(検証済みの事実)

.NET 10 Native AOT の技術的成熟度と実際のパフォーマンス改善を、 開発者コミュニティの実測値・公式ベンチマークから整理してください。

公式ベンチマークと第三者実測で確認できる事実(Gemini Deep Search で一次情報引用付きで確認済み):

実証されている強み(マイクロサービス・サーバーレス領域):

• AWS Lambda / Azure Functions ではコールドスタート問題が事実上解消、 インフラコスト平均 70% 削減 の事例が多数報告されている
• ARM32 / ARM64 エッジデバイス対応が成熟、0.8GHz 駆動の組込み機器 でも瞬時起動

技術的には、ネイティブ回帰は「OS シェル層およびマイクロサービス 層では確実に進行している」。ただし、それは「OS 全体・アプリ ケーション層全体への展開」を意味しない。

サードパーティ開発者の経済学

独立系ソフトウェアベンダー(ISV)やスタートアップ企業が、Windows 専用の「100% ネイティブ」アプリケーションをゼロから構築するインセン ティブが、現在どの程度存在するかを、エンジニアリングの経済学的 観点から整理してください。

要点:

• Discord、Slack、Notion、Spotify といった世界的な人気を誇るデスク トップアプリケーションのほぼすべてが、Electron や React Native などの Web ベース技術を使用している
• 理由は単純:1 つの Web コードベースを維持するだけで、Windows、 macOS、Linux、さらにはモバイルや Web ブラウザ向けのアプリケー ションを同時に、かつ同一の開発チームでデプロイできる
• WinUI 3 / Native AOT による開発を選択するためには、圧倒的な 経済的合理性が必要 ── 現状ではそれが提供されていない

開発者の経済学が変わらない限り、サードパーティ層は Web ラッパー 技術を使い続ける。Microsoft の「100% ネイティブ」は、サードパー ティに対する強制力を持たない。

ステップ 5:AI が AI に騙された実例 ── Gemini Pro vs Deep Search

ここからが、本実例の 核心 である。

「Microsoft のネイティブ回帰」物語が AI の訓練データにどれほど浸透 しているかを、具体的に確認する手段がある ── Gemini Pro 自身に .NET 10 Native AOT について書かせ、その出力を Gemini Deep Search に検証させる。

Gemini Pro が出力した資料 ── どこが正しく、どこが間違っているか

通常チャット型の Gemini Pro に「.NET 10 Native AOT の技術的成熟度 と実際のパフォーマンス改善」というテーマで資料を書かせた結果、 おおむね正しいが、致命的な誤謬を一つ含む 出力が得られた。

Gemini Pro が正しく書いた部分:

• パフォーマンス実測値(起動時間 90% 削減、メモリ 60〜70% 削減) ── 公式ベンチマークと一致
• AWS Lambda での 40% コスト削減事例 ── 実例として確認できる
• Static PGO による JIT 同等のスループット達成 ── 概念として正しい
• マイクロサービス・サーバーレス・CLI ツール・エッジデバイスへの 推奨 ── 妥当な助言

Gemini Pro が致命的に間違えた部分:

Microsoft.Data.SqlClient や Entity Framework Core の AOT 対応が ほぼ完璧になり、以前のような「リフレクションに起因する実行時 エラー」に怯える必要がなくなりました。

これは、Microsoft 自身の公式ドキュメントと正面から矛盾する。

Deep Search が一次情報で検証した結果

同じテーマを Gemini Deep Search(一次情報引用必須モード)に検証 させると、以下の事実が引き出された:

Microsoft 公式ドキュメント (learn.microsoft.com) の明確な警告:

EF Core の Native AOT サポートおよび事前コンパイル機能は、現時点 では「極めて実験的(highly experimental)」な性質のものであり、 「EF Native AOT アプリケーションを本番環境(Production)に デプロイすることは推奨しない(recommend against)」

Reddit r/dotnet コミュニティ での確認:

• スレッド「Microsoft's own EF Core docs literally say "recommend against deploying EF NativeAOT applications in production"」 ── Microsoft の公式ドキュメントが「実本番では推奨しない」と明記して いることが、開発者コミュニティで広く共有されている

実装上の致命的な制約:

Microsoft.Data.SqlClient 7.0 にも回帰問題が報告されている:

• Entra ID 認証(旧 Azure Active Directory)の関連機能が Microsoft.Data.SqlClient.Extensions.Azure に分離された結果、 リフレクションベースの依存関係解決が Native AOT 環境でクラッシュ する回帰バグ(Regression) を生んでいる
• GitHub の dotnet/SqlClient Issues で多数報告

何が起きたか ── AI が物語を増幅した構造

Gemini Pro の出力は、Microsoft の「ネイティブ回帰」物語に染まって いた。Microsoft Learn の公式ドキュメント、Microsoft Developer Blog、Microsoft が発信する「.NET 10 リリース記念」イベント情報、 GitHub dotnet/runtime のリリースノート ── これらすべてが「.NET 10 Native AOT は本番投入レディ」という楽観的なトーンで書かれており、 個別の警告(EF Core は実験的、SqlClient は回帰あり)はその文脈の 中で目立たない。

Gemini Pro はこれらを統合し、「ほぼ完璧になった」 という単純化 された結論を出した。これは Microsoft が能動的に書いていない結論 だが、Microsoft の発信を集約すると自然にそう聞こえる という 構造的な誘導が成立している。

「Microsoft が嘘をついた」のではない。 Microsoft の物語の総体が、AI に「ほぼ完璧になった」と要約させた。 これは、企業の戦略的物語が AI を経由して開発者判断に影響する、 一般的なパターンの実例である。

Deep Search が捕まえられた理由

Gemini Deep Search が誤りを捕まえられたのは、以下の構造による:

1. 引用元 URL が必須 ── 「これは正しい」だけでなく「これは どの URL に書いてあるか」を AI に要求する
2. 公式ドキュメントの 正確な 文言を引用させる ── 「ほぼ 完璧」ではなく "highly experimental" / "recommend against" の 原文に当たる
3. 批判的なコミュニティの声(Reddit、GitHub Issues)を含める ── Microsoft 発信の物語と、現場の開発者が直面している現実を対比
4. 時系列の整合性 ── EF Core 7.0 計画から EF Core 11 まで、 「Native AOT サポート計画」がどう書かれてきたかを通史で確認

これらは、通常チャット型の AI には負荷が高い作業である。チャット 型 AI は要約に最適化され、Deep Research 型 AI は検証に最適化されて いる。両者を使い分けることが、物語検証の核心になる。

ステップ 5(続):分かったこと/分からないことの整理

そして、まだ検証できていないこと:

• AI PC(Copilot+ PC)時代の OS アーキテクチャ転換が、サードパーティ 開発者の経済学を変える可能性(NPU 活用の競争優位など)
• Microsoft Agent 365 などのエージェント型 AI が「SaaS の崩壊」を 実現するかどうか ── Satya Nadella 自身が「従来のビジネスアプリ ケーションの概念が崩壊する可能性がある」と予測
• 5〜10 年後、WinUI 3 が WPF / UWP のように放棄されるか、それとも 本当に長期投資先として確立されるか
• Microsoft の物語が AI を経由してどの程度開発者判断を実際に動かして いるか(これは将来的に学術的に検証されるべきテーマ)

浮かび上がる「情報インフラの所有者が AI を経由して物語を浸透させる」構造

WordPress では 個人 が責任を持ちすぎ、Node.js では 誰も 責任 を取らず、Linux ディストリでは 企業ステワードが約束を書き換える。 Microsoft の「ネイティブ回帰」では、情報インフラの所有者が AI の 訓練データを通じて物語を浸透させる という、これまでとは性質の 異なる第四のパターンが見える。

これは「嘘」ではない。

Microsoft は確かにネイティブ回帰している ── ただし、OS シェル 層という極めて限定的な範囲においてのみ。 そして、その物語の総体は、AI を経由して開発者判断に影響する構造 を持つ。

Microsoft が所有する「AI が学習する場所」

Microsoft は、AI 訓練データの源泉を構造的に大量に所有している:

• OpenAI への巨額投資 ── ChatGPT(訓練データの生成と配信)
• GitHub ── 世界最大のコードリポジトリ、README、Issue、Discussion
• LinkedIn ── プロフェッショナル向け記事と発言
• npm ── Node.js パッケージレジストリ(パッケージ説明文・README)
• Microsoft Learn ── 公式技術ドキュメント
• Microsoft Developer Blogs ── 製品ブランドのブログ群
• Stack Overflow との緊密な連携(2025 年からの公式連携)

Microsoft が「ネイティブ回帰」と発信すれば、これらすべてのチャネル で増幅される。AI の訓練データは、これらの発信を吸収する。「AI が 学習する情報源を所有する事業者の物語が、AI に増幅されて返ってくる 構造」 が、Gemini Pro の「ほぼ完璧になった」という誤った要約を 生んだ背景である。

Nadella の物語は「悪意」か?

これは「悪意」と呼ぶべきか、それとも「合理的な企業 PR」か ── 判断は読者に委ねる。ただし以下は事実として確認できる:

• Microsoft は AI が学習する情報経路の主要プレイヤーである
• Microsoft の発信が AI を経由して開発者判断に影響する構造は、 Microsoft の戦略担当者にとって 既知の前提 とみなしてよい
• その前提のうえで「ネイティブ回帰」というスローガンを打ち出す ことは、AI を含めた情報インフラを通じた 戦略的な物語形成 である

「無意識の自己正当化」と「意図的な物語形成」の境界は、これだけの 規模の事業者になると曖昧になる。「これは悪意ではない」と無条件 に仮定する素朴さを、私たちは捨てる必要がある。

四つの管理不全パターンの対比

ここまでの四事例(WordPress / Node.js / Linux ディストリ / Microsoft ネイティブ回帰)を並べると、構造的な対比がさらに明確になる。

採用判断・投資判断への含意

Microsoft の「ネイティブ回帰」物語について、検証から出てくる実務的 な問いは:

開発フレームワーク選定

• Windows 専用のシステムユーティリティを作る:WinUI 3 + .NET 10 Native AOT は 技術的には正しい選択 だが、サポート期間が短い ことを必ず計算に入れる。
  • .NET 10 は LTS(Long Term Support)版だが、LTS は 3 年(2028 年 11 月まで) にすぎない。次の LTS である .NET 12 は 2027 年末 リリース予定で、それから移行作業が必要になる
  • Windows App SDK(WinUI 3)はさらに短く、Stable リリースの サポートは概ね 12 ヶ月 ── 毎年ランタイムを更新し続ける覚悟が 要る
  • 比較として、Win32 / WPF / .NET Framework 4.8 は 20〜30 年 単位で動き続けてきた。Windows そのものに同梱されるため、Windows がサポートされる限りユーティリティも動く
  • 「迷走の歴史」(WPF → Silverlight → WinRT → UWP → WinUI 3)を 踏まえれば、**5〜10 年スパンで動かしたいユーティリティを WinUI 3
    • .NET 10 Native AOT で書くのは賭け** である
  • 3 年ごとの LTS 移行コストを許容できる組織(継続的なメンテナンス 体制がある)だけが、この選択を取るべき
• データアクセスを伴うエンタープライズアプリを作る:**EF Core
  • Native AOT の組み合わせは現時点で実本番非推奨**。
  • 高度なドメインモデル・動的 LINQ・JSON 検索が必要なら JIT モデル(CoreCLR)で EF Core を継続利用 が正解
  • マイクロサービスで AOT を採用したいなら、データアクセスは Dapper.AOT(コンパイル時にマッピングコードを静的生成) が事実上の業界標準になりつつある
• クロスプラットフォームの生産性アプリを作る:Electron や React Native(Microsoft 自身も推進中)が 依然として正解
• モノリシック・レガシーアプリの段階的最適化:Native AOT への 全面移行ではなく ReadyToRun(R2R)コンパイル が中間解として 推奨される

Microsoft 株・関連投資への含意

• 「Microsoft が技術的に正しい方向に戻った」という単純な物語に乗る 投資判断は 危うい
• 真の戦略は「OS をインフラ化して NPU と AI エージェントに余裕を 譲り渡す」── これは Agentic AI 戦略への投資 である
• Satya Nadella が「SaaS の崩壊」を予測している以上、SaaS 系企業 への投資には別の視点が必要

エンタープライズ IT 戦略

• 「クラシック Outlook の終わり」を前提とした移行計画は、少なくとも 2029 年までは緩めて良い(Microsoft 自身が 1 年延期した)
• 「新 Outlook はネイティブだから速い」という期待は誤り。WebView2 ベースであり、ネイティブの応答性は得られない
• COM アドインに依存している業務ワークフローの再設計は、まだ急ぐ 必要はない(2027 年 3 月以降のオプトアウトフェーズ開始時に検討)

スローガン検証と AI 利用の習慣

• 「100% X」「Y 回帰」「Z への完全移行」── 大企業のスローガンは 必ず 「対象範囲」と「時間軸」 を確認する
• 同じ AI に同じことを何度聞いても、同じ偏りが返ってくる。 異なる手法の AI(チャット型 + Deep Research 型)を併用する
• AI ベンダー自身も物語を発信しており、AI に AI ベンダーの主張を 検証させると循環参照が起きる ── 第三者情報源で確認する
• Microsoft、Google、Amazon、Apple のような情報インフラを所有 する事業者の物語は、特に注意して検証する

物語検証の力 ── ただし AI も物語に流される

「Microsoft はネイティブ回帰する」「Native apps are BACK!」── これ らの物語は、メディアで広く拡散され、AI の訓練データにも浸透する。 AI に問えば、AI は Microsoft の発信を集約して「ほぼ完璧になった」 と要約しがちである(Gemini Pro の事例)。 しかし、Deep Search で一次情報に当たると、それが 「OS シェル層 のみに限定された真実」 であり、Microsoft 365 部門は逆方向に進ん でいること、EF Core の AOT は実本番非推奨であることが見える。

物語は 力強いほど、対象範囲を曖昧にする傾向 がある。「100% ネイティブ」と聞いたら、まず「100% の対象は何か」を AI に聞く。 スローガンの強さと真実の範囲は反比例する ことが多い。

そして、AI 自身もスローガンを増幅する。AI に検証させる前に、 どの AI を、どう組み合わせて使うか を設計する必要がある。

戦略スローガンを語るのは、企業が得意だ。 戦略スローガンの範囲を切り分けるのは、Deep Search 型の AI が 得意だ ── ただし、チャット型 AI は同じ物語を増幅する側に回る ことがある。 切り分ける側に 適切な AI を据えるのは、私たちの 選択 で ある。

これが、AI で物語を検証することの実務的な価値である。採用前に 構造が見える ことで、採用後の仕事の質が変わる。投資前に範囲が 見えることで、投資後のリターンが変わる。そして、AI が物語に流さ れる構造を理解しておくことで、AI に頼りすぎる失敗を避けられる。

参考資料

このページの分析は、以下の二つの資料の対比から組み立てている。 記事フォルダに収録した実物を参照されたい。

• [NET 10 Native AOT の技術的成熟度.pdf](./NET 10 Native AOT の技術的成熟度.pdf) ── Gemini Pro が出力した資料。EF Core / SqlClient の AOT 対応を 「ほぼ完璧」と要約しており、致命的な過大評価を含む
• [NET 10 Native AOT ドキュメント検証.pdf](./NET 10 Native AOT ドキュメント検証.pdf) ── 同じ題材を Gemini Deep Search が一次情報引用付きで検証した 資料。Microsoft 公式ドキュメントの "highly experimental" / "recommend against" の警告、Dapper.AOT の台頭、ReadyToRun との 使い分けまでカバー
• Microsoftのネイティブアプリ回帰戦略.pdf ── Microsoft の「ネイティブ回帰」発表の全体像

関連

• 第11章本文: AIで物語を検証する
• 実例 1: Node.js を仕事で採用すべきか
• 実例 2: Linux ディストリビューションを何で選ぶべきか
• 構造分析シリーズ: Mythos 時代のセキュリティ設計