ファイル名でシステム連携が失敗する原因｜WindowsとLinuxの違い

開発環境では問題なく動いていたのに、サーバーに上げた途端に動かなくなる。よくある報告です。

• Webサイトの画像だけが表示されない（404エラー）
• Windowsで作ったZIPをサーバーで展開したら、一部のファイルが消えている
• フォルダをコピーしようとしたら「パスが長すぎます」と言われた
• ダウンロードしたファイル名が「%E8%AB%8B%E6%B1%82%E6%9B%B8.pdf」になっていた

これらはすべて、WindowsとLinuxでファイル名のルールが違うことから起きています。

ファイル名に、OSごとのルールがあるとは。

普段は意識しませんが、開発をWindows、本番をLinuxで行う構成では、この境界を毎日またぐことになります。同じ境界で起きる問題としては改行コードの違いも有名ですが、ファイル名にはさらに多くのルール差があります。順に整理します。

違い①：大文字小文字の区別

最も事故が多いのがこれです。次の2つのファイルは、同じものでしょうか。

Report.pdf
report.pdf

答えはOSによって変わります。

OS	判定
Windows	同じファイル（区別しない）
Linux	別のファイル（区別する）

マイクロソフトの公式資料でも、Windowsのファイルシステムは大文字小文字を区別しないと明記されており、例として「D:\」と「d:\」は同じボリュームを指すと説明されています。

なぜ本番環境だけ404になるのか

この違いが最もよく表面化するのが、Webサイトの公開時です。

HTMLの記述  : <img src="images/Logo.png">
実際のファイル: images/logo.png

手元のWindowsでは大文字小文字を区別しないため、これでも画像は表示されます。ところがLinuxサーバーに置くと、Logo.pngというファイルは存在しないと判断され、404エラーになります。

「自分のPCでは見えているのに、公開したら画像が出ない」——多くはこれが原因です。

ファイル名の綴りは合っているため、目視では気づきにくいのが厄介な点です。

違い②：使える文字の範囲

ファイル名に使えない文字も、両者で大きく異なります。

Linux系OSの仕様を定めるPOSIXでは、ファイル名がこう定義されています。

名前を構成するバイトに、NULおよびスラッシュ文字を含んではならない

つまりLinuxで使えないのは、実質スラッシュだけです。スラッシュは階層の区切りに使われるため、名前には使えません。

一方Windowsでは、使えない文字がはるかに多くなっています。

OS	使えない文字
Linux	/ のみ（＋NUL）
Windows	< > : " / \ | ? * ＋制御文字（＋NUL）

実務で引っかかりやすいのはコロンです。「見積書:2026年度.pdf」のような名前はWindowsでは作成できません。時刻を含むファイル名（backup_12:30.logなど）を自動生成する処理を、Linuxで作ってWindowsに移植すると失敗します。

違い③：Windowsには使えない「名前」がある

文字だけでなく、特定の単語そのものがWindowsでは使えません。マイクロソフトの資料には、予約された名前が列挙されています。

CON, PRN, AUX, NUL,
COM1〜COM9, LPT1〜LPT9

これらはMS-DOS時代に、プリンタや通信ポートといった装置を指す名前として使われていたものです。当時の互換性を保つため、現在も予約され続けています。

拡張子を付けても回避できない

ここが盲点です。同資料は次のように注意しています。

これらの名前の直後に拡張子を付けたものも避けること。たとえば NUL.txt と NUL.tar.gz はどちらも NUL と等価である

「NUL」がだめでも「NUL.txt」なら大丈夫、とはなりません。拡張子の有無にかかわらず使えません。

さらに細かい話として、上付き文字の「COM¹」「LPT²」といった表記まで予約対象になっており、資料には echo test > COM¹ がファイル作成に失敗する例が挙げられています。

実務では、伝票番号や製品コードを自動でファイル名にする処理が該当します。「CON」「AUX」「PRN」で始まるコード体系を使っている場合は要注意です。Linuxでは問題なく作れるため、移行時に初めて発覚することがあります。

違い④：末尾のスペースとピリオド

見た目では判別できない違いもあります。マイクロソフトの資料はこう述べています。

ファイル名やディレクトリ名をスペースまたはピリオドで終わらせないこと。基盤となるファイルシステムがそうした名前をサポートしていても、Windowsのシェルやユーザーインターフェイスは対応していない

「報告書.」や「資料 」（末尾に空白）といった名前は、Linuxでは作成できてもWindowsでは扱えません。ファイル転送の際に名前が変わったり、コピーに失敗したりします。

一方で先頭のピリオドは問題ありません。同資料も、名前の最初の文字としてピリオドを指定することは許容されると明記しています。.gitignoreのような設定ファイルが使えるのはこのためです。

違い⑤：パスの長さ制限

Windowsには、パス全体の長さにも制限があります。

Windows 10 version 1607より前のエディションでは、パスの最大長はMAX_PATH、すなわち260文字と定義されている

それ以降のバージョンでは、レジストリの変更またはグループポリシーの設定によって制限を解除できます。ただし既定では有効なままのため、実務では依然として遭遇します。

この260文字はドライブ名からファイル名までの合計です。日本語のフォルダ名は1文字が1文字分として数えられますが、階層が深くなると意外に早く上限へ近づきます。

C:\Users\yamada\Documents\プロジェクト\2026年度\第1四半期\報告書\
→ ここまでで50文字を消費

共有フォルダやクラウド同期フォルダでは、さらに階層が深くなりがちです。「特定のフォルダだけコピーできない」という症状が出たら、パスの長さを疑ってください。

日本語ファイル名とURL

最後に、冒頭で挙げた「%E8%AB%8B…」の正体です。

URLには使える文字の範囲が決まっており、日本語はそのままでは含められません。そこで用いられるのがパーセントエンコーディングです。RFC 3986はこの仕組みをこう定義しています。

パーセントエンコードされたオクテットは、パーセント文字「%」に続く2桁の16進数という3文字の組で表現される

「請求書.pdf」をこの方式で変換すると、次のようになります。

請求書.pdf  →  %E8%AB%8B%E6%B1%82%E6%9B%B8.pdf

ブラウザは通常これを元に戻して表示しますが、変換が正しく行われないと、そのままの文字列がファイル名になります。半角スペースが%20に変わるのも同じ仕組みです。

ファイル名の文字コードが送信側と受信側で食い違えば、文字化けも発生します。日本語ファイル名は、システム間の受け渡しでは事故要因になりやすい要素です。

実務での指針

システム間でファイルをやり取りする場合、次のルールで設計すると事故を防げます。

• 半角英数字・ハイフン・アンダースコアのみを使う。すべてのOSで安全に扱えます
• すべて小文字に統一する。大文字小文字の混在が事故の元になるため、どちらかに寄せます
• スペースを使わない。URLでは%20に変換され、コマンド操作でも扱いにくくなります
• 日付は20260818や2026-08-18の形式にする。スラッシュやコロンは使えないうえ、この並びなら名前順に並べるだけで日付順になります（日時の表記ルール）
• 階層を深くしすぎない。パス長の上限に余裕を持たせます

連携用のファイル名は「人が読むための名前」ではなく「機械が確実に処理できる名前」として設計するのが基本です。人向けの情報はファイルの中身や管理台帳に持たせます。

よくある質問

Q. macOSはどちらの仕様ですか？

macOSはLinuxと同じUnix系ですが、既定のファイルシステムでは大文字小文字を区別しない設定になっています。Windows寄りの挙動と考えてください。そのため、macOSで開発してLinuxサーバーに公開する場合も、同じ404の問題が起こりえます。

Q. なぜWindowsだけ制約が多いのですか？

MS-DOS時代からの互換性を維持しているためです。予約名はその代表例で、40年以上前の装置名が現在も影響を残しています。

Q. 日本語のファイル名は使わないほうがよいですか？

社内で完結する文書なら問題ありません。ただしシステム間の自動連携やWeb公開で使うファイルは、英数字にすべきです。文字コードとURLエンコードの二重の問題を避けられます。

Q. パスが長すぎてコピーできないときの対処法は？

フォルダ階層を浅い場所に移動してからコピーするのが確実です。Windows 10以降であれば、グループポリシーで制限を解除する方法もあります。

Q. ZIPを展開したらファイルが消えるのはなぜですか？

Linuxで作成された「使えない名前」のファイルが含まれている場合、Windows側で展開に失敗することがあります。大文字小文字だけが違う同名ファイルが同梱されていた場合も、片方が上書きされて消えます。

参考にした主な調査・資料

• Naming Files, Paths, and Namespaces（Microsoft）— Windowsで使用できない文字、予約名、末尾文字の制約、MAX_PATHの規定
• The Open Group Base Specifications: Definitions（The Open Group / IEEE）— POSIXにおけるファイル名・パス名の定義
• RFC 3986: Uniform Resource Identifier (URI): Generic Syntax（IETF）— パーセントエンコーディングの仕様

まとめ

ファイル名の違いは、環境をまたいだときだけ表面化します。

• Windowsは大文字小文字を区別せず、Linuxは区別する。本番環境だけ404になる典型的な原因
• Linuxで使えない文字はスラッシュのみ。Windowsは9種類＋制御文字
• WindowsにはCON・PRN・NULなどの予約名がある。拡張子を付けても回避できない
• 末尾のスペースとピリオドはWindowsで扱えない。先頭のピリオドは可
• パスは260文字が既定の上限
• 日本語ファイル名はURL上でパーセントエンコードされる
• 連携用ファイルは小文字の英数字・ハイフン・アンダースコアで統一する

「手元では動くのにサーバーでは動かない」と感じたとき、真っ先に確認すべきはファイル名の綴りです。