Skip to content

Instantly share code, notes, and snippets.

Show Gist options
  • Select an option

  • Save TakashiSasaki/8af2b415e75e2db82e09c153c1307205 to your computer and use it in GitHub Desktop.

Select an option

Save TakashiSasaki/8af2b415e75e2db82e09c153c1307205 to your computer and use it in GitHub Desktop.

App Paths の廃止とアプリ実行エイリアスへの移行

はじめに

従来、Windows ではアプリケーションの実行ファイルのパス解決に「App Paths」と呼ばれるレジストリキーが活用されていました。
具体的には、

  • HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\App Paths
  • HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\App Paths
    といったキーに、アプリケーションの実行可能ファイル名とその完全修飾パスが登録され、ユーザーはコマンドラインや「ファイル名を指定して実行」で直接ファイル名を入力するだけでアプリケーションを起動できました。

しかし、最新の Windows では、より柔軟で安全な方法として「アプリ実行エイリアス」が導入され、これらのレガシーな App Paths キーは下位互換性のために保持されるものの、実際のコマンド検索時には利用されなくなりました。

App Paths の役割とその限界

App Paths キーは、実行可能ファイル名をフルパスにマッピングする仕組みとして、Windows 7 や初期の Windows 10 などで広く利用されてきました。
この方式では、たとえば「notepad.exe」と入力すると、システムは App Paths キー内のエントリを参照して「C:\Windows\System32\notepad.exe」などのパスを取得し、アプリケーションを起動しました。

しかし、パッケージ化や UWP(Universal Windows Platform)アプリの登場、さらにはセキュリティや管理の観点から、従来のレジストリ依存の方法には以下のような課題がありました。

  • 下位互換性のための冗長性
    古いアプリケーションとの互換性を保つためにレジストリに登録される一方、最新のシステムでは実際のコマンド検索処理で使用されないケースが増加。
  • セキュリティと管理の複雑化
    レジストリの一部として公開される情報は、管理やセキュリティ上のリスクとなる可能性がある。

アプリ実行エイリアスの導入

Windows 10 Fall Creators Update(バージョン 1709)以降、Microsoft は新たな仕組み「アプリ実行エイリアス」を導入しました。
この仕組みでは、従来の App Paths キーではなく、各ユーザーの以下のフォルダ内に配置されるプレースホルダファイルが実行ファイルの起動に利用されます。

  • %LOCALAPPDATA%\Microsoft\WindowsApps

このフォルダに配置されたファイルは、NTFS の再解析ポイント(リパースポイント)として実装され、
IO_REPARSE_TAG_APPEXECLINK(0x8000001B)という専用のタグが設定されています。
従来のシンボリックリンクで使われる IO_REPARSE_TAG_SYMLINK(0xA000000C)とは異なり、アプリ実行エイリアス専用に設計されたタグとなっています。

アプリ実行エイリアスの特徴

  • 簡単な起動
    ユーザーはコマンドラインや「ファイル名を指定して実行」でエイリアス名を入力するだけで、実際のアプリケーションが起動します。
  • 下位互換性の維持
    既存の App Paths キーはシステム上に残りますが、最新のコマンド検索ではこの情報は参照されず、アプリ実行エイリアスが優先されます。
  • セキュリティの向上
    再解析ポイントを利用することで、レジストリの公開情報に頼らずにアプリケーションのパス解決が可能になり、セキュリティ面での改善が期待されます。

まとめ

最新の Windows(Windows 10 Fall Creators Update 以降および Windows 11)では、従来の App Paths キーに依存する方法から、
%LOCALAPPDATA%\Microsoft\WindowsApps 内に配置されるアプリ実行エイリアスによって実行ファイルのパス解決が行われるようになりました。
これにより、古いアプリケーションとの互換性は下位互換性として保持しつつ、現代のアプリケーション環境に適した安全かつ柔軟な実行メカニズムが提供されています。

参考情報:
citeturn2search0 Learn Microsoft – App registration ドキュメント
citeturn2search1 Microsoft の再解析ポイントと App Execution Alias に関する情報

次の例が示すように、レジストリに App Paths が登録されていても、実際の再解析ポイント(WindowsApps フォルダ内のプレースホルダファイル)が作成されていない場合、コマンドラインで firefox.exe を入力しても起動できません。これは、Windows 10/11 の「アプリ実行エイリアス」設定がオフになっていると、エイリアス用の再解析ポイントが生成されないためです。


具体例:Firefox の場合

  1. レジストリ上には Firefox が登録されている

    • PowerShell などで
      Get-ChildItem -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\App Paths"
      を実行すると、Firefox のパスが確認できます。
    • しかし、App Paths キーがあっても、最新のコマンド検索ではここを参照しません。
  2. WindowsApps フォルダに reparse point(プレースホルダファイル)がない

    • C:\Users\<ユーザー名>\AppData\Local\Microsoft\WindowsApps ディレクトリを確認すると、Firefox.exe に対応する再解析ポイントが存在しない。
    • コマンドラインで firefox.exe と打っても「見つかりません」エラーになる。
  3. 「アプリ実行エイリアス」の GUI で Firefox がオフ

    • Windows の「設定」→「アプリ」→「アプリ実行エイリアス」で確認すると、Firefox のトグルがオフになっている。
    • トグルがオフの場合は、再解析ポイントが作成されないため、コマンド検索で見つけられない。
  4. トグルをオンにすると再解析ポイントが生成される

    • Firefox のトグルをオンにしてから WindowsApps フォルダを見ると、firefox.exe(サイズ 0 バイトの実行ファイル)が新規に作成される。
    • これが再解析ポイント(リパースポイント)であり、実際の Firefox 実行ファイルへのリンク情報を保持している。
    • コマンドラインから firefox.exe と入力すると、今度は正常に起動できるようになる。

まとめ

  • レジストリの App Paths は下位互換性のために残っている
    実際にはコマンド検索に使われないので、そこに Firefox が登録されていても、アプリ実行エイリアスがオフならば起動できません。

  • アプリ実行エイリアスのトグルがオンかオフかが重要
    オンにすることで、WindowsApps フォルダ内に再解析ポイントが生成され、firefox.exe というコマンド名で起動できるようになります。オフの場合はその再解析ポイントが作られないので、コマンドラインで見つけられません。

  • 再解析ポイントの仕組み
    アプリ実行エイリアスは、NTFS の再解析ポイントを使って実際の実行ファイルへのリンク情報を保持しており、従来のシンボリックリンク (IO_REPARSE_TAG_SYMLINK) ではなく、IO_REPARSE_TAG_APPEXECLINK(0x8000001B)という専用タグを使っています。

このように、GUI 上でアプリ実行エイリアスをオンにしないと再解析ポイントが作成されず、コマンドラインからは起動できないという挙動が、Firefox をはじめとする多くのアプリで共通の仕組みとなっています。

アプリ実行エイリアスと再解析ポイントの仕組み

はじめに

Windows 10 Fall Creators Update 以降、Microsoft は従来のレジストリ上の App Paths キーに依存しない新たな実行方式として「アプリ実行エイリアス」を導入しました。
この仕組みは、ユーザーがコマンドラインや「ファイル名を指定して実行」でアプリケーション名を入力するだけで、対応するアプリを起動できるように設計されています。

本記事では、アプリ実行エイリアスがどのように NTFS の再解析ポイントを利用して実現されているのか、そしてシンボリックリンクとの違いや専用のリパースタグが採用されている点について詳しく解説します。

再解析ポイントとは?

NTFS には「再解析ポイント(Reparse Point)」という機能があり、これは特定のファイルまたはディレクトリに追加のメタデータを付与して、アクセス時にその情報に基づく動作(たとえば、リダイレクトやシンボリックリンクのような挙動)を実現する仕組みです。
再解析ポイントは、ファイルシステムレベルで動作するため、ユーザー側からは単なるファイルやフォルダとして扱われますが、内部的には追加の処理が施されています。

アプリ実行エイリアスの実装

専用のリパースタグの採用

アプリ実行エイリアスは、従来のシンボリックリンクで用いられる
IO_REPARSE_TAG_SYMLINK(0xA000000C)
ではなく、専用のリパースタグ
IO_REPARSE_TAG_APPEXECLINK(0x8000001B)
を使用して実現されています。

この専用タグの採用により、システムはアプリ実行エイリアスとして登録されたプレースホルダファイルを識別し、通常のシンボリックリンクとは異なる動作を行います。
具体的には、これらのプレースホルダファイルは NTFS 上の再解析ポイントとして実装され、ユーザーが入力したエイリアス名に対応する実際のアプリケーション実行ファイルへのマッピング情報を内部に保持しています。

%LOCALAPPDATA%\Microsoft\WindowsApps フォルダの役割

最新の Windows では、各ユーザーの
%LOCALAPPDATA%\Microsoft\WindowsApps
フォルダ内にアプリ実行エイリアスのプレースホルダファイルが配置されます。
これらのファイルは、サイズが 0 バイトであっても、再解析ポイントとしての情報(実行可能ファイルの実際のパスなど)を持っており、ユーザーがコマンドラインでエイリアス名を入力すると、この情報をもとにアプリケーションが起動されます。

シンボリックリンクとの違い

シンボリックリンクは、単純に別のファイルやフォルダへの参照情報を保持する機能です。
一方、アプリ実行エイリアスで採用されている専用のリパースタグは、アプリ実行専用に設計されており、単なる参照情報だけでなく、実行時の振る舞い(たとえば、パッケージ化されたアプリケーションの起動や UWP アプリとの連携)を適切に制御するための情報を格納しています。
この点において、シンボリックリンクよりも柔軟で安全なアプローチといえます。

まとめ

アプリ実行エイリアスは、従来の App Paths キーに代わり、
%LOCALAPPDATA%\Microsoft\WindowsApps
フォルダ内に配置された NTFS 再解析ポイントとして実現されています。
専用のリパースタグ(IO_REPARSE_TAG_APPEXECLINK)を使用することで、従来のシンボリックリンクとは異なる動作を行い、アプリケーションの起動処理をより安全かつ柔軟に管理しています。

この仕組みにより、最新の Windows ではパッケージ化されたアプリや UWP アプリの起動がスムーズに行われ、下位互換性を保ちながらも現代のアプリケーション環境に適した実行方式が実現されています。

参考情報:
citeturn2search0 Learn Microsoft – App registration ドキュメント
citeturn2search1 Microsoft の再解析ポイントと App Execution Alias に関する情報

@TakashiSasaki

Copy link
Copy Markdown
Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment