WordPress 7.1は8月19日にリリースされました。その直後、WP Rocketを実行していた一部のサイトで致命的なエラーが発生しました。
この問題が発見されたのはリリース当日ではありませんでした。実際には7月6日に公開で報告されていましたが、WordPress 7.1はまだアルファ版でした。
報告には再現手順、エラーの原因、そして1行で済む修正案が含まれていました。しかし……その後、6週間以上が経過しました。
45日間の経過
2026年7月6日
致命的なエラーが、再現手順、問題の原因、そして1行で済む修正案とともに公開報告されました。
2026年7月15日
WordPress 7.1 Beta 1がリリースされ、公開ベータテスト期間が始まりました。
2026年8月5日
WordPress 7.1はリリース候補版のテスト段階に入りました。互換性の問題はまだ解決されていませんでした。
2026年8月19日
WordPress 7.1がリリースされました。影響を受けるWP Rocketの設定を使用しているサイトで、致命的なエラーが発生し始めました。
2026年8月20日
WP Rocket 3.23.2.2で修正が提供されました。最初の報告から45日後のことでした。
その期間中、WordPress 7.1は、リリーススケジュールに従って4回のベータ版リリースと4回のリリース候補版を経ました。WP Rocketも互換性修正が提供されるまでに4回のプラグイン更新を行いました。
この経過を踏まえると、WordPressサイトの所有者は、依存しているプラグインに何を期待すべきかという、もっともな疑問が生じます。
互換性はパフォーマンスの一部です
バグは、私たちのプロジェクトを含め、あらゆるソフトウェアプロジェクトで発生します。アルファ版リリースに対する報告は、不完全だったり、1つの環境に限られていたり、最終リリースまでの変更の影響を受けていたりする可能性があります。プラグインのメンテナーは、報告を慎重に調査し、優先順位を付ける必要があります。
この報告は、通常とは比べものにならないほど具体的でした。誤ったデータ型を受け取っていた正確な関数を特定し、致命的なエラーを再現する手順を示し、修正案まで含んでいました。
テストする時間もありました。WordPress 7.1の公開リリースサイクルには、7月15日開始のベータ版リリースと、8月5日開始のリリース候補版が含まれていました。
パフォーマンスプラグインはWordPressの深部で動作します。ページのキャッシュ方法やスクリプトの読み込み方法を変更し、CSSを配信し、アセットを提供します。そのため、互換性への対応は特に重要です。
サイトが高速になっても、通常のWordPress更新によってオフラインになってしまうなら、あまり意味がありません。
これは公表されたセキュリティ脆弱性ではありませんでした。特定の設定でサイトの可用性に影響を及ぼす、互換性の障害でした。この違いは技術的には重要ですが、影響を受けたサイト所有者にとって、結果が深刻だったことに変わりはありません。
Jetpackが深刻なセキュリティ報告を処理する方法
WP Rocketの問題はセキュリティ脆弱性として報告されたものではないため、エクスプロイトと直接比較するのは正確ではありません。それでも、深刻な報告への対応について私たちが定めている基準を示す例として、私たちのセキュリティポリシーは役立ちます。
Jetpackには公開セキュリティポリシーがあり、AutomatticのHackerOneバグバウンティプログラムにも参加しています。内部では、HackerOne、GitHub、そして社内のAutomatticチームを通じて受け取った報告を、私たちのプロセスで扱います。
- 報告をトリアージします。 WordPress.comが影響を受けているかどうかを含め、問題が悪用可能か、影響を受けるバージョン、露出する可能性のあるサイト数を評価します。
- 適切なチームを関与させます。 Jetpackエンジニアリングは、Automatticのセキュリティチーム、および状況に応じてサポート、コミュニケーション、法務、ホスティングパートナー、またはWordPress.orgと連携します。
- 深刻度に応じてリリースを調整します。重大な脆弱性には、できるだけ早いホットフィックスと、影響を受けるリリースへのバックポートが必要です。深刻度の高い問題にはポイントリリースで対応します。リスクが低い問題にも、明確なリリース計画を割り当てます。
- 修正をレビューします。セキュリティパッチにはセキュリティレビューを行います。リスクが緊急の場合はテストを迅速化できますが、省略することはありません。
- 伝達し、学びます。深刻なインシデントには、エンジニアリング、ユーザーへの告知、サポートそれぞれの明確な担当者を置きます。その後、何が起きたのか、何を変えるべきかを振り返ります。
どのようなポリシーでも、ソフトウェアチームを完璧にすることはできません。ただし、期待される対応を明確にすることはできます。信頼できる報告には、担当者、深刻度の判断、リリース計画、そして最後までやり遂げる対応が必要です。
今こそ、パフォーマンス設定を見直す良い機会です
WordPressのパフォーマンス設定は、時間とともに増えていきがちです。まずキャッシュプラグインを追加し、次に画像の最適化、CDN、スクリプトの遅延読み込み、Critical CSS、そして結果を測定する別のツールを加えていきます。
やがて、複数のプラグインがサイトの同じ部分を変更するようになる可能性があります。
WP Rocketを主にキャッシュとフロントエンドの最適化に使用している場合、Jetpack Boostは、同じ作業の多くをカバーします。
- ページキャッシュ
- Critical CSS
- 必須ではないJavaScriptの遅延読み込み
- CSSとJavaScriptの結合および最小化
- JetpackのグローバルCDNによる画像最適化
- 組み込みのパフォーマンススコア
これらの機能は個別に有効化できるため、各変更の効果を理解しやすくなります。無料版には、ページキャッシュ、手動でのCritical CSS生成、JavaScriptの遅延読み込み、画像CDN、そしてCSSとJavaScriptの連結が含まれます。
Jetpackのすべての機能が必要でなくても問題ありません。Jetpack Boostは単独のプラグインとしても提供されています。これを使うためにメインのJetpackプラグインをインストールする必要はありません。
WP RocketからJetpack Boostへ切り替える方法
パフォーマンスプラグインを変更する前に、サイトをバックアップするか、ステージングサイトで変更をテストしてください。
サイトがすでにWordPress 7.1の致命的なエラーの影響を受けている場合は、まずWP Rocketをバージョン3.23.2.2に更新してください。サイトが再び動作するようになったら:
- 現在のパフォーマンス結果を記録し、基準値として利用できるようにします。
- WP Rocketを無効化し、残っているサーバーまたはCDNのキャッシュを削除します。
- 次のJetpack Boostをインストールして有効化してください。
- パフォーマンスモジュールを一度に1つずつ有効化します。
- 変更するたびに、ホームページ、投稿、フォーム、検索、ログイン、チェックアウトなど、その他の重要な操作をテストしてください。
- 結果を元の基準値と比較します。
複数のプラグインで同じ最適化を有効にすることは避けてください。同じJavaScriptの遅延読み込みや同じキャッシュの管理を2つのツールが試みると、新たな互換性の問題が発生する可能性があります。
WordPressのサイトは一つひとつ異なるため、すべての最適化が役立つと決めつけず、結果を測定してください。
プラグインの更新には信頼が必要です
サイト所有者は、プラグインチームがWordPressの開発動向を追い、今後のリリースをテストし、本番環境にリリースされる前に信頼できる互換性報告を調査することを期待しています。
WP Rocketの問題は、ソフトウェアにバグがないことを期待しているという話ではありません。深刻な問題がすでに報告され、提案された修正も明らかになった後に何が起こるか、という話です。
このインシデントをきっかけにWP Rocketを再検討しているなら、Jetpack Boostを使えば、サイトに必要な最適化を維持しながら、パフォーマンス設定を簡素化する実践的な方法があります。
Jetpack 