広告について: このサイトには広告・アフィリエイトリンクを含むページがあります。このページでは、画像のサイズ調整に関する実験結果を中心にまとめ、未確認の成果や未使用ツールの体験談は書いていません。
AI画像をそのままWordPressへ入れると、見た目はきれいでも容量が大きくなりがちです。スマホで読む人には、本文が開くまでの待ち時間が増えるのが一番もったいないところ。なので今回は、同じ16:9画像を使って、横幅と保存形式だけ変えたらどれくらい軽くなるかを測りました。
先に結論です。ブログ本文なら、まずは横幅1200px前後のJPEGかWebPにして、細かい文字を読ませたい画像だけ大きめに残すのが扱いやすいです。今回の実験では、元PNGの54.8KBに対して、幅1200pxのJPEGは47.1KB、幅1200pxのWebPは17.7KBでした。
今回の同じ入力
元画像は、ブログのサムネイル改善記事を想定したローカル生成のサンプルです。実在の商品画像やサービス画面のスクリーンショットは使っていません。入力条件は以下の通りです。
- 元画像: 1600×900px PNG
- 用途: WordPressの記事本文とアイキャッチ候補
- 処理: リサイズ、JPEG保存、WebP保存、比較画像の作成
- 追加費用: 今回のローカル処理では未発生
- 実測時間: 画像生成と保存処理で{ELAPSED_SECONDS}秒
容量の比較
| 条件 | 形式 | 寸法 | 容量 |
|---|---|---|---|
| そのままPNG | PNG | 1600×900 | 54.8KB |
| 幅1200 JPEG q82 | JPEG | 1200×675 | 47.1KB |
| 幅1200 WebP q78 | WEBP | 1200×675 | 17.7KB |
| 幅800 JPEG q82 | JPEG | 800×450 | 26.5KB |
圧縮率だけ見るとWebPがかなり強いです。ただ、管理画面での扱いや、後から別ツールに渡すことまで考えると、JPEGもまだ無難です。自分用の手順としては、本文画像はJPEG、細かい比較画像や透明背景が必要な画像だけPNG/WebPを検討、という分け方がラクでした。
今回の元画像はフラットな図解に近いので、PNGでもかなり軽く出ました。写真っぽい画像や、ノイズの多い生成画像だと結果は変わります。だから「WebPなら必ず正解」「JPEGなら必ず軽い」と決め打ちするより、公開前に1枚だけでも容量を見て、表示に必要な解像度まで落とす方が失敗しにくいです。
WordPressに入れる前の手順
- 元画像を残したまま、投稿用コピーを作る。
- 本文に大きく表示しない画像は、横幅800〜1200pxへ縮小する。
- 写真風・サムネ風ならJPEG、透過が必要ならPNG、軽さ優先ならWebPで保存する。
- ファイル名に日本語や空白を入れすぎず、記事内容が分かる英数字にする。
- WordPressのメディアライブラリへ入れたら、代替テキストも一緒に入れる。
WordPress公式の画像ブロックでは、画像の表示やリンク設定を調整できます。メディアライブラリ側で画像を探しやすくしておくと、あとから差し替える時も迷いません。
アイキャッチ用と本文用で同じ画像を使う場合も、元画像とは別に投稿用の軽い版を作っておくと安心です。アイキャッチはSNSカードやトップページで大きく使われることがあるので、横長16:9なら1200px前後を残し、本文中の補足画像は800px程度まで落とす、という分け方から始めると管理しやすいです。
やらない方がいいこと
元画像を消して、軽くした画像だけ残すのはおすすめしません。後でアイキャッチを作り直したくなった時に、文字が潰れた画像しか残っていないと地味に困ります。もう一つ、容量だけを見て小さくしすぎるのも危ないです。比較表や操作画面の文字が読めなくなると、記事としての役割が弱くなります。
また、ツール名や料金表を画像の中に小さく入れる場合は、縮小後にスマホ幅で読めるかを見ます。読めないなら、画像内の文字を減らして、説明は本文に回した方が親切です。ブログ画像は作品としてのきれいさより、読者が迷わず内容を理解できることを優先した方が、結果的に記事全体が読みやすくなります。
WordPress 6.9以降なら、画像の「表示」と「容量」は分けて見る
2026年10月6日にWordPress公式情報を確認すると、WordPress 6.9ではギャラリーブロックに固定アスペクト比を設定できるようになり、LCP改善につながるパフォーマンス調整も案内されています。これは見た目を整える助けにはなりますが、アップロード前の画像容量を自動で最適化してくれる、という意味ではありません。
なので、この記事の手順はそのまま使えます。先に画像を軽くしてから、WordPress側では「本文画像」「アイキャッチ」「ギャラリー」で表示比率を整える、という順番が安全です。
- ギャラリーに複数枚を並べる: WordPress側の固定アスペクト比で見た目をそろえ、元画像は別に保管する。
- バナー風の見出し画像: 文字を画像に焼き込む前に、本文側で説明できないか確認する。小さい文字はスマホで潰れやすい。
- AI画像をアップロードできない: まずファイル形式、拡張子、保存場所、ファイル名を確認する。日本語や空白が原因と決めつけず、別名で保存したコピーも試す。
- 更新通知が出ている: WordPress 6.9.9はセキュリティ修正として案内されています。公開中サイトではバックアップを取ってから更新し、画像表示とメディアライブラリを確認します。
今回の追記は、WordPress公式ドキュメントと最近の公開Q&A・掲示板投稿を見て、AI画像ブログの実務チェックに落とし込んだものです。SNSや掲示板の反応数は需要や不具合の確定証拠とは扱っていません。
確認した公式情報: WordPress 6.9のリリース情報、WordPress 6.9.9のドキュメント、Media Add New screen、Image blockを確認しています。
広告リンクを入れる時の注意
画像制作ツールやサーバーを紹介する場合は、広告だと分かる表示を本文の見える位置に置きます。消費者庁は、広告であることを隠す表示をステルスマーケティングとして説明しています。楽天アフィリエイトなどを使う場合も、ガイドラインとステマ規制対応を確認してから掲載します。
クラウドでAI画像を作るか、自分のPCで作るか迷っている場合は、先にこちらの比較も見ると判断しやすいです。
※リンク先の料金・条件は変更されることがあります。申し込み前に公式ページで確認してください。
次に読む記事
今回の根拠
- WordPress.org Image block
- WordPress.org Media Library screen
- 消費者庁 ステルスマーケティングに関する情報
- 楽天アフィリエイトガイドライン
- 楽天アフィリエイト ステルスマーケティング規制対応
あわせて読みたい
広告：この記事には広告・アフィリエイトリンクを含みます。
YouTubeの画像投稿やショートにも使い回すなら、1枚で全部済ませない
2026年9月30日にYouTube公式ヘルプを確認すると、ブログ用の横長アイキャッチをそのままYouTubeへ流用するより、用途ごとに比率を分けて作る方が安全です。画像投稿は最大10枚まで選べ、JPG、PNG、GIF、WEBPを使えますが、フィードでは1:1が推奨されています。一方、ショート動画のカスタムサムネイルは9:16、通常動画のサムネイルは16:9が目安です。
- ブログのアイキャッチ：本文幅と表示速度を優先し、この記事の手順どおり横長を軽くする。
- YouTubeの画像投稿：スマホのフィードで見切れにくい1:1を別書き出しする。
- Shortsサムネ：9:16で作り、文字は上下端に寄せすぎない。
- 通常動画サムネ：16:9で作る。Shorts用とは別ファイルにする。
AI画像で最初から文字まで入れると、比率を変えたときに日本語が崩れたり、端の文字が切れたりしやすくなります。先に背景画像を作り、最後に文字を重ねる流れは AI画像の文字は後から入れたほうが楽かを比べた記事 で確認できます。背景を切り抜いて別サイズへ流用する場合は、髪の毛や透明な物が残るかの検証 も見ておくと、白い縁や透け方の失敗を避けやすくなります。
確認した公式情報： YouTube公式コミュニティの画像投稿案内、YouTubeヘルプの投稿作成、YouTube Studioヘルプのサムネイル仕様を確認しています。
今回の追記では、YouTube画像投稿そのものの再生数や収益は未取得です。反応数を成果として扱わず、ブログ側では画像容量、表示速度、内部リンク、広告表示を分けて確認します。
追記：画像から見つかった流入はSearch Consoleで別に見る
2026年9月24日に、Google Search Consoleへ Web: multimodal の検索タイプが追加されました。Google Lens、Circle to Search、画像アップロード、Chromeの「この画像を検索」など、画像をきっかけにしたWeb検索の見え方を確認するための項目です。
AI画像をブログで使う場合、容量を小さくするだけでなく、どのページが画像経由で見つかったかも後から確認できるようになりました。ただし、これは「画像のどの部分で検索されたか」まで分かる機能ではありません。Googleのヘルプでは、マルチモーダル検索は画像を使うため、通常の検索語句データは利用できないと説明されています。まずはページ別に見て、画像・見出し・本文の関係を点検する使い方が現実的です。
ブログ画像で見る順番
- Search Consoleの検索パフォーマンスで、検索タイプを Web: multimodal に切り替える。
- クリック数や表示回数がある場合は、ページ別でどの記事に出ているかを見る。
- 対象ページのアイキャッチ、本文中画像、alt、画像まわりの説明文が、記事内容とずれていないか確認する。
- 従来の「画像」検索タイプとは混ぜず、画像検索タブからの流入と、画像を使ったWeb検索の流入を分けて記録する。
今回このサイトのSearch Console実測値は取得できていません。なので、表示回数やクリックが0だったとは書きません。実測が取れるようになったら、この記事ではまず 文字を後から入れたサムネイル記事 と 背景除去の検証記事 をページ別に見て、画像経由の発見があるか確認します。
出典：Google Search Central Blog、Search Console Help、Search Console performance dimensions