Windows 11には、MS-DOS時代から続く「8.3形式」の短いファイル名が今も残っている。

たとえば長いフォルダ名とは別に、PROGRA~1のような短い名前が自動的に付けられる仕組みだ。古いソフトウェアとの互換性を保つための機能だが、Microsoftは性能上の理由から、この短縮名を新たに作らない設定も用意している。

ただし、ここで注意したいのは、「これから短縮名を作らないこと」と、「すでに存在する短縮名を削除すること」は別の操作だという点だ。

Microsoftは特に後者について、アプリが正常に動かなくなったり、アンインストールできなくなったりする可能性があると警告している。

また、8.3形式を無効にすればWindows 11全体が高速化するわけでもない。Dellが大きな性能差を確認したのは、一つのフォルダに100万件を超えるファイルを作り続けるという特殊な条件だった。

そのため、この設定を「Windows高速化テクニック」として一括りにするのではなく、どの処理に効果があり、どこに互換性のリスクがあるのかを分けて考える必要がある。

AD

「今後作らない」と「すでにある短縮名を消す」は別

Microsoftのfsutil 8dot3nameには、8.3形式の短縮名を扱う複数の操作が用意されている。

queryは現在の設定を確認するコマンドだ。

setは、今後新しく作成するファイルやフォルダに8.3形式の短縮名を付けるかどうかを変更する。

一方、stripは、すでにファイルやフォルダに付いている短縮名を削除する。

この違いが重要だ。

操作 何をするか 注意点
query 現在の8.3形式の設定を確認する 設定を変更しない
set 今後、新しい短縮名を作るかどうかを変更する 古い短縮名に依存するソフトウェアとの互換性に注意
scan 短縮名を削除した場合に影響しそうなレジストリ項目を調べる 見つかった参照先を自動で修正するわけではない
strip すでに存在する短縮名を削除する アプリの動作不良やアンインストール不能につながる可能性がある

Microsoftが特に強く警告しているのは、既存の短縮名を削除するstripだ。

ソフトウェアの中には、インストール時にPROGRA~1のような短縮パスをレジストリなどへ記録しているものがある。

その短縮名だけを後から削除すると、ソフトウェア側は存在しないパスを参照することになる。

しかもstripを実行しても、レジストリに保存された古いパスまで自動的に書き換えてくれるわけではない。

/fオプションを付ければ、こうした参照が見つかっても削除を強制できる。そのためMicrosoftは、実行前のバックアップを勧め、アプリが動作しなくなったり、アンインストールできなくなったりする可能性を明記している。

一方、setで新しい短縮名の作成を止めても、すでに存在する短縮名はそのまま残る。

つまり、

  • 今後の短縮名作成による処理を減らす
  • 過去に作られた短縮名まで削除する

の二つは、性能面でも互換性の面でも別の変更だ。

なぜWindows 11にMS-DOS時代の仕組みが残っているのか

「8.3」という名前は、昔のDOSで使われていたファイル名の制限に由来する。

ファイル名の本体を最大8文字、拡張子を最大3文字までとする形式だ。

現在のWindowsでは長いファイル名を普通に使えるが、古いソフトウェアとの互換性を保つため、長い名前とは別に短縮名を持つことがある。

たとえば、

Program Files

というフォルダに、

PROGRA~1

という短縮名が付くことがある。

これは別のフォルダが作られているわけではない。どちらの名前を使っても同じフォルダへアクセスできる。

昔のソフトウェアの中には長いファイル名を正しく扱えないものがあるため、この短縮名が互換性維持のために使われてきた。

一方、現在のソフトウェアだけを使う環境では、すべてのファイルに短縮名を作る必要がない場合もある。

そのためMicrosoftは、性能上の理由から8.3形式の短縮名作成を無効にできるようにしている。

MicrosoftのNTFSの説明によると、新しいWindowsで新規にフォーマットした一部のボリュームでは、短縮名の作成は既定で無効になっている。

ただし、Windowsが入っているシステムボリュームでは、ソフトウェアとの互換性を考慮して有効のままになる場合がある。

つまりMicrosoft自身も、「すべてのドライブで必ず必要な機能」とは考えていない一方、Windowsや既存ソフトウェアが使う場所では簡単に切れない機能として扱っている。

AD

100万件を超えるファイルで性能が大きく低下

8.3形式が性能に影響する例として、Dell Technologiesが公開している調査がある。

Dellはバックアップ製品Avamarで、100万件を超えるファイルが入ったフォルダを復元した際、何日経っても処理が終わらない問題を調査した。

公開された調査結果によると、8.3形式の短縮名が有効になっているNTFSボリュームで、ファイル作成速度が大きく低下していた。

DellはAvamarそのものの処理を切り離して原因を調べるため、一つのディレクトリへ大量の異なる名前のファイルを連続して作成する試験を行った。

8.3形式を有効にした場合と無効にした場合で、一定時間ごとの作成ファイル数を比較している。

8.3形式が有効な環境では、約130万件付近からファイル作成が著しく遅くなった。

一方、無効にした環境では、2～3時間で500万件を超えるファイルを作成できた。

Dellは、実用上の性能低下が目立ち始める目安として約110万件を挙げている。

ただし、これはNTFSそのものに「110万ファイルまで」という制限があるわけではない。

Dellも、性能低下が始まるファイル数はハードウェアや環境によって変わるとしている。

つまり、110万件や130万件はWindows共通の境界値ではなく、Dellが特定の環境で確認した目安だ。

普通のWindows操作が高速化するわけではない

この結果だけを見て、「8.3形式を無効にするとWindowsが大幅に速くなる」と考えるのは適切ではない。

Dellが測定したのは、一つのディレクトリに大量のファイルを連続して作成する処理だ。

ゲームのフレームレートやアプリの起動時間、SSDの読み書き速度、エクスプローラーで普通のフォルダを開く速度などを測った試験ではない。

そのため、一般的なWindows PCで8.3形式を無効にしても、体感できるほど高速化するとは限らない。

影響が出やすいのは、一つのフォルダへ非常に多くのファイルを作る処理だ。

8.3形式が有効な場合、Windowsは長いファイル名だけでなく、それに対応する短縮名も管理する必要がある。

ファイル数が極端に増えると、この短縮名を生成・管理する処理が追加の負荷になる。

このため、例えば次のような環境では検討する意味がある。

  • バックアップから大量のファイルを復元するボリューム
  • 大量のビルド成果物を保存する領域
  • 非常に多くの小さなデータファイルを扱うストレージ
  • 大量のログファイルを生成するシステム

ただし、Dellが実際に測定したのはAvamarの復元に関連する大量ファイル作成だ。

ビルドやログ保存でも同じ程度の効果が得られることまで、この試験が証明しているわけではない。

重要なのは、ファイルの総数だけでなく、

  • 一つのディレクトリにどれだけ集中しているか
  • どのソフトウェアがその領域を使うのか
  • そのソフトウェアが8.3形式の短縮名に依存していないか

を見ることだ。

AD

無効化するならPC全体ではなく対象を限定する

Windowsでは、8.3形式の短縮名作成について0から3までの設定が用意されている。

大まかに言えば、

  • すべてのボリュームで有効
  • すべてのボリュームで無効
  • ボリュームごとに個別設定
  • システムボリュームだけ有効

といった使い分けができる。

つまり、Windowsが入っているCドライブでは互換性を優先して短縮名を残し、大量のデータを保存する別ドライブでは短縮名を作らない、といった構成も可能だ。

これは、Microsoftが8.3形式を単純に「オンにするか、オフにするか」という機能として扱っていないことを示している。

性能上の問題が起きている特定のボリュームだけ設定を変え、互換性が必要な場所は残すという使い方ができる。

既存の短縮名まで削除したい場合は、さらに慎重な確認が必要だ。

scanを使えば、削除によって影響を受ける可能性があるレジストリ項目を探せる。

strip /tでは、実際には削除せず、どの短縮名が削除対象になるのかを確認できる。

ただし、これらを実行して問題が見つからなかったからといって、完全に安全だと保証されるわけではない。

scanが確認するのは主にレジストリ上の参照であり、アプリ内部の設定ファイルやスクリプトなど、ほかの場所で短縮パスが使われている可能性まですべて確認できるとは限らない。

そのため、8.3形式の設定変更は、一般ユーザー向けの「Windows高速化スイッチ」と考えるべきではない。

まず確認すべきなのは、PC全体がなんとなく遅いかどうかではなく、特定のディレクトリに極端な数のファイルを作っているかどうかだ。

そのうえで、その場所を使うソフトウェアが8.3形式の短縮名に依存していないことを確認し、必要ならデータ用ボリュームに限定して新しい短縮名の作成を止める。

Dellの事例が示しているのは、通常のWindows 11を高速化する裏技ではなく、100万件を超えるような大量ファイルを扱う特殊な環境では、古い互換機能が大きな処理負荷になる場合があるということだ。