Cocoonでサムネイルがぼやけた|以前あったRetina設定が見つからなかった話と、子テーマで直した記録

Cocoonのサムネイルがぼやける|Retina対応を子テーマで復活 WordPress
この記事は約14分で読めます。

2026年1月2日の夜、Rapls PDF Image Creator の初回 SVN リリースを終えてターミナルを閉じ、そのまま開いていた MacBook で自分のブログのトップページを開きました。記事一覧に並んだサムネイルが、1枚や2枚ではなく、ほぼ全部ぼんやりして見えました。

ぼやけたサムネイルと鮮明なサムネイルの比較画像

原因は、元画像でもキャッシュでもありませんでした。Cocoon の管理画面から Retina サムネイルのチェックボックスが消えていて、公式マニュアルどおりに探しても項目が見つからない状態だった、というのが答えです。機能そのものはテーマの中に残っていたので、子テーマの functions.php に3行足して、Regenerate Thumbnails でサムネイルを作り直したら直りました。足したのはこれだけです。

ここまでが結末で、以下はそこへたどり着くまでの記録です。手を動かした順に書きます。

検証環境:WordPress 6.9 / Cocoon 2.8.9 / Xserver スタンダードプラン / PHP 8.3.21 / 確認デバイスは Intel MacBook Pro 16inch(2019モデル)と iPhone 17 / WP-Rocket と Compress X(Avif) を併用 / 検証は2026年1月、最終確認は2026年5月。

確認できたこと:自分のサイト(raplsworks.com)で起きた症状、Cocoon 2.8.9 のソースコード(BBEdit の Multi-file search で「retina」を検索)、Cocoon 公式マニュアルの記述、子テーマで functions.php のフィルターを当てたあとの DevTools 確認、Regenerate Thumbnails での再生成、Intel MacBook Pro 16inch(2019)と iPhone 17 での実機確認。

確認できていないこと:Cocoon 2.9.0 以降での仕様変更、Studio Display や Pro Display XDR など他機種での挙動、画像が数百枚から数千枚あるサイトでの再生成負荷、Avif 以外のフォーマットでの PageSpeed への影響、WP-Rocket 以外のキャッシュプラグインとの組み合わせ。

この手順は私の環境で動いた記録です。functions.php を編集する前にバックアップを取り、ステージング環境があればそちらで先に試してください。

サムネイルぼやけ問題に気づいて対応するまでの時系列タイムライン

上は、気づいてから直すまでの流れを時系列にしたものです。実際には、疑わなくてよかったものを2つ疑ってから本題に入っています。

元画像は足りていた

最初に浮かんだのは、アップロードした元画像が小さかったのではないか、でした。アイキャッチに使っているのは、たいていプラグイン管理画面のスクリーンショットか、自作の解説図です。元画像が小さければサムネイルもきれいには出ません。メディアライブラリを開いて、いくつかの記事のアイキャッチを順にクリックし、「画像の編集」画面の右側に出る情報欄でピクセル数を確認していきました。結果は、1280px や 1920px を超えるものがほとんどで、明らかに足りないと言えるものはありませんでした。十分な解像度をアップロードしているのに、サムネイルだけがぼやける。ここで一度手が止まりました。

キャッシュでもなかった

次はブラウザキャッシュとサーバーキャッシュです。WP-Rocket を使っているので、古い画像が配信されている可能性は十分あります。管理画面から全キャッシュを削除して、ブラウザも Cmd+Shift+R でハードリロード。それでもサムネイルはぼやけたままでした。シークレットウィンドウでも、別のブラウザでも症状は変わりません。ここでキャッシュ系は切り離せました。手元の iPhone 17 でも同じように眠たく見えていたので、自分の目でも画面の調子でもなく、配信されている画像そのものに何かある、という見当はついていました。

開発者ツールに -320×180 と書いてあった

画面に出ている画像が物理的に何ピクセルなのかを、直接見るしかありません。Chrome でトップページを開いて Cmd + Option + I。左上の矢印アイコンで、並んでいるサムネイルのひとつを指定します。

ブラウザで開発者ツールを開いた状態
開発者ツールの矢印アイコンを赤枠で囲んだ画面

選択された img タグの src を見たとき、ちょっと声が出ました。

開発者ツールで読み込まれているサムネイルURL内の -320x180 を赤枠で強調した画面

ファイル名に -320x180 と入っています。表示領域とちょうど同じピクセル数の画像が読み込まれている、ということです。サムネイルの見た目のサイズは、たしかに320×180px相当でした。けれど MacBook Pro 16inch も iPhone 17 も高解像度ディスプレイで、同じ320×180pxでも物理的には2倍以上のピクセルを使って描画しています。

なぜ2倍のサイズが要るのか

MacBook や iPhone の画面は、見た目のサイズが320pxでも、内部では640px以上の細かさで描画していることがあります。

デバイスの種類 ピクセル密度の目安 代表的な機種
通常のディスプレイ 1x 古いデスクトップモニターなど
高解像度ディスプレイ 2x前後 MacBook、最近のWindowsノートPCなど
スマートフォン 2x〜4x程度 iPhone、Android各機種など

デバイス別ピクセル密度の比較表
ぼやける仕組みの図解イラスト

320×180px の表示領域に、本当に320×180px の画像を渡すと、高解像度ディスプレイは足りないぶんを引き伸ばして表示します。引き伸ばされた画像は輪郭が甘くなる。これが眠たく見えていた正体でした。用意するべきなのは、表示領域より大きめのサムネイルです。320×180px の場所に640×360px の画像を読み込ませれば、ピクセルが足りない状態にはなりません。

公式マニュアルにある項目が、管理画面にない

Cocoon には画像まわりの設定が細かく揃っていて、Retina ディスプレイ向けのサムネイル生成をオンにする項目があったはず、という記憶がありました。念のため他の解説記事もいくつか読みましたが、多くが同じ手順を紹介しています。Cocoon 公式マニュアルにも、「画像」タブの「全体画像設定」にある Retina ディスプレイの設定を変更する、と書かれていました。

そのつもりで Cocoon 設定 → 画像タブ → 全体画像設定を開きました。

Cocoon設定の画像タブを開いてもRetinaディスプレイの項目が見当たらない状態

上から下までスクロールしても、Retina に関連する項目がどこにも見当たりません。見落としているのかもしれないと何度かページを行き来して、全体画像設定のブロックも一つひとつ見ましたが、サムネイルサイズの項目はあっても Retina のスイッチはありません。投稿、インデックス、アピールエリアと他のタブも開きましたが、状況は変わりませんでした。私の環境は Cocoon 2.8.9 です。Cocoon は更新頻度が高く、機能の整理や追加が定期的に入るので、公式マニュアルの記述がテーマ側の変更に追いついていない、という可能性はありそうでした。

ソースコードに retina_thumbnail_enable は残っていた

管理画面に項目がなく、公式マニュアルと他の解説記事にはある。確認できる場所はテーマの中身しかありません。普段から、テーマやプラグインのソースは BBEdit の Multi-file search で横断検索しています。今回も Cocoon 親テーマのフォルダ全体に対して、キーワード「retina」で探しました。

BBEditのMulti-file search機能でCocoonテーマフォルダ内の retina 関連ソースコードを検索した結果画面

ヒットしたのは4つのファイルです。about-forms.phpimage-forms.phpimage-funcs.phpimage-posts.php。前後の文脈を読んでいくと、設定値の名前が retina_thumbnail_enable であることが見えてきます。

Cocoonのソースコード(image-forms.php)のキャプチャ

Retina サムネイルを有効化するフラグそのものは、テーマファイルの中にしっかり残っていました。機能の中身は生きていて、管理画面のチェックボックスだけが外れている状態のようです。アップデート履歴を一行ずつ追ったわけではないので断定はできませんが、過去のどこかのバージョンで、他の設定の整理に合わせて管理画面側の項目だけが削られたのではないかと思っています。

内部のフラグが残っているなら、子テーマの functions.php からフィルターで値を書き換えれば有効化できます。実際、この方法で動きました。

子テーマに3行足す

先に念を押しておくと、functions.php の編集はバックアップを取ってから手をつけてください。短いコードを足すだけでも、書き間違えるとサイトが真っ白になります。私も過去に何度か白画面を見ているので、編集前のバックアップは今でも習慣にしています。あわせて、有効になっているテーマが「Cocoon Child」であることも確認します。

WordPress管理画面「外観→テーマ」でCocoon Childが有効化されている状態

子テーマがまだ入っていない場合は、Cocoon 公式サイトから子テーマの zip をダウンロードして先にインストールします。親テーマを直接編集すると、Cocoon がアップデートされたタイミングで全部消えます。

「外観 → テーマファイルエディター」を開いて、右側のファイル一覧から子テーマ側の functions.php を選びます。ファイル名は同じでも親テーマと子テーマの両方に存在するので、画面右上の「編集するテーマを選択」が Cocoon Child になっているかを確認します。

WordPress管理画面の左メニュー「外観→テーマファイルエディター」をクリックする様子
テーマファイルエディター画面の右側ファイル一覧でfunctions.phpを選択する様子

ファイルの末尾に、冒頭で出した3行を追加します。add_filter は WordPress 標準の仕組みで、テーマやプラグイン側の設定値を外から書き換えるためのフックです。theme_mod_retina_thumbnail_enable は Cocoon が Retina 対応を判定するために読んでいる設定キーで、この値を 1 に強制しているだけ、という構造です。すでに別のコードを書いている場合は、既存はそのままにして末尾に足せば動きます。

functions.phpの末尾にコードを追加した状態の画面
コード追加後のfunctions.php全体の画面キャプチャ

書けたら画面下の「ファイルを更新」をクリックします。「ファイルの編集に成功しました。」と出れば保存は通っています。もし保存後にサイトが真っ白だったりエラーが出ていたりしたら、追加したコードの括弧やセミコロンの閉じ忘れを確認してください。バックアップから戻すのも手です。

「ファイルを更新」ボタンを赤枠で囲んだ画面
保存成功メッセージが表示された画面

これで、これからアップロードする画像には Retina 向けのサムネイルが自動で生成されます。ただし、過去にアップロード済みの画像のサムネイルは古いままです。

過去の画像を作り直す

WordPress は、画像をアップロードしたタイミングでサムネイルを生成します。functions.php にコードを足しただけでは、過去の画像のサムネイルは作り直されません。トップページや記事一覧のサムネイルもきれいにしたい場合は、再生成が要ります。私の目的はまさにそこでした。定番の Regenerate Thumbnails を使います。

「プラグイン → 新規追加」で「Regenerate Thumbnails」を検索して、インストールして有効化します。

管理画面「プラグイン→新規追加」メニュー
検索結果に「Regenerate Thumbnails」が表示された画面
「今すぐインストール」→「有効化」ボタンの画面

「ツール → Regenerate Thumbnails」を開いて、「Regenerate Thumbnails For All Attachments」を押すと、メディアライブラリ内のすべての画像についてサムネイルが作り直されます。処理が始まるとプログレスバーが出るので、途中でタブを閉じたり別のページへ移動したりしないようにします。

管理画面「ツール→Regenerate Thumbnails」メニュー
Regenerate Thumbnails画面で再生成ボタンをクリックする様子
再生成処理中のプログレスバー画面

その時点でアップロードしていた画像は、たぶん30枚くらいでした。Xserver スタンダードプランで数分ほどで終わり、ブラウザがフリーズすることも、サーバーが重くなる感じもありませんでした。数百枚から数千枚あるサイトだと、また別の話だと思います。負荷が気になるなら、夜間など訪問の少ない時間帯にやるのが無難です。反映されない画像がある場合は、既存のサムネイルファイルを削除してから作り直すタイプの再生成プラグインに切り替える方法もありますが、削除を伴う処理は影響が大きいので、サーバー側で確実にバックアップを取ってからにしてください。

2倍になったかを確認する

再生成が終わったら、最初に開発者ツールで見たのと同じ場所をもう一度見ます。トップページで Cmd + Option + I、同じ手順でサムネイルの src を確認します。

開発者ツールでサムネイル画像のURLを確認している画面

状態 画像URLの例
対応前 image-320×180.jpg
対応後 image-640×360.jpg

URL に含まれるサイズ表記が640×360のように2倍の数字に変わっていれば、Retina 向けのサムネイルが生成されています。あとは実機です。MacBook と iPhone でトップページを開いて、サムネイルがくっきりしていれば想定どおりです。

Retina対応後にスマホで表示したサムネイルのきれいな画面
Retina対応後のきれいなトップページ全体のキャプチャ

これで一気に印象が変わりました。本文の内容は同じなのに、トップページがしっかりして見える。サイトとして最低限の手入れができている感じが、すこし戻ってきたような気がしました。

ファイルサイズと PageSpeed はどうなったか

サムネイルが2倍サイズになれば、ファイルサイズも増えます。表示領域320×180px 向けで考えると、対応前は20〜30KB前後だったファイルが、対応後の640×360px では60〜100KB程度になることもあります。1枚あたりの差は小さくても、枚数が多ければ合計では変わります。

PageSpeed Insights のスコアがどう動くかは、気にしながら見ていました。結果は、対応の前後でモバイル96点のまま、まったく動きませんでした。これは、うちの構成が幸運だっただけかもしれません。Rapls Works ではページ表示の高速化に WP-Rocket を使い、画像の配信には Compress X という Avif 変換プラグインを併用しています。Avif は同じ見た目でも PNG や JPEG よりファイルサイズが小さくなるフォーマットなので、サムネイルのピクセル数が2倍になっても、配信される Avif のサイズはそこまで増えていない、という可能性があります。

WP-RocketとCompress X(Avif変換)を併用したサムネイル配信の構成フロー図

ここは推測です。自分のサイトでスコアの動きを見るのが確実だと思います。

気をつけたいこと

元画像のサイズ

640×360px のサムネイルを作るには、元画像が最低でも640×360px以上必要です。それより小さい元画像をアップロードしている場合、Retina サイズのサムネイルは作れません。アイキャッチを用意するときは、できるだけ大きめの画像を選んでおくと後から困りません。

サーバーのストレージ容量

サムネイルの数が増えるぶん、メディアライブラリ全体の容量も増えます。私の環境では正確に測っていないのですが、サイト規模が大きい人ほど、再生成の前後でストレージの使用量を一度見ておくと安心です。

再生成中のサーバー負荷

30枚程度なら一瞬で終わりましたが、画像が数百枚を超えるサイトだと、再生成中にサーバーのレスポンスが落ちる可能性があります。同じ時間帯に訪問が集中していると、訪問者には重いサイトになってしまうので、夜間帯が無難です。

よく聞かれる質問

Cocoon 設定の中に Retina の項目が見当たらないのですが、これで合っていますか?

合っています。私が確認した Cocoon 2.8.9 では、「Cocoon 設定 → 画像」の中に Retina ディスプレイ用の項目が見当たりませんでした。公式マニュアルにはその手順が書かれていますが、現行のテーマでは管理画面側の設定項目が見つからない状態のようです。機能の中身そのものはテーマ内に残っているので、子テーマの functions.php からフィルター経由で値を渡せば、同じ効果が得られます。

子テーマなしでもできますか?

技術的には親テーマを直接編集しても同じことができますが、おすすめしません。Cocoon がアップデートされたタイミングで、編集した内容が全部消えるからです。アップデートを当てた瞬間にぼやけ問題が再発して、何が起きたんだろうと原因を探すのは、けっこう疲れます。

既存の記事のサムネイルも変わりますか?

functions.php にコードを追加しただけでは変わりません。Regenerate Thumbnails などでサムネイルを再生成する作業が別途必要です。

元画像が小さい場合もきれいになりますか?

効果が出にくいです。640×360px のサムネイルを作りたいのに元画像が320×180px しかない、というケースだと生成されません。アイキャッチには、最低1280×720px、できれば1920×1080px以上を用意しておくと安心です。

新しくアップロードする画像にも反映されますか?

はい。コードを追加した後にアップロードする画像については、自動的に Retina 向けのサムネイルが生成されます。再生成は要りません。ただし元画像が小さいと、期待したサイズのサムネイルが作られないことがあります。

元に戻したい場合はどうすればいいですか?

functions.php に追加したコードを削除すれば、今後生成されるサムネイルは元の設定に戻ります。すでに生成済みの Retina サムネイルも戻したい場合は、コード削除後にもう一度 Regenerate Thumbnails で再生成してください。

使ってから問題は起きていませんか?

子テーマで対応してから数か月、サムネイルまわりで問題は起きていません。新しい記事をアップロードしても自動的に2倍サイズのサムネイルが生成されますし、Cocoon のアップデートが入っても子テーマ側の functions.php は消えないので、対応が続いています。

子テーマの functions.php 全体

子テーマの functions.php が初期状態に近い場合、全体としてはこの形に落ち着きます。

次に同じ症状を見たときのために

自分用のメモとして順番を残します。サムネイルが眠たく見えたら、まず開発者ツールで img の src を見る。ファイル名に -320x180 のような表示領域と同じ数字が入っていたら、そこでだいたい確定します。元画像のサイズとキャッシュは、この確認のあとで疑えば足りました。Cocoon 設定に Retina の項目が見当たらないのは仕様なので探さない。子テーマの functions.php に theme_mod_retina_thumbnail_enable のフィルターを3行足して、Regenerate Thumbnails で過去分を作り直す。確認は開発者ツールの URL と実機の両方で。

残っている宿題は、Cocoon 2.9.0 以降で管理画面の項目が戻っていないか、そして画像が数百枚を超えたときに再生成がどれくらい重くなるかです。どちらもまだ確かめていません。

あわせて読みたい関連記事

WordPress
この記事を書いた人
rapls

WordPressのプラグインを作っているフリーランスエンジニアです。Web開発はもう6年以上。WordPress.orgで Rapls AI Chatbot、Thanks Mail for Stripe、Rapls PDF Image Creator、Prime Cache の4本を公開し、保守を続けながら、日本語ロケールの翻訳エディター(PTE)も務めています。このブログに書くのは、現場で自分が実際にハマって、調べて、直した話です。

raplsをフォローする
raplsをフォローする

コメント

タイトルとURLをコピーしました