画像リサイズのベストプラクティス - アスペクト比と補間アルゴリズムの選び方
アスペクト比を維持する重要性
画像をリサイズする際に最も重要なのは、アスペクト比 (縦横比) を維持することです。アスペクト比を無視してリサイズすると、被写体が引き伸ばされたり圧縮されたりして、不自然な見た目になります。人物写真では顔が横に広がったり縦に伸びたりする歪みが発生し、商品画像では形状が正確に伝わらなくなります。一般的なアスペクト比には 4:3 (デジカメ標準)、16:9 (ワイドスクリーン)、3:2 (一眼レフ)、1:1 (SNS プロフィール) などがあります。
アスペクト比を維持したリサイズでは、幅または高さの一方を指定し、もう一方を自動計算します。例えば、元画像が 3000x2000 (3:2) の場合、幅を 1500 に指定すれば高さは自動的に 1000 になります。計算式は単純で、新しい高さ = 元の高さ × (新しい幅 / 元の幅) です。
- 固定幅リサイズ: 幅を指定し、高さを比率に応じて自動算出する方法。Web サイトのカラム幅に合わせる場合に有効です。レスポンシブデザインでは、ブレークポイントごとに異なる幅の画像を用意します。
- 固定高さリサイズ: 高さを指定し、幅を自動算出する方法。サムネイル一覧で高さを揃えたい場合に使用します。Pinterest のようなマソンリーレイアウトでは幅固定が適しています。
- バウンディングボックス: 最大幅と最大高さを指定し、その範囲内に収まるようリサイズ。レスポンシブ画像の生成に最適で、縦長・横長どちらの画像にも対応できます。
補間アルゴリズムの種類と特徴
画像のリサイズ時には、元のピクセルデータから新しいピクセル値を計算する「補間 (Interpolation)」処理が行われます。元画像のピクセルグリッドと新しいサイズのピクセルグリッドは一致しないため、新しい各ピクセルの色を周囲のピクセルから推定する必要があります。アルゴリズムの選択によって、処理速度と画質のバランスが大きく変わります。
- Nearest Neighbor (最近傍補間): 最も近いピクセルの値をそのまま使用します。処理は最も高速ですがジャギー (階段状のギザギザ) が目立ちます。ドット絵やピクセルアートの拡大に適しており、意図的にピクセル感を残したい場合に選択します。QR コードの拡大にも適しています。
- Bilinear (双一次補間): 周囲 2x2 = 4 ピクセルの加重平均で新しい値を算出します。速度と品質のバランスが良く、リアルタイム処理やプレビュー表示に向いています。ゲームエンジンのテクスチャフィルタリングでも広く使用されています。
- Bicubic (双三次補間): 周囲 4x4 = 16 ピクセルを使用して 3 次多項式で滑らかな結果を得ます。Photoshop のデフォルト設定で、写真のリサイズに最適です。Bilinear より計算コストは高いですが、エッジの滑らかさが大幅に向上します。
- Lanczos (ランチョス補間): sinc 関数に基づく高品質な補間で、周囲 6x6 または 8x8 ピクセルを参照します。シャープネスを維持しつつリサイズできるため、写真の縮小に最適です。計算コストは最も高いですが、品質も最高です。
一般的に、縮小には Lanczos または Bicubic (Sharper)、拡大には Bicubic (Smoother) が推奨されます。Canvas API の imageSmoothingQuality プロパティで high を指定すると、ブラウザは高品質な補間 (通常 Bicubic 相当) を使用します。Sharp ライブラリでは sharp(input).resize(width, { kernel: 'lanczos3' }) のように明示的にアルゴリズムを指定できます。
用途別の推奨リサイズサイズ
リサイズの目標サイズは用途によって大きく異なります。適切なサイズを選ぶことで、表示品質とファイルサイズの最適なバランスを実現できます。以下に主要な用途ごとの推奨サイズをまとめます。
- Web サイト本文画像: 幅
800-1200px。コンテンツ幅が 800px のサイトなら、Retina ディスプレイを考慮して 1,600 px を用意するのが理想的です。ただし、ファイルサイズとのトレードオフを考慮し、1.5 倍 (1,200 px) で妥協する判断も合理的です。 - サムネイル:
300x300px程度。一覧表示用で、クリック後にフルサイズを表示する設計が一般的です。EC サイトでは400x400pxの正方形が標準的です。 - OGP 画像:
1200x630px。SNS でシェアされた際の表示に最適化されたサイズです。このサイズは Twitter、Facebook、LINE のすべてで適切に表示されます。 - 印刷用: 300 DPI 以上を確保。A4 サイズ (210 × 297mm) なら
2480x3508pxが必要です。名刺サイズ (91x55mm) なら1076x650pxです。 - メール添付: 幅
800-1000px、ファイルサイズ 500KB 以下を目安にします。多くのメールサービスは添付ファイルの合計を 25MB に制限しています。 - アプリアイコン: iOS は
1024x1024pxのマスター画像から各サイズを自動生成。Android は512x512pxが最大サイズです。
レスポンシブ Web デザインでは、srcset 属性を使って複数サイズの画像を用意し、デバイスの画面幅に応じて最適な画像を配信する手法が標準的です。一般的には 640px、960px、1,280 px、1,920 px の 4 段階を用意します。
リサイズ時の品質劣化を最小限に抑える方法
画像のリサイズは本質的に情報の損失を伴います。縮小では複数のピクセルを 1 つに統合するため細部が失われ、拡大ではピクセルを「推測」して生成するため元画像にない情報は復元できません。品質劣化を最小限に抑えるためのテクニックを紹介します。
まず、リサイズは可能な限り 1 回で完了させてください。複数回のリサイズを繰り返すと、その都度補間処理による劣化が蓄積します。元画像から目標サイズへ直接リサイズするのが鉄則です。CMS やビルドツールで自動リサイズする場合も、常にオリジナル画像をソースとして使用してください。
- シャープネス補正: 縮小後にアンシャープマスク (USM) を適用すると、失われたディテールを視覚的に補えます。半径
0.5-1.0px、量50-100%、しきい値0-2が目安です。Sharp ライブラリでは.sharpen()メソッドで適用できます。過度なシャープニングはハロー (白い縁取り) を生むため注意が必要です。 - 段階的縮小の回避: 50% 以下への大幅な縮小でも、一度に目標サイズまで縮小する方が品質が高いです。かつては段階的縮小 (50% ずつ) が推奨されていましたが、現代の Lanczos 補間では直接縮小の方が優れた結果を得られます。
- 元画像の保持: リサイズ後の画像とは別に、必ず元画像を保存しておきます。後から別サイズが必要になった場合に再リサイズできます。Git LFS やクラウドストレージでオリジナルを管理するワークフローが推奨されます。
- 適切なフォーマットでの保存: リサイズ後に JPEG で保存する場合、再圧縮でさらに劣化が発生します。品質設定は
85-92%の範囲が、ファイルサイズと画質のバランスに優れています。可能であれば WebP で保存し、より小さいファイルサイズで同等の品質を維持してください。
クロップとリサイズの組み合わせ - 構図を活かす手法
実務では単純なリサイズだけでなく、クロップ (トリミング) との組み合わせが頻繁に求められます。特に、異なるアスペクト比への変換が必要な場合 (例: 3:2 の写真を 1:1 の正方形サムネイルにする) は、クロップが不可欠です。
クロップの戦略:
- 中央クロップ: 画像の中央を基準にクロップする最もシンプルな方法。風景写真や対称的な構図に適しています。自動化が容易で、バッチ処理に向いています。
- スマートクロップ (顔検出): 人物写真では顔の位置を検出し、顔が切れないようにクロップ位置を調整します。Sharp の
.resize({ fit: 'cover', position: 'attention' })や、専用の顔検出 API を使用します。 - エントロピーベースクロップ: 画像内の情報量 (エントロピー) が最も高い領域を残すようにクロップします。被写体が中央にない写真でも、重要な部分を自動的に残せます。
- 手動クロップ + 自動リサイズ: CMS でフォーカルポイント (注目点) を手動設定し、各サイズへのリサイズ時にその点を中心にクロップする方式。WordPress の画像編集機能がこの方式を採用しています。
CSS による表示時クロップ:
画像ファイル自体をクロップせず、CSS の object-fit: cover で表示時にクロップする手法も有効です。この場合、画像は元のアスペクト比のまま配信し、ブラウザ側で表示領域に合わせてクロップします。object-position プロパティでクロップの基準点を調整できます。ファイルサイズは大きくなりますが、1 つの画像ファイルで複数のレイアウトに対応できる柔軟性があります。
自動リサイズパイプラインの構築
手動でのリサイズは少数の画像なら問題ありませんが、Web サイトの運用では数百〜数千枚の画像を複数サイズで管理する必要があります。自動化されたリサイズパイプラインを構築することで、一貫した品質と効率的な運用を実現できます。
Node.js + Sharp によるビルド時リサイズ:
Sharp は Node.js で最も高速な画像処理ライブラリで、libvips をバックエンドに使用しています。1 枚の元画像から複数サイズ・複数フォーマットを生成するスクリプトを数十行で記述できます。sharp(input).resize(800).webp({ quality: 80 }).toFile('output-800.webp') のように、リサイズとフォーマット変換を 1 つのパイプラインで実行します。
レスポンシブ画像の自動生成:
srcset 用の複数サイズを自動生成する場合、一般的には 4-6 段階のブレークポイントを設定します。例えば [320, 640, 960, 1280, 1920] の幅で生成し、HTML の srcset と sizes 属性で適切な画像を選択させます。Next.js の Image コンポーネントや Gatsby の gatsby-plugin-image はこの処理を自動化してくれます。
CDN での動的リサイズ:
Cloudinary、imgix、Cloudflare Images などの画像 CDN サービスを使えば、URL パラメータでリサイズサイズを指定し、オンデマンドで画像を生成できます。例えば https://cdn.example.com/photo.jpg?w=800&h=600&fit=cover のように、リクエスト時にリサイズが実行されます。初回リクエスト後はキャッシュされるため、2 回目以降は高速に配信されます。オリジナル画像を 1 つ管理するだけで、あらゆるサイズに対応できる柔軟性が最大のメリットです。