WordPressの画像がぼやける原因と直し方｜スマホだけ・文字入り画像も比較

WordPressに画像を入れたら文字がにじむ。パソコンでは気にならないのに、スマホで見ると輪郭がぼやける。そんなときは、画像を何度も書き出し直す前に、「元の画像」「ページが読み込んだ画像」「画面上の表示幅」を分けて確認してください。

最初に試すのは、問題の画像だけを選び、画像ブロックの解像度を「大」や「フルサイズ」に変えて、プレビューで比較することです。改善すれば、読み込んでいた画像が小さかった可能性があります。変わらない場合は、元画像の品質、スマホでの画像選択、圧縮・配信処理を順番に調べます。全画像を一括で変更したり、プラグインをすべて停止したりする必要はありません。

この記事では、自作した文字入り画像を使って、縮小後の拡大、JPEG圧縮、スマホ相当の表示での画像選択を別々に検証しました。前半は管理画面で確認する手順、後半は制作担当者向けの調査方法です。コードを触らない方は、症状別の表と画像ブロックの確認、最後のチェックリストから進められます。

検証日：2026年9月10日。WordPressの操作確認には、本番とは独立したWordPress Playgroundのローカル環境（WordPress 6.8.3・PHP 8.3.33）を使用しました。最新版の画面を示すものではありません。PC・スマホ幅の画像選択はChromeによるブラウザ検証です。実機のiPhone・Android、すべてのテーマや画像最適化サービスで同じ結果になることを確認したものではありません。

まずは症状別に確認する｜画像がぼやける原因と直す順番

「ぼやける」には、細かな文字が読めない、写真の輪郭が甘い、四角いブロックが見える、最初だけぼんやりする、といった異なる状態が含まれます。原因をまとめて「WordPressの画質が悪い」と扱うと、必要のない設定変更が増えてしまいます。最も近い症状から、調べる対象を一つに絞りましょう。

症状	最初に確認すること	次の対処
パソコン内の元画像もぼやける	元画像を100%表示して文字や輪郭を見る	高解像度の原本から再書き出し、撮影・切り出し位置を見直す
記事に入れると急に粗くなる	画像ブロックの解像度と表示幅	その画像だけ「大」「フルサイズ」で比較
スマホだけぼやける	スマホ表示時に実際に選ばれた画像の幅	srcset・sizes・配信サービスの幅指定を確認
文字や赤枠の周囲だけにじむ	同じ寸法の原本と圧縮後を比較	圧縮を弱める、PNGや可逆WebPで比較する
本文は鮮明だが一覧だけ粗い	一覧カードが使うサムネイルサイズ	テーマやカードの画像出力を確認
読み込み中だけぼやける	読み込み完了後に鮮明になるか	遅延読み込みやプレースホルダーを確認
差し替えても古い画像が出る	画像の内容・URL・更新状態	画質ではなく保存やキャッシュの反映を切り分ける

たとえば「300pxの画像を横幅800pxに引き伸ばしている」なら、圧縮率を変更しても画素不足は解消しません。一方で「1200pxの画像が読み込まれているが、赤い文字だけにじむ」なら、さらに大きいサイズを送る前に圧縮設定を調べる価値があります。幅の問題と圧縮の問題を混ぜないことが、遠回りを減らすポイントです。

変更前に、問題のページURL、画像ファイル名、見ている端末、どの部分が読みにくいかを控えてください。「画像が悪い」よりも「スマホの記事本文で、表の右下にある金額が読めない」と記録したほうが、改善後に同じ箇所を比較できます。複数枚で起きていても、最初は代表の一枚で試します。

元画像は鮮明？アップロード前のファイルを確認する

容量のKBより先に、横幅・高さのpxを確認

画像の「大きさ」には、1200×600pxという画素数と、70KBというファイル容量があります。画素数は縦横にいくつの点で画像を表しているか、容量は保存するデータの量です。容量が大きければ必ず鮮明、容量が小さければ必ず不鮮明、という関係ではありません。文字中心の図は軽くても鮮明になり、ノイズの多い写真は大容量でも輪郭が甘いことがあります。

Windowsでは、元ファイルを右クリックして「プロパティ」の「詳細」で幅と高さを確認できます。ファイル形式によって項目が出ない場合は、画像編集ソフトの画像サイズ表示を使ってください。Webページから保存した画像の場合、原作者の大きな原本ではなく、そのページ用に縮小された画像を保存している可能性にも注意します。

続いて元画像を開き、画面に合わせた縮小表示だけでなく、100%相当の表示で問題箇所を見ます。写真なら髪や輪郭、文字入り画像なら小さな文字と細線、スクリーンショットなら設定名を確認します。ここで読めない文字が、WordPressへのアップロードだけで正確に復元されるわけではありません。

小さな画像を大きく保存し直しても、原本には戻らない

300pxの画像を画像編集ソフトで1200pxに拡大すると、ファイルの寸法は1200pxになります。しかし、最初から1200pxで作った画像と同じ細部が戻るわけではありません。補間によって境目が滑らかになっても、つぶれた文字の形や数字を確かな情報として取り戻せるとは限りません。

文字入りバナーなら、PNGを拡大するのではなく、Illustratorやデザインツールの編集元から必要な寸法で書き出します。スクリーンショットなら、画像を引き伸ばす前に、撮影対象のウィンドウを大きくする、必要なパネルだけを撮るなど、素材の作り方を変えます。画像内の説明文が長い場合は、本文のテキストへ移す方法も有効です。

また、チャットやSNSを経由して受け取った画像が、共有時に縮小・変換されていることがあります。原本を持つ人に確認できるなら、「もっと重い画像」ではなく「加工前の横幅が分かる原本」を依頼しましょう。権利や機密情報を確認せず、外部の高画質化サービスへアップロードする必要はありません。

WordPressの画像ブロックで、読み込むサイズを確認する

元画像が鮮明なら、次は記事側の設定です。以下は標準の画像ブロックを使う場合の流れです。クラシックエディター、ページビルダー、テーマ独自の画像パーツでは、項目の場所や名称が異なります。「解像度」「画像サイズ」「Image size」「Resolution」など、使用する画像ファイルのサイズを選ぶ項目を探してください。

1. 該当する記事を開き、問題の画像を選択します。周囲の段落ではなく、画像ブロックを選びます。
2. 右側のブロック設定を開きます。表示されていなければ、編集画面の設定を開いて「ブロック」側を選びます。
3. 解像度の選択肢を確認します。サムネイルや中サイズになっていたら、現在の設定を記録します。
4. その画像だけ「大」または「フルサイズ」に変更します。選択肢は、元画像とサイトの設定によって異なります。
5. プレビューを開き、同じ画面幅・同じ倍率で比較します。保存が必要な操作は下書き・検証環境から行います。
6. 読みやすくなったかに加え、画像が極端に大きくなっていないか、レイアウトが変わっていないかを確認します。

重要なのは、「解像度」と、画面に配置する「幅・高さ」を別の設定として考えることです。中サイズの画像を選んだまま、表示幅だけ800pxへ広げると、小さい画像を大きく見せる指定になることがあります。反対に、十分な解像度の画像を選び、画面上では小さく見せる設定もできます。項目の基本的な役割はWordPress公式の画像ブロック説明でも確認できます。

本記事のローカル検証では、1200×600pxのPNGをアップロードすると、300×150px、768×384px、1024×512pxなどの画像が生成されました。同じ一枚の画像でも、複数の寸法が存在する状態です。実際のサイトでは管理画面のメディア設定、テーマ、プラグインが関わるため、この寸法の一覧がそのまま全サイトに当てはまるわけではありません。

「フルサイズ」に変えても改善しない場合

フルサイズに変えても、ブラウザが読み込む画像が必ず原本一種類に固定されるとは限りません。レスポンシブ画像の候補から別サイズを選んだり、画像配信サービスがURLを変換したりする構成があります。実際にローカルWordPressで生成したフルサイズの画像HTMLにも、複数サイズの候補が含まれていました。

また、大きな画像ではWordPressの処理により縮小版が基準になる場合があります。標準の大画像のしきい値には2560pxが使われますが、フィルターなどで変更可能です。「フルサイズ＝カメラの原本そのまま」と決めつけないでください。詳しい条件はbig_image_size_thresholdの公式リファレンスを参照できます。

この段階で変化がなければ、無制限に大きな画像をアップロードし続けるのではなく、後述するcurrentSrcで実際の配信画像を確認します。管理画面で選んだ設定と、訪問者のブラウザに届くデータが同じかを調べるのが次の一手です。

比較検証①：300pxの画像を600pxで表示するとどうなる？

幅の不足を確認するため、文字・細線・赤い注釈を含む1200×600pxの自作画像を用意しました。この原本から600×300pxと300×150pxのPNGを作り、比較図ではどちらも横幅600pxにそろえています。圧縮形式はPNGのままにして、主に縮小と再拡大の影響を見られるようにしました。

下の比較図は、上が1200px原本から600pxに縮小したもの、下が300pxまで縮小したあと600pxへ拡大したものです。記事の表示幅によって図全体が縮小されるため、差が小さく見える場合は画像を開いて確認してください。比較用の加工条件は説明のためにそろえたもので、すべてのブラウザの補間結果と同一ではありません。

確認すると、300pxを経由した画像では、小さい文字の線が太く混ざり、赤文字や細い縦線の境界が柔らかくなりました。大きな見出しは内容を読み取れても、小さな数字や設定名は読みにくくなります。「画像全体は見えるから大丈夫」ではなく、読者に読んでほしい最小の文字を基準に判断する必要があります。

この結果から言えるのは、小さな画像を大きく表示することが、ぼやけの一因になるということです。すべての写真に1200pxが必要だとか、600pxなら必ず十分だという結論ではありません。必要な寸法は、実際の表示幅、画面の密度、画像内の細かさによって変わります。次の節では、その目安を計算します。

表示幅を小さくするだけで改善できる場合もある

原本が小さく、取り直しや再書き出しができない場合は、表示する面積を小さくする選択もあります。300pxしかない画像を記事幅いっぱいに引き伸ばすより、補助的な小画像として配置し、内容を本文で説明したほうが読みやすいことがあります。ただし、スマホでも重要情報が読めるかは別途確認してください。

画像の周囲の余白を切る方法も、場合によっては有効です。ただし、切り抜いた部分をまた大きく引き伸ばせば画素不足は残ります。たとえば横幅1200pxのスクリーンショットの中に、実際に必要な設定欄が横幅300pxしか写っていないなら、その欄自体の情報量は300px相当です。画像全体の寸法だけを見て判断しないことが大切です。

スマホだけぼやけるときは、表示幅とDPRを分けて考える

スマホの画面は小さいので、小さな画像で十分だと思うかもしれません。しかし、Webページの幅を表すCSSピクセルと、画面が持つ物理的なピクセルは同じとは限りません。DPRは、その比率を考えるための値です。ここでは厳密な画質保証ではなく、画像の幅が明らかに足りないかを見つける目安として使います。

必要な画像幅の目安 ＝ 画面上の表示幅（CSS px）× DPR
例：表示幅350 CSS px × DPR 2 ＝ 幅700px程度
例：表示幅350 CSS px × DPR 3 ＝ 幅1050px程度

同じ表示幅350pxでも、300pxの画像を受け取る場合と1200pxの画像を受け取る場合では、細かい文字に使える情報量が違います。ただし、必要幅を満たしただけで、元画像のピンぼけや強い圧縮まで直るわけではありません。また、常にすべての端末へ最大サイズを送ればよい、という話でもありません。

画面上の表示幅	DPR 1の目安	DPR 2の目安	DPR 3の目安
150 CSS px	150px	300px	450px
350 CSS px	350px	700px	1050px
600 CSS px	600px	1200px	1800px
800 CSS px	800px	1600px	2400px

たとえばブログ本文の最大幅が800pxでも、左右に余白のあるスマホでは画像が350px程度になることがあります。PCの幅だけを基準に一種類の画像を決めるのではなく、表示位置に応じた候補を用意する考え方が役立ちます。ファイル容量が増えると読み込み負担も変わるので、文字の読みやすさと配信容量の両方を見ます。

ブラウザの拡大率や、実機との違いにも注意

PCのブラウザを拡大している場合、通常表示のときと見え方や画像選択の条件が変わることがあります。比較の際は、まず同じズーム倍率にそろえます。スマホのピンチ操作による拡大も、通常の読み方とは別に記録しましょう。「200%に拡大して粗い」ことと、「通常表示で文字が読めない」ことは分けて判断します。

開発者ツールのスマホ表示は、幅やDPRを切り替えて原因を調べるのに便利です。ただし実機のディスプレイ、OS、ブラウザ、通信設定を完全に再現するものではありません。ブラウザ検証で改善したら、可能な範囲で実機でも確認します。確認していない機種まで「対応済み」とせず、検証条件を残すと後の問い合わせに対応しやすくなります。

比較検証②：同じ元画像でも、sizesの指定で選択画像が変わった

次は、ブラウザが実際に選ぶ画像を確認しました。自作の検証ページに300px・600px・1200pxの候補を用意し、画面上では最大600px、スマホ幅では350pxになるよう配置しています。元画像も候補も同じにして、画像がどの幅で表示されるとブラウザに伝えるか、その指定だけを変えました。

正しい条件では、表示幅に対応するsizesを指定しました。誤った条件では、実際は350pxで表示される画像に対して、sizesを150pxに固定しています。これは本番サイトの設定を壊して試したのではなく、原因を分離するために作ったローカルの再現ページです。

テスト条件	表示幅	DPR	選ばれた画像幅	表示幅×DPR
PC・表示幅に合う指定	600 CSS px	1	600px	600px
スマホ相当・表示幅に合う指定	350 CSS px	2	1200px	700px
スマホ相当・150pxと誤指定	350 CSS px	2	300px	700px

このテストでは、誤った指定のときだけ300pxのファイルが選ばれました。原本の1200px画像は用意されていても、読者が実際に受け取る画像は小さい状態です。管理画面の原本が鮮明だからといって、スマホにも十分な画像が届いているとは判断できないことが分かります。

一方、正しい条件で1200pxが選ばれたのは、候補が300・600・1200pxだった今回の結果です。候補に750pxや800pxがあるサイト、異なるブラウザ、読み込み済みの画像を再利用する状況では、選択結果が変わり得ます。「DPR 2なら必ず最大の画像」という規則を覚えるのではなく、実際に選択されたURLを確認することが重要です。

srcsetとsizesは、画像を劣化させる機能ではない

srcsetは画像の候補を並べるための属性で、sizesは幅指定の候補を使う場合に表示幅の情報を伝えるための属性です。適切に組み合わせれば、小さい表示には軽い候補、大きい表示には十分な候補を使いやすくなります。WordPressのレスポンシブ画像の仕組みを使うこと自体が、ぼやけの原因ではありません。

したがって、画像が粗いからといってsrcsetをサイト全体で削除するのは、最初の対処として勧めません。候補が不足しているのか、表示幅の情報が合っていないのか、独自の画像配信処理が候補を小さくしているのかを分けます。本番の共通設定を変える場合は、本文だけでなく一覧・関連記事・ロゴへの影響も確認してください。

比較検証③：文字入り画像は圧縮形式でも読みやすさが変わる

画像の幅が足りているのに、文字や赤枠の周りが汚く見える場合は圧縮を確認します。今回は、同じ1200×600pxの原本から、PNG、可逆WebP、JPEG品質85、JPEG品質20を作りました。JPEGはどちらも同じ変換ツール、同じ4:2:0の色差サブサンプリング条件です。品質の数値はこのツール内での設定で、別サービスの85と同じ見た目を意味しません。

保存条件	寸法	実測ファイル容量	今回確認したポイント
PNG	1200×600px	70,069バイト	比較の基準となる原本
可逆WebP	1200×600px	36,166バイト	RGBの復号画素が原本と一致
JPEG・品質85	1200×600px	72,745バイト	同寸法でも圧縮による差がある
JPEG・品質20	1200×600px	29,385バイト	赤文字や線の周囲の劣化を比較

今回の文字中心の素材では、強く圧縮したJPEGで文字の周りのにじみや境界の汚れが目立ちました。さらに、JPEG品質85の容量はPNGより大きくなっています。「PNGは重いから必ずJPEGへ」という判断も、この素材には当てはまりませんでした。写真が主役の画像では違う結果になり得るため、画像の種類ごとに比較する必要があります。

可逆WebPは今回、原本より軽く、RGB画素も一致しました。ただし、これは保存したファイル同士の検証です。WordPressへの登録後に最適化サービスや画像プロキシが再変換すれば、訪問者へ届く画像がそのまま可逆とは限りません。本記事の比較図も配信時に最適化処理が入るため、図だけを使った厳密な画素判定には向きません。

文字入り画像・写真・透明画像を同じ設定にしない

スクリーンショットや表のように、背景が単色で文字や細線が多い画像は、まずPNGや可逆WebPを比較候補にすると判断しやすくなります。写真は、細部の見え方を確認しながら非可逆の圧縮を使える場面があります。透明な背景が必要な画像では、透明部分が保たれる形式かも確認します。

大切なのは拡張子の優劣を決めることではなく、読者が必要とする情報を保ちつつ、無駄な容量を減らすことです。本文の文字が読めないほど圧縮するより、不要な余白を切る、画像を分ける、本文で説明するなど、別の軽量化方法を先に考えたほうがよい場合があります。

圧縮をやり直すときは、すでに強く圧縮したJPEGから再保存を繰り返さず、できるだけ加工前の原本から書き出します。比較用に新しいファイル名を付ければ、どの設定の画像を見ているか分かりやすくなります。元ファイルを上書きせず残すことは、失敗したときの戻しやすさにもつながります。

制作担当者向け：実際に読み込まれた画像を調べる

ここからはブラウザの開発者ツールを使います。慣れていない場合は無理にコードを変更せず、この節の確認項目を制作担当者へ渡してください。目的はサイトを修正することではなく、まず読み込まれた画像と表示寸法を記録することです。HTMLのsrcだけを見て「原本が使われている」と判断しないようにします。

currentSrc・表示幅・DPRを記録する

Chromeで問題の画像を右クリックして「検証」を開き、Elementsで対象のimg要素を選びます。背景画像のCSSではなく、画像を表すimgを選ぶ手順です。Consoleの利用に慣れている担当者は、内容を確認したうえで次の読み取り専用コードを実行すると、現在の状態を表にできます。サイトへの保存・送信・書き換えは行いません。

const image = $0;
if (!(image instanceof HTMLImageElement)) {
  console.info('Elementsで対象のimg要素を選んでください');
} else {
  const rect = image.getBoundingClientRect();
  console.table({
    src: image.getAttribute('src'),
    currentSrc: image.currentSrc,
    srcset: image.getAttribute('srcset'),
    sizes: image.getAttribute('sizes'),
    naturalWidth: image.naturalWidth,
    naturalHeight: image.naturalHeight,
    renderedWidth: rect.width,
    renderedHeight: rect.height,
    devicePixelRatio: window.devicePixelRatio
  });
}

ブラウザが貼り付けを警告した場合、警告を無視して無理に実行する必要はありません。Elementsの属性、画像の寸法表示、Networkの画像リクエストから同じ情報を調べられます。コードの意味を確認できない場合は、実行せず担当者に依頼してください。コンソールに認証情報や外部送信処理を貼り付ける手順は不要です。

currentSrcは、その画像要素でブラウザが選択している画像のURLを確認するためのプロパティです。srcが1200pxの原本URLでも、currentSrcが300pxの縮小版になることがあります。幅を切り替えたあとも大きい候補が再利用される場合があるので、比較する条件ごとにページを新しく開くなど、読み込み状態もそろえます。

naturalWidthを「ファイルの実画素幅」と決めつけない

naturalWidthは便利ですが、常に保存ファイルの横幅そのものではありません。密度補正されたCSSピクセルとしての固有幅を返すため、srcsetなどの条件によってファイルの画素数と異なることがあります。今回の正しいスマホ相当テストでは、1200pxのファイルを読み込んでいてもnaturalWidthは350でした。

この数字だけを見て「350pxしかないから足りない」と判定すると、正しい画像を誤って問題扱いしてしまいます。MDNのnaturalWidthの説明にも密度補正について記載があります。実際の画素幅を確認したい場合は、currentSrcの画像を取得してファイルの寸法を見る、または配信レスポンスを調べる方法と組み合わせます。

画像URLに「300×150」と書いてあれば手がかりになりますが、ファイル名だけでは断定できません。CDNや画像プロキシは、拡張子を変えずに内容を変換したり、クエリ文字列で幅を指定したりすることがあります。URLの見た目、実ファイルの寸法、レスポンスのContent-Typeを分けて記録します。

sizesを見直すときの小さな例

次は、本文の画像が最大600pxで、幅640px以下の画面では左右20pxずつ余白を取る、という仮のレイアウト例です。この条件なら、画像の実際の表示幅とsizesの説明をそろえられます。自分のテーマの余白やカラム幅が違うのに、そのまま数値だけコピーしないでください。

<img
  src="sample-600.png"
  srcset="sample-300.png 300w,
          sample-600.png 600w,
          sample-1200.png 1200w"
  sizes="(max-width: 640px) calc(100vw - 40px), 600px"
  width="1200" height="600"
  alt="設定名を示した説明画像"
  style="display:block;width:100%;max-width:600px;height:auto">

この例の親要素も、画面幅から左右の余白を引いた幅であることが前提です。sizesは画像を実際に配置するCSSの代わりではありません。幅指定の候補の仕組みと属性の条件はMDNのimg要素のリファレンスで確認できます。最近の出力ではsizesにautoが含まれる場合もあるため、文字列だけで良否を決めず、選択画像と表示結果を確認します。

本文では鮮明なのに、アイキャッチや記事一覧だけぼやける場合

記事本文、記事上部のアイキャッチ、トップページのカード、関連記事は、同じ画像を使っていても出力方法が別の場合があります。本文の画像ブロックを直しても、一覧カードが小さいサムネイルを指定していれば、その場所の表示は改善しません。どの場所で問題が起きているかを先に分けます。

同じアイキャッチについて、記事詳細では鮮明か、一覧では粗いか、PCとスマホのどちらで起こるかを見比べます。一覧だけで起こるなら、元画像を何度も差し替えるより、カード側が要求している画像サイズを調べます。カードが横幅400pxで表示されるのに150pxの画像だけを読み込んでいないか、という確認です。

テーマの開発では、画像IDと必要なサイズからHTMLを出力するwp_get_attachment_image()などが利用できます。ただし、関数を使えば自動的にどのレイアウトにも最適になるわけではありません。呼び出しているサイズ、生成されている候補、実際の表示幅を合わせて確認する必要があります。

画像サイズ設定を変えた後、古い画像にも反映される？

設定を変えれば、過去にアップロードした画像のファイルがすべてその場で作り直される、とは限りません。新しいサイズが必要なのに古い添付画像に存在しない場合は、サムネイルの再生成を検討します。ただし、最初から全メディアを対象にせず、バックアップを用意して検証環境で一枚だけ試すのが安全です。

WP-CLIを扱える担当者なら、wp media regenerateの公式説明で対象IDやサイズ指定を確認できます。対象を絞っても既存ファイルに影響する可能性がある操作です。権限、保存容量、外部ストレージ連携、配信キャッシュの扱いまで確認してから実行してください。本記事の検証では本番の既存メディアを再生成していません。

有料テーマの場合は、親テーマへ直接修正を加える前に、テーマ側の設定やサポート情報、子テーマでの対応を確認します。親テーマを直接書き換えると、更新で変更が失われる可能性があります。画像だけの問題に見えても、一覧全体の共通部品を変えるなら影響範囲は広くなります。

画像最適化・CDN・遅延読み込みが関係する場合

WordPressに保存されている画像と、訪問者へ届く画像の間に、最適化プラグイン、CDN、独自の画像プロキシが入る構成があります。この場合、原本や画像ブロックの設定だけでは説明できない変化が起こります。まず、currentSrcやNetworkで、画像がどのホスト名・URLから届いているかを確認します。

調べる項目は「要求している横幅」「変換後の形式」「圧縮品質」「端末ごとの分岐」「キャッシュ」です。ただし、すべてのサービスが同じ名前の設定を持つわけではありません。URLにw=300のような指定があっても、そのサービスで幅を意味するか確認します。推測だけでパラメーターを変更し、記事の画像URLへ一括反映しないでください。

最適化を疑うなら、まず一枚だけで比較する

可能なら検証環境で、同じ一枚について最適化前後を比較します。元画像を差し替えるのと同時に圧縮設定も変更すると、何が効いたか分からなくなります。先に寸法を固定し、圧縮品質だけを変える。次に品質を固定し、配信幅だけを変える、というように一項目ずつ確認します。

本番サイトで全プラグインを停止したり、CDNを丸ごと無効化したりすると、画質以外にも表示速度や機能へ影響する可能性があります。原因候補が絞れない場合は、構成を調べるところで止め、制作担当者やサービスのサポートへ記録を渡します。切り分けのために本番を壊す必要はありません。

最初だけぼやけるなら、読み込み完了後も確認する

画像の読み込み中に小さな仮画像を表示し、本画像が届いたら置き換える実装では、最初だけぼやけて見えることがあります。数秒後に鮮明になり、その後は安定するなら、保存画像の画質とは別の現象かもしれません。低速回線ではこの時間が長くなるため、通常回線と低速条件も区別して記録します。

読み込みが終わっても仮画像のままなら、本画像のリクエスト失敗やスクリプトの問題を確認します。403・404などの応答、画像形式への対応、遅延読み込み処理を調べる対象です。「ぼやけるから高解像度の画像を追加する」前に、そもそも本画像の取得が成功しているかを見るほうが早い場合があります。

なお、画像の内容自体が古い場合は、画質よりも更新反映の問題です。差し替え前の画像と差し替え後の画像を混同すると、品質設定を変えても改善したように見えません。どのファイルのどの版を確認しているかをそろえたうえで、必要なキャッシュ層だけを調べます。

文字入り画像は「高画質化」より、読める設計に直す

十分な画素数があっても、文字が小さすぎればスマホでは読みにくいままです。たとえば幅1200pxの画像を350pxで表示すると、画像内の24pxの文字は見かけ上およそ7px相当まで小さくなります。これは圧縮で文字がつぶれる問題とは別で、画像全体が縮小されることによる読みづらさです。

文字を大きくして書き出すだけでなく、説明を一枚へ詰め込みすぎていないかを見直します。設定画面全体を一枚で見せるより、「どこを開くか」の全体図と「何を変更するか」の拡大図に分けるほうが、読者が迷いにくい場合があります。赤枠だけでは対象が曖昧なら、短い番号や本文の手順と対応させます。

ただし、画像を何枚も増やせば必ず分かりやすくなるわけではありません。同じ画面をほぼ同じ状態で何度も載せると、必要な場所へたどり着きにくくなります。一枚ごとに「この画像で何を確認してほしいか」を決め、前後の本文で結論を伝えます。装飾用の写真で説明画像の不足を埋めないことも大切です。

重要な文字は本文にも残す

金額、日付、設定値、注意事項など、読み間違いを避けたい情報は本文にも書きます。画像だけに閉じ込めると、拡大しないと読めない、コピーできない、画像が読み込めないと分からない、といった不便が残ります。画像は位置関係を示し、本文は設定値と理由を伝える、という役割分担にすると読みやすくなります。

altは、画像の内容や役割を伝えるために付けます。「WordPress 画像 ぼやける 高画質」のように検索語を並べるのではなく、「画像ブロックの解像度でフルサイズを選択した設定画面」のように、その画像が伝える情報を説明します。長い表の全内容をaltへ詰め込むより、本文に表や説明を用意したほうが扱いやすくなります。

説明画像をクリックして大きく開けるようにする場合は、ログインしていない訪問者もリンク先を開けるかを確認します。管理者だけが見られる原本URLや、認証付きのCMS画像へ直接リンクしていないかにも注意します。拡大表示の導線があっても、通常表示で何の画像か分かることが前提です。

修正後の確認と、直らないときに渡す調査メモ

改善したかを判断するときは、変更前と同じページ、同じ画像、同じ画面幅で比較します。編集画面だけで判断せず、訪問者向けのページも確認してください。ログイン中とログアウト後でキャッシュや配信が違う構成では、管理者の画面だけ鮮明でも訪問者には古い状態が残ることがあります。

• 元画像の最小の文字や数字が、原本で読める。
• 記事本文・アイキャッチ・一覧カードを別々に確認した。
• PCとスマホ幅で、通常の倍率のまま必要な情報が読める。
• 実際に選ばれた画像の幅が、表示幅に対して不足していない。
• 圧縮後の文字・赤枠・細線に許容できないにじみがない。
• 画像を開くリンク先が、訪問者にも表示できる。
• 不要に大きい画像を全ページへ配信する変更になっていない。
• 問題が出た場合に元へ戻せるファイルと設定を残している。

自分で原因を絞れない場合は、次の項目を制作担当者へ渡すと調査を始めやすくなります。管理画面のパスワードを記事や公開の相談欄へ貼る必要はありません。画像URLに署名やトークンが含まれる場合は、公開せず安全な連絡手段で共有してください。

項目	記入例
問題の場所	記事本文の2枚目。表の右下の数字がにじむ
端末・ブラウザ	WindowsのChromeでは良好、スマホ幅の検証で粗い
元ファイル	1200×600pxのPNG。原本の数字は読める
表示条件	表示幅350 CSS px、DPR 2
読み込まれた画像	currentSrcのファイルは300×150px
実施した変更	一枚だけ解像度を中からフルサイズへ変更。改善なし
未確認	CDNの変換設定、実機Safariでの表示

このように事実と未確認を分ければ、元画像を再制作すべきか、テーマの出力を直すべきか、配信側を調べるべきかが伝わります。原因を断定するために設定を何度も変えるより、まず観察結果をそろえることが、修正の精度を上げます。

よくある疑問｜dpi・フルサイズ・画像枚数は関係する？

72dpiを300dpiにすればWeb画像は鮮明になる？

横幅・高さの画素数が同じままなら、dpiの数値だけを変えることを解決策にはしません。Webでの見え方を調べる際は、まずファイルのpx寸法と表示される大きさを確認します。印刷用の設定値と、ブラウザで何pxの画像を何pxに表示するかを混ぜないでください。書き出し時に画素数も変わったなら、その変化を別に確認します。

すべてフルサイズにしておけば安心？

一枚の切り分けには役立ちますが、全画像への一律変更は勧めません。小さなカードに巨大な原本を配信するなど、表示目的に対して過剰なデータになる可能性があります。まず必要な場所で十分なサイズが選ばれるようにし、その後に容量を調整します。フルサイズでも配信処理が挟まる構成では、実際の取得画像の確認が必要です。

CSSのimage-renderingで鮮明にできる？

画像の拡大時の描画方法を変えることはできますが、失われた文字や写真の細部を復元する方法ではありません。ピクセルアートの表現と、写真や説明画面を自然に見せる目的は別です。一般的な記事画像では、先に元画像の寸法と配信サイズを直します。輪郭を無理に硬くして数字の形を変えてしまわないように注意します。

画像を増やせばSEOで上位に行ける？

本記事の検証は画質と読みやすさの確認で、画像枚数と検索順位の因果関係を測ったものではありません。画像を増やすこと自体を目標にせず、手順の場所が分かる、比較結果が分かる、文字が読める、といった読者の助けになるかで判断します。読みやすい画像を用意しても、検索順位やアクセス数の上昇を保証することはできません。

動画から切り出した画像だけぼやける場合は？

WordPressへ入れる前から粗いなら、動画の解像度、圧縮、切り出したフレームを確認します。動きの途中のブレや、録画段階で失われた細部は、静止画を高画質形式で保存するだけでは戻りません。文字を見せたいなら、できるだけ静止している場面を選び、必要に応じて元のアプリ画面を直接撮り直します。

録画や配信そのものがカクついている場合は、本記事の画像配信の問題とは別です。OBSで高負荷の表示が出る場合は、次の関連記事で録画側の確認手順をまとめています。

まとめ：原本・配信画像・表示幅の順で、一枚ずつ直す

WordPressの画像がぼやけるときは、まず元画像が読めるかを確認し、次に画像ブロックの解像度を見ます。それでも直らない場合は、実際に届いた画像と表示幅の関係、圧縮、テーマや配信サービスの順に原因を分けてください。

今回の検証では、小さくした画像の再拡大と、強いJPEG圧縮で文字の見え方が変わりました。また、同じ元画像を用意していても、表示幅を誤って伝えるとスマホ相当の条件で小さな画像が選ばれました。「原本を大きくする」だけではなく、「必要な画像が読者へ届いているか」まで確認することが改善の近道です。

最初の作業は一枚で十分です。原本、設定、表示結果を記録し、一項目ずつ直して比較しましょう。改善方法が確認できてから同じ原因の画像へ広げれば、不要な容量増加や本番への影響を抑えながら修正を進められます。