# 実例 3 — 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)が明示
> されていない主張は、その点も指摘してください。

主要な分類結果:

| 主張 | 分類 | 検証可能性 |
|---|---|---|
| 「Microsoft はネイティブ回帰する」 | 評価+事実主張、**範囲が不明確** | 検証可・範囲を特定する必要 |
| 「100% ネイティブ」 | 事実主張、**対象が不明確** | 検証可・対象を特定する必要 |
| 「Native apps are BACK!」 | 比喩・修辞 | 評価レベル |
| 「Windows 11 は軌道修正する」 | 評価 | 「軌道修正」の中身が不明 |
| 「.NET 10 / WinUI 3 がルネサンスをもたらす」 | 事実主張 + 評価 | 部分的に検証可 |

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

> **「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 が示す変遷:

| フレームワーク | 登場時期 | 推奨期間 | 終わり方 |
|---|---|---|---|
| **Win32 / MFC** | 1990 年代〜 | 長期 | 「レガシー」として保持 |
| **WPF** | 2006 年〜 | 約 10 年 | 「事実上のメンテナンスのみ」 |
| **Silverlight** | 2007 年〜 | 約 5 年 | **2012 年に事実上放棄** |
| **WinRT / Metro / Windows Store apps** | 2012 年〜 | 約 3 年 | UWP に統合 |
| **UWP(Universal Windows Platform)** | 2015 年〜 | 約 6 年 | **Windows Phone の終焉とともに崩壊。Microsoft 自身の主力アプリも採用を見送った** |
| **WinUI 3(Windows App SDK)** | 2021 年〜 | 現在進行中 | 未確定 |

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

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

---

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

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

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

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

| アプリケーション | アーキテクチャ | リソース消費(実測) | ユーザー体験の主な摩擦 |
|---|---|---|---|
| **WhatsApp(デスクトップ版)** | WebView2(PWA) | アイドル時でも最大 600MB の RAM 消費(8GB RAM 環境時) | バックグラウンドでの常駐によるシステム全体のメモリ圧迫 |
| **Discord** | Electron | アクティブ時に最大 4GB の RAM 消費 | メモリリークによるクラッシュ、重いゲームのバックグラウンド実行時のパフォーマンス低下 |
| **Microsoft Copilot(Windows)** | WebView2 | バックグラウンドで 500MB、使用時は最大 1GB の RAM 消費 | OS の組み込み機能であるにもかかわらず、スタンドアロンのブラウザと同等の負荷 |
| **Microsoft Store** | 混成(Web コンポーネント含む) | ページ遷移ごとに数秒の遅延 | ネイティブな UWP アプリからの退行と認識される顕著なロード遅延 |

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

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

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

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

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

| 指標 | JIT(従来型) | Native AOT(.NET 10) | 改善 |
|---|---|---|---|
| 起動時間(コールドスタート) | 200ms - 800ms | 15ms - 50ms | **80〜90% 削減** |
| メモリ使用量(RSS) | 80MB - 120MB | 25MB - 40MB | **60〜70% 削減** |
| 実行バイナリサイズ | 100MB+(ランタイム込) | 4MB - 20MB | 最大 40% 削減、4MB まで縮小も可 |
| スループット(RPS) | 100%(基準) | 95% - 105% | 静的 PGO 適用時は **JIT を凌駕** |

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

- 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](https://learn.microsoft.com/en-us/ef/core/performance/nativeaot-and-precompiled-queries))
の明確な警告:

> 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 の公式ドキュメントが「実本番では推奨しない」と明記して
  いることが、開発者コミュニティで広く共有されている

**実装上の致命的な制約:**

| 制限事項 | 影響 |
|---|---|
| 動的 LINQ の非互換性 | ユーザー入力や実行時条件で `.Where` や `.OrderBy` を動的に結合するクエリは、ビルド時に静的解析できず **コンパイルエラー**。検索フィルターやダッシュボードクエリの大半が抵触 |
| LINQ クエリ構文の非サポート | `from x in y select z` 形式の包含構文は **未対応** |
| 値コンバーターと状態のキャプチャ | DDD 等で多用されるカスタム値コンバーターの静的コード生成が **サポートされていない** |
| コードの肥大化と生成時間の増大 | すべてのクエリバリエーションに静的インターセプタークラスを生成するため、コンパイル時間が **非現実的な長さ** |

**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(続):分かったこと/分からないことの整理

| 項目 | 結論 |
|---|---|
| OS シェル層のネイティブ化 | **確実に進行中**。Rudy Huyn のチームが具体的な成果を出している |
| Microsoft 365 アプリのネイティブ化 | **発生しない**。新 Outlook も Teams 2.0/3.0 も WebView2 ベース |
| サードパーティ層のネイティブ化 | **発生する見込みはない**。経済的合理性が変わらない |
| .NET 10 Native AOT のマイクロサービス領域 | **本番レディ**。AWS Lambda 等で 70% コスト削減事例 |
| .NET 10 Native AOT の **EF Core 領域** | **本番非推奨**(Microsoft 自身が明記)。動的 LINQ 非互換、コンパイル時間非現実的 |
| Microsoft.Data.SqlClient 7.0 + AOT | **回帰バグあり**(Entra ID 認証クラッシュ) |
| 「100% ネイティブ」の意味 | **OS シェル層に限定**。アプリケーション全体ではない |
| クラシック Outlook の終焉 | **少なくとも 2029 年まで継続**。Web 移行ですら難航 |
| WinUI 3 の長期持続性 | **未確定**。WPF / UWP の前例から、開発者コミュニティは慎重 |

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

- 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
ネイティブ回帰)を並べると、構造的な対比がさらに明確になる。

| 事例 | 失敗の方向 | 典型的な被害 | 検証で見抜く方法 |
|---|---|---|---|
| **WordPress / Mullenweg** | 個人が責任を持ちすぎる(過度な集中) | 個人の機嫌・対立で組織全体が振り回される | 個人の発言を時系列で並べると矛盾が出る |
| **Node.js / npm** | 誰も全体を管理しない(全体不在の分散) | サプライチェーン事故、燃え尽き、責任の所在不明 | ガバナンス構造を一次情報で整理すると、責任主体が分裂している |
| **CentOS / Red Hat / Ubuntu** | 企業ステワードが約束を書き換える | 数年単位の長期計画が突然崩れる、移行コスト | 過去 5〜10 年の方針変更を時系列で並べる |
| **Microsoft「ネイティブ回帰」** | 情報インフラの所有者が AI を経由して物語を浸透させる | 技術選定で範囲を見誤り、AI も同じ誤りを増幅する | チャット型 AI と Deep Search を組み合わせ、一次情報を要求する |

---

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

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のネイティブアプリ回帰戦略.pdf)
  ── Microsoft の「ネイティブ回帰」発表の全体像

---

## 関連

- 第11章本文: [AIで物語を検証する](/ai-native-ways/verify-narratives/)
- 実例 1: [Node.js を仕事で採用すべきか](/ai-native-ways/verify-narratives/example-1/)
- 実例 2: [Linux ディストリビューションを何で選ぶべきか](/ai-native-ways/verify-narratives/example-2/)
- 構造分析シリーズ: [Mythos 時代のセキュリティ設計](/insights/security-design/)