Windows 11のファイルを右クリックするたびに起動する、1990年代のコード
Windows 11でファイルをクリックし、右クリックメニューを開く。一見何でもない操作だが、その瞬間に実行されているのは、インターネットが商業化される以前の1990年代に書かれたコードである。Win32 APIは、Windows 95以前のWindows NTにまでその起源を遡る。MicrosoftのAzure最高技術責任者（CTO）であり、Sysinternalsの創設者でもあるMark Russinovichは、2026年5月にMicrosoft Dev Docsの公式Xアカウントに投稿されたビデオの中でこう言い切っている。「1990年代に、Win32が2026年においても第一級のAPIサーフェスであり続けると予想した人間はいなかったと思う。当時の我々が思い描いていたのは、空飛ぶ車や月面基地であって、Win32ではなかった」。
Win32とは、Windowsアプリケーションがプロセス管理、ファイルI/O、GUIの描画、メモリ確保といった低レイヤのOS機能を呼び出すためのインターフェース群（Application Programming Interface）のことである。その定義が確立されたのはWindows 95の時代だが、Microsoftは今日も公式のプログラミングリファレンスドキュメントのメンテナンスを続けている。このAPIを経由してOSと通信するコードは、エクスプローラー、タスクマネージャー、コントロールパネルなど、Windows 11を構成するコアコンポーネントの至るところに潜んでいる。
刷新しようとするたびに失敗してきた30年間
Russinovichの発言が指摘する通り、Microsoftは過去30年間にわたって幾度となくWin32の置き換えを試みてきた。その歴史は、断念されたフレームワークの墓場と言える。
最初の本格的な交代候補はWindows Presentation Foundation（WPF）である。XAMLという宣言型マークアップとハードウェアアクセラレーションによるレンダリングを導入し、Win32の後継として設計されたが、完全な移行には至らなかった。続いてSilverlight（シルバーライト）がクロスプラットフォーム展開を目指したが、HTML5の台頭によって短命に終わった。
最もラジカルな置き換えの試みはWindows 8で登場したWinRT（Windows Runtime）である。セキュリティを前提とした完全サンドボックス型のAPIで、タッチ操作に最適化されたModernアプリを想定していた。しかしWindows 8のUIは市場に受け入れられず、WinRTはWin32を代替するのではなく、デスクトップとは切り離された別個の存在として扱われるようになった。
Russinovich自身もビデオの中で振り返っている。「MicrosoftがWindowsのAPIサーフェスを刷新しようとした時期は何度もあった。WinRTがその例で、実際には多くの人が予期した形には展開しなかった。デスクトップのWin32とブラウザ（HTMLとJavaScript）という分断が依然として残ったからだ」。
WinRTの失敗を受けてWindows 10で導入されたUniversal Windows Platform（UWP）も、過剰なサンドボックス制限が開発者に嫌われた。深いOSアクセスを必要とするデスクトップアプリ開発者にとって、UWPは制約が多すぎたのである。
なぜWin32は、これほど多くの交代候補を押しのけて生き残ったのか
フレームワークの刷新に繰り返し失敗した理由は、技術的な優劣だけでは説明がつかない。Win32の存続を支えたのは、その上に積み重なったエコシステムの巨大さである。
このダイナミクスについてRussinovichは「Win32が持続している理由のひとつは、Windowsの根底にある基本的なレイヤーに、あまりにも多くのアプリ、技術、エコシステムが構築されたことだ。それはいわば地層（bedrock）のようなものだ」と説明する。
このダイナミクスは、技術的な進化を研究する上で典型的なパターンを示している。あるプラットフォームが普及すると、その上に無数の依存関係が積み重なり、やがてそのプラットフォームの置き換えコストは、置き換えによって得られる利益を遥かに上回るようになる。Win32はこのロックインの典型例である。世界中の数十万本のソフトウェアが、コンパイル済みのバイナリレベルでWin32の関数呼び出しに依存している。MicrosoftがWin32を廃止すれば、既存のアプリケーション資産が一夜にして動作不能となるリスクがある。
Russinovichはこの力学を自身のプロジェクトで具体的に示している。1996年に彼が書いたSysinternalsのツール群について、「2026年もまだ現役だとは100万ドルを賭けてもあり得ないと当時は思っていた」と語りつつも、現実にはSysmonがWindows 11の2026年3月更新でOSへの直接統合を果たし、ZoomItはPowerToysの人気コンポーネントとして今も広く使われている。Win32の地盤が揺らがない限り、その上に立つSysinternalsも揺らがないのである。
WebView2という失敗を経て、WinUI 3によるネイティブ回帰へ
Microsoftがネイティブフレームワークの置き換えを繰り返し断念したことは、別の深刻な問題を生んだ。開発者がWindowsプラットフォームへの投資を忌避し始めたのである。どのフレームワークに乗っても、いずれMicrosoftに廃止されるリスクがあると、開発者はプラットフォームへの長期的コミットを諦めた。
その結果として広まったのが、WebView2を用いたWebアプリの包み込みである。WebView2はChromiumベースのMicrosoft Edgeエンジンをデスクトップアプリ内に埋め込む開発者コントロールで、現在はMicrosoft Teams、Clipchamp、新しいOutlook、OneDriveクライアント、Windows 11のウィジェットボード、そしてCopilotまでもがこのアプローチを採用している。Web技術は開発コストを下げ、複数プラットフォームへの展開を容易にするが、その代償は深刻なシステムリソースの消費である。フルブラウザエンジンをアプリ単位で個別に組み込む設計は、RAMを食い潰す。実際、WhatsAppデスクトップアプリは何も処理していない待機状態でも異常なほどのメモリを消費する。UWP時代に採用していた軽量なネイティブコードをWebラッパーに置き換えた結果が、そのままRAM使用量に現れている。
Microsoftはこの状況の危うさにようやく気づき、現在はWinUI 3を軸とした段階的なネイティブ回帰を進めている。MicrosoftのパートナーアーキテクトであるRudy Huynは、Windows 11向けの「100%ネイティブ」アプリを専門に開発するチームの採用を進めていることを明言しており、この方針転換が組織レベルで本格的に動き出していることを示している。WinUI 3はWindows App SDK傘下の最新ネイティブUIフレームワークで、Fluent Designに準拠したモダンなUIを、Win32の「地層」へのフルアクセスを維持したまま構築できる。Windows App SDK 2.0ではセマンティックバージョニング、再設計されたWindows MLスタック、WebView2コンテンツとネイティブWinUI 3シェルを統合するドラッグアンドドロップ機能が追加された。
具体的な成果も出始めている。Windows 95以来の設計のままだったFile ExplorerのPropertiesダイアログがWinUI 3ベースの新バージョンに置き換えられ、ダークモードが完全サポートされた。同様にWin32で実装されていたRunダイアログ（Win + R）も.NET AOTでコンパイルされたWinUI 3アプリケーションとして完全に書き直され、起動までの中央値時間は94ミリ秒を達成した。これはWin32による旧来の実装よりも速い数値であり、WinUI 3がパフォーマンスの面でWin32に引けを取らないことを実証している。
重要なのはMicrosoftが今回採用しているアプローチが「段階的な移行」であることだ。WinRTの時のように既存のエコシステムに対して断絶を強制するのではなく、Win32の地盤は残したまま、その上に構築されているUIレイヤーをWinUI 3に置き換えていく。これにより、既存の大量のWin32依存アプリを動作させながら、Windows 11のシステム全体のメモリ効率と応答性を段階的に改善できる。
Russinovichが「2026年においてWin32は以前よりも現役だ」と述べた言葉には、皮肉と事実の両方が含まれている。1990年代のコードが現代の最先端OSの根幹を担い、それを置き換えるあらゆる試みがことごとく失敗に終わった事実は、ソフトウェアアーキテクチャにおけるロックインの強固さを示している。空飛ぶ車は実現しなかったが、Win32は生き残った。そしてMicrosoftはそのWin32という「地層」を掘り崩すことなく、その上の建物を建て替えるという現実的な選択肢を歩み始めている。
