画像圧縮ツール

オンライン画像圧縮は、画像ファイルのサイズを小さくし、ページ表示を速くしたり、アップロード制限に収めたり、共有時の通信量を減らしたりするためのツールです。ファイルは ToolAct の変換サービスにアップロードされ、サーバー側のライブラリ（libvips / mozjpeg / libwebp）でデコードと再エンコードが行われ、圧縮結果がブラウザに返送されます。変換完了後、元のファイルは直ちにサーバーから削除され、アーカイブされず、トレーニングにも使用されません。形式によっては画質、メタデータ、色の情報、エンコード設定を調整し、通常の表示サイズでは大きな劣化が目立たない範囲で容量を下げられます。ブログ画像、商品写真、SNS 投稿、サポート添付、下書き素材に向いています。一方で、印刷用、保存用、細部確認が必要な画像では、圧縮後の質感や文字のにじみを必ず確認する必要があります。個人情報を含む写真、社内資料、その他機密性のある画像はアップロードしないでください。

画像圧縮は非可逆と可逆の境界に沿って明確に分かれます。非可逆フォーマット（JPEG、WebP 非可逆）は人間の知覚限界を活用します。目は高周波の色差成分（クロマ）よりも輝度（ルーマ）に対する感度がはるかに高いため、エンコーダーは 8x8 または 16x16 ブロックの微細な色情報を大多数の視認者に気づかれることなく削除します。JPEG は 1992 年からこの DCT ベースの方式を採用しており、近代的な代替フォーマットとして mozjpeg（同一 SSIM で libjpeg より約 5-10% 小さい、エンコードは遅い）、libwebp（Google の VP8/VP8L 画像コーデック、2010 年）、AVIF（Alliance for Open Media、AV1 イントラ、2019 年）があります。可逆フォーマット（PNG、GIF、WebP 可逆）はエントロピーコーディング（LZ77 スライドウィンドウ辞書 + Huffman または算術コーディング）によりバイトを縮小し、ピクセルを一切変更しません。 本ツールのパイプラインは完全にサーバー側で実行されます。ブラウザは各画像を署名付きマルチパートアップロードとして ToolAct の圧縮エンドポイント（/image/compress）に送信します。サーバーはリクエストを検証し、バイト列を libvips（高性能・低メモリの画像処理ライブラリ。ストリーミングかつオンデマンドのパイプライン）に渡します。libvips はソースをデコードし、必要に応じて長辺をリサイズして出力寸法を制限し、JPEG であれば mozjpeg、WebP であれば libwebp、PNG であれば libpng/oxipng で再エンコードします。エンコードされたバイト列はダウンロードレスポンスとしてそのままブラウザに返送され、一時アップロードファイルはレスポンス書き出し直後にディスクから削除されます。アーカイブはなく、トレーニングパイプラインへの投入もなく、内容を人が確認することもありません。 JPEG の量子化がフォーマットの核心です。品質 90 ではほぼすべての DCT 係数を保持し、75 では中周波数の係数が削除され始め（黄色地の赤いテキストで視認可能）、50 ではグラデーションにブロック歪みが現れる典型的な JPEG となり、25 では顔写真にポスタリゼーションが発生します。PNG 圧縮は zlib（DEFLATE）レベル 0〜9 に基づき、レベル 1 は高速ですがファイルサイズが大きく、レベル 9 はフラットカラーのバナーで最後のバイトまで絞り出しますが CPU コストが増大します。EXIF、ICC プロファイル、XMP、IPTC メタデータは再エンコード時にデフォルトで削除されます。エンコーダーがファイルヘッダーをゼロから再構築するため、200 KB のカメラ写真が同じ解像度で 60 KB のアップロードになる理由はここにあり、画像の出典やカラーマネジメントのメタデータが重要な場合は別途保持する必要があります。

• libvips（John Cupitt、LGPL）はサーバー側の画像処理エンジンです。ストリーミングかつオンデマンドのパイプラインで、1 億ピクセル入力でも低メモリ使用を維持でき、Sharp、ImageMagick の IM7 vips 委譲、本ツール背後の変換エンドポイントを支えています。
• mozjpeg（Mozilla、libjpeg-turbo のフォーク、より優れた心理視覚モデルを搭載）は同一 SSIM で標準の libjpeg より 5-10% 小さいファイルを生成しますが、エンコード速度は約 3〜5 倍遅くなります。2017 年以降の JPEG 品質 80-85 の Web デフォルト設定の背景にはこのトレードオフがあります。
• PNG は LZ77 + Huffman 方式です。エンコーダーは最大 32 KB 前方の繰り返しバイトシーケンスを検出し（スライドウィンドウ）、（距離、長さ）ペアを出力し、Huffman コード化します。WebP 可逆（VP8L）は同様の方式にローカルパレットパッチを加え、同一 RGBA ピクセルで通常 PNG より 20-26% 小さいサイズを実現します。
• libwebp は Google の WebP 参考エンコーダー/デコーダーです。サーバー側ではこれを使用して非可逆 VP8（品質 0〜100、デフォルトで 4:2:0 クロマ）または可逆 VP8L（品質パラメータは圧縮の効率を制御し、ピクセル忠実度には影響しない）のいずれかで書き出します。WebP デコードは広く利用可能（Chrome 32+ 2014 年、Firefox 65+ 2019 年、Safari 14+ 2020 年）で、変換された WebP はほぼすべての近代ブラウザで安全に表示できます。
• JPEG のデフォルト 4:2:0 クロマサブサンプリング（4 ルーマサンプルあたり 2 クロマサンプル）により、品質 60 で黄色背景の赤いテキストがぼやけて見えるのは、クロマの詳細がルーマの詳細より先に削除されるためです。テキストのエッジが重要なスクリーンショットや UI キャプチャでは 4:4:4（サブサンプリングなし）に切り替えてください。
• EXIF（交換可能画像ファイルフォーマット、JEITA CP-3451）と ICC カラープロファイルは再エンコード時にデフォルトで削除されます。6.3 MB の iPhone JPEG がサーバーで処理されると 1.8 MB になることがあり、これが消費者向けカメラマンが Web ツールを経由するたびにファイルサイズが減少する理由です。 実際のバッチ処理での落とし穴：フォルダに小さなアイコン（200x200 px 未満、アルファ付き PNG）、フラットカラーの UI スクリーンショット（PNG、非常に高い圧縮性）、スマートフォン写真（JPEG、主にノイズに似たコンテンツ）が混在する場合、単一の品質スライダーではすべてに適切ではありません。アイコンは可逆 PNG または WebP 可逆が適し、スクリーンショットは品質 85-90 の 4:4:4 JPEG が適し、写真は品質 75-80 の非可逆 WebP が適します。品質 60 で一括圧縮するとバイト節約にはなりますが、アイコンに赤いフリンジ、スクリーンショットにリンギングアーティファクト、写真にバンディングが発生します。よりスマートなパイプラインはカテゴリごとに異なるエンコーダーパスを使用するため、API はユーザーがデフォルトを 1 つ選択してもファイルごとにターゲット形式を上書きできるようになっています。 将来に向けて、JPEG XL（ISO/IEC 18181、2022 年）は Google と Cloudflare が 2020 年から JPEG の後継として推進してきたフォーマットです。同等品質で約 20% 小さい、完全な可逆モード、クロマサブサンプリングなし、低速ネットワーク向けのプログレッシブデコードを備えています。ブラウザサポートは部分的（Chrome は 110 で JPEG XL を無効化）であり、現時点での実用的な移行パスは品質 80 の WebP、追加バイト節約が必要なヒーローアセットには AVIF、旧 Safari や古いメールクライアント向けに JPEG フォールバックを維持することです。本ページでは品質、最大寸法、ターゲット形式の 3 つの主要パラメータを公開しており、それ以外は実装の詳細です。
• サーバー側変換ライフサイクル：各アップロードファイルは libvips のデコード + 再エンコードを実行し結果をストリーム返送する間だけ保持されます。一時ファイルは変換の成功・失敗にかかわらず、レスポンス終了時に削除されます。本来ブラウザのメインスレッドを 200〜500 ミリ秒ブロックしていた 24 MP JPEG の処理が、ユーザーの端末を完全に離れて行われます。
• 移行パス：AVIF は次世代のターゲットフォーマット（Alliance for Open Media、AV1 イントラ、10/12 ビット、アルファ、アニメーション対応）です。サーバー側で libavif/aom により AVIF をエンコードしても、速度は WebP の 10〜30 倍遅いままなので、ほとんどのページは品質 80 の WebP を採用し、追加 15-20% のバイト節約が得られるヒーロー写真に AVIF を活用しています。