iPhoneで撮った写真をWordPressへアップロードしようとしたら、うまく入らない。
ファイルを見ると拡張子が「.HEIC」になっている。
仕方なくMacのプレビューでJPEGへ変換。
あるいはPhotoshopで開いて書き出し直す。
WordPressを仕事で使っていると、たまに出てくる地味に面倒な作業です。
これがWordPress 7.1でかなり変わりました。
WordPress 7.1ではHEICへの対応が強化され、条件が合えばiPhoneのHEIC写真をブラウザ側でJPEGへ変換してアップロードできるようになっています。
しかも今回変わったのはHEICだけではありません。
画像の圧縮。
リサイズ。
サムネイル生成。
これまでサーバー側で行っていた処理の一部を、WordPressを操作しているパソコンのブラウザ側で行うようになりました。
見た目には地味ですが、WEBサイトを運用する側には結構大きな変更です。
- そもそもHEICとは？
- HEICがWEB制作では少し面倒だった
- WordPress 7.1でHEIC対応が強化された
- HEICをブラウザ側でJPEGへ変換する
- WordPress 7.1ならHEICは必ずアップロードできる？
- HEIC対応はブラウザとOSにも左右される
- 画像処理そのものもブラウザ側へ移った
- WordPress 7.1ではパソコン側で画像を処理する
- なぜわざわざブラウザ側で処理するの？
- 「画像をアップしたらWordPressがエラー」の原因になることもある
- ブラウザ側処理ならPHPメモリを使わない
- 共有サーバーでは地味にありがたい
- アップロード画像も少し軽くなる
- 画像が軽ければ表示速度にも効く
- じゃあ画像圧縮プラグインはいらなくなる？
- 既存の画像最適化プラグインとの相性は確認したい
- Chromeなら全部動く？
- Safariでは全部使えない？
- 対応していない環境ではどうなる？
- AVIFにも対応
- アニメーションGIFも変わった
- iPhone写真をそのままWEBに載せていい？
- WordPressがリサイズしてくれても元画像は残る
- クライアント自身が更新するサイトにはかなり便利
- 「画像が入らない」という問い合わせも減るかもしれない
- WordPress 7.1へ上げればいい？
- 画像アップロードで確認しておきたいこと
- WordPressの画像アップロードが「サーバーの仕事」ではなくなってきた
- iPhoneで撮って、そのままWordPressへ
- 参考：WordPress公式情報
そもそもHEICとは？
HEICは、iPhoneなどで使われている画像ファイル形式です。
iPhoneで普通に写真を撮っただけなのに、パソコンへ送ったら、
IMG_1234.HEIC
となっていた。
見たことがある人も多いと思います。
JPEGより効率よく画像を保存できるため、同程度の画質でもファイルサイズを抑えやすいのが特徴です。
iPhone側では普通に見られるので、写真を撮っている本人はファイル形式を意識していないこともあります。
HEICがWEB制作では少し面倒だった
問題は、その写真をWEBで使うときです。
JPEGやPNGほど、どこでもそのまま扱える形式ではありません。
WordPressへアップロードしたときのHEIC処理も、サーバー環境に左右される部分がありました。
そのため、クライアントから、
「ホームページに使ってください」
とiPhone写真を30枚もらった。
開いてみたら全部HEIC。
まずJPEGへ変換するところからスタート。
こんなことが普通に起こります。
WordPress 7.1でHEIC対応が強化された
2026年8月19日に公開されたWordPress 7.1では、メディア処理が大きく変更されました。
WordPress公式が挙げている対応形式には、
- HEIC
- AVIF
- HDR gain map
などがあります。
その中でもiPhoneユーザーに分かりやすいのがHEICです。
HEICをブラウザ側でJPEGへ変換する
WordPress 7.1では、HEIC画像をブラウザ側でデコードし、JPEGへ変換してからサーバーへアップロードできる仕組みが入っています。
つまり、
iPhoneで撮影
↓
HEICファイルをWordPressへアップロード
↓
ブラウザ側で読み込み
↓
JPEGへ変換
↓
WordPressへ保存
という流れです。
これまで「サーバーがHEICを変換できるか」に左右されていた処理の一部を、アップロードする側の端末で処理できるようになったわけです。
WordPress 7.1ならHEICは必ずアップロードできる？
ここは少し注意が必要です。
WordPress 7.1へ更新したから、どんなパソコン・ブラウザでも必ずHEICを処理できる、という意味ではありません。
HEICのデコードには、利用しているOSやブラウザ側の対応も関係します。
HEIC対応はブラウザとOSにも左右される
WordPress公式の開発情報では、HEICのブラウザ内デコードについて、macOS上のChromium系ブラウザやSafari、HEVC対応環境を備えたWindowsなどが挙げられています。
つまりWordPressだけではなく、
- OS
- ブラウザ
- 端末側のHEIC・HEVC対応
も関係します。
「WordPress 7.1だから絶対大丈夫」ではなく、対応環境ならかなり扱いやすくなった、と考えるのが正確です。
画像処理そのものもブラウザ側へ移った
WordPress 7.1の変更で面白いのは、HEIC変換だけではありません。
画像をWordPressへアップロードすると、通常は元画像だけを保存するわけではありません。
テーマやWordPressの設定に応じて、
- サムネイル
- 中サイズ
- 大サイズ
- テーマ独自サイズ
など、複数サイズの画像が作られます。
これまでは基本的に、この処理をWEBサーバー側で行っていました。
WordPress 7.1ではパソコン側で画像を処理する
対応環境では、WordPress 7.1から画像の、
- 圧縮
- リサイズ
- サブサイズ生成
をブラウザ側で処理します。
技術的にはWebAssembly版のlibvipsが使われています。
簡単に言えば、レンタルサーバーへ大きな写真を送ってから全部処理させるのではなく、アップロードしているパソコン側で先に必要な画像を作ります。
なぜわざわざブラウザ側で処理するの？
大きな理由のひとつがサーバー負荷です。
最近のスマートフォン写真は普通に大きいです。
数MB。
場合によっては10MBを超える。
画像サイズも4000px、5000pxを超えることがあります。
こうした写真から複数のサムネイルをサーバー側で一気に生成すると、PHPのメモリをかなり使います。
「画像をアップしたらWordPressがエラー」の原因になることもある
小さな画像なら問題ありません。
でも高解像度写真を何枚もアップロードすると、
PHP memory limit。
処理時間。
サーバーCPU。
こうした制限へ引っかかることがあります。
写真そのものはアップロードできたのに、サムネイル生成で失敗。
あるいは「サーバーが画像を処理できません」というエラー。
画像アップロードでトラブルが起きる原因のひとつです。
ブラウザ側処理ならPHPメモリを使わない
WordPress 7.1の新しい仕組みでは、対応環境なら画像処理をユーザーのパソコン側で行います。
そのため、大きな画像を処理するためにWEBサーバーのPHPメモリを大量消費する必要がありません。
WordPress公式も、PHPメモリ制限やアップロード時のタイムアウトを避けやすくなることをメリットとして挙げています。
共有サーバーでは地味にありがたい
WordPress専用の高性能サーバーなら、画像処理で困ることは少ないかもしれません。
でも実際の企業サイトはさまざまです。
昔から使っているレンタルサーバー。
低価格な共有サーバー。
PHPメモリを自由に増やせない環境。
そういうサイトもあります。
端末側へ画像処理を逃がせる意味は意外と大きいです。
アップロード画像も少し軽くなる
WordPress公式によると、新しいブラウザ側画像処理ではlibvipsを利用し、JPEGについては従来のGDやImagickによる処理と比べて、より効率よく圧縮できるとしています。
公式の開発資料では、JPEGで約15％小さくなるケースが示されています。
もちろん画像によって結果は変わります。
すべてのJPEGが必ず15％減るという意味ではありません。
ただ、WordPressへ普通に画像を入れたときの生成ファイル自体が軽くなれば、ページ表示にも効いてきます。
画像が軽ければ表示速度にも効く
WEBページのデータ容量で大きくなりやすいのは画像です。
特に、
- 施工事例
- 飲食店
- 不動産
- EC
- 美容
- ポートフォリオ
のように写真が多いサイト。
1枚100KB違えば、10枚で約1MB違います。
スマートフォン回線で見るユーザーには無視できません。
じゃあ画像圧縮プラグインはいらなくなる？
ここは「全部いらない」とまでは言えません。
画像最適化プラグインには、WordPress標準機能とは別に、
- 既存画像の一括圧縮
- WebP変換
- AVIF変換
- CDN配信
- 遅延読み込み
- 画質の細かな指定
などを持つものがあります。
WordPress 7.1の画像処理だけで、すべての画像最適化機能を置き換えるわけではありません。
既存の画像最適化プラグインとの相性は確認したい
むしろ注意したいのはこちらです。
WordPress Core側の画像処理方法が変わったことで、画像アップロードを独自に処理するプラグインにも影響する可能性があります。
画像圧縮。
WebP・AVIF変換。
メディア管理。
こうしたプラグインを使っているサイトでは、WordPress 7.1対応状況を確認しておいた方がいいでしょう。
Chromeなら全部動く？
ブラウザ側の画像処理については、さらに条件があります。
WordPress公式の開発ドキュメントでは、フルのクライアントサイド処理はChromium系ブラウザが対象です。
具体的には、
- Chrome 137以降
- Edge 137以降
など。
FirefoxやSafariでは、フルのWASM画像処理パイプラインが使えない場合、従来のサーバー側処理へフォールバックします。
Safariでは全部使えない？
ここも少しややこしいところです。
SafariではWordPress 7.1のフルのクライアントサイド画像処理には対応していません。
ただしHEICのブラウザ内デコードについては別で、macOSのSafariでも利用できる場合があります。
つまり、
HEICを読み込む処理。
WordPressのすべての画像サイズをブラウザ側で生成する処理。
この2つは同じ条件ではありません。
対応していない環境ではどうなる？
基本的には従来方式へ戻ります。
ブラウザや端末が新しいクライアントサイド処理の条件を満たしていなければ、WordPressはサーバー側の画像処理へフォールバックします。
ユーザーが毎回、
「このPCではブラウザ処理できないから設定を変更しよう」
と考える必要はありません。
AVIFにも対応
WordPress 7.1ではAVIFの扱いも改善されています。
AVIFはJPEGやWebPより効率よく画像を圧縮できることがある比較的新しい画像形式です。
従来はサーバー側のPHP画像処理環境がAVIFへ対応しているかが問題になるケースがありました。
WordPress 7.1ではクライアントサイド処理を利用できる場合、サーバー側の画像エディターがAVIFに対応していなくてもAVIFを扱えるケースがあります。
アニメーションGIFも変わった
さらに面白いのがGIFです。
アニメーションGIFは、同じような短い動画と比べてファイルサイズがかなり大きくなることがあります。
WordPress 7.1では条件を満たすアニメーションGIFについて、ブラウザ側でMP4やWebMのコンパニオン動画を生成できる仕組みが追加されています。
見た目はGIFのように自動再生・ループ。
でも実際に転送するデータは動画形式。
ページを軽くできる可能性があります。
iPhone写真をそのままWEBに載せていい？
HEICをアップロードできるようになった。
だからiPhoneで撮った写真を何も考えず全部WordPressへ入れればいい。
そこは別の話です。
現在のスマートフォン写真は解像度がかなり高い。
WEBサイトで横幅1200px程度しか表示しない写真に、5000px以上の元画像が本当に必要なのか。
サイトによって考えた方がいいです。
WordPressがリサイズしてくれても元画像は残る
WordPressは表示用のサブサイズを生成します。
ただしメディアライブラリには元になる画像ファイルも存在します。
写真を何千枚も入れるサイトなら、ストレージ容量も増えていきます。
アップロードが楽になったからといって、画像管理そのものを考えなくていいわけではありません。
クライアント自身が更新するサイトにはかなり便利
制作側より、むしろ更新担当者に効く変更だと思います。
たとえば店舗サイト。
スタッフがiPhoneで商品を撮る。
そのままWordPressへアップロード。
お知らせを更新。
以前なら、
「HEICなのでJPEGへ変換してください」
と説明しなければならなかった。
この一手間がなくなるだけでも運用は楽になります。
「画像が入らない」という問い合わせも減るかもしれない
WEB制作側にはこれがありがたい。
「この写真だけアップロードできません」
「iPhoneから送った画像が使えません」
確認するとHEICだった。
ファイルを変換して返す。
一件なら数分です。
でも保守しているサイトが増えると、こういう小さな対応が積み重なります。
WordPress標準側で吸収してくれるなら、その方がいい。
WordPress 7.1へ上げればいい？
現在WordPress 7.1系を利用しているなら、2026年9月時点の最新リリースは7.1.2です。
WordPress公式のリリースアーカイブでも7.1.2が最新として公開されています。
7.1.2はセキュリティ修正を含むため、7.1や7.1.1へ止める理由はありません。
ただし本番サイトのWordPressを更新する場合は、テーマやプラグインとの互換性、バックアップ、更新後の動作確認まで含めて行います。
画像アップロードで確認しておきたいこと
WordPress 7.1以降を使っているなら、一度実際に試してみるのが早いです。
- iPhoneで撮影したHEIC写真を用意する
- WordPressのメディアへアップロードする
- メディアライブラリで正常に表示されるか確認する
- 投稿へ挿入する
- 実際のページで表示を確認する
- 生成された画像サイズも確認する
画像最適化系プラグインを利用しているなら、その状態でもテストします。
WordPressの画像アップロードが「サーバーの仕事」ではなくなってきた
今回の変更で個人的に面白いのはHEIC対応そのものより、画像処理をブラウザ側へ持ってきたことです。
WordPressは長い間、
画像をサーバーへ送る。
PHPで処理する。
サムネイルを作る。
という仕組みでした。
WordPress 7.1では、その仕事の一部をサイト更新者のパソコンへ移しています。
スマートフォンの写真はどんどん高画質になる。
画像形式も増える。
でもWEBサーバーのPHPメモリを際限なく増やせるわけではありません。
だったらアップロードする側の端末を使う。
かなり合理的です。
iPhoneで撮って、そのままWordPressへ
WEB制作をしている側からすると、HEICをJPEGへ変換すること自体は難しくありません。
でもサイトを更新する人全員が、画像形式を理解する必要はないと思います。
店で商品を撮った。
施工現場を撮った。
イベントの様子を撮った。
WordPressを開いて写真を入れる。
本来、それくらいでいい。
WordPress 7.1の画像処理は派手な新機能ではありません。
管理画面を開いても「AI搭載！」みたいな大きなボタンが増えるわけでもない。
でも「この画像、HEICだから変換してから送ってください」というやり取りがひとつ減る。
仕事で使うWordPressなら、こういう変更の方がじわじわ効いてきます。
