要約:
Windows 11 には、長らくユーザーを混乱させてきた設計があります。64 ビット システムでは、C:WindowsSystem32 は実際には 64 ビット システム ファイルを保存しますが、名前に「64」が含まれる C:WindowsSysWOW64 ディレクトリには代わりに 32 ビット ファイルが保存されます。 Windows の歴史を知らないユーザーにとって、この名前付けスキームは完全に逆に見えるかもしれません。
マイクロソフトのエンジニアは最近、この設計の背後にある理由を再度説明しました。その答えは、Microsoft が単にディレクトリ名を逆にしたということではなく、古いパスに依存する多くのソフトウェアが壊れるのを避けるためだということです。 Windows が 32 ビット アーキテクチャから 64 ビット アーキテクチャに移行したとき、Windows はすでに広く使用されている System32 ディレクトリ名を保持することを選択し、ファイル システム リダイレクト メカニズムを使用して、32 ビット プログラムが別のシステム ファイルのセットに自動的にアクセスできるようにしました。
Windows 最新では、2026 年 10 月 20 日にこの問題を紹介し、関連するメカニズムを Microsoft の公式技術文書と併せて説明した記事を公開しました。報告書は、この設計はソフトウェア互換性に対する Windows の長期的なこだわりを完全に反映していると指摘しました。古い命名方法がもはや直感的ではなくなったとしても、性急な変更によって多数のプログラムが実行できなくなる可能性がある限り、Microsoft は元の構造を維持し、互換性レイヤーを通じて問題を解決する傾向があります。
この設計を理解するには、Windows の初期の時代に戻る必要があります。
16 ビット Windows の時代、システム ファイルは主に C:WindowsSystem ディレクトリに保存されていました。 Microsoft が 32 ビット Windows を発売したとき、システムには 32 ビット システム ファイルを収容するための新しいディレクトリが必要だったので、C:WindowsSystem32 が使用されました。 「32」は確かに当時の 32 ビット システム アーキテクチャに関連しています。
しかし、64 ビット Windows が登場すると、事態は複雑になりました。多くのソフトウェアは System32 をプログラム コードにプログラムしており、Windows が提供するシステム インターフェイスを通じて正しいシステム ディレクトリを動的に取得する代わりに、このパスを直接使用してシステム ファイルにアクセスしています。
64 ビット Windows の起動時に Microsoft が System32 の名前を System64 に直接変更すると、多くの古いプログラム、インストーラー、バッチ スクリプトが必要なシステム ファイルを見つけられなくなる可能性があります。開発者がソフトウェアを再コンパイルしたとしても、ハードコーディングされたパスをすべて時間内に修正できない可能性があります。
さらに問題なのは、一部のソフトウェアは 64 ビット バージョンにアップグレードした後も、デフォルトで System32 から対応するシステム コンポーネントを読み取ることです。 Microsoft が 32 ビット ファイルのみを保存するように System32 を変更すると、これらの 64 ビット プログラムは必要なダイナミック リンク ライブラリを正常にロードできなくなります。
そのため、Microsoft は最終的に、歴史的な名前 System32 を保持し、64 ビット Windows のオペレーティング システムのネイティブ アーキテクチャに一致するファイルを保存できるようにすることを決定しました。 Windows 11 のメインストリーム x64 バージョンの場合、これは、System32 が 64 ビット バージョンのシステム コンポーネントを保存し、32 ビット バージョンが別のディレクトリに配置されることを意味します。
このディレクトリは SysWOW64 です。
WOW64 は、「Windows 32-bit on Windows 64-bit」の略称で、32 ビット Windows アプリケーションを 64 ビット Windows 上で実行するための互換性メカニズムです。 SysWOW64 の「64」は、ファイル自体が 64 ビットであることを意味するのではなく、SysWOW64 が存在する 64 ビット Windows 環境を指します。つまり、名前は、ディレクトリ内のバイナリのビット数ではなく、互換性メカニズムがターゲットとしているプラットフォームを表します。
マイクロソフトのシニア エンジニア、レイモンド チェンはかつて技術記事の中で、一部のブランド名と同様に、System32 の「32」は徐々に歴史的なレガシー名になってきており、元の意味を完全に反映しなくなったとしても、長期使用により依然として残り続けると説明しました。
システム全体を再設計できる場合、より理想的なディレクトリ名は、現在のシステム アーキテクチャに一致する実行可能ファイルを保存するために使用される SysExec のような名前になる可能性があると彼は考えています。しかし、Windows は数十年前から存在しており、System32 は長い間、無数のプログラムが依存する固定パスであったため、名前を変更することによる潜在的なリスクが、名前を付けることによるメリットをはるかに上回っています。
64 ビット Windows では、ディレクトリの命名に加えて、より現実的な問題も解決する必要があります。つまり、32 ビット プログラムは 64 ビット ダイナミック リンク ライブラリを直接ロードできず、64 ビット プログラムは 32 ビット ダイナミック リンク ライブラリを直接ロードできません。
たとえば、kernel32.dll は Windows の重要なシステム コンポーネントです。同じ名前のファイルは System32 と SysWOW64 にありますが、これらは異なるアーキテクチャ用にコンパイルされているため、単純に交換することはできません。最新の Windows が Windows 11 26H2 システム内のこれら 2 つのディレクトリをチェックしたとき、対応するファイルのサイズの違いも見つかりました。
32 ビット プログラムが System32 に 64 ビット バージョンを直接ロードすると、バイナリ アーキテクチャに互換性がないため実行できない可能性があります。この状況を回避するために、Windows は WOW64 ファイル システム リダイレクターを導入しました。
64 ビット Windows では、32 ビット プログラムが C:WindowsSystem32 にアクセスしようとすると、通常、システムはアクセス要求を自動的に C:WindowsSysWOW64 にリダイレクトします。このプロセスは基本的にプログラム自体に対して透過的であり、プログラム自体は依然として System32 にアクセスしていると認識しており、オペレーティング システムはそのプログラムに適した 32 ビット ファイルを舞台裏で見つけます。
Microsoft の公式ドキュメントには、64 ビット Windows の System32 ディレクトリは 64 ビット アプリケーション用に予約されており、WOW64 は一部のシステム パスへの 32 ビット プログラムのアクセスを対応する 32 ビット ディレクトリにリダイレクトする役割を担っていると明確に記載されています。
このメカニズムには、システム ダイナミック リンク ライブラリだけでなく、一部のシステム ツールも影響します。たとえば、32 ビット プログラムが Windows ディレクトリ内の特定のツールにアクセスすると、SysWOW64 の対応するバージョンにリダイレクトされる場合があります。これにより、オペレーティング システムのアーキテクチャが一致しない場合に、32 ビット プログラムが 64 ビット ツールを誤用したり、誤った操作を実行したりすることが防止されます。
WOW64 は、レジストリ アクセスやプログラムのインストール パスなどの互換性の問題も処理します。 32 ビット アプリケーションの場合、Windows は別のレジストリ ビューを提供できます。通常の場所は HKEY_LOCAL_MACHINESoftwareWow6432Node です。また、システムは通常、32 ビット プログラムの Program Files パスを C:Program Files (x86) にポイントするため、異なるアーキテクチャのソフトウェアを可能な限り個別に管理できます。
これらのメカニズムは合わせて Windows 互換システムの一部を形成しており、開発者が古いプログラムごとにすべてのコードを書き直すことなく、初期の 32 ビット Windows 用に作成された多数のソフトウェアを 64 ビット Windows 11 上でも実行できるようになります。
ただし、ファイル システムのリダイレクトは、開発者を混乱させやすい状況を引き起こす可能性もあります。
たとえば、32 ビットのコマンド プロンプトと 64 ビットのコマンド プロンプトでは、一見同一のパスを使用して C:WindowsSystem32kernel32.dll にアクセスしても、取得される実際のファイルは異なる場合があります。前者は通常 SysWOW64 にリダイレクトされ、後者は System32 に直接アクセスします。
Microsoft Visual Studio チームの元メンバーである Matt Pitrek 氏は、32 ビットのコマンド プロンプトで 2 つのディレクトリに同じ名前のファイルがリストされ、混乱を招く結果になったため、問題のトラブルシューティングにも時間を費やしたと技術記事で述べています。これは、ファイル システムのリダイレクトによってソフトウェアの互換性は維持できるものの、システムのデバッグや開発作業がより複雑になることがわかります。
いくつかの特殊な状況を解決するために、Microsoft は Sysnative と呼ばれる仮想パスも提供しています。 32 ビット プログラムが 64 ビット Windows のネイティブ System32 ディレクトリにアクセスする必要がある場合は、C:WindowsSysnative を使用して通常のファイル システム リダイレクトをバイパスできます。
Sysnative はディスク上の実際のフォルダーではなく、Windows によって特別に提供されるパス エイリアスであることに注意してください。 64 ビット アプリケーションは、32 ビット プログラムのようにこのエイリアスを使用できないため、ユーザーがエクスプローラーで Sysnative を直接検索すると、パスが存在しないというメッセージが表示される場合があります。
Microsoft は、通常のファイル システム リダイレクトの影響を受けない、次のような多数の System32 サブディレクトリもリストしています。
C:WindowsSystem32catroot
C:WindowsSystem32catroot2
C:WindowsSystem32driverstore
C:WindowsSystem32driversなど
C:WindowsSystem32 ログファイル
C:WindowsSystem32spool
これらのディレクトリには、システム コンポーネント ディレクトリ、ドライバー ストレージ、ネットワーク構成ファイル、ログ記録と印刷などの機能が含まれます。 Microsoft のドキュメントには、これらの例外パスが明確にリストされていますが、各例外の具体的な設計理由については統一された説明がありません。 Windows 最新では、これらのディレクトリの一部には、ドライバーなどのホスト ファイルなど、異なるアーキテクチャのプログラムが共同でアクセスする必要があるデータが含まれている可能性があると考えられます。
x64 プラットフォームに加えて、Arm アーキテクチャ上の Windows 互換メカニズムでも同様のマルチディレクトリ設計が採用されています。
Arm システム上の一部の初期の Windows では、32 ビット x86 プログラムは SysWOW64 を使用しますが、32 ビット Arm プログラムは SysArm32 を通じて対応するシステム コンポーネントにアクセスできます。 Arm プラットフォームは異なる命令セット アーキテクチャ間の互換性の問題に対処する必要があるため、Windows も対応するシミュレーションおよび変換メカニズムを使用します。
ただし、Microsoft の最新の Arm 開発ドキュメントには、Arm 上の Windows は 32 ビット Arm アプリケーションをサポートしなくなり、関連するシステム バイナリも SysArm32 ディレクトリから削除されると記載されています。同時に、通常の x86 アプリケーションは互換性メカニズムを通じて引き続き実行でき、一部の x86 プログラムは Prism エミュレーション テクノロジによってサポートされています。
これは、Windows 互換システムが完全に静的ではないことも示しています。ハードウェア プラットフォームとソフトウェア エコシステムの変化に伴い、Microsoft は引き続き一部の古いアーキテクチャのサポートを段階的に終了しますが、依然として広く使用されているアプリケーションについては、可能な限り互換性を維持するよう努めます。
技術的な観点から見ると、System32 と SysWOW64 の命名は確かに十分直感的ではありません。一般のユーザーにとって、「64」という文字を見れば、そのディレクトリには 64 ビットのファイルが格納されていると考えるのが自然です。しかし Windows では、ディレクトリ名は直感に従うようにゼロから設計された一連のルールではなく、歴史を反映しています。
Microsoft が 2 つのディレクトリの名前を単純に変更しなかった主な理由は、互換性でした。 Windows は多くの歴史的なソフトウェアを実行する必要があり、これらのプログラムは固定パス、レガシー システム インターフェイス、および特定のバイナリ ファイル レイアウトに依存している場合があります。これらのインフラストラクチャを無謀に変更すると、ソフトウェアのインストールに失敗したり、システム ツールに異常が発生したり、古いコンポーネントに依存するビジネス プロセスに影響を与えたりする可能性があります。
そのため、Microsoft はディレクトリ命名システムを完全に再構築するのではなく、ファイル システム リダイレクト、レジストリ リダイレクト、仮想パスなどのメカニズムを通じて問題を解決することを選択しました。
この設計は完璧ではありませんが、Windows と他のオペレーティング システムの開発経路における重要な違いを反映しています。Windows は常に、継続的な最新化と数十年前のソフトウェアとの互換性の間のバランスを見つける必要があります。 System32 と SysWOW64 の一見逆転した名前は、この長期的な互換性戦略によって残された典型的な痕跡です。
コメント