iPhoneのHEIC写真をWordPressにアップロードする：変換いらずの方法

結論から書く。WordPress 6.7以降は.heicを公式に受け付ける。ただし、サーバーのImageMagickがlibheif付きでビルドされていないとサムネイルは無言で壊れる。ホストが対応しているなら直接アップロード、対応していないかわからないなら端末側でJPEGに変換してから送るのが安全だ。

2017年以降のiPhoneはデフォルトでHEICで撮る。一方、2024年より前のWordPressサイトはほぼ全部、HEICのアップロードを拒否してきた。15年WordPressを触ってきて、自分が一番たくさんのクライアントを混乱に巻き込まれたフォーマット問題がこれだ。

2024年後半、WordPress 6.7がHEICのネイティブサポートを追加して状況は改善した。でも「改善」と「解決」は別物だ。HEICが無言で失敗するホスティングはまだあるし、このフォーマットでつまずくプラグインもあるし、フォーラムには相反するアドバイスが転がっている。「アップロードできない」と相談されて掘ってみたら原因がHEICだった、というケースはWordPressに画像がアップロードできないときの原因切り分けでも触れた。

ここから先は、何十ものクライアントサイトでこの問題に当たってきて学んだことだ。

HEICとは何か

HEIC（High Efficiency Image Container）は、HEIF画像フォーマットをH.265圧縮で包んだもの。AppleがiOS 11で採用したのは、見た目の画質を保ったままJPEGよりおよそ40〜50%小さいファイルが作れるからだ。JPEGなら6MBになる典型的なiPhoneの写真が、HEICなら約3MBで済む。

このサイズ差は、モバイル回線でアップロードするときに効いてくるし、WordPressサーバーのストレージにも影響する。同じ画質、より小さいファイル。フォーマットそのものに欠点はない。

欠点は互換性の側にある。長年、Appleのエコシステム外ではHEICファイルをほぼ何も開けなかった。Windowsは2018年に対応。Androidは2019年。WordPressが対応したのは2024年後半のバージョン6.7で、しかもサーバーに適切な画像処理ライブラリが入っていることが前提だ。

HEICはJPEGより豊富なメタデータも保持する。8ビットではなく10ビットのカラーデプス、sRGBより広いDisplay P3色域、そしてHDRゲインマップによりモダンなディスプレイがハイライトをより力強く描けるようになる。JPEGに変換するとこれら3つすべてが失われる。

WordPressがデフォルトでHEICを拒否する理由

WordPress 6.7より前は、メディアライブラリに.heicファイルを放り込むと「セキュリティ上の理由から、このファイルタイプは許可されていません」という例の警告が出た。これは実際にはマルウェア的な意味でのセキュリティではなく、ホワイトリストの問題だ。

WordPressはアップロードのすべてをwp_check_filetype_and_ext()で検証し、拡張子とMIMEタイプをget_allowed_mime_types()のハードコードされたリストと照合する。組み合わせがリストにないとメディアライブラリに到達する前に拒否される。「セキュリティ」という言い方をするのは、任意のファイルタイプを許可すると画像に偽装した実行ファイルをアップロードされる恐れがあるからだが、実態は単に厳格な許可リストにすぎない。

HEICの場合、歴史的な問題は2つあった。第1に、image/heicがデフォルトリストになかったこと。第2に、フィルタで強引に許可しても、PHPの画像ライブラリ（GDとImageMagick）がほとんどのサーバーでこのフォーマットをデコードできなかったこと。WordPressは正直だった。システムが処理できないファイルを受け取っても意味がない、という理由で拒否していたのだ。WordPress 6.7はimage/heicとimage/heifを許可リストに追加し、libheifが利用可能なときに画像エディタークラスがHEICをImageMagickに振り分けるよう教え込むことで、両方の問題を解決した。

WordPress 6.7のHEICサポート：何が変わったか

6.7より前の回避策は、すべての写真をアップロード前にJPEGに変換する（面倒）か、functions.phpにスニペットを書いてMIMEタイプをホワイトリスト化する（サーバーが本当にファイルを処理できないならリスクあり）か、のどちらかだった。両方のアプローチでサイトが微妙に壊れる場面を見てきた。ホワイトリスト方式はサムネイルが壊れ、手動変換方式はメタデータを無言で失う。

WordPress 6.7はHEICを許可ファイルタイプの一覧に加え、HEICからサムネイルを生成する基本サポートも盛り込んだ。サーバーのImageMagickがHEIFサポート付きでコンパイルされている（またはGDにlibheifがある）なら、WordPressはHEICをネイティブに扱えるようになった。

この「なら」が大きな分岐点だ。

うまくいく環境

最近のマネージドホスティング（Cloudways、Kinsta、SiteGroundの新しめのインフラなど）はだいたいHEIFサポート付きのImageMagickが入っている。これらのホストでWordPress 6.7以降を使っていれば、HEICアップロードはそのまま動くはずだ。

うまくいかない環境

古いインフラの共有ホスティングは当たり外れがある。格安ホストの多くは古いバージョンのImageMagickを動かしていて、HEIFサポートが含まれていない。アップロード自体は成功する（ファイルはサーバーに届く）が、WordPressがサムネイルを生成できない。メディアライブラリにフルサイズのHEICが置かれて、サムネイルプレースホルダーがあちこち壊れている、という状態になる。

このとき、わかりやすいエラーメッセージは出ない。メディアライブラリにプレビューの代わりに汎用アイコンが表示されるだけ。クライアントから「写真がアップロードできない」と報告を受けても、実際にはアップロードは成功していて、ただ管理画面で壊れて見えていただけ、ということが何度もあった。すべてが正しく動いているときのメディアライブラリの挙動について深掘りしたい人は、WordPressメディアライブラリガイドもどうぞ。

ホスティング会社別HEICサポート比較表

同じiPhoneのHEICファイルを主要5社のホストでテストして、きれいに処理できるホストとサムネイルが無言で壊れるホストを週末まるまる使って洗い出した。結果は2026年初頭時点のもの。

ホスト	HEICアップロード受付	サムネイル生成	ImageMagick + libheif	備考
Kinsta	可	可	あり（ImageMagick 7 + libheif）	もっとも快適。AVIFも動く。
Cloudways（Vultr/DO）	可	可	あり	スタックバージョン依存。新しめのサーバーは問題なし。
WP Engine	可	可	あり	2024年のプラットフォーム更新でネイティブHEICサポート追加。
SiteGround	可	部分的	環境による	新しめのプランは動く。古い共有環境はサムネイル失敗。
Bluehost（共有）	可	不可	なし（古いImageMagick）	アップロードは完了するがサムネイル壊れる。事前変換推奨。

パターンは明らかだ。プレミアムなマネージドWordPressホストは最新の画像ライブラリに投資しているが、格安共有ホスティングは古いスタックのままで、HEICサポートはよくてまだら。BluehostシェアードやそれくらいのプロバイダにいてHEICがワークフロー上重要なら、サーバーと格闘するよりアップロード前に変換したほうが早い。

サーバーがHEICに対応しているか確認する方法

WordPress管理画面でツール > サイトヘルス > 情報 > メディア処理 に移動する。ImageMagickのバージョンとサポートされているフォーマットを確認。一覧に「HEIC」または「HEIF」があればOK。

なければ、もしくはImageMagickではなくGDを使っているなら、HEICのサムネイルは生成されない。選択肢は2つ。ホスティング会社にImageMagickのアップグレードを依頼するか、写真をアップロード前に変換するかだ。

「アップロード前に変換」の落とし穴

「とりあえずHEICをJPEGに変換しておけ」がWordPressフォーラムでもっとも多いアドバイスだ。一見もっともらしい。でも画質を気にするなら、実は最悪の選択になりうる。iPhoneのデフォルトの変換経路は、多くの人が気づかないところで劣化を起こすからだ。

iOSにHEICからJPEGへの自動変換を任せるとき（Windows向けのAirDrop、Mail Drop添付、シェアシートからほとんどのアプリへ送るとき）、何が起きるか:

• 色域の圧縮。元のHEICはDisplay P3で保存されており、これはsRGBより約25%広い色空間。JPEGエクスポートはsRGBにクランプされる。鮮やかな赤・オレンジ・緑が目に見えてフラットになる。
• ビット深度の縮小。HEICは10ビットカラー（チャンネルあたり1024階調）を保持する。JPEGは8ビット（256階調）に固定される。空のなめらかなグラデーションが、変換後にバンディングとして現れることがある。
• HDRゲインマップの消失。iOSはSDRピクセルデータと並べてHDRゲインマップを埋め込み、対応ディスプレイで明るいハイライトを描けるようにしている。JPEGには等価のものがない。エクスポート時に影とハイライトのディテールが潰れる。
• EXIFの剥落（場合による）。変換にどのアプリが介在するかで、GPS座標、レンズ情報、撮影設定が落ちることがある。整理やジオタグにメタデータを使っているなら、一括変換前に必ず確認すること。
• ファイルサイズの肥大化。そもそもHEICが存在する理由は圧縮にある。3MBのHEICは品質85のJPEGに変換するとだいたい6〜8MBに膨れあがり、ストレージ消費が倍になる。

厄介なのは、これらの劣化がサムネイルサイズではすべて見えないこと。気づくのは誰かがズームしたとき、印刷したとき、広色域ディスプレイで見たときだ。そのときにはもう手遅れ、JPEGが手元のファイルになっている。

賢いやり方は、公開の瞬間に変換すること。守るべきものを守り、WordPressがフラット化する必要があるものだけをフラット化するツールを使う。これは使う価値のある専用アップロードツールすべての設計思想だ。

iPhone本体での変換問題

HEICをJPEGに変換してからアップロードする、と聞けば簡単そうだ。PCではその通り。macOSのプレビューなら数秒でバッチ変換できるし、Windowsのフォトアプリでも処理できる。

iPhoneでは話が違う。一括変換する標準機能がない。カメラ設定でHEICではなくJPEGで撮るように変えることはできる（設定 > カメラ > フォーマット > 互換性優先）が、そうするとWordPress送り以外の写真もすべて、40〜50%のファイルサイズメリットを失うことになる。

ショートカットアプリでHEIC→JPEGコンバーターを組む人もいる。動くけれど、ワークフローに手作業がもう1ステップ増えるし、変換後のファイルは大きくなる。問題を別の問題に置き換えただけだ。

本当に苛立たしいのは、iPhoneが場面によってはこの変換を自動でやっていること。メールで写真を送る、Windows PCにAirDropするときには、iOSが裏でJPEGに変換する。でもブラウザやWordPressアプリ経由でアップロードするときは、元のHEICをそのまま送る。アップロードに対してこの挙動を切り替える設定は存在しない。iPhoneからWordPressへ一度に10〜20枚を頻繁に送るなら、iOSの癖を乗り越えるテクニックをまとめたスマホからの一括画像アップロードのメモも参考にしてほしい。

SnapPressがHEICをどう扱うか

SnapPressを作るとき、HEICの扱いは最初に解決しないといけないことのひとつだった。アプローチはシンプル。アプリが元のHEICファイルを読み込み、iPhone上でローカルにJPEGへ変換してから、JPEGをWordPressにアップロードする。

つまり、サーバー構成に関係なくどのWordPressサイトでも動く。ホスト側にImageMagickのHEIFサポートは不要。WordPressがバージョン6.7である必要もない。サーバーに到達するのは標準的なJPEGで、これはバージョン1.0以来すべてのWordPressが扱える。

変換はデバイス上で行われ、写真1枚あたりほんの一瞬で終わる。変換が見えることもないし、設定することもない。写真を選んでアップロードをタップすれば、メディアライブラリにサムネイルもプレビューもすべて正常なJPEGが現れる。

これが「正しい」やり方かどうかは、何を重視するかによる。ファイルサイズを極限まで小さくしたいなら、対応サーバーにネイティブHEICをアップロードするほうが技術的には有利。サーバー設定を確認しなくてもどのWordPressサイトでも動くものがほしいなら、自動変換のほうが確実だ。SnapPressが他の選択肢に対してどう位置づけられるかを知りたい人は、競合するiOSアプリをいくつか比較したWordPress写真アップロードアプリのベスト記事もどうぞ。

自分は理論的最適化より信頼性を選んだ。ほとんどのWordPressユーザーは自分のホストのImageMagickバージョンなんて知らないし、気にしない。写真がちゃんと表示される、それだけが望みだ。料金プランの話はSnapPress v2.0のフリーミアム化に書いた。

JetpackとWordPress公式モバイルアプリは？

WordPress公式モバイルアプリ（多くの機能でJetpackに依存している）は、長年HEICの扱いが安定しなかった。最近のバージョンはアップロード前にHEICをJPEGに変換するようになっており、SnapPressがやっていることに似ている。ただしその変換はJetpackの画像処理パイプラインを通るので、Jetpack接続とサイトに紐づいたアクティブなWordPress.comアカウントが必要になる。

もうJetpackを使っているなら問題ない。使っていないなら厄介で、接続がないとアプリが完全にアップロードを拒否することがある。よりスリムな構成を望む読者向けに、別途Jetpackなしで写真をWordPressにアップロードする方法を書いた。要点はこう。Jetpackをワークフローから外したいなら、WordPress REST APIに直接話しかけるサードパーティアプリを使うこと。WordPress.comへの依存を完全にスキップできる。

もうひとつ出会うフォーマット：HEIFとAVIF

HEICは技術的にはHEIF画像をラップするコンテナフォーマットだ。.heicの代わりに.heif拡張子のファイルを見ることもある。WordPress 6.7はどちらも同じように扱う。

AVIFはウェブで勢いを増している新しいフォーマット（Netflixや多くのCDNが画像配信に使っている）。WordPressはバージョン6.5でAVIFサポートを追加した。新しいiPhoneの一部はAVIFで撮影できるが、まだデフォルトではない。

今のところiPhone写真をアップロードするなら99%はHEICが相手だ。でもAVIFは要チェック。HEICよりさらに高い圧縮率で、クロスプラットフォームのサポートも広い。

iPhone 16のAVIF対応：これから何が来るか

iPhone 16はiOS 18全体でフルAVIFサポートを搭載している。写真アプリはAVIFファイルを読み、Safariはインラインで描画し、シェアシートも一級市民として扱う。カメラはまだHEICがデフォルトだが、レンダリングとデコードのパイプラインは末端までAVIF対応になっている。

WordPress側も準備は整っている。バージョン6.5は2024年3月にimage/avifを許可MIMEタイプに追加し、6.7は画像処理ロジックを拡張してAVIFが正しいサムネイルを生成できるようにした。サーバーに新しめのImageMagick + libavifが入っていれば、設定なしでパイプライン全体が動く。

パブリッシャーにとってAVIFが重要な理由はこうだ。同等の体感品質でHEICよりおよそ20%、JPEGより約50%小さく圧縮できる。さらに、ブラウザの普及度が一度も完全になることのなかったHEICとは違い、すべての主要モダンブラウザ（Chrome、Firefox、Safari、Edge）で動く。そしてAV1のおかげでロイヤルティフリーで、HEICが乗っかっているHEVCの絡み合った特許ライセンスもない。

実務上の違い: HEICは入り口で格闘するキャプチャフォーマット、AVIFは出口で訪問者に届ける配信フォーマットだ。多くのワークフローは、カメラからのHEICオリジナル → メディアライブラリ内のJPEGまたはAVIF中間ファイル → CDNやShortPixelのようなプラグイン経由でブラウザへ送るAVIF、という流れに落ち着く。AppleがカメラのデフォルトをAVIFに切り替えるのは、ProRAWやLive Photosが移行を終えてから、つまり数年がかりの話になりそうだ。今は入ってくるHEICの扱いを最適化し、配信側のAVIFはCDNに任せておけばいい。

自分のおすすめ

ホスティングがHEICに対応していて（サイトヘルスで確認）、WordPress 6.7以降を使っているなら、HEICファイルをそのままアップロードしよう。小さなファイルサイズの恩恵を受けられる。

ホスティングがHEICに非対応か、複数サイトを別々のホストで運用していて1つずつ確認したくないなら、自動で変換してくれるツールを使おう。SnapPressはこれを自動でやってくれる。SnapPress Connectプラグインがサイト接続を担い、アプリがフォーマット変換を裏で処理する。

WordPressで一度トラブったからといって、iPhoneのカメラ設定をJPEGに戻さないでほしい。HEICのほうが優れたフォーマットだ。順応すべきはアップロードツール側で、カメラ設定じゃない。