画像SEO：ファイル名、altテキスト、サイズ圧縮、WebP形式
1. SEOにおける画像の2つの役割：画像検索とページ性能
多くのB2Bサイトは画像SEOを「ファイル名にキーワードを詰め込むこと」と捉えていますが、これは誤解です。画像はSEOにおいて実際に2つの役割を担います。1つはGoogle画像検索からの流入源、もう1つはページ読み込み性能の主要な負担です。
ここで直感に反する判断があります。ファイル名にキーワードを詰め込んでも、画像検索の順位への影響はごくわずかです。Googleは主にページの文脈、altテキスト、画像周辺のテキストから画像の主題を判断します。ファイル名をstainless-steel-flange-pn16.jpgとするのは良い習慣ですが、stainless-steel-flange-pn16-ansi-b16-5-industrial-flange.jpgとしても画像クリックがもう1回増えるわけではありません。
SEOに本当に影響するのは容量です。2MBの未圧縮の製品画像はページ全体の読み込みを遅らせ、LCPが1.8秒から3.5秒に落ち、順位とコンバージョン率の両方を損ないます。これはCore Web Vitalsで最もよくある減点ポイントです。
| 画像SEOの観点 | 順位への直接的な影響 | CTRとコンバージョンへの間接的な影響 |
|---|---|---|
| ファイル名 | ごく小さい | なし |
| altテキスト | 中程度（画像検索） | アクセシビリティと画像検索の両方に効果 |
| 容量と形式 | 大きい（LCPに影響） | 読み込みが速く直帰率が低い |
| サイズとsrcset | 中程度（モバイル体験） | モバイル流入のコンバージョン |
| 構造化データ ImageObject | 小さい | リッチリザルトでの表示 |
とメディア資産の管理との関係：あの記事では画像と動画の命名、圧縮、再利用の流れを扱い、本記事は画像のSEOにおける具体的な書き方に焦点を当てます。
2. ファイル名とaltテキスト：書くこと、書かないこと
ファイル名とaltテキストはしばしば混同されます。ファイル名はサーバーとクローラーが読み、altテキストはスクリーンリーダーと画像検索のインデックスが読みます。両者の書き方は異なります。
| 要素 | 正しい書き方 | 誤った書き方 |
|---|---|---|
| ファイル名 | stainless-flange-pn16.jpg | IMG_2038.jpg、DSC_0001.jpg |
| altテキスト | ステンレスフランジPN16圧力等級の製品画像 | flange flange flange stainless |
| 装飾画像のalt | alt=””（空） | alt=”区切り線”、alt=”image” |
| 長さ | altは8から15語 | altに長文を書く |
| 言語 | ページの言語と一致させる | 英語サイトに中国語の alt を書く |
alt テキストの核心ルールはこれだけです。スクリーンリーダーが目の見えないユーザーにこの画像を読み上げていると想像して、あなたならどう説明しますか。これがサイトのアクセシビリティ（WCAG）の要件であり、画像 SEO の正しいやり方でもあります。「ステンレスフランジ PN16 圧力等級 製品画像」と書けば十分で、「これはステンレス素材、PN16 圧力等級、ANSI B16.5 規格に適合するフランジ製品の画像で、石油化学プラントの配管に適しています」と書くのはキーワードの詰め込みです。
装飾的な画像（区切り線、背景パターン、アイコン）の alt は必ず空にします（alt=””）。「区切り線」とは書きません。スクリーンリーダーは空の alt なら読み飛ばしますが、「区切り線」と書いてあると読み上げてしまい、目の見えないユーザーにとってはノイズになります。
三、サイズ圧縮と WebP：しきい値とツール
圧縮は画像 SEO の中で最も費用対効果が高い施策です。2MB の未圧縮の製品画像を 200KB まで圧縮しても、見た目の違いはほとんど分かりません。読み込み時間は 4 秒から 0.4 秒に短縮されます。
| フォーマット | JPEG 比のファイルサイズ | おすすめの用途 | 互換性 |
|---|---|---|---|
| WebP 品質 80 | 25% から 35% 小さい | 2026 年の標準 | すべてのモダンブラウザが対応 |
| AVIF | 50% 小さい | 極端に遅い回線の場面 | 互換性がやや弱く、JPEG のフォールバックが必要 |
| JPEG 品質 80 | 基準 | フォールバック形式 | すべてのブラウザ |
| PNG | 2 倍から 5 倍大きい | 背景が透明な画像のみ | すべてのブラウザ |
実務で使うしきい値は 3 つです。製品メイン画像の幅は 1200px まで（それ以上は無駄）、本文中の画像の幅は 1600px まで、サムネイルの幅は 400px まで。品質は 80 で統一します。品質 90 と 80 は見た目の差がごくわずかなのに、ファイルサイズは倍違います。
ツール面では、WordPress サイトなら ShortPixel か Imagify で WebP に自動変換します。自社構築のサイトなら Sharp のコマンドラインで一括処理します。CDN 層でもリアルタイムのフォーマット変換が可能です。詳しくはCDNによるグローバル高速化の画像最適化戦略をご覧ください。
四、メイン画像と LCP：なぜメイン画像が SEO で最優先の画像なのか
Core Web Vitals の LCP（最大コンテンツ描画）指標は、80% のケースでページのファーストビューにある最初の画像が対象になります。この 1 枚を圧縮するほうが、ページ下部のサムネイル 10 枚を圧縮するよりも LCP への影響が大きいのです。
| メイン画像の最適化アクション | 期待できる効果 | 実装コスト |
|---|---|---|
| WebP に変換 | サイズ -30% | 低（プラグインで自動） |
| 品質 80 に圧縮 | サイズ -60% | 低 |
| width/height を明示 | CLS が低下 | 低（テンプレート修正） |
| fetchpriority=”high” | LCP -0.5 秒 | 低（属性を追加） |
| srcset で複数サイズ | モバイルの通信量を 50% 削減 | 中（複数サイズを生成） |
事例 1：製品詳細ページのメイン画像が幅 2400px、1.8MB の JPEG で、LCP は 3.8 秒でした。幅 1200px、WebP 品質 80、220KB に変更し、fetchpriority=”high” を追加したところ、LCP は 1.6 秒に短縮され、メインキーワードの順位は 14 位から 7 位に上がりました。
事例 2：ブログ記事のメイン画像が幅 1920px のカバー PNG で、サイズは 1.2MB でした。WebP に変換して 180KB にすると、読み込み時間は 2.4 秒から 0.6 秒に短縮され、モバイルの直帰率は 65% から 41% に下がりました。
多言語サイトの画像ローカライズでは、グラフに埋め込まれた文字も考慮する必要があります。詳しくは多言語サイトのグラフ処理画像内のテキストは alt では翻訳できず、専用の画像を書き出す必要があります。
五、よくある失敗と公開前チェックリスト
画像 SEO で最も多い五つの失敗は、どれもサイト全体のスキャン一回で見つかります。
| 誤り | 診断方法 | 修正アクション |
|---|---|---|
| alt がすべて空 | HTML をスキャンして alt=”” の割合を集計 | 商品画像とメイン画像には alt が必須 |
| 原図を圧縮していない | 1 枚 300KB 超の画像を数える | WebP に一括変換して品質 80 |
| width/height がない | Lighthouse のレポート | テンプレートに属性を追加して CLS を低減 |
| ファイル名が IMG_xxxx | uploads ディレクトリをスキャン | 意味のある名前へ一括リネーム |
| モダンな形式を使っていない | Content-Type を確認 | CDN 側で WebP 自動変換を有効化 |
画像の構造化データ（ImageObject）は B2B の商品ページでわずかな効果があり、次の項目と構造化データSchema同時に公開できます。ただし優先度は圧縮と alt より下です。まず容量を減らし、それからリッチリザルトを考えましょう。
六、画像 Sitemap、著作権フィールド、遅延読み込み
alt を書いて画像を圧縮すれば画像 SEO は終わりだと思われがちですが、実は三つ見落としがあります。一つ目は画像 Sitemap です。HTML のサイトマップとは別に、Google は sitemap 内で画像 URL、caption、title、license の各フィールドを個別に指定できます。商品画像やインフォグラフィックをページ内の img タグだけに任せて Google の巡回を待つと、新しい画像が画像検索に入るまでに二、三週間かかることがあります。画像 Sitemap を送信すれば、インデックスまでの期間は通常三〜五日に短縮されます。B2B の工業系サイトでは画像検索からの流入は自然流入の 5〜15% にとどまりますが、この流入は購買意欲が非常に強いので手放せません。
二つ目は著作権とライセンスのフィールドです。Schema の ImageObject には license、acquireLicensePage、creditText の三つを追加でき、その画像の著作権の帰属と商用利用の許諾を示せます。普段は誰も気にしませんが、AI の視覚モデルの学習に使われたとき、明確な著作権フィールドは後から権利を主張する根拠になります。逆に、有料ストックフォトの画像を使いながらページ上にライセンスを明記していなければ、原作者から申し立てを受けて削除されるリスクは常につきまといます。
三つ目は遅延読み込みと LCP 画像の衝突です。LCP のメイン画像は eager で読み込み、fetchpriority=”high” を付けます。本文中の他の画像だけに loading=”lazy” を使います。よくある失敗はサイト全体に一律で loading=”lazy” を付けてしまい、メイン画像まで遅延されて LCP がそのまま 1 秒遅くなるケースです。確認方法は Lighthouse の Largest Contentful Paint image was lazily loaded という警告を見ることです。出ていればメイン画像に誤って lazy が付いています。
| 補足項目 | やり方 | メリット |
|---|---|---|
| 画像 Sitemap | XML sitemap に画像 URL を記載 | 画像のインデックスが約二週間短縮 |
| 著作権フィールド | ImageObject に license を追加 | 商用利用の許諾を追跡可能に |
| メイン画像は eager | LCP 画像に lazy を付けない | LCP が悪化 |
| 構造化データ | 商品画像に ImageObject を追加 | リッチリザルトでの表示 |
多言語サイトの画像には、もうひとつ別の問題があります。画像内のテキストは alt では翻訳できません。情報図に中国語のスペックが書かれているなら、英語版では英語で注記した画像を新しく用意する必要があり、alt テキストで画像内の文字を翻訳できると期待してはいけません。図表のローカライズはコストがかかりますが、これを怠った多言語サイトは、英語版が母語のバイヤーから見れば機械翻訳の画像だと一目で分かり、信頼度が直接損なわれます。この部分の流れは次を参照してください。多言語サイトのグラフ処理。
FAQ よくある質問
画像のファイル名には必ずキーワードを入れるべきですか？
Alt テキストはどのくらいの長さが適切ですか？
WebP は JPEG よりどのくらい小さくなりますか？
画像のファイルサイズは何 KB までなら合格ですか？
画像は Google 画像検索のトラフィックにどれほど影響しますか？
WordPress で画像を自動最適化するプラグインはどれですか？
最後に
画像 SEO の優先順位は明確です。まず最初の画像を圧縮して LCP を解決し、次に alt テキストを書いてアクセシビリティと画像インデックスを解決し、最後にファイル名のセマンティック化です。この3ステップを終えれば、まだ2MBの原図をアップロードしている B2B サイトの80%をすでに超えています。
3ステップで進めます。今週はLighthouseでサイト全体の主要20ページを計測し、LCPが2.5秒を超えるページをリストアップします。来週はそのページのメイン画像を一括でWebPに変換し、250KB以内に圧縮して、width/heightとfetchpriorityを追加します。3週目はサイト全体でaltが空の商品画像を洗い出し、「8〜15語で画面を説明する」ルールに沿って書き足します。
覚えておきたい一言。画像SEOで大事なのはファイル名にキーワードを詰め込むことではなく、メイン画像を250KB以内に圧縮することです。速くなれば、順位もコンバージョンもついてきます。