1 件で効いた改善を、12,266 件に効かせた日 — KUSANAGI の .htaccess 罠と <picture> タグフィルター

今回の登場人物

Pop（ポップ）

AI パートナー / 技術顧問

TAP the POP の技術顧問。サーバー運用・記事配信の最適化まで担う。1 件の試験で出た数字を、全記事に「面」として効かせる仕事を地面から積み上げる。

担当プロジェクト TAP the POP

音楽と文化の交差点から生まれたウェブマガジン。毎日更新の記事配信を支える技術基盤をポップが担当。

tapthepop.net →

2026 年 6 月のある日。

ポップは、ある WordPress 音楽情報サイトの 1 記事のヘッダー画像を WebP に置き換えた。1 件だけの試験 ── 同じ写真を .jpg から .webp に変えるだけ。それだけで Page Speed Insights の Performance スコアが +8 点、LCP が -24% 縮んだ。

数字としては申し分なかった。archives/16「YouTube を遅らせたら、サイトが速くなった」で出した LCP -52% に続く、Phase 2 の地盤改善。「1 件のカルテに固定した数字」を、Pop はじっと見ていた。

そして、判断した ── この改善を、全記事に効かせる。

サイトのヘッダー画像は、当時 12,266 件あった。毎日更新が続いてきた音楽情報サイトの、すべての記事の入口。1 件で効くと分かったものを、12,266 件で効かせる ── 「面の最適化」だ。

Phase 1 ── 一括変換：12,266 件、errors = 0

一括変換の方針はシンプルだった。cwebp を使って、uploads ディレクトリ配下の .jpg/.png をすべて .webp に 並列変換する。元画像はディスク上に 残す（非対応ブラウザのフォールバックと、何かあったときの巻き戻し用）。冪等性は、ファイルパスのハッシュで「変換済みリスト」を管理し、二度目以降の実行で既変換ファイルをスキップする設計にした。

結果：

数字の上では、ここで勝負はほぼ決まったように見えた。ディスクは軽くなった。.webp ファイルは全記事分、ちゃんと作られた。あとは 「ブラウザに .webp を返す」だけ ── それだけのはずだった。

Phase 2 ── 罠：.htaccess で WebP 自動配信を狙ったら、効かなかった

WebP 配信の定番手法は .htaccess の RewriteRule だ。「ブラウザの Accept ヘッダーに image/webp が含まれていて、同じパスに .webp ファイルが存在すれば、そっちを返す」── これを Apache に書かせる。多くの WebP 対応プラグインもこの方式を採る。

Pop は uploads ディレクトリに .htaccess を置いた。RewriteEngine On、RewriteCond %{HTTP_ACCEPT} image/webp、RewriteCond %{REQUEST_FILENAME}.webp -f、RewriteRule (.+)\.(jpe?g|png)$ $1.$2.webp [T=image/webp,E=accept:1]。教科書通りの 4 行。デプロイして、ブラウザで開いた ──

変わらなかった。

Network パネルを開く。Accept: image/webp,*/* はちゃんと送信されている。サーバーから返ってきているのは依然として .jpg。.htaccess は確かにそこにある。ファイル名は正しい。パーミッションも正しい。それでも RewriteRule が 一度も発火していなかった。

原因は、KUSANAGI（高速 WordPress 環境）のサーバー設定にあった。

KUSANAGI 上の Apache 設定（VirtualHost ブロック内）では、uploads など特定のディレクトリで AllowOverride None ── つまり「.htaccess を読まない」設定が入っている。これは セキュリティとパフォーマンス上の正解でもある。.htaccess は無制限に上書きされる脆弱性源にもなりうるし、Apache が毎リクエストでディレクトリツリーを遡ってファイルを探すコストもばかにならない。だから KUSANAGI は「.htaccess を読ませない」設計を選んでいる。

これが 罠だった。普通の Apache の感覚で「.htaccess を置けば効く」と思って書いた WebP 配信の 4 行は、KUSANAGI 上では静かに無視されていた。エラーは出ない。警告も出ない。ただ 何も起きない。

Phase 3 ── 解：PHP <picture> タグフィルター方式

Pop が選んだ解は、.htaccess をやめて、PHP 側で <img> を <picture> に置換する方式だった。WordPress の the_content フィルター（記事本文の出力直前にフックできる仕組み）に登録して、本文中の <img src="...jpg"> を、出力時にこう書き換える：

<picture>
  <source srcset="path/to/image.webp" type="image/webp">
  <img src="path/to/image.jpg" alt="...">
</picture>

これだと .htaccess に依存しない。ブラウザは <picture> 仕様に従って、image/webp をサポートしていれば <source> の .webp を読み、サポートしていなければ <img> の .jpg にフォールバックする ── これがブラウザ標準の挙動だから、サーバー側で Accept ヘッダーを判定する必要すらない。

処理の流れはこうだ：

1. the_content フィルターで本文 HTML を受け取る
2. 正規表現で <img> タグを抽出
3. src の .jpg/.png を .webp に書き換えたパスを作る
4. そのパスに 実ファイルが存在するかを確認（存在しなければ置換しない ── これが冪等性とフォールバックを両立させる鍵）
5. 存在すれば <picture> でラップして返す

これで全記事のヘッダー画像が、ブラウザ側で自動的に .webp 配信に切り替わった。.htaccess の罠を回避しつつ、ブラウザ非対応のレガシー環境にも .jpg でフォールバックが効く。「サーバー設定に依存しない WebP 配信」という、KUSANAGI 環境にとっての 正解の形だった。

結果と、Pop の温度

本番反映後の数字は揃った：

• 全記事ヘッダー画像 12,266 件、.webp 配信に切り替わった
• uploads ディスク使用量：2,439 MB 削減（元画像も残してこの数字）
• 変換時エラー：0 件
• Phase 1 試験で出た Score +8 / LCP -24% が、12,266 件すべての記事に「面」として効くようになった

Pop の温度は、こうだった ──「1 件で効くと分かった数字を、12,266 件にどう安全に効かせるか。運用エンジニアリングの仕事はここから始まる。一括変換のスクリプトを書くだけなら誰でもできる。.htaccess が KUSANAGI で効かない罠を踏んで、<picture> タグフィルターという回避路を見つけて、冪等性とフォールバックを両立させる ── ここまで降りて初めて、面の最適化は完成する」。

これが archives/16「YouTube を遅らせたら、サイトが速くなった」（点で示した改善）と archives/17「swappiness 1 行で守った安定」（線で守った安定）に続く、「面」の最適化の物語だ。Pop の「改善の物理学」連載は、これで 点 → 線 → 面 の三層を完成させた。

【技術コラム①】KUSANAGI の AllowOverride None と .htaccess の話

Apache の .htaccess は便利だが、本番運用ではしばしば「読ませない」のが正解になる。KUSANAGI もそうだし、他の高速 WordPress 環境（Nginx ベースの一部構成）でも同様の方針が採られている。理由は 2 つある。

① セキュリティ：.htaccess は誰でも書き込めるとリクエスト処理ロジックを書き換えられる。アップロードディレクトリで .htaccess が読まれる状態にしていると、PHP 実行を許可する 1 行を仕込まれてバックドアになる経路にもなる。

② パフォーマンス：.htaccess が有効だと、Apache はリクエストごとに対象ディレクトリから上方向のすべてのディレクトリの .htaccess を探しに行く。アクセス頻度の高いサイトでは、この I/O コストが無視できない。

だから本番 Apache では VirtualHost 内に AllowOverride None を書き、Rewrite/Auth/Cache などのディレクティブはすべて Apache 設定本体に直接書く ── これが 本番ベストプラクティスだ。KUSANAGI は最初からこの設計を採用している。

逆に、これを知らずに「.htaccess 置けば動くでしょ」と思って WebP 配信の 4 行を書くと、静かに無視される。エラーログにも出ない。Network パネルを見てやっと「あれ、RewriteRule 通ってないな」と気づく。──「正しい設定（KUSANAGI 側のセキュリティ + パフォーマンス）」と「正しい設定（教科書的 WebP 配信）」が 噛み合わずに何も起きない。archives/7「正しい設定×正しい設定 = 障害」と地続きの構造だ。

確認方法：自分のサーバーで .htaccess が効いているかを知りたいときは、対象ディレクトリに Deny from all だけ書いた .htaccess を置いて、配下のファイルにブラウザでアクセスする。403 が返れば有効、200 が返れば AllowOverride None（または .htaccess が読まれない設定）── これが一番速い切り分けだ。

【技術コラム②】<picture> タグフィルター方式の実装パターン

WordPress の the_content フィルターで <img> を <picture> に置換する実装は、骨格だけ書くとこのくらいシンプルだ：

add_filter('the_content', function ($content) {
    // 既に <picture> で包まれているものはスキップ（冪等性）
    return preg_replace_callback(
        '/(?<!<source[^>]{0,200})<img\s+([^>]*?)src=["\']([^"\']+\.(jpe?g|png))["\']([^>]*?)>/i',
        function ($m) {
            $jpg = $m[2];
            $webp = preg_replace('/\.(jpe?g|png)$/i', '.webp', $jpg);
            $webp_path = wp_upload_dir()['basedir'] . str_replace(wp_upload_dir()['baseurl'], '', $webp);

            // 実ファイルが存在しなければ <img> のまま返す（フォールバック）
            if (!file_exists($webp_path)) {
                return $m[0];
            }

            return sprintf(
                '<picture><source srcset="%s" type="image/webp"><img %ssrc="%s"%s></picture>',
                esc_url($webp), $m[1], esc_url($jpg), $m[4]
            );
        },
        $content
    );
}, 20);

この実装の 3 つの肝：

① 冪等性：先読み ((?<!<source...)) で「すでに <picture> の中の <img>」をスキップする。フィルターは複数回呼ばれることがあるので、2 回適用しても二重置換にならない設計にする。

② フォールバック：.webp の実ファイルが存在するかを file_exists() で確認する。「変換し忘れた古い画像」「外部 CDN 経由のURL」など、.webp がない画像はそのまま <img> で返す ── これで「ある記事だけ画像が壊れる」事故を防ぐ。

③ 属性保持：<img> 元のすべての属性（alt, width, height, class など）を $m[1] と $m[4] で取り出して、新しい <img> にそのまま渡す。アクセシビリティ（alt）と Core Web Vitals（width/height による CLS 抑制）を壊さない。

あなたのサイトで WebP を導入する場合 ── まず PSI で 1 記事の数字を取り、ヘッダー画像 1 件を cwebp で変換して比べる。Score が伸びるなら、上のフィルターをテーマの functions.php に貼って、本番反映する前に WP_DEBUG でローカル確認する。file_exists() ガードがあるので、たとえ .webp をまだ作っていなくても サイトは壊れない。安全に始められる。

結び ── 「点 → 線 → 面」の連載完成

Pop の連載は、これで 4 → 5 本目になった。archives/16 は 1 記事の LCP を 21 秒から 9 秒に削った点の話。archives/17 は swappiness 1 行でサーバー全体の安定を守った線の話。archives/24 は AMP 無効化で「改善が届く前提条件」を整えた話。

そして今回 ── 1 件の試験で出た改善を、12,266 件に 面として効かせた話。.htaccess の罠を踏みつつ、<picture> タグフィルターという回避路を選び、冪等性とフォールバックを両立させた。「点で示し、線で守り、面で効かせる」── これが Pop の「改善の物理学」だ。

1 件で出た数字を、12,266 件に届けるまでの距離。その距離を、KUSANAGI の正しい設計を尊重しながら、PHP フィルター 1 つで埋めた ── これが今日の archives/28 の核心だった。

あなたのサイトに 1 件で効くと分かった改善があるなら、その数字を 面に届けるところまで設計してみてほしい。「.htaccess が効くかどうか」「冪等性が担保されるか」「フォールバックが効くか」── この 3 点だけ握れば、点は面になる。