ファイルパスが260文字を超えると保存できない。よくある相談だが、原因はWindowsに残るMAX_PATHの260文字制限だ（出典：Maximum File Path Limitation）。Win32APIが登場した当時の互換性を守るために続く仕様であり、長年アプリケーションの前提として扱われてきた。

　内部的にはプレフィックスを使えば3万2767文字までのパスも扱えるものの、アプリケーション側がlongPath対応のマニフェストを備えていなければ効果は限定的だ。Windows 10以降は、グループポリシーやレジストリ設定により長いパスの利用を有効化できるが、既定では制限が残っており、すべてのアプリが対応しているわけではない。

　Windows 11でこの仕様が続いているのは、現行アプリの多くが依然としてMAX_PATH前提で設計されているためだ。基盤となるWin32APIが同じである以上、安易な断絶はかえって混乱を招く。歴史仕様は今も互換性の柱になっている。

予約デバイス名の呪縛

　WindowsではCONやAUX、NULといった名前がファイル名として禁止されている（出典：Naming a File）。拡張子を付けても拒否されるため、初めて遭遇すると驚く。

　Win32の命名規則では、これらの名前は“デバイス”として扱われる。過去のアプリケーションがこの名前を特別な存在として前提にしている場合があるため、その挙動を壊さないように禁止名として維持されている。歴史仕様としてそのまま残っているのは、この互換性のためだ。

　Windows 11でもこの挙動は変わらない。理由は単純で、基底層のデバイス命名規則が現在もWin32と同じ構造の上にあるためだ。ファイル名衝突を避けるという役割は今も必要とされている。

WinSxSフォルダ肥大化

　WinSxSフォルダの容量が大きい、という相談は情シスの定番だろう。WinSxSフォルダは、実際にはWindowsのコンポーネントストアであり、更新に必要な複数バージョンのファイルを保持する役割を担う（出典：WinSxS folder）。ロールバックや安全な更新手順の確保が目的であるため、簡単に削除できない。

　このフォルダの見かけ上のサイズが大きく見えるのは、実体がNTFSのハードリンク構造を利用しているからだ。実際のディスク使用量より大きく表示されることがあり、“巨大化しているように見える”現象が起きやすい。

　Windows 11でもWinSxSはそのまま採用されている。理由は、コンポーネントベースのメンテナンス方式（CBM）がWindows Updateの根幹を支えているからだ。スリム化よりも安全性と確実な復旧を優先した設計が受け継がれている。

　なお、WindowsのDISMツールなどを使えば、不要なコンポーネントを分析・削除するクリーンアップも可能だ。

DLL地獄の名残

　かつてWindowsユーザーを悩ませたDLL Hell（DLL地獄）。異なるアプリが同名のDLLを上書きし、動作しなくなる問題が相次いだ。これを根本的に解消するために導入されたのがSide-by-Side Assembly（SxS）であり、アプリごとに必要なDLLを見分けて読み込む仕組みだ（出典：Side-by-side assemblies）。

　この仕組みによりDLL Hellは大幅に軽減されたが、アプリのマニフェストやSxS構造を確認しないと原因を特定しづらい場面がある。情シス業務では“特定アプリだけ起動しない”といった相談が多く、この仕組みが関係していることも少なくない。

　Windows 11でもSxSは維持されている。Win32アプリの互換性を確保する必要性は変わらず、SxSを廃止すれば再びDLL Hellを招きかねない。内部構造は改善されているものの、設計思想はNT時代から連続している。

Windows Updateが“勝手に”再起動

　ユーザーが作業中に突然再起動が発生する。もっとも不満が集まりやすい挙動だ。Windowsは更新適用のためにActive Hours（使用時間帯）を参照し、その外側で再起動を試みる（出典：Active Hours）。

　既定では利用パターンに基づく自動推定が働くが、この推定がユーザーの感覚と合わないと“勝手に再起動された”と感じる。情シスではグループポリシーなどで明示的に再起動を制御することが可能だ。

　Windows 11でもActive Hoursの仕組み自体は継続している。再起動の通知やタイミングに改善は見られるが、公式には詳細が明示されておらず、再起動を避けられない構造は変わっていない。安全性と利用者体験のバランスをとる現在進行形の仕様といえる。

FILETIME、1601年起点という深い設計理由

　Windowsの内部時刻はFILETIME構造体で管理される。1601年1月1日を起点とし、100ナノ秒単位で増加する整数値だ（出典：File Times）。UNIXの1970年起点とは異なるが、NTFSの時刻管理と整合性をとるための合理的な設計だ。

　FILETIMEを知ると、ログの微妙な時刻差やアプリケーション間のズレの理由が理解しやすくなる。日常業務で直接触れることは少ないが、情シスが内部時計の精度を把握するうえで有用だ。

　Windows 11でもFILETIMEは変更されていない。NTFSとWin32APIをまたぐ設計全体がこの方式に依存しており、時刻表現を変更すると互換性に甚大な影響が出るためだ。内部が進化しても、時間の刻み方だけは変わらない。

　Windowsの“クセ強仕様”は見方を変えればOSの歴史そのものだ。慣れない挙動に見えても、それぞれが互換性、安全性、制御性のために残されている。Windows 11では改善された部分もあるが、基盤を支える仕様は意図的に継承されている。背景を押さえておくと、日常の“なぜこうなるのか”が理解でき、情シスの業務にも余裕が生まれる。