Agents8 分で読めます

Squoosh CLI・imagemin・sharp・PiPic、2026年コマンドライン画像圧縮ツール健康診断

PiPic チーム

Agents

pipic ./img -o ./out --json

{"file":"…/img/broken.jpg","status":"error",…}

✗ exit 1

ターミナルで画像を圧縮したい。人に聞いても、返ってくる答えはいつも同じ顔ぶれです。 SquooshのCLI、imagemin、sharp、こだわる人なら pngquant のような単一フォーマットのエンコーダー。ただ、こうしたおすすめの多くは2023年以前から言い伝えられてきたもの。そこで2026年8月7日の午後、全部をまっさらな状態から入れ直してみました。ごく普通の開発機、macOS、Apple Silicon、Node 22.14（現行LTS）。テストフォルダには4つのファイルを用意しました。PNGが1枚、JPEGが1枚、すでに一度最適化済みのJPEGが1枚、そして broken.jpg に改名した12バイトのプレーンテキスト。実際のプロジェクトの画像フォルダには、この手の変なものが必ず紛れ込んでいるからです。

手を動かす前に、npmレジストリのタイムスタンプを一巡り。この時点でだいぶ見えてきます。

latest release per package · npm registry · checked 2026-08-07

@squoosh/cli 0.7.3 Jan 2023 "no longer maintained" imagemin 9.0.1 Mar 2025 imagemin-cli 8.0.0 May 2024 imagemin-mozjpeg 10.0.0 Dec 2021 imagemin-webp 8.0.0 Jan 2023 sharp 0.35.3 Jul 2026 sharp-cli 5.2.0 Jun 2025

Squoosh CLIは最初の1枚に触れる前に落ちた

まず @squoosh/cli から。いちばん名前が挙がるからです。Squoosh本体はGoogle製のウェブアプリで、今もメンテナンスされていて、実際よくできています。CLIは別の話。最後のリリースは2023年1月で、readmeにはこう書いてあります。"Project no longer maintained."（このプロジェクトはもうメンテナンスされていません。）

インストールは普通に通ります。コマンドも起動します。ところが実際に圧縮させると、その場でクラッシュ。WebAssemblyを読み込むのにローカルのファイルパスへ fetch() をかける作りで、今のNodeはこれを受け付けません。

npx @squoosh/cli --oxipng '{}' -d out photo.png · Node 22.14

code: 'ERR_INVALID_URL', input: '…/@squoosh/lib/build/imagequant_node-a4aafbae.wasm' — exit 1

JPEGの経路でも試しました。同じ場所で、同じ死に方。つまり今日このツールを入れても、画像は1枚も圧縮できません。チュートリアルは今も推していて、そのチュートリアルで学習したモデルも推してきます。誰も情報を直さない。直す人が、もういないからです。

imageminは仕事をこなし、テキストファイルには嘘をついた

imageminの第一印象は悪くありませんでした。コアパッケージは2025年3月にもリリースがあり、本物の画像はきちんと処理してくれます。3ファイル投げて "3 images minified"、それで終わり。

ただ、途中で引っかかったことが2つ。ひとつはインストールです。4パッケージ入れる間に deprecated警告が5本、そして npm audit は作りたてのプロジェクトで**37件の脆弱性（うち1件はcritical）**を数え上げました。理由は簡単で、圧縮の実作業はフォーマットごとのプラグインが担っていて、そのプラグインが古いのです。JPEGプラグインの最終リリースは2021年12月、WebPは2023年1月、AVIFに至っては公式プラグインがありません。

もうひとつは、例の偽ファイル。

npx imagemin broken.jpg --plugin=mozjpeg · 12 bytes of text


Minifying images
1 image minified
— exit 0

12バイトのテキストをそのまま出力フォルダへコピーし、圧縮済み画像1枚として数え、終了コード0。人間なら一目で気づきます。スクリプトは気づけません。"1 image minified, exit 0" を読んだagentは成功と報告して、次のタスクへ進みます。

sharpには何の問題もない。そこが罠

sharp自体の状態は文句なしです。2026年7月にもリリースがあり、npmの画像処理を 10年支えてきた。メンテナンス状況の勝負なら他を寄せつけません。

でもsharpはフォルダを圧縮してくれません。ライブラリなので、スクリプトは自分で書くことになります。そこで、みんなが実際に書くようなスクリプトを書きました。数行、すべてデフォルト設定。結果はこうです。

node compress.mjs · sharp, default .jpeg() quality

photo.jpg 88556 -> 38879 smaller photo-optimized.jpg 26659 -> 32050 LARGER — exit 0

書き出したてのJPEGはきれいに縮みました。最適化済みの1枚は20%大きくなって戻ってきて、スクリプトはそれをそのまま保存しました。「大きくなったら保存しない」と書かなかったからです。sharpのバグではありません。qualityをいくつにするか、どのファイルを飛ばすか、出力が膨らんだらどうするか、結果をどう報告するか。sharpはすべて、スクリプトを書く人に委ねます。そして書くのはたいてい、夕方6時に帰りたいあなたか、あなたのagentです。agentが即興で書くのがまさにこのスクリプトだという話はコーディングagentに画像圧縮ツールを持たせように書きました。今回はその失敗を目の前で見たわけです。

こちらに不利な数字がひとつ

これは表に出しておくべき数字です。デフォルト設定では、imageminのmozjpegがこの日いちばん小さいJPEGを作りました。26,659バイト、pipicは31,774バイト。ただしデフォルトの品質設定はツールごとに違うので、バイト数だけ比べても何も決まりません。画質評価とセットで初めて意味が出ますが、それは今回やっていません。この記事が比べているのは挙動であって、圧縮率の順位付けではない。それでも、自分たちに不利な数字を隠すことはしません。

ついでに単一フォーマットのエンコーダーにも触れておきます。pngquant、oxipng、 cjpeg、cwebp、avifenc。どれも堅実で、上に挙げたツールが包んでいる中身は結局これらです。扱うフォーマットが1つだけなら、これで十分（AVIFを使うべきかどうかはAVIFページに詳しくあります）。4フォーマットとなると、インストール4回、フラグの方言4種類、そして今後あなたがメンテナンスするラッパースクリプトが1本、という計算になります。

同じフォルダをpipicに

まったく同じディレクトリを、壊れたファイルも抜かずに pipic CLI へ。

$ pipic ./img -o ./out --json          # paths shortened
{"file":"…/img/broken.jpg","status":"error","before":12,"after":0,"saved":0,"error":"UPSTREAM_ERROR: Compression service error"}
{"file":"…/img/icon.png","status":"ok","before":13897,"after":7449,"saved":6448}
{"file":"…/img/photo-optimized.jpg","status":"skipped","before":26659,"after":26659,"saved":0,"error":"not smaller — copied as-is"}
{"file":"…/img/photo.jpg","status":"ok","before":88556,"after":31774,"saved":56782}
{"file":"…/img/photo.png","status":"ok","before":302850,"after":104288,"saved":198562}
— exit 1

前のツールたちが間違えた問題を、この出力と突き合わせてみてください。テキストファイルは理由つきの error になり、実行全体は終了コード1。スクリプトは何かが失敗したとすぐ分かります。最適化済みJPEGは skipped で、元ファイルはそのまま、理由もその行に書いてある。こっそり20%太らされたりしません。残りの画像は1枚 1行のJSONで、圧縮前後のバイト数つき。スクリプトはフィールドで分岐するだけです。

対価もはっきり言っておきます。この記事の他のツールは全部あなたのマシンで動きますが、pipicはサービスです。ファイルはアップロードされ、メモリ上で圧縮され、すぐ削除されます。保存は一切なし。それでも、あなたのコンピューターの外へは出ます。CLIにはログインが必要で、月100枚まで無料、Proは月$9で5,000枚。ウェブ版圧縮ツールはこれとは無関係に、ずっと無料・無制限・登録不要です。「画像はこのマシンから出さない」がルールなら、ローカルツールを使ってください。そのルールはこの記事のどの結論よりも優先されるべきものです。

ログインと引き換えに得られるのは、ここまでの発見のちょうど裏返しです。朽ちていくwasmローダーもなく、プラグイン一式を自分で組むこともなく、qualityを即興で決めることもなく、自動化が本当に頼れる出力がある。

PNG、JPEG、WebP、AVIF を対象に、ライセンス確認済みの12入力を使った別のベンチマークも実施しました。方法、全72回の実行結果、中央値、保持した失敗、目視確認を公開しています。このデータセットは PiPic Agent CLI 1.0.6 と sharp 0.35.3 を比較します。上のフォルダ試験は運用時の挙動を調べるもので、圧縮率の順位は示しません。

この実験は自分でもできます

方法一式は午後ひとつで終わりますし、こちらの数字を信じる必要もありません。まず、プロジェクトに人がいるかを見る。

npm view @squoosh/cli time.modified

次にフォルダをひとつ作って、最適化済みの画像1枚と壊れたファイル1個を入れ、候補のツールで走らせてみてください。きれいな画像はどのツールでもきれいに縮み、差は出ません。ツールの判断力が現れるのは、きれいでないファイルに当たった瞬間です。そして、ずっときれいなままのフォルダなんて、あるでしょうか。

自分の画像で試してみる

無料、登録不要、保存も一切なし。

画像を圧縮する