LASSIC Media らしくメディア
アプリ画像最適化（WebP/AVIF）を外注する方法
LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託
この記事のポイント
- WebP・AVIFは従来フォーマットより大幅にファイルサイズを削減でき、アプリのパフォーマンス向上に直結します。
- picture要素を使ったAVIF→WebP→JPEGのフォールバック実装と遅延読込（lazy loading）の組み合わせが現在の標準的アプローチです。
- 外注先に依頼する際は、CDN配信・変換ツール・ブラウザ対応の3点を確認することで、内製リスクを抑えながら導入できます。
目次
WebP・AVIFとは何か — 次世代画像フォーマットの基礎
モバイルアプリの画像最適化（WebP/AVIF）とは、JPEGやPNGに代わる次世代画像フォーマットへ変換し、ファイルサイズを削減しながら表示品質を維持する取り組みを指します。アプリの読み込み速度はユーザー体験に直接影響し、画像はページ全体のデータ量のうち大きな割合を占めます。
WebP（ウェブピー）は、Googleが開発したオープンな画像フォーマットです。MDN Web Docsによると、lossy（非可逆）圧縮では同等品質のJPEGと比べてファイルサイズが25〜35%小さくなり、lossless（可逆）圧縮ではPNGより26%小さくなります*1。
AVIF（AV1 Image File Format）は、動画コーデック「AV1」をベースに策定された次世代フォーマットです。web.devが公表した情報によると、AVIFはJPEGと比べて50%以上のファイルサイズ削減が見込める場合があります*2。AVIFはロイヤリティフリーのオープンフォーマットとして設計されており、HDRや広色域にも対応しています*1。
2つのフォーマットの特性を簡潔に整理すると次の通りです。
| フォーマット | JPEGとのサイズ比較 | PNGとのサイズ比較 | 主な特徴 |
|---|---|---|---|
| WebP | 25〜34%削減*3 | 26%削減（lossless）*3 | lossy/lossless両対応。 アニメーション・透過に対応 |
| AVIF | 50%以上削減の場合あり*2 | — | ロイヤリティフリー。 HDR・広色域対応。プログレッシブレンダリング非対応 |
ファイルサイズが小さくなることは、モバイル通信環境でのアプリ起動時間の短縮と、データ通信量の削減につながります。ユーザーが低速回線を利用している場面でも、表示速度の改善が期待できます。
ブラウザ対応の実態 — AVIF・WebPはどこまで使えるか
WebPはChrome・Edge・Firefox・Opera・Safariのすべての現行バージョンで対応済みです*1。2021年以降に主要ブラウザが一通りサポートしており、フォールバックを用意すれば実用上の問題はほとんどありません。
AVIFの対応状況は、Can I useのデータによるとグローバルブラウザシェアの93.42%が対応済みです*4。主要ブラウザ別の対応バージョンは以下の通りです。
| ブラウザ | AVIF対応バージョン | 備考 |
|---|---|---|
| Chrome（デスクトップ） | 85以降 | 2020年9月リリース |
| Firefox | 93以降 | アニメーションAVIFは113以降 |
| Edge | 121以降 | — |
| Safari（デスクトップ） | 16.4以降 | macOS Ventura 13.3以降に相当 |
| Safari on iOS | iOS 16.0以降 | — |
| Samsung Internet | 14.0以降 | — |
Internet Explorer（IE）はAVIF・WebPともに非対応です*4。IE利用者が対象ユーザーに含まれる場合は、JPEG/PNGへのフォールバックを設けることが大切です。
また、AVIF（AV1 Image File Format）は動画コーデックを転用した仕様のため、エンコード処理の負荷がWebPより高くなる傾向があります。ビルドパイプラインへの組み込みや、サーバーサイドでの変換処理の設計は事前に見積もっておく必要があります。
picture要素によるAVIF→WebP→JPEGフォールバック実装
異なるブラウザで適切なフォーマットを届けるには、MDN Web Docsが示す <picture> 要素（複数の <source> を持つHTMLコンテナ）を用いたフォールバックパターンが有効です*5。ブラウザが対応している最初のフォーマットを選び、未対応なら次に進む仕組みです。
基本的な記述は次のような形になります。
- 1行目：
type="image/avif"を持つ<source>（AVIF優先） - 2行目：
type="image/webp"を持つ<source>（WebPにフォールバック） - 3行目：
<img src="image.jpg">（最終フォールバック）
ブラウザは上から順に type を確認し、対応しているフォーマットのファイルのみを取得します。そのため通信コストが無駄になりません。
実装上の注意点として、<source> の記述順序が重要です。AVIFを先に書かなければ、AVIF対応ブラウザでもWebPが選ばれてしまいます。また、モバイルアプリのWebView（アプリ内ブラウザ）を利用する場合は、WebViewのレンダリングエンジンがAVIFに対応しているかを別途確認する必要があります。
この実装には少なくとも次の知識が必要です。
- HTML/CSSの基礎（
<picture>・<source>・srcset属性） - AVIF・WebP変換ツールの操作（Squooshなど）
- ビルドパイプラインへの変換処理の組み込み（Node.js/Webpack/Viteなど）
- 各フォーマットの品質設定と圧縮効率のトレードオフ理解
内製エンジニアがビルドパイプラインを持っていない場合は、変換スクリプトの設計から着手する必要があります。変換処理の実装ミスは、全画像が正しく表示されない障害につながるリスクがあります。
遅延読込とCDN配信 — 画像最適化を加速する2つのアプローチ
フォーマットの変換だけでなく、読み込みのタイミングと配信経路の最適化も組み合わせると、実用上の効果が高まります。
遅延読込（Lazy Loading）の活用
遅延読込（lazy loading）とは、画面の表示領域外にある画像をユーザーがスクロールするまで読み込みを遅らせる手法です。web.devの情報によると、<img> タグに loading="lazy" を付与するだけでブラウザネイティブの遅延読込が有効になります*6。JavaScriptライブラリ不要で実装できます。
画像の loading="lazy" はChrome 77以降・Edge 79以降・Firefox 75以降・Safari 15.4以降で対応しています*6。未対応ブラウザではこの属性が無視されるだけで、画像の表示は問題なく行われます。
ただし、ファーストビュー（画面の最初に表示される領域）に含まれる画像に loading="lazy" を付与すると、表示が遅延してLCP（Largest Contentful Paint、ページの主要コンテンツが描画されるまでの時間）が悪化する場合があります。ファーストビューの画像には付与しない設計が大切です*6。
CDNによる画像配信
CDN（Content Delivery Network、コンテンツ配信ネットワーク）は、世界各地のエッジサーバーからユーザーに近い場所でコンテンツを配信する仕組みです。モバイルアプリでCDNを活用すると、地理的な遅延を抑えながら画像を高速配信できます。
CDNの中にはAVIF/WebPへのリアルタイム変換機能を持つものもあります。その場合、アプリ側の実装を大きく変えずにフォーマット変換を自動化できるメリットがあります。一方で、CDNサービスの選定・設定ミスは意図しないフォーマットが配信されるリスクを招くため、対応フォーマット・キャッシュ設定・フォールバック挙動の確認が必要です。
内製リスクと外注が向いているケース
WebP・AVIF対応を内製で完結させるには、フォーマット変換・ビルドパイプライン改修・CDN設定・表示検証の4工程を自社エンジニアが担う必要があります。
対応ブラウザ・WebViewのテストマトリクスを組むと、iOS Safari・Android Chrome・Samsung Internet・Opera Mobileなど複数の組み合わせに及びます。フォールバック実装の不備は「特定のスマートフォンで画像が表示されない」という不具合を招く可能性があります。
工数の目安は対象画像の規模によって異なりますが、変換スクリプトの構築・テスト・ビルドパイプライン統合だけで相当な時間を要することがあります。専任のフロントエンドエンジニアが関与できない場合は、稼働コストが想定を超えるリスクがあります。
外注が特に有効なのは次のケースです。
- 社内にフロントエンド専任エンジニアがいない、または工数が確保できないケース
- 既存アプリのビルドパイプラインが複雑で、変換処理の組み込みリスクが高いケース
- CDN選定や画質設定のノウハウが社内に蓄積されていないケース
- リリーススケジュールが短く、試行錯誤の時間が取れないケース
外注パートナーが画像最適化の実績を持つ場合、変換設定の最適化・CDN連携・テスト工程を一括で委託でき、社内チームの本来業務への集中を維持できます。
外注先選定の3つのチェックポイント
画像最適化（WebP/AVIF）の外注先を選ぶ際に確認すべき項目を整理します。
チェックポイント1：変換パイプラインの実績と対応ツール
Squoosh（スクウォッシュ）はGoogleChromeLabs（Google Chrome Labs）が開発したオープンソースの画像変換ツールです*7。ブラウザ上で動作し、AVIF・WebP・JPEG・PNGへの相互変換と品質設定が可能です。外注先がこのようなツールや独自のビルドスクリプトをどのように活用しているか、変換処理の自動化・品質管理の方針を確認するとよいでしょう。
手動で1枚ずつ変換するワークフローは、画像数が増えるほど属人化・品質劣化のリスクが高まります。外注先がビルドパイプラインへの組み込みや自動変換フローを提案できるかを確認することが大切です。
チェックポイント2：CDN連携・配信設計の提案力
画像変換だけでなく、配信経路の設計まで対応できるかを確認します。CDNの選定・設定・フォールバック設計はフォーマット変換と表裏一体であり、配信側の設定ミスは変換の効果を打ち消します。
外注先が提案するCDN構成が、アプリの想定ユーザー地域・通信環境・アクセス規模と合致しているかを評価するとよいでしょう。
チェックポイント3：ブラウザ・WebView互換テストの体制
AVIF対応の有無はブラウザバージョンによって異なります。モバイルアプリのWebViewを利用する場合はさらに条件が複雑になります。外注先が対応デバイス・OS・WebViewのテストマトリクスを持ち、想定する利用環境でフォールバックが正しく動作することを検証できるかを確認します。
テスト体制が不明なまま発注すると、特定環境での画像非表示や品質劣化がリリース後に発覚するリスクがあります。
まとめ：アプリ画像最適化を外注するための判断軸
本記事ではモバイルアプリの画像最適化（WebP/AVIF）について、フォーマットの特性・ブラウザ対応・実装手法・外注判断の流れを整理しました。要点を3つにまとめると次の通りです。
第一に、WebPはJPEGより25〜34%、AVIFはJPEGより50%以上削減できる場合があり*2,*3、どちらも一次情報（Google・web.dev）で裏付けのある効果です。ただし削減率は画像の内容・品質設定により異なります。
第二に、AVIFはグローバルブラウザシェアの93.42%が対応済みですが*4、iOS Safari 16.0未満・IE非対応のため、picture要素によるAVIF→WebP→JPEGのフォールバック実装が現時点での標準的なアプローチです。
第三に、変換パイプライン構築・CDN設計・マルチデバイステストには専門知識が必要です。社内に専任エンジニアがいない場合や、リリーススケジュールが短い場合は、実績のある外注パートナーへの委託でリスクを抑えられます。
よくある質問
WebPとAVIF、どちらを優先して対応すればよいですか？
圧縮効率を優先するならAVIFが有利ですが、対応ブラウザの範囲はWebPのほうが広い状況です。MDN Web Docsが示す実装パターンでは、AVIF対応ブラウザにはAVIFを、非対応にはWebPを、さらに非対応にはJPEG/PNGを届けるpicture要素のフォールバック実装が推奨されています*1。実務上は両方の変換ファイルを用意してフォールバックを設けるアプローチが現在の標準です。
AVIFはiPhoneやiPadでも表示されますか？
Can I useのデータによると、iOS SafariはiOS 16.0以降でAVIFに対応しています*4。iOS 15以前のデバイスでは非対応のため、picture要素によるWebP/JPEGへのフォールバックが必要です。iOS 15以前のサポート対象期間が続くアプリでは、フォールバック実装を省略すると画像が表示されない場合があります。
画像の変換にはどのようなツールを使えばよいですか？
Google ChromeチームがオープンソースとしてSquooshを提供しており、ブラウザ上でAVIF・WebP・JPEGなどへの相互変換と品質設定が可能です*7。少量の画像を試験的に変換する用途に向いています。大量の画像をビルド時に自動変換するには、Node.jsの画像処理ライブラリやWebpack/Viteのプラグインを組み合わせる構成が一般的です。外注先に依頼する際はビルドパイプラインへの組み込み実績を確認するとよいでしょう。
遅延読込（lazy loading）を設定すると表示速度は上がりますか？
ファーストビューより下にある画像への適用は、初回ページ読み込み時の通信量を減らし、表示速度の改善につながります。web.devの情報によると、loading=”lazy”を付与したブラウザネイティブの遅延読込はJavaScriptライブラリ不要で動作します*6。ただし、ファーストビュー内の画像（特にLCP対象）に付与すると表示が遅延する場合があるため、適用範囲の設計が大切です。
画像最適化の外注にはどのくらいの費用がかかりますか？
対象画像数・変換自動化の規模・CDN連携の有無によって費用は異なります。現時点では一次情報として公的機関や業界団体から標準費用相場が公表されていないため、複数の外注先に個別に見積もりを依頼することをお勧めします。見積もり時は変換パイプライン構築・テスト体制・CDN設計を含む範囲を明確にすると、比較しやすくなります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：MDN Web Docs「Image file type and format guide」（Mozilla、2024年）
- *2 出典：web.dev「Compress images using AVIF」（Google、2024年）
- *3 出典：Google Developers「WebP Compression Techniques」（Google、2024年）
- *4 出典：Can I use「AVIF image format」（2025年参照）
- *5 出典：MDN Web Docs「picture 要素」（Mozilla、2024年）
- *6 出典：web.dev「Lazy loading images」（Google、2024年）
- *7 出典：GoogleChromeLabs「Squoosh」（Google Chrome Labs）
