「パス長260文字」の正体 — それは文字数の制約ではない

「Windowsのパスは260文字までしか使えない」という説明を、一度は見たことがあるはずです。しかし公式資料を原文で確認すると、この260という数字は「パスに使える文字数の物理的な上限」ではなく、MAX_PATHという名前のWin32 API定数の値です。定数の値である以上、接頭辞の付け方やファイルシステム自体の構造によって、実際に扱える長さは何段階にも変わります。本記事は、260という数字が何を指しているのかを一次資料の原文で確認したうえで、単位の異なるLinuxの255バイト制限と並べ、数字だけを比較することの危うさを整理します。本サイトは特定のパスやファイル名の可否を判定するものではありません。

「260文字」はどこから来た数字か

出典はMicrosoft Learnの「Maximum Path Length Limitation」です。原文には次のように書かれています。

maximum length for a path is MAX_PATH

ここで重要なのは、「パスの長さには物理的に260文字という壁がある」と書かれているのではなく、MAX_PATHという名前の定数が260という値で定義されていると書かれている点です。定数である以上、この値を参照するAPIを使うか、別の値を使うAPIを使うかによって、実際に扱える長さは変わります。「260文字」という数字だけが独り歩きして、あたかもWindowsそのものの絶対的な制約であるかのように語られがちですが、原文が定義しているのは特定のAPI定数の値である、という一段階手前の事実です。

\\?\接頭辞と32,767文字、そしてNTFS自体の32,760文字

同じ資料は、パスの先頭に \\?\ という接頭辞を付けることで、拡張長パスとして最大32,767文字までAPI上で扱えるようになる、としています。一方、Microsoft LearnのFile System Functionality Comparisonのページでは、NTFS自体の構造上の上限として次の原文があります。

32,760 Unicode characters with each

この32,760という数字は、NTFSのオンディスク構造そのものの上限であり、各要素(パス中の1つのフォルダ名・ファイル名)は255文字までという条件が付きます。同じ「パスの長さ」という話題の中に、少なくとも3つの異なる層の数字が存在することになります。

260と32,767と32,760、この3つの数字はいずれも「Windowsのパス長」を語っていますが、指している対象が異なります。どれか1つだけを覚えて「Windowsのパス長は◯文字」と単純化すると、残り2つの文脈では正確性を欠くことになります。

LongPathsEnabledという設定

Windows 10 バージョン1607以降では、レジストリ値LongPathsEnabledを有効にすることで、\\?\接頭辞を付けなくても長いパスを扱えるようにする仕組みが用意されています。これも「260文字の壁を消す魔法の設定」ではなく、MAX_PATHという既定値を使わない挙動に切り替えるオプトイン設定という位置づけで理解する必要があります。すべてのアプリケーションがこの設定に対応しているとは限らない点にも注意してください。

Gitのcore.longpathsは「本家Git」の設定ではない

Windows環境でGitのチェックアウトが「Filename too long」のようなエラーで失敗したとき、git config core.longpaths trueを設定すれば直る、という説明を見かけます。しかし、本家git-scm.comが公開している公式のgit-configマニュアルを全文検索すると、core.longpathsという設定項目は0件、つまり存在しません。

この設定が実際に定義されているのは、Git for Windowsプロジェクトが独自に公開しているReleaseNotes.mdのほうです。原文には次のようにあります。

refuses to check out such files

ここでの「such files」とは、260文字の閾値を超えるパスを持つファイルを指します。つまりcore.longpathsは、本家Gitのマニュアルには存在しない、Git for Windowsプロジェクトが独自に追加・保守している拡張機能です。「Gitの設定」として広く語られているものの実体が、特定ディストリビューションの拡張であるという点は、260文字という数字がWindows API由来であることと同じ構造の混同だと言えます。

対比: Linuxの255は「バイト」であって「文字」ではない

ここまでのWindows側の数字はいずれも「文字数」でした。ところが比較対象としてよく引き合いに出されるLinuxの255という上限は、単位が異なります。POSIX.1-2017の§3.271 Pathnameには次のようにあります。

may be limited to {PATH_MAX} bytes

Linuxカーネルの公式ドキュメント(ext4のdirectory.rst)にも、ファイル名について次の原文があります。

file names cannot be longer than 255

この255の単位はバイトです。ASCII文字であれば1文字1バイトなので255文字とほぼ一致しますが、UTF-8の日本語は主に1文字3バイトを使います。この環境のpythonで実際に計算すると、次のようになります。

つまり、Linuxの「255」を「Windowsの260」と同じ感覚で「文字数の上限」として比較すると誤りです。日本語のファイル名であれば、実質的な上限は255文字ではなく85文字前後になります。260(文字)と255(バイト)という2つの数字が近いために同種の制約として語られがちですが、測っている単位そのものが違う、という点が本記事の核心です。

実務者が確認すべきこと

「260文字を超えるとエラーになる」という現象に遭遇したとき、まず確認すべきは、その260という数字がどの層の話かです。既定のWin32 API(MAX_PATH)なのか、\\?\接頭辞を使っても超える量なのか、NTFS自体の構造上の限界(32,760・各要素255文字)なのか、それともGit for Windows固有のcore.longpathsが関係する場面なのかによって、対処の仕方は変わります。またLinux側で発生する255バイトのエラーは、非ASCII文字を含むファイル名では見た目の文字数だけで判断できません。なお、OneDrive・SharePointの同期におけるパス長制限は、Windows OS自体のMAX_PATHとは別に、サービス側が独自に公開している数値(パス全体400文字など)に従います。この点を実際のファイル名でチェックしたい場合は、当サイトの姉妹ツールOneDrive/SharePointのファイル名チェッカーをご利用ください。

よくある質問

出典・関連リンク

このページを引用する場合

本記事の情報を引用・紹介いただく場合は、記事名「「パス長260文字」の正体 — それは文字数の制約ではない」と情報確認日「2026年7月26日」をあわせてお示しください。当ページへのリンクは任意です(リンクいただける場合は https://www.conbu.jp/tool/filename-limits/article-max-path.html をご利用ください)。