2026-01-27 画像サイズ制限緩和

検討結果: 画像サイズ制限緩和

日付	内容
2026-01-27	初回相談: モバイル撮影画像が5MB制限に引っかかりアップロードできない問題

ImageUploaderコンポーネントでスマートフォンのカメラ撮影画像をアップロードする際、現行の5MB制限に引っかかって実用上の問題が発生している。スマートフォンのカメラは通常5MB〜15MB程度のJPEGを生成するため、撮影した写真をそのままアップロードできないケースが多い。

画像の最終用途はClaude CLIに一時ファイルとして渡すだけであり、高解像度の元画像が必要なケースは少ない。適切な圧縮・リサイズにより、品質を大きく損なわずにサイズを削減できる。

モバイルデバイスからカメラ撮影した画像を添付して指示を送りたいユーザー

Loading diagram...

画像はBase64エンコードしてJSON本文に含めて送信している。Base64は元データの約1.33倍のサイズになるため、5枚の画像を送る場合のリクエストボディは最大で 5MB * 5枚 * 1.33 = 33.3MB に達しうる。

概要: ブラウザのCanvas APIを使い、アップロード前に画像をリサイズ・圧縮する。外部ライブラリ不要。
処理フロー: File -> Image -> Canvas (リサイズ) -> canvas.toBlob(JPEG, quality) -> Base64
リサイズ目標: 長辺2048px以下、JPEG quality 0.8程度で1〜2MB程度に収まる
メリット:
- 外部依存なし（ブラウザ標準API）
- バンドルサイズ増加ゼロ
- フロントエンドのみの変更で完結可能
- ネットワーク転送量も削減
デメリット:
- Canvas APIはEXIF情報（回転情報等）を自動処理しない場合がある（ただし最近のブラウザは対応済み）
- PNG透過画像をJPEGに変換すると透過が失われる
- GIF/WebPの変換には制約がある
- 実装がやや煩雑（リサイズロジック、非同期処理）
工数感: 小

概要: browser-image-compression ライブラリを使い、アップロード前に自動圧縮する。
処理: File -> compress(file, options) -> compressedFile -> Base64
メリット:
- EXIF回転の自動処理
- Web Worker対応（UIブロック回避）
- maxSizeMB / maxWidthOrHeight の宣言的な指定が可能
- 実装が簡潔
デメリット:
- 外部依存の追加（約40KB gzipped）
- ライブラリのメンテナンス状況への依存
工数感: 小

Loading diagram...

Loading diagram...

観点	案A: Canvas API	案B: ライブラリ	案C: 制限引上げ	案D: ハイブリッド
実装の簡潔さ	中	高	最高	中
外部依存	なし	あり	なし	なし/あり
転送量削減	あり	あり	なし	あり
画質維持	高	高	最高	高
エッジケース対応	中	高	低	最高
将来対応力	高	高	低	最高
バックエンド変更	不要	不要	必要	必要

推奨案: 案A（Canvas APIによるフロントエンド圧縮）

外部依存を追加せず、フロントエンドのみの変更で完結する案Aを推奨する。

ImageUploaderの processFiles 内で、サイズが閾値（例: 2MB）を超えるJPEG/PNG画像に対してCanvas APIでリサイズ・圧縮を実行
リサイズ条件: 長辺が2048pxを超える場合にリサイズ
出力形式: JPEG（quality 0.8）
- ただしPNG透過画像はPNGのままリサイズ
圧縮後にも5MB制限のバリデーションを適用（フェイルセーフ）
圧縮中の進捗表示（「圧縮中...」のインジケーター）
バックエンドの制限値は変更しない

ファイル	変更内容
`frontend/src/components/ImageUploader.tsx`	圧縮ロジック追加、UIに圧縮中インジケーター追加

Loading diagram...

Loading diagram...