送信前にファイルを圧縮：サイズ削減で時間を節約

テキスト、ソースコード、ログ、 CSV 、 .bmp や .tiff のような無圧縮画像形式は送信前に圧縮しましょう。 3〜10 倍のサイズ削減が期待できます。一方、 .jpg 、 .png 、 .mp4 、 .mp3 、 .docx 、 .xlsx 、 .pdf 、 .zip ファイルは圧縮不要です。これらは内部で既に圧縮されており、二度目の圧縮は最大でも 2〜3% の削減にしかなりません。複数の小ファイルを一つのアップロードにまとめるにはストアモード（無圧縮）の .zip を使います。圧縮可能なデータで最大圧縮率を求めるなら、 LZMA2 を使った 7z が .zip より 30〜40% 優れています。 RAR は 7z と同程度ですが、受信者に WinRAR または 7-Zip のインストールが必要です。 .zip はすべての環境で標準サポートされています。

圧縮が実際に効果的な場面

テキストファイルは劇的に圧縮されます。 10 MB のサーバーログファイルは .zip で約 800 KB（12 倍）、 7z で約 550 KB（18 倍）になることがよくあります。ログにはタイムスタンプ、 IP アドレス、 HTTP ステータスコードなど高度に反復的なパターンが含まれており、圧縮アルゴリズムがこれを効率的に活用するためです。

同様に圧縮効果が高いカテゴリー。

• ソースコード： .js 、 .py 、 .java 、 .cs 、 .go — 一般的に 3〜5 倍
• CSV データ： 内容の冗長性に応じて 4〜10 倍
• JSON/XML ： フィールド名の繰り返しにより 5〜8 倍
• 無圧縮画像： .bmp（5〜10 倍）、無圧縮 .tiff（4〜8 倍）
• データベース： .sql ダンプ、空きページのある SQLite ファイル（2〜4 倍）
• PSD フラットレイヤー： 内部で RLE 圧縮されていない場合 2〜3 倍

中規模プロジェクトの Git リポジトリ tarball はしばしば 4〜5 倍に圧縮されます。これが git archive がデフォルトでツリーを .tar.gz にラップする理由です。

圧縮が無意味な場面

すでに圧縮済みの形式はそれ以上小さくなりません。基礎となるデータは既に DEFLATE 、 H.264 、 JPEG DCT 量子化、または同様のスキームを通っており、エントロピーは理論的最小値に近い状態です。

圧縮の恩恵を受けないファイル。

• .jpg 、.jpeg 、.heic ： 損失圧縮が既に適用済み
• .png ： DEFLATE 圧縮が組み込み済み
• .mp4 、.mov 、.mkv ： H.264 または H.265 圧縮が既に適用済み
• .mp3 、.aac 、.flac 、.ogg ： 音声は既に圧縮済み
• .pdf ： 内部オブジェクトストリームは通常 DEFLATE 圧縮済み
• .docx 、.xlsx 、.pptx ： 実際には XML の ZIP アーカイブで、再 ZIP は冗長
• .zip 、.7z 、.rar 、.gz 、.bz2 、.xz ： 圧縮済みアーカイブへの再圧縮は無駄
• .apk 、.jar 、.war ： ZIP ベースの Java/Android アーカイブ

これらを圧縮すると CPU を浪費し、アーカイブメタデータのオーバーヘッドでファイルがわずかに大きくなることもあります。

ZIP 対 7z 対 RAR の比較

| 形式 | 一般的な圧縮率 | 速度 | 受信者の互換性 | 暗号化 | |---|---|---|---|---| | .zip（DEFLATE） | ベースライン | 高速 | 普遍的（ Windows 、 macOS 、 Linux に組み込み） | ZIP 2.0（弱い）、 AES-256（最新ツール） | | .zip（DEFLATE64） | 5〜10% 向上 | 高速 | Windows 組み込み、 7-Zip 、一部の macOS ツール | .zip と同じ | | 7z（LZMA2） | .zip より 30〜40% 向上 | 遅い | 7-Zip 、 Keka 、 The Unarchiver が必要 | AES-256 組み込み | | .rar（RAR5） | .zip より約 25〜35% 向上 | 中程度 | WinRAR または 7-Zip が必要 | AES-256 組み込み | | .tar.gz | .zip と同程度 | 高速 | macOS 、 Linux に組み込み、 Windows では 7-Zip が必要 | ネイティブなし | | .tar.zst（Zstandard） | .zip と 7z の間 | 非常に高速 | zstd が必要（まだ普遍的ではない） | ネイティブなし |

可搬性では .zip が最も安全な選択です。圧縮率では 7z が勝ります。速度と現代的な効率性では Zstandard（.zst）が優れていますが、受信者にはサポートするツールが必要です。

まとめ用の「ストア」モード

200 枚の .jpg 写真を一回の転送で送る場合でも、受信者が「ダウンロード」を一回クリックするだけで済むよう単一のアーカイブにまとめたいものです。圧縮レベル 0（「ストア」モード）の .zip を使いましょう。アーカイブはファイルサイズの合計に数キロバイトのディレクトリオーバーヘッドが加わるだけで、作成の CPU コストはほぼゼロです。

7-Zip では：アーカイブに追加 → 圧縮レベル → 格納。 macOS Finder では：右クリック → 圧縮（デフォルトで DEFLATE 使用）。コマンドラインでは：zip -0 bundle.zip *.jpg。

圧縮時の暗号化

AES-256（レガシーの ZIP 2.0 暗号化ではない）を使用するパスワード保護 ZIP ファイルは、転送チャネルのセキュリティに頼れない場合の機密ペイロードの妥当な搬送方法です。 WinRAR 、 7-Zip 、 macOS のアーカイブユーティリティはすべて AES-256 ZIP 暗号化をサポートします。

注意点はパスワード交換です。 ZIP と同じメッセージでパスワードをメール送信しないでください。ファイルを送信した後、 Signal 、 iMessage 、または別のチャネルでパスワードを共有しましょう。より安全なのは、組み込みのパスワード保護を持つ転送サービスを使うことです。

レガシー ZIP 2.0 暗号化は暗号学的に破られており、既知平文攻撃で数秒で復元できます。アーカイブ暗号化をセキュリティに依存する場合は、必ず AES-256 を使用していることを確認しましょう。

CPU 時間と節約バイト数のトレードオフ

圧縮は時間とサイズのトレードオフです。 5 GB テキストアーカイブの最大 7z 圧縮はノートパソコンで 30 分かかり、 .zip より 2 GB 節約できるかもしれません。転送がサイズ制約を受けている場合（上限 2 GB のサービスなど）、その価値があります。転送が時間制約を受けており帯域幅が十分な場合、同じ 5 GB は光回線で 90 秒でアップロードでき、30 分の圧縮作業は節約した時間より多くの時間を費やすことになります。

経験則：CPU に対してネットワークが遅いときは圧縮する、ネットワークが速いときは気にしない。

大きなアーカイブの分割

ファイルが転送サービスの上限を超える場合、ボリュームへの分割が選択肢になります。 7-Zip と WinRAR はどちらもマルチパートアーカイブ（ .7z.001 、 .7z.002 、または .part1.rar 、 .part2.rar ）をサポートします。各パートを別々に転送でき、受信者はすべてのパートをダウンロードして展開します。

この方法は機能しますが脆弱で、一つのパートが欠けるとアーカイブ全体が使用不可になります。可能であれば、より大きな上限を持つサービスを使うほうが安全です。 SwissTransfer の 50 GB 上限は、現実的なほとんどのケースで分割の必要性を排除します。

非可逆圧縮という選択肢

目的がアーカイブ圧縮ではなく、ファイル形式の最適化である場合もあります。 200 MB の .wav 音声ファイルは 15 MB の 320 kbps .mp3 になります。非可逆ですが、カジュアルなリスニングではほぼ劣化を感じません。 60 MB の無圧縮 .tiff 写真は 5 MB の高品質 .jpg になります。 4K の .mov 動画を妥当なビットレートで H.265 に再エンコードすれば 3〜5 倍縮むことがあります。

マスターファイルには非可逆変換を避けましょう。プレビューや成果物には適切なツールです。動画・音声には FFmpeg 、動画には Handbrake 、画像には ImageMagick 、または Photoshop や Final Cut Pro のエクスポートダイアログを活用できます。

転送サービスが行う処理

ほとんどの転送サービスはある程度途中で圧縮します。 TLS 圧縮はセキュリティ上の理由で無効化されていますが、 API レイヤー上の HTTP gzip または brotli はメタデータに対して時々機能します。実際のファイルペイロードはサーバー側で圧縮されません。トラフィックのほとんどが既に圧縮済みの形式だからです。

HexaTransfer のようなゼロ知識サービスは、暗号文を受信するためサーバー側でペイロードを圧縮できません。圧縮は暗号化前にクライアント側で行う必要があります。暗号化後の暗号文はランダムに見えて非圧縮になるためです。 E2EE サービスを使用する際にサイズを削減する唯一の方法はクライアント側圧縮です。

習慣ではなく内容で判断する

よくある間違いは、反射的に「送信前に必ず ZIP」とすることです。 20 個の .pdf ドキュメントを受け取るクライアントには ZIP バンドルが便利です。しかし 800 MB の .mp4 を一つ受け取るクライアントには、 ZIP は双方の時間を浪費するだけです。選択を内容に合わせましょう。

迷ったら生のまま送りましょう。受信者は受信後にいつでも ZIP 化できます。複数のファイルをまとめる場合はストアモードの .zip を使います。内容がテキスト中心の場合は、本物の節約のため 7z を使います。

hexatransfer.comでお試しください — 無料、登録不要、最大10GB。