「Edgeで画像を保存したら、勝手にWebPやAVIFになってしまい、Windows 10標準のアプリではうまく扱えない」――そんな現場の悩みを、仕組みから回避策・恒久対策まで一気通貫で解決する実践ガイドです。単なる小手先のテクニックではなく、なぜそうなるのか（HTTPのコンテンツネゴシエーションやOSのコーデック事情）を理解し、再現性のあるワークフローを手に入れましょう。
問題の全体像
Edge（Chromium系）でWebページ上の画像を右クリックし「名前を付けて画像を保存」を選ぶと、表示上はJPG/PNG/GIFでも、保存候補が.webpまたは.avifしか出てこないケースがあります。Windows 10標準環境ではAVIFのサムネイルや閲覧に制約があり、社内共有・DTP・レガシーツール連携などで困りがちです。サードパーティーの変換ツールに毎回頼るのも手間・品質・セキュリティ面で現実的ではありません。
技術的な原因
コンテンツネゴシエーション（HTTPの仕様）
ブラウザは画像を取得する際、サーバーへ「どの形式を受け取れるか」を示す Accept ヘッダーを送信します。Chromium系ブラウザは概ね以下のような値を送ります（例）：
Accept: image/avif,image/webp,image/apng,image/svg+xml,image/*,*/*;q=0.8
この自己申告に基づき、サーバー側（またはCDNの画像最適化機能）は、同一画像のバリアント（JPEG/PNG/WebP/AVIFなど）の中から最適と判断した形式を返します。より軽量なWebPやAVIFが選ばれた場合、ダウンロードの「実体」もその形式になり、拡張子も .webp や .avif になります。
<picture>/srcset による分岐
<picture> 要素や srcset も形式分岐の一因です。例えば、以下のようなマークアップでは、ブラウザがAVIFに対応していればAVIFが優先されます。
<picture>
<source type="image/avif" srcset="/images/sample.avif">
<source type="image/webp" srcset="/images/sample.webp">
<img src="/images/sample.jpg" alt="sample">
</picture>
この場合、右クリック保存でも「表示中の実体（最終的に選ばれた形式）」が保存対象になるため、JPGが用意されていてもAVIFやWebPで保存されます。
保存時のファイル名と拡張子が変わる仕組み
ダウンロード時の拡張子は、レスポンスヘッダーの Content-Type と、場合によっては Content-Disposition の filename パラメータに基づいて決定されます。CDNのオンザフライ変換（例：f=auto、format=auto 等の挙動）では、元がJPGでも返却がAVIF/WebPなら拡張子もそれに合わせて変わります。つまり「見た目がJPGでも、実際にはJPGを受け取っていない」ことが原因です。
Windows 10/11 のコーデック事情と制約
形式が最新になるほど圧縮効率は上がりますが、Windows 10の標準体験は限定的です。Windows 11ではネイティブ対応が進んだものの、運用環境によっては差異が残ります。
| 項目 | WebP | AVIF |
|---|---|---|
| 圧縮効率 | JPEGより良好。透過・アニメ可。 | 非常に高効率。HDR/10bit・透過・アニメ可。 |
| Windows 10（標準） | 拡張機能追加でサムネイル/閲覧が安定。 | 拡張機能や環境に依存。Photos/Paintで開けないファイルが残ることあり。 |
| Windows 11（最新） | ほぼ標準サポート。アプリにもよる。 | 標準サポートが拡充。高ビット深度・アニメなど一部はアプリ依存。 |
| 業務アプリ互換 | おおむね良好だがレガシーツールは要検証。 | 非対応・未検証ツールが依然多い。 |
注： 拡張子だけを「.jpg」に書き換えても中身は変わらず、開けなかったり色化け・表示崩れの原因になります。再エンコード（変換）が必要です。
いますぐ試せる回避策（目的別）
| 方法 | 狙い/手順 | メリット | デメリット | 対象者 |
|---|---|---|---|---|
| IEモードで再読み込み | Edgeの設定 > 既定のブラウザー > 「Internet Explorer モードでの再読み込みを許可」を有効化。該当ページで「…」>「Internet Explorer モードで再読み込み」。右クリックで保存。 | IEエンジンはWebP/AVIF非対応のため、サーバーがJPG/PNGを返しやすい。 | 長期的には縮小が想定される。サイトによっては表示崩れ。 | 確実に元形式で保存したいユーザー |
| 拡張機能で「保存形式を選択」 | 右クリックメニューからJPG/PNG/WebPを選択可能にするタイプを導入。 | マウス操作だけで完結。 | 品質・信頼性は拡張機能次第。評価が割れることがある。 | 手軽さ重視の一般ユーザー |
| コーデック追加（閲覧・簡易変換） | WebP/AVIFをサムネイル/Photosで見られるようにして、必要に応じて一括変換（IrfanView/XnConvert/ImageMagick等）を運用。 | 「とりあえず見える/変換できる」環境を短時間で用意。 | 元形式で保存できるわけではない。画質劣化・メタデータ喪失の可能性。 | 閲覧・変換が目的のユーザー |
| 開発者ツールで元URLを取得 | F12 > Elementsで<img>のsrc/currentSrcを確認。CDNのパラメータをJPG/PNG指定に書き換えて開く。 | 元のJPG/PNGが用意されている場合は高確率で取得可能。 | サイト/CDNごとにURL仕様が異なり学習コストあり。 | 上級ユーザー・制作/広報担当 |
| スクリーンショットで代替 | Snipping Tool/PrintScreenで取得。 | ルール/権限に依存しづらい。 | 原寸/画質/メタデータを損なう。著作権・ライセンス要配慮。 | 緊急時のやむを得ない手段 |
IEモードの詳細手順
- Edgeを開く → 設定 → 既定のブラウザー → 「Internet Explorer モードでの再読み込みを許可」を許可に。
- 対象ページで「…」メニュー → Internet Explorer モードで再読み込み。
- 画像を右クリック → 名前を付けて画像を保存。JPG/PNGで保存できるか確認。
企業環境ではIEモードのサイトリスト（Enterprise Mode Site List）で対象サイトを指定運用すると再現性が高まります。
開発者ツールで元画像URLを見つける
- F12でDevTools → Elementsタブを開き、対象画像の
<img>を選択。 - 右側のPropertiesで
currentSrcを確認。<picture>利用時はこれが最終的に選ばれたURLです。 - Networkタブ → 「Img」フィルタで読み込まれたリソースを確認。
Content-Typeがimage/avifやimage/webpなら、パラメータ（例：f=auto）をf=jpeg/format=jpeg等に変更して試行。 - 実体が表示されたら「画像を新しいタブで開く」→ 保存。
CDNごとに指定は異なります。例として f=jpeg / format=jpeg / fm=jpg / output=jpg などが使われることがあります（サイト実装に依存）。
企業・上級者向け：Acceptヘッダーを書き換えてJPG/PNGを取得
ローカルプロキシ（Fiddler Classic／mitmproxy など）でHTTPヘッダーを書き換えると、ブラウザや拡張機能に依存せず「サーバーから最初からJPG/PNGで返してもらう」ことが可能です。
Fiddler Classic（JScript.NET ルール）の例
// OnBeforeRequest ハンドラ内
if (oSession.oRequest.headers.ExistsAndContains("Accept","image/")) {
// AVIF/WebPを明示的に外し、汎用画像を優先
var acc = oSession.oRequest["Accept"];
acc = acc.Replace("image/avif,", "")
.Replace(",image/avif", "")
.Replace("image/webp,", "")
.Replace(",image/webp", "");
// 必要ならJPEG/PNGを優先する書き方に調整
oSession.oRequest["Accept"] = "image/jpeg,image/png,image/*;q=0.8,*/*;q=0.5";
}
mitmproxy（Pythonスクリプト）の例
from mitmproxy import http
def request(flow: http.HTTPFlow) -> None:
req = flow.request
if "image" in req.headers.get("Accept",""):
accept = req.headers["Accept"]
accept = accept.replace("image/avif,","").replace(",image/avif","")
accept = accept.replace("image/webp,","").replace(",image/webp","")
req.headers["Accept"] = "image/jpeg,image/png,image/*;q=0.8,*/*;q=0.5" プロキシ導入時は、HTTPS復号の社内ポリシー、証明書配布、個人情報の取り扱いに注意してください。誤設定はセキュリティリスクとなり得ます。
PowerShell / cURL でピンポイントにJPG/PNGを取得
ブラウザを介さずにHTTPヘッダーを明示して取得する方法です。ワークフローに組み込むことで、都度の手作業を減らせます。
PowerShell（Windows）
$u = "https://example.com/path/to/image"
$h = @{
"Accept" = "image/jpeg,image/png,image/*;q=0.8,*/*;q=0.5"
}
Invoke-WebRequest -Uri $u -Headers $h -OutFile "image.jpg"
cURL（クロスプラットフォーム）
curl -H "Accept: image/jpeg,image/png,image/*;q=0.8,*/*;q=0.5" \
-L "https://example.com/path/to/image" -o image.jpg
ヒント： JPG/PNGバリアントが存在しない場合はこの方法でもWebP/AVIFしか得られません。その際は変換工程を挟むか、配信元にJPG/PNGの提供を依頼します。
変換ワークフローを設計する（品質・メタデータを守る）
止むを得ず変換する場合は、画質やメタデータ（EXIF/ICCプロファイル）をできるだけ保持できるツール・設定を選びましょう。
| 目的 | 推奨アプローチ | 注意点 |
|---|---|---|
| 大量一括変換 | ImageMagick / XnConvert / IrfanView バッチ | 色空間の自動変換に注意。-colorspaceやICC維持オプションを明示。 |
| 高品位再現 | デスクトップ編集（Photoshop/GIMP等）でICC/EXIF保持設定を確認。 | 再圧縮の連鎖を避ける。元のビット深度からのダウンサンプリングに注意。 |
| アルファ透過の維持 | PNG（透過）またはWebP Losslessに一時退避し、最終出力を選択。 | JPGは透過不可。背景合成の品質と色管理を設計。 |
| アニメーション | APNG/WebP/AVIFの互換を確認し、最終納品形式の要件に合わせる。 | GIFへの戻しは容量が大きくなりがち。フレーム数調整を検討。 |
制作者・配信者側のベストプラクティス
閲覧者のダウンロード体験を良くするには、配信側の実装も重要です。
- 「オリジナルを保存」ボタンを用意：JPG/PNGの固定URLに
Content-Disposition: attachment; filename=...を付ける。 - CDNの自動最適化を理解：f=auto/format=auto 等の既定を把握し、「強制JPG/PNG」パラメータをドキュメント化。
- <picture> でのダウンロード導線：表示はAVIF/WebPでも、キャプションやメニューに「JPGを保存」リンクを併設。
- 著作権表記とメタデータ：自動変換でEXIFや著作権情報が落ちやすい。必要に応じて
IPTC/XMPをサーバー側で保持・再付与。
管理者向け：グループポリシー/IEモードの運用
企業環境では、ユーザー任せにせず、ポリシーで再現性を担保します。
- IEモードの許可：Allow unconfigured sites to be reloaded in IE mode を許可し、必要サイトをサイトリストで配信。
- プロキシでAcceptを正規化：社内プロキシにヘッダー正規化ルールを実装し、ログでヒット率・例外を監視。
- 変換基盤の整備：NAS上に「投げ込み→自動JPG化」ジョブを用意（例：ImageMagick + タスクスケジューラ）。
- 教育とガバナンス：「拡張子を書き換えない」「スクショは最終手段」「著作権・ライセンス順守」を周知。
よくあるQ&A
- Q：拡張子を
.jpgに変えれば開けますか？
A：いいえ。中身はAVIF/WebPのままです。必ず再エンコード（変換）が必要です。 - Q：Edgeの不具合ですか？
A：仕様に基づく挙動です。HTTPのコンテンツネゴシエーションや<picture>の分岐が原因です。 - Q：Chrome/FirefoxならJPGで保存できますか？
A：多くの場合同様です。どのブラウザも近いAcceptを送るため、配信側が最新形式を返せばJPGになりません。 - Q：画質劣化を避けたい。ベストは？
A：配信元のJPG/PNGバリアントを直接取得するのが最良。無理ならロスレス一時形式に変換し、最終出力へ。 - Q：アニメーションWebP/AVIFはどう扱う？
A：GIF化は容量増が極端です。用途に応じてフレーム間引き、WebP/AVIFのまま配布できないか検討してください。
検証：サーバーが返す形式を見極める
Networkタブでレスポンスヘッダーを確認しましょう。
| ヘッダー | 確認ポイント | 意味 |
|---|---|---|
Content-Type | image/avif / image/webp / image/jpeg 等 | 実体の形式。保存拡張子に影響。 |
Vary | Accept | リクエストの Accept に応じて応答が変わる（バリアント配信）。 |
Content-Disposition | attachment; filename="..." | ダウンロード名のヒント。常に付与されるとは限らない。 |
CDN別・形式固定のヒント（例）
実装は各社・各サイトで異なりますが、概念把握のための例を挙げます。
- Cloudflare系：f=auto が付いている場合、f=jpeg や f=png を試す。
- Fastly系：format=auto → format=jpeg/format=png を試す。
- Akamai系：クエリやパスで形式指定のパターンあり（例：im=resizeと併用）。
あくまで一例であり、サイトによっては無効化されていることもあります。最終的にはNetworkタブで確認してください。
「保存形式を選択」機能がない理由と要望の出し方
Edgeの標準UIは「表示している実体をそのまま保存する」思想のため、保存ダイアログで形式を選ぶことはできません。要望としては、保存時だけJPG/PNGを選べる オプションの実装、または ダウンロード時にコンテンツネゴシエーションを抑制する オプションが考えられます。フィードバックHubや企業チャネル経由で継続的にリクエストを伝えるとよいでしょう。
Windows 10のサポート状況と移行の視点
Windows 10はセキュリティ更新の提供が終了しています。現場視点では「最新コーデックや画像機能の恩恵を受けにくい」という運用上のデメリットが増えがちです。Windows 11へ移行すれば、Explorer/Photos/ペイントを含むOS標準のAVIF/WebP体験が改善され、変換やサムネイルの不具合が減ります。長期的なTCOを考えると、OS移行 + ブラウザ/配信設計の見直しが最もシンプルで持続可能な解です。
実務に効くチートシート
| やりたいこと | 最短手段 | 品質 | 再現性 | 備考 |
|---|---|---|---|---|
| 今すぐJPGで保存 | IEモードで再読み込み→保存 | ◎（再圧縮なし） | ◯ | サイトによってはUI崩れに注意 |
| 元URLを直に取得 | DevToolsのcurrentSrc／NetworkからURL解析 | ◎ | △（サイト依存） | CDNパラメータの癖を学ぶと早い |
| 変換を自動化 | バッチ（ImageMagick等）＋NAS監視 | ◯（設定次第） | ◎ | ICC/EXIF保持の設定必須 |
| 恒久的にJPG/PNGを優先 | プロキシでAcceptを書き換え | ◎ | ◎ | 導入・運用コストあり |
トラブルシューティング
- 保存すると拡張子が
.avifだが、画像ビューアで開けない：別ツールで中身の形式を確認（例：magick identify image.avif）。サムネイルが出ていてもアプリが対応しないケースあり。 - ダウンロード名が毎回「.webp」になる：
Content-Dispositionが付与されていないか、CDNが自動変換。URLパラメータで固定形式を試す。 - 同じページでJPGのときとWebPのときがある：
Vary: Acceptとキャッシュの組み合わせ。ハードリロードやキャッシュ無効化で挙動を切り分け。 - 印刷入稿で色が変わる：sRGBへの強制変換やICC脱落が原因。変換時にICCを保持、または明示的に埋め込み直す。
セキュリティとライセンスの留意点
- ダウンロード・変換・再配布は各サイトの利用規約/ライセンスに従いましょう。
- プロキシ導入時はHTTPS復号の可否・社内規程・監査ログを明確化。
- 拡張機能は開発元・権限・評価を確認し、最小限の権限に抑制。
まとめ
- JPG/PNGで保存できない主因は、ブラウザの
Acceptヘッダーとサーバー側の最適化（バリアント配信）。 - 短期解としてはIEモードが確実。合わせてDevToolsで元URLを掘ると成功率が上がる。
- 変換が必要なら品質・メタデータ保持を意識し、バッチ化で作業負荷を下げる。
- 恒久策はプロキシでの
Accept正規化か、Windows 11への移行＋標準機能活用。 - 配信側は「オリジナルを保存」導線や形式固定パラメータを提供すると、ユーザー体験が大幅に向上。
付録：便利なコマンド例
ImageMagickでAVIF→JPG（ICC/EXIF維持を試みる）
magick input.avif -strip -colorspace sRGB -define jpeg:preserve-settings=true -quality 92 output.jpg
-strip は不要なメタデータを落とします（ポリシーで決めてください）。色空間の扱いはワークフローに合わせて調整しましょう。
Windows バッチでフォルダー一括変換（例）
@echo off
for %%f in (*.avif *.webp) do (
magick "%%f" -colorspace sRGB -quality 92 "out\%%~nf.jpg"
)
echo done.
PowerShellでURLリストをJPG優先で取得
$list = Get-Content ".\urls.txt"
$headers = @{ "Accept" = "image/jpeg,image/png,image/*;q=0.8,*/*;q=0.5" }
foreach($u in $list){
$name = [System.IO.Path]::GetFileNameWithoutExtension(($u -split '\?')[0]) + ".jpg"
Invoke-WebRequest -Uri $u -Headers $headers -OutFile $name -UseBasicParsing
}
本記事の使い方（実務フロー例）
- まずはIEモードで保存を試す（成功すれば完了）。
- ダメならDevToolsでcurrentSrcやURLパラメータを調べ、JPG/PNGを直取得。
- それでも無理なら、PowerShell/cURLでAcceptを指定して取得。
- 恒久対策として、社内はプロキシでヘッダー正規化／個人は変換バッチを整備。
- 中長期的にはWindows 11へ移行し、標準機能での閲覧・変換の負担を減らす。
コメント