なぜ作ったか
Web掲載前の画像を一括圧縮し、見た目を確認しながら容量を減らす。 NAYUTA Laboとして小さく実装し、実際の操作で成立するかを検証する。
どう作ったか
使用したAI・制作環境：Gemini / Browser JavaScript
要件を整理 → Geminiへ初期指示 → MVPを実装 → 実データで操作確認 → Error / Fixを記録 → Complete / Resultを撮影
今回の検証
端末内完結で動作する一括圧縮プロトタイプの構成
本実験では、Google Apps ScriptのWebアプリケーション機能を介して画面を配信し、実際の画像リサイズ・品質圧縮・ZIPアーカイブ生成をすべて利用者のWebブラウザ（クライアントサイドJavaScript）で実行する構成を試作しました。
ブラウザのCanvas APIを活用して指定した最大横幅への縮小と品質指定（WebPまたはJPEG）を行い、JSZipライブラリを用いてブラウザメモリ内で直接ZIPファイルを出力します。画像バイナリが外部の変換サーバーへ送信されない仕組みを最小構成で確認しています。
- HTML/Canvasによるクライアントサイドでのリサイズおよび形式変換（WebP / JPEG / 元形式維持）
- JSZipを用いたブラウザ内での一括ZIPファイル生成
- 圧縮前後のファイルサイズ比較と左右並列の画質プレビューモーダル
検証環境と現在の確認状況
本プロトタイプは検証中（IN_VERIFICATION）のステータスにあり、画面呼び出しと初期UIの表示、および基本機能の配置確認（Before/After記録）を行っている段階です。
大容量ファイルや一度に数百枚を超えるような極端な負荷条件下でのブラウザメモリ消費やクラッシュ耐性、また旧型端末における描画負荷については、今後の個別検証項目としています。
- 確認済み：初期UIの展開および基本画面構成（Before / After状態の確認）
- 未検証：大量・超高解像度画像投入時のブラウザメモリ上限および実測処理速度
- 前提条件：HTML読み込み時にCDN経由でTailwind CSSおよびJSZipのスクリプト取得が許可されているネットワーク環境
運用の注意点と前提条件
ブラウザ内部で処理が完結する設計であっても、初期表示用HTMLの読み込みや外部CDNスクリプトの取得に伴うネットワーク通信は発生します。完全なオフライン稼働や社内セキュリティルールの無条件クリアを保証するものではありません。
また、透過情報（アルファチャンネル）を含むPNG画像をJPEGに変換する際は背景が白で補正される仕様など、フォーマット特性に応じた出力の違いをプレビュー機能で確認しながら進める運用が求められます。
- CDN遮断環境ではライブラリの事前ホスティング等の構成変更が必要
- 透過PNGからJPEGへの変換時は透明部分が自動的に白色で塗りつぶされる仕様
- 端末スペックに依存するため、過度に大量のファイルを同時処理する際は分割投入を推奨
実際の操作画面
BEFORE
AFTER
