Windowsのショートカットは、移動したファイルをどうやって見つけるのか？ ── ファイルの「場所」と「同じファイルであること」は別の話

Windowsのショートカットは、保存された場所でリンク先が見つからないとき、利用できる追跡情報やファイルの特徴から探し直せます。ただし、開けたことだけでは、以前と同じファイルであるとは証明できません。

図の実線は常に成り立つ関係、破線は条件付きの関係です(成立条件は詳細ページの各関係の説明に記載)。関係すべての一覧(全5件、根拠・確度つき)と主要概念の定義は知識マップ詳細ページにまとめています。データ: JSON-LD / Turtle

問題・質問

「下書き」フォルダーの企画書にショートカットを作り、企画書本体を「提出用」へ移しました。ショートカットを作り直していないのに、移動後の企画書を開けることがあります。元の場所にないファイルを、Windowsはどうやって見つけるのでしょうか。

この記事では、移動や改名に追従できる理由と、同じ内容のコピーや元の場所に置いた別ファイルを、元のファイルそのものと区別できるのかを説明します。自分の環境で挙動を確認する手順と、アプリからリンク先を解決するときの注意点も扱います。

対象環境

対象は、Windowsのシェルが扱う、普通のファイルを指す.lnkショートカットです。説明と確認手順は、ローカルの同じNTFSボリューム内でファイル本体を移動・改名する場合を中心にします。URLへのリンクや、ファイルシステムのシンボリックリンクの説明ではありません。

分散リンク追跡と、ファイルの特徴による探索は別の仕組みです。結果は残っている情報、ファイルシステム、サービス、管理ポリシー、APIの呼び出し方などに左右されます。USB、同期フォルダー、ネットワーク共有、別のPCへの移動まで、同じ結果を保証するものではありません。分散リンク追跡の適用条件とResolveの動作条件を参照してください。

既存の実測は、Windows Server 2025 Datacenter（10.0.26100、ビルド26100）、ローカルの同一NTFSボリューム、追跡サービスがRunningの環境に限られます。COM APIのIShellLinkW::Resolveを使った観測であり、Windows 11のエクスプローラー画面での試験ではありません。結果は「確認」で、読者向けの手順とは分けて示します。

回答・解決方法

ショートカットは、保存されたパスだけでなく、リンク先を探し直すための情報も持てるため、移動や改名に追従できることがあります。通常のリンク解決では、保存された場所を確認し、そこになければ利用可能な分散リンク追跡を試し、それでも見つからなければ特徴による探索を試みます。追跡や探索を実施するかは設定や指定フラグにも依存します。Shell Links

これは、開けるリンク先を見つけるための仕組みです。内容をすべて比較したり、毎回元のファイルであることを証明したりする仕組みではありません。元の場所に同じ名前の別ファイルがあれば、そちらを開く可能性もあります。

定義

シェルショートカット（.lnk）

Windowsのシェルが別の対象へアクセスするための情報を保存したファイルです。プロパティの「リンク先」に表示される一行が、その情報のすべてではありません。Shell Links

リンクの解決

ショートカットの保存情報を使い、必要に応じてリンク先を探し直す処理です。アプリから明示的に行う場合は、IShellLinkW::Resolveを使います。保存されているパスを取得するだけの処理とは区別します。Shell LinksのLink Resolution

パス

ファイルやフォルダーの場所と名前を表す情報です。保存されたパスに対象が見つかることと、その対象が移動前から続く元のファイルであることは別の条件です。Shell LinksのLink Resolution

ファイルの同一性

ここでは、内容が一致するだけでなく、移動前から続く同じファイルであることを指します。この記事では、「同じパスにある」「同じ内容を持つ」「移動前から続く同じファイルである」を区別します。パスは場所と名前を表します。同じNTFSボリューム内で元のファイルを移動・改名することと、内容をコピーして別ファイルを作ることは、同じ操作ではありません。Object Identifiers

Object ID

ボリューム内のファイルやフォルダーを識別する任意の属性です。分散リンク追跡はこれを利用します。必須の属性ではなく、ファイルハンドルから取得するファイルIDとは別の識別情報です。Object IDの説明

ファイルID

ファイルハンドルを通じて取得できる、ファイルを識別する情報です。例えばGetFileInformationByHandleのファイルインデックスは、ボリュームの識別情報と組み合わせて二つのパスの対象を比較します。追跡用Object IDとは別の項目なので、「ID」という呼び方だけで混同しないでください。GetFileInformationByHandle

分散リンク追跡

Object IDなどの追跡情報を利用して、移動したリンク先を探すWindowsの仕組みです。名前や作成日時などから候補を探す方法とは異なり、利用できる情報やサービスの条件に依存します。Distributed Link Tracking and Object Identifiers

特徴による探索

ファイルの名前・作成日時・属性などを手がかりに、リンク先の候補を探す処理です。分散リンク追跡が使えない場合などに試みられますが、特徴の一致だけで元のファイルそのものだと証明する処理ではありません。IShellLinkW::ResolveのRemarks

役割

リンク先へのアクセスの回復

リンク解決の役割は、ファイルの置き場所や名前が変わったときに、ショートカットからのアクセスを回復することです。利用者が必ずショートカットを作り直さなくても済むように、保存した場所以外の手がかりも利用します。Shell Links

同一性確認との役割分担

住所が変わっても別人になるわけではないように、ファイルのパスが変わっても、元のファイルを追う手がかりが残る場合があります。ただし、この比喩は「ショートカットが必ず本人確認をする」という意味ではありません。リンク先の発見と、業務で必要なファイルの同一性の確認は、分けて考えます。

構成

.lnkには、場所に関する情報に加え、リンク先の属性や追跡用の追加情報を保存する形式が定義されています。各情報がすべてのショートカットで有効に使える、という意味ではありません。

パスと識別子リスト

保存された場所に関する情報は、通常の解決で、まずリンク先の所在を確認する手がかりです。表示されるパスだけでなく、シェルの識別子リストなども関わります。Shell Links

ShellLinkHeader

リンク先の属性、作成時刻、ファイルサイズなどの記録欄があります。情報の保存形式と、実際の探索で何を使ったかは別の話です。ShellLinkHeader

TrackerDataBlock

リンク先を探すために、分散リンク追跡サービスへ渡す情報を保持する追加データです。存在するだけで追跡の成功が保証されるわけではありません。TrackerDataBlock

仕組み

通常のリンク解決の大筋を、保存された場所、追跡用の識別情報、ファイルの特徴という三つの手がかりに分けて見ます。個々の呼び出しで通った内部経路を、この説明だけから断定することはできません。

保存された場所の確認

企画書をC:\Work\下書き\企画書.txtから、同じNTFSボリューム内のC:\Work\提出用\企画書.txtへ移したとします。ファイルは一つのままですが、ショートカットが保存していたパスは「下書き」を指しています。

flowchart TB
    accTitle: 企画書の移動で古いパスと現在地が分かれる
    accDescr: ショートカットが覚えている下書きフォルダーには企画書がなく、同じ企画書は提出用フォルダーへ移っています。
    L["ショートカット"] --> O["下書き：もうない"]
    F["同じ企画書"] --> N["提出用：ここにある"]

図1: 古い場所だけをたどる仕組みなら、ここで行き止まりになります。

Windowsのシェルは、まず保存された場所に対象があるかを確認します。そこで見つかれば解決でき、見つからなければ利用可能な情報で探し直します。移動後も開ける理由を考えるには、単に古いパスを読む処理と、この探し直す処理を区別する必要があります。Shell LinksのLink Resolution

Object IDによる追跡

提出用へ移した企画書を提案書.txtへ改名すると、場所と名前の両方が変わります。それでも、元のファイルを移動・改名したのであって、別のファイルを作ったわけではありません。

分散リンク追跡は、NTFS上のファイルやフォルダーに付くObject IDを利用します。Object IDは必須の属性ではなく、そのボリューム内にはObject IDの索引もあります。利用できる追跡情報があれば、古い名前を全フォルダーから探すだけでなく、識別情報を手がかりにできます。Distributed Link Tracking and Object Identifiers

図2では、この識別情報を「名札K」にたとえています。Kは説明用の記号であり、実際のIDの形式ではありません。

flowchart TB
    accTitle: 同じボリュームで移動と改名をしても追える識別情報
    accDescr: 追跡情報が保たれる場合、下書きの企画書から提出用の提案書へ名前と場所が変わっても、同じ名札を手がかりに追跡できます。
    A["企画書：名札K"] -->|"移動・改名"| B["提案書：名札K"]
    L["ショートカットの追跡情報"] -.->|"Kを手がかりに探す"| B

図2: 「どこにあるか」が変わっても、追跡に使える識別情報まで変わるとは限りません。

.lnkのTrackerDataBlockは、この追跡サービスへ渡す情報を保存できます。ただし、すべてのショートカットが、この方法で解決されるわけではありません。TrackerDataBlock

ファイルの特徴による探索

追跡サービスを利用できない、または追跡で見つからない場合、シェルはファイルの特徴による探索も試みます。公式の説明では、元のフォルダーやその近辺などから、名前・作成日時・属性などが合う候補を探します。IShellLinkW::ResolveのRemarks

flowchart TB
    accTitle: 保存された場所から追跡情報と特徴へ手がかりを変える
    accDescr: 保存された場所で見つからなければ利用できる追跡情報を試し、それでも見つからない場合は特徴による探索を試みます。
    P["保存した場所を確認"] -->|"見つからない"| I["追跡情報を利用"]
    I -->|"使えない・見つからない"| S["特徴が合う候補を探す"]

図3: 通常のリンク解決の大筋です。追跡や探索を行うかどうかは、設定や呼び出し方にも左右されます。

「名札が一致した」と「特徴が似ている」は、根拠の強さが違います。同じ名前や作成日時のファイルが複数あれば、特徴だけで元の相手だとは証明できません。これは、内容をすべて比較して同一性を証明する処理ではなく、見失ったリンク先を探し直す処理です。

具体例

同じ内容のコピー

提出用の提案書.txtを「配布用」へコピーすると、同じ内容を持つファイルが二つになります。一方だけを編集しても、もう一方の内容はそのままです。「中身が同じ」と「元のファイルそのもの」は区別しなければなりません。

通常のコピーでは、元と同じObject IDをそのまま引き継ぎません。同じボリュームに同じIDを持つ別ファイルが二つできると、識別子の一意性が失われるためです。Object Identifiers

flowchart TB
    accTitle: ファイルの移動とコピーで同一性の意味が違う
    accDescr: 同じファイルを移動する操作に対し、通常のコピーでは内容を持つ別ファイルが作られ、元の追跡用Object IDはそのまま複製されません。
    O["元の提案書"] -->|"通常のコピー"| C["別ファイルの提案書"]
    O --> A["元の名札"]
    C --> B["同じ名札は引き継がない"]

図4: 中身を同じにすることと、元のファイルそのものを移すことは違います。

元の場所に置いた別ファイル

企画書を提出用へ移した後、空いた下書き\企画書.txtに同じ名前の別ファイルを置いたとします。通常は保存された場所の確認が先なので、そこに対象が見つかれば、移動先を探す段階へ進まないことがあります。Shell LinksのLink Resolution

したがって、追跡機能があることを、必ず移動した元ファイルを選ぶ保証としては使えません。重要な書類を扱うときは、「開けたから正しい」と判断せず、開いた対象のパスと内容を確認します。

手順

以下は自分の環境で挙動を確認するための手順です。この改稿で新たに実行した試験結果ではありません。エクスプローラーでの観察と、開発者向けのAPI呼び出しを分けます。

移動・改名後のリンク先を確認する

書き込み権限のあるローカルNTFSボリュームに、新しい検証専用フォルダーを用意します。例としてC:\ShortcutLabを使いますが、書き込めない場合は別の場所を選びます。同期フォルダーとネットワーク共有は使わず、業務ファイルや既存の同名フォルダーを上書きしないでください。サービスやポリシーの変更、Object IDの編集は不要です。

1. 検証専用フォルダーの中に「下書き」と「提出用」を作成します。

   二つのフォルダーを同じNTFSボリューム内に置きます。使用したOS、ビルド、保存場所も記録します。

2. 「下書き」に企画書.txtを作り、「移動する元ファイル」など判別用の文字を保存して閉じます。

3. そのファイルへのショートカットを作り、検証専用フォルダーに置いて、一度開きます。

   元のファイルが開き、判別用の文字が見えることを確認して閉じます。以降、ショートカット自体は移動せず、リンク先を手動で編集しません。

4. ファイル本体だけを「下書き」から「提出用」へ移動します。

   コピーではなく移動であることと、古い場所にファイルが残っていないことを確認します。

5. 同じショートカットを開き、開いたファイルのパスと判別用の文字を記録して閉じます。

   アプリがフルパスを表示できる場合は、その表示で実際の対象を確認します。タイトルにファイル名だけが出る場合、名前だけでは保存場所を確認したことになりません。

6. 提出用のファイル本体を提案書.txtへ改名し、同じショートカットからもう一度開いて結果を記録します。

   開けなかった場合は、表示されたエラーや対象の不在を記録します。移動先を手動で指定して開いた結果は、自動で見つけた結果と分けます。

追跡または探索で移動先を見つけられた場合、提出用のファイルが開きます。開けない結果もあり得ます。成功だけでは、Object IDによる追跡が使われたのか、特徴による探索が使われたのかは判定できません。

元のパスの再利用を試す

前の試行とは別の新しい検証専用フォルダー、ファイル、ショートカットで最初からやり直します。一度解決したショートカットはリンク情報が更新され得るため、使い回すと比較の条件が変わります。移動前のファイルには「元ファイル」、代わりに置くファイルには「別ファイル」と異なる文字を保存します。Resolveの更新条件

1. 新しい「下書き」に元ファイルを作り、そのショートカットから開けることを確認して閉じます。

2. 元ファイル本体を「提出用」へ移動します。

   ここではまだショートカットを開かないでください。

3. 空いた元のパスに、同じ名前で内容の異なる別ファイルを新規作成します。

   移動した元ファイルは削除・上書きせずに残します。

4. ショートカットを開き、パスと判別用の文字から、どちらのファイルが開いたかを記録します。

古いパスの「別ファイル」が開けば、この条件ではショートカットの解決が移動した元ファイルの選択を保証しなかったと分かります。ほかの結果になっても、環境や条件を省略して一般化しないでください。

APIでリンク先を解決する

この手順は、COMを初期化し、IShellLinkWとIPersistFileを扱うWindowsデスクトップアプリの開発者向けです。検証用の.lnkを使い、UI表示、探索時間、リンク情報の更新をどう扱うか先に決めます。具体的な初期化・解放を含む例はShell LinksのUsing Shell Linksを参照してください。

1. IPersistFile::Loadでショートカットを読み込み、戻り値を確認します。

2. 目的に合ったフラグでIShellLinkW::Resolveを呼び出し、成功を確認します。

   失敗した場合はHRESULTを記録し、解決後のパスが得られたものとして処理を続けません。IShellLinkW::Resolve

3. IShellLinkW::GetPathでパスを取得し、取得結果と対象を確認します。

   GetPathはパスの取得であって、見失ったファイルを探し直す操作ではありません。S_FALSEは空のパスが返る場合の戻り値なので、取得できたものとして扱わないでください。IShellLinkW::GetPath

解決とパス取得に成功した場合、解決後のパスを得られます。ただし、その成功を、業務上意図した元のファイルであることの証明とは扱いません。

Resolveのフラグを確認する

flowchart TB
    accTitle: ショートカットを読み込んでからリンク先を解決する
    accDescr: IPersistFileでリンクを読み込み、Resolveで解決を試みて成功を確認した後にGetPathで解決後のパスを取得します。
    L["リンクを読み込む"] --> R["Resolveで解決を試す"]
    R -->|"成功を確認"| G["GetPathでパスを得る"]

図5: 元の場所の文字列を読むだけでは、移動先を探したことにはなりません。

主な指定を示します。フラグは目的に応じて選び、「どれでも開ければ成功」としないことが大切です。正確な更新条件や組み合わせはResolveのAPIリファレンスで確認します。

確認

確認するのは、古い場所が使えなくなった後に、どの対象へたどり着いたかです。「開けたか」「正しい対象か」「内部でどの探索経路を使ったか」は別々の問いです。

試行条件と解決結果

開けない場合は、まず移動先に本体が存在し、直接開けるかを確認します。自動追跡を成立させるためにObject IDや管理ポリシーを変更するのではなく、条件と失敗結果を記録してください。実務で入口を直す場合は、正しい本体だと確認してから新しいショートカットを作り、もう一度対象を確認します。

既存のAPI検証結果

初版で公開した検証記録（JSON）には、対象環境と次の観測が残っています。これは既存記録の説明であり、この改稿でWindows上の再測定を行ったという意味ではありません。

各試行で、得られたパスの対象は存在していました。記録には、移動前後でファイルIDが一致し、コピーと差し替えファイルのIDは異なること、コピーの内容が元と同じであることも残っています。このファイルIDの観測を、追跡用Object IDを実際に使った証拠とは扱いません。

この一環境では、移動・改名後の新しいパスが得られる一方、元の場所に別ファイルを置くと古いパスが得られました。Windows 11のエクスプローラーでの動作や、Resolve内部の探索経路は、この記録からは確認できません。

制約

追跡・探索の実行条件

追跡情報が利用できること、対象へアクセスできること、必要な探索が許可されていることなどが結果に関わります。APIではフラグ、管理環境ではNoResolveTrackやNoResolveSearchのポリシーで、追跡や探索を制限できます。開けなかったことだけを、ファイルが消えた証拠やObject IDが壊れた証拠とは扱えません。ADMX_StartMenu Policy CSP

別ボリューム・別PCへの移動

同一NTFSボリュームの確認結果を、USB、別ボリューム、別PC、同期・ネットワーク環境へ一般化しないでください。別の場所まで追跡できる条件はありますが、常に見つかるわけではありません。また、ショートカットだけを渡しても、リンク先のファイル本体が一緒に渡るわけではありません。分散リンク追跡の機能と制約

識別子の有効範囲

追跡用Object IDと、ファイルハンドルから取得するファイルIDは別の項目です。ファイルIDによる比較にはボリュームの識別情報も関わり、識別子の有効範囲や再利用にも注意が必要です。どのAPIのどの識別子を、どの条件で比較するのかを確認します。GetFileInformationByHandleのRemarks

Object IDの変更

Object IDを手で書き換える必要はありません。Microsoftは、Object IDの変更・削除が分散リンク追跡などに問題を起こし得ると警告しています。fsutil objectid

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

.lnkはシェルが読み取ってリンク先を解決するファイルです。シンボリックリンクは、ファイルシステムのパス解決に関わる別の仕組みです。「リンク」という名前が共通でも、ここで説明した追跡や探索をそのまま適用することはできません。Symbolic Links

関連記事

USBの安全な取り外しと書き込みキャッシュ

参考資料

Microsoftの一次資料と、初版で公開した検証記録です。本文中の各主張の近くからも、対応する資料へリンクしています。

• Microsoft Learn, Shell Links。通常のショートカットの保存情報、リンク解決の大筋、COMを使う例。
• Microsoft Learn, IShellLinkW::Resolve。追跡と特徴による探索、各種フラグ、リンク情報の更新条件。
• Microsoft Learn, Distributed Link Tracking and Object Identifiers。Object ID、コピーとの違い、NTFSの追跡と制約。
• Microsoft Open Specifications, ShellLinkHeader。リンク先の属性・時刻・サイズの保存形式。
• Microsoft Open Specifications, TrackerDataBlock。リンク先の探索に渡す追跡用追加データ。
• Microsoft Learn, ADMX_StartMenu Policy CSP。NoResolveTrackとNoResolveSearchによる追跡・探索の制御。
• Microsoft Learn, IShellLinkW::GetPath。リンク先パスの取得と戻り値。
• Microsoft Learn, GetFileInformationByHandle。ファイルIDとボリューム識別情報による比較、および識別子の制約。
• Microsoft Learn, fsutil objectid。追跡用Object IDと出生時の識別情報、識別子の不用意な変更への警告。
• Microsoft Learn, Symbolic Links。.lnkとは異なるファイルシステムのリンク。
• ショートカットの移動追跡の検証記録（JSON）。Windows Server 2025の一環境で観測したAPIの結果。

関連する記事

同じタグを共有する最新の記事です。さらに近い話題で知識を深められます。

関連トピック

このテーマと近いトピックページです。記事を起点に、関連するサービスや他の記事へ進めます。

このテーマがつながるサービス

この記事は次のサービスページにつながります。近い入口からご覧ください。

よくある質問

この記事のテーマについて、相談時によくある質問をまとめています。

元のファイルを移動してもショートカットが開けるのはなぜですか？

通常の.lnkショートカットは、保存したパスでリンク先を見つけられない場合に、利用できる追跡情報やファイルの特徴を使って探し直せるためです。単なるパス文字列ではありません。ただし、ファイルシステムや設定、探索の条件によっては見つからないこともあります。

ショートカットはファイルの内容を比較して元のファイルを探しますか？

ここで説明するリンク解決は、パス、NTFSの追跡用識別情報、名前や作成日時などを使います。内容の一致によって元のファイルであることを証明する仕組みではありません。同じ内容をコピーしても、そのコピーは別のファイルです。

元の場所に同じ名前の別ファイルを置くと、移動した元ファイルを開きますか？

必ず元のファイルを開くとは限りません。通常のリンク解決では保存されたパスの確認が先なので、元の場所の別ファイルがリンク先として扱われる可能性があります。自動追跡を、特定のファイルを必ず選ぶ保証として使わないでください。

USBや別のPCへ移しても必ず追跡できますか？

保証されません。NTFSの追跡と特徴による探索は別の仕組みであり、移動先のファイルシステム、残っている追跡情報、サービスやポリシー、接続状態などが関わります。ショートカットだけを渡しても、リンク先のファイル本体が一緒に渡るわけではありません。

ショートカットとシンボリックリンクは同じですか？

異なります。.lnkはWindowsのシェルが読み取ってリンク先を解決するためのファイルです。シンボリックリンクはファイルシステムのパス解決に関わる別の仕組みであり、.lnkの探索動作がそのまま当てはまるわけではありません。

著者プロフィール

記事の著者プロフィールページです。

小村 豪

合同会社小村ソフト 代表

Windows ソフト開発、技術相談、不具合調査を中心に、既存資産が残る案件や原因が見えにくい障害調査に強みがあります。