WordPressで画像をWebPに変換する方法｜コア機能とプラグインの使い分け

WordPressでは、プラグインを入れなくても image_editor_output_format フィルターを数行書けば、アップロードしたJPEGやPNGのサムネイル（サブサイズ）をWebPで出力できます。ただし、サーバーのGDまたはImagickがWebPに対応していることが前提で、元ファイルは変換されず、既存画像は再生成するまで変わりません。この記事では、サーバー側の確認から、コードでの変換、プラグインでの変換、既存画像の扱い、つまずきやすい点までを順に説明します。

WebPに変換すると何が変わるのか

WebPはJPEGやPNGに比べて、同程度の見た目でファイルサイズを小さくしやすい画像形式です。どれだけ軽くなるかは写真か図版か、圧縮品質をどう設定するかで大きく変わるため、「何割削減」と決め打ちせず、自分のサイトの代表的な画像で前後のサイズを比べるのが確実な判断方法です。

現行の主要ブラウザはWebPを表示できるため、表示側の互換性を心配する場面は少なくなりました。一方で、メールに画像を貼る、外部サービスに画像URLを渡すといった用途では、WebPを受け付けない相手がまだ残っています。サイト内の表示用と、外部に渡す用途を分けて考えておくと後で困りません。

WordPressコアのWebP対応の範囲

WordPress 5.8で、WebP画像のアップロードと、WebPを元にしたサブサイズ生成に対応しました。同じ5.8で image_editor_output_format フィルターが追加され、「この形式で入ってきた画像は、この形式で保存する」という対応表を差し替えられるようになっています。

WordPress 6.1の開発中には、JPEGのサブサイズを標準でWebP出力にする案が入りましたが、リリース前に取り下げられました。そのため（2026年10月現在）も、コアの既定はアップロードした形式と同じ形式でサブサイズを作る動作で、WebP化はフィルターかプラグインで有効にする必要があります。なお6.7以降、このフィルターの既定値にはHEIC/HEIF画像をJPEGに変換する設定が最初から入っています。自分でフィルターを書くときは、配列を丸ごと置き換えずに要素を追加する形にしてください。

サーバーがWebPを書き出せるか確認する

WebPの書き出しはPHPの画像ライブラリが担当します。GDならWebPサポート付きでビルドされていること、ImagickならImageMagick側にWebPのデリゲート（libwebp）が組み込まれていることが条件です。ここが満たされていないと、フィルターを書いても変換は行われません。

管理画面の「ツール」→「サイトヘルス」→「情報」タブにあるメディア処理の項目で、使用中の画像エディターと対応形式の一覧を確認できます。サーバーにSSHで入れるなら、次のコマンドでも確かめられます。

# GD の WebP 対応（true なら書き出し可能）
php -r 'var_dump(function_exists("imagewebp"));'

# Imagick の WebP 対応（WEBP が表示されれば可）
php -r 'if (class_exists("Imagick")) { print_r(Imagick::queryFormats("WEBP")); } else { echo "Imagick なし\n"; }'

# WordPress から見た判定（WP-CLI）
wp eval 'var_dump( wp_image_editor_supports( array( "mime_type" => "image/webp" ) ) );'

注意したいのは、コマンドラインのPHPとWebサーバーのPHP-FPMが別のバージョンや別の拡張構成になっている場合です。CLIで true でも、実際のアップロード処理では使えないことがあります。最後の wp eval の結果と、サイトヘルスの表示が一致しているかを見ておくと安心です。対応していない場合は、レンタルサーバーならPHPのバージョン切り替えで解決することがあり、VPSなら php-gd や php-imagick と libwebp を含むパッケージを入れ直します。

コードでサブサイズをWebP出力にする

プラグインを増やしたくない場合は、子テーマの functions.php か、テーマ変更の影響を受けない mu-plugins に次のコードを置きます。mu-plugins を使う場合は wp-content/mu-plugins/webp-output.php のように作成すれば自動で読み込まれます。

<?php
/**
 * JPEG・PNG のサブサイズを WebP で出力する。
 * サーバーが WebP を書き出せない場合は何もしない。
 */
defined( 'ABSPATH' ) || exit;

add_filter( 'image_editor_output_format', function ( $formats ) {
	static $supported = null;
	if ( null === $supported ) {
		$supported = wp_image_editor_supports( array( 'mime_type' => 'image/webp' ) );
	}
	if ( ! $supported ) {
		return $formats;
	}

	// 既定の HEIC→JPEG などは残したまま、JPEG と PNG の行き先だけ追加する
	$formats['image/jpeg'] = 'image/webp';
	$formats['image/png']  = 'image/webp';
	return $formats;
} );

PNGを対象にするかは用途しだいです。ロゴや図版のように透過や輪郭のくっきりした画像は、WebPにすると劣化が目に付くことがあるので、気になるなら image/png の行を外してJPEGだけを変換対象にします。

画質は wp_editor_set_quality フィルターで調整できます。WordPressの既定値はJPEGが82、WebPが86です。サイズを優先して少し下げたい場合は、形式ごとに値を返します。

add_filter( 'wp_editor_set_quality', function ( $quality, $mime_type ) {
	if ( 'image/webp' === $mime_type ) {
		return 80;
	}
	return $quality;
}, 10, 2 );

設定後は、テスト用にJPEGを1枚アップロードし、メディアライブラリの添付ファイル詳細でサムネイルや中サイズのURLが .webp になっているかを確認します。元のファイル（アップロードしたファイルそのもの）はJPEGのまま残るのが正常な動作です。大きな画像で自動作成される縮小版や、テーマが原寸を使う箇所など、どのURLが記事に出ているかはブラウザの開発者ツールのネットワークタブで実際に確かめてください。

プラグインで変換する場合

コードを管理したくない、AVIFも試したい、元形式との併用を細かく選びたいといった場合はプラグインが向いています。選び方の軸は大きく2つです。

1つ目は、WordPressのパフォーマンスチームが開発している「Modern Image Formats」（旧名 WebP Uploads）のように、コアの仕組みに沿ってサブサイズをWebPやAVIFで生成するタイプです。設定は「設定」→「メディア」にまとまっていて、元形式の画像も併せて作るかどうかを選べます。対象は新しくアップロードした画像のみで、プラグインの必要環境はバージョンごとに上がるため、導入前に配布ページで確認してください。

2つ目は、EWWW Image Optimizer や ShortPixel などの画像最適化プラグインです。元のJPEGの横に .webp を別ファイルで作り、<picture> タグへの書き換えや、.htaccess のリライトでブラウザに応じて出し分ける方式が中心です。既存画像の一括処理機能を備えているものが多い反面、外部APIを使うタイプでは処理枚数の上限や料金体系があるため、利用条件を確認してから導入します。

リライトで出し分ける方式では、同じURLに対してJPEGとWebPのどちらを返すかがリクエストの Accept ヘッダーで変わります。CDNやサーバーのページキャッシュが Vary: Accept を考慮しないと、WebP非対応の環境にWebPが返る、あるいはいつまでもJPEGが返るといった食い違いが起きます。CDNを使っているサイトでは、<picture> タグ方式を選ぶか、CDN側の画像変換機能に任せるほうが管理しやすくなります。

既存の画像をWebPにする

コードでもプラグインでも、設定を変えただけでは過去にアップロードした画像はそのままです。既存画像は、Regenerate Thumbnails のようなプラグインか、WP-CLIの wp media regenerate でサブサイズを作り直す必要があります。作業前には、データベースと wp-content/uploads のバックアップを取ってください。

# まず 1 枚（添付ファイルID 123）で試す。古いサムネイルは消さない
wp media regenerate 123 --skip-delete

# 問題がなければ全件。確認プロンプトを省略
wp media regenerate --skip-delete --yes

ここで最もつまずきやすいのが、記事本文に埋め込まれた画像URLです。ブロックエディターで挿入した画像は、本文に photo-1024x683.jpg のようなサブサイズのURLが直接書かれています。再生成で古いJPEGのサムネイルを削除すると、本文側のURLが残ったまま実ファイルが消え、画像が表示されなくなります。--skip-delete を付けて古いファイルを残しておけば、既存記事は従来どおりJPEGで表示され、新しく挿入する画像からWebPになります。本文の参照先まで書き換えたい場合は、置換の前にバックアップを取り、ステージング環境で表示を確認してから進めてください。

レスポンシブ画像の srcset は、WordPressが添付ファイルのメタデータから組み立てるため、再生成後はWebPのサブサイズが候補に入ります。本文の src はJPEGのまま、srcset はWebPという混在になることがありますが、表示上の問題は通常ありません。

うまくいかないときの確認順

変換されない場合は、次の順に切り分けると原因を絞り込めます。

• サイトヘルスや wp eval でWebP書き出しが「対応」になっているか
• フィルターを書いたファイルが実際に読み込まれているか（子テーマが有効か、mu-plugins の場所が正しいか）
• 別の画像最適化プラグインが同じ処理を上書きしていないか
• テストした画像が設定後に新しくアップロードしたものか
• キャッシュ系プラグインやCDNが古い画像URLを返していないか

アップロード時にエラーが出る、または処理が途中で止まる場合は、PHPのメモリー上限や実行時間の不足も疑います。大きな画像ではサブサイズの数だけ変換処理が走るため、WebP化前より負荷が上がることがあります。

まとめ

• WordPressコアは5.8以降 image_editor_output_format フィルターでサブサイズをWebP出力にでき、既定値は変わらず元形式のまま（2026年10月現在）
• 前提条件はGDまたはImagickのWebP対応。サイトヘルスと wp eval で、Webサーバー側のPHPで使えるかを確かめる
• フィルターは配列を置き換えず要素を追加する。画質は wp_editor_set_quality で形式ごとに調整できる
• 元ファイルは変換されず、既存画像は再生成が必要。本文の画像URLが切れないよう --skip-delete を付ける
• CDNやキャッシュを使うサイトでは、Acceptヘッダーで出し分ける方式の食い違いに注意する

• EWWW Image Optimizerの設定方法
• WordPressの画像サイズを管理する方法