4-3 画像 SEO と alt 属性の最適化

なぜ画像 SEO が重要なのか

画像はテキストの「補足」ではなく、SEO の主役のひとつです。とくに 2026 年現在は、Google 画像検索からの流入に加えて、Core Web Vitals のスコア、AI Overviews での引用、SNS シェア時のサムネイル品質まで、すべてが画像最適化に左右されます。画像が重い・説明文がない・ファイル名が雑、というだけで、本来取れたはずの流入を毎日取りこぼしている状態になります。

画像 SEO を整えることで得られる効果は次の通りです。

1. Google 画像検索からの流入 「商品名 画像」「料理名 レシピ」のような検索では、画像検索結果が上位に表示されます。とくに EC・レシピ・旅行・不動産・美容のジャンルは、画像検索経由のセッションが Web 検索の 20〜40% に達することもあります。

2. Core Web Vitals (LCP) の改善 LCP (Largest Contentful Paint) はファーストビューで一番大きな要素の表示時間を測る指標で、その「一番大きな要素」はほぼ常にメイン画像です。画像を軽くするとそのまま LCP が改善し、検索順位にも反映されます。

3. AI Overviews・Perplexity での引用 生成 AI 検索は、テキストと一緒に画像も引用します。alt テキストと ImageObject 構造化データが整っているサイトの画像は、AI Overviews の回答カードに採用されやすくなります。

4. 表示のガタつき (CLS) の防止 width / height を指定していない画像は、読み込み時にレイアウトを押し下げるため CLS が悪化します。これは LCP と並ぶ Core Web Vitals の柱です。

5. アクセシビリティ 視覚障害のあるユーザーはスクリーンリーダーで Web を閲覧します。alt がなければ「画像」としか読まれず、コンテンツが伝わりません。

ファイル名は「内容を 5 単語で説明したもの」にする

カメラやスマホで撮った画像は IMG_1234.jpg DSC_0042.HEIC のような名前で保存されます。これは Google に何の手がかりも与えない「無」のファイル名です。

ファイル名のベストプラクティスは次の通りです。

命名規則は次の 5 つを守ります。

1. 小文字のみを使う
2. 単語の区切りはハイフン(-)、アンダースコア (_) は使わない
3. 半角英数字のみ、日本語・全角スペースは避ける
4. 3〜6 単語で内容を説明する
5. ブランド名・場所・モデル番号など、検索される語を含める

alt 属性は「画像が消えたとき何と書いてあれば伝わるか」

alt 属性 (代替テキスト) はスクリーンリーダーが読み上げる文字列であり、Google が画像内容を理解する最大の手がかりでもあります。

alt の書き方は次の通りです。

ただし、装飾目的の画像 (背景の模様・区切り線など) は意図的に alt="" を空にします。スクリーンリーダーがスキップしてくれるためです。「装飾なら空」「コンテンツなら説明」、この線引きが重要です。

画像フォーマットの使い分け

2026 年現在、画像フォーマットの選択は次の通りです。

JPEG / PNG はもはや「fallback 用」と割り切ってよく、メインは AVIF / WebP に揃えます。Claude Code に一括変換を任せると一瞬で終わります。

> public/images 以下の .jpg と .png をすべて WebP と AVIF に変換して。
> 元ファイルは残して、HTML から参照している箇所も <picture> タグに置き換えて。
> AVIF を優先、WebP を fallback、最後に元の JPEG を残す形にして。

サイズ最適化、必要な解像度だけ配信する

iPhone で撮った 4032×3024 ピクセルの写真をそのまま Web に載せると、表示は 800px なのに 5MB ダウンロードさせる、という事故が起きます。これは LCP を即死させ、モバイル回線のユーザーを離脱させます。

サイズ最適化の手順は次の通りです。

手動でやるなら TinyPNG / Squoosh / ImageOptim を使いますが、Claude Code に頼めばコマンド一発です。

> public/images の画像をすべて最大幅 1600px にリサイズして、AVIF と WebP に変換。
> 画質は AVIF=50, WebP=75 で。元ファイルは backup/ に退避して。

responsive images で転送量を 1/4 にする

srcset と sizes を使うと、スマホには小さい画像、デスクトップには大きい画像、を自動で出し分けられます。

<img
  src="hero-1600.webp"
  srcset="
    hero-400.webp 400w,
    hero-800.webp 800w,
    hero-1200.webp 1200w,
    hero-1600.webp 1600w
  "
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 80vw, 1200px"
  alt="渋谷のオフィスで会議をするチーム"
  width="1600"
  height="900"
  loading="lazy"
/>

これだけでモバイルユーザーへの転送量が 1/4 程度になります。

lazy loading でファーストビューを軽くする

loading="lazy" 属性を付けると、画面外の画像は実際にスクロールされるまで読み込まれません。長いページで画像が 30 枚あっても、最初は 2〜3 枚しか読み込まれない、という状態にできます。

<!-- ファーストビューの画像 (LCP 候補) -->
<img src="hero.avif" alt="..." loading="eager" fetchpriority="high">

<!-- スクロール先の画像 -->
<img src="below.avif" alt="..." loading="lazy">

注意点は次の通りです。

• ファーストビューの画像に lazy を付けない。LCP が遅くなります
• ファーストビューの主要画像には fetchpriority="high" を付けて優先読み込み
• それ以外は全部 lazy で OK

ImageObject 構造化データ

Google 画像検索のリッチリザルト (ライセンス情報・撮影者・キャプション) を表示させるには、JSON-LD で ImageObject を埋め込みます。これは特に Google から画像を「商用利用可能」「クレジット明示」とラベル付けしてもらうために重要です。フォトグラファー・メディア・EC サイトでは画像盗用の抑止にもつながり、ライセンス販売の導線にもなります。

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "ImageObject",
  "contentUrl": "https://example.com/images/tokyo-skytree.webp",
  "license": "https://example.com/license",
  "acquireLicensePage": "https://example.com/how-to-license",
  "creditText": "Photo by Naoki Hirahara",
  "creator": {
    "@type": "Person",
    "name": "Naoki Hirahara"
  },
  "copyrightNotice": "BlueAI 2026"
}
</script>

レシピ・商品・記事ページでは、Article / Product / Recipe スキーマの image プロパティに上記の ImageObject を入れ子で入れると、AI Overviews と画像検索の両方で引用されやすくなります。

画像 CDN という選択肢

毎回手動でリサイズ・変換するのが面倒なら、画像 CDN を使う方法もあります。Cloudflare Images / Imgix / Cloudinary / Vercel Image Optimization などが代表例で、元画像をアップロードするだけで、デバイスごとの解像度・フォーマット・品質を URL パラメータだけで取り出せます。

<!-- Cloudflare Images の例 -->
<img
  src="https://imagedelivery.net/<account>/<image-id>/w=800,format=auto,quality=80"
  alt="渋谷オフィスの会議風景"
  width="800"
  height="450"
  loading="lazy"
/>

format=auto を指定すると、AVIF 対応ブラウザには AVIF、それ以外には WebP、と自動で出し分けてくれます。月間 10 万 PV 程度までなら数ドルで運用できるので、画像が多いサイトは検討する価値があります。

Claude Code に頼む実践ワーク

画像最適化は手作業だと丸 1 日かかりますが、Claude Code なら数分で終わります。実際の指示例は次の通りです。

# 1. サイト全体の画像 SEO 監査
> /seo images https://あなたのサイト.com

# 2. alt が空の画像をリストアップして、内容に合った説明を提案
> public/ 以下の HTML を走査して、alt="" または alt 属性なしの img タグを全部出して。
> 画像ファイル名と周辺テキストから推測した alt 案を 3 つずつ提案して。

# 3. ファイル名の一括リネーム
> public/images の IMG_*.jpg を、画像内容に合った英語ハイフン区切りの名前に変更して。
> HTML / MDX / TSX 内の参照も全部追従して書き換えて。

# 4. AVIF + WebP + JPEG の三段 picture タグ生成
> components/HeroImage.tsx を作って、<picture> で AVIF → WebP → JPEG の順で
> srcset 配信するコンポーネントにして。width / height / loading は props で受ける。

# 5. ImageObject JSON-LD を全記事に挿入
> content/blog/*.mdx のヒーロー画像に対して ImageObject の JSON-LD を生成して、
> frontmatter の image / author / license から値を埋めて。

# 6. Lighthouse スコアでビフォーアフター
> bunx lighthouse https://localhost:3000 で計測して、画像最適化前後のスコアを比較表にして。

やってみよう、画像の問題を一括チェック

まずは現状把握から始めましょう。

> /seo images https://あなたのサイト.com

# チェックされる項目
# - alt テキスト (画像の説明文) があるか
# - ファイルサイズが大きすぎないか (目安 200KB 以下)
# - 最新の画像形式 (WebP / AVIF) を使っているか
# - 横幅・高さが HTML で指定されているか
# - 遅延読み込み (lazy loading) が設定されているか
# - ファイル名が IMG_xxx などの無意味な名前になっていないか
# - ImageObject 構造化データが含まれているか

効果測定、本当に速くなったかを数字で確認する

最後に、画像最適化の効果を数字で見ましょう。「やった気になる」が一番もったいないため、必ず計測します。

確認する 4 つの指標は次の通りです。

1. PageSpeed Insights の LCP — モバイル / デスクトップそれぞれを pagespeed.web.dev で計測。2.5 秒以下を目標
2. Lighthouse の Performance スコア — Chrome DevTools から実行。90 点以上が目標
3. Search Console の Core Web Vitals レポート — 実ユーザーのデータ。「良好」URL を増やす
4. Google Search Console の画像検索流入 — Performance → Search Type を Image にしてクリック数推移を見る

> bunx lighthouse https://example.com --only-categories=performance --view
> bunx unlighthouse --site https://example.com

unlighthouse を使うとサイト全体のページを一気にスキャンして、画像が原因で遅いページのランキングを出してくれます。改善対象が一目でわかります。

<Quiz question="画像の SEO で最も重要な要素は？" options={["alt テキスト (画像の説明文)","画像のファイルサイズ","画像の解像度"]} answer={0} />

<Quiz question="ファーストビュー (画面を開いてすぐ見える位置) のメイン画像に付けるべき属性はどれか？" options={["loading="lazy"","loading="eager" fetchpriority="high"","属性は何もつけなくてよい"]} answer={1} />

<Checklist id="seo-ch4" items={["構造化データ (JSON-LD) の仕組みを理解した","自分のサイトにスキーマを追加 (または確認) した","画像の alt テキストとファイルサイズを最適化した","画像を WebP / AVIF に変換した","ファイル名を内容がわかる英語ハイフン区切りに変更した","ファーストビュー以外の画像に loading="lazy" を設定した","width / height を全画像に指定して CLS をゼロにした"]} />

次のステップ

• 5-1: SEO 戦略の立て方｜優先順位の決め方 — 次章の入口。技術と表示の整備が終わったら、戦略レイヤーで施策の優先順位を組み立てます
• 4-2: JSON-LD スキーマを Claude Code で自動生成する — 画像と並ぶリッチリザルト要素、構造化データの実装をもう一度確認できます
• 2-3: モバイル SEO と HTTPS 対応チェック — 画像の最適化と同じく Core Web Vitals に効くテクニカル要件をおさらいできます