60 枚の画像、そして一度に 20 枚しか受け付けない圧縮ツール

納品用に画像を 60 枚書き出す。いつも使っている圧縮ツールを開くと、一度に 20 枚までだと 言われる。まあいい——3 回に分ければ済む。

ところがそのうち十数枚が 5 MB を超えていて、ツールはそれらをまったく受け付けない。遅い わけでも、キューに入るわけでもない。拒否だ。こうしてあなたは 12 枚を抜き出し、それ用の 別のツールを探し、フォルダを手作業で組み直すことになる。

枚数で数えるところでは、答えはどこも 20

2026 年 7 月 22 日に無料の圧縮ツールを 10 個調べた。制限値は誰かの比較記事ではなく、各 サイトから直接読み取っている。画像の枚数で上限を設けているツールの中では、同じ答えが 何度も返ってきた：

tinypng.com          20      (and max 5 MB per file)
compressjpeg.com     20
jpeg-optimizer.com   20
squoosh.app           1      no batch mode at all
jpegcompressor.com   no image cap, 250 MB per batch

Google の Squoosh はバッチ処理自体を提供していない——その FAQ は 2021 年以来ずっと、 バッチ処理を「最も要望の多い機能」と呼び続けている。

あとは算数だ。上限 20 枚に対して 60 枚なら、アップロード 3 回、待ち時間 3 回、zip ファイル 3 個、そしてダウンロードフォルダへ 3 往復して断片を組み直す作業。上限 100 枚なら、それぞれ 1 回で済む。

実際に足を止めるのは TinyPNG の 5 MB の壁

「あの圧縮サイト」と言うとき、多くの人が指しているのは TinyPNG だ。そのドロップゾーンは 条件を飾らずに書いている：Up to 20 images, max 5 MB each.

この二つの制限は、失敗の仕方が違う。バッチ上限が奪うのは時間で、時間は使えばいい。サイズ 上限が奪うのはそのファイルそのものだ。4000 ピクセルの製品写真、デザインツールから出した ばかりの PNG、ここ数年のスマートフォンで撮った写真——どれも 5 MB を超えるのは日常茶飯事で、 それらは拒否されて返ってきて、待つべきものは何も残らない。

PiPic は 8 MB を受け付ける。この数字はメモリ予算から出ている。Worker インスタンスには 128 MB が割り当てられ、同時に複数のアップロードを処理する。そして処理中の各アップロードは 受信ファイルの完全なコピーを 1 つ保持する——ストリームは一度しか読めず、リトライにはそれを 再生できる必要があるからだ。8 MB なら、1 インスタンスをおよそ 16 件のアップロードで共有 できる余裕が残る。私たちは、混雑した午後に倒れる大きな数字よりも、マシンが実際に支えられる 数字を公表するほうを選ぶ。

アップロードする前に制限を確認する

ここに書いたことを鵜呑みにする必要はないし、制限にぶつかって初めて知る羽目になるべきでも ない：

• たいていドロップゾーンにそのまま書いてある。「choose files」の下のあの灰色の一行が、 TinyPNG が 20 枚と 5 MB を置いている場所だ。
• そこになければ、サイトの FAQ で limit や how many を検索する。
• 「無料・無制限」は注意して読む。ほぼ必ず「1 日あたりの上限がない」という意味であって、 「1 回あたりの上限がない」ではない。この二つはまったく別の約束だ。
• どこにも書かれていなければ、壁にぶつかって知ることになる。調べた 10 個のうち 2 個は、 アカウントを持たない訪問者向けに制限をまったく公表していない。

PiPic の立ち位置

1 バッチ 100 枚、1 ファイル 8 MB、JPG・PNG・WebP・AVIF を入れて同じ形式で受け取り、 アカウント不要、バッチ全体を 1 つの zip で返す。60 枚のフォルダは 1 回で終わり、大きい 十数枚も他と一緒に通る。

バッチ上限は私たちが意図的に押し上げた数字だ。2 分で済む仕事を午後いっぱいの帳簿作業に 変えてしまうのが、まさにこの制限だからだ。PNG しか圧縮しないなら、PNG ページ が同じ圧縮器に形式固有の注記を付けたものになっている。

60 枚の画像、1 回のアップロード、1 つの zip。売り文句はそれで全部だ。