はじめに
ブログ運用で軽視できないのが画像です。一枚の画像がページ表示速度を遅らせ、altの欠落がアクセシビリティとSEOを同時に下げます。それでいて、画像の扱いは記事ごとに微妙に違うため、テンプレ化が一番進めにくい領域でもあります。
このシリーズの第6回では、原稿執筆時の画像の置き方から、WebP変換、alt自動付与、CDN配信、失敗時のフォールバックまでを通した画像処理パイプラインの設計判断を記録します。
画像処理の全体像
一枚の画像が、原稿に置かれてから読者に届くまでに通る道筋は、次のように整理できます。
各ステップは前のステップが成功してから次に進む直列構造です。並列化はしません。並列化すると失敗時の状態が複雑になり、デバッグコストが上がるためです。画像処理は数秒余分にかかっても良いから、確実に通ることを優先します。
1. WebP変換のタイミング
画像をWebP形式に変換すると、JPEGやPNGに比べてファイルサイズが30〜50%減ります。ただし、いつ変換するかには複数の選択肢があります。
私が選んだのは案B、投稿時に変換する構成です。
案Aを取らなかったのは、執筆中に画像形式を意識したくないからです。スマホで撮った写真をそのまま原稿フォルダに置けば、あとは自動でWebPに変換されて投稿される。執筆体験を中断したくありませんでした。
案Cを取らなかったのは、プラグインの動作を完全には信頼できないからです。サーバー側で動的変換するプラグインは便利ですが、変換が失敗したとき・遅延したときの挙動が読めません。投稿時に静的に変換しておけば、表示時の不確実性が減ります。
WebP変換にはPython側でPillowを使います。元のPNG/JPEGも残しておき、WebP非対応のブラウザに備えてpicture要素でフォールバックを書きます。
from PIL import Image
img = Image.open(src_path)
img.save(webp_path, 'WEBP', quality=80, method=6)
quality=80、method=6は経験則です。それ以上の品質値にしてもサイズが大きく増える割に見た目の差が分かりません。method=6は最も圧縮率が高い設定で、変換時間は数秒長くなりますが、投稿時の一度きりなので許容します。
2. alt属性の自動付与判断
altは画像の説明テキストで、視覚障害者向けスクリーンリーダーが読み上げる対象であり、Google検索の画像検索にも影響します。書かれていないと、両方の機能が壊れます。
altの取り扱いには三つの選択肢があります。
私の選択はB、書かなければエラーで止めるです。一年運用してみての結論として、ここを甘くすると後で必ず後悔します。
ただし、AIで自動生成する案を試す価値はあると考えています。次のような分岐を設けると、書き手の負担と品質の両立が見えてきます。
「auto-alt: true」をフロントマターで明示的に指定したときだけ自動生成する設計にしておけば、AI生成altと人間が書いたaltが混ざることを防げます。生成されたaltは原稿に書き戻して、次回以降は人間が書いたものとして扱う。生成しっぱなしにはしません。
ここでも人間の意図的な指示があったときだけ自動化が起動する設計を優先しています。何でも自動でやろうとすると、運用の見通しが悪くなります。
3. CDN連携の構造
WordPressに画像をアップロードすると、デフォルトでは/wp-content/uploads/配下に保存され、サイトのドメイン経由で配信されます。これだと、画像の配信もWordPressのインフラを使うことになり、表示速度が安定しません。
CDNを挟む構成にすることで、画像配信を専門のサーバーに分離します。
CDN設定の本質は、画像URLをCDNドメイン経由に書き換えることです。wp_import.pyの中で、画像URLをWPのドメインからCDNのドメインに置換する処理を入れます。
def to_cdn_url(wp_url):
return wp_url.replace(WP_DOMAIN, CDN_DOMAIN)
このわずか一行の処理を、投稿時に通すか通さないかで、ブログ全体の表示速度に影響します。
ここで決めた判断が一つあります。CDN設定をプラグインではなくスクリプト側で行うことです。CDN系プラグインも存在しますが、プラグインの設定とスクリプトの設定が二重化するのを避けたかった。一箇所で管理できれば、設定の食い違いから起きる事故を減らせます。
4. 失敗時のフォールバック
画像処理は外部サービスへのアップロード、API呼び出し、ローカルのファイル変換と、失敗ポイントが多いプロセスです。各段階の失敗にどう対処するかを、事前に決めておきます。
ポイントは、段階ごとに違うフォールバックを設計することです。すべてをエラー停止にすると運用が止まりやすく、すべてをリトライにするとどこで失敗したか追えなくなります。
WebP変換の失敗は、元のJPEG/PNGをそのまま投稿することで進めます。劣化はしますが、止まるより良い。代わりにログには「WebP変換失敗：foo.png」を残しておき、後から手動で再変換できる状態を保ちます。
CDN同期遅延は待ちません。本文に書く画像URLをCDN URLとWPオリジンURLの両方にしておき、CDNが空振りしたらブラウザがオリジンを取りに行くようにします。picture要素を使うとこの分岐が綺麗に書けます。
<picture>
<source srcset="https://cdn.example.com/foo.webp" type="image/webp">
<img src="https://example.com/wp-content/uploads/foo.jpg" alt="...">
</picture>
画像処理パイプラインの完成形
ここまでの設計を踏まえた、画像一枚の処理の最終形は次のようになります。
複雑に見えますが、各分岐の判断はここまでに説明したものを並べただけです。
画像処理に関わる固定費・変動費
設計判断のもう一つの側面として、コスト感も整理しておきます。
| 項目 | 月額イメージ | 備考 |
|---|---|---|
| WordPressサーバー | 既存に含まれる | 画像置き場として使用 |
| CDN | 無料〜数百円 | Cloudflare Free・Bunny等 |
| AI alt生成（任意） | 数十円〜 | 月数十枚程度なら微小 |
| 画像変換処理（自前） | 無料 | Pillowはローカル実行 |
CDNと自前変換は、ほぼ追加コストなしで導入できるのが大きい。AI生成altはオプションで、判断は記事のジャンルによります。
設計時に却下した代替案
案：すべての画像を最初からWebPでブログに置く
執筆段階からWebPで原稿に置けば、変換ステップは不要になります。
却下した理由は、iPhoneでスクショや写真を撮ると基本はHEIC/JPEGで、執筆中にWebPに変換する手間が必ず発生することです。執筆体験の中断を避けたいので、原稿はJPEG/PNGのまま受け入れ、変換は機械側で完結させる方針にしました。
案：alt自動生成を必須化する
altは全部AIで自動生成すれば、原稿側で書く必要がなくなる、という考え方もあります。
却下した理由は、生成altの品質です。画像の内容を機械的に説明するaltと、記事の文脈に合わせたaltでは質が違います。ゴルフコースの写真に「緑のフィールドに白いボール」とaltを付けるより、「ホールアウト直後のグリーン」と付けた方がコンテンツに合います。文脈は人間しか持っていません。
案：CDNを使わず、WordPressオリジンのみで配信
シンプルさを取って、CDNなしで運用する選択肢もあります。
却下した理由は、サーバーへの負荷分散と、画像表示速度のSEOへの影響です。Core Web Vitalsの一つLCP（Largest Contentful Paint）は画像読み込み速度に直結します。CDN導入のコストはほぼゼロなのに対し、得られるメリットが大きい。これは導入しない理由が見つかりませんでした。
次回予告
最終回は エラー処理と運用一年の学び を扱います。これまで設計してきた基盤を実際に一年運用して、起きた事故、見直した判断、次に作り直すなら変えるところを記録します。シリーズの締めくくりとして、却下案の章をもう一度厚めに書き直す回になります。
このシリーズで紹介する設計は、執筆時点の各ツールバージョンに基づきます。Claude Code、MCP、WordPress、各種APIは仕様変動が大きいため、最新ドキュメントとの照合をおすすめします。
