本記事はマイクロソフト社員によって公開されております。
こんにちは、Windows サポートの丸山です。
エクスプローラーで ZIP ファイルを展開しようとすると「圧縮 (zip 形式) フォルダーは無効です」というエラーが表示されることがあります。本記事では、この事象の原因と回避策を解説します。
■ 事象
エクスプローラーで ZIP ファイルを開く、または展開しようとすると、以下のエラーが表示されます。
フォルダーを開くことができません。圧縮 (zip 形式) フォルダー ‘C:\Users\xxx\フォルダー.zip’ は無効です。
ZIP ファイル自体は破損しておらず、PowerShell の Expand-Archive コマンドレットや 7-Zip では正常に展開できます。
■ 原因
エクスプローラーの ZIP 展開機能 (zipfldr.dll) は、ZIP ファイル内の各エントリのファイル名の バイト長 を検査しています。このバイト長が 260 以上 (MAX_PATH) の場合、ZIP ファイル全体を「無効」と判定してエラーを返します。
注意すべきポイントは以下の 3 点です。
判定基準は「文字数」ではなく「バイト長」
ZIP ヘッダの File Name フィールドに格納された生のバイト数が基準です。UTF-8 エンコードの ZIP であれば UTF-8 バイト長、Shift_JIS エンコードの ZIP であれば Shift_JIS バイト長が判定対象となります。ZIP 内の相対パス (エントリ名) のみが対象
展開先フォルダーの絶対パス (C:\Users\xxx...) ではなく、ZIP ファイル内部に記録されたエントリのパスのみで判定されます。LongPathsEnabled レジストリは効果なし
zipfldr.dll は Long Path API を使用していないため、LongPathsEnabledレジストリを有効にしても、この制限は緩和されません。
日本語文字は UTF-8 で 1 文字あたり 3 バイト を消費するため (ASCII は 1 バイト)、日本語を多用するファイル名は少ない文字数で 260 バイトに到達します。目安として、日本語のみのパスでは約 86 文字が上限です。
■ 回避策
この事象は zipfldr.dll の実装上の制約であり、ZIP ファイル自体の破損ではありません。以下のいずれかの方法で回避できます。
方法 1: PowerShell の Expand-Archive コマンドレットで展開する (推奨)
.NET の System.IO.Compression を使用した展開機能であり、zipfldr.dll の制限を受けません。
1 | Expand-Archive -Path "C:\Users\xxx\ファイル.zip" -DestinationPath "C:\Users\xxx\展開先" |
Windows PowerShell 5.1 以降に標準搭載されているため、追加のインストールは不要です。
方法 2: 7-Zip 等のサードパーティ ツールで展開する
7-Zip をはじめとするサードパーティの展開ツールは、独自の実装を使用しており、zipfldr.dll の制約は受けません。
方法 3: ZIP 作成時のファイル/フォルダー名を短くする
ZIP ファイルの作成元において、ファイル名やフォルダー パスを短縮することで、260 バイトの制限を回避できます。
| パスの文字種 | 260 バイトに到達するおおよその文字数 |
|---|---|
| ASCII (英数字) のみ | 259 文字 |
| 日本語のみ | 約 86 文字 |
| 日本語 + ASCII 混在 | 日本語 1 文字 ≒ ASCII 3 文字として計算 |
⚠
LongPathsEnabledレジストリの有効化は、本事象の回避策にはなりません。 zipfldr.dll はこの設定を参照しません。
■ まとめ
| 項目 | 内容 |
|---|---|
| 影響を受けるコンポーネント | エクスプローラーの ZIP 展開機能 (zipfldr.dll) |
| 制限の基準 | ZIP エントリのファイル名フィールドのバイト長 ≥ 260 (MAX_PATH) |
| 判定基準 | 文字数ではなく、ZIP ヘッダに格納された生バイト長 |
| エンコーディング依存性 | なし (UTF-8 でも Shift_JIS でも生バイト長で判定) |
| 影響を受ける OS | Windows 11 全バージョン / Windows Server 2016 以降の全バージョン |
| LongPathsEnabled の効果 | なし |
| 推奨回避策 | PowerShell の Expand-Archive コマンドレット |
■ 検証結果
テスト 1: UTF-8 エンコード ZIP の境界値
ZIP エントリ名の UTF-8 バイト数を 258 ~ 262 で変化させた ZIP ファイルを System.IO.Compression.ZipArchive で作成し、Shell.Application COM オブジェクト (zipfldr.dll と同等) で展開を試行しました。
| UTF-8 バイト数 | 文字数 | zipfldr.dll | Expand-Archive (.NET) | tar.exe (libarchive) |
|---|---|---|---|---|
| 258 | 248 | ✅ OK | ✅ OK | ✅ OK |
| 259 | 249 | ✅ OK | ✅ OK | ✅ OK |
| 260 | 250 | ❌ FAILED | ✅ OK | ✅ OK |
| 261 | 251 | ❌ FAILED | ✅ OK | ✅ OK |
| 262 | 252 | ❌ FAILED | ✅ OK | ✅ OK |
テスト 2: OS バージョン間比較
同一テスト (UTF-8 ZIP, 259/260/261 バイト) を複数バージョンの OS で実施しました。
| OS | ビルド番号 | 259 bytes | 260 bytes | 261 bytes |
|---|---|---|---|---|
| Windows 11 version 23H2 | 22631 | ✅ OK | ❌ FAILED | ❌ FAILED |
| Windows 11 version 24H2 | 26100 | ✅ OK | ❌ FAILED | ❌ FAILED |
| Windows 11 version 25H2 | 26200 | ✅ OK | ❌ FAILED | ❌ FAILED |
| Windows Server 2016 | 14393 | ✅ OK | ❌ FAILED | ❌ FAILED |
| Windows Server 2019 | 17763 | ✅ OK | ❌ FAILED | ❌ FAILED |
| Windows Server 2022 | 20348 | ✅ OK | ❌ FAILED | ❌ FAILED |
| Windows Server 2025 | 26100 | ✅ OK | ❌ FAILED | ❌ FAILED |
調査対象の OS すべて同一のしきい値 (260)。 クライアント/サーバーを問わず、OS バージョンによる差異はありませんでした。
テスト 3: LongPathsEnabled の効果検証
| UTF-8 バイト数 | LongPathsEnabled = 0 | LongPathsEnabled = 1 |
|---|---|---|
| 259 | ✅ OK | ✅ OK |
| 260 | ❌ FAILED | ❌ FAILED (変化なし) |
※ 本情報の内容 (添付文書、リンク先などを含む) は、作成日時点でのものであり、予告なく変更される場合があります。
■ 補足: ZIP ファイルのエンコーディングと MAX_PATH の背景
ここから先は、この問題がなぜ起きるのかについての技術的な背景解説です。上記の回避策で問題が解決した場合は、読み飛ばしていただいて問題ありません。
ZIP ファイルのファイル名エンコーディングの歴史
ZIP フォーマットは、1989 年に Phil Katz 氏が開発した PKZIP によって誕生しました。当時、ZIP ファイル内のファイル名は各国の OEM コードページ (日本では Shift_JIS、米国では CP437) でエンコードされていましたが、ZIP ファイルにはどのコードページを使用したかを示す情報がありませんでした。そのため、異なる言語圏の PC で ZIP を開くとファイル名が文字化けする問題が長年続いていました。
2006 年、ZIP 仕様 (APPNOTE.TXT 6.3.0) に UTF-8 フラグ (General Purpose Bit Flag の bit 11) が追加され、ファイル名を UTF-8 でエンコードできるようになりました。現在の Windows のエクスプローラーは ZIP 作成時にこのフラグを設定するため、文字化けの問題は解消されています。
なぜ日本語ファイル名で問題が起きやすいのか
UTF-8 では日本語文字は 1 文字あたり 3 バイト を消費します (Shift_JIS では 2 バイト)。同じ文字数のファイル名でも、日本語を含むと UTF-8 換算のバイト数が大きくなり、MAX_PATH (260 バイト) の制限に到達しやすくなります。
例えば、全角の 】 (UTF-8: 3 バイト) を半角の ] (UTF-8: 1 バイト) に変えるだけで 2 バイトの差が生じ、260 の境界を越えるかどうかが逆転するケースがあります。
MAX_PATH とは
Windows API で定義されている MAX_PATH は 260 です。この値は MS-DOS 時代の内部バッファサイズに由来し、ドライブ文字 2 + パス区切り 1 + パス本体 256 + NULL 終端 1 = 260 として固定されました。Win32 API が登場した Windows NT 3.1 (1993 年) 以来、30 年以上にわたってこの値は変わっていません。
Windows 10 バージョン 1607 以降、LongPathsEnabled レジストリで一部のアプリケーションに対してこの制限を緩和できるようになりましたが、zipfldr.dll はこの仕組みに対応していません。
■ 更新履歴
- 2026-06-24 初版公開