WordPress 7.1 Mary Louリリース。レスポンシブ対応強化と新メディアエディタ搭載
WordPress 7.1「Mary Lou」が2026年8月19日に正式リリースされた。今回のメジャーアップデートでは、カスタムCSSなしでレスポンシブ対応ができるスタイル機能、新しいメディアエディタ、リッチテキスト対応のNotes機能などが追加されている。800人以上の貢献者による1,500以上の改良と修正が含まれる大規模リリースだ。
従来のWordPressでは、画面サイズごとに表示を調整するにはカスタムCSSを書く必要があった。WordPress 7.1ではサイトエディタ内で完結するため、中小企業のサイト担当者やコーディングに不慣れなユーザーでも直感的にレスポンシブ対応できるようになる。画像処理のブラウザ内実行や新ブロックの追加も見逃せない変更点だ。
WordPress 7.1の全体像と主要な新機能
WordPress 7.1のコードネーム「Mary Lou」は、ジャズピアニストのメアリー・ルー・ウィリアムズに由来する。彼女はスウィング、ビバップ、セイクリッドジャズとジャンルを横断しながら常にサウンドを再発明し続けた。その革新と協働の精神が今回のリリースに反映されている。
リリース全体の規模を見ると、世界中から800人以上の貢献者が参加し、170人以上が初めてコントリビュートした。修正と改良の総数は1,500を超える。主要な変更点は、レスポンシブスタイルのビジュアル編集、管理バーの全エディタ対応、新しいメディアエディタ、Notes機能の拡張、PlaylistとTabsの2つの新ブロック、そして開発者向けAPI群の公開だ。
このデモでは、WordPress 7.1の主要な変更点を分野別に色分けして示している。青がレスポンシブ対応、橙がメディア編集、紫がコラボレーション、緑がパフォーマンス、赤が新ブロックを表す。
今回のリリースの特徴を一言でまとめると、「サイト制作の作業導線を管理画面内に集約する」方向性が鮮明になったことだ。従来はCSSファイルの編集や複数の画面を行き来する必要があった作業が、ブロックエディタやサイトエディタの中で完結するようになっている。特に中小企業のサイト担当者にとっては、外注や開発者への依頼なしで調整できる範囲が広がる。
レスポンシブスタイルと管理バーの改善
カスタムCSSなしのレスポンシブ対応
WordPress 7.1では、サイトエディタのグローバルスタイルと個別ブロック設定の両方にレスポンシブコントロールが追加された。具体的には、デスクトップ・タブレット・モバイルの各画面サイズでブロックの表示をどう変えるかを、ビジュアル操作だけで設定できる。
編集中の画面でビューポート（表示領域の幅）を切り替えながらスタイルを調整できるため、仕上がりを確認しやすい。従来のようにカスタムCSSでメディアクエリを手書きする必要がない。この変更は、コーディングに不慣れなユーザーにとって特に大きな意味を持つ。
このデモでは、従来のカスタムCSSによる対応と、WordPress 7.1のビジュアル編集による対応の違いを示している。上段の赤い枠がBefore、下段の緑の枠がAfterを表す。CSSの記述が不要になり、プレビューを見ながら調整できるようになった点が大きな変化だ。
管理バーがすべてのエディタで表示される
管理バーがサイトエディタを含むすべてのエディタで追従するようになった。投稿執筆中でもサイトデザインの編集中でも、ダッシュボードや関連ツールへのショートカットが常に画面上部に表示される。WordPressの管理画面を行き来する手間が減り、作業導線が分断されにくくなった。
さらに、ブロックテーマではテーマの設定ファイル（theme.json）にタブレットとモバイルのブレークポイントを独自に定義できるようになった。レスポンシブスタイルとブロック表示の切り替えに使う画面幅の基準を、サイトごとに調整できる。
メディア編集の刷新と画像処理の高速化
新しいメディアエディタ
従来はインラインで行われていた画像の切り抜きが、新しいモーダル形式のメディアエディタに置き換わった。自由な切り抜き、アスペクト比を固定した切り抜き、水平・垂直の反転、細かな角度調整ができるスナップ回転、そしてメタデータ編集が1つの専用画面に統合されている。
エントリーポイントは従来と同じ「切り抜き」ボタンのまま。既存の操作感を維持しつつ、機能が大幅に拡張されたかたちだ。画像編集のためにプラグインを追加していたユーザーにとっては、標準機能だけで済むケースが増える。
このデモは、新しいメディアエディタの操作手順を4ステップで示している。青・緑・橙・紫の順に進み、1つのモーダル内で画像編集からメタデータ更新まで完結する流れが分かる。
ブラウザ内での画像処理
画像の圧縮・リサイズ・サムネイル生成が、サーバーではなくブラウザ内で実行されるようになった。libvipsのWebAssemblyビルドを利用しており、大きな画像をアップロードしてもPHPのメモリ制限やアップロードタイムアウトに引っかかりにくくなる。
サーバー負荷の軽減は、共有サーバーや低スペックのレンタルサーバーを利用しているサイトにとって特に有効だ。画像の多いメディアサイトやECサイトでは、アップロード時のタイムアウトエラーが減ることが期待できる。
対応画像形式も拡充された。AVIF、HEIC、HDRゲインマップのネイティブサポートが追加され、最新のスマートフォンやカメラで撮影した画像をそのまま扱えるようになった。GIFを動画に自動変換するオプションもあり、ファイルサイズの削減が進む。
Notes機能の進化とコラボレーション強化
WordPress 7.1では、コンテンツのレビュー作業を支援するNotes機能が大幅に拡張された。従来はブロック単位でしかコメントを残せなかったが、今回から特定のテキスト範囲に対してノートを付けられるようになった。
リッチテキストにも対応した。太字、斜体、コード表示、リンクの挿入がノート内で使える。さらに「@」を入力すると共同編集者をメンションでき、通知が飛ぶ。複数の会話を同じブロック内で並行して進められるほか、長いノートを折りたたんでサイドバーをすっきり保つことも可能だ。
この機能強化は、複数人で記事をレビューする編集部や、クライアントとの校正作業を行う制作会社にとって実用的な価値がある。フィードバックの場所が明確になり、メールやチャットでのやり取りをWordPress内に集約できる。
執筆中の投稿エディタも全テーマでiframe化された。編集キャンバスが管理画面のスタイルから分離されるため、テーマのCSSが管理画面のスタイルと衝突しにくくなる。ビューポート単位やメディアクエリが編集キャンバスを正確に参照するようになり、レスポンシブレイアウトのプレビュー精度が向上した。
新ブロックと開発者向けAPIの拡充
PlaylistブロックとTabsブロック
WordPress 7.1では2つの新しいブロックが追加された。Playlistブロックは複数の音声トラックを1つのプレイリストにまとめて再生できる。オプションで波形表示も付けられ、リスナーは各トラックの長さや進行具合を視覚的に把握できる。
Tabsブロックは、関連する情報をタブ形式で整理するためのブロックだ。すべてのコンテンツを一度に表示するのではなく、タブを切り替えて必要な内容だけを見せる。FAQ、料金プランの比較、製品仕様など、関連情報をコンパクトに提示したい場面で役立つ。
開発者向けAPI群
開発者向けの変更も大きい。SVG Icon APIが公開APIとなり、wp_register_icon_collection()、wp_register_icon()、wp_get_icon()といった関数で独自のアイコンコレクションを登録し、エディタ全体で利用できるようになった。
Abilities APIは前バージョンで導入された基盤を拡張し、フィルタ可能な実行ライフサイクル、カスタムバリデーション、共有ディスカバリーを追加した。WordPress上での統合機能や自動化、AI搭載ツールの構築が容易になる。
新しいDesign Systemは、色、角丸、カーソルスタイルを含むWordPress管理画面のテーマリングを支援する。開発者はセマンティックなデザイントークンとThemeProvider Reactコンポーネントを使って、WordPressに馴染むカスタム管理画面を構築できる。
テーマ開発者には、theme.jsonでレスポンシブスタイルと疑似状態（hover、focus、focus-visible、active）のスタイリングが可能になった。DataViewsとDataForm画面を設定する新しいフィルタも追加され、サイトエディタのページ・テンプレート・パーツ管理画面をカスタマイズできる。
パフォーマンスとアクセシビリティの改善
パフォーマンス面では、前述のブラウザ内画像処理に加えて、GIFから動画への自動変換が導入された。GIFアニメは動画ファイルよりサイズが大きくなりがちで、この変換によりページの読み込み速度が改善する。アップロードの進捗インジケーターと自動リトライも追加され、接続が途中で切れてもアップロードが再開できるようになった。
メディアライブラリはデフォルトで無限スクロールになった。ページネーションに戻すオプションもユーザーごとに用意されている。多数の画像を扱うサイトでは、ページを切り替える操作なしで目的のメディアを探しやすくなる。
Speculative loadingのデフォルト設定を、環境変数や定数で指定できるようになった。ホスティング事業者やサイト運営者は、プラグインを書かずにWordPressの先読み動作を設定できる。これはサイト速度の調整手段として、特にトラフィックの多いサイトで有用だ。
アクセシビリティの改善も続いている。wp_get_tooltip()とwp_get_toggletip()という新しい関数が追加され、投稿メタボックスやログイン画面を含む管理画面の各所でアクセシブルなツールチップを利用できるようになった。スクリーンリーダーのサポートも強化され、投稿一覧テーブルでのラベル付けとナビゲーションがより予測しやすくなっている。
この記事のポイント
- WordPress 7.1「Mary Lou」が2026年8月19日にリリースされた
- カスタムCSSなしでレスポンシブスタイルを設定できるようになった
- 新しいメディアエディタが切り抜き・反転・回転・メタデータ編集を統合
- 画像処理がブラウザ内で実行され、サーバー負荷とタイムアウトが軽減された
- Notes機能がリッチテキストとメンションに対応し、コラボレーションが強化された
- PlaylistブロックとTabsブロックが標準搭載された
- 開発者向けにSVG Icon API、Abilities API、Design Systemが公開された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressでHTTPS切替後に画像やメニューが崩れる時の直し方
WordPressサイトをHTTPからHTTPSへ切り替えた直後に、メニューが反応しない、画像ギャラリーが表示されない、ページレイアウトが崩れるといった症状が出る場合は、データベース内に残った「http」形式のURLが原因だ。Better Search Replaceというプラグインで旧URLを一括置換し、ElementorのCSSを再生成すれば解消できる。
なぜHTTPS切替後にサイト表示が崩れるのか
HTTPSへ切り替えただけでは、WordPressのデータベースに保存された古いURLは自動的に更新されない。投稿本文やメタ情報、ウィジェット設定、ElementorのCSSファイル内に「http」形式のURLが残ったままになるためだ。
ブラウザはHTTPSページの中にHTTPの画像やスクリプトが混在している状態を「混合コンテンツ」と呼び、セキュリティ上の理由で読み込みをブロックする。この結果、画像が途中で消える、メニュークリックが反応しない、ギャラリーのスライドが止まるといった症状が起きる。
HTTPとHTTPSが混在するとブラウザがリソースをブロックする仕組みのデモ。
Better Search Replaceでデータベースを一括置換する手順
壊れたURLを手作業で直す必要はない。Better Search Replaceという無料プラグインを使えば、データベース内のすべての「http」形式のURLを「https」形式に一括で置換できる。事前に必ずバックアップを取っておくこと。
Better Search ReplaceによるURL置換の全体の流れのデモ。
バックアップが最優先だ
置換操作はデータベース全体に影響を与えるため、失敗すると復旧が難しくなる。必ずプラグインやサーバー側のバックアップ機能で、データベースとファイルの両方を取得してから作業する。
検索と置換のURL指定を間違えない
検索フィールドには「http、自サイトのドメイン」、置換フィールドには「https、自サイトのドメイン」を入力する。ドメインの前後やスラッシュの有無を間違えると置換が正しく行われないため、コピーアンドペーストで正確に入力するのが安全だ。
置換後の確認ポイント
置換が完了したら、ブラウザのシークレットモードでサイトを開き、画像やメニューが正常に表示されるか確認する。管理画面の「設定 → 一般」に記載されたURLもHTTPSになっているか合わせてチェックする。
WordPress設定とElementorを修復する手順
データベースの置換後も、WordPressの「一般設定」に記載されたサイトURLとWordPress URLが正しいHTTPS形式になっているか確認する必要がある。管理画面にログインできる場合は、設定画面から変更するだけでよい。
管理画面に入れなくなった場合はphpMyAdminから修正する
URLを誤って書き換えてログインできなくなった場合は、サーバーの管理画面からphpMyAdminを開き、wp_optionsテーブルの「siteurl」と「home」の2つの値を正しいHTTPSのURLに戻す。これでWordPressに再ログインできる。
ElementorのCSSを再生成する
ElementorはCSSを自動生成して保存しているため、URL変更後はこのCSSが古いHTTPのURLを参照したままになることがある。Elementorの設定画面から「CSSを再生成」を実行し、合わせて「Elementorのデフォルト設定を更新」も確認する。
ElementorのCSS再生成の手順と修復後の状態のデモ。
置換しても直らない場合の追加対策
一括置換後にキャッシュやサーバー設定が原因で症状が残ることがある。順番に確認していくことで、残りの問題を特定できる。
ブラウザのデベロッパーツールで混合コンテンツを探す
ChromeやEdgeのデベロッパーツール（F12）を開き、コンソールタブを確認する。「Mixed Content」という警告が出ていれば、まだHTTPのURLが残っている。該当するURLをメモし、Better Search Replaceで追加の置換をかける。
キャッシュ系プラグインとサーバーキャッシュを削除する
キャッシュプラグイン（WP Super CacheやW3 Total Cacheなど）が古いHTTPのページを保存していると、データベースを置換しても表示が変わらない。プラグインの設定からキャッシュを全削除し、あわせてサーバー側のキャッシュも管理画面からクリアする。
htaccessでHTTPをHTTPSへリダイレクトする
WordPressサイトのルートにあるhtaccessファイルに、HTTPアクセスをHTTPSへリダイレクトする設定を追加する。これにより、古いHTTPのURLにアクセスしても自動的にHTTPSへ転送され、検索エンジン評価の分散も防げる。不安であればサーバー会社のサポートに設定を依頼してもよい。
よくある質問
Really Simple SSLプラグインでは直らないのか
Really Simple SSLはHTTPSへのリダイレクトと、管理画面のURL更新を自動で行うプラグインだ。ただし、データベース内のすべてのHTTP URLを置換する機能は制限版では一部に限られる。画像やElementorのCSSに残るURLを完全に直すには、Better Search Replaceによる一括置換が必要になる。
置換後にログインできなくなったらどうするか
URL設定を誤るとログアウトして再ログインできなくなることがある。その場合はphpMyAdminからwp_optionsテーブルの「siteurl」と「home」を正しいHTTPSのURLに戻す。これで管理画面に再アクセスできる。
置換しても一部の画像が表示されない場合は
置換後の画像不表示は、キャッシュが古いHTTPのページを返しているか、CDNや外部サービスが元のURLを参照している可能性がある。キャッシュを全削除し、CDNを利用している場合はCDN側のキャッシュもクリアする。
HTTPS化後のSEOへの影響はあるのか
HTTPS化はGoogleのランキングシグナルとして評価されるため、正しくリダイレクトを設定すればSEOにはプラスに働く。サイト側でHTTPとHTTPSが両方アクセスできる状態を放置すると評価が分散するため、リダイレクト設定まで済ませておく。
Elementorで編集画面が真っ白になった場合は
URL変更後にElementorの編集画面が読み込めない場合は、CSS再生成とあわせて「Elementorのデフォルト設定を更新」を実行する。さらにWordPressのパーマリンク設定を一度「保存」して書き換えることで、内部リンク構造がリフレッシュされる。
この記事のポイント
- HTTPS切替後もデータベースにHTTPのURLが残り、混合コンテンツとしてブロックされる
- Better Search Replaceでhttpからhttpsへ一括置換する
- 置換前に必ずフルバックアップを取る
- ElementorはCSS再生成とデフォルト設定の更新が必要
- キャッシュ削除とリダイレクト設定で仕上げる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressの__GA_INJ_START__マルウェア感染を完全駆除する手順
WordPress のテーマファイル functions.php に「__GA_INJ_START__」というコメント記述を見つけたら、Google Analytics を装ったマルウェア感染の可能性が高い。完全に駆除するには、functions.php を元に戻すだけでは不十分で、データベースに潜む隠し管理者アカウントの削除と侵入経路の遮断まで行う必要がある。
__GA_INJ_START__マルウェアとは何か
このマルウェアは、テーマの functions.php 内に不正なコードを注入する際、開始位置の目印としてコメント文「__GA_INJ_START__」を書き込む。Google Analytics の計測タグに似せた外見のため、コードをざっと見ただけでは正規のトラッキングコードと勘違いしやすい。
実際に注入されるコードは、Google Analytics とは無関係の永続的なバックドアとして働く。具体的には、不正な管理者アカウントを定期的に生成したり、攻撃者が自由にサイトへ再侵入するための隠し経路を維持する機能を持つ。コード自体が自己修復的に動くこともあり、単に該当部分を削除しても再び書き戻されるケースがある。
感染の典型的な流れは、まず正規の WordPress 管理者アカウントへ何らかの方法でログインし、管理画面内のファイル編集機能やコードスニペット系プラグインを経由して functions.php に到達する。その段階で不正な管理者アカウントを追加し、数日から数週間かけて隠しアカウントを増やした後、最終段階として __GA_INJ_START__ 付きのコードがテーマに注入される。
このデモは侵入から感染完了までの典型的な進行パターンを示している。攻撃者は一度管理者権限を得ると、すぐに目立つ改ざんを行うのではなく、まず隠しアカウントを作って持続的なアクセスを確保するのが特徴だ。
隠し管理者アカウントをどうやって見つけるか
このマルウェアに感染したサイトでは、データベース内に通常では一覧に表示されない形で不正な管理者アカウントが追加されている。管理画面のユーザー一覧に表示されない場合もあるため、phpMyAdmin などでデータベースを直接確認するのが確実だ。
まず wp_users テーブルを開き、ユーザー名に不審な接頭辞が付いていないかを確認する。具体的には sync_agent、cdn_worker、seo_service の後にランダムな英数字が続く形式のアカウントが典型的だ。テーブルプレフィックスが wp_ 以外の場合は、その文字列に読み替えて探す。
次に wp_usermeta テーブルで、該当ユーザー ID に administrator 権限を付与するエントリが存在するかを調べる。さらに wp_options テーブルには __ga_hidden_users、_theme_inject_status、__ga_r_cache という見慣れないキーが保存されていることがある。これらのキーはマルウェアが隠し管理者の一覧を管理するために使う。
サーバーに SSH でログインできる環境なら、ファイルシステム全体を横断検索するのが最も早い。以下のコマンドでマルウェア特有の文字列を探せる。
grep -RniE '__GA_INJ|__ga_hidden_users|__ga_r_cache|_theme_inject_status|sync_agent|cdn_worker|seo_service' .SSH が使えない場合は、FTP でファイルをダウンロードしてエディタの検索機能を使うか、運営中のレンタルサーバーが提供するファイルマネージャの検索機能を活用する。また、WordPress 管理画面から有効化されているプラグイン一覧を確認し、心当たりのないプラグインが増えていないかも必ず調べる。
マルウェアを完全に駆除するにはどうすればいいか
重要なのは、functions.php を置き換えるだけでは駆除できないという点だ。隠し管理者アカウントとバックドアをすべて取り除くまで、攻撃者は何度でも再侵入できる。以下に駆除の全体フローを示す。
このデモは駆除作業の全体像を示している。以下、各ステップの具体的な進め方を詳しく解説する。
バックアップを必ず先に取得する
駆除作業ではデータベースのレコード削除やファイルの書き換えを行うため、操作を誤るとサイトが壊れる恐れがある。作業前にデータベースとファイルの両方を丸ごとバックアップしておく。レンタルサーバーにバックアップ機能が付属している場合も、念のため別の場所にもコピーを保存する。
隠し管理者アカウントをデータベースから削除する
phpMyAdmin などで wp_users テーブルを開き、不審なユーザー名のレコードを特定する。sync_agent、cdn_worker、seo_service にランダムな英数字が付いた形式が典型だが、まったく別の名前で偽装している可能性もある。新規登録した覚えのない管理者権限ユーザーはすべて削除対象だ。
ユーザーを削除する際、wp_usermeta テーブルに残った関連エントリも忘れずに削除する。SQL を直接実行する場合は、該当ユーザー ID を指定して両テーブルからレコードを消す。操作前に必ずバックアップを取り、プレビュー画面で対象レコードを確認してから実行する。
functions.php の不正コードを除去する
テーマの functions.php をエディタで開き、__GA_INJ_START__ から始まるコメントと、それに続くコードブロックを特定する。__GA_INJ_END__ または類似の終了マーカーがある場合は、その範囲全体を削除する。マーカーが無い場合は、不審な関数定義や管理者アカウントを操作するコードを丁寧に確認しながら取り除く。
該当テーマが親テーマなら、修正がテーマ更新で失われないよう子テーマ化を検討する。また、他のテーマファイルや wp-content 直下の PHP ファイルにも同じマーカーが仕込まれている可能性があるため、前述の grep コマンドで全ファイルを横断検索してから作業するのが安全だ。
セッションとパスワードをリセットする
攻撃者が既存のセッションを保持していると、アカウントを消してもアクセスが続く。WordPress の管理画面からユーザー一覧を開き、すべての管理者ユーザーに対して「全てのセッションを破棄」を実行する。さらに全管理者のパスワードを新しいものへ変更する。可能ならメールアドレスも再確認し、見覚えのない転送設定が無いか調べる。
アクセスログから感染時期を特定するにはどうするか
__GA_INJ_START__ が functions.php に現れた日が感染開始日とは限らない。実際には、その数日前から数週間前にかけて攻撃者が隠し管理者アカウントを作り、段階的に足場を固めていたケースが多い。駆除後に再発を防ぐには、感染の起点となった脆弱性や認証情報を特定することが欠かせない。
まずデータベースの wp_users テーブルで、不正な管理者の登録日時を確認する。WordPress はユーザー作成日時を user_registered カラムに記録している。次にサーバーのアクセスログを同じ期間分さかのぼり、wp-login.php へのログイン試行や、admin-ajax.php、theme-editor.php などへの不審なアクセスが無いかを照合する。
攻撃者が最初に正規の管理者アカウントでログインしていた場合、ログには正常なログインとして記録されているため見落としやすい。ログイン元 IP アドレスの突発的な変化、深夜帯のログイン、短時間での連続したファイル編集操作などを手がかりにする。ログの保存期間が短いレンタルサーバーでは、可能な範囲でログ保管期間を延ばしておくと今後の調査に役立つ。
再感染を防ぐには何をすればいいか
駆除が完了しても、侵入経路が残っていれば同じ手口で再び感染する。再発防止には、まず WordPress 本体、テーマ、プラグインを最新版へ更新する。侵入経路として悪用された可能性のあるファイル編集系プラグインやコードスニペット系プラグインは、使用していないなら削除する。
管理者アカウントに対しては二段階認証を有効にし、パスワードは推測されにくい長いものへ変える。管理画面へのアクセスを IP アドレス制限で絞るのも効果的だ。さらに wp-config.php にファイル編集機能を無効化する定数 DISALLOW_FILE_EDIT を追加すると、管理画面からテーマやプラグインのコードを書き換えられる経路を塞げる。
定期的な点検も重要になる。ユーザー一覧に知らない管理者が増えていないか、wp_options に見覚えのないキーが無いか、functions.php などのテーマファイルに不審なコメントが追加されていないかを毎月確認する。可能ならセキュリティプラグインによる定期スキャンを導入し、変更検知の通知を受け取れるようにしておく。
functions.php に __GA_INJ_START__ が注入され、データベースには sync_agent や cdn_worker などの隠し管理者が存在する。攻撃者はいつでも再侵入できる状態。
不正コードが除去され、隠し管理者はデータベースから完全に削除済み。パスワードとセッションもリセットされ、更新も適用されている。
このデモは駆除前後の状態を対比したものだ。感染状態ではマルウェアの目印と隠し管理者が残っているが、駆除後は不正な要素がすべて取り除かれている。
よくある質問
__GA_INJ_START__はGoogle Analyticsの正規コードではないのか
正規の Google Analytics 計測コードにこのようなマーカーは存在しない。__GA_INJ_START__ は不正なコードの開始位置を示す目印で、マルウェアが後からコードを書き戻す際の識別子として使われる。テーマファイルにこの文字列を見つけたら感染を強く疑うべきだ。
隠し管理者アカウントはデータベースのどこを確認すれば見つかるか
wp_users テーブルと wp_usermeta テーブルの両方を確認する。ユーザー名が sync_agent、cdn_worker、seo_service にランダムな英数字が付いた形式なら要注意だ。さらに wp_options テーブルに __ga_hidden_users や _theme_inject_status などの見慣れないキーが無いかも調べる。
セキュリティプラグインを導入しているのに感染したのはなぜか
プラグインが検出できるシグネチャを持たない新種や変種だった、定義が古かった、正規の管理者としてログインしてから活動したため不正ログインと判定されなかった、などの理由が考えられる。プラグインに頼るだけでなく、定期的なユーザー一覧やファイルの目視確認も併用する。
感染後、サイトを公開したまま駆除作業はできるか
推奨されない。攻撃者がバックドアを持っている間、サイトを公開し続けると訪問者の情報が窃取されたり、別の攻撃の踏み台にされたりする恐れがある。可能ならメンテナンスモードに切り替え、バックアップを取ってから作業するのが安全だ。
駆除後にサイトが真っ白になった場合の対処方法は？
デバッグモードを有効にしてエラー内容を特定し、テーマやプラグインを一つずつ有効化して切り分ける。テーマの functions.php を編集した際に記述ミスがあると画面が真っ白になることが多い。感染前のバックアップがあれば、その時点から修復する方が確実な場合もある。
この記事のポイント
- __GA_INJ_START__はGoogle Analyticsを装ったマルウェアの目印
- 隠し管理者アカウントはデータベースを直接確認しないと見落とす
- functions.phpの置き換えだけでは再感染する
- アクセスログを数日〜数週間さかのぼって感染起点を探す
- 駆除後は全パスワード変更とセッションリセットが必須
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
EUのAIラベリング規則が8月2日施行。サイト運営者が知るべき4つの義務
EUでAI生成コンテンツのラベリング義務が2026年8月2日から始まった。対象はディープフェイク、チャットボット、完全AI生成テキスト、感情認識ツールの4種類に絞られる。
この規則はEU企業に限らない。EU圏のユーザーにAI出力を提供する世界中の企業が対象になる。つまり、日本語のサイトでもEUからのアクセスがあれば義務を負う可能性がある。
違反時の罰則は各国の監督機関が定めるが、GDPRと同様に高額な制裁金が科される可能性がある。AI生成コンテンツを公開するサイト運営者は、対象範囲と正しい表示方法を押さえておきたい。
ラベリング義務の対象は4つに絞られる
EUのAI法第50条(4)に基づく透明性義務では、ラベリングが必要なケースを4種類に限定している。すべてのAI生成コンテンツにラベルが必要なわけではない点が重要だ。
この4つのカテゴリに該当するAI生成物を提供する企業は、プロバイダー（AIシステムの開発・供給者）とデプロイヤー（利用者）の双方が法的義務を負う。外部製AIツールを使っていても免責にはならない。
ディープフェイクは「本物らしさ」が判断基準
ディープフェイクに該当するのは、実在の人物、物体、場所、出来事に似せていて、本物だと誤認させる画像・音声・動画だ。逆に、明らかにフィクションとわかるものや、本物らしく見せていないコンテンツは対象外になる。
広告やマーケティングで使うAI生成の商品画像、人物写真、ポスターも、実在のものに似せている場合は開示が必要になる。特にECサイトの商品画像には注意したい。
完全AI生成テキストは「公共の利益」が条件
完全にAIが書いた文章のラベリング義務は、公共の利益に関する事項が対象だ。公共の利益とは、健康、安全、環境、経済、金融、政治、科学、文化などを指す。人間による実質的な編集がない場合に開示が必要になる。
通常のブログ記事や商品説明でも、内容が健康や金融など公共性の高いテーマに触れる場合は対象になり得る。一方、単なる日記や創作は対象外だ。
人間が編集すればラベル不要になる境界線
「AIで下書きを作り、人間が編集した」場合、どこからラベルが必要になるのか。EU委員会のガイダンスでは、軽微な編集と実質的な編集の境界線が示されている。
文章の言い回しを微調整する程度ならラベル不要だが、文章全体をAIに生成させた場合は開示が必要になる。「公開前に人がざっと目を通した」だけでは実質的な編集とは認められない。
実務での判断ポイント
EUのガイダンスは、編集責任者を明示した上で実質的な編集管理を行うことを求めている。つまり、誰が責任を持って内容を確認し、修正したのかという記録が重要になる。
WordPressサイトでAI生成下書きを使う場合は、編集フローを整備しておくとよい。人間による確認作業を経た記事と、AI出力をそのまま公開する記事を区別し、後者にはラベルを付ける運用が現実的だ。
スパークルアイコンだけでは不十分
多くの製品がAI機能を示すために使うスパークル（✨）アイコンは、EUの要件を満たさない可能性が高い。スパークルは「AI搭載機能」という意味で使われることが多く、「この特定のコンテンツがAI生成」という意味にはならないからだ。
EUは公式のAIアイコンセットを公開している。これは「AI」の文字を含む専用バッジで、スパークルとは異なる。ただし、アイコンを使うだけでは法的準拠にはならない。アイコンは明確に見え、プレーンテキストと併用し、支援技術からアクセスできる必要がある。
適切なラベルの表示方法
EUのガイドラインでは、アイコンが小さすぎる、フッターに埋もれている、一瞬だけ表示される、といったパターンはすべて不適合とされる。ラベルはコンテンツの近くに常時表示し、共有やダウンロード後も保持される必要がある。
サイトでAI生成画像を掲載する場合は、画像の近くに「AI生成」というテキストラベルを置くのが現実的だ。altテキストにも「AI生成画像」と記載しておくと、スクリーンリーダー利用者にも伝わる。
世界で同時多発するAIラベリング規制
今回のEU規則は単独の動きではない。中国、カリフォルニア州、韓国、インドでも同様のAIラベリング規制が相次いで施行されている。
- 中国では2025年9月1日からAIコンテンツの表示義務が始まっている
- 米カリフォルニア州のSB 942はEUと同じ2026年8月2日に施行された
- 韓国ではAI基本法が2026年1月22日に施行され、ディープフェイク表示を義務化
- インドではIT規則改正により2026年2月20日から合成情報のラベル表示が必須になった
各国の規制は細部が異なるが、方向性は同じだ。AIが生成したコンテンツが人間の制作物と誤認される場合、明確に開示するという共通パターンが浮かび上がる。
サイト運営者が今からできる準備
AI生成コンテンツを扱うサイト運営者は、まず自社サイトでどの部分がAI生成に該当するかを棚卸しするところから始めたい。特に、商品画像、チャットボット、自動生成されるブログ記事、AIによる要約表示などが対象になる。
次に、ラベルの表示ルールを整備する。AI生成コンテンツには「AI生成」というテキストラベルと公式アイコンを併用し、目立つ位置に配置する。WordPressの場合はテーマのテンプレートやカスタムフィールドを使って、AI生成フラグを管理する方法もある。
最後に、編集フローを文書化しておく。人間が実質的に編集した場合と、AI出力をそのまま使った場合を区別し、後者だけにラベルを付ける運用にすると、無駄なラベル表示を避けられる。
この記事のポイント
- EUのAIラベリング義務は2026年8月2日から施行され、EU圏のユーザーにAI出力を提供する全世界の企業が対象
- ラベリングが必要なのはディープフェイク、チャットボット、完全AI生成テキスト（公共の利益）、感情認識ツールの4種類
- 人間が実質的に編集したAI生成コンテンツは開示不要。軽微な編集はAI生成に該当しない
- スパークルアイコンだけでは不十分。公式アイコンと「AI生成」というテキストラベルを併用する
- 中国、カリフォルニア、韓国、インドでも同様の規制が始まっており、サイト運営者は早めの対応が求められる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Two-Factor 0.15.0で2FAコードが無効になる時の対処と原因
Two-Factor プラグインを 0.15.0 に更新後、認証アプリのコードが「無効な確認コード」と拒否される場合、一時的に 0.14.2 へ戻すのが最も確実な対処だ。並行してサイト環境とプラグインの互換性を確認し、根本原因を切り分ける。
なぜ 0.15.0 で 2FA コードが無効になるのか
Two-Factor 0.15.0 では認証コード検証の内部処理が見直された。その結果、特定の環境で「それまで使えていたコード」が突然拒否される症状が報告されている。すべてのサイトで起こるわけではなく、PHP バージョンや共存プラグインの組み合わせが影響する。
典型的なエラーは「ERROR: Invalid verification code.」だ。日本語環境では「無効な確認コード」と表示されることが多い。認証アプリ側の時刻ずれではないのに毎回弾かれる場合、プラグイン側の検証処理が疑わしい。
0.14.2 では問題なくログインできていたなら、ユーザーが設定した秘密鍵そのものは生きている。鍵の保存形式やハッシュ計算の互換性が 0.15.0 で崩れた可能性が高い。
このデモは、バージョン更新前後の認証結果の違いを概念的に示したイメージだ。
まず 0.14.2 に戻してログインを復旧する手順
複数ユーザーが締め出されているなら、何より先にアクセスを回復する。0.15.0 を無効化し、0.14.2 を入れ直す手順を紹介する。
管理画面に入れる場合の戻し方
管理者自身はログインできる場合、プラグイン画面から操作できる。ただし 2FA が有効なサイトでは、管理者もログイン時にコードを要求される点に注意する。
- 「プラグイン」→「インストール済みプラグイン」で Two-Factor を無効化する
- プラグインを削除する
- 「新規プラグインを追加」から Two-Factor を検索する
- バージョン 0.14.2 をダウンロードしてインストールする
バージョンを指定してインストールするには、WordPress.org のプラグインページにある「詳細」画面下部の「旧バージョンをダウンロード」から取得できる。
管理画面に入れない場合の対処
管理者も含めて誰もログインできない場合、FTP またはサーバーのファイルマネージャーからプラグインフォルダーを操作する。
- FTP で
wp-content/plugins/に接続する two-factorフォルダーを一時的にリネームする（例two-factor-old）- ログイン画面から通常のパスワードのみで入れるようになる
- その後、管理画面から 0.14.2 を再インストールする
このデモは、管理画面に入れない状態から復旧するまでの手順を示している。
ログインできた後に確認すべき環境要因
アクセスを回復したら、なぜ 0.15.0 だけが問題を起こすのかを切り分ける。同じプラグインを更新しても、環境によっては正常に動くケースがあるためだ。
PHP のバージョンと拡張
0.15.0 は PHP 8.4 系で問題が出た事例がある。一方、8.3 系で動いているサイトでは同じ更新が成功する報告もある。PHP のバージョンだけでなく、ハッシュ計算に関係する拡張機能の有無も差を生む。
レンタルサーバーの管理画面から PHP バージョンを確認し、可能なら 8.3 系へ一時的に切り替えて 0.15.0 の動作を試す。ただし、PHP を変更すると他のプラグインやテーマに影響するため、事前にバックアップを取ってから実施する。
WPML など多言語プラグインとの共存
複数ドメインで動かす WPML 構成では、認証に関係する URL やクッキーの扱いが変わる。0.15.0 でこれが悪さをした可能性も考えられる。WPML を使っているサイトで問題が再発するなら、Two-Factor と WPML の両方の設定を見直す。
認証アプリ側の時刻と再同期
「無効な確認コード」は時刻ずれでも起きる。認証アプリの「設定」から時刻の同期を行い、それでも 0.15.0 だけが通らない場合は時刻ずれではないと判断できる。
バージョン固定と更新タイミングの判断
0.14.2 で問題が起きていないなら、修正版が出るまで 0.14.2 に固定するのが実務的だ。ただし、セキュリティプラグインの古いバージョンを長期間使い続けるのは望ましくない。公式の変更履歴とサポートフォーラムを確認し、修正版が出たら速やかに更新する。
プラグインの自動更新が有効だと、意図せず再び 0.15.0 に上がる恐れがある。更新を止めるには、プラグインの自動更新設定をオフにするか、サイト全体の更新管理を見直す。
このデモは、0.15.0 を避ける運用方法と注意点を整理したものだ。
よくある質問
0.15.0 で一部のユーザーだけログインできないのはなぜ？
ユーザーごとに秘密鍵の保存形式が異なる可能性がある。古いバージョンで作成された鍵と新しい検証処理の相性が悪く、特定のユーザーだけ弾かれることがある。
0.14.2 に戻してもユーザーに再設定してもらう必要はある？
通常は必要ない。0.14.2 に戻せば、以前作成した認証情報とアプリのコードがそのまま使える。再設定を求めるのは、認証情報が壊れている場合に限られる。
認証アプリのコードが「無効な確認コード」になる他の原因は？
サーバーと端末の時刻ずれ、秘密鍵の保存不備、キャッシュによる画面の不整合などが考えられる。まず認証アプリの時刻同期を行い、その後プラグインのバージョンを確認する。
0.15.0 の修正版はいつ出る？
リリース時期は未定だ。公式のプラグインページとサポートフォーラムの更新を確認する。修正版が出るまでは 0.14.2 固定が安全だ。
この記事のポイント
- Two-Factor 0.15.0 で 2FA コードが無効になる問題が報告されている
- まず 0.14.2 に戻してログインを復旧する
- PHP バージョンや WPML など環境要因を切り分ける
- 修正版が出るまでは 0.14.2 固定と自動更新オフで運用する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressのmu-pluginsに潜むPopCashマルウェアを見つけて削除する方法
WordPressサイトで意図しないタブが勝手に開くポップアンダー攻撃が続く場合、通常のプラグインではなく mu-plugins フォルダにマルウェアが隠れている可能性が高い。全プラグインを無効化しても症状が消えないなら、必須プラグイン領域とテーマ内の偽 JavaScript ファイルを点検し、該当ファイルを削除したうえで Thrive Architect を最新版へ更新する。
なぜマルウェアはプラグイン無効化後も残るのか
mu-plugins フォルダは「必須プラグイン」とも呼ばれ、/wp-content/mu-plugins/ に置いた PHP ファイルは自動的に読み込まれる。WordPress 管理画面からプラグインを一括停止しても、このフォルダの中身は対象外になるため、攻撃者はここにファイルを置くと症状を消さずに済む。
今回確認された手口では、テーマフォルダ内の js ディレクトリに PHP ファイルが置かれ、JavaScript として配信されていた。拡張子が .php のまま配信時の形式だけを JavaScript に偽装し、テーマの script タグから読み込まれる形を装う。
この PHP ファイルは外部の api-js.popcash.net にサーバー間通信でアクセスし、得たコードを訪問者のブラウザへそのまま流す。ローカルファイル自体には難読化や eval がなく、「広告ネットワークの API を呼び出すだけのコード」に見える。これが Wordfence や Sucuri などのスキャナーに検出されない理由だ。
設定にはポップアンダーを有効にする pop_fback というオプションが含まれる。さらに curl、shell_exec、file_get_contents へ順に切り替えるフォールバックを持つため、サーバー側の関数制限が厳しくても動き続ける。
mu-pluginsに潜む感染ファイルを見つける手順
調査は FTP または SSH でファイルを直接確認するのが確実だ。感染ファイルは管理画面から見えない場所に置かれるため、ブラウザ上のプラグイン一覧だけでは発見できない。
感染ファイルを検出する調査フローを4ステップで示す。以下で各手順を詳しく説明する。
mu-pluginsフォルダ内の全ファイルを確認する
FTP アプリや SSH で /wp-content/mu-plugins/ を開き、ファイル名を目視で確認する。今回確認が取れているのは wp-ppck-assets.php という名前だが、同じ攻撃ツールは qtt-ppck-core.php や qtt-ajax-core.php といった別名でも置かれる。通常のサイト運営で作った覚えのない .php ファイルが1つでもあれば、削除候補として控えておく。
暗号めいた名前をキーワード検索する
ppck、qtt-、popcash といった文字列がファイル名やディレクトリ名に含まれていないか検索する。一見無害な英数字列に変えられたケースもあるため、名前だけで安全と判断せず、中身と更新日時も確認する。
テーマフォルダ内でPHPファイルが.jsとして呼ばれていないか確認する
テーマディレクトリの js フォルダや assets フォルダに、拡張子が .php のファイルが script タグで読み込まれる形跡がないか確認する。JavaScript の置き場所に PHP があること自体が不自然だ。今回のペイロードは qtt-ppck-core.php という PHP ファイルがテーマの js フォルダに置かれ、外部 API から取得したスクリプトを訪問者へ配信していた。
findコマンドで直近に変更されたPHPファイルを洗い出す
SSH が使える環境なら find コマンドで直近60日以内に変更された PHP ファイルを一覧化する。攻撃者は設置後に修正日時を偽装していないことが多いため、この一覧は感染日の特定に有効だ。
find /path/to/wordpress -type f -mtime -60 -name "*.php"マルウェア本体とドロッパーを完全に削除する
感染ファイルを特定したら、本体だけでなく侵入に使われたアップローダーも削除しなければ再感染する。ここでは削除対象と優先順位を整理する。
感染時に存在した不要ファイルと削除後の状態を対比する。削除対象は本体だけに留めない。
最初に該当ファイルをすべて削除する
mu-plugins 内の wp-ppck-assets.php と、テーマ内の qtt-ppck-core.php を削除する。同じツールキットは qtt-ajax-core.php や wp-tmp-up.php、_w10_up.php といった別名でも設置されるため、検索でヒットした全ファイルを対象にする。削除前には必ずバックアップを取り、削除後はサイトの表示と管理画面へのログインが正常にできることを確認する。
ルート直下の検証用テキストファイルも削除する
攻撃者は任意のファイル書き込みが可能か確認するために、WordPress のルートディレクトリへランダムな英数字20文字の .txt ファイルを置くことがある。今回の例では 52faade47ac664d8d0d3.txt というファイルが確認されており、削除対象になる。同様の .txt が残っていれば侵入テストの痕跡として除去する。
バックドアのパターンを全PHPから検索する
ファイルを消しただけでは、別の場所に置かれたバックドアが残る可能性がある。eval(、base64_decode(、gzinflate(、shell_exec(、assert( などの危険な関数が含まれる PHP を全検索する。正規のプラグインが使っている場合もあるため、検索結果はファイルの出所と更新日時を確認しながら判定する。
grep -Rl -e "eval(" -e "base64_decode(" -e "shell_exec(" /path/to/wordpressThrive Architectの脆弱性を塞ぐアップデート手順
今回の感染経路は Thrive Architect のクロスサイトスクリプティング脆弱性だった。プラグインを更新するだけでは設置済みのマルウェアは消えないため、削除作業の後に必ず更新する。
CVE-2026-66694の影響範囲
2026年8月6日に公開された CVE-2026-66694 は、Thrive Architect バージョン10.9.3.1以前に存在する未認証のクロスサイトスクリプティングと任意コード入力の脆弱性だ。自動化されたボットが未パッチのサイトをスキャンし、ファイル書き込み権限を取得してマルウェアを展開した。対象バージョンを使い続けると、同様の侵入が繰り返される。
最新版への更新と注意点
管理画面の更新画面または公式の入手経路から Thrive Architect をバージョン10.9.3.2以降へ更新する。更新によって脆弱性は塞がるが、すでにアップロードされたドロッパーやバックドアは自動的に削除されない。必ず先に感染ファイルの除去を行い、その後で更新する順番を守る。更新後は改めて不審な PHP が増えていないか確認する。
感染後の再発防止と全パスワード変更
マルウェアの削除と脆弱性対策が完了しても、攻撃者が別の認証情報を持っていれば再侵入される。認証情報の変更とログの確認まで行って、初めて駆除は完了する。
全パスワードを必ず変更する
WordPress の管理者、FTP や SFTP、データベース、ホスティングコントロールパネルの全パスワードを変更する。特に FTP や SFTP の認証情報が流出していた場合、管理者パスワードを変えただけでは再侵入を防げない。使い回しのパスワードは避け、二要素認証が使える場所では必ず有効化する。
WordPress本体と全テーマ・プラグインを更新する
WordPress コア、テーマ、すべてのプラグインを最新版にする。使用していないプラグインやテーマは削除する。海賊版や未更新のテーマは既知の脆弱性を多く含むため、公式に配布されている正規品だけを使う。更新後は管理画面と公開ページの動作を確認する。
サーバーログで侵入日時と経路を確認する
アクセスログには攻撃者の痕跡が残っている。今回の例では、任意ファイル書き込みの検証としてルート直下にランダムな .txt が作成され、約30分後に隠しアップローダーへ POST が送られ、その3秒後に curl でペイロードの動作確認が行われていた。ログを感染日の前後で精査すると、同じ手口で侵入されていないか、他に不審なリクエストが残っていないかを確認できる。
よくある質問
mu-pluginsとは何か、普通のプラグインと何が違うのか
mu-plugins は WordPress の必須プラグインフォルダで、手動で .php ファイルを置くと自動的に読み込まれる。管理画面から停止できないため、すべてのプラグインを無効化する操作の対象にならない。普段使わない環境なら中身が空であることが多いが、攻撃者はこの盲点を狙って設置する。
なぜWordfenceやSucuriは検出できなかったのか
マルウェア本体が外部 API を呼び出すだけのシンプルな構成で、eval や base64_decode などの典型的な攻撃パターンを含まないため、シグネチャ検出に引っかからなかった。ローカルファイル自体は無害に見え、危険なコードは外部から動的に取得される。このため、手動でのファイル名確認と日時調査が欠かせない。
Thrive Architectを更新すればマルウェアは自動で消えるか
消えない。アップデートで脆弱性は塞がれるが、すでに書き込まれたドロッパーやバックドアはそのまま残る。先に怪しいファイルを削除してから更新し、更新後にも再検査する順番が重要だ。
FTPが使えない場合はどう調べればよいか
ホスティングのファイルマネージャーやSSHを使う。SSHが利用できるなら find コマンドで直近に変更された PHP を一覧化できる。レンタルサーバーによっては管理画面からファイルマネージャーが提供されるため、まずサーバー管理パネルを確認する。
パスワードを変更するだけでも大丈夫か
不十分だ。ファイルを削除して脆弱性を塞ぎ、バックドアを検索し、ログを確認するまでが一連の駆除になる。パスワード変更は侵入経路を断つ一部であり、単独では再侵入を防げない。
この記事のポイント
- mu-pluginsフォルダは管理画面のプラグイン停止の対象外なので必ず手動で確認する
- ppckやqtt-を含む不審なPHPファイルとテーマ内の偽.jsファイルを削除する
- ドロッパーや検証用txtファイルも含めてバックドアを全検索する
- Thrive ArchitectのCVE-2026-66694対策として最新版へ更新する
- WordPress管理画面とFTPやデータベースの全パスワードを変更して二要素認証を有効化する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
CCBillプラグイン1.3.2更新で重大なエラーが出た時の対処法
CCBillプラグインを1.3.2へ更新した直後にサイトが落ちた場合、原因は更新版に必須のincludes/GelatoConfig.phpが同梱されていないことだ。対処は1.3.1へロールバックするのが確実で、require_once行の削除や空ファイルの作成では正常に戻らない。
なぜプラグイン更新後にサイトが落ちるのか
プラグインのメインファイルは読み込み時にrequire_once ‘includes/GelatoConfig.php’;という命令を実行する。ところが1.3.2の配布ZIPにはincludesディレクトリに該当ファイルが含まれていない。PHPは必要なファイルを開けないため、その場で処理を中断し、WordPressは「このサイトで重大なエラーが発生しました」という画面に切り替わる。
このデモは、更新版で必須ファイルが欠落した際にエラーが発生し、旧版で解消する流れを表している。
読み込み失敗が致命的エラーへ進む流れ
require_onceは指定したファイルを必ず読み込む命令であり、見つからなければPHPの実行が止まる。WordPressはこの致命的エラーを検知して、訪問者には復旧用の画面を表示し、管理者には状況を伝えるメールを送ることがある。サイトが突然止まった場合は、まず更新直後に起きたことを前提に動くと早期に原因へたどり着ける。
他のファイルも同じクラスに依存している
1.3.2の他の複数ファイルはGelatoConfigクラスのメソッドやプロパティを呼び出している。そのため、require_once行をコメントアウトしたり、中身のないincludes/GelatoConfig.phpを作ったりしても、次の段階でクラスが見つからないエラーへ変わるだけだ。今回の不具合は行の書き換えで吸収できる規模ではない。
エラーログで原因を確定させる手順
画面が真っ白になったり、重大なエラーの表示だけでは原因が見えない。まずはWordPressのデバッグログを有効にして、どのファイルで止まっているかを確認する。
wp-config.phpでデバッグログを有効にする
FTP・SFTPでサーバーに接続し、WordPressのルートにあるwp-config.phpを編集する。以下の定数を設定すると、エラー内容がwp-content/debug.logに記録される。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );debug.logに記録された該当行を確認する
debug.logを開くと、require_once()がincludes/GelatoConfig.phpを開けなかったことや、GelatoConfigクラスが見つからない趣旨のエラー（英語表示では ‘Class GelatoConfig not found’）が記録されている。このログが取れたら、原因はプラグインのファイル欠落であると確定できる。
旧バージョンへ戻す具体的な手順
管理画面にアクセスできるかどうかで手順が変わる。ここでは先に全体フローを確認し、それぞれの詳細を説明する。
ロールバックの基本手順を示した。それぞれの詳細は次項で解説する。
公式配布ページから1.3.1のZIPを入手する
WordPress.orgのプラグインページを開き、下部にある詳細表示（Advanced View）から過去の版を選べる。画面下部のバージョン選択で1.3.1を指定し、ZIPをダウンロードする。ローカルに展開して、includes/GelatoConfig.phpが含まれていることをこの段階で確認しておくと安心だ。
FTP・SFTPでプラグインフォルダを置き換える
FTP・SFTPクライアントでサーバーに接続し、wp-content/plugins/ の該当プラグインフォルダを開く。既存のフォルダをいったん別名にリネームして退避し、展開した1.3.1のフォルダをアップロードする。リネーム後に新しいフォルダを置くと、サイト上では1.3.1が読み込まれる。
管理画面に入れないときの一時的な復旧
サイト全体が落ちて管理画面にも入れない場合は、FTP・SFTPで該当プラグインのフォルダをリネームして無効化する。これでサイトが表示されるようになれば、管理画面にログインして旧版ZIPをアップロードできる。自動更新が走る環境では、復旧前に更新を止めておくのが確実だ。
キャッシュを削除して反映を確認する
旧版への置き換え後は、サイトのキャッシュプラグインとブラウザのキャッシュを削除する。サーバー側キャッシュを使っている場合はそれもクリアする。その後、フロントと管理画面の両方が表示され、プラグイン設定が1.3.1に戻っていることを確認する。
require_once行の削除や空ファイルでは直らない理由
部分的なコード修正では別のエラーへ移るだけで、旧版への切り戻しが最短の解決になる。
GelatoConfigクラスは複数のファイルから参照されている
1.3.2のコードはGelatoConfigクラスに依存する構造になっている。require_once行を消すとファイル読み込みは通っても、その後でクラスのプロパティやメソッドを呼ぶ箇所がエラーになる。空ファイルを作ってもクラス定義がないため、PHPは同じ理由で停止する。問題の本質は設定ファイルの有無ではなく、配布物からクラス定義ごと抜け落ちている点にある。
誤った修正をした場合のリスク
プラグイン本体を直接書き換えると、将来の更新で上書きされ、変更が失われる。また、クラス定義を部分的に再現できたとしても、決済処理など他の機能に影響が出るおそれがある。商用サイトでは旧版へ戻す方法が最も安全だ。開発元が修正版を配信するまでは、1.3.1に留めて更新を保留する。
再発を防ぐために更新前に確認したいこと
ステージング環境で先に更新を試す
本番サイトへそのまま更新を適用せず、コピー環境（ステージング）でプラグイン更新を実行する。更新後にフロントと管理画面、主要な導線を一通り確認し、エラーがないことを確かめてから本番へ反映する。ステージング環境が用意できない場合は、更新前にフルバックアップを取っておく。
更新前に旧版のZIPを確保しておく
プラグインは自動更新で最新版だけが残り、旧版の入手経路が分からなくなることがある。今回のように最新版が壊れているケースでは、更新前に利用中のバージョンのZIPをダウンロードして保管しておくと速やかに戻せる。プラグインページの詳細表示からダウンロードできる。
更新直後に異常を検知したらすぐに切り戻す
サイトを更新した直後は、必ずトップページと管理画面、問い合わせフォームなど主要機能を開いて確認する。重大なエラーが出た場合は、原因調査より先に旧版へ戻すのが先決だ。ログの確認はその後で行い、開発元の修正版が出るまで更新を保留する。
よくある質問
プラグインを1.3.2に更新したのに管理画面に入れません。どうすればいいですか
FTP・SFTPでwp-content/plugins/ の中にある該当プラグインのフォルダをリネームして無効化する。これで管理画面に入れるようになったら、旧版1.3.1のZIPをアップロードして再び有効化する。
旧版の1.3.1はどこでダウンロードできますか
WordPress.orgのプラグインページにある詳細表示（Advanced View）から過去の版を選んでダウンロードできる。今回のような更新直後の不具合に備え、普段から利用中のバージョンのZIPを手元に保管しておくのが有効だ。
require_once行を削除してもサイトは戻らないのでしょうか
戻らない。削除すると次の段階でGelatoConfigクラスが見つからないエラーに変わる。空のファイルを置いてもクラス定義がないため解消しない。旧版へ戻すのが最短の対処だ。
プラグイン1.3.2に自動更新されないようにするには
該当プラグインの自動更新をオフにするか、サイト全体の自動更新設定でプラグイン更新を手動に切り替える。ただし修正版が公開された場合は、手動で更新を適用する必要がある。
サイトが重大なエラー画面のままの場合は、メールは届きますか
WordPressがサイト管理者へ復旧用リンク付きのメールを送ることが多い。メールが届かない場合は、FTP・SFTPでプラグインを無効化して管理画面への導線を確保する。
この記事のポイント
- 1.3.2では必須ファイルincludes/GelatoConfig.phpが欠落している
- 行の削除や空ファイルではエラーの種類が変わるだけで直らない
- 旧版1.3.1へ戻すのが最短の対処だ
- 旧版ZIPはプラグインページの詳細表示から入手できる
- 更新前にはバックアップと旧版の確保、ステージングでの確認を行っておく
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WP Activity Log v5.6.4でアプリパスワード削除時に500エラーが出る原因と回避策
WP Activity Log v5.6.4を有効化したWordPressサイトで、プロフィール画面からアプリケーションパスワードを取り消すと「このサイトで重大なエラーが発生しました」と表示される場合、プラグインのアップデート待ちでは解決しない。原因はWP Activity Logが汎用のupdate_user_metaフックに対するメタキーの検証を怠っている点にあり、PHP 8ではcount()に文字列を渡すとTypeErrorが発生して致命的エラーになる。この記事では、エラーの仕組みから、手動での回避策、上位互換のためのコードパッチまでを具体的に示す。
エラーの全容と発火する条件
WP Activity Log v5.6.4に収録されたWP_User_Profile_Sensor::event_application_password_added()は、汎用のupdate_user_metaアクションにフックされている。関数シグネチャには$meta_keyが渡されているが、コールバック内でこれを一度も検証しない。代わりにHTTPリファラとREQUEST_URIだけを見て、アプリケーションパスワード変更のリクエストかどうかを判定している。
このため、ユーザーのプロフィール画面からアプリケーションパスワードを取り消すときに、REST APIへのDELETEリクエストが発行される。リファラチェックはプロフィールページを指し、URIチェックも/wp/v2/users/{id}/application-passwords/...を含むため、両方の条件を通過する。ここでBuddyBoss Appのようなプラグインが、同じリクエストのディスパッチ中にlast_activityというユーザーメタを更新すると、本来アプリケーションパスワードのメタを想定していたセンサーが誤ってそのtimestamp文字列を処理してしまう。
致命的エラーの発生箇所とスタックトレース
実運用のログには、次のような未捕捉のTypeErrorが記録される。PHP 8ではcount()の引数が配列またはCountableでない場合、警告ではなくTypeErrorがスローされる。WP Activity Logのコードは文字列をcount()に渡しているため、リクエストが500エラーになる。
スタックトレースを追うと、クラスの203行目でcount( $_meta_value )が呼ばれている。ここで$_meta_valueはtimestampの文字列であり、$old_valueは_application_passwordsの配列である。文字列をcount()に渡すとPHP 8ではTypeErrorが発生し、アプリケーションパスワードの取り消しは実行されないまま処理が失敗する。
第一の対処方法、プラグインの停止で被害を止める
まず、サイトが利用者から見て壊れている状態を早く解消するには、WP Activity Logを停止する。管理画面にアクセスできる場合は「プラグイン」画面からWP Activity Logを無効化する。アクセスできない場合はFTPでwp-security-audit-logディレクトリをリネームする。リネームするとWordPressがプラグインを検出できなくなり、自動的に無効化される。
第二の対処方法、一時的にPHPのエラー表示を止める
WP Activity Logを使い続けたい場合は、PHPのcount()エラーが致命的にならないよう回避策を施す。だが、これは根本解決ではなく症状を隠すだけだ。むしろ、エラー自体を修正するパッチを適用する方が安全である。ただし、プラグインのアップデートで上書きされることを理解した上で、運用上の措置として行うかどうかを判断してよい。
ソースコードを直接修正する根本対応
WP Activity Logの該当ファイルはwp-security-audit-log/classes/WPSensors/class-wp-user-profile-sensor.phpである。コールバックの先頭で、メタキーが_application_passwordsでない場合は早期returnするようガードを追加する。これが今回のエラーを確実に止める最小の修正だ。
public static function event_application_password_added( $meta_id, $user_id, $meta_key, $_meta_value ) {
if ( '_application_passwords' !== $meta_key ) {
return;
}
// 以下、既存の処理
}加えて、防御的措置としてcount()に渡す前に配列キャストを行うと、将来何らかの形で配列以外の値が混入した場合にも致命的エラーを防げる。メタキーガードだけでも今回の症状は解消するが、運用中のサイトでは両方の修正を施しておく方が堅牢だ。
} elseif ( count( (array) $_meta_value ) < count( (array) $old_value ) ) {修正後、コード上の同じパターンが他に残っていないか、deleted_user_metaやadded_user_metaへの登録も確認するとよい。同じクラス内で複数のフックが同様のリファラ＋URIチェックだけに頼っている場合、似た条件のリクエストで誤発火する可能性がある。
PHP 8環境で注意すべきcount()の挙動
PHP 7.xでは、count()に文字列を渡しても警告が出るだけで処理は継続されていた。しかしPHP 8ではTypeErrorとしてスローされるため、これまで表面化しなかったコードの前提ミスが致命的エラーとして現れる。WP Activity Logに限らず、WordPressプラグインの旧コードでは、更新順にこうした潜在バグが発覚することがある。
サイトをPHP 8系へ更新した直後に、特定の操作でのみ500エラーが出る場合は、エラーログにcount(): Argument #1 ($value) must be of type Countable|array, string givenのような記録が残っていないか確認する。該当する場合は、エラーを起こしているプラグインのコードが文字列をcount()に渡している可能性が高い。
- count()に文字列を渡すと警告のみ
- 処理は継続される
- 潜在的バグが表面化しない
- TypeErrorがスローされる
- 致命的エラーで500応答
- 操作が完了しない
よくある質問
WP Activity Logを無効化すると監査ログは消えますか？
無効化しても記録済みの監査ログはデータベースに残る。ただし、無効化している間に発生したイベントは記録されない。復旧後にプラグインを再度有効化すれば、既存のログを閲覧できる。
BuddyBoss Appが原因なのでBuddyBoss側を停止すれば直りますか？
BuddyBoss Appがユーザーメタを更新するタイミングが発火に重なっているが、根本的な誤動作はWP Activity Log側のフック設計にある。BuddyBoss Appが動いていなくても、別のプラグインが同様にRESTリクエスト中にユーザーメタを更新すれば同じエラーが起きる。
WP Activity Logのバージョンを下げれば回避できますか？
過去のバージョンが同じコードを含んでいる場合、単純なダウングレードでは解消しない。今回のクラスのコールバックを変更せずに添付された報告では、v5.6.5にも修正が含まれていないと指摘されている。信頼できる最新の修正が入るまでは、上記のコードパッチを適用するか、プラグインを停止する方が確実だ。
プロフィール画面でアプリパスワードを管理できる権限がないユーザーも影響を受けますか？
このエラーはアプリケーションパスワード管理を行えるユーザーに限らず、同じリクエスト経路でユーザーメタが更新される状況であれば発火しうる。ただ、発火条件としてプロフィール画面からの操作と、REST APIのURIにアプリケーションパスワードのパターンが含まれることが必要になる。
プラグインをアップデートしたら勝手に直りますか？
プラグインの開発者がメタキーガードを実装したバージョンをリリースすれば直る。ただし、現時点で修正が含まれているかはリリースノートとソースを確認する必要がある。修正が見つからないうちは、手動パッチか無効化で運用を守る。
この記事のポイント
- WP Activity Log v5.6.4の500エラーはPHP 8のcount()エラーが原因
- コールバックがメタキーを検証せず、アプリパスワードと無関係なユーザーメタで誤発火する
- メタキーガードを追加するコードパッチが根本解決になる
- 配列キャストを加えるとPHP 8の厳格なエラーに強いコードになる
- 修正版が出るまでは、プラグイン停止かパッチ適用で被害を防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPressに勝手にインストールされるwp-flareマルウェアの感染経路と駆除方法
WordPressに「wp-flare」という身に覚えのないプラグインがインストールされていた場合、それはマルウェアによる不正侵入の痕跡だ。感染したプラグインファイルとデータベース上の登録を削除し、侵入経路を特定して塞ぐことが根本対策になる。
wp-flareマルウェアの感染経路はどこにあるのか
wp-flareは正規のプラグインディレクトリには存在しない、攻撃者が設置する不正なプラグインだ。このプラグインがインストールされるということは、すでに何らかの方法でサイトの管理者権限を奪われている、またはファイルを書き込む経路を確保されていることを意味する。
感染経路として最も多いのは、使用しているプラグインやテーマに存在する脆弱性の悪用だ。すべてのプラグインが最新版でも、サポートが終了した古いプラグインや、公式ディレクトリにない野良プラグインに脆弱性が残っているケースがある。攻撃者はこうした穴を突いて任意のファイルをアップロードし、不正なプラグインを設置する。
次に疑うべきは、管理者パスワードの漏洩や総当たり攻撃の成功だ。二段階認証（2FA）を導入していても、XML-RPC経由の認証試行や、別サイトから流出した同じパスワードを使い回している場合は突破されることがある。
複数サイトが同時期に感染する理由
異なるホスティングの複数サイトが同時期に感染する場合、共通して使っているプラグインやテーマ、管理ツールが感染源になっている可能性が高い。たとえば、同じ開発元が配布するプラグインの配布元が改ざんされていたり、管理用のパソコン自体がマルウェアに感染してFTPやSSHの認証情報を窃取されているケースもある。
感染経路の特定には、各サイトのファイル更新日時とアクセスログを突き合わせるのが有効だ。wp-flareのファイルが設置された日時を調べ、その前後に不審なPOSTリクエストやログイン試行がないかを確認する。
上の図は感染に至る典型的な3つの経路を示している。どの経路であっても最終的にはwp-flareという不正プラグインが設置される点が共通している。
感染したサイトで最初に確認すべき症状
wp-flareに感染したサイトでは、管理画面のプラグイン一覧に「wp-flare」という名前の見慣れない項目が表示される。ただし攻撃者がプラグインの表示名を偽装している場合もあるため、一覧に表示されないこともある。
そのほか、以下のような症状が現れることがある。すべてに該当する必要はなく、1つでも当てはまれば感染を疑うべきだ。
- サイトが知らないURLにリダイレクトされる
- 検索結果に表示されるタイトルや説明文が書き換えられている
- 管理画面の動作が急に重くなった
- 見覚えのない管理者ユーザーが追加されている
- サーバーに身に覚えのないファイルが増えている
最も確実なのは、サーバーのプラグインディレクトリ（wp-content/plugins/）を直接確認することだ。wp-flareという名前のフォルダが存在する場合は、マルウェア感染と断定してよい。
wp-flareマルウェアを駆除する手順
wp-flareの駆除は、プラグインファイルの削除だけでなく、データベース上の不正な登録や、設置されたバックドアの除去まで行う必要がある。以下の手順で進める。
この手順は上から順に実施する。途中でサイトが表示できなくなっても復旧できるよう、STEP 1のバックアップは必ず最初に行う。
wp-flareのプラグインフォルダを削除する
FTPソフトまたはホスティングのファイルマネージャーにログインし、wp-content/plugins/wp-flare ディレクトリを丸ごと削除する。管理画面からプラグインを「削除」しようとしても、プラグイン自体が無効化を妨害する仕組みを持っている場合があるため、ファイルシステム上から直接削除するのが確実だ。
削除後、管理画面のプラグイン一覧に「wp-flare」が表示されなくなることを確認する。もしプラグイン一覧にまだ表示される場合は、データベース側に登録が残っている可能性が高い。
データベースから不正な登録を削除する
WordPressのプラグイン情報は、データベースの wp_options テーブルにある active_plugins という項目で管理されている。不正プラグインがここに登録されていると、ファイルを削除しても管理画面に残り続ける。
phpMyAdminなどのデータベース管理ツールで wp_options テーブルを開き、option_name が active_plugins の行を探す。その値の中に wp-flare や wp_flare を含む文字列があれば、その部分を削除する。操作前にデータベースのバックアップを取得しておくこと。
バックドアの痕跡を全ファイルから探す
wp-flare本体を削除しても、攻撃者が別の場所にバックドア（再侵入用の隠しファイル）を設置している場合がある。主に以下の場所を確認する。
- テーマディレクトリ内の見覚えのないPHPファイル
- アップロードディレクトリ内のPHPファイル（画像のはずなのに拡張子がPHPになっているもの）
- WordPress本体の
wp-adminやwp-includes内の改ざんファイル - サイトのルート直下に置かれた小さなPHPファイル
ファイル数が多い場合は、サーバー上で find コマンドを使って直近に変更されたファイルを抽出すると効率的だ。感染が確認された日時以降に更新されているPHPファイルを重点的に調べる。
find /path/to/wordpress -name "*.php" -mtime -30このコマンドは、指定したWordPressディレクトリの中で過去30日以内に更新されたPHPファイルを一覧表示する。感染が判明した時期に合わせて日数を調整する。
全パスワードと認証情報を変更する
駆除が完了したら、侵入経路に関係なく以下の認証情報をすべて変更する。感染中に窃取されていた可能性を考慮し、同じパスワードの使い回しは避ける。
- WordPress管理画面の全ユーザーのパスワード
- FTP・SSHの接続パスワード
- データベースの接続パスワード
- ホスティングのコントロールパネルのパスワード
- メールアカウントのパスワード
再発を防ぐためのセキュリティ対策
wp-flareを駆除しても、感染経路を塞がなければ再び同じ被害に遭う。特に複数サイトが同時期に感染した場合は、サイト単体の対策だけでなく、管理環境全体の見直しが必要だ。
使用中のプラグインとテーマを棚卸しする
すべてのサイトで使用しているプラグインとテーマの一覧を作成し、以下に該当するものがないか確認する。これらが感染源になっている可能性が高い。
- 配布元が公式ディレクトリではないプラグイン
- 更新が1年以上停止しているプラグイン
- サイトの機能上不要になったプラグイン
- 正規の配布元ではないサイトから入手したテーマ
不要なプラグインは削除し、更新が停止しているプラグインは代替品への移行を検討する。どうしても使い続ける必要がある場合は、開発元のセキュリティ情報を定期的に確認する。
管理用パソコンのマルウェアスキャンを行う
複数のサイトが同時期に感染した場合、サイトではなく管理用のパソコンが感染源になっている可能性がある。FTPやSSHの接続情報を保存しているFTPソフトの設定ファイルから認証情報が窃取され、攻撃者に悪用されるケースがある。
管理用パソコンで信頼できるアンチウイルスソフトのフルスキャンを実施し、FTPソフトやパスワード管理ソフトの保存データが漏洩していないか確認する。スキャン後は、保存済みのパスワードもすべて変更するのが安全だ。
FTPソフトにパスワードを保存する機能は便利だが、マルウェア感染時には認証情報の流出経路になる。可能であれば、接続のたびにパスワードを入力する運用に切り替えるとリスクを減らせる。
ファイル変更の監視を導入する
感染の早期発見には、サーバー上のファイル変更を監視する仕組みが有効だ。WordPressのセキュリティプラグインには、ファイルの改ざんを検知して通知する機能を持つものがある。プラグインの新規インストールや、想定外のファイル変更があった場合にメールで知らせる設定にしておくと、被害が拡大する前に対処できる。
XML-RPCを無効化する
XML-RPCはWordPressの外部連携機能だが、総当たり攻撃やSSRF攻撃の入口として悪用されることが多い。外部サービスとの連携で使っていない場合は、無効化するのが効果的な対策になる。
セキュリティプラグインの多くにXML-RPCを無効化するオプションがある。もしくは、以下のコードをテーマの functions.php に追加する方法もある。
add_filter( 'xmlrpc_enabled', '__return_false' );ただし、このコードは子テーマの functions.php に追加するのが基本だ。親テーマを直接編集すると、テーマ更新時にコードが消えるため注意する。
よくある質問
wp-flareは公式プラグインディレクトリに存在しないのか
存在しない。wp-flareはWordPress公式ディレクトリに登録されておらず、攻撃者が独自に設置する不正なプラグインだ。プラグイン一覧に表示される名前が同じでも、正規のプラグインと混同しないよう注意する。
管理画面からwp-flareを削除できない場合はどうするのか
管理画面からの削除ができない場合は、FTPまたはファイルマネージャーでサーバーに直接アクセスし、プラグインディレクトリからフォルダを削除する。削除後もプラグイン一覧に表示される場合は、データベースの active_plugins に残っている登録を手動で削除する必要がある。
感染したサイトのバックアップは復元に使えるのか
感染前のバックアップが確実に存在する場合は、バックアップからの復元が最も確実な駆除方法になる。ただし、バックアップ自体が感染後に取得されたものであれば復元しても意味がない。取得日時を必ず確認し、感染前のものを使う。
wp-flare対策に有効なセキュリティプラグインはあるのか
定期的なマルウェアスキャン、ファイル変更の監視、ログイン試行の制限、XML-RPCの無効化などを提供するセキュリティプラグインが有効だ。ただし、プラグインを導入するだけで完全に防げるわけではない。プラグインの棚卸しやパスワード管理など、運用面の対策と組み合わせることが重要になる。
同じパスワードを複数サイトで使い回してもよいのか
避けるべきだ。1つのサイトでパスワードが漏洩すると、同じパスワードを使うすべてのサイトが連鎖的に感染する原因になる。サイトごとに異なるパスワードを設定し、パスワード管理ソフトで一元管理するのが安全な運用だ。
この記事のポイント
- wp-flareは攻撃者が設置する不正なプラグインだ
- 感染経路はプラグインの脆弱性、パスワード漏洩、FTP認証情報の窃取が主な候補になる
- 駆除はファイル削除とデータベースの掃除、バックドア除去まで行う
- 複数サイトが感染した場合は管理用パソコンのマルウェアスキャンも必要だ
- 再発防止にはプラグインの棚卸しとファイル変更の監視が有効だ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Tutor LMSでコース画像が小さくぼやける原因と画像サイズ変更の手順
Tutor LMSのコース一覧でサムネイル画像が小さくぼやける症状は、プラグインが登録した専用画像サイズ（約370×235px）をテンプレートが呼び出し、ブラウザ側で大きな容器に引き伸ばしているのが主な原因だ。子テーマでテンプレートを上書きするか、フィルターフックで画像サイズを変更すれば解決する。
Tutor LMSでコース画像がぼやける仕組みと原因
Tutor LMSはコース一覧ページを表示する際、専用の画像サイズを呼び出す。このサイズはプラグインがサーバー環境に登録したもので、コースカードのレイアウトに合わせて小さい寸法に設定されていることが多い。
問題は、テーマ側のスタイルシートがコースカードをより広い幅で表示しようとする場面だ。画像の実寸（約370×235px）に対して、実際の表示領域がそれを上回ると、ブラウザが画像を無理に拡大する。高解像度の元画像をアップロードしても、プラグインが生成した小さなサムネイルを参照している限り、ぼやけや文字の潰れは解消されない。
また、Tutor LMSのコースループ用テンプレートは標準の post_thumbnail_size フックを無視し、独自のサイズ指定を直接コード内に持っている。そのため、WordPressの標準設定から画像サイズを変更しても、コース一覧に反映されないという構造的な理由がある。
このデモは、Tutor LMSが小さいサムネイルを呼び出してからブラウザが拡大する流れと、修正後に高解像度画像を直接参照する流れを示している。
テンプレート上書きで画像サイズを変更する手順
最も確実な方法は、Tutor LMSのテンプレートファイルを子テーマにコピーし、画像サイズの指定を書き換えることだ。プラグイン本体のファイルを直接編集するとアップデートで上書きされるため、必ず子テーマを使う。
Tutor LMSのテンプレート構造を確認する
Tutor LMSのテンプレートは wp-content/plugins/tutor/templates/ ディレクトリ内に配置されている。コース一覧のカードを構成するテンプレートは、templates/course/loop/ または templates/loop/ 以下のファイル群だ。バージョンによって多少の違いはあるが、コースカードの表示を担当するファイルにサムネイル呼び出しが含まれている。
管理画面の「プラグイン」→「プラグインファイルエディター」からTutor LMSを選択し、templates/ フォルダを展開すると実ファイル名を確認できる。FTPで接続できるなら wp-content/plugins/tutor/templates/ を直接参照する方が速い。
子テーマにテンプレートをコピーする
対象のテンプレートファイルを子テーマ内の tutor/ ディレクトリにコピーする。Tutor LMSは子テーマの tutor/ フォルダを優先的に読み込む仕組みを持っている。コピー先のパスは wp-content/themes/子テーマ名/tutor/ だ。ディレクトリ構造を保ったままコピーする。
画像サイズの指定を変更する
コピーしたテンプレートファイル内の get_the_post_thumbnail() または tutor_course_loop_thumbnail() の呼び出し部分を探す。第二引数に指定されているサイズ名（例 'tutor-course-thumbnail'）を 'full' または 'large' に変更する。
// 変更前
get_the_post_thumbnail($course_id, 'tutor-course-thumbnail');
// 変更後
get_the_post_thumbnail($course_id, 'full');テンプレート内に the_post_thumbnail() が直接記述されている場合は、同じくサイズ引数を 'full' に置き換える。
このデモは、テンプレート上書きの4つの手順を順番に示している。
フィルターフックで画像サイズを変更する方法
テンプレートを編集せずに済ませたい場合は、Tutor LMSが提供するフィルターフックを利用する。functions.php に数行追加するだけで、コースループで呼び出される画像サイズを変更できる。
functions.phpにフィルターを追加する
子テーマの functions.php に以下のコードを追加する。tutor_course_thumbnail_size フックは、コースループで使われるサムネイルサイズを差し替えるためのものだ。
add_filter('tutor_course_thumbnail_size', function($size) {
return 'full';
});このコードは、Tutor LMSがコースカードのサムネイルを出力する際に参照するサイズ名を full に上書きする。元画像が十分な解像度でアップロードされていれば、一覧表示でも鮮明になる。
なお、プラグインのバージョンや使用中のテーマによってフック名の実装が異なる場合がある。テンプレート上書きの方が確実に効くため、フィルターで変化が見られない場合はテンプレート上書きに切り替えるのが確実だ。
サムネイル再生成とキャッシュのクリア
画像サイズの指定を変更した後は、既存の画像に対して新しいサイズのサムネイルが生成されていない場合がある。特に full サイズを使う場合は元画像そのものを参照するため再生成は不要だが、large や独自サイズを使う場合は再生成が必要になる。
サムネイル再生成で古いサイズを更新する
「Regenerate Thumbnails」などの再生成プラグインを使うと、WordPressに登録されている全画像サイズを一括で作り直せる。再生成の所要時間は画像点数に依存するが、数百枚程度なら数分で完了する。
サイトキャッシュとブラウザキャッシュを削除する
変更後に表示が古いままの場合は、キャッシュ系プラグインの全削除と、ブラウザのキャッシュクリアを行う。CDNを利用している場合は、CDN側のキャッシュもパージする。これで新しい画像サイズがサーバーから配信される。
このデモは、画像サイズ変更後に確認すべき作業の流れを示している。
よくある質問
Tutor LMSのコース画像サイズはどこで登録されているのか？
Tutor LMSはプラグインのコード内で add_image_size() 関数を使って専用サイズを登録している。登録名は tutor-course-thumbnail などで、コースループ用テンプレートがこのサイズを参照する。標準のWordPress設定画面からは変更できない。
子テーマを作っていない場合はどうすればよいか？
まず子テーマを作成する。WordPress公式ドキュメントに従い、style.css と functions.php を含むフォルダを作成すればよい。親テーマを直接編集するとアップデートで変更が消えるため、子テーマ運用が安全だ。
画像を変更しても古いサイズのまま表示されるのはなぜか？
ブラウザキャッシュやサイトキャッシュが古い画像を保持している可能性が高い。キャッシュ系プラグインの全削除と、ブラウザのキャッシュクリアを行う。CDNを使っているならCDN側のパージも必要だ。
フィルターフックが効かない場合はどうする？
プラグインのバージョンやテーマの構造によって、特定のフックが実装されていない場合がある。その場合はテンプレート上書き方式に切り替える。テンプレートファイル内のサイズ指定を直接書き換えれば、フックの有無に関係なく確実に反映される。
CSSだけで画像を鮮明にできるか？
できない。CSSで image-rendering プロパティを調整しても、元の画像データが小さい限り拡大によるぼやけは残る。根本的な解決には、テンプレートやフィルターで大きなサイズの画像を呼び出す必要がある。
この記事のポイント
- Tutor LMSのコース画像ぼやけは小さい専用サイズの参照が原因
- 子テーマへのテンプレート上書きで確実に修正できる
- フィルターフックでもサイズ変更が可能
- サイズ変更後は再生成とキャッシュ削除が必須
- CSSだけでは根本解決にならない
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている