クリエイター支援Webツール『StampCreator』を公開してから、多くのイラストレーターやAI術師の方々から「スマホだけで申請ZIPが作れて助かった」「サーバーにアップロードされないので安心」という反響をいただいています。
本記事では、StampCreatorを設計・開発するにあたり、なぜ**「完全ブラウザ完結（Zero-Server / Client-Side Only）」**という方針を徹底したのか、その技術選定と設計思想の裏側をお話しします。
1. クリエイターの最大の懸念：「未公開作品の流出リスク」
画像変換Webサービスを作る場合、Node.jsやPython（Pillow/OpenCV）を使ってバックエンドサーバーで画像を処理する構成が一般的です。しかし、この構成にはクリエイター視点で重大な心理的ハードルがあります：
「まだ世に出していない自分の作品データが、知らないサーバーにアップロードされて保存されていないか？」
特に販売前のオリジナルキャラクターや商用素材の場合、データの流出やAIの無断学習に対する不安は非常に根強いものがあります。
StampCreatorでは、この不安を根本から排除するため、**「画像処理を1ピクセルたりともサーバーに送らない」**という鉄の掟を定めました。HTML5の Canvas API と JSZip を組み合わせることで、すべての画像解析・リサイズ・余白補正・ZIP圧縮をユーザーの端末（ブラウザ内部メモリ）上だけで完結させています。
2. 開発者視点のメリット：「サーバー代・帯域コストが永続ゼロ」
クライアントサイド完結アーキテクチャには、個人開発者にとっても絶大なメリットがあります。
もしサーバーサイドで40枚もの高解像度画像をZIP化する処理を行っていれば、アクセスが集中した瞬間にサーバーのCPUとメモリが逼迫し、高額なクラウドサーバー費用やデータ転送料（Egressコスト）が発生してしまいます。
StampCreatorは静的なHTML/JSとして配布されるため：
- ホスティングは Cloudflare（帯域無制限・完全無料） のみ
- 計算負荷（CPU / RAM）はユーザーのブラウザ側が分散処理
- サーバー運用・保守・セキュリティアップデートの工数がゼロ
これにより、**「広告モデルや完全無料で永続的にサービスを提供し続けられる頑健な基盤」**が完成しました。
3. スマホのメモリ制約と戦ったフロントエンド技術
ブラウザ完結処理の唯一の難所は、スマートフォンのブラウザ（特にSafari/iOS）におけるメモリ制限です。40枚の画像を一度に Image() オブジェクトとして展開すると、メモリクラッシュでタブがリロードされる問題に直面しました。
この課題に対しては以下の工夫を行いました：
- 逐次非同期処理（Async Queue）:
全画像を並列でCanvasに描画するのではなく、1枚ずつ順次処理して即座にメモリを解放（
canvas.width = 0）。 - Blobの最適化: 処理済みデータはBase64ではなく直にバイナリBlobとしてZIPストリームに流し込み、RAM消費を最小限に抑制。
4. おわりに
個人開発でWebツールを作り、長く愛されるプロダクトにするためには、「ユーザーの安心」と「開発者の持続可能性」が完全に一致する設計を選ぶことが重要だと実感しています。今後もUNAGICHAN LABでは、この思想に基づいた実用ツールを生み出し続けていきます。