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

「下書き」フォルダーに置いた企画書へ、デスクトップから開くためのショートカットを作った。その後、企画書を「提出用」フォルダーへ移した。

ショートカットは作り直していません。それなのに、ダブルクリックすると移動後の企画書が開くことがあります。

元の場所にないファイルを、なぜ見つけられるのでしょうか。

ショートカットが覚えているのは、場所だけではありません。見つからなくなった相手を探し直すための情報も持てるのです。この記事では、普通のファイルを指す.lnkを題材に、その探し方を追います。¹

1. まず、前の場所を見に行く

企画書をC:\Work\下書き\企画書.txtから、同じNTFSボリューム内のC:\Work\提出用\企画書.txtへ移したとします。

ファイルは一つのままで、置き場所だけが変わりました。しかし、ショートカットに保存されていたパスは、まだ「下書き」を指しています。

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

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

Windowsのシェルも、まず保存された場所にリンク先があるかを確認します。ただし、見つからなかったところで直ちに諦めるとは限りません。利用できる情報を使って探し直す処理が続きます。これをリンクの解決と呼びます。²

.lnkのファイル形式には、リンク先の場所を表す情報だけでなく、作成日時やサイズなどを記録する欄もあります。さらに、追跡用の情報を持つ追加データも定義されています。プロパティの「リンク先」に表示される一行が、ショートカットの持つ情報のすべてではないのです。³⁴

では、名前まで変わっていたら、何を頼りに探すのでしょうか。

2. 名前が変わっても残る「名札」を使う

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

このような場面で使えるのが、場所や名前とは別の識別情報です。

Windowsの分散リンク追跡という仕組みは、NTFS上のファイルやフォルダーに付けるObject IDを利用します。Object IDは必須の属性ではなく、追跡対象を識別するための名札に相当します。そのボリューム内のObject IDを引くための索引も用意されています。⁵

たとえば、企画書に「名札K」が付いていた、と考えてみます。Kは説明用の記号であり、実際のIDの形式ではありません。

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

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

利用できる追跡情報があれば、古い名前を全フォルダーから探し回るだけでなく、識別情報から移動後の相手を探せます。.lnkのTrackerDataBlockには、この追跡サービスへ渡す情報を保存できます。⁴

住所が変わったから別人になるわけではない。それと同じように、ファイルのパスが変わっても、同じファイルを追うための手がかりは残せる。 移動後も開ける理由の一つは、ここにあります。

ただし、すべてのショートカットが、この方法で解決されるわけではありません。名札を使えなければ、別の探し方へ進みます。

3. 識別情報で見つからなければ、特徴から探す

元の企画書と同じ作成日時で、同じような属性を持つファイルが、近くのフォルダーにあったらどうでしょうか。「名前を変えた元のファイルかもしれない」という候補になります。

シェルには、こうした特徴を使う探索もあります。公式の説明では、追跡サービスを利用できない、または追跡で見つからない場合、元のフォルダーやその近辺などから、名前・作成日時などが合う候補を探します。²

ここまでの筋をまとめると、次のようになります。

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

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

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

また、探索は無条件にどこまでも続くわけではありません。アプリが追跡や探索を抑制するフラグを指定したり、管理ポリシーでそれらを制限したりできます。開けたという結果だけでは、どの手がかりが役立ったかまでは分かりません。⁶

4. 同じ内容のコピーは、同じファイルか？

提出用の提案書.txtを、今度は「配布用」へコピーします。内容は同じですが、ファイルは二つになりました。一方だけを編集すれば、もう一方の内容はそのままです。

Object IDも、通常のコピーでそのまま複製されるわけではありません。同じボリュームに同じIDのファイルが二つあると、名札で相手を区別できなくなるからです。コピーには元と同じObject IDを引き継がない、とMicrosoftは説明しています。⁵

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

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

ここで、もう一つ意外な場面を考えます。元の企画書を提出用へ移したあと、空いた下書き\企画書.txtに、同じ名前の別ファイルを置いたらどうなるでしょうか。

1章のとおり、通常は保存された場所の確認が先です。そこに対象が見つかれば、移動先を探す段階へ進まないことがあります。つまり、追跡機能があっても、必ず移動した元ファイルを選ぶという保証にはなりません。¹

ショートカットは「いま開けるリンク先を見つける」ための便利な入口です。「以前と同じファイルであることを毎回証明する」ための仕組みではない。この違いを押さえると、便利さと限界がつながります。

5. 自分のPCで、同じファイルを追ってみる

試す場合は、仕事の資料ではなく、ローカルの検証用フォルダーに作ったテキストファイルを使います。まずはNTFSの同じボリューム内に「下書き」「提出用」を作り、同期フォルダーやネットワーク共有は避けると条件を絞れます。

「下書き」にファイルを作ってショートカットを作成し、そこから開けることを確認します。次にファイル本体だけを「提出用」へ移し、ショートカットを開きます。さらに本体の名前を変えて、もう一度試します。毎回、どのファイルが開いたかを確認してください。

ここで見るのは、古い場所が使えなくなったあとに、新しい場所へたどり着けるかです。 開けなかった場合も、記事と矛盾するわけではありません。NTFSの追跡が利用できる条件、残っている情報、設定などで結果が変わります。USBや別のPCへの移動まで同じ結果を期待しないでください。⁵⁶

執筆時には、Windows Server 2025（ビルド26100）のローカルNTFS上でも、IShellLinkW::Resolveを使って確かめました。移動と改名の後は新しいパスが得られ、元の場所に別ファイルを置いた別の試行では、古いパスが得られました。これは一環境でのAPIの観察で、Windows 11のエクスプローラー画面での試験や、内部でどの探索経路を使ったかの検証ではありません。検証記録も残しています。

元の場所へ別ファイルを置く比較をするなら、別の検証用ファイルで最初からやり直します。一度解決したショートカットはリンク情報が更新され得るため、同じショートカットを使い回すと、もう古い場所を指していない場合があるからです。²

6. 開発者向け：パスを読む処理と、探し直す処理

アプリから.lnkを扱う場合も、保存された情報を読むことと、見失った相手を探すことを分けます。IShellLinkのGetPathでパスを取得することと、Resolveでリンク先の解決を試みることは、同じ操作ではありません。⁷

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

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

自動処理では、見つからないときのUI、探索時間、追跡の利用、リンク情報を更新するかも設計対象です。たとえばSLR_NOSEARCHは特徴による探索を、SLR_NOTRACKは分散リンク追跡の利用を抑えます。フラグは目的に応じて選び、単に「どれでも開ければ成功」としないことが大切です。²

なお、追跡用のObject IDと、ファイルハンドルから取得するファイルIDは、同じ項目ではありません。ファイルIDの比較にはボリュームも関わります。IDという単語だけで混ぜず、どのAPIのどの識別子かを確認します。Object IDを手で書き換える必要はありません。⁸⁹

また、ここで扱った.lnkはシェルのファイルです。ファイルシステムのパス解決で働くシンボリックリンクとは異なり、その探索の説明をそのまま置き換えることはできません。¹⁰

ショートカットが覚えているのは「前の住所」だけではありません。 場所で見つからなければ追跡情報を使い、それも使えなければ特徴から探す。だから移動や改名に追従できることがあります。そして、同じ内容のコピーや、元の場所に置かれた別ファイルまで含めて、必ず元の相手を選べるわけではありません。

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

関連記事

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

参考リンク

関連する記事

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

関連トピック

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

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

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

よくある質問

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

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

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

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

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

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

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

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

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

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

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

著者プロフィール

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

小村 豪

合同会社小村ソフト 代表

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