ShinyHuntersが教育機関を標的に、Oracle PeopleSoft脆弱性を悪用
CVE-2026-35273を悪用した大規模攻撃、教育機関が標的に
2026年5月下旬から6月上旬にかけて、Oracle PeopleSoftの重大な脆弱性を悪用するサイバー攻撃が発生した。MandiantとGoogle Threat Intelligence Group（GTIG）の調査により、攻撃者はShinyHunters（UNC6240）として知られるグループであり、標的となったのは主に高等教育機関を含む世界中の組織だった。
攻撃の起点となったのはCVE-2026-35273だ。PeopleSoftのEnvironment Managementコンポーネントに存在するリモートコード実行の脆弱性で、CVSSスコアは最高レベルの9.8。この脆弱性は6月10日にOracleからセキュリティアラートが発表されるまでゼロデイとして悪用されていた。
この記事では、本攻撃キャンペーンの技術的な分析、攻撃者の手口、そして組織が今すぐ取るべき具体的な防御策について、技術に詳しい同僚のようにわかりやすく解説する。
グローバル通知の試みと被害の実態
GTIGはスキャン活動と悪用を検知した後、潜在的に脆弱なエンドポイントを持つ100以上の組織に通知を行った。通知対象の大半は米国に拠点を置き、その68%が高等教育機関だった。一部の組織は脆弱性の修正に成功したが、多くの組織で侵害が確認され、窃取されたデータがShinyHuntersのデータリークサイトに公開される事態に至った。
攻撃の起点となったゼロデイ脆弱性
問題のCVE-2026-35273は、PeopleSoftのEnvironment Management Hub（EMHub）における重大な欠陥だ。この機能は管理者やシステム間コンポーネント向けであり、エンドユーザーが直接利用するものではない。しかし、認証なしでリモートからのコード実行が可能であることが攻撃成立の決定的な要因となった。
攻撃基盤の構築から内部偵察までの技術分析
攻撃者の手口は、ステージングサーバーの構築から始まった。2026年5月27日、攻撃者はオープンソースのリモート管理ツールであるMeshCentralをインストールし、C2（コマンド＆コントロール）環境を整えた。その際、正規のMicrosoft Azureサービスを装うドメイン「azurenetfiles.net」を取得し、SSL証明書まで自動化する念の入れようだ。
ステージングサーバーには、MeshCentralエージェントが配置された。エージェントのファイル名は「meshagent32-azure-ops.exe」など、正規のAzure運用エージェントに見せかけられていた。これらのエージェントは、攻撃者が自由に遠隔操作を行うためのバックドアとして機能する。
内部ネットワークの探索と情報収集
ステージングサーバーのコマンド履歴（.bash_history）からは、侵入後の詳細な偵察活動が明らかになった。攻撃者はmeshctrl.jsというMeshCentralのCLIツールを使い、侵害したマシン上で以下のようなコマンドを実行し、内部ネットワークの地図を作り出していた。
- システムのホスト名やユーザーIDの確認
- PeopleSoftのプロセススケジューラ設定ファイル（psappsrv.cfg）の解析による、マシン名とIPアドレスの抽出
- ネットワークマウントの確認とPeopleSoft関連領域の特定
- ローカルホストテーブル（/etc/hosts）を精査し、内部の全ノードをマッピング
- WebLogicサーバーのXML設定ファイルからのアプリケーションサーバー情報の収集
これらの偵察は、後の水平展開を効率的に行うための下準備だ。まずは地図を描き、その後に攻撃を拡大するという、組織的な手口が浮かび上がる。
水平展開の自動化スクリプトとデータ窃取の仕組み
攻撃の核心は、自走式の水平展開スクリプト「[victim_abbreviation]_fanout.sh」にある。このスクリプトは、偵察フェーズで収集した内部ホスト情報を基に、SSHの認証情報を総当たりで試行し、侵害範囲を一気に拡大するよう設計されている。
スクリプトは、特定の命名規則を持つホスト名を/etc/hostsから抽出し、事前にハードコードされた複数のユーザー名とパスワードのリストを使ってSSH接続を試みる。この手法はSSHクレデンシャル・スプレー攻撃と呼ばれるものだ。
攻撃が成功すると、スクリプトはPayloadとして「README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT」というファイルを、WebLogicやプロセススケジューラのディレクトリに書き込む。これは単なる嫌がらせの証跡ではなく、被害組織に対する恐喝のマーカーとして機能した。
データの流出とリークサイトへの接続
水平展開が完了した後、攻撃者は窃取したデータをzstdという高圧縮率のツールでアーカイブし、ステージングサーバー経由で外部へ持ち出した。一連のコマンド履歴の最後には、攻撃者のステージングサーバーから、ShinyHuntersのデータリークサイト公開ミラーをホストするIPアドレス「176.120.22.24」へのSSH接続が記録されていた。
この接続が、侵害された組織のデータが最終的にリークサイトで公開されるまでの一連の流れを決定づけた。実際に2026年6月9日には、複数の被害組織のデータが同サイト上に公開されている。
今すぐ取るべき具体的な防御策
この脅威に対抗するため、GoogleとOracleの両方は、PeopleSoftを運用する組織に対し、以下の即時対応を強く推奨している。対策は、ネットワークの遮断、ログ監視、そしてホストレベルの監査という3つのレイヤーに分類できる。
ネットワークレベルでの緊急対応
最も即効性が高いのは、エンドポイントそのものへの外部からのアクセスを遮断することだ。具体的には、ファイアウォールや境界ネットワークで「/PSEMHUB/hub」と「/PSIGW/HttpListeningConnector」へのHTTP POSTリクエストを遮断する。これらのエンドポイントは一般ユーザー向けの機能ではないため、遮断による業務への影響はない。
WAF（Webアプリケーションファイアウォール）だけに頼るのは危険だ。ルールをすり抜けられる可能性があるため、あくまで補助的な対策と考えるべきだろう。
ログとエンドポイントの徹底監視
次に重要なのが、侵入口と内部活動の痕跡をログから探し出すことだ。WebLogicのアクセスログで「/PSEMHUB/hub」や「/PSIGW/HttpListeningConnector」へのPOSTリクエストを調査する。送信元が外部IPや信頼できないアドレスであれば要注意だ。
特に「/PSIGW/HttpListeningConnector」へのリクエストでは、SSRF（サーバーサイドリクエストフォージェリ）攻撃の兆候を探す。リクエストパラメータに「127.0.0.1」や「localhost」などのループバックアドレス、内部IPレンジが含まれていないか確認する必要がある。
さらに、ネットワークレベルでは、PeopleSoftサーバーから外部の不審な宛先へのSMB通信（TCPポート445）を監視する。これは攻撃チェーンの一環として、WindowsマシンのNetNTLMハッシュを窃取するために悪用される可能性があるためだ。
ホストレベルでのフォレンジック監査
最後に、侵害の有無を確定させるためのファイルシステム調査を行う。以下のディレクトリに、通常存在しないファイルやフォルダがないかを重点的にチェックする。
- WebLogicのアプリケーションディレクトリ内の「PSEMHUB.war」配下に、未知のJSPファイル（WebShell）が生成されていないか
- 「envmetadata/transactions/」ディレクトリに、不審なフォルダや攻撃者のツールがドロップされていないか
- 「envmetadata/data/environment/」配下に、最近更新された怪しいXMLファイルがないか（XMLDecoderを介した永続化の可能性）
これらの調査により、攻撃者が仕掛けたバックドアや永続化の仕組みを特定し、再起動後も安全な状態を確保できる。
この記事のポイント
- ShinyHuntersはCVE-2026-35273をゼロデイとして悪用し、100以上の組織を攻撃した。標的の68%は高等教育機関だった
- 攻撃者は正規クラウドサービスを装う高度なC2インフラを構築し、MeshCentralを悪用して遠隔操作と水平展開を自動化した
- スクリプトによるSSHスプレー攻撃で内部ネットワークに拡散し、最終的にデータを窃取。盗まれた情報はリークサイトで公開された
- 防御の最優先事項は、使用していない管理用エンドポイントをネットワーク境界で遮断すること。これによりWAFバイパスのリスクを根本的に排除できる
- 遮断と並行して、アクセスログの調査、SMB通信の監視、ファイルシステムのフォレンジック監査を速やかに実施する必要がある
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
JavaScriptがログアウト時に動かない原因と直し方
管理画面にログインしているときだけ JavaScript が動き、ログアウトすると止まる。この現象の原因は、ほぼ「スクリプトの読み込み順序」と「キャッシュ・最適化プラグインの挙動」のどちらか、あるいは両方の組み合わせだ。ログイン時は管理バー用のスクリプト等が読み込まれるため依存関係が偶然成立し、ログアウト時にそれが外れてエラーになるケースが多い。
ログアウト時だけ JavaScript が動かなくなる仕組み
このデモは典型的な依存関係の崩れを示している。ログイン中は WordPress が管理バーやフッターに jQuery を読み込むため、その後に記述されたスクリプトが偶然動く。ログアウトすると jQuery が存在せず、$ is not defined や jQuery is not defined といったエラーで止まる。
HTML ブロックに直接書いた JavaScript が招く問題
WordPress の「カスタム HTML」ブロックに <script> タグを直書きする方法は、一見手軽だが制御が難しい。出力される位置がテーマやブロック配置に依存し、jQuery などのライブラリより前に実行されれば必ず失敗する。さらにインラインスクリプトは多くのキャッシュプラグインで最適化対象から外されたり、結合・遅延読み込みの対象にならず、ログアウト時だけ二重に不利な状況を生む。
HTML ブロック直書きスクリプトの3つの弱点
- 読み込み順序を制御できない（テーマの render 順に依存する）
- jQuery の依存関係を WordPress に伝えられない
- キャッシュ・圧縮プラグインがスクリプトとして認識しない場合がある
ログアウト時でも動くようにする正しい組み込み手順
原則は「JavaScript は HTML ブロックに直書きせず、WordPress の仕組み（wp_enqueue_script）で読み込む」ことだ。すでに直書きで動いているものを移行するには、以下の手順で進める。
STEP 1 既存の script タグを外部ファイルに移す
HTML ブロック内の <script>〜</script> 部分だけを抜き出し、子テーマのフォルダ内に testimonial-slider.js のような名前で保存する。<script> タグそのものは不要で、中身のコードだけを移す。HTML ブロックにはスライダーの構造（ul や div のマークアップ）だけを残す。
STEP 2 functions.php で安全に読み込む
子テーマの functions.php に以下のコードを追加する。管理画面ではなくフロントエンドだけに読み込ませるために wp_enqueue_scripts フックを使う。依存関係として jquery を指定すれば、WordPress 本体の jQuery が先に読み込まれてから実行される。
function my_testimonial_slider_script() {
wp_enqueue_script(
'testimonial-slider',
get_stylesheet_directory_uri() . '/testimonial-slider.js',
array('jquery'),
'1.0.0',
true
);
}
add_action('wp_enqueue_scripts', 'my_testimonial_slider_script');最後の引数 true はフッターで読み込む指定だ。スライダーの DOM 要素が本文中に存在する場合はフッター読み込みで問題ない。もしスライダーを本文より前に実行する必要があるなら false にしてヘッダーで読ませるが、多くのケースではフッターで十分だ。
STEP 3 $ の衝突を防ぐ
WordPress の jQuery は noConflict モードで動作しているため、$ がそのまま使えない環境がある。古いコードを流用している場合は $ is not a function エラーが起きやすい。回避策として、外部ファイル全体を即時実行関数で囲み、引数で $ を受け取る記法が安全だ。
(function($) {
$(document).ready(function() {
// ここにスライダーのコード
});
})(jQuery);STEP 4 キャッシュプラグインでスクリプトを除外する
ここまで対応しても直らない場合、キャッシュや最適化プラグインが原因の可能性が高い。ログアウト時はページキャッシュが有効になり、スクリプトの遅延読み込みや結合が適用される。自前の testimonial-slider.js をこれらの処理から除外する必要がある。
プラグインの設定画面で「スクリプトの除外」「遅延読み込みの除外」といった項目を探し、testimonial-slider（ハンドル名）または testimonial-slider.js（ファイル名の一部）を指定する。除外後は必ずキャッシュを全削除してからログアウト状態で確認する。
Elementor のフックやテーマのアクションフックを使った場合の注意点
テーマ付属のフック（GeneratePress の Element など）に HTML ブロックごと差し込む方法も考えられるが、根本的にはスクリプトの読み込み順序問題は同じだ。フックで出力する位置を変えても、jQuery より前に呼ばれるリスクは残る。フックを使う場合でも、スクリプト部分は wp_enqueue_script に任せ、フックにはマークアップだけを出力する形が堅実だ。
Elementor Pro の「カスタムコード」機能を使っているなら、その中に script タグを書くのではなく、同様に子テーマのファイルとして切り出してハンドル登録するほうが制御できる。どうしても直書きが必要なら、カスタムコードの「場所」設定を「本文の終了タグ直前」にし、さらにコード内で jQuery を明示的に使う（$ を使わない）ことでエラーを減らせる。
よくある質問
コンソールに「$ is not defined」と出るがどう直せばいいか
jQuery が読み込まれる前に $ を使っているか、noConflict モードで $ が無効になっている。即時関数で (function($) { ... })(jQuery); とラップし、すべての $ をこのスコープ内に収めれば解決する。
functions.php を編集せずに直す方法はあるか
「WPCode」などのコードスニペット管理プラグインを使えば、管理画面から wp_enqueue_script のコードを登録できる。functions.php を直接触りたくない場合の現実的な代替手段だ。スニペットの実行場所を「フロントエンドのみ」に設定するのを忘れないようにする。
キャッシュを削除しても直らないのはなぜか
ブラウザキャッシュだけを消していて、サーバー側のページキャッシュや CDN キャッシュが残っているケースが多い。WordPress のキャッシュプラグインの「すべてのキャッシュを削除」を実行し、さらに CDN を使っている場合はその管理画面からもパージする。シークレットウィンドウで確認するとブラウザキャッシュの影響を除外できる。
スライダーのマークアップだけ残して script を外したら表示が消えた
新しく作った JS ファイルが正しく読み込まれていない。ブラウザの開発者ツールの「ネットワーク」タブで testimonial-slider.js が 200 番で返っているか確認する。404 ならパスが間違っている。読み込まれているのに動かない場合は、コンソールに別のエラーが出ていないか調べる。
この記事のポイント
- ログアウト時だけ JavaScript が動かない原因は、jQuery の依存切れとキャッシュ最適化の複合
- HTML ブロックへの script 直書きは読み込み順序を制御できず、根本対策にならない
- wp_enqueue_script で jQuery 依存を明示し、外部ファイルとして切り出すのが正攻法
- 即時関数で $ の衝突を防ぎ、キャッシュプラグインでは独自スクリプトを除外対象に追加する
- Elementor やテーマフックを使う場合も、スクリプトだけは enqueue に任せる設計が堅実
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
特定商品ブロックを設置した固定ページでfatal errorが発生する問題の直し方
特定商品ブロックを固定ページに配置したときに「Uncaught Error Call to a member function get_id() on null」というfatal errorが表示されるのは、PreCart for WooCommerce のバグが原因だ。プラグインを最新バージョンへ更新するか、functions.php へ一時的な修正コードを追加すれば直る。
なぜ固定ページ上の商品ブロックで fatal error が起こるのか
PreCart は WooCommerce の商品情報を扱うフィルターフック（woocommerce_product_add_to_cart_text など）にコールバック関数を登録し、その中で global $product から商品オブジェクトを取得して $product->get_id() を呼び出している。しかし、ブロックエディタで「特定商品」ブロックを通常の固定ページに配置すると、WooCommerce のブロック表示パイプラインではグローバル変数 $product が null のままフィルターが走るケースがある。PreCart のコードには null チェックがないため、null に対して get_id() を呼び出してしまい、致命的なエラーでページ全体が落ちる。
$product が null のままコールバックが実行される$product->get_id() で致命的エラー発生（画面が真っ白になる）影響を受けるメソッドは change_add_to_cart_text()、display_pre_order_messgae()、display_pre_order_badge() など、いずれも保護コードがない。WooCommerce の商品ブロックを店舗ページ以外で使っているサイトはすべてこの問題に遭遇し得る。
PreCart を更新してエラーを解消する手順
開発元はこの問題を認識しており、すでに修正アップデートがリリースされている。まずは管理画面からプラグインを最新版に上げるのが最も安全で確実な対処法だ。
更新通知が表示されない場合
「ダッシュボード」→「更新」から更新の再確認を行うか、PreCart のプラグインページで一度「プラグインを削除」→ 公式リポジトリから再インストールする方法もある。ただしこの場合、設定がリセットされる可能性があるため、事前に PreCart の設定をメモしておくかエクスポート機能があれば使っておくと安心だ。
functions.php で null チェックを追加して一時的に対処する方法
どうしてもすぐにプラグインを更新できない場合や、何らかの理由で更新後に問題が残る場合は、テーマの functions.php にフックを追加して一時的にエラーを回避できる。
/**
* PreCart の null チェック不足による fatal error を回避（一時的対応）
*/
add_filter( 'woocommerce_product_add_to_cart_text', function( $text, $product ) {
if ( ! $product || ! is_a( $product, 'WC_Product' ) ) {
return $text;
}
// 以下は原本の処理が走るが、早期リターンで保護
return $text;
}, 1, 2 );
add_filter( 'woocommerce_single_product_summary', function() {
global $product;
if ( ! $product || ! is_a( $product, 'WC_Product' ) ) {
return;
}
// 同様に早期リターン
}, 1 );上記のコードは PreCart が使っているのと同じフックに、より優先度の高いコールバック（優先度 1）で null チェックを追加し、商品オブジェクトが存在しないときは処理を打ち切る仕組みだ。PreCart のフィルターよりも先に実行されるため、致命的エラーに至る前に関数を抜けられる。
$product->get_id();
$product->get_id();
functions.php 編集時の注意点
子テーマを使っていない場合、テーマ更新で修正が上書きされるリスクがある。必ず子テーマの functions.php にコードを追加するか、Code Snippets プラグインでコードを管理するのが望ましい。また、この一時対応はあくまで応急処置であり、PreCart の他の機能が正常に動作しない可能性もゼロではない。早めに公式アップデートを適用して、追加コードは削除する。
手動修正後に確認しておきたいポイント
- 一時的なコードを追加した後、サイトの表示速度やエラーログに変化がないか定期的にチェックする
- PreCart の機能（カート追加テキストの変更や予約注文バッジなど）が期待どおり動作しているかテストする
- PHP のエラーログを確認し、別の箇所で同様の null 参照エラーが隠れていないか調べる
- サイト全体のキャッシュをクリアし、CDN を利用している場合は CDN キャッシュも破棄する
- PreCart の更新が確認できたら必ずプラグインを最新版に上げ、追加コードを削除する
よくある質問
PreCart 以外のプラグインでも同じように商品ブロックでエラーが出ることはありますか
ある。WooCommerce のブロックを通常ページで使うと、$product グローバルを正しく取り扱っていない他の拡張プラグインでも同様の null 参照エラーが起きるケースが報告されている。エラーの文面に別のプラグイン名が含まれている場合は、そちらの開発元へ報告しつつ、同じように functions.php で早期リターンを追加すれば応急回避できることが多い。
WooCommerce の商品ブロックを固定ページで使うこと自体は問題ないのでしょうか
WooCommerce のブロックは基本的に店舗ページや商品ページで使うことを想定しているが、WordPress の標準ブロックとして技術的にはどの投稿タイプでも利用できる。プラグインがグローバル変数の有無を適切にハンドリングしていれば固定ページで使っても問題は起きない。ただ、テーマやプラグインが認めるまで、動作確認は入念に行ったほうがよい。
エラーメッセージが表示されずに画面が真っ白になる場合はどうすればよいですか
WordPress が致命的エラーを表示しない設定（WP_DEBUG が false）のときは、管理画面のメールに送られる復旧モード用のリンクを探すか、サーバーの PHP エラーログを確認する。wp-config.php で define('WP_DEBUG', true); を一時的に有効にすれば、画面上にエラー詳細が表示され、原因を特定しやすくなる。なお、本番環境ではデバッグモードをすぐに無効に戻すこと。
管理画面にも入れなくなってしまった場合はどうすれば直りますか
FTP またはレンタルサーバーのファイルマネージャーで /wp-content/plugins/precart/ ディレクトリの名前を一時的に変更（例：precart_deactivated）すれば、プラグインが無効化されて管理画面に再ログインできる。その後、前述の更新や一時コードで対処し、ディレクトリ名を元に戻す。
この記事のポイント
- 固定ページに WooCommerce 商品ブロックを配置したときの fatal error は PreCart の null チェック不足が原因
- 解決策は PreCart プラグインの最新版への更新が最も安全で確実
- すぐに更新できない場合は、functions.php にフックで早期リターンを追加すれば応急回避できる
- functions.php 編集は子テーマで行い、アップデート後は必ず追加コードを削除する
- 管理画面に入れなくなったら FTP でプラグインフォルダ名を変更し無効化する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
AWS WAFがAIボット収益化機能を追加、コンテンツ所有者が課金可能に
AWSは2026年6月15日、AWS WAFにAIトラフィック収益化機能を追加した。コンテンツ所有者やパブリッシャーが、自社のWebコンテンツにアクセスするAIボットやAIエージェントに対して、ネットワークエッジで直接課金できるようになる。
AIボットによるWebトラフィックは、多くのコンテンツプロバイダーで全体の50%を超え、AI専用クローラーは前年比300%以上増加している。従来の検索エンジンクローラーはリンクを返すことで参照トラフィックをもたらすが、AIボットはコンテンツを要約してAIインターフェイス上で表示するため、元のサイトにはほとんどトラフィックが還元されない。その結果、コンテンツ提供者はインフラコストだけを負担し、広告収入や購読コンバージョンといった従来の収益源が得られない状況が続いていた。
今回の新機能は、このギャップを埋めるものだ。AWS WAF Bot Controlの仕組みを拡張し、コンテンツパスごと、ボットカテゴリごと、検証ティアごとにリクエスト単価を設定できる。また、ステーブルコインによる支払いをウォレットで受け取り、単一のダッシュボードで収益とボットアクティビティを追跡可能にする。
AIボット収益化の新機能がAWS WAFに追加された背景
AIトラフィックの爆発的な増加
GPTBotやClaude-Web、Perplexity-BotといったAIクローラーは、学習用データやリアルタイム情報の収集のためにWebサイトを大量にクロールする。こうしたトラフィックは増加の一途をたどり、一部のコンテンツプロバイダーではAIボットが全リクエストの50%を超えるまでになっている。検索エンジンのクローラーとは異なり、AIボットはインデックスを生成する代わりにテキストを直接消費し、要約をAIチャット画面に表示する。そのため、元記事を読むための流入はほとんど発生しない。
従来のBot Controlでは限界があった理由
AWS WAF Bot Controlはこれまで、650種類以上のAIボットを検出し、ブロックまたはレート制限をかけることができた。しかし、ボットのトラフィックを完全に遮断するのではなく、課金して収益化したいというニーズは強く存在していた。コンテンツを無料で提供し続ければインフラコストがかさむ一方、単純にブロックすればAIサービスへの露出が途絶えてしまう。そこで、ボットにコンテンツ利用の対価を支払わせる仕組みが求められていた。
AIトラフィック収益化の仕組み
x402プロトコルとHTTP 402 Payment Required
今回の収益化機能の核は、x402というマシンツーマシン決済のオープンプロトコルだ。ルールに合致したAIボットからのリクエストに対し、AWS WAFはHTTP 402 Payment Requiredレスポンスを返す。このレスポンスボディには、コンテンツの価格（USDC建て）、受け入れ可能なブロックチェーンネットワーク（BaseやSolanaなど）、送金先ウォレットアドレス、支払いタイムアウトを含むJSON形式のプライスマニフェストが含まれる。これを受け取ったx402対応のエージェントランタイムは、自律的に署名付き支払い承認を提出し、AWS WAFがそれを検証したうえでコンテンツを提供するという流れだ。
ステーブルコイン決済の流れ
決済はステーブルコイン（USDC）で行われ、サードパーティのファシリテーターサービス（現在はCoinbaseのx402 Facilitator）がオンチェーン上の決済処理を支援する。Stripeによる直接アカウント決済やMachine Payments Protocol（MPP）への対応も近日中に予定されている。コンテンツ所有者は、AWS WAFの設定パネルでウォレットアドレスを指定するだけでよく、独自の決済インフラを構築する必要はない。また、AWS自体は決済手数料を徴収しない。
上記のように、収益化を有効にするとAIボットのアクセスが自動的に402レスポンスに切り替わり、支払いが完了したリクエストだけがコンテンツに到達する。コンテンツ所有者はアクセスを遮断する代わりに料金を設定し、ボットトラフィックを収益源に変えることができる。
収益化の設定手順
プロテクションパックの作成
AIトラフィック収益化を使うには、まずAWS WAF Bot ControlをCommonまたはTargetedレベルで有効にしたうえで、プロテクションパック（Protection Pack）を作成する。プロテクションパックとは、どのコンテンツパスを収益化するか、各検証ティアにいくら課金するか、どの支払い方法を受け入れるかといったポリシーをまとめた設定単位だ。AWSマネジメントコンソールで「WAF & Shield」を開き、「Protection packs (web ACLs)」から作成を開始する。
作成時にアプリカテゴリ（コンテンツ・パブリッシングシステム、Eコマースなど）を選択し、保護対象のリソース（CloudFrontディストリビューション）をひも付ける。推奨ルールパッケージが提示されるが、個別のルールを選ぶことも可能だ。プロテクションパックを作成したら、必要に応じて価格帯や支払い方法、コンテンツ範囲、ライセンス条項をカスタマイズする。
収益化ルールの設定
プロテクションパックを選び、「Configure AI monetization」から検証ティアごとにアクションを割り当てる。アクションは6種類ある。Monetize（402を返し課金）、Allow（無料アクセス許可）、Block（完全遮断）、Count（課金せずログだけ記録）、CAPTCHA（人間の確認）、Challenge（ブラウザかどうかのサイレントチェック）だ。Monetizeを選択すると、支払い決済用のブロックチェーンネットワーク（BaseやSolanaなど）を指定し、ウォレットアドレスとUSDC建てのページ単価を設定する。
Monetizeアクションは、Amazon CloudFrontディストリビューションに関連付けられたWeb ACLでのみサポートされる。リージョナルWeb ACLでは使えない点に注意が必要だ。また、本番投入前にテストモード（Currency modeをTestに切り替え）で、テストネット（Base SepoliaやSolana Devnet）を使った検証が可能となっている。テストモードでも実際の402レスポンスと支払いフローが再現され、すべてのイベントにCurrencyMode: TESTのログが付与される。
この一連の流れは、サイトのオリジンサーバーに一切手を加えることなく、AWS WAFのエッジで完結する。コンテンツ提供者はアプリケーションコードを修正する必要がないため、既存のWebサイトに迅速に収益化機能を追加できる。
AIトラフィック分析ダッシュボードと収益トラッキング
価格設定を最適化するためのAIトラフィック分析ダッシュボードも提供される。プロテクションパックを選択すると、ボットリクエスト全体、AIボットリクエスト、検証済みAIトラフィック、未検証AIトラフィックの4カテゴリに分けてトラフィックを可視化する。帯域幅の消費量、推定月間コスト、ピークリクエストレートといったインフラ影響指標も表示され、パスごとのヒートマップで時間帯別のAIボット集中度がわかる。
Currency modeをRealに切り替えると、「AI access monetization」ダッシュボードで実際の収益をリアルタイムに追跡可能だ。総収益、検証済みボットと未検証ボットの内訳、リクエストあたりの平均単価が表示され、上位の収益ソースやコンテンツパス別の収益ランキングも確認できる。Settlementsタブでは決済プロバイダーごとの精算状況や支払い失敗の分析も行える。
導入のポイントと今後の展望
この機能は、CloudFrontを利用するすべてのAWS WAFユーザーに対して追加料金なしで提供される。ただし、Monetizeを適用できるのはCloudFrontディストリビューションに関連付けたWeb ACLのみである点は押さえておきたい。また、テストモードを活用して本番適用前に価格設定やウォレット設定、x402フローを十分に検証することが推奨される。
今後、Stripeの直接アカウント決済やMPPに対応することで、より多様な支払い手段が利用可能になる見通しだ。AIボットのトラフィックが増え続ける中、コンテンツの価値を適切に回収する仕組みとして、この収益化機能は重要な選択肢となる。自社サイトへのAIクローラーの影響を分析している企業は、まずBot Controlのダッシュボードでトラフィックの可視化から始め、段階的に収益化を検討するのが良いだろう。
この記事のポイント
- AWS WAFにAIボット向け課金機能が追加され、HTTP 402とx402プロトコルでマシンツーマシン決済を実現
- コンテンツパスや検証ティアごとにリクエスト単価を設定でき、ステーブルコインで収益を受け取れる
- 設定はプロテクションパック単位で行い、CloudFront環境のエッジで自律的に課金とコンテンツ配信が完結
- AIトラフィック分析ダッシュボードでコストと収益を可視化し、価格設定を最適化できる
- テストネットを使った検証モードがあり、本番適用前にリスクを評価可能
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AI EngineとJetpackが衝突してGeminiが使えない時の解決策
AI Engine プラグインをバージョン 3.5.5 以降にアップデートすれば、この問題は即座に解決する。根本原因は Jetpack が REST API に追加する整数型 enum フィールドを、Google Gemini がツール定義で拒否していたことにある。AI Engine の開発者がこのスキーマ生成ロジックを修正し、文字列型以外の enum を自動除去するようになった。
どのようなエラーが発生するのか
Desktop Commander で AI Engine を MCP サーバーとして管理モードで接続し、AI モデルに Google Gemini を指定すると、次のようなエラーで通信が失敗する。
「GenerateContentRequest.tools[0].function_declarations[30].parameters.properties[jetpack_publicize_connections].items.properties[status].enum: only allowed for STRING type」という趣旨のエラーが返る。翻訳すると「enum は STRING 型にしか使えない」という厳格な制約に違反した形だ。
管理画面では具体的に「AI Engine が Gemini API からの応答に失敗しました」といった形で表示され、チャットが開始できないか、途中で止まる。管理モードでなければ発生しないエラーだ。
なぜ Jetpack と AI Engine が衝突するのか
核心は Google Gemini API の「ツール定義」に対する極めて厳格なバリデーションにある。Gemini は利用可能な関数のパラメータをスキーマで受け取るが、enum（許容値の固定リスト）を使う場合、そのデータ型を必ず文字列にしなければならない。
一方 Jetpack は、WordPress の投稿作成や更新時に使われる REST API エンドポイントへ、ソーシャルメディア連携用のフィールドを動的に追加している。その中の jetpack_publicize_connections フィールドには status というパラメータがあり、Jetpack はこれを整数型の enum（[0, 1]）として定義している。
AI Engine が WordPress のスキーマ全体を走査して Gemini 向けのツールリストを組み立てる際、この整数型 enum をそのまま継承してしまう。その結果、Gemini API がリクエスト全体を「400 Bad Request」ではねつける流れだ。
読み取り専用モードならば投稿作成系のツールが含まれないため、このエラーは発生しない。管理モードで書き込み権限を付与する場合に限って表面化する。
AI Engine 3.5.5 以降へのアップデートで恒久修正する
AI Engine の開発者によって、バージョン 3.5.5 で根本的な修正が加えられた。ツールスキーマを作成する際、文字列型以外の enum 定義を自動的に除去する処理が追加されている。
スキーマキャッシュのバージョンも同時に引き上げられているため、更新後に手動でキャッシュをクリアする必要はない。自動的に再生成され、Jetpack の整数型 enum は除去された状態でツールリストが構築される。
どうしてもアップデートできない場合の手動修正
何らかの理由で AI Engine を最新版にできない場合、子テーマの functions.php または Code Snippets プラグインに以下のコードを追加し、Jetpack の整数型 enum フィールドを強制的に文字列型へ変換できる。
<?php
/**
* Jetpack と AI Engine、Google Gemini の競合を修正する。
* Jetpack の status enum フィールドを文字列型に変換する。
*/
add_action( 'wp_enqueue_scripts', 'enqueue_parent_styles' );
function enqueue_parent_styles() {
wp_enqueue_style( 'parent-style', get_template_directory_uri() . '/style.css' );
}
add_action( 'rest_api_init', 'fix_jetpack_enum_for_gemini', 9999 );
function fix_jetpack_enum_for_gemini() {
global $wp_rest_additional_fields;
if ( ! empty( $wp_rest_additional_fields ) ) {
foreach ( $wp_rest_additional_fields as $post_type => $fields ) {
if ( isset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections'] ) ) {
if ( isset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status'] ) ) {
// 問題を起こす整数 enum を除去
unset( $wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status']['enum'] );
// データ型を文字列に明示
$wp_rest_additional_fields[$post_type]['jetpack_publicize_connections']['schema']['items']['properties']['status']['type'] = 'string';
}
}
}
}
}
?>コード追加だけでは修正されないケースがある。AI Engine はツールリストをデータベースに強力にキャッシュしているため、キャッシュを強制的に再生成させる必要がある。
Jetpack を無効化した状態でチャットを実行することで、AI Engine は Jetpack 関連フィールドのないスキーマを新規に作成する。Jetpack を再有効化した後は上記のフィルタが働き、問題の enum がスキーマに混入することはなくなる。
よくある質問
Jetpack を使っていなければこの問題は起こらないのか
Jetpack の jetpack_publicize_connections フィールドが原因であるため、Jetpack を導入していなければ発生しない。ただし、他のプラグインも整数型 enum を REST API に追加している場合は似たエラーが出る可能性がある。その場合も AI Engine 3.5.5 以降であれば同様に自動除去される。
読み取り専用モードではなぜ問題ないのか
読み取り専用モードでは、投稿の作成や更新といった書き込み系のツールが Gemini に送信されない。問題の jetpack_publicize_connections フィールドは投稿作成時に登場するため、ツールリストから除外される。管理モードだけが影響を受ける。
AI モデルが Gemini 以外でも同じエラーは出るか
このエラーは Gemini のツール定義バリデーションが特に厳格なために発生する。OpenAI の GPT シリーズなど、他の AI モデルでは整数型 enum を許容するものもあるが、根本原因はスキーマにあるため、どのモデルでも潜在的な問題になりうる。AI Engine 3.5.5 の修正で全モデルに対応できる。
AI Engine 3.5.5 にアップデートした後、スキーマキャッシュは本当に自動クリアされるのか
開発者によれば、スキーマキャッシュのバージョンナンバーが引き上げられているため、更新後の初回リクエスト時に自動的に再生成される。手動でキャッシュを削除する操作は不要。もし不安があれば、AI Engine の設定画面からキャッシュを手動クリアしても問題ない。
この記事のポイント
- AI Engine 3.5.5 以降のアップデートで根本解決する
- 原因は Jetpack の整数型 enum を Gemini が拒否するため
- 読み取り専用モードでは書き込み系ツールが送信されず問題は出ない
- 手動修正する場合は Jetpack 一時無効化によるキャッシュ再生成が必須
- 修正後は文字列型以外の enum が自動除去され、あらゆる AI モデルで安定する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Googleのノンコモディティ方針、ECサイトが取るべきコンテンツ戦略
Googleが2026年5月、AI検索時代を見据えた新しい可視性ガイドラインを公開した。その中核にあるのが「ノンコモディティ・コンテンツ（Non-Commodity Content）」という概念だ。誰にでも書ける凡庸な情報ではなく、書き手自身の経験や独自の視点がにじむコンテンツを評価するという方針である。
Practical Ecommerceの記事によると、この考え方自体は目新しいものではない。Googleは長年にわたりEEAT（経験・専門性・権威性・信頼性）を重視してきた。しかしAIによるゼロクリック検索が急速に台頭する中で、改めて「人間にしか書けないコンテンツ」の重要性が言語化された形だ。
この記事では、Googleの「ノンコモディティ」方針の具体的な内容を整理する。あわせて、ECサイトを運営する事業者やWooCommerceユーザーがこの変化をどう受け止め、どんなコンテンツ戦略を取るべきかを実務目線で解説する。
Googleが定義する「コモディティコンテンツ」とは何か
GoogleのAI可視性ガイドラインは、検索上位を目指すコンテンツを2つに大別している。「コモディティコンテンツ」と「ノンコモディティコンテンツ」だ。まず前者の定義から確認しよう。
誰が書いても同じになる情報
コモディティコンテンツとは、いわゆる「一般的な知識」に基づいて書かれた情報のことだ。具体例としてGoogleが挙げているのが「初めて住宅を購入する人への7つのヒント」といった記事である。この手の内容は、どの書き手が担当しても似たような仕上がりになる。
実務的にいえば、競合他社の記事を参考に構成し、公開データだけを元にまとめた商品比較記事や、製品スペックを並べただけの紹介ページが該当する。生成AIを使えば数分で量産できるタイプのコンテンツだ。
検索におけるコモディティコンテンツの限界
Google検索のインハウスリエゾンであるダニー・サリバン氏は、2026年4月のSearch Central Live Torontoでこのテーマを取り上げている。同氏が示した業界別の対比表を見ると、コモディティコンテンツの問題点がより明確になる。
- ランニングシューズ販売店の場合「ランニングシューズ購入時に考慮すべき10のポイント」
- インテリアデザイナーの場合「2024年に見逃せないキッチントレンド」
これらは情報として誤りではない。しかし、検索エンジンから見れば「どのサイトを上位表示してもユーザー体験に大差がない」と判断されるリスクをはらむ。AIによる回答生成が進むほど、この傾向は強まるだろう。
ノンコモディティコンテンツが評価される理由
一方のノンコモディティコンテンツは、書き手固有の経験や専門知識に裏打ちされた情報を指す。生成AIが簡単に要約したり、出典なしで再利用したりしにくい性質を持つ。
Googleが示した具体例
先のダニー・サリバン氏による業界別の対比表では、ノンコモディティに該当する例として以下が挙げられている。
- ランニングシューズ販売店「なぜこの顧客のシューズは400マイルで壊れたのか、摩耗パターンの分析」
- インテリアデザイナー「大理石 vs ブドウジュース、5人家族に石材を勧めなかった理由」
どちらも実際の顧客対応や施工現場で起きた具体的なエピソードだ。競合が簡単に真似できる内容ではなく、読み手に「この店で買いたい」「このデザイナーに依頼したい」と思わせる力がある。
EEATとの関係性
ノンコモディティという用語は新しいが、背景にある考え方はGoogleが長年重視してきたEEATと重なる。EEATとは「Experience（経験）」「Expertise（専門性）」「Authoritativeness（権威性）」「Trustworthiness（信頼性）」の頭文字を取った評価基準だ。
Practical Ecommerceの記事では、Googleが以前から人間の評価者に対してEEATに基づくサイト評価を指示しており、ランキングアルゴリズムにもヘルプフルコンテンツシステムの一部としてEEATに似た要素が組み込まれている可能性が高いと指摘している。要するに、新しい概念が登場したというより、AI時代に合わせて既存の評価軸を再定義したと見るのが自然だ。
上図の対比からわかるように、ノンコモディティコンテンツは「そのサイトでなければ読めない情報」を提供する。この一点がAI時代の検索評価において決定的な差となる。
ECサイトが取り組むべきコンテンツ戦略
では、WooCommerceをはじめとするECサイト運営者は、この方針転換にどう対応すればよいのか。具体的な打ち手を3つの軸で整理する。
独自データに基づく分析記事
顧客の購買データや問い合わせ履歴を分析し、傾向を記事化する手法はノンコモディティコンテンツの典型例だ。「昨年と比べて20代女性の購入単価が15%上昇した理由」「雨の日に売れる商品トップ5とその背景」といった内容である。
WooCommerceのレポート機能やGoogleアナリティクスのデータを活用すれば、小規模店舗でも十分に独自性のある分析が可能だ。数字と具体的な事例をセットにすることで、読み手の信頼を得やすくなる。
実際の使用例や顧客ストーリー
商品紹介ページに顧客の使用シーンを詳細に盛り込むことも効果的だ。「30代男性がキャンプで3日間使用した感想」「子育て中の女性が選んだ理由と1カ月後の変化」といった具体的なエピソードは、スペック表では伝わらない価値を読者に届ける。
重要なのは、単なるレビュー評価の転載ではなく、店舗スタッフが直接ヒアリングした内容や観察した気づきを文章化することだ。この一手間が、生成AIでは代替できない独自性を生む。
専門家としての見解や実験結果
自社で取り扱う商材について、スタッフが実際に検証した結果を公開する方法もある。「3種類の防水スプレーを実際に試して効果を比較した」「同価格帯の Bluetooth イヤホン5製品を音質測定器でテストした」といった記事だ。
これらは手間とコストがかかるが、検索エンジンからの評価だけでなく、ブランドの信頼構築やリピーター獲得にも直結する。YouTube動画と組み合わせれば、さらに効果は高まるだろう。
コモディティコンテンツが無価値というわけではない
ここまでノンコモディティの重要性を強調してきたが、誤解してはいけない点がある。商品リリース情報や価格改定のお知らせ、採用情報といった「コモディティ的」なコンテンツにも確かな価値は存在する。
読者が求めるなら迷わず発信する
Practical Ecommerceの記事はこの点を明確に指摘している。読者が知りたい情報であれば、それがコモディティコンテンツであっても積極的に発信すべきだ。自社ブランドのファンは新製品の発表を待っているし、既存顧客はメンテナンス情報を必要としている。
直接流入の強化は、結局のところ最も確実なSEO対策である。コモディティかノンコモディティかという区分に過度に縛られるより、まずは目の前の顧客が何を求めているかに集中する姿勢が大切だ。
バランスの取れたコンテンツ設計を
理想的なのは、両方のタイプをバランスよく配置することだ。商品ページはコモディティ的な基本情報をしっかり押さえつつ、ブログ記事ではノンコモディティ的な独自コンテンツで差別化する。この二層構造が、AI検索時代のECサイトに求められるコンテンツ戦略の基本線となる。
WooCommerceサイト運営者が今すぐ始めるべき3つの施策
ここまでの内容を踏まえ、WooCommerceでECサイトを運営する事業者が今日から取り組める具体的なアクションを3つに絞って提案する。
1. 商品説明文に実体験を注入する
メーカー提供のスペック情報をそのまま転載している商品説明ページがあるなら、すぐに手を入れるべきだ。スタッフが実際に商品を使った感想や、想定外の使い方の発見、競合品との微妙な違いなどを追記するだけで、コンテンツの独自性は格段に高まる。
2. 社内ブログに顧客事例カテゴリを新設する
WooCommerceサイトにブログ機能を追加するのは難しくない。そこに「お客様事例」というカテゴリを作り、月1本のペースで実際の顧客ストーリーを掲載していく。許可を得た上で、購入のきっかけや使用後の変化を具体的に聞き取って記事化する。
3. アクセス解析から問いの種を探す
Googleサーチコンソールで自社サイトに流入している検索クエリを確認し、まだ十分に回答できていない質問を特定する。「〇〇 比較」「〇〇 口コミ」「〇〇 使い方」といったクエリに対して、自社の実体験やデータに基づいた回答記事を用意すれば、それがそのままノンコモディティコンテンツになる。
この記事のポイント
- GoogleはAI検索時代に対応するため「ノンコモディティコンテンツ」の重要性を正式に打ち出した
- ノンコモディティとは、書き手固有の経験や専門知識に裏打ちされた、生成AIでは簡単に再現できない情報を指す
- ECサイトでは顧客データ分析、使用事例の詳細な紹介、自社検証記事の公開が有効な差別化策となる
- 読者が求める情報であれば、コモディティ的なコンテンツにも価値はある、バランスが肝心
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
PHP 8.4にしたらmodern-events-calendar-liteで翻訳読み込みエラーが出た時の対処法
PHP 8.4への移行直後にデバッグログへ記録された「_load_textdomain_just_in_time」の通知は、PHPのバージョンが原因ではない。WordPress 6.7で追加された新しい翻訳読み込み機構が、modern-events-calendar-liteプラグインの不適切な翻訳呼び出しを検出し、注意喚起しているだけだ。サイトの動作には影響しないが、デバッグモードを有効にしているとログを埋め尽くす。根本的な解決はプラグインのバージョンアップだが、更新が提供されていなければ数行のコードで通知を抑制できる。
なぜPHP 8.4への切り替え後にこの通知が現れたのか
実際のところ、PHP 8.4と翻訳読み込みの仕組みには直接の関係はない。今回の通知が突然ログに現れたのは、ふたつのタイミングが重なったためだ。ひとつは WordPress 6.7 で導入された「just-in-time翻訳読み込み」機能が、従来よりも厳密にプラグインのコードをチェックするようになったこと。もうひとつは、PHPのバージョンを上げるタイミングでデバッグモード（WP_DEBUG）を有効にした、もしくはデバッグログの出力先を確認したことだ。
つまり、PHP 7.4 の環境でも WordPress 6.7 以降であれば同じ通知は発生していた可能性が高い。PHP 8.4 にしたからといって、追加のエラーが生じたわけではないと捉える必要がある。デバッグログを初めて見たことで、以前から存在していた通知に気づいたという構図になる。
_load_textdomain_just_in_time通知の正体
WordPress 6.7 では、翻訳ファイルの読み込みをできるだけ遅延させる「just-in-time翻訳」の仕組みが強化された。その中核を担うのが _load_textdomain_just_in_time という内部関数だ。この関数は、プラグインやテーマが本来「init」アクション以降に行うべき翻訳ファイルの読み込み（textdomainのロード）を、それより早い段階で実行しようとした場合に検知し、開発者向けの通知を発生させる。
表示されるエラーメッセージの日本語訳は「_load_textdomain_just_in_time 関数が正しく呼び出されませんでした。modern-events-calendar-lite ドメインの翻訳の読み込みが早すぎるタイミングで開始されました。」といった趣旨になる。これは「重大なエラー」ではなく「注意（Notice）」であるため、サイトの表示が崩れたり、機能が停止したりすることはない。
PHP Notice: Function _load_textdomain_just_in_time was called incorrectly. Translation loading for the modern-events-calendar-lite domain was triggered too early. This is usually an indicator for some code in the plugin or theme running too early. Translations should be loaded at the init action or later.
-- デバッグログから当該通知がなくなり、本来のエラーだけが記録される --
上記のBefore/Afterのように、この通知を抑制すればデバッグログがすっきりし、本当に注意すべきエラーを見落としにくくなる。通知の表示自体はWordPress側の仕様変更によるものなので、PHP 8.4にしたからといって新たな不具合が混入したわけではないと理解しておこう。
翻訳読み込み通知を解消する手順
プラグインの更新状況を確認する
まずは、modern-events-calendar-liteプラグインが最新版になっているか管理画面の「プラグイン」一覧から確認する。WordPress 6.7への対応が完了していれば、アップデートを適用するだけで通知は自然に消える。ただし、このプラグインはしばらく大きな更新がないケースもあり、執筆時点では修正が提供されていない可能性が高い。
更新が見つからない場合は次の手順に進む。開発元が対応しないあいだは、ユーザー側で通知を抑える方法を取らざるを得ない。
コードを追加して通知を抑制する
更新が提供されていない場合でも、WordPressのフィルターフックを使って、modern-events-calendar-liteに限って「_load_textdomain_just_in_time」の通知を発生させないようにできる。具体的には、以下のコードをMUプラグイン（Must-Use Plugin）として配置する。
<?php
/**
* Plugin Name: Suppress MEC Translation Notice
* Description: modern-events-calendar-lite の翻訳読み込み通知を抑制する
*/
add_filter( 'doing_it_wrong_trigger_error', function( $trigger, $function_name, $message, $version ) {
if ( '_load_textdomain_just_in_time' === $function_name && false !== strpos( $message, 'modern-events-calendar-lite' ) ) {
return false;
}
return $trigger;
}, 10, 4 );このコードは「doing_it_wrong_trigger_error」フィルターを利用し、問題の関数名とメッセージ内に当該プラグインのテキストドメインが含まれている場合のみ、通知のトリガーを無効にする。他のプラグインやコアの重要なお知らせには影響を与えないため、安全に使える。
設置方法は、wp-content/mu-plugins/ ディレクトリに任意の名前のPHPファイル（例: mec-translation-suppress.php）を作成し、上記コードを貼り付けるだけ。mu-plugins フォルダが存在しない場合は手動で作成する。MUプラグインを使うと、テーマの切り替えや通常のプラグイン管理の影響を受けず、恒久的にフィルターが適用される。
デバッグログを確認する
コードを追加したあと、再度サイトを表示したり、管理画面にログインし直したりすると、それ以降のデバッグログ（wp-content/debug.log）に当該通知が記録されなくなる。念のため、一度プラグインを無効化・再有効化するか、任意のページを表示してからログを確認すると確実だ。通知が消えていれば対処は完了。もし引き続き同じ通知が残っている場合は、ファイルの設置場所やコードの記述ミスを確認する。
よくある質問
この通知はサイトを停止させるのか
停止しない。WordPressの「Notice」レベルの出力であり、サイトの表示やプラグインの動作そのものにはまったく影響を与えない。デバッグモードが有効な環境でのみログに出力されるものなので、訪問者が目にすることもない。
PHP 8.4に戻したほうがいいのか
戻す必要はない。通知はPHPのバージョンに依存せず、WordPress 6.7の仕様に起因する。PHP 7.4はすでにセキュリティサポートが終了しているため、PHP 8.4を使い続けるほうが望ましい。今回の通知を理由にPHPのバージョンを下げるのは誤った判断だ。
他のプラグインでも同じ通知が出る可能性はあるか
十分にある。WordPress 6.7以降、翻訳の読み込みを「init」より前に行っている多くの古いプラグインやテーマで同様の通知が発生する。同じ仕組みで対処したい場合は、上記のコード内の「modern-events-calendar-lite」の部分を該当するテキストドメインに置き換えればよい。
通知を消すコードを使うとほかのエラーも隠れてしまうのか
今回紹介したフィルターは、関数名とメッセージ内容の両方で限定しているため、ほかの「doing_it_wrong」通知には影響しない。別のプラグインやWordPressコアが発する重要な警告は、従来どおりデバッグログに記録される。ただし、全体的な検証のために、テスト環境でコードの動作を確認してから本番に適用するのが安心だ。
この記事のポイント
- PHP 8.4への切り替え後に出た翻訳通知は、PHPのバージョンが原因ではない
- WordPress 6.7のjust-in-time翻訳機能が古いプラグインの不備を検出したもの
- サイトの動作には影響せず、デバッグログに記録されるだけのNotice
- プラグインの更新がなければ、フィルターコードで通知だけを抑制できる
- 通知を抑制しても他の重要なエラーは引き続きログに残る
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
会員制サイトSEOの7つの戦略、ティーザーで制限コンテンツを検索上位に
会員制サイトを運営していると、せっかく質の高いコンテンツを制作しても、Google検索にまったく表示されないという問題に直面しやすい。原因の多くは、価値のある記事やコースがログインページやペイウォールの奥に隠れていることにある。検索エンジンは会員専用エリアをクロールできず、サイト全体のテーマを正しく把握できないのだ。
しかし、コンテンツ保護とSEOはトレードオフではない。適切な設計を施せば、プレビュー部分を検索エンジンに読み取らせつつ、中核の有料コンテンツはしっかり守れる。WPBeginnerがまとめた「会員制サイトSEOの7つの戦略」をもとに、具体的な実装方法を解説する。
会員制サイトのSEO課題と「ティーザーコンテンツ」の考え方
会員制サイトには特有のSEOの壁がある。Googleは公開されている情報だけをインデックスするため、ログイン必須のレッスンやダウンロード資料、会員ダッシュボードの中身は一切読み取れない。一方で、完全に閉ざしてしまうと検索流入を失い、新規会員の獲得機会が減ってしまう。
検索エンジンはゲート付きコンテンツをどう扱うか
Googleは、ログイン前の訪問者にも表示される「公開プレビュー」部分をインデックス可能だ。一方、認証画面の奥にある会員専用ページはクローラーのアクセス対象外となる。この仕組みを逆手に取り、ティーザーコンテンツ（Teaser Content）と呼ばれる一部公開方式を採用するサイトが多い。WPBeginnerの著者も、これが会員制サイトのSEOにおいて最も効果的で安全な手法だと述べている。
ティーザーコンテンツが有効な理由
ティーザーとは、記事の導入部やレッスンの要約、キーポイントなどを会員以外にも公開し、続きはログイン後に読めるようにする仕組みだ。Googleはこの公開部分をもとにページの主題を理解し、検索結果に表示できるようになる。訪問者にとっては内容の魅力を事前に感じられるため、会員登録へのコンバージョン率も向上しやすい。WPBeginnerの実践では、無料の動画コース一覧を誰でも閲覧可能にし、レッスン本体は会員登録後に開放する形で、SEOと会員獲得を両立している。
このデモのように、Googleは公開部分のテキストからページの内容を把握し、ランキング評価に活用する。訪問者にとっては「続きも見たい」というモチベーションが生まれ、会員獲得の導線としても機能する。
ティーザーとコンテンツドリッピングを安全に運用する
ティーザー表示の設定ができたら、次は会員にコンテンツを段階的に提供する「コンテンツドリッピング」について理解しておきたい。これはオンラインコースなどでよく使われる手法で、SEOに悪影響を及ぼさないためにはいくつかの注意点がある。
MemberPressを使ったティーザー公開の設定手順
WordPressで会員制サイトを構築する場合、高い機能を持つプラグインとしてMemberPressが広く使われている。管理画面の「MemberPress」→「ルール」から新規ルールを追加し、保護したい投稿やカテゴリを選択する。その後「アクセス条件」で特定の会員レベルを指定し、「未認証時のアクション」で抜粋の表示を有効にすれば、公開ティーザーが実装できる。
抜粋の長さは200〜300語程度を目安に設定すると、検索エンジンがページ主題を理解するのに十分な情報量を提供できる。WPBeginnerのガイドでは、未認証時に表示されるメッセージに料金ページや登録ページへのリンクを埋め込むことで、コンバージョン向上を図る方法も推奨されている。
コンテンツドリッピングがSEOに与える影響と事前対策
ドリッピングとは、会員登録後の日数経過や特定の日付に合わせて、レッスンを少しずつ開放していく仕組みだ。未解放のコンテンツは検索エンジンからも見えないため、その期間はインデックスされない。しかし、事前にティーザーページやレッスン概要を用意しておけば、後日開放されたときにスムーズにクロールされる。
動画コースの場合は、各レッスンに短いプレビュー動画や書き起こしテキスト、キーポイントをまとめた公開ランディングページを設ける方法が有効だ。WPBeginnerの著者は、これによって開放前から検索エンジンに内容を認識させられると指摘している。
無料コンテンツを拡充して検索トラフィックを底上げする
会員制サイトの運営者の中には、コンテンツの大半をペイウォールの内側に置いてしまうケースがある。だが、それではGoogleがサイト全体の専門性を評価する材料が不足し、オーガニック流入が伸び悩む。実際に成果を上げているサイトは、無料コンテンツを充実させ、そこから有料会員プログラムへと誘導する設計をとっている。
無料と有料の境界線の引き方
無料コンテンツは、幅広い検索キーワードでアクセスを集める役割を担う。一方、有料コンテンツにはテンプレートやワークシート、詳細な実装ガイドなど、より深い価値を置く。WPBeginnerが提示する枠組みでは、初心者向けチュートリアルや統計レポート、業界の基礎知識は無料とし、高度なノウハウや会員限定のツールキットは有料会員向けに保護する。
- 無料コンテンツ：検索ボリュームの大きいキーワードを狙うブログ記事、初心者向け解説、バックリンクを獲得しやすいリソース
- 有料コンテンツ：テンプレート、ワークシート、オンラインコース、会員限定の実装ガイド
このように切り分けると、無料記事で集めた訪問者に「より深い学びを得たければ会員登録を」と自然に促せる。
E-E-A-Tシグナルとキーワード戦略で信頼を構築する
会員制サイトは、専門知識やトレーニングを販売する性質上、訪問者からの信頼獲得が欠かせない。Googleが評価するE-E-A-T（経験、専門性、権威性、信頼性）の観点からも、無料コンテンツを使って実績や実例を示すことが有効だ。WPBeginnerの著者は、実際に自分たちでツールを使い、結果やケーススタディを共有することで、サイトの専門性を高めている。
具体的には、著者プロフィールの充実、会員の声や成功事例の掲載、実際の運用画面の紹介などが信頼構築に役立つ。無料記事にこうしたシグナルを埋め込んでおくと、検索エンジンだけでなく、人間の読者にも「このサイトは信用できる」と感じてもらいやすい。
テクニカルSEOとnoindex設定でクローラーの集中力を高める
どれだけ優れたコンテンツ戦略を立てても、サイトの技術的な土台が整っていなければ、検索順位は伸びにくい。会員制サイトでは特に、ログインページやアカウントページといった「低価値ページ」が検索結果に紛れ込むのを防ぐことも重要になる。
サイトスピードやHTTPSなど基盤のチェックリスト
- HTTPSによるセキュリティ保護とランキングシグナルの確保
- キャッシュプラグインの導入と画像最適化によるサイトスピード改善
- モバイルフレンドリーなデザインの採用
- XMLサイトマップを生成し、検索エンジンにサイト構造を伝える
- リンク切れや404エラーを定期的に検出し修正する
これらの対策は会員制サイトに限らず重要だが、ペイウォールがあるぶん、クローラビリティの健全性を保つ意識がより求められる。
ログインページやアカウントページをnoindexに
会員ログインページやアカウント管理画面、決済完了後のサンキューページなどは、検索結果に表示されてもユーザーにとってほとんど価値がない。むしろ、これらのページがインデックスされると、サイトの評価につながる重要なコンテンツの存在が薄れてしまう可能性がある。
そのため、All in One SEO（AIOSEO）などのSEOプラグインを使って、該当ページの編集画面から「Robots Meta」設定で「No Index」を有効にすることを推奨する。WPBeginnerの著者も、会員向け機能ページはnoindexに設定し、ブログ記事やコースランディングページなどの集客に集中させる方針をとっている。
内部リンクとコンバージョン最適化で会員化を加速する
無料コンテンツで訪れたユーザーを会員登録へと導くためには、サイト内の動線設計が欠かせない。内部リンクを活用して無料記事から有料プランへつなぎ、さらにポップアップやスライドインなどの施策で後押しすれば、SEOで獲得したトラフィックを収益に結びつけられる。
無料記事から有料コンテンツへの自然な導線
ブログ記事で「会員制サイトの始め方」を解説しているなら、記事の途中や末尾に「さらに詳しいテンプレートは会員プログラムでダウンロード可能」といったリンクを設置する。リンクのアンカーテキストは「こちらをクリック」ではなく「会員限定テンプレートを入手する」のように具体的に書くと、クリック率とSEO評価の両面で効果が高い。
- ブログ記事 → 関連する有料コースのランディングページ
- 無料のチュートリアル → 会員限定の上級編トレーニング
- リソースガイド → プレミアムテンプレートのダウンロードページ
内部リンクを張り巡らせると、Googleがサイト構造を理解しやすくなるのに加え、訪問者を収益化ページへ自然に誘導できる。
OptinMonsterによるExit-Intentやスライドインの活用
WPBeginnerの著者が特に効果的だと評価しているのが、OptinMonsterを使った出口検知ポップアップやスクロール連動スライドインだ。MemberPressとの連携機能により、未会員の訪問者だけを対象にキャンペーンを表示できるため、無料トライアルや割引オファーを最適なタイミングで提示できる。
たとえば、記事を最後まで読んだユーザーに対して「続きは会員限定です。今なら初月無料」と表示するスライドインは、押しつけがましくなく自然に感じられる。実際に、WPBeginnerの運営する複数のサイトでも、こうした導線によってメールリストの拡大や会員登録数の増加を実現している。
効果測定の指標とMonsterInsightsでの追跡
会員制サイトのSEO施策が成果を上げているかは、アクセス数だけでなく会員登録数やコンバージョン率で判断する必要がある。MonsterInsightsを使えば、GoogleアナリティクスのデータをWordPress管理画面に取り込み、どの記事が最も会員登録につながっているかを直感的に把握できる。
- オーガニックトラフィックの推移
- ティーザーページへの流入と直帰率
- 会員登録完了ページへの到達数
- バックリンク獲得状況
定期的にこれらの指標を確認し、特に会員登録につながっているコンテンツを強化していくと、施策の費用対効果を最大化しやすい。
この記事のポイント
- 会員制サイトのSEOには、公開ティーザーで検索エンジンに内容を伝える手法が欠かせない
- MemberPressで抜粋表示を設定し、一部のコンテンツを誰でも見られるようにする
- コンテンツドリッピングは事前にティーザーページを用意すればSEO上のデメリットは最小限
- 無料コンテンツで集客し、内部リンクとコンバージョン施策で有料会員へ誘導する
- 会員向け機能ページはnoindexにして、クロールのリソースを重要なページに集中させる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
AnthropicのFable 5が米政府命令で強制停止、SEO業界に衝撃
Fable 5とMythos 5、米国政府の輸出管理命令で突然の利用停止
米国政府は2026年6月13日、国家セキュリティを理由にAnthropicへ輸出管理命令を出し、同社の最新AIモデル「Fable 5」および「Mythos 5」の全利用停止を強制した。命令は外国籍の個人によるアクセスを禁じており、実質的に全顧客の接続を遮断せざるを得ない内容だ。
Anthropicは同日に声明を発表し、政府の見解に反論した。両モデルには強固なセーフガードが重層的に組み込まれており、既存のAIモデルと同等のリスク水準に留まっていると主張している。しかし、命令受領からわずか数時間でFable 5とMythos 5のアクセスは世界中で停止された。
この措置は、SEOやデジタルマーケティングで最先端AIを活用してきた企業・個人に直接的な影響を及ぼす。高性能モデルの急な遮断は、コンテンツ制作フローや競合分析の自動化パイプラインを根底から揺るがすためだ。
このデモでは、Fable 5が突然使えなくなり、SEOワークフローに穴が空く状況を図示している。高性能なモデルに依存していた自動化プロセスは、一気に精度と速度が落ちる。
輸出管理命令の具体的な中身
命令は輸出管理指令と呼ばれる法的措置で、技術やデータの国外移転を制限する。Anthropicはこの命令を「外国籍の者へのアクセスを一切禁じる」と解釈せざるを得ず、結果的に全世界のユーザーが利用不能になった。同社が受けたのは東部夏時間17時21分。ほぼその日のうちに、サービス停止が現実となった。
政府はFable 5のセーフガードを突破する手法があると指摘しているが、Anthropicは提示された事例を「軽微な脆弱性」と一蹴。同社は既に多層防御と厳重なモニタリングでリスクを抑え込んでいる立場だ。
SEO業界が受ける打撃、AI駆動型ワークフローの寸断
Fable 5の急停止は、SEO担当者やアフィリエイトマーケターに具体的な痛みをもたらした。特に月額200ドルの「Claude Max」プランに切り替えたばかりのユーザーからは、返金を求める声がXで相次いだ。新しいモデルを前提にした記事生成や分析タスクが突然止まったためだ。
この流れは、AIモデルをコンテンツ制作パイプラインに組み込んできたSEOチームにとって、サプライチェーン途絶に近い。短納期の記事更新や、多言語でのローカライズ、高度なエンティティ抽出にFable 5を使っていたケースでは、代替モデルへの切り替えに伴う品質低下と工数増加が避けられない。
上のフローは、AIモデルを活用したSEOコンテンツ制作の典型的な手順だ。Fable 5が消失すれば、STEP 1の時点で生産性が大幅に落ちる。
返金要求とMaxプランの混乱
Xの投稿では、多くのユーザーが「Fable 5を使うためにMaxプランに切り替えたのに、当日に遮断された」と訴えている。あるユーザーは「生物学の基本的な質問さえできなかった」と、セーフガードの過剰さを指摘。多額の課金が一瞬で無駄になった苛立ちが広がった。
これはBtoBのSEO支援会社にとっても同様で、クライアント向けのコンテンツをFable 5に依存していた場合、納期の遅延と追加コストが発生する。急速なAI導入が裏目に出る典型例と言える。
国家セキュリティとAI規制、SEOに迫る論点
今回の措置は、AIによるサイバーセキュリティリスクを巡る政府とAnthropicの長年の対立の延長線上にある。Anthropicは大量監視や自律型兵器への技術提供を拒否してきた経緯があり、それが政府の不信感を強めたと見られる。
SEO業界への教訓は単純だ。極めて高性能なAIモデルは、常に地政学的リスクの影響を受ける。特定のベンダーに過度に依存したコンテンツ戦略は、突如として停止する可能性がある。複数のAIプロバイダーを使い分けるマルチベンダー戦略が、今後の安定運用の鍵を握る。
上の図は、リスク分散のためのマルチベンダー構成の一例だ。1つのモデルが遮断されても、他のプロバイダーや自社ホストのモデルでカバーできる。
「強力すぎるAI」を喧伝したツケ
批判の矛先はAnthropic自身にも向いた。同社が長年「極めて強力で危険なAI」と自社モデルを位置付けてきたことが、政府の深刻な受け止めを招いたという指摘だ。Xでは「恐怖をブランドにして政府に輸出管理をかけられ、今更『誤解』と言うのか」と皮肉る投稿が散見された。
SEO担当者にとっては、AIの性能を過大にアピールするマーケティングが規制を早める可能性を認識する契機になる。クライアントや社内で「最強のAIを使っている」と謳う前に、その文言が持つ政治的な重みを考慮すべき局面だ。
SEO戦略に組み込むAIレジリエンス、今後の備え
Fable 5停止のような事態に備え、SEO担当者は次の3つの柱を早急に固める必要がある。第一に、複数AIモデルへのアクセス経路の確保。第二に、AI非依存の編集プロセスとの併用。第三に、オープンソースLLMの社内導入検討だ。
Anthropicは「サービスの早期復旧を目指す」と表明しているが、法的な結末は不透明だ。最悪の場合、最先端モデルへのパブリックアクセスが恒久的に制限される可能性もゼロではない。そのとき、手元に自前の代替手段を持たないチームは、検索順位を維持するための初速で致命的な遅れを取る。
この比較が示す通り、AIに依存するほど、その供給停止がもたらすダメージは大きくなる。今のうちにバックアップのAIパイプラインをテストし、実際に切り替え可能な状態にしておくことが重要だ。
この記事のポイント
- 米国政府の輸出管理命令によりAnthropicのFable 5とMythos 5が全ユーザーに対して突然停止された
- SEO業界では高精度AIを前提としたコンテンツ制作フローが寸断され、返金要求や納期遅延が発生
- 高性能AIのブランディングが規制を呼び込むリスクが現実化した
- マルチベンダー戦略やオープンソースLLMの導入で、AIサービス遮断に強いSEO体制を構築すべき
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WP Rocketのキャッシュ後にモバイルレイアウトが崩れる原因と直し方
WP Rocket のキャッシュ生成後にモバイルレイアウトだけが崩れる場合、Remove Unused CSS（未使用 CSS の削除）や CSS の縮小化（Minify）がレスポンシブ用のメディアクエリや動的クラスを誤って処理している可能性が高い。最初に「未使用 CSS の削除」を無効化するか、モバイル用 CSS を除外設定すれば多くのケースで即座に解決する。
なぜ WP Rocket のキャッシュ後だけモバイル表示が崩れるのか
WP Rocket はサイトの表示速度を上げるため、CSS や JavaScript ファイルを結合・縮小・遅延読み込みする。この最適化処理は強力だが、画面幅に応じてスタイルを切り替えるメディアクエリ（@media）を含むファイルを処理する際に、意図しない形でルールを並べ替えたり削除したりすることがある。
特に問題を起こしやすいのは「未使用 CSS の削除（Remove Unused CSS）」機能だ。この機能はページで実際に使われている CSS だけを抽出して配信する仕組みだが、JavaScript で動的に追加されるクラスや、スクロール位置・タップ操作などユーザーのアクション後に初めて適用されるスタイルを「未使用」と判断して除去してしまう。モバイル表示の崩れは、ほぼこの機能か Critical CSS の生成に起因する。
Cloudflare のキャッシュや Auto Minify が WP Rocket と二重に最適化をかけている場合も、CSS の破損リスクが高まる。キャッシュを両方でクリアしても、最適化処理そのものが走るたびに同じ崩れが再発するのはそのためだ。
■ カラムが重なって文字が読めない
■ ボタンや画像が画面幅をはみ出す
■ WP Rocket の「未使用 CSS 削除」が
@media ルールを除去している■ Critical CSS の再生成と検証
■ Cloudflare 側の二重最適化を停止
■ すべてのデバイスで同一レイアウトを維持
WP Rocket が CSS を処理する流れは、ファイルの読み込み・解析・不要ルールの除去・結合・縮小という順序で進む。このデモは、どの段階でモバイル用のスタイルが失われるかを概念的に示したものだ。
最初に試すべき設定変更と確認手順
未使用 CSS の削除を一時的に無効化する
WordPress 管理画面の「設定」→「WP Rocket」→「ファイル最適化」タブを開き、「CSS ファイル」セクションにある「未使用の CSS を削除（Remove Unused CSS）」のチェックを外す。変更を保存したら、WP Rocket のキャッシュを完全に削除し、Cloudflare を使っている場合は Cloudflare 側のキャッシュもパージする。
シークレットウィンドウまたはキャッシュの残っていない別ブラウザでモバイル表示を確認し、問題が解消したかどうかを判断する。もしこれで直った場合、原因は未使用 CSS の削除処理だと特定できる。
Critical CSS の生成状況を確認する
「未使用 CSS の削除」を有効にしたまま使いたい場合は、Critical CSS（ファーストビュー表示に必要な最小限の CSS）の生成がモバイル用に正しく行われているかを検証する。「WP Rocket」→「ファイル最適化」→「CSS ファイル」セクションにある「クリティカル CSS の最適化（Optimize Critical CSS）」の設定を開き、モバイル向けの Critical CSS が生成されているか確認する。
生成された Critical CSS が不完全な場合、モバイルでのレイアウトが崩れる。一度「クリティカル CSS を再生成」ボタンで再生成し、それでも改善しない場合は、この機能自体をいったん無効化して様子を見る。
CSS 縮小化（Minify）と結合の影響を切り分ける
「未使用 CSS の削除」を無効にしても問題が続く場合、CSS 縮小化（Minify CSS）または CSS 結合（Combine CSS）が原因である可能性を調べる。どちらか一方だけを有効にしてキャッシュを削除し、崩れの有無を確認する。縮小化と結合を両方有効にしていると切り分けができないため、必ず一方ずつ試す。
原因となる機能を特定できたら、その機能だけを無効化するか、次項で説明する除外設定を使って該当 CSS だけを最適化対象から外す方法に進む。
モバイル用 CSS を WP Rocket の最適化から除外する方法
テーマやプラグインが読み込むモバイル用 CSS ファイルを特定し、WP Rocket の除外リストに追加すれば、最適化によるレイアウト崩れを防ぎつつ、他のファイルの高速化は維持できる。
どの CSS ファイルが除外対象かを特定する
ブラウザのデベロッパーツール（F12）でモバイル表示を開き、「ネットワーク」タブで読み込まれている CSS ファイルを確認する。レスポンシブ用のスタイルを含むファイル名には responsive mobile tablet などの文字列が含まれていることが多い。また、テーマのメインのスタイルシート（style.css）の後半に @media ルールが集中している場合は、ファイル全体を除外候補として扱う必要がある。
WP Rocket の除外設定に CSS を追加する
「WP Rocket」→「ファイル最適化」→「CSS ファイル」セクションを開き、「除外する CSS ファイル（Excluded CSS Files）」のテキストエリアに、先ほど特定したファイル名（例: responsive.css mobile.css theme-responsive-min.css）を行単位で入力する。ファイルの URL の一部（例: /themes/my-theme/css/responsive）でも指定できる。
特定の CSS の塊（インラインの @media ブロックなど）だけを除外したい場合は、「未使用 CSS の削除」の設定内にある「セーフリスト（Safe list）」にクラス名や ID を追加する方法も有効だ。たとえば .mobile-menu #responsive-nav .hamburger など、モバイル表示でのみ使われるセレクタをカンマ区切りで指定すれば、そのルールは削除されずに残る。
Cloudflare 側の設定との競合を防ぐ
Cloudflare の「速度」→「最適化」→「Auto Minify」で CSS と JS の縮小化が有効になっている場合、WP Rocket の縮小化と二重がけになって CSS が破損することがある。Cloudflare 側の CSS 縮小化は無効にし、WP Rocket に一本化する。また Cloudflare の「Rocket Loader」も JavaScript の実行順序を変更するため、モバイルでの動的なスタイル適用に悪影響を及ぼす可能性がある。問題が解消しない場合は Rocket Loader も一時的に停止して検証する。
よくある質問
WP Rocket の「モバイルキャッシュ」機能は有効にすべきか
レスポンシブテーマを使っている場合は「モバイルキャッシュを有効にする（Enable caching for mobile devices）」はオフのままで問題ない。この機能はモバイル専用の別テーマ（例：Jetpack のモバイルテーマ）を使っている場合に必要になる設定で、通常のレスポンシブサイトでは有効化するとキャッシュが二重管理されて意図しない表示になることがある。
CSS 縮小化で改行が消えてレイアウトが崩れることはあるか
改行や空白の除去自体が CSS の意味を変えることはほとんどない。ただし、コメント行に書かれた条件付きブラウザ指定（/*! normalize.css */ のような特殊構文）や、不適切に記述された @import 文が縮小化で破損することがある。その場合は該当ファイルを縮小化の除外リストに追加する。
Remove Unused CSS をオフにするとサイト速度は大幅に落ちるか
ページ全体の CSS サイズが極端に大きい場合を除き、体感速度が大きく落ちることは少ない。むしろレイアウト崩れによるユーザー離脱のリスクのほうが深刻だ。未使用 CSS の削除を無効化したうえで、Critical CSS の生成だけを有効にすると、ファーストビューの表示速度を保ちつつ安定したレイアウトを維持できる。
モバイルキャッシュを削除しても直らないのはなぜか
WP Rocket のキャッシュ削除に加えて、Cloudflare のキャッシュ、ブラウザキャッシュ、サーバー側のページキャッシュ（Nginx FastCGI や LiteSpeed Cache など）のいずれかに古いデータが残っている可能性がある。すべてのキャッシュ層を順にクリアしてからシークレットモードで確認する。また、CDN のエッジサーバーにキャッシュが残っている場合もあるため、Cloudflare の「キャッシュ」→「すべてをパージ」を実行したあと最低5分は待ってから検証する。
この記事のポイント
- モバイルレイアウト崩れの主因は「未使用 CSS の削除」と Critical CSS の不完全な生成
- 問題の CSS を特定し WP Rocket の除外リストに登録すれば最適化と両立できる
- Cloudflare の Auto Minify や Rocket Loader との二重がけに注意する
- キャッシュの検証は全キャッシュ層をクリアしたうえでシークレットモードで行う
- モバイルキャッシュ機能はレスポンシブテーマではオフでよい
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている