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 ── Gemini Pro が出力した資料。EF Core / SqlClient の AOT 対応を「ほぼ完璧」と要約しており、致命的な過大評価を含む
• 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 時代のセキュリティ設計