さくらのウェブアクセラレータの費用を抑える近道は、「CDN から配信する転送量そのものを減らす」ことと、「キャッシュヒット率を上げてオリジンへの問い合わせを減らす」ことの2つです。この記事では、WordPress サイトでこの2点を実践する手順を、どこを見て判断し、何を変えればよいかという順で説明します。導入後のエラーや表示崩れへの対処は別のテーマなので、ここでは費用に関わる設定に絞ります。
料金の単価や無料分の有無、課金の単位は改定されることがあるため、本記事では金額を扱いません。最新の課金体系は（2026年10月現在）さくらインターネットの公式サイトとコントロールパネルで確認してください。
費用が決まる仕組みを押さえる
ウェブアクセラレータは、利用者に届けたデータ量に応じて課金される従量制が基本です。つまり、同じアクセス数でも、1ページあたりの重さが半分になれば費用もおおむね半分に近づきます。ここで誤解しやすいのは「キャッシュヒット率を上げれば CDN の費用が下がる」という考え方です。ヒット率は主にオリジンサーバーの負荷と応答速度に効く指標で、利用者に届ける量が同じなら CDN の転送量は変わりません。
整理すると、費用最適化の打ち手は次の3種類に分かれます。
- 届けるバイト数を減らす：画像の圧縮、テキストの圧縮、不要なファイルの削除
- CDN に載せる範囲を選ぶ：本当に CDN が必要なファイルだけを配信する
- 無駄なリクエストを減らす：ボットやホットリンク、キャッシュの取りこぼしによる余計な転送を抑える
手順1：現状の転送量の内訳を把握する
最初に、何が転送量を占めているかを調べます。コントロールパネルの利用状況やアクセス統計で月ごとの転送量を確認し、オリジン側のアクセスログからファイル種類ごとの合計サイズを集計すると、手を付ける順番が見えてきます。
# Nginx の標準的な combined 形式のログを想定した例（ログ形式に合わせて列番号を調整）
# 拡張子ごとの転送バイト数の合計を多い順に表示
awk '{split($7, a, "?"); n = split(a[1], p, "."); ext = (n > 1) ? p[n] : "(none)"; bytes[ext] += $10}
END {for (e in bytes) printf "%s\t%.1f MB\n", e, bytes[e] / 1048576}' /var/log/nginx/access.log \
| sort -t$'\t' -k2 -nr | head -20多くの WordPress サイトでは、画像（jpg・png）が上位を占めます。動画や PDF、ZIP などの大きなファイルが上位にある場合は、それらの扱いが費用を大きく左右します。
手順2：画像を軽くする
転送量のほとんどが画像なら、ここが最も効果の大きい対策です。
- アップロード前のリサイズ：表示幅が 1,200px 程度のテーマに 4,000px の写真をそのまま載せていないか確認します。WordPress は大きな画像をアップロードすると縮小版を作りますが、本文で原寸を指定していれば原寸が配信されます。
- WebP や AVIF の利用：WordPress は 5.8 で WebP、6.5 で AVIF のアップロードに対応しました（サーバーの画像ライブラリが対応している場合）。変換を自動化するなら、EWWW Image Optimizer や Converter for Media などの保守されているプラグインを検討します。変換後のファイルの配信方法（
<picture>要素か、サーバーでの出し分けか）によって、CDN 側のキャッシュの扱いが変わる点に注意してください。 - srcset を活かす：テーマで
wp_get_attachment_image()を使って画像を出力すると、srcsetとsizesが付き、スマートフォンには小さい画像が選ばれます。直接<img src>を書いているテンプレートがあれば置き換えを検討します。
画像を一括で再圧縮・変換する前には、wp-content/uploads のバックアップを取り、ステージング環境で表示を確認してから本番に適用します。
手順3：テキストファイルを圧縮して配信する
HTML・CSS・JS・SVG は gzip や Brotli で圧縮すると数分の一になります。オリジンが圧縮済みのレスポンスを返し、Vary: Accept-Encoding を付けていれば、ウェブアクセラレータを経由しても圧縮された状態で届くのが一般的です。CDN 側で圧縮が行われるかどうかはサービスの仕様によるため、次のように確認します。
curl -sI -H "Accept-Encoding: gzip, br" https://www.example.com/wp-content/themes/mytheme/style.css \
| grep -iE "content-encoding|vary|cache-control"Content-Encoding が返らない場合は、オリジンの Web サーバーで圧縮設定を有効にします。
手順4：CDNに載せる範囲を見直す
すべてを CDN 経由にすることが最適とは限りません。
- 大容量ファイル：会員向けの動画や大きな配布ファイルは、配信回数が少なくても転送量を押し上げます。動画は専用の配信サービスや外部の動画プラットフォームに任せる、ダウンロードはオリジン直にする、といった分け方を検討します。
- キャッシュされない HTML：ログイン中のページやフォームの確認画面など、キャッシュできない応答を CDN 経由にしても、オリジンとの往復が増えるだけで高速化の効果は限られます。
- 静的ファイル専用ホスト：画像・CSS・JS だけを CDN 用のサブドメインで配信する構成にすると、何が CDN を通っているかが明確になり、費用の見通しも立てやすくなります。
手順5：キャッシュの取りこぼしを減らす
ウェブアクセラレータは、オリジンが返す Cache-Control などのヘッダーに従ってキャッシュするかどうかを決める方式です。ヘッダーがない、private や no-store が付いている、Set-Cookie を伴うといった応答はキャッシュされにくく、毎回オリジンに問い合わせが行きます。CDN の転送量は変わらなくても、オリジン側のサーバー費用や負荷に響くため、あわせて見直します。
- バージョン付き URL で配信される CSS・JS・画像には、長めの
max-ageを設定する - 同じファイルに異なるクエリ文字列が付いて別物として扱われていないか、ログで確認する
- 静的ファイルに不要な
Set-Cookieが付いていないか、curl -sIで確認する
手順6：不要なアクセスを減らす
- ホットリンク：他サイトが自サイトの画像を直接表示していると、その分の転送量も自分の費用になります。リファラーごとの転送量をログで確認し、必要であればオリジン側で制限します。
- 過剰なクローラー：一部のボットが大量の画像を取得していることがあります。ユーザーエージェント別の転送量を集計し、
robots.txtやサーバー側の制限で対処します。正規の検索エンジンのクローラーまで止めないよう注意してください。
効果を測って続ける
対策ごとに、翌月の転送量とページあたりの平均転送量を比べます。アクセス数が増えると総転送量も増えるので、「総量」ではなく「1ページビューあたり」で比較すると、対策の効果を正しく判断できます。
まとめ
- 費用は主に利用者へ届ける転送量で決まるため、画像の軽量化と圧縮が最も効く
- キャッシュヒット率は主にオリジン負荷と速度に効く指標で、CDN の転送量削減とは分けて考える
- 大容量ファイルやキャッシュできない応答は、CDN に載せるべきかを見直す
- ホットリンクや過剰なクローラーによる無駄な転送をログで見つけて抑える
- 料金体系は改定されるため、公式情報で最新の課金単位を確認する