ひとことで言うと
ZIP bombは圧縮率を極限まで高めた悪意のあるZIPファイルで、42.zip（45KBのZIPが解凍後42PBになる）が有名な例です。ZIPの仕様上、同じバイト列の繰り返しは極めて高効率で圧縮できるため、ゼロバイトの繰り返しなどで作られたファイルは数KBのZIPが解凍後に数GBになることがあります。
ZIP bombはウイルスではなく、解凍プログラムの挙動を悪用したDOS（サービス妨害）の一種です。悪意を持って送りつけるケースのほか、AI生成ツールのバグや不正な出力でZIPの圧縮率が異常になるケースも理論上起こりえます。受け取る側のサービスが適切な防御策を持たないと、1ファイルのアップロードでサーバーが機能停止する危険があります。
- 相手がログインなしで開ける状態か確認する
- PCとスマホで最低1回ずつ表示を確認する
- 内部情報・個人情報・不要な外部送信が残っていないか見る
- レビュー期限と修正時の差し替え方を決めておく
HTML共有で関係する場面
ギガサイト便のようにZIPをアップロードしてHTMLサイトを公開するサービスでは、アップロードされたZIPを解凍する処理が必ず必要です。この解凍処理にZIP bombの対策を施していない場合、大量のディスク書き込みが発生してサービス全体が影響を受ける可能性があります。信頼できるサービスは解凍前にZIPメタデータから非圧縮サイズを確認し、閾値を超えた場合は解凍をキャンセルする仕組みを持っています。
利用者側の視点では、AIツールが自動生成したZIPを確認せずそのままアップロードする際に注意が必要です。特にLLMがbase64エンコードされたコンテンツを繰り返し生成した場合など、結果として圧縮率が異常に高いZIPが生成されることがあります。アップロード前に`unzip -l archive.zip`でリスト表示し、合計非圧縮サイズが不自然に大きくないか確認することをお勧めします。
よくある誤解
「ZIP bombはウイルス対策ソフトが検出・ブロックしてくれる」という誤解が多くあります。確かに一部のアンチウイルスはZIP bomb検出機能を持ちますが、ネスト構造を使った高度なZIP bombはスキャンをすり抜けることがあります。サーバー側では解凍サイズの上限チェックをウイルス検査と独立して実装することが必要です。
「ZIP bombは大きなファイルを送るのと同じリスク」という認識も誤りです。通常の大きなファイルは転送帯域が制限になりますが、ZIP bombは小さな転送量（数KB〜数MB）でサーバーリソースを枯渇させられる点が異なります。アップロードサイズ制限だけでは防げず、解凍後サイズの検査が不可欠です。
安全に使うための注意点
ZIPを受け付けるサービスを開発する際は、解凍処理に必ずクォータを設けてください。Pythonの`zipfile`モジュールを使う場合は`ZipFile.open()`で読み出すバイト数を上限チェックしながら処理し、Node.jsの`yauzl`ライブラリではエントリーのサイズ検証が可能です。解凍先のディレクトリを事前にクォータ付きマウントポイントに設定する方法も有効です。
利用者としてHTML共有サービスを使う場合は、サービスの利用規約にZIPサイズ制限と解凍後サイズ制限が明記されているか確認してください。明記されていないサービスは対策が十分でない可能性があります。また、自分でZIPを作成する際はmacOSの`Archive Utility`やWindowsのエクスプローラーの「圧縮」機能など標準ツールを使えば、異常なZIPが生成されるリスクは極めて低いです。
よくある質問
42.zipを誤ってダウンロードした場合、自分のPCに害はありますか？
ダウンロードするだけでは害はありません。解凍しようとした場合に危険です。Windowsのエクスプローラーやmacのダブルクリックで開こうとすると大量のファイルが書き出されてディスクが満杯になる可能性があるため、解凍せずに削除してください。
HTML共有サービスがZIP bombかどうかをどのように判断しているのですか？
ZIPのセントラルディレクトリに記録されている各エントリーの非圧縮サイズを合算し、設定した閾値（例：100MB）を超えたら解凍を拒否します。この検査はファイルを実際に解凍する前に行えるため、処理コストをほぼゼロに抑えられます。
ZIP bombと意図せず高圧縮率になったZIPを区別できますか？
技術的には難しいケースもあります。ただし圧縮率が1000倍を超えるような値（例：1KBのZIPが1GB超）であれば意図的な細工を疑う根拠になります。HTMLサイトの用途では解凍後サイズが数十MBを超えることはまれなので、100MBを閾値にしても実運用上の影響はほぼありません。