WordPressのMCP接続、3つの選択肢を比較。Elementorユーザーが最初に試すべき方法
WordPressにMCP（Model Context Protocol）でAIエージェントを接続する方法が、2026年10月に入って大きく変わった。WordPressプロジェクトが公式のMCPアダプターをリリースし、一方でElementorはバージョン4.3.0からMCP機能を標準搭載した。
現在、WordPress向けMCP接続には3つの選択肢がある。公式のWordPress MCP Adapter、非公式のMCPサーバー、そしてElementor内蔵のMCPだ。それぞれ設定の手間やメンテナンス負担が異なる。
この記事では3つの選択肢の違いを整理し、どのようなサイト運営者がどれを選ぶべきかを解説する。特にElementorを使っているなら、追加インストール不要の内蔵MCPが最短ルートになる。
WordPressのMCP接続とは何か
MCP（Model Context Protocol）は、AIエージェントが外部のサイトやツールに接続するための共通規格だ。ClaudeやCodexなどのAIクライアントが、WordPressサイトの機能を呼び出すための橋渡し役を果たす。この仕組みを使うと、AIエージェントはサイト上の操作を自動化できるようになる。
MCPが登場する前は、AIエージェントをWordPressに接続する手段が統一されていなかった。サービスごとに独自のAPIを用意する必要があり、開発者にとっては接続のたびに学習コストがかかっていた。MCPはこの接続方法を標準化し、1つの仕組みでさまざまなAIクライアントと連携できる道を開いた。
MCPが解決する接続の課題
従来の接続方式では、サイト側とAIクライアント側の両方に個別の設定が必要だった。MCPはこの複雑さを抽象化し、AIエージェントが「ツール」「リソース」「プロンプト」という3つの単位でサイトの機能を扱えるようにする。たとえば「商品を更新する」「スタイルを変更する」といった操作が、AIエージェントから呼び出せる単位になる。
WordPressのAbilities APIとは
WordPressにはAbilities APIという標準がある。これは、WordPress本体や各プラグインが持つ機能をAIエージェントに公開するための仕組みだ。Abilities APIに登録された機能は、MCP接続を通じてAIエージェントが発見し、呼び出せるようになる。
重要なのは、Abilities APIはどのMCP接続方式でも利用できる点だ。WordPress MCP Adapterでも、Elementor内蔵MCPでも、同じ標準に基づいて機能が公開される。つまり、MCP接続の選択肢が増えても、プラグイン側が対応すべき仕組みは共通である。
3つの方法はそれぞれ性質が異なる。次のセクションから順番に見ていく。
WordPress MCP Adapterの仕組み
2026年10月2日、WordPress MCP Adapterのバージョン0.7.0がWordPress.orgのプラグインディレクトリに公開された。これまでGitHub上でのみ入手可能だったが、公式ディレクトリに登場したことで、一般のサイト運営者にとって入手のハードルが大きく下がった。
このプラグインの役割は、Abilities APIに登録された機能をMCPの「ツール」「リソース」「プロンプト」に変換することだ。AIエージェントはこの変換を通じて、WordPressサイトの機能を発見し、呼び出せるようになる。注意すべきなのは、このプラグイン自体はAI機能を追加しないという点だ。
WordPress MCP Adapterは「橋」にすぎない。実際にAIエージェントが実行できる操作は、サイトに導入済みのプラグインがAbilities APIに登録した内容に依存する。つまり、Adapterを導入しただけでは何も起きず、Abilitiesを提供するプラグインが揃って初めて機能する。
手動設定の具体的な手順
WordPress MCP Adapterには、現時点で設定画面や製品内の案内が用意されていない。接続するには、まずWordPressでアプリケーションパスワードを生成し、次にAIクライアントの設定ファイルを編集してサーバーエンドポイントを指定する必要がある。設定ファイルの編集に慣れている開発者向きの手順だ。
Adapterが持つ制約
WordPress MCP Adapterはバージョン0.7.0という早期段階にある。動作にはWordPress 6.9以降が必要で、まだ正式リリースには至っていない。今後のバージョンアップで設定画面が追加される可能性はあるが、現時点では技術的な知識なしに接続するのは難しい。
非公式MCPサーバーの注意点
WordPress向けの非公式MCPサーバーは、個人開発者やサードパーティが公開しているプラグインやリポジトリとして存在する。これらは公式のWordPress MCP Adapterが登場する前から利用されてきた経緯がある。
メンテナンスと権限のリスク
非公式MCPサーバーを使う際の最大の懸念は、品質のばらつきだ。メンテナンスが継続的に行われているか、どの権限を要求するか、サイトや利用者に関するどのようなデータを保存するか、AIエージェントにどこまで操作を許可するか。これらがサーバーごとに異なる。
また、非公式MCPサーバーの多くは手動設定が必要だ。WordPress MCP Adapterと同様に、アプリケーションパスワードを生成してAIクライアント側に設定する作業が発生する。さらに、更新の有無を自分で確認し続ける必要がある。
セキュリティの観点では、信頼できる開発者による実績のあるサーバー以外は避けるのが無難だ。特にクライアントの本番サイトでは、権限が過剰なものやデータの取り扱いが不透明なものは導入すべきではない。
Elementor内蔵MCPの違い
公式のElementor MCPは、Elementor 4.3.0以降に標準搭載されている。追加でダウンロードするプラグインは不要だ。Elementorがインストールされて有効化されていれば、そのままMCP接続を開始できる。
この「追加インストール不要」という点は、サイト運営者にとって実務上の大きな利点になる。プラグインを増やせば増やすほど、更新の手間や互換性リスクが積み上がる。内蔵機能としてMCPが使えるなら、その負担を増やさずに済む。
UIで完結する設定フロー
Elementor MCPの設定は、WordPressダッシュボード内の専用UIで完結する。「Elementor」メニューから「Elementor MCP」を開き、利用するAIツールを選択して、画面に表示される手順に従うだけだ。設定ファイルを直接編集する必要はない。
アプリケーションパスワードはElementorがバックグラウンドで自動生成する。利用者がパスワードを手動で生成したり、AIクライアントに設定を書き込んだりする作業は不要だ。この手順の簡潔さは、技術的な知識がないサイト運営者にとって大きな意味を持つ。
直接接続がもたらす安全性
Elementor MCPの接続では、アプリケーションパスワードはサイトとAIツールの間だけで保持される。Elementorがパスワードを閲覧することはなく、AIツールはサイトに直接接続する。中間に何かを介在させない設計になっている。
設定の手間を比較すると、Elementor内蔵MCPは技術的な知識がなくても接続できる。対してWordPress MCP Adapterと非公式サーバーは、設定ファイルの編集という作業が発生する。この差は実務上の導入障壁に直結する。
ProとAngieで広がる機能
Elementor単体でもMCP接続は可能だが、Elementor ProとAngieを追加すると、AIエージェントが扱えるAbilitiesの範囲が広がる。どちらを選ぶにせよ、MCP接続の方式とは独立した追加機能として考えるのがよい。
Elementor Proが追加するAbilities
Elementor Proは、Theme Builder、Loops、Forms、動的コンテンツ、表示条件などのツールを追加する。これらの機能がAbilitiesとして登録されることで、AIエージェントはより高度なサイト構築・編集作業を実行できるようになる。
Angieが開くプラグイン連携の幅
AngieはElementor公式のAIプラグインだ。カスタムウィジェットやアプリの生成、WordPress管理画面のカスタマイズ、サイト全体にわたる一括操作などをAIエージェントに提供する。Angie自身が独自のAbilitiesを持つことに加えて、他のプラグインがAbilities APIに登録した機能にも到達できるようになる。
具体的には、WooCommerce、Yoast、WPForms、Jetpack、ACFなどがAbilities APIに登録した機能を、Elementor MCPの接続を通じてAIエージェントが利用できる。1つの接続でサイト全体のスタックにアクセスできる点がAngie導入の強みだ。
Angieを導入すると、Elementorの機能に限定されないサイト全体の自動化が視野に入る。ECサイトの商品更新、SEO設定の調整、フォームデータの処理など、プラグインごとの機能をAIエージェントが横断的に扱えるようになる。
どの選択肢を選ぶべきか
3つの選択肢を比較したうえで、実際にどれを導入するかはサイトの状況によって異なる。ここではサイト運営のタイプ別に推奨を整理する。
サイト運営タイプ別の推奨
- Elementorを使っている場合 → 追加インストール不要の内蔵MCPから始めるのが最短。Elementor 4.3.0以降にアップデートして、ダッシュボードの「Elementor」→「Elementor MCP」から設定する。
- Elementorを使っていない場合 → WordPress MCP Adapterが公式の選択肢になる。ただし手動設定が必要なため、設定ファイルの編集に慣れていることが前提になる。
- 全プラグインのAbilitiesを横断的に使いたい場合 → ElementorユーザーならAngieを追加する。Elementorユーザーでなければ、Abilities API対応プラグインを個別に導入してWordPress MCP Adapterで接続する。
- セキュリティを最優先する場合 → 実績のある公式の選択肢（WordPress MCP AdapterまたはElementor MCP）を選ぶ。非公式サーバーは権限やデータ取り扱いを個別に精査してから判断する。
1つ留意すべき点がある。この比較はElementor公式ブログの記事に基づいており、自社製品に有利な視点が含まれる可能性は否定できない。特に「設定の簡潔さ」や「直接接続の安全性」といった評価は、Elementor側の主張として受け止めるのが妥当だ。
とはいえ、MCPの標準化そのものはプラグインやベンダーに依存しない動きであり、WordPress全体のエコシステムにとって前進である。WordPress MCP Adapterが公式ディレクトリに登場したことと、Elementorが内蔵MCPを提供したことは、どちらも「AIエージェントがWordPressに接続する」という流れを加速させる。
今後、WordPress MCP Adapterのバージョンが進み、設定画面が追加されれば、技術的な知識がない運営者でも公式アダプターを使いやすくなる可能性がある。Abilities APIに対応するプラグインが増えれば、MCP接続の価値はさらに高まる。選択肢の優劣は、時間とともに変わることを見越しておくのがよい。
この記事のポイント
- WordPress向けMCP接続には「WordPress MCP Adapter」「非公式MCPサーバー」「Elementor内蔵MCP」の3つの選択肢がある。
- WordPress MCP Adapterは2026年10月2日にWordPress.orgへ登場。バージョン0.7.0で、WordPress 6.9以降が必要。設定は手動。
- 非公式MCPサーバーはメンテナンスや権限のばらつきが大きく、本番サイトでは慎重な選定が必要。
- Elementor MCPは4.3.0以降に内蔵され、追加インストール不要。UIで数ステップの設定で完了する。
- Angieを導入すると、WooCommerceやYoastなど他プラグインのAbilitiesにも1つのMCP接続で到達できる。
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
CleanTalk更新後にサイトが落ちた時のFTP復旧と原因特定
CleanTalk（アンチスパムプラグイン）の更新後にサイト全体が表示されず、管理画面（wp-admin）にも入れなくなった場合は、FTPからプラグインフォルダの名前を変更して無効化するのが最短の復旧方法だ。アクセスを回復した後でエラーログを確認し、プラグインの再インストールや競合の切り分けを行えば原因を特定できる。
CleanTalk更新後にサイトが落ちる主な原因
CleanTalkはスパムコメントや迷惑メール送信を防ぐため、WordPressの全リクエストに介入して送信元IPアドレスをクラウド上の判定サーバーに照会する。この仕組みは強力だが、更新後のコードがサーバー環境と合わなかったり、ほかのプラグインと衝突したりすると、ページ表示の段階で致命的なエラーが発生する。
典型的な原因は次の通りだ。プラグイン更新時のファイル破損、PHPバージョンとの非互換、セキュリティ系プラグインやキャッシュプラグインとの競合、データベース上のテーブル定義差分、そしてCleanTalkのAPIサーバーに接続できないタイムアウトなどが考えられる。このうちどれが該当するかは、後述するエラーログの確認で絞り込める。
このデモはCleanTalk更新によってサイトが停止した状態と、FTPでの無効化による復旧後の状態を表している。更新のたびにページが落ちるのではなく、特定のバージョンや環境の組み合わせで起きることが多い。
FTPでプラグインを無効化してサイトを復旧する手順
管理画面に入れない状態では、サーバー上のファイルを直接操作してプラグインを無効化する以外に確実な方法はない。手順はシンプルで、FTPクライアントかレンタルサーバーのファイルマネージャーがあれば5分程度で完了する。焦らず順番に進めてほしい。
この手順はCleanTalkの主要フォルダ名を変更して、WordPressにプラグインを認識させない仕組みだ。以後の詳しい操作を各STEPに分けて説明する。
FTPクライアントでプラグインディレクトリへ接続する
FTPクライアント（FileZillaやWinSCPなど）を起動し、レンタルサーバーから発行されたFTPホスト名・ユーザー名・パスワードを使って接続する。接続後、サイトのドキュメントルートにあるwp-contentフォルダを開き、その中のpluginsフォルダへ移動する。レンタルサーバーの管理画面にあるファイルマネージャーでも同じ操作が可能だ。
CleanTalkのフォルダ名を変更して無効化する
pluginsフォルダ内にcleantalk-spam-protectというフォルダがある。これを選択してリネームし、末尾に-disabledや-offを付ける。フォルダ名を変えるだけでWordPressはプラグインを見失い、強制的に無効化される。これは「手動によるプラグイン無効化」と呼ばれ、管理画面が使えない時の最終手段として最も確実な方法だ。
サイトと管理画面へのアクセスを確認する
リネームが終わったらブラウザを開き直し、サイトのトップページとwp-adminの両方にアクセスする。正常に表示されれば復旧は成功だ。管理画面の「プラグイン」ページを開くと、CleanTalkが「無効化されています」と表示されるはずだ。ここで「削除」はまだ選ばず、原因調査に進む。
CleanTalkを安全に再有効化して原因を特定する手順
サイトが復旧したら、次はCleanTalkを再び使える状態に戻すための調査を行う。いきなり同じ設定で再有効化すると再発する可能性が高い。エラーログの確認、競合の切り分け、クリーンインストールの順で進めるのが安全だ。
WordPressのエラーログを確認する
まずwp-config.phpに以下の記述を追加してデバッグモードを有効化する。この設定により、ページ表示時に発生した具体的なエラー内容がログファイルに記録される。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );上書き保存後、wp-contentフォルダ内にdebug.logが生成される。この中に「PHP Fatal error」や「Uncaught Error」という行があれば、エラーの発生場所（ファイル名と行番号）が表示される。CleanTalk関連のパス（cleantalk-spam-protect）が含まれているか確認し、含まれていればそれが直接の原因だ。記録が終わったらデバッグモードは必ずfalseに戻す。
ほかのプラグインとの競合を切り分ける
CleanTalkを再有効化する前に、セキュリティ系プラグインとキャッシュ系プラグインを一時的に無効化してから試す。特にWordfenceやSucuriなどのセキュリティプラグイン、W3 Total CacheやWP Super Cacheなどのキャッシュプラグインは、CleanTalkのリクエスト監視と競合しやすい。標準テーマ（Twenty Twenty-Fiveなど）に切り替えた状態でCleanTalkを有効化し、問題が再現するかを確認すると環境の絞り込みが早い。
このデモは競合切り分けの基本フローを表している。すべてのプラグインを無効化した状態からスタートし、CleanTalkだけを先に有効化して問題がなければ、ほかのプラグインを1つずつ戻していく。
CleanTalkをクリーンインストールする
FTPでリネームしたフォルダを削除し、管理画面の「プラグイン」→「新規追加」から「Anti-Spam by CleanTalk」を検索して再インストールする。最新版が配布されており、以前のバージョンで発生していた不具合が修正されているケースも多い。インストール後、APIキー（CleanTalkのダッシュボードで発行されるアクセスキー）を再入力すれば設定はクリーンな状態から始められる。設定のバックアップがなくても、APIキーさえあればスパム対策の主要機能はすぐに再開される。
PHPとWordPressのバージョンを確認する
管理画面の「ツール」→「サイトヘルス」を開くと、現在のPHPバージョンとWordPressバージョンが表示される。CleanTalkが要求するPHPの最低バージョンを下回っている場合は、レンタルサーバーの管理画面からPHPバージョンを上げる操作が必要になる。PHP 8.3や8.4が最新系だが、ほかの古いプラグインとの兼ね合いも確認してから変更しよう。
更新トラブルを防ぐための設定と運用のポイント
CleanTalkに限らず、プラグインの自動更新が原因でサイトが落ちる事故は定期的に発生する。被害を最小限に抑えるには、更新前のバックアップ、ステージング環境での事前検証、自動更新の制御という3つの対策が有効だ。
更新前にバックアップを取る
レンタルサーバーが提供する自動バックアップに加えて、データベースとファイルの両方を手動で取得しておくと安心だ。管理画面が落ちてもFTPから復元できるため、今回のようなプラグイン停止事故から数分で元に戻せる。バックアッププラグインもこの目的に使えるが、プラグイン自体が競合の原因になり得るため、サーバー側のバックアップを優先するのが安全だ。
ステージング環境で更新を検証する
ビジネスで運用しているサイトでは、本番環境と同一構成のステージング環境（テスト用の複製サイト）を用意し、そこにプラグイン更新を適用して表示確認するのが理想だ。レンタルサーバーによっては管理画面からステージングサイトを簡単に作れる。更新後24時間以内に問題が起きなければ本番に反映する、という運用で更新事故の大半は防げる。
自動更新を制御する
WordPressではプラグインごとに自動更新の有効・無効を設定できる。更新直後にサイトが落ちた経験があるなら、CleanTalkの自動更新を無効化し、手動で更新する運用に切り替えるのが現実的な対策になる。自動更新を完全に止めるのではなく、メジャーアップデート（1.0→2.0など）は手動、マイナーアップデート（1.1→1.2など）は自動という使い分けも有効だ。
よくある質問
CleanTalkを無効化している間、スパム対策はどうなるか
CleanTalkを無効化している間は、スパムコメントや迷惑フォーム送信をブロックできなくなる。短期間のメンテナンス中は、WordPress標準の「コメントは管理者の承認が必要」設定や、Akismetなど別のアンチスパム機能で一時的にカバーする。運用上、数日程度の無効化であれば大きな被害にはなりにくいが、早めの再有効化を目指したい。
FTPの接続情報がわからない場合はどうするか
レンタルサーバーの管理画面にログインし、FTPアカウントの作成・確認ページを開けば、ホスト名・ユーザー名・パスワードを確認または再発行できる。管理画面のファイルマネージャー機能があればFTPクライアントは不要で、ブラウザ上でプラグインフォルダのリネームが可能だ。どちらも使えない場合は、サーバー運営会社のサポートに連絡して対応を依頼する。
CleanTalkを更新するたびにサイトが落ちるが、根本対策はあるか
更新のたびに症状が再発するなら、特定のプラグインとの組み合わせやサーバー環境に原因がある可能性が高い。エラーログに記録された発生場所をCleanTalkのサポートに報告し、修正版のリリースを待つか、設定項目で競合しやすい機能（スパムファイアウォールなど）を無効化して回避する。プラグインの更新を手動に切り替え、事前検証を徹底することも有効な根本対策になる。
复旧後にCleanTalkの設定は引き継がれるか
FTPでフォルダ名を変更しただけなら、設定はデータベースに残っているため、元のフォルダ名に戻せば従来の設定のまま再有効化される。一方、クリーンインストール（フォルダ削除→新規インストール）を行うと設定がリセットされるため、APIキーを再入力する必要がある。どちらを選ぶかは、問題の深刻度と設定の複雑さで判断するとよい。
この記事のポイント
- CleanTalk更新後にサイトが落ちたら、まずFTPでプラグインフォルダをリネームして無効化する
- 復旧後はエラーログ（debug.log）を確認し、発生場所を特定する
- 競合切り分けは全プラグイン無効化→CleanTalk単体で有効化→1つずつ戻す手順で行う
- クリーンインストールとPHPバージョン確認で再発を防ぐ
- バックアップ・ステージング環境・手動更新への切り替えが更新事故の根本対策になる
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
TablePress 3.4更新後にテーブルが表示されない時の原因と安全な復旧手順
TablePress 3.4に更新した後にテーブルがショートコード [table id=28 /] のまま表示されない場合、まずプラグインが停止しているか、ショートコードの処理が途中で失敗しているかを確認する。サイト内検索まで動作しなくなったケースでは、古いテーブルデータの保存形式に不整合が起きている可能性が高いが、バックアップを取ればデータを失わずに復旧できる。
TablePress 3.4への更新後にテーブルが表示されない原因
TablePress は、投稿や固定ページに書かれた [table id=28 /] というショートコードを、実際の表の HTML に置き換えて表示する仕組みになっている。プラグインが無効化されていたり、更新の途中で停止していたりすると、この置き換えが行われず、ショートコードがそのまま画面に出る。
更新直後にショートコードだけが見える症状と、プラグイン停止という原因の関係を表したものだ。停止が原因なら再有効化だけで表は戻る。
ショートコードがそのまま表示される仕組み
ショートコードは、WordPress のプラグインがページ表示のタイミングで処理する仮の置き場だ。TablePress が有効な状態なら表に変換されるが、無効になると [table id=28 /] という文字列が読者に見えてしまう。更新後にこの症状が出た場合は、更新処理が最後まで完了せずプラグインが自動で停止したケースが多い。
更新後にプラグインが自動で停止していないか確認する
WordPress の管理画面で「プラグイン」メニューを開き、TablePress の状態を確認する。「有効化」ボタンが表示されていれば、更新後に何らかの理由で停止している。まず一時的に有効化し、テストページで表が表示されるか、サイト内検索が動くかを順に確かめる。
なぜ更新後にサイト内検索が動かなくなったのか
TablePress のデータは、WordPress の投稿と同じデータベースの wp_posts テーブルに保存されている。テーブル本体は JSON という書式で格納されるため、3.4 更新後に古い形式のデータを読み込む処理が変わると、サイト全体の投稿一覧や検索クエリにエラーを引き起こすことがある。特に公開サイトの検索フォームが正常に動作しなくなる症状が報告されている。
古いテーブルデータの保存形式と不整合のリスク
長年運用してきたサイトでは、TablePress が過去に保存したテーブルデータが現在の期待する形式と異なる場合がある。3.4 ではテーブルの読み込み処理が更新されたため、旧形式のデータをそのまま読み込むと PHP の警告や致命的エラーが発生し、結果として検索機能まで落ちることがある。
検索が壊れたときはプラグイン切り分けで特定する
TablePress を無効化して検索が復活したなら、原因は TablePress 側にある可能性が高い。より正確に切り分けるには、TablePress を有効化したままテーブルを1つずつ再保存し、どのテーブルで検索が止まるかを調べる。これにより、データの破損箇所を特定できる。
バックアップを取ったうえで安全に復旧する手順
復旧作業は、必ず現状のバックアップを確認してから進める。ショートコードが表示されたままの公開ページを放置せず、次の手順で原因の切り分けと復旧を行う。
復旧の作業は5段階で進める。いきなり全テーブルを変更せず、表示と検索を細かく確認しながら原因を絞り込むのが安全だ。
復旧前に実施するバックアップの確認
UpdraftPlus のようなバックアッププラグインで、サイト全体とデータベースのバックアップが最新であることを確認する。バックアップの復元方法も1度確認しておくと、万が一テーブルデータを誤って書き換えても元に戻せる。
プラグインの再有効化と表示確認
プラグイン画面で TablePress を有効化し、問題が出ているページを1つだけ開いて表が表示されるか確認する。このときサイト全体のキャッシュが残っていると古い画面が見えるため、シークレットウィンドウや別ブラウザで確認すると正確だ。
古いテーブルを1つずつ再保存して切り分ける
TablePress の管理画面で「テーブル一覧」を開き、公開している各テーブルを編集画面で開いて「変更を保存」を押す。再保存で現在の形式にデータが整い、古い形式に起因するエラーが解消されることが多い。1つ保存するたびに検索が動くかを確認すれば、問題のあるテーブルを特定できる。
ブラウザとサイトのキャッシュを削除して再確認
再保存後も症状が続く場合は、WordPress のキャッシュ系プラグインやサーバー側のキャッシュを削除し、ブラウザのキャッシュもクリアする。キャッシュが残ったままだと、修正後の状態を確認できない。
古いテーブルデータの不整合を調べて修正する方法
古いテーブルデータの不整合が原因で検索まで壊れた場合は、テーブルを再保存するだけでなく、データの中身を直接確認する方法も有効だ。焦らず1つずつ確認すれば、過去の歴史データを失わずに済む。
どのテーブルが古い形式かを特定する方法
TablePress のテーブル一覧で、更新日時が古いテーブルや、長期間編集していないテーブルを優先して確認する。古い形式のデータは、特に大量の行を持つテーブルで問題を起こしやすい。まず行数の多いテーブルから再保存を試す。
JSONデータの破損を修復する手順
TablePress のテーブルは JSON 形式でデータベースに保存されている。破損が疑われる場合は、TablePress の「エクスポート」機能で CSV として書き出し、内容を確認してから新しいテーブルとして読み込む。これにより JSON の構造が新しく作り直され、破損が解消される。
エクスポートと再インポートでデータを整える
元テーブルをエクスポートして CSV を保存し、TablePress の「インポート」で新しいテーブルとして取り込む。取り込み後にショートコードの ID が変わらないよう、元のテーブルを削除して同じ ID に割り当てるか、元テーブルを編集して CSV を貼り直す。ID を変えたくない場合は、テーブル編集画面で内容を丸ごと貼り直すのが安全だ。
旧バージョンへ戻す一時的な対処と再更新の判断
場合によっては、TablePress 3.4 自体の不具合が原因で、データを整えても検索や表示が直らないことがある。その場合は旧バージョンへ戻して一時的に安定させ、修正版のリリースを待つのが現実的な選択になる。
旧バージョンを入手して手動で戻す手順
WordPress.org の TablePress プラグインページにある「詳細を表示」から過去のバージョンを取得する。管理画面の「プラグイン > 新規追加 > プラグインのアップロード」で旧バージョンの ZIP をアップロードすると、現在のバージョンを上書きして戻せる。アップロード前には必ずバックアップを取り直す。
ロールバック後に再度更新するタイミング
旧バージョンへ戻したら、WordPress の更新通知で TablePress 3.4 の修正版が出るまで自動更新を止めておくことも検討する。修正版が公開されたら、テスト環境か深夜の時間帯で更新し、表示と検索を再確認してから本番に適用する。
よくある質問
TablePress を再有効化したら検索が再び壊れるのでは？
まずテーブルを1つずつ再保存してから検索を確認すれば、問題のあるテーブルだけを特定できる。再保存後も検索が壊れるなら、旧バージョンへ戻すか、プラグインの修正版を待つ。バックアップがあれば元に戻せるため、慌てて全データを消す必要はない。
古いテーブルだけが表示されないのはなぜか
古いテーブルはデータの保存形式が現在の TablePress と一致していない場合がある。編集画面で開いて保存し直すと現在の形式に変換され、表示されるようになることが多い。
TablePress を無効化したままでもデータは消えないか
プラグインを無効化しても、テーブルのデータはデータベースに残る。プラグインを削除しない限り過去のデータは保持される。ただし安全のため、無効化中もバックアップを取っておく。
ショートコードが表示されたまま放置するリスクは？
訪問者に [table id=28 /] という文字列が見え続けると、サイトの信頼性が下がる。検索エンジンのクローラーも表の内容を取得できないため、早めに再有効化か代替表示へ切り替える。
キャッシュ系プラグインを使っている場合の注意点は？
修正後も古い画面が表示され続ける場合は、キャッシュ系プラグインの全キャッシュ削除とブラウザのキャッシュクリアを行う。サーバー側のキャッシュが残っていることもあるため、ホスティングの管理画面も確認する。
この記事のポイント
- 更新後にショートコードが見えるのはプラグイン停止が主な原因
- まずバックアップを確認し、それから再有効化する
- 検索が壊れた場合は古いテーブルデータの不整合を疑う
- テーブルを1つずつ再保存して問題箇所を特定する
- 直らないときは旧バージョンへ戻して修正版を待つ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress管理画面でトグル設定が勝手にオンに戻る時の原因と対処法
WordPress管理画面のトグル設定をオフにしても勝手にオンに戻る場合、原因は主にJavaScriptエラーかキャッシュの不整合にある。トラッキング不具合時の診断メール設定が保存されない症状では、画面の表示とデータベースの値がずれている可能性が高く、切り分け手順を順に試すことが最も確実な対処法だ。
トグル設定が勝手にオンへ戻るのはなぜか
WordPressの管理画面にあるトグルボタンは、押した瞬間にAJAX通信でサーバーへ設定値を送信する仕組みだ。送信された値はnonce検証を経てデータベースに保存される。ここで問題が起きると、画面上ではオフに切り替わったように見えても、データベースには保存されないままになる。
別のページへ移動して戻った時、画面はデータベースから最新の設定値を読み込む。保存が失敗していれば、以前の値がそのまま表示されるためトグルがオンへ戻ったように見える。これが今回の症状の正体だ。
特に「トラッキング不具合時の診断メール」のような通知系の設定は、プラグイン側がデフォルトでオンにする仕様になっている場合がある。保存の失敗とデフォルト値の再適用が重なると、オフにしても戻るという挙動が顕著に現れる。
原因になりやすい要素は以下のとおりだ。
- 管理画面でJavaScriptエラーが発生しAJAX送信が失敗している
- キャッシュプラグインやオブジェクトキャッシュが古い設定値を返している
- テーマや別のプラグインが設定を強制的にオンへ戻している
- セキュリティプラグインがnonce検証やAJAX通信をブロックしている
- データベースへの書き込み権限やオプション保存処理に問題がある
このデモはトグル設定の保存が正常に終わる場合と、途中で失敗して次回表示時に設定が戻ってしまう場合のフローを示している。次節からは原因を特定するための手順を具体的に進めていく。
JavaScriptエラーをブラウザで確認する手順
最初に確認するべきは管理画面でJavaScriptエラーが発生していないかだ。ブラウザの開発者ツールを使えば、AJAX通信が失敗した原因を直接確認できる。Chromeの場合はF12キー、Macの場合はCommand＋Option＋I、Windowsの場合はCtrl＋Shift＋Iで開発者ツールが開く。
開発者ツールが開いたらConsoleタブに切り替える。ここに赤いエラーメッセージが表示されていれば、それがトグル設定の保存を妨げている原因になる。特に「FAILED」「POST」「403」「500」のような表示がある場合は、AJAX通信そのものが失敗している証拠だ。
エラーが確認できた場合は、エラーメッセージの内容を控えておく。ファイル名や関数名が表示されていれば、どのプラグインやテーマがエラーの原因かを特定する手がかりになる。調査を次の段階へ進める前に、まずはエラーの有無を確認するだけで状況が大きく変わる。
このデモはJavaScriptエラーの確認から発生源の特定までを順に示している。トグル操作を再現してエラーが増える場合は、そのトグルに関連するスクリプトでエラーが起きている可能性が高い。
キャッシュを削除して保存状態を確認する方法
JavaScriptエラーが見つからない場合はキャッシュの影響を疑う。サイト全体のキャッシュを削除してからトグル設定を再度オフにし、別ページへ移動して戻るという流れで確認する。WordPressでは複数のキャッシュ層が重なっていることがあり、それぞれを順にクリアする必要がある。
キャッシュプラグインのキャッシュを削除する
キャッシュプラグインを利用している場合は、プラグインの管理画面からキャッシュを全削除する。代表的なプラグインでは「キャッシュを消去」「Purge All」のようなボタンが用意されている。削除後、トグル設定をオフにして別ページへ移動し、戻って状態を確認する。
オブジェクトキャッシュを無効化して確認する
高速化のためにRedisやMemcachedといったオブジェクトキャッシュを導入している場合は、一時的に無効化して確認する。オブジェクトキャッシュはデータベースの値をメモリ上に保持するため、更新処理が古い値を返し続けてしまうことがある。wp-config.phpに記載されているキャッシュ関連の設定を一時的に外すか、サーバー側のキャッシュサービスを停止してテストする。
ブラウザキャッシュを削除する
ブラウザ側のキャッシュが管理画面の表示に影響することは少ないが、シークレットウィンドウを使えば完全にキャッシュの影響を排除できる。シークレットウィンドウで管理画面へログインし、トグル設定をオフに変更してから別ページへ移動し、再度戻って状態を確認する。この方法で問題が再現しなければ、通常のブラウザセッションにキャッシュが残っていたことになる。
プラグイン競合を切り分ける手順
JavaScriptエラーやキャッシュの影響が見つからない場合、次に疑うのはプラグイン同士の競合だ。特にセキュリティ系プラグインや高速化系プラグインは、管理画面のAJAX通信に干渉することがある。テーマに含まれるスクリプトが原因になることも少なくない。
切り分けは次の順序で行う。まず全プラグインを一括で無効化し、標準テーマ（Twenty Twenty-FourやTwenty Twenty-Fiveなど）へ切り替える。この状態でトグル設定をオフに変更し、別ページへ移動して戻る操作を行い、設定が保持されるか確認する。
この状態で問題が再現しなければ、プラグインの1つずつを有効化して同様の操作を繰り返す。問題が再現した時点で、直前に有効化したプラグインが原因の可能性が高い。特定できたらそのプラグインの設定を見直すか、開発元へ情報を集める。
なお全プラグインの一括無効化はサイトの表示にも影響を与える。切り分け作業を行う場合は、アクセスの少ない時間帯を選ぶかステージング環境を利用する。
このデモはプラグイン競合の特定を効率的に進めるための順序を示している。問題が再現したタイミングを記録しておくと、原因プラグインの特定がスムーズになる。
データベースの設定値を直接確認して修正する方法
ここまでの切り分けで原因が特定できない場合は、データベースに保存されている設定値を直接確認する。WP-CLI（WordPress Command Line Interface。WordPressのコマンドライン操作ツール）が使える環境であれば、管理画面を経由せずにオプション値を調べられる。
WP-CLIでオプション値を検索する
トグル設定に関連するオプション名を確認するには、wp option listコマンドを使う。オプション名はプラグインごとに異なるが、diagnosticやtrackingといったキーワードを含むものが対象になる。該当するオプションの値がオン（1やyesと表示される）になっていれば、設定がデータベースに保存されていないことが確定する。
wp option list | grep -i diagnostic
wp option list | grep -i tracking見つかったオプション名を指定して値を確認するには、wp option getコマンドを使う。値がオンを示していれば、トグル設定が保存されていないことになる。値がオフを示していれば、保存自体は成功しているため別の要因が影響している。
wp option get 該当するオプション名phpMyAdminで直接確認する場合
WP-CLIが使えない環境ではphpMyAdminを使う。データベース内のwp_optionsテーブル（プレフィックスが異なる場合は該当するテーブル）から、option_name列にキーワードを含む行を検索する。option_value列の値がオンを示していれば保存が失敗している。
検索にはSQL文を使う。プレフィックスは環境によって異なるため、テーブル名を確認してから実行する。
SELECT * FROM wp_options WHERE option_name LIKE '%diagnostic%';直接データベースを変更する場合は必ずバックアップを取ってから行う。設定値がシリアル化された配列の中に含まれている場合、直接変更するとデータ構造が崩れるリスクがある。不安がある場合は手動更新を避け、プラグインの設定画面から保存し直す方が安全だ。
このデモはデータベースの設定値の状態から原因の方向性を切り分ける方法を示している。保存の成否を知ることで、その後の調査対象を絞れる。
よくある質問
トグル設定が勝手に戻るのはいつどんな状況で起きるのか
主にJavaScriptエラーが発生している場合に起きやすい。管理画面のトグルはAJAX通信で設定を保存するが、他のプラグインやテーマが読み込むスクリプトと競合して通信が失敗すると、画面表示だけが切り替わって保存が行われない。キャッシュプラグインの影響で古い設定値が表示される場合もある。
キャッシュプラグインを使っていないのに設定が戻るのはなぜか
サーバー側のオブジェクトキャッシュやホスティング会社が提供する静的キャッシュが影響している可能性がある。またテーマのfunctions.phpや別のプラグインに、設定を強制的にオンへ戻すコードが含まれている場合もある。データベースの値を直接確認すれば保存の成否がわかる。
セキュリティプラグインが原因になることはあるか
ある。セキュリティプラグインが管理画面のAJAXリクエストやnonce検証をブロックすると、設定の保存が失敗する。ファイアウォール機能が過剰に反応して管理画面の操作を妨げるケースがあるため、一時的に無効化して切り分けを行う必要がある。
設定値をデータベースから直接変更しても問題ないか
問題ない場合が多いが、バックアップを取ってから行うことが必須。WP-CLIでオプション名を確認してからupdate_optionを行う。ただしプラグインの設定構造によってはシリアル化された配列に含まれており、直接変更が難しいこともある。不安がある場合はプラグインの設定画面から保存し直す方が安全だ。
本体のアップデートで解消されることがあるか
ある。プラグイン側のバグが原因の場合は本体アップデートで修正されることが多い。プラグインとWordPress本体を最新版に更新してから再度確認する価値は十分にある。ただし更新前にバックアップを取っておくと安心だ。
この記事のポイント
- トグル設定が勝手に戻る原因の多くはJavaScriptエラーかキャッシュの不整合
- ブラウザの開発者ツールでconsoleエラーを確認するのが最初の切り分け手順
- キャッシュプラグインとオブジェクトキャッシュを順に無効化して特定する
- プラグインを全停止し1つずつ再有効化して競合元を見つける
- 最終手段としてWP-CLIやphpMyAdminからデータベースの設定値を直接確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce Dual APIが専用プラグインに移行、コアから削除へ
WooCommerce 11.2で、実験的なDual APIエンジンがコアから削除され、専用プラグインとして提供される。10.9から11.1まで利用できた検証用の商品・クーポンAPIも廃止されるため、使っていた開発者は対応が必要だ。
Dual APIとはPHPクラスからGraphQLエンドポイントを自動生成するコードファーストな仕組みで、WooCommerce 10.9で実験機能として導入された。今回の変更は、開発の自由度を高めるための構成変更である。
WooCommerce 11.2でDual APIの提供形態が変わる
WooCommerce 10.9で導入されたDual APIは、PHPクラスを定義するだけでGraphQLエンドポイントを生成できる実験的な拡張機能だった。これまではWooCommerce本体に組み込まれ、フィーチャーフラグで有効化する方式だった。
WooCommerce 11.2では、このDual APIエンジンがWooCommerceコアから削除される。代わりに、WooCommerce Dual APIプラグインとして独立したリポジトリで提供される形だ。
この変更により、WooCommerce本体のリリースサイクルに縛られず、Dual APIだけを柔軟にアップデートできるようになる。Dual APIエンジン自体は、独自のAPIを開発したいエクステンション開発者にとって引き続き有用だ。
検証用の商品・クーポンAPIは削除される
WooCommerce 10.9から11.1まで、商品とクーポンに関する検証用APIが組み込みで提供されていた。このAPIはWooCommerce 11.2で削除される。
この検証用APIを使っていた開発者は、利用を停止するか、自前のエクステンションで同等のAPIを構築する必要がある。注意点として、Dual APIプラグインをインストールしても、この検証用エンドポイントが復活することはない。
Dual API移行で開発者が知るべき変更点
独自のDual APIを開発しているエクステンション開発者には、いくつか重要な変更がある。フィーチャーフラグの廃止、APIビルダースクリプトの移設、ドキュメントの場所変更、そして依存関係の宣言方法だ。
プラグイン依存関係をヘッダーに宣言する
これまでDual APIエンジンを有効化していたフィーチャーフラグは利用できなくなる。代わりに、Dual APIプラグインをインストールして有効化することでエンジンが使えるようになる。プラグインの要件はWooCommerce 11.2以上、PHP 8.1以上だ。
エクステンションがDual APIエンジンに依存する場合、プラグインのヘッダーで両方の依存関係を宣言する必要がある。具体的には以下のように記述する。
Requires Plugins: woocommerce, woocommerce-dual-apiこの記述により、エクステンションのインストール時にWooCommerce本体とDual APIプラグインの両方が必要であることが明示される。依存関係の宣言は、プラグインの動作に必要な前提条件をユーザーに伝える重要な役割を果たす。
APIビルダーとドキュメントの場所が変わる
APIビルダースクリプトは、WooCommerce Dual APIプラグインのリポジトリに移動した。利用するには、プラグインをインストールするか、リポジトリをローカルにクローンする。
ドキュメントもDual APIプラグインのリポジトリ内に移設された。GitHub Pagesでも閲覧できる形で提供されている。開発者は最新のドキュメントをプラグインリポジトリで確認することになる。
エンドポイント登録のコード例
Dual APIプラグインはエンジンを提供し、エクステンション側で独自のGraphQLエンドポイントを登録する。WooCommerceのシンプルイベントサンプルプラグインから、登録方法のコードを示す。
use Automattic\WooCommerce\Api\Infrastructure\Main as DualApiMain;
add_action(
'plugins_loaded',
static function () {
if ( method_exists( DualApiMain::class, 'register_graphql_endpoint' ) ) {
DualApiMain::register_graphql_endpoint(
__DIR__,
'wc',
'/graphql/simple-events'
);
}
}
);このコードは、プラグインの読み込み時にDual APIエンジンが利用可能か確認し、利用可能であればGraphQLエンドポイントを登録する。エンドポイントのパスや名前空間はエクステンションごとに自由に設定できる。
Dual APIは引き続き実験的ステータス
Dual APIはプラグインに移行した後も、実験的なステータスは変わらない。Automattic\WooCommerce\Api名前空間以下のすべての要素は、後方互換性のない形で変更される可能性がある。
つまり、将来のリリースでAPIの構造が変わったり、削除されたりする可能性があるということだ。このため、本番環境のエクステンションでDual APIを使用することは推奨されていない。開発用途や検証目的に限定して使うべきだろう。
開発者コミュニティへのフィードバック募集
WooCommerceチームは、Dual APIエンジンが実際に有用かどうか、非実験的な状態でWooCommerce本体に含めるべきか、改善点はないかについて、開発者からの意見を求めている。
フィードバックはGitHubの専用ディスカッションページで受け付けている。Dual APIを試した開発者は、実際の使用感や要望を共有することで、今後の方向性に影響を与えることができる。
この記事のポイント
- WooCommerce 11.2でDual APIエンジンがコアから削除され、専用プラグインとして独立した
- 10.9〜11.1の検証用商品・クーポンAPIは削除されるため、利用者は移行が必要
- プラグインの要件はWooCommerce 11.2以上、PHP 8.1以上
- 依存関係はプラグインヘッダーで宣言する
- 引き続き実験的ステータスであり、本番利用は推奨されない
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
ByTheWeb AIレビュー！無料GEOプラグインでAI検索に引用されるサイトを目指す
ChatGPTやGeminiなどAI検索の利用が広がる中、従来型SEOだけでは不十分な局面が増えてきた。GEO（Generative Engine Optimization / 生成AI向け最適化）と呼ばれる、生成AIにサイトを理解させるための最適化が必要になっている。検索エンジン向けにメタディスクリプションやXMLサイトマップを整えても、AIが回答を組み立てる際に情報源として引用されるとは限らない。
WP Mayorの2026年9月2日付レビューをもとに、ByTheWebの料金体系、主要機能、実務での使い方、プライバシー面を整理した。
AI検索対策を低コストで始めたい中小企業や個人ブロガーが、この無料ツールをどこまで使えるかを判断するための内容だ。
ByTheWeb AIの全体像
ByTheWebは2つのWordPressプラグインに分かれている。無料のByTheWeb GEOがAI可読性スコアの算出、スキーマ生成、llms.txt出力、robots.txt管理という土台部分を担う。ここでllms.txtは、大規模言語モデル向けにサイト情報を整理したテキストファイルだ。任意のByTheWeb AIはクレジット制のアシスタントとして、不足するフィールドの自動補完やメタ情報の生成をクラウド処理で行う。
重要なのは、どちらのプラグインも必須ではない点だ。ByTheWeb GEOはアカウントなしで手動機能をすべて使える。ByTheWeb AIは無料のAPIキーを接続して初めて生成機能が動く。この分離設計により、クレジット消費を伴うAI機能だけを後から追加できる。
料金とクレジットの仕組み
ByTheWeb GEOの基本機能は無料だ。ダッシュボード、スキーマ、llms.txt、サイトマップ、robots.txt、手動フィールドはアカウント登録なしで利用できる。費用が発生するのはByTheWeb AIを接続した場合に限られる。新規アカウントには30日間有効の5,000クレジットが付与される。
試用期間後の有料プランは4段階ある。いずれも1プランで対応するドメインは1つで、未使用クレジットは翌月に繰り越されない。
- Starter AIは月額10.95米ドルで5,000クレジットを利用できる
- Creator AIは月額19.95米ドルで10,000クレジットを利用できる
- Growth AIは月額29.95米ドルで20,000クレジットを利用できる
- Pro AIは月額39.95米ドルで30,000クレジットを利用できる
クレジットの消費量はAIアクションごとに異なる。1回の操作で50クレジットで済む場合もあれば、450クレジットを消費する場合もある。利用頻度が高い場合は、月に何回のAIアクションを実行するかを事前に見積もるとよい。
プラグインとは別に、ByTheWebは無料のAI可視性およびSEOサイトスキャナーも提供している。URLを入力すると、OpenAI、Google Gemini、Perplexity、Claudeがそのビジネスをどう理解しているかを、実際のWeb検索結果と引用元付きで確認できる。接続と検証を済ませるとレポート全体が閲覧可能になり、見つかった課題をWordPressツールで修正できる。
主要機能の解説
AI向けフィールドとllms.txt
ByTheWeb GEOの中心となるのが、Short AnswerとAI Summaryという2つのAI向けフィールドだ。Short Answerは質問への直接的な一文回答であり、AI Summaryは重要事実を箇条書きにしたスキャンしやすい要約である。どちらもサイトが自動生成するllms.txtファイルに反映される。必要に応じてllms-full.txtとしてMarkdown形式の完全版も出力できる。
FAQビルダーは手動で書いた質問をJSON-LD形式のFAQスキーマへ変換する。ここでスキーマとは、ページ内容を検索エンジンやAIが機械的に理解できるよう構造化するマークアップの一種だ。JSON-LDはその構造化データを記述するフォーマットである。ショートコードまたはElementorウィジェットで訪問者にも表示できる。
そのほか、Article、Organization、Person、Local Business、Service、BreadcrumbListの各スキーマと、sameAsおよびContactPointフィールドが構造化データの側面を補う。sameAsは自社の公式プロフィールを紐付けるためのフィールドだ。
従来のSEO機能と既存プラグインとの共存
AI向け機能に加えて、ByTheWeb GEOは従来型のSEOレイヤーも備える。タイトルとメタディスクリプションの文字数インジケーター、最適化チェック、スマート変数を使った動的テンプレートの作成が可能だ。WP Mayorのレビューでは、主要なSEOプラグインにある基本機能はおおむねこちらでも揃っていると指摘されている。
ByTheWeb GEOはYoast SEOやRank Mathと併用できる。機能が重複するフィールドは重複を避けて調整される一方で、GEOスコアとスキーマ機能はそのまま有効になる。既存のSEOワークフローにByTheWebを追加しやすい設計だ。
実務での使い方とGEOスコア改善
初期設定とスキャン
ByTheWeb GEOをインストールして有効化すると、WordPress管理画面に専用メニューが追加され、バックグラウンドで初回サイトスキャンが実行される。最初にGEO設定とSEO設定の画面で、ビジネス名や所在地などの基本情報を登録するとよい。両方のプラグインを有効にした場合、Needs Attention（要対応）テーブルからページごとのGEOスコアを確認できる。スコアが低いページが上に並ぶため、改善対象を見つけやすい。
スコア改善の流れとAIアシスト
Short Answer、AI Summary、FAQを手動で追加すると、そのページのGEOスコアは上がる。これらの情報はページソースのメタタグやFAQスキーマとして出力され、llms.txtにも反映される。ByTheWeb AIを接続している場合は、不足フィールドの横にあるボタンを押すだけで自動生成できる。生成前にはページ内容、任意のトピック指定、クレジット消費量が表示される。
生成結果の編集が必要かどうかは、元のページにどれだけ情報があるかに左右される。このツールはゼロからリサーチするのではなく、ページ上の情報を素材にするためだ。既存コンテンツが充実していれば、そのまま使える精度の出力が得られやすい。
このデモは、AI検索に引用される状態への変化を概念として示したものだ。実際の改善はプラグインが算出するスコアに沿って進める。スコアが上がると、ChatGPTやGeminiが回答の根拠としてサイトを使う可能性が高まる仕組みだ。
プライバシー、サポート、総合評価
クラウド処理とプライバシー
ByTheWeb AIでコンテンツ生成を実行すると、該当ページの内容とドメイン情報がByTheWebのクラウドサービスを経由する。WP Mayorのレビューでは、厳格なデータ処理要件を持つサイトはプライバシーポリシーを確認し、必要に応じて運営チームへ問い合わせるべきだと触れられている。手動機能だけを使う場合はクラウド処理が発生しない。
サポート体制
サポートはWebサイト上のチケットシステムで受け付ける。WordPressプラグインのダッシュボードから簡単にアクセスできる。ナレッジベースには基本機能と一部の応用ケースがまとめられており、多くは短い動画ガイド付きだ。WP Mayorのレビューでは、動画だけでなくテキストによる詳しい説明が増えるとさらに良いという指摘もある。
導入に向くサイトタイプ
WP Mayorのレビューでは、ブロガー、複数サイトを監査するエージェンシー、構造化データを追加したいローカルビジネスにとって最も価値があると評価されている。一方、同レビューは成熟したSEOスタックを導入済みの場合やAI引用の保証を求める場合、複数ある判断材料の1つとして扱うのが現実的だとしている。確立されたリーダーというより、形成途中のカテゴリに登場した有望な初期段階の製品という位置づけだ。
この記事のポイント
- ByTheWeb GEOは無料でAI可読性スコア、llms.txt、スキーマ、従来SEOを管理する
- ByTheWeb AIは任意のクレジット制アシスタントで、不足フィールドを自動生成する
- 新規アカウントには30日間有効の5,000クレジットが付与される
- Yoast SEOやRank Mathと併用でき、GEOスコアとスキーマは有効なまま残る
- AI生成を実行するとページ内容がクラウドを経由するため、プライバシー確認が必要だ
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Rank Mathプラグインが管理者権限を無断取得か。WordPressセキュリティ問題
Rank Mathプラグインに重大なセキュリティ懸念が持ち上がっている。無料アカウントに連携した状態で「ヘルプ＆サポート」セクションを開くと、管理者権限を持つアプリケーションパスワードが無断で生成されるという指摘が、開発者コミュニティからあがった。
指摘したのは、競合するThe SEO Frameworkプラグインの開発者Sybre Waaijer氏だ。Rank Mathは400万以上のサイトで利用される人気プラグインであり、影響範囲は極めて広い。今回はこの問題の仕組みと、サイト運営者が取るべき対処法を整理する。
このデモは、Rank Mathが取っているとされる方式と、WordPress公式が定める方式の違いを図式化したものだ。無承認での生成が問題の核となっている。
Rank Mathプラグインに何が起きているのか
指摘の発端と具体的な動作
2026年8月30日、Search Engine JournalはRank Mathプラグインに関する新たな疑惑を報じた。The SEO Frameworkの開発者Sybre Waaijer氏が、Rank Mathの「ヘルプ＆サポート」セクションを開くだけで管理者権限が外部に渡ると指摘したのだ。
Waaijer氏によれば、Rank Mathは1.0.277へのアップデートでセキュリティ問題を修正した。しかし同じアップデートに、group.one（WP Rocketの所有者でもある企業）がサイトの管理者権限を取得できる機能が含まれていたという。
対象となるファイルは vendor/groupone/wap-client/includes/class-app-password-manager.php だ。無料のrankmath.comアカウントに接続されたサイトで、管理者が「ヘルプ＆サポート」を開くと、プラグインが即座に「WAP – Rank Math Support Agent」という名前のアプリケーションパスワードを生成する。そのパスワードはgroup.oneのサーバーへ送信され、同社のAIエージェントがユーザーに代わってサイトを操作できる状態になる。
許可なき権限委譲という問題
Waaijer氏は「プラグインは最初にユーザーへ確認しない。「利用規約」ボックスは表示されるが、パスワードの生成と送信を止めることはできない。送信はボックスが表示される前に始まっている」と説明している。
つまりユーザーは、何の操作もしないうちに、自分のサイトの管理者権限を第三者へ委譲してしまう。しかも、その事実を知らされることはない。ヘルプ＆サポートを閉じてもパスワードは失効せず、無期限に有効なままだ。
影響範囲と深刻度
Rank Mathは400万以上のサイトで利用されている。管理者権限があれば、プラグインの更新、テーマの変更、投稿の削除、ユーザー情報の閲覧といった、サイト運営の中核的な操作が可能になる。これはSEOプラグインの枠を超えた、サイト全体の安全性に関わる問題だ。
問題の中核にあるアプリケーションパスワードとは
WordPress標準の正当な仕組み
WordPressアプリケーションパスワードは、WordPressコアに含まれる正規の機能である。外部アプリケーションがWordPressサイトへ安全に接続するための仕組みで、ユーザーはいつでも個別に取り消せる。プラグインがこの仕組みを利用すること自体は、公式に認められている。
重要なのは、公式の仕様ではアプリケーションパスワードを発行する前に、必ず承認画面が表示されることだ。ユーザーがプラグインの身元を確認し、接続を許可するか拒否するかを選べる。パスワードがプラグインに渡るのは、ユーザーが承認した後でなければならない。
Rank Mathがガイドラインから外れている点
Rank Mathの動作は、この公式プロセスを完全に飛ばしている。承認画面は表示されず、ユーザーが何かをクリックする前にパスワードが生成され、外部サーバーへ送信される。Waaijer氏が指摘する通り、過去に同氏が「バックドア」と分類したものと構造が似ている。
WordPress.orgのプラグインガイドラインでは、外部サーバーと通信する際にはユーザーの明示的な同意が必要だと定められている。オプトインのチェックボックスや、サービスへの登録を経た同意が求められるのだ。Rank Mathの実装は、この原則に真っ向から反している。
取り消し方法が明示されない
アプリケーションパスワードは本来、ユーザーが確認して取り消せることを前提にしている。しかしRank Mathの場合、「ヘルプ＆サポート」を開いただけでは、パスワードが発行された事実に気づく手がかりがない。プロフィール画面に「WAP – Rank Math Support Agent」という名前で表示されるため、知っていれば探せるが、知らなければ発見は難しい。
ユーザーコミュニティの反応
ソーシャルメディア上の反応は、一貫して否定的だった。一部のユーザーはWordPressコアにSEO機能を統合すべきだと主張し、別のユーザーはRank Mathから別のSEOプラグインへ移行する意思を示した。
フォーラムスレッド削除の疑惑
議論の中で、Rank Mathの公式フォーラムに大きなスレッドが立っていたが、その後削除されたという報告もあった。ユーザーの一人は「数日前にフォーラムで大きなスレッドが立っていたが、今日削除通知が来た。ユーザーフォーラムが大荒れになった後に削除されたようだ」と述べている。
もし事実なら、これはコミュニティの懸念を正面から受け止めていない姿勢と映る。透明性を求める声に対して、静かな対処を選んでいるように見えるからだ。
ユーザーが感じている不信感
「管理者アクセスが無断で？」という短い反応に、多くのユーザーの驚きが凝縮されている。SEOプラグインは検索順位を改善するための道具であって、サイトの制御権を委譲するものではない。誰もがそう考えていたからこそ、今回の発覚は衝撃を持って受け止められた。
Rank Mathの過去の脆弱性と信頼性
脆弱性の履歴
Rank Mathは2024年に7件、2025年に4件、2026年に入って3件の脆弱性が発見されている。直近では、認証されていない状態で保存型クロスサイトスクリプティング（XSS）を実行される脆弱性も報告されていた。
1つのプラグインにこれだけの脆弱性が続くこと自体が、セキュリティ管理の甘さを示す。その上に今回の無断権限取得が加われば、信頼はさらに揺らぐ。
Search Engine Journalの推奨リストから外れている
Search Engine Journalは、自社の推奨WordPressプラグインリストにRank Mathを含めていない。推奨条件の1つが「脆弱性の履歴がないこと」であり、Rank Mathはこの基準を満たせていないためだ。
プラグインの選択では、機能の豊富さだけでなく、セキュリティ面の信頼性を確認することが重要になる。今回の件は、その判断基準を改めて浮き彫りにした。
WordPressサイト運営者が取るべき対処法
まずはパスワードを取り消す
Rank Mathを利用していて、無料アカウントに接続した状態で「ヘルプ＆サポート」を開いたことがあるなら、すぐにアプリケーションパスワードを取り消すべきだ。Waaijer氏が具体的な手順を示している。
- WordPress管理画面の「ユーザー」から「プロフィール」を開く
- 「アプリケーションパスワード」セクションを確認する
- 「WAP -」で始まるパスワードをすべて取り消す
この操作により、Rank Mathのサポートエージェントが保持している管理者権限を無効化できる。手順は数分で済むが、放置すればリスクは残り続ける。
接続解除と設定の見直し
Rank Mathアカウントとの接続を解除することも有効な対策だ。接続していなければ、ヘルプ＆サポートを開いてもパスワードは生成されない。必要になるまで無料アカウントへの接続を切っておくのが無難だ。
また、プラグインの権限設計そのものを見直す機会にしてほしい。管理者以外のユーザーがプラグイン設定を触れるようになっていないか、不要なプラグインが残っていないかを確認する。サイトのセキュリティは、積み重ねた小さな確認で守られる。
他プラグインの移行を検討する
今回の件を受けて、別のSEOプラグインへの移行を検討するユーザーも増えている。The SEO FrameworkやYoast SEOなど、信頼性の高い選択肢は複数ある。重要なのは、移行前に既存の設定やリダイレクト情報をバックアップしておくことだ。
上記のステップを順に実行することで、無断で付与された権限を無効化し、今後のリスクを低減できる。最初のステップが最も緊急性が高い。
この記事のポイント
- Rank Mathはヘルプ＆サポートを開くと管理者権限のアプリケーションパスワードを無断生成すると指摘された
- 承認画面なしでパスワードが外部サーバーへ送信される仕組みはWordPress公式ガイドラインに違反する
- Rank Mathは2024年から2026年にかけて合計14件の脆弱性が報告されている
- 利用者は「ユーザー → プロフィール → アプリケーションパスワード」から「WAP -」をすべて取り消すべき
- アカウント接続の解除と他SEOプラグインへの移行も有効な対策になる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
hCaptcha 5.2.0更新後にログインできない時の対処法とダウングレード手順
hCaptcha プラグインを 5.2.0 に更新した直後からログイン画面に「Bad hCaptcha signature!」と表示され、管理画面へ入れない場合は、5.1.0 へのダウングレードと全キャッシュの削除で解決する。この不具合は 5.2.0 の署名検証リグレッションが原因で、サイトキーやシークレットキーの設定ミスではない。
なぜhCaptcha 5.2.0への更新後にログインエラーが起きるのか
hCaptcha 5.2.0 はログイン時の署名形式を変更している。署名とは、データが改ざんされていないことを証明する値のことだ。この変更が原因で署名検証フローにリグレッション（回帰不具合、以前は正常だった機能が更新によって壊れること）が混入した。
WordPress のログイン統合と別のログイン統合が、同じ wp-login.php エンドポイントを通じて送信される際に署名の検証が失敗する。複数のプラグインがログイン画面に同時に作用する構成で、この問題が顕著に現れる。
「Bad hCaptcha signature!」というエラーは、プラグインがローカルで生成している。hCaptcha API にリクエストを送る前の段階で発生するため、サイトキーとシークレットキーの検証が成功していてもエラーが消えない。この点が原因の切り分けを難しくしている。
「ログイン試行前のhCaptcha」の設定値を 0 にしている場合、この不具合はすべてのログイン試行で発生する。0 に設定すると署名検証を回避する余地がなくなり、毎回エラーに遭遇する。
ログイン不能な状態から管理画面へ入る手順
管理画面に入れない状態でも、FTP や SSH でサーバーへ接続すれば hCaptcha プラグインを一時停止できる。プラグインを停止するとログイン経路が確保されるため、その後は通常どおり管理画面へアクセスできる。
この手順で管理画面へ入り、ダウングレードの準備を整える。
FTPまたはSSHでプラグインを停止する
FTP クライアントでサーバーへ接続し、wp-content/plugins ディレクトリへ移動する。hcaptcha というフォルダを見つけたら、フォルダ名を「hcaptcha-disabled」のように変更する。WordPress はプラグインを読み込まなくなるため、ログイン画面からキャプチャが消えて通常のログインフォームが表示される。
SSH を使える環境なら、wp-content/plugins ディレクトリで mv コマンドを実行する方法が速い。コマンドラインでの操作に慣れている場合は、この選択肢が確実だ。
管理画面に入ったらhCaptcha設定を確認する
プラグインを停止してログインできたら、WordPress 管理画面の「プラグイン」を開く。hCaptcha が停止状態になっていることを確認し、これから行うダウングレードに備えて現在の設定メモを残しておくとスムーズだ。
hCaptcha 5.2.0を5.1.0へダウングレードする手順
管理画面へ入れるようになったら、hCaptcha 5.2.0 を削除して 5.1.0 をインストールする。設定データは削除しても保持されるため、サイトキーとシークレットキーを再入力する必要はない。
5.1.0 へ戻すと署名検証の不具合が解消され、ログインできるようになる。
5.2.0を削除して5.1.0をインストールする
WordPress 管理画面の「プラグイン」から hCaptcha 5.2.0 を削除する。削除しても設定はデータベースのオプションテーブル（デフォルトでは wp_options）に残るため、サイトキーやシークレットキーが消えることはない。
次に 5.1.0 の ZIP ファイルを公式リポジトリなどから入手する。「プラグイン」メニューの「新規追加」を開き、「プラグインのアップロード」から ZIP ファイルを選択してインストールする。インストール完了後に有効化する。
サイトキーとシークレットキーを再確認する
インストール後、hCaptcha の設定画面を開き、サイトキーとシークレットキーに値が入っていることを目視で確認する。5.2.0 から戻しても設定は残っているはずだが、念のため両方のフィールドをチェックしておく。
キーの検証ボタンを押して成功すれば、API との通信自体は正常ということだ。ただしこの不具合は通信前にローカルで発生するため、検証成功の表示が出ても油断はできない。あくまでキーの有効性を確認するだけの操作だと理解しておく。
モードをLiveに設定して保存する
設定画面でモードが Live になっていることを確認し、変更があれば保存する。サイズが invisible になっているかも確認する。設定を保存したら、次のキャッシュ削除の手順へ進む。
キャッシュを削除してエラーを完全に解消する
バージョンを 5.1.0 に戻しただけではエラーが残ることがある。5.2.0 が署名形式を変更した影響で、以前のバージョンが生成したログイン HTML が各種キャッシュに残っていると、同じエラーが引き続き表示される。
ページキャッシュとサーバーキャッシュを削除する
使用しているキャッシュプラグイン（WP Super Cache や W3 Total Cache など）の管理画面を開き、ページキャッシュとオブジェクトキャッシュを削除する。サーバー側のキャッシュ機能（Varnish や LiteSpeed Cache など）が有効な場合も、同じく削除操作を行う。
CDNのキャッシュを削除する
Cloudflare やその他の CDN を利用している場合、CDN の管理画面からキャッシュをパージする。ログインページの HTML がエッジサーバーに残っていると、WordPress 側の設定が正しくても古い署名形式のページが配信され続ける。
プライベートウィンドウで動作確認する
キャッシュ削除後、通常のブラウザタブではなくプライベートウィンドウ（シークレットウィンドウ）でログインページを開く。ブラウザのローカルキャッシュや Cookie も残っていると、修正後のページを正しく読み込めないことがある。
プライベートウィンドウでログインを試み、キャプチャを通過して管理画面に入れればダウングレードは成功だ。通常のブラウザタブでまだエラーが出る場合は、ブラウザのキャッシュと Cookie を個別に削除して再試行する。
自動更新を止めて再発を防ぐ
修正版がリリースされるまで、自動更新で 5.2.0 に戻らないようにしておく。プラグインの自動更新は個別に無効化できるため、hCaptcha だけ更新を止めておくのが安全だ。
hCaptchaの自動更新を無効化する
WordPress 管理画面の「プラグイン」一覧で hCaptcha の行を確認し、自動更新を無効にする。プラグインごとの自動更新設定はプラグイン一覧画面から切り替えられる。WordPress 本体の自動更新とは別の設定なので、本体は更新を継続したまま hCaptcha だけを固定できる。
修正版のリリースを確認する方法
プラグインの公式ページやリポジトリを定期的に確認し、5.2.1 以降の修正版がリリースされたかをチェックする。修正版が出るまでは 5.1.0 のまま運用し、更新前には必ずテスト環境でログイン動作を確認する。
本番環境へ修正版を適用する際も、まずステージング環境でログイン、キャプチャ表示、ユーザー登録、パスワードリセットの一連の動作を検証してからリリースするのが安全だ。
よくある質問
プラグインを削除するとhCaptchaの設定は消えますか
いいえ、消えない。プラグインを削除しても設定はデータベースに保持される。アンインストール時にデータを削除するクリーンアップ設定を事前に有効化していた場合のみ、削除される仕組みだ。ダウングレードでサイトキーを再入力する必要はない。
ダウングレード後に「インストールが不正です」と表示されます
5.2.0 から 5.1.0 へ手動で戻す際、WordPress が古いバージョンのインストールを「不正」と判定することがある。この場合は一度 5.2.0 を完全に削除してから 5.1.0 を新規インストールする。設定が残っているため、再設定の手間はかからない。
サイトキーとシークレットキーの検証は成功するのにエラーが続きます
「Bad hCaptcha signature!」は、プラグインが API へリクエストを送る前のローカル段階で生成される。キーの検証は API との通信が正常であることを示すだけで、署名検証の不具合とは無関係だ。そのためキーが正しくてもエラーは消えない。
ログイン時にキャプチャテストが表示されるのは正常ですか
「サイズ」を「invisible」に設定しているにもかかわらず画像選択テストが表示される場合、設定が正しく反映されていない可能性がある。ダウングレード後にキャッシュを削除し、プライベートウィンドウで再度確認するとよい。それでも表示される場合は、ログイン試行前の設定値や他のログイン系プラグインとの競合を調べる。
自動更新で勝手に5.2.0に上がるのを防げますか
防げる。WordPress 管理画面の「プラグイン」一覧から hCaptcha の自動更新を個別に無効化できる。また、複数のプラグインを一元管理している場合は、更新ポリシーで hCaptcha を除外する設定を行う。
この記事のポイント
- 5.2.0 の署名検証リグレッションがログインエラーの原因
- エラーはAPI通信前のローカル処理で発生する
- 5.1.0 へのダウングレードが確実な対処法
- プラグイン削除後も設定データは保持される
- 全キャッシュ削除とプライベートウィンドウでの確認が必須
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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に勝手にインストールされる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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている