画像処理の技術選定と設計方針
環境
- Ruby on Rails 8.1.3
- Docker（開発環境）
- Render（本番環境）
設計概要
ユーザーがアバター画像をアップロード
↓
Rails サーバ上で libvips を使って 200×200 にリサイズ
↓
Active Storage 経由で Cloudinary に保存
という流れです。
技術選定
Active Storage （ CarrierWave と比較）
ファイルアップロードの仕組みとして CarrierWave と Active Storage を比較しました。
Rails 標準として安定してメンテナンスされている Active Storage を選びました。
Cloudinary （ImageKit との比較）
クラウドストレージの選択肢として Cloudinary を採用しました。
決め手は導入のシンプルさと無料枠の存在です。
導入手順はアカウントを作成して API キーなどを環境変数に設定し、gem を追加した上で config.active_storage.service を cloudinary に変更するだけです。Active Storage の設計上、ストレージの向き先は設定ファイルの1行で切り替えられるため、手軽に設定できます。
また、比較対象として ImageKit も無料枠を持っていますが、日本の Rails コミュニティにおける実績は Cloudinary と比べて少なく、トラブル時に参考にできる情報が限られます。日本語の実装記事が豊富な Cloudinary であれば導入の確実性が高いと判断しました。
libvips （ImageMagick との比較）
画像処理ライブラリとして ImageMagick と libvips を比較しました。Rails 公式ドキュメントには「ImageMagick は libvips に比べて知名度が高く普及も進んでいるが、libvips は 10 倍高速かつメモリ消費も 1/10 である」という記述があります（参考：Rails 公式ドキュメント）。
今回の要件はシンプルなアバター画像のリサイズなので、ImageMagick が持つ豊富な機能は不要です。
処理速度とメモリ効率に優れた libvips が適していると判断しました。
設計方針
アップロード前にサーバ側でリサイズする理由
リサイズのタイミングを Cloudinary へのアップロード前に置くことで、転送するデータ量を小さく抑えられるからです。
Active Storage のバリアント機能を使わない理由
バリアントとは、アップロード済みの画像を表示時に動的にリサイズする Active Storage の機能です。
下記の点から不要と判断しました
- アップロード時点でサーバ側に 200×200 に統一する設計を採っている
- 表示する場所によってサイズ差がほとんどない