WordPressプラグインで「No valid ImageMagick mode found!」が出た時の直し方
WordPressのプラグイン設定画面で「No valid ImageMagick mode found!」と表示される場合、原因はサーバーのPHPに「Imagick」拡張モジュールが入っていないか、正しく読み込めていないことにある。まずはサイトヘルスでImageMagickが認識されているか確認し、必要ならImagickを導入するかGDライブラリへ切り替えるのが解決への近道だ。
なぜ「No valid ImageMagick mode found!」が表示されるのか
WordPressは画像のリサイズや圧縮などの処理に「GD」か「ImageMagick」という2種類の画像処理エンジンを使う。ImageMagick（イメージマジック）は高画質の画像変換ができるライブラリで、PHPから利用するには「Imagick」というPHP拡張モジュールが必要になる。
「No valid ImageMagick mode found!」は、プラグインがImageMagickの利用可否をチェックした際に、有効なモード（利用できる画像フォーマットや処理経路）をひとつも検出できなかったことを示す。つまりサーバー側にImagick拡張がない、あってもPHPのバージョンと互換性がない、あるいは拡張を読み込む設定が不足しているケースが多い。
特にPHP 8系ではImagickの対応バージョンがシビアで、古いImagick 3.6以前のビルドが残っているとWordPressやプラグインから正しく認識されない。画像のアップロードやWebP変換を多用するサイトほど、このエラーが出たまま放置するとサムネイル生成や画像最適化が止まる可能性がある。
このデモはエラーの発生原因と解決後の状態を概念化したイメージ。Imagick拡張が読み込まれるとプラグインのチェックも通る。
ImageMagickがサーバーで有効か確認する手順
エラーの原因を切り分けるには、まずWordPressがサーバー上でImageMagickを認識できているかどうかを確認する。管理画面の「ツール」→「サイトヘルス」→「情報」タブを開くと確認できる。
サイトヘルスの「画像処理」欄に「ImageMagick」が表示されず「GD」だけが並んでいるなら、サーバーにImagick拡張が入っていない可能性が高い。表示はあってもエラーが出る場合は、Imagickのバージョンが古くPHPと互換していないことが考えられる。
Imagick拡張を導入してエラーを解消する
共用レンタルサーバーを使っている場合は、管理パネルからPHPの使用モジュールとしてImagickが選択できるか確認する。選択肢にない場合はサーバー会社に問い合わせて導入が可能か確認する必要がある。VPSや専用サーバーなら、次のコマンドで導入できる。
# Debian / Ubuntu 系
sudo apt update
sudo apt install php-imagick
# PHP のバージョンが複数ある場合
sudo apt install php8.3-imagick
# 導入後にPHPを再起動
sudo systemctl restart php8.3-fpmPHP 8系を使う場合はImagick 3.7.0以降が必要になる。古いパッケージが入っている場合は、一度削除してから最新版を入れ直す。導入後に「php -m」コマンドで「imagick」が一覧に出ることと、WordPressのサイトヘルスで「ImageMagick」が表示されることを確認する。
Imagickを入れたら、プラグインの設定画面を開き直してエラーが消えたか確認する。キャッシュ系プラグインを使っている場合はキャッシュを削除してから確認するのが確実だ。
GDライブラリに切り替えてエラーを回避する
サーバーにImagickを導入できない場合や、すぐにエラーを止めたい場合は、WordPressの画像処理をGDライブラリに固定する方法がある。子テーマのfunctions.phpか、次のコードをmu-pluginsフォルダーに設置すると有効になる。
<?php
// 画像エディタをGDライブラリに固定する
function switch_to_gd_editor($editors) {
if (class_exists('WP_Image_Editor_GD')) {
return array('WP_Image_Editor_GD');
}
return $editors;
}
add_filter('wp_image_editors', 'switch_to_gd_editor');GDライブラリ切り替えで品質に影響はないか
GDはImageMagickに比べて対応フォーマットが限られ、JPEGの生成品質や色空間の扱いで差が出る場合がある。ただし通常のサムネイル生成やリサイズ程度なら実用上の問題は少ない。WebP変換やCMYKのJPEG出力、EXIFの向き補正などを多用するサイトでは、ImageMagickの方が有利だ。
GDに切り替えたあとも「No valid ImageMagick mode found!」が消えない場合は、そのプラグインがGDフォールバックを持たず、ImageMagickを必須要件にしている可能性が高い。この場合はプラグイン自体の置き換えを検討する。
このデモはGDとImageMagickの性質の違いを示す概念図。用途に応じて切り替え先を選ぶ。
プラグインの設定でできる回避策
エラーを出しているプラグインに画像処理エンジンの選択肢がある場合は、設定でGDに切り替えられることがある。プラグインの設定画面に「ImageMagickを使用する」のようなチェックボックスがあるなら、それを外してGD側を選ぶ。
設定項目がなく、Imagickの導入もできない環境なら、同種の機能を持つ別のプラグインへ移行する選択肢も現実的だ。画像最適化やWebP変換系のプラグインは、GDフォールバックを持つものも多い。移行時は既存の画像が再処理される仕様かどうかを確認しておく。
また、Imagick拡張を導入したのにエラーが消えない場合は、PHP-FPMやApacheの再起動が済んでいるか、キャッシュ系プラグインやCDNのキャッシュが残っていないかを順に確認する。
よくある質問
「No valid ImageMagick mode found!」はサイトを止める致命的なエラーですか
このエラー単体でサイトが完全に停止することは少ないが、画像のサムネイル生成や最適化処理が止まるため、メディアライブラリからのアップロードや商品画像の表示に影響が出る可能性がある。早めの対処が望ましい。
GDライブラリだけで運用しても問題はないですか
通常のリサイズや圧縮だけであればGDでも十分に動く。ただしCMYKのJPEGやWebP変換、EXIFの向き補正などが必要なサイトでは、ImageMagickを入れた方が品質と互換性で有利だ。
共用レンタルサーバーでもImagickを導入できますか
サーバー会社によって異なる。管理パネルのPHP設定にImagickの選択肢があればすぐに有効化できる。選択肢がない場合は問い合わせて導入可否を確認する必要がある。
Imagickを入れたのにエラーが消えない場合はどうすればいいですか
PHPの再起動、Imagickのバージョン確認、プラグインのキャッシュ削除の順に確認する。PHP 8系ではImagick 3.7.0未満だと認識されないことがある。
プラグインを無効化すればエラーは消えますか
エラーを出しているプラグインを無効化すれば表示は消えるが、そのプラグインの機能も失われる。画像最適化など必要な機能なら、代替プラグインへ移行するのが現実的だ。
この記事のポイント
- エラーはPHPのImagick拡張が読み込めていないのが主因
- サイトヘルスの「情報」タブでImageMagickの認識を確認
- 共用サーバーは設定確認、VPSはphp-imagickを導入
- Imagickを入れられない場合はGDに切り替えて回避
- PHP 8系はImagick 3.7.0以降との組み合わせが必要
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
EDDのログインフォームにロックアウト時のカスタムエラーメッセージを表示する方法
Easy Digital Downloads（以下、EDD）のログインフォームでセキュリティプラグインのロックアウト時にカスタムエラーメッセージが表示されない原因は、EDDがwp-login.phpの login_errors フィルターを通らない独自のエラー処理を持つことにある。authenticate フィルターに優先度30のフックを追加し、ロックアウトエラーをEDDのエラー表示システムへ渡せば解決する。
なぜEDDのログインフォームではカスタムエラーメッセージが表示されないのか
WordPress標準のログインページ（wp-login.php）は、ログイン時に発生したエラーを login_errors フィルターを通して画面へ表示する。セキュリティプラグインの多くはこのフィルターにフックし、ロックアウト時に「ログイン試行回数の上限に達しました」などのカスタムメッセージへ置き換えている。
一方、EDDのチェックアウト画面や [edd_login] ショートコードが生成するログインフォームは、認証処理を自前で実行する。内部では wp_signon() を呼び出すものの、返ってきたWP_Errorをそのまま表示せず、エラーコードごとに独自のメッセージへ変換してしまう。ロックアウト系のエラーコードはこの変換テーブルに存在しないため、標準メッセージ「ユーザー名またはパスワードが間違っています」に置き換えられてしまう。
つまり、セキュリティプラグインは正常にロックアウトを検知してカスタムメッセージ付きのWP_Errorを返しているにもかかわらず、EDDのエラー処理がそれを捨てて汎用メッセージに差し替えているのが根本原因だ。
このデモは、ロックアウト時の表示が標準メッセージからカスタムメッセージへ変わる流れを示したイメージだ。
authenticateフィルターでEDDにエラーを渡す手順
解決のアプローチは、EDDがエラーを独自メッセージへ変換する前に、ロックアウトのWP_Errorを検知してEDDのエラーシステムへ正しいメッセージを登録することだ。WordPressの authenticate フィルターは認証処理の中で必ず実行されるため、プラグイン本体を変更せずにフックを追加できる。
このデモは、認証時のエラーがEDDのログインフォームまで正しく届く流れを示している。
authenticateフィルターに追加する実装コード
以下のコードを子テーマのfunctions.phpまたはカスタムプラグインへ追加する。authenticate フィルターの優先度は30に設定し、セキュリティプラグインが通常使う優先度20より後に実行されるようにする。これにより、ロックアウトのWP_Errorが返った段階で確実に捕捉できる。
/**
* EDD のログインフォームでロックアウト時のカスタムエラーメッセージを表示する
*/
function custom_edd_show_lockout_error( $user, $username, $password ) {
if ( is_wp_error( $user ) ) {
$error_code = $user->get_error_code();
// ロックアウト系のエラーコードを判定するパターン
$lockout_patterns = array(
'lockout',
'too_many',
'attempts',
'blocked',
'limit',
'tries',
);
$is_lockout = false;
foreach ( $lockout_patterns as $pattern ) {
if ( strpos( strtolower( $error_code ), $pattern ) !== false ) {
$is_lockout = true;
break;
}
}
// ロックアウトエラーなら EDD のエラーシステムへ登録する
if ( $is_lockout && function_exists( 'edd_set_error' ) ) {
edd_set_error( 'login_lockout', $user->get_error_message() );
}
}
return $user;
}
add_filter( 'authenticate', 'custom_edd_show_lockout_error', 30, 3 );コード内の $lockout_patterns 配列は、セキュリティプラグインが返すエラーコードに合わせて調整する。エラーコードはプラグインごとに異なるため、実際の環境で確認しながらパターンを追加するとよい。
エラーコードを確認してパターンを調整する方法
セキュリティプラグインが返すエラーコードは、デバッグログやテストコードで確認できる。たとえば、一時的に以下のコードを追加してロックアウトを再現し、error_log() に出力すれば正確なエラーコードを把握できる。
// 一時的なデバッグ用コード（確認後に削除する）
function debug_edd_login_error( $user, $username, $password ) {
if ( is_wp_error( $user ) ) {
error_log( 'EDD login error code: ' . $user->get_error_code() );
error_log( 'EDD login error message: ' . $user->get_error_message() );
}
return $user;
}
add_filter( 'authenticate', 'debug_edd_login_error', 25, 3 );ロックアウトを発生させた後、サーバーのエラーログ（debug.log）を確認すると、セキュリティプラグインが返したエラーコードが記録されている。このコードを前セクションの $lockout_patterns に追加すれば、確実に判定できる。
functions.phpへコードを追加する前の確認事項
コードを本番サイトへ追加する前に、いくつか確認しておくべき点がある。まず、子テーマを使用しているか確認する。親テーマのfunctions.phpを直接編集すると、テーマのアップデートでコードが消えるため、必ず子テーマのfunctions.phpまたはカスタムプラグインへ追加する。
次に、ロックアウトを再現できるテスト環境を用意する。自分の管理画面からのログイン試行でテストすると、自分自身がロックアウトされて管理画面へアクセスできなくなる可能性がある。ブラウザのプライベートウィンドウや別の端末からテストするのが安全だ。
さらに、edd_set_error() 関数はEDDが有効化されている場合にのみ存在する。コード内で function_exists() による存在確認を入れているため、EDDが無効化されてもエラーは発生しないが、EDD以外のログインフォームではこの方法は機能しない点に注意する。
よくある質問
このコードはWooCommerceのログインフォームでも使えますか？
基本的な考え方は同じだが、edd_set_error() はEDD専用の関数だ。WooCommerceの場合は wc_add_notice() を使うか、WooCommerceのログインフォーム用フィルターを利用する必要がある。フックするポイントは authenticate フィルターで共通だが、エラーを登録する関数を各プラグインのものへ置き換える。
セキュリティプラグインの種類によってエラーコードは異なりますか？
異なる。プラグインごとに独自のエラーコードを割り当てているため、「too_many_retries」「lockout」「attempts_exceeded」など名称はさまざまだ。デバッグコードで実際のエラーコードを確認し、パターン配列を調整するのが確実だ。
EDDのバージョンアップでコードが動作しなくなることはありますか？
可能性はある。EDDの内部実装やエラー処理の方法が変更された場合、edd_set_error() の動作も変わる可能性がある。メジャーアップデート後はロックアウト時の表示を必ずテストし、問題があればエラーコードの確認からやり直すとよい。
コードを追加して問題が起きた場合の復旧方法は？
FTPまたはサーバーのファイルマネージャでfunctions.phpを開き、追加したコードを削除すれば元に戻る。FTPが使えない場合は、サーバー会社の管理画面からファイル編集機能を利用するか、バックアップから復元する。コード追加前に必ずバックアップを取っておくこと。
この方法でwp-login.php側のカスタムメッセージも変更されますか？
変更されない。authenticate フィルターで edd_set_error() を呼び出しても、wp-login.phpの表示には影響しない。wp-login.phpは引き続き login_errors フィルターを通してメッセージを表示するため、両方のログインフォームでカスタムメッセージを表示したい場合は、セキュリティプラグイン本来の設定とこの追加コードが共存する。
この記事のポイント
- EDDのログインフォームはwp-login.phpの
login_errorsフィルターを通らない authenticateフィルターに優先度30のフックを追加してロックアウトエラーを捕捉するedd_set_error()へカスタムメッセージを登録すればEDDのログインフォームに表示される- エラーコードのパターンはセキュリティプラグインごとに調整が必要
- 子テーマのfunctions.phpへ追加し、テスト環境で動作確認してから本番へ適用する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
B2BKingのMCP連携でWooCommerce B2BストアをAIが設定。仕組みと接続手順
WooCommerce向けB2B・卸売販売プラグインのB2BKingが、MCP連携機能を実装した。AIアシスタントが自然言語の指示だけで、ストア設定の読み取りから変更までを実行できる。従来は数時間かかっていた設定作業が、数分で完了する可能性がある。
対応するのはClaude、Codex（OpenAIのコーディングエージェント）、Cursor、VS Codeなど、MCP（Model Context Protocol）をサポートするすべてのAIツールだ。コードを書く必要も、設定画面を1つずつ巡回する必要もない。
B2BKingのMCP連携とは何か
B2BKingはWooCommerce向けのB2B・卸売販売プラグインだ。約7年の開発実績を持ち、累計1万5,000以上のWooCommerceストアで稼働している。このB2BKingが、WordPressの標準API群を通じてAIアシスタントから直接設定を変更できる仕組みを実装した。
具体的には、B2BKingがWordPress Abilities APIに主要なストア設定を「能力」として登録する。その能力を公式のWordPress MCP AdapterがMCP経由で外部に公開し、MCPをサポートするAIアシスタントが利用できるようになる。特定のAI製品向けの独自コネクタを作るのではなく、オープンな標準の上に構築されている点が特徴だ。
一度接続すると、英語で普通の文章を入力するだけでストア設定を操作できる。B2B限定ストアとハイブリッドB2B/B2Cの切り替え、ゲストの閲覧制御、顧客グループの作成、卸売価格や最低注文金額の設定、顧客のグループ割り当てなどが対象となる。
指示はAIアシスタントからMCP Adapterへ送られ、B2BKingが登録した能力を通じてWooCommerceに反映される。すべて標準化されたプロトコル上で動作するため、特定のAI製品に依存しない。
AIが設定できる5つの領域
現時点でAIが操作できる範囲は、B2Bストアの構築に必要な主要な決定事項をカバーしている。大きく5つの領域に分類できる。
ストア全体の設定と登録機能
1つ目はストア構成だ。AIがB2BKingの設定全体を読み取り、B2B限定モードとハイブリッドB2B/B2Cモードを切り替えられる。ゲストが見る内容も制御でき、価格の非表示、ショップ全体の非表示、ログイン限定ストア、価格の代わりに見積依頼を表示する設定などに対応する。
2つ目は登録と機能の制御だ。B2B登録フォームの有効化、ロールのドロップダウン表示、アカウント承認フローをオン・オフできる。見積依頼、会話機能、オファー、購入リスト、一括注文フォーム、会社サブアカウントなどの機能も同様に操作できる。
顧客グループと価格ルールの操作
3つ目は顧客グループの管理だ。既存のグループを一覧表示するだけでなく、リセラーやディストリビューターなどの新しいグループを作成できる。グループには与信枠を設定することも可能だ。
4つ目は価格ルールだ。パーセント割引、固定金額割引、固定価格、送料無料、最低注文金額などのルールを、全B2B顧客または特定のグループに対して設定できる。適用範囲もカタログ全体、単一商品、カテゴリ単位で指定できる。
5つ目は顧客の個別管理だ。特定の顧客のB2Bステータス、所属グループ、承認状態を確認し、B2Bグループへの移動やB2Cへの戻しを実行できる。グループを作成した後のルール適用や顧客の移動も、同じ会話の中で続けて指示できる。
手動で設定画面を巡回する作業が、AIアシスタントへの1つの指示文で置き換わる。所要時間は数時間から数分へ短縮される。
WordPress Abilities APIとMCPの技術的仕組み
Abilities APIの役割
WordPress Abilities APIはWordPress 6.9からコアに導入された標準機能だ。プラグインが「自分に何ができるか」をAIに宣言するための共通の方法を提供する。各能力（アビリティ）には、説明文、期待する入力データのスキーマ、権限チェックの3つが含まれる。
これによりAIは、ある操作が何をするのかを事前に理解できる。さらに、ログイン中のユーザーがその操作を実行できるかどうかも、何かが起こる前に検証される。B2BKingは主要なストア設定をこのAbilities APIに登録している。
MCP Adapterの役割
MCP（Model Context Protocol）は、AIアシスタントが外部ツールと会話するためのオープンプロトコルだ。Claude、Codex、Cursor、VS Codeが同じB2BKingの設定を操作できるのは、このMCPが共通の通信基盤になっているからだ。
公式のWordPress MCP Adapterは、Abilities APIに登録された能力をMCP経由で外部に公開する橋渡し役を担う。ライブサイトとローカル開発環境の両方で動作し、WordPressのAIエコシステム全体が成熟するほどB2BKingも自動的に恩恵を受ける構造だ。
注目すべきは、この設計が特定のAI製品へのロックインを避けている点だ。独自のコネクタを開発するのではなく、オープンな標準に乗っているため、MCPをサポートする新しいAIツールが登場すれば、追加の開発なしで利用可能になる。
AIによるストア設定の安全性
AIがストア設定を変更できると聞くと、多くのストア運営者は「制御を失うのでは」と不安に感じる。B2BKingはこの懸念に対して、複数の安全機構を実装している。
実行前のチェック機構
第1に、すべての能力が実行前に接続ユーザーのWordPress権限（ケイパビリティ）をチェックする。権限のないユーザーが接続しても、変更操作は実行できない。
第2に、入力値の検証が行われる。存在しないグループやカテゴリを指定したルール、100%を超える割引率などをAIが指示しても、検証によって拒否される。B2BKingが各ステップを実行時に確認する仕組みだ。
第3に、各能力は読み取り専用か変更を伴うものかがラベル付けされている。AIクライアントは変更実行前にユーザーへ確認を求める設定にできる。第4に、ライセンスキーはAIアシスタントに渡らない設計になっている。
4つの安全機構により、AIがストア設定を誤って変更するリスクを抑えている。特にライセンスキーがAIに渡らない設計は、セキュリティ面で重要なポイントだ。
開発者向けフィルター
開発者向けには2つのフィルターが用意されている。b2bking_mcp_enabledでMCP連携を完全に無効化できる。またb2bking_mcp_write_enabledで読み取り専用に制限することも可能だ。本番ストアでは読み取り専用にしておき、ステージング環境でのみ書き込みを許可するといった運用が現実的だろう。
ClaudeやCodexとB2BKingの接続手順
MCPをサポートするAIアシスタントならどれでも動作するが、ClaudeとCodexが最も始めやすい。接続設定自体もAIに任せられるためだ。コードを書く必要はない。AIはB2BKingに組み込まれた能力を通じてのみ動作する。
AIに接続設定を任せる方法
最も簡単な方法は、ClaudeやCodexに「公式WordPress MCP Adapterを使用してMCP経由でストアに接続したい」と伝えることだ。AIが必要なインストールと設定を判断して進めてくれる。
通常、AIが求めるのはアプリケーションパスワードのみだ。WordPress管理画面の「ユーザー」→「プロフィール」→「アプリケーションパスワード」から作成できる。これだけで接続は完了する。
手動で接続する手順
自分で設定する場合は、以下の手順を踏む。まずWordPress 6.9以降と最新版のB2BKingが必要だ。次にMCP Adapterプラグインをインストールし、アプリケーションパスワードを作成する。最後にAIクライアントのMCP設定に短い設定項目を追加する。
B2BKing側で何かを有効化する必要はない。能力は自動的に登録されるためだ。設定スニペットの全文はB2BKing公式サイトの「AIによるWooCommerce B2Bストア構築ガイド」に掲載されている。
接続後は、以下のような指示文を送るだけで設定作業が始まる。
ストアをハイブリッドB2B/B2Cモードに設定して。ゲストには価格の代わりに見積依頼を表示。Wholesaleグループを与信枠5,000ドルで作成し、全体に15%割引と最低注文300ドルを適用。AIはまず現在のB2BKing設定を読み取り、状況を把握する。その後、ハイブリッドモードへの切り替え、ゲスト見積依頼の設定、Wholesaleグループの作成、15%割引ルールと300ドル最低注文ルールの追加を順番に実行する。各ステップでB2BKingが検証を行い、すべて完了するとAIが変更内容を報告する。
この記事のポイント
- B2BKingがMCP連携に対応し、ClaudeやCodexから自然言語で操作できる
- Abilities APIとMCP AdapterというWordPress標準の仕組みで構築されている
- ストア構成、登録機能、顧客グループ、価格ルール、顧客管理の5領域を設定できる
- 権限チェック、入力検証、読み取り/書き込み区別、ライセンスキー遮断の4重の安全機構を備える
- 7年の実績と1万5,000以上のストアで使われてきた信頼性の上にAI連携が乗っている
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WP Umbrellaが管理画面で403になる原因と解決法
WP Umbrellaが管理画面へ送る内部リクエストが一部のレンタルサーバーで403エラーになるのは、Refererヘッダーが欠けているためだ。mu-pluginでヘッダーを付与すると一時的に解決でき、修正版への更新で恒久的に直る。
WP Umbrellaの403エラーはリクエストヘッダー不足が原因
WP Umbrellaは監視・管理のため、WordPressのadmin-ajax.phpへ内部リクエストを送っている。このバックグラウンド通信にはUser-Agentとして「WPUmbrella」が使われ、CookieもRefererも含まれない。多くのホスティングはこのリクエストを許可するが、セキュリティ規則が厳しい環境では「403 Forbidden（アクセス拒否）」を返す。
ホスト側のWAFやmod_securityは、CookieやRefererのないPOSTリクエストを不正アクセスと判断することがある。特に/wp-admin/配下への直接POSTは警戒されやすい。結果としてWP Umbrellaのダッシュボードにプラグインの更新情報が一部表示されない、サイトの監視データが欠けるといった影響が出る。
ヘッダーにRefererなし、Cookieなし。WAFがブロックする。
Refererヘッダーを追加するとサーバーが受け付ける。
上のデモは、WP Umbrellaの内部リクエストがRefererの有無でどう変わるかを示している。403はサイトの表示を壊さないが、管理画面側で更新データの取得漏れが起きる。
mu-pluginでRefererヘッダーを追加する手順
プラグインの修正版が配布されるまでの間は、mu-plugin（マスタードロップイン）でWP UmbrellaのリクエストにRefererヘッダーを自動付与するのが確実だ。mu-pluginは/wp-content/mu-plugins/に置くPHPファイルで、管理画面から無効化できない代わりに毎回確実に読み込まれる。
ファイル名は任意でよいが、add-referer-for-wp-umbrella.phpのように役割が分かる名前が管理しやすい。
<?php
/**
* WP Umbrella の内部リクエストに Referer ヘッダーを付与する
*/
add_filter( 'http_request_args', function ( $args, $url ) {
if ( 'WPUmbrella' === ( $args['user-agent'] ?? '' )
&& 0 === strpos( $url, admin_url() )
&& empty( $args['headers']['Referer'] ) ) {
$args['headers'] = (array) ( $args['headers'] ?? array() );
$args['headers']['Referer'] = admin_url();
}
return $args;
}, 10, 2 );このコードが何をしているのか
http_request_argsフィルタは、WordPressがHTTPリクエストを送る直前に引数を書き換えられるフックだ。ここではUser-Agentが「WPUmbrella」であること、リクエスト先が管理画面のURLであること、Refererが未設定であることの3条件が揃った場合だけ、管理画面URLをRefererとして追加している。
条件を限定しているため、WP Umbrella以外の通信には影響しない。WP Umbrella側のリクエスト検証にも変更はない。修正版に更新した後はこのmu-pluginを削除して問題ない。
プラグインのアップデートで恒久的に解決する
この問題はWP Umbrellaの開発チームが把握しており、次期リリースで内部リクエストのUser-AgentとRefererが修正されることが発表されている。具体的には、User-Agentが「WordPress/」で始まる文字列になり、Refererに管理画面URLが付与される。
WordPress管理画面の「プラグイン」→「インストール済みプラグイン」でWP Umbrellaの更新通知が表示されたら、通常どおり更新する。更新後は403になる頻度がなくなり、mu-pluginの応急処置は不要になる。更新が配布されていない間は、mu-pluginを置いたまま運用してかまわない。
同じ403が別のプラグインでも出た場合の切り分け
Refererヘッダー不足による403は、WP Umbrella以外の監視・バックアップ・API連携系プラグインでも起こり得る。原因を切り分けるには、まず該当プラグインが管理画面のadmin-ajax.phpへPOSTを送っているかをエラーログやプラグインの仕様で確認する。
特定のプラグインだけが403になる場合は、ホスティングのWAF設定を緩める前に、mu-pluginで当該プラグインのリクエストだけにRefererを追加できないか検討する。WAF全体を無効化するとサイトの防御力が下がるため、最終手段として扱う。
原因がプラグインの実装にある場合は、開発元にフォーラムやサポートから報告すると、今回のようにプラグイン本体で修正される可能性が高い。
よくある質問
403エラーが出てもサイト表示には影響あるか
このケースではサイトの表示や一般ユーザーの操作には影響しない。WP Umbrellaのバックグラウンド通信だけが拒否されるため、ダッシュボード上の更新情報取得や監視データの一部が欠ける形になる。
mu-pluginフォルダが見つからない場合はどうするか
/wp-content/の直下にmu-pluginsフォルダがない場合は、自分で新規作成すればよい。フォルダ名は必ずmu-pluginsにする。その中にPHPファイルを直接置くとWordPressが自動で読み込む。
このmu-pluginはWP Umbrella以外に影響を与えるか
影響しない。コード内でUser-Agentとリクエスト先を限定しているため、WP Umbrellaの管理画面への内部通信だけにRefererを追加する。他のプラグインのHTTP通信には触れない。
プラグイン更新後にmu-pluginは削除すべきか
修正版WP Umbrellaに更新したらmu-pluginは不要になるので、削除してよい。残していても通常は害がないが、意図しない通信パラメータの重複を避けるため削除するのが綺麗だ。
403の原因がWP Umbrella以外だった場合の確認ポイントは何か
全プラグインを無効化して1つずつ再有効化し、どのプラグインで403が再発するかを確認する。テーマを標準テーマに切り替える方法も有効だ。サーバーのWAFログやPHPエラーログも手がかりになる。
この記事のポイント
- WP Umbrellaの内部リクエストがReferer不足で403になる
- mu-pluginでRefererを付与すると応急処置できる
- 開発元が修正した次期リリースで恒久解決する
- サイト表示への影響はなく、管理データの取得漏れが起きる
- 同様の403は他プラグインでもWAF設定の見直しで対処する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
FoundByAIのllms.txtが404になる原因とDiviショートコード混入の修正手順
FoundByAIが生成する /llms.txtが404を返す場合、Rank Math SEOやYoast SEOなどのSEOプラグインがエンドポイントを確保していることが主な原因だ。プラグインをバージョン1.3.6以降に更新すると、404とDiviショートコード混入の両方を解決できる。
llms.txtが404を返す原因は何か
/llms.txtにアクセスすると404になるのに、パーマリンクを再保存してもキャッシュを削除しても直らない。この症状は多くの場合、SEOプラグインが /llms.txtというURLを「自分の管轄」として押さえていることが原因だ。
Rank Math SEO、Yoast SEO、All in One SEOなどは、llms.txtを自ら配信する機能を持っている。FoundByAIは1.3.5以前、これらのSEOプラグインが有効化されていると「SEOプラグインが配信するだろう」と判断し、/llms.txtの配信役を自ら降りていた。
ところがSEOプラグイン側のllms.txt機能がオフになっていると、どのプラグインもURLに応答しない。結果としてHTTP 404が返る。これが「プラグイン上は生成済みと表示されるのに、実際のURLでは404になる」理由だ。
エンドポイントの担当がSEOプラグインとFoundByAIの間で競合していた状態だ。
Rank Mathのllms.txt機能がオフの環境で起きやすい
特にRank Math SEOは、llms.txt配信機能がデフォルトでオフの状態が多く、AI関連機能を無効化している場合はなおさらだ。しかしFoundByAI 1.3.5以前は「Rank Mathが有効化されている」という事実だけで配信を譲っていたため、404が発生しやすかった。
パーマリンク再保存やキャッシュ削除で直らない理由
この404は .htaccessの書き換え設定ではなく、プラグイン同士の「エンドポイントの取り合い」が原因だ。パーマリンク設定を変更しても、ファイル転送の設定や配信ルールが変わらないため、状況は改善しない。キャッシュが原因でもないため、キャッシュを削除しても同じ結果になる。
FoundByAI 1.3.6への更新で直す手順
バージョン1.3.6では、他のプラグインが /llms.txtを配信しない場合、FoundByAIが自ら配信するように動作が変わった。更新するだけで404は解消する。
更新から配信確認までの一連の流れだ。
更新前に使っているSEOプラグインを確認する
まず利用中のSEOプラグインがllms.txtを配信しているかを確認する。配信しているなら、そのSEOプラグインのファイルが優先されるため、FoundByAI側の設定を変更する必要はない。配信していない場合に、1.3.6以降のFoundByAIが自動で代替する。
更新後の動作確認方法
更新後は、シークレットウィンドウで /llms.txtにアクセスしてHTTP 200が返ることを確認する。あわせて /llms-full.txtの内容にDiviショートコードが残っていないかも目視で確認する。ブラウザのキャッシュが残っていると古い結果が見えることがあるため、シークレットウィンドウを使うのが確実だ。
llms-full.txtにDiviショートコードが混入するのはなぜか
llms-full.txtに [et_pb_section] や [et_pb_row] などの生のショートコードが出力されるのは、生成処理がDiviのモジュール読み込みよりも先に実行されていたためだ。1.3.5以前のFoundByAIは、DiviがショートコードをHTMLに展開する前にページ内容を収集していた。
この結果、Diviのテキストモジュールやアコーディオン、カスタムHTMLブロックの中身が、読みやすいテキストではなく生のショートコードとして埋め込まれる。AIクローラーが読むファイルとしては不適切な内容だ。
[et_pb_row]
[et_pb_text]
本文のテキストが生のまま混ざる
[/et_pb_text]
[/et_pb_row]
[/et_pb_section]
##本文の見出し
読みやすいテキストだけが出力される
更新前後でllms-full.txtの内容はこのように変わる。
1.3.6で修正済みだがDivi 5は要確認
1.3.6はDivi 4.27で動作確認が行われている。Divi 5はコードベースが大きく変更されているため、公式には確認されていない。Divi 5環境では更新後に必ず /llms-full.txtを開いて、生のショートコードが残っていないかを確認する。
Markdown版ページは元から正常だった
補足すると、個別ページのMarkdown版（.md形式）は1.3.5以前からクリーンな出力だった。問題があったのはllms-full.txtという全体をまとめたファイルだけだ。両者の生成タイミングが異なるため、この差が生じていた。
初回アクセスに30〜40秒かかる問題の軽減策
1.3.6への更新後、/llms.txtと /llms-full.txtの初回アクセスに30〜40秒かかることがある。2回目以降はキャッシュが使われ、ほぼ瞬時に表示される。この待ち時間は、サイト全体のページを収集してMarkdownを生成する処理が動くためだ。
より深刻なのはキャッシュの有効期限が切れた直後だ。AIクローラー（OAI-SearchBot、ChatGPT-User、ClaudeBotなど）が初回リクエストを送ったとき、30〜40秒待たされるとタイムアウトして取得を諦める可能性がある。
キャッシュの仕組みを理解する
FoundByAIは生成したファイルを一定時間キャッシュする。キャッシュが有効な間は高速に配信されるが、期限切れ後の最初のリクエストでは再度フル生成が走る。バックグラウンドで事前生成する仕組みがなければ、この「最初の1人」は必ず長い待ち時間を経験する。
静的ファイルを手動配置してタイムアウトを回避する
確実な対策は、生成済みのllms.txtとllms-full.txtをサーバーのルートディレクトリに静的に配置することだ。プラグインの生成処理を待たず、常に即時配信されるため、AIクローラーがタイムアウトする心配がなくなる。
ただし、コンテンツを更新するたびに手動で再生成する運用が必要になる。サイト更新の頻度が高い場合は、キャッシュの有効期限を長めに設定しつつ、更新作業の後に手動でファイルを再配置する運用が現実的だ。
手動アップロードしたllms.txtをどう扱うか
1.3.6への更新前に手動でllms.txtをアップロードした場合、更新後しばらくはそのまま残しておいて問題はない。プラグイン生成版の配信が確認できてから削除するのが安全だ。
手動ファイルが残っていると、生成されたファイルと内容が食い違うことがある。プラグインの生成が安定したら、手動ファイルは削除して一元管理するのが望ましい。サイトの構成や更新頻度に応じて、手動配置を継続するかプラグインに任せるかを判断する。
よくある質問
llms.txtとは何か、誰が読むのか
llms.txtは大規模言語モデル（LLM）向けのサイト案内ファイルだ。robots.txtが検索エンジン向けなら、llms.txtはAIクローラー向け。サイトの重要ページ一覧や要約をMarkdown形式で記述し、AIが効率よくサイトを理解できるようにする。llms-full.txtはより詳細な全文版だ。
Rank Math SEOのllms.txt機能がオフなのに404になるのはなぜか
FoundByAI 1.3.5以前は、Rank Mathが有効化されていると「Rank Mathが配信する」と判断して自ら配信を止めていた。Rank Math側のllms.txt機能がオフだと、どのプラグインも配信せず404になる。1.3.6ではこの判断が修正されている。
Divi 5でもFoundByAI 1.3.6は正常に動くか
1.3.6のDivi対応はDivi 4.27でテストされている。Divi 5はコードベースが異なるため、公式には動作確認されていない。Divi 5環境では更新後に /llms-full.txtを開いて生のショートコードが残っていないか確認する。
プラグインを更新せずにこの問題を回避できるか
手動でllms.txtをアップロードすれば404は回避できる。ただしllms-full.txtのDiviショートコード混入は手動では根本解決できない。1.3.6以降への更新が最も確実な対処だ。
キャッシュ有効期限が切れた後の初回アクセスを速くする方法はあるか
生成済みの静的ファイルをサーバーに直接配置する方法が有効だ。キャッシュ期限に関係なく即時配信される。ただしコンテンツ更新時には手動で再生成する必要がある。
この記事のポイント
- /llms.txtの404はSEOプラグインとの競合が主因
- FoundByAI 1.3.6への更新で404とDiviショートコード混入が解決
- Rank Math SEOのllms.txt機能がオフの環境で発生しやすい
- 初回アクセスの30〜40秒はキャッシュ生成が原因
- 静的ファイルの手動配置でクローラーのタイムアウトを防ぐ
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Contact Form 7更新後にフォーム管理画面へアクセスできない時の原因と直し方
Contact Form 7を6.2系へ更新した後、管理者以外のユーザーがフォームの編集画面に入れなくなった場合は、管理メニューのURL変更が原因の可能性が高い。メニュー設定を制御するプラグイン（WP Custom Admin Interfaceなど）に新しいURLを追加すれば解決する。
Contact Form 7 6.2系で管理画面URLが変わった理由
Contact Form 7は6.2.0から管理メニューの構成が整理された。従来のフォーム一覧画面は /wp-admin/wpcf7 という直感的なURLだったが、6.2以降は /wp-admin/admin.php?page=wpcf7 に変更された。
あわせて新規作成画面は /wp-admin/admin.php?page=wpcf7-new、ダッシュボードは /wp-admin/admin.php?page=wpcf7-dashboard に分かれた。メニューのスラッグ（識別子）が変わったため、旧URLを基準にアクセス制御をかけていたプラグインが反応しなくなる。
このURLの変化は、フォーム管理画面への直リンクやブックマークにも影響する。旧URLを保存している場合は、新URLへ置き換える必要がある。
管理者以外がフォームを編集できなくなる原因
管理メニューの表示や権限をカスタマイズするプラグインは、メニューのスラッグを記録して「どの役割にどのメニューを見せるか」を制御する。WP Custom Admin Interfaceのようなプラグインは、WordPressが登録するメニュー情報を監視し、条件に合わないメニューを非表示にしたりアクセスを拒否したりする。
CF7 6.2系でメニュー構成が変わると、プラグインが記録していた旧スラッグに一致するメニューが存在しなくなる。結果として、新しく追加された wpcf7 や wpcf7-new というスラッグが「許可されていないメニュー」と見なされ、管理者以外のユーザーが画面を開けなくなる。
マルチサイト環境では、ネットワーク全体を管理するスーパー管理者と、各サイトの管理者とで権限の扱いが異なる。スーパー管理者はネットワークレベルの権限で大半の制限を迂回できるため、一見するとスーパー管理者だけがアクセスできるように見えることがある。
管理メニュー設定に新しいURLを追加する対処手順
まずは利用中のメニュー制御系プラグインの設定画面を開き、Contact Form 7に関連する新しいメニュー項目を許可リストへ追加する。WP Custom Admin Interfaceでは「Admin Menu」設定でメニュー項目ごとに表示・アクセスの可否を管理できる。
追加すべきメニュー項目の一覧
wpcf7（フォーム一覧）wpcf7-new（新規作成）wpcf7-dashboard（ダッシュボード）wpcf7-integration（連携設定、テーマにより表示）
メニュー項目を追加してもアクセスできない場合は、プラグインがURLの完全一致ではなく前方一致や正規表現で判定している可能性がある。wpcf7 という文字列を含む項目をすべて許可する設定ができるかどうかを確認する。
設定を変更しても直らない場合の切り分け
メニュー設定の追加だけで解決しないときは、一時的にメニュー制御系プラグインを無効化して、Contact Form 7のフォーム管理画面へアクセスできるかを確認する。無効化でアクセスできるなら、プラグイン側のURL判定が新しいメニュー構造へ対応していない。
プラグインの開発元がCF7 6.2系への互換アップデートを出しているかを確認し、最新版へ更新する。それでも対応していない場合は、権限制御を別の方法（ユーザー役割の見直しや、Contact Form 7の権限フィルター）で実現することを検討する。
権限設定と役割を確認する方法
Contact Form 7の管理画面へアクセスするには、ユーザーに適切な権限（ケイパビリティ）が必要だ。標準では管理者権限（manage_options）を持つユーザーがフォームを管理できるが、カスタム権限を設定している環境では役割ごとの権限を見直す必要がある。
ユーザー役割編集系プラグインを使っている場合、Contact Form 7自体が要求する権限を確認し、対象の役割へ割り当てる。CF7 6.2系では管理画面のページが細分化されたため、フォーム管理の権限とダッシュボード閲覧の権限が別に扱われることがある。
マルチサイト環境では、サイト管理者とスーパー管理者の権限差も確認する。スーパー管理者だけがアクセスできる状態は、ネットワークレベルの権限設定が影響している場合があるため、各サイトの管理者にも適切な権限が付与されているかを確認する。
プラグイン更新前に検証環境で確認する推奨フロー
Contact Form 7のように管理画面の構造を変える更新は、本番環境へ適用する前に必ずステージング環境（検証サイト）で確認する。特にメニュー制御系や権限管理系のプラグインを併用している場合は、更新後に管理画面へ正常にアクセスできるかを各ユーザー役割でテストする。
ステージング環境を用意できない場合でも、メンテナンス時間を設けて更新し、直後に管理者以外のユーザーでアクセス確認を行う。問題が起きたときにすぐ切り戻せるよう、更新前のバックアップを必ず取得しておく。
よくある質問
Contact Form 7 6.2系の管理URLはどこに変わった？
フォーム一覧が /wp-admin/wpcf7 から /wp-admin/admin.php?page=wpcf7 に変わった。新規作成は wpcf7-new、ダッシュボードは wpcf7-dashboard というページとして分離された。
メニュー管理プラグインを使っていない場合も影響する？
メニュー制御系プラグインを使っていなければ、通常は管理者以上の権限を持つユーザーがそのままアクセスできる。影響が出るのは、旧URLを前提にメニューや権限をカスタマイズしていた場合に限られる。
マルチサイト特有の注意点はある？
マルチサイトではスーパー管理者とサイト管理者の権限差がある。サイト管理者がフォームを編集できない場合は、メニュー制御プラグインの設定に加えて、各サイトのユーザー役割にContact Form 7の管理権限が付与されているかも確認する。
WP Custom Admin Interface以外のメニュープラグインでも同じ問題が起きる？
起きる可能性がある。管理メニューのスラッグを記録してアクセス制御する仕組みを持つプラグインは、Contact Form 7に限らず他のプラグインのメニュー構造が変わったときも同様の競合が起こり得る。
新しいURLを追加してもアクセスできない場合は？
メニュー制御系プラグインを一時的に無効化して、Contact Form 7単体でアクセスできるかを確認する。無効化でアクセスできるなら、プラグインの互換アップデートを待つか、権限管理を別の方法へ移行することを検討する。
この記事のポイント
- Contact Form 7 6.2系で管理画面URLが
admin.php?page=wpcf7に変わった - メニュー制御系プラグインが旧URLを基準にアクセスを拒否する
- 対処は新しいメニュースラッグを許可リストへ追加するのが基本
- 設定追加で直らない場合はプラグイン無効化で切り分ける
- 更新前にステージング環境で各ユーザー役割のテストを行う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
ACFブロックが編集画面で表示されない時の原因と対処（React 19実験を無効化）
GutenbergのReact 19実験が有効になると、ACFで登録したブロックが編集画面で「このブロックでエラーが発生したためプレビューできません」と表示され、プレビューできなくなることがある。この症状はACFがReact 19に未対応の段階で起こる互換性問題で、テーマのfunctions.phpにフィルターを追記してReact 18に固定すれば回避できる。
なぜACFブロックだけが編集画面でエラーになるのか
ACFで登録したブロックは、編集画面のプレビュー部分がReactコンポーネントとして扱われる。React 19ではコンポーネントの渡し方や内部処理が変更されたため、ACF 6.8.10以前の実装と噛み合わず「要素のタイプが無効です」という趣旨のReactエラー（コンソール上はReact error #130）が発生する。
コアブロックでは発生せずACFブロックだけに症状が出るのは、このエラーがブロックエディタ全体の不具合ではなくACFプラグイン側の互換性に起因するためだ。フロントエンドはサーバー側で描画されるため影響を受けず、編集画面のプレビューだけが壊れる。
編集画面では赤いエラー表示だけが出て手も足も出ないが、フロントエンドが正常ならこの互換性問題を強く疑ってよい。
React 19実験はなぜ自動で有効になるのか
GutenbergのReact 19実験は、互換性のないプラグインやテーマが見つからない限り自動で有効になる設計だ。不要なテーマやプラグインを整理した直後など、互換性チェックが通るようになったタイミングで突然有効化されることがある。
管理画面の「Gutenberg」メニューの「実験」画面で有効かどうかを確認できる。ただし一部のホスティング環境では、チェックを外しても保存されず、設定が既定値（有効）に戻ってしまう。そのため管理画面からの無効化だけでは対処できない場合がある。
この流れでReact 19が有効になった結果、ACFブロックのプレビューだけが壊れる。管理画面の設定が保存されない環境では、次の手順で強制的にReact 18へ固定する。
functions.phpでReact 18に固定する手順
対処は子テーマのfunctions.phpにフィルターを追記し、Gutenbergの実験オプションを上書きしてReact 18を維持する方法が確実だ。親テーマを直接編集するとアップデートで上書きされるため、必ず子テーマを使う。
// ACFがReact 19に対応するまでブロックエディタをReact 18に固定する
$theme_disable_react_19 = function($experiments){
$experiments = is_array($experiments) ? $experiments : [];
$experiments['gutenberg-react-19'] = false;
return $experiments;
};
add_filter('option_gutenberg-experiments', $theme_disable_react_19);
add_filter('default_option_gutenberg-experiments', $theme_disable_react_19);このフィルターは、Gutenbergの実験設定を保存するオプションに対して gutenberg-react-19 フラグを常にfalseに上書きする。管理画面でチェックを外しても戻ってしまう環境でも、テーマ側から強制できるため再発しない。
ACFがReact 19に対応したバージョンにアップデートされたあとは、このコードを削除して通常の設定に戻す。削除し忘れると新しいReactを使うべきタイミングでも18に固定されたままになるため、ACFの更新履歴は確認しておく。
修正後にブロックが表示されるか確認する方法
functions.phpにコードを追加したあとは、サーバー側とプラグイン側のキャッシュを削除し、ブロックエディタをハード再読み込み（Ctrl + Shift + Rなど）する。ACFブロックを再配置し、プレビューが表示されることを確認する。
ブラウザのコンソールを開き、React error #130が消えていることも確認すると確実だ。本番環境で直接試すのが不安な場合は、ステージング環境に同じコードを入れて挙動を確認してから反映する。
ACF側の対応と今後のアップデート
この症状はACFがReact 19に正式対応するまでの過渡期の互換性問題として認識されており、ACFの開発側でも修正が進められている。今後のアップデートでReact 19対応が含まれた場合は、本記事のフィルターを外して編集画面の挙動を再確認する。
それまでの間は、本番環境でReact 19実験を有効にしたまま使い続けるリスクを避けるため、本記事のフィルターでReact 18に固定しておくのが現実的だ。関連するプラグインやテーマが更新されたタイミングで、ステージング環境から互換性を確認する流れを作っておくと安全だ。
よくある質問
React 19実験を無効化すればACFブロックは直るのか
直る。ただし一部のホスティング環境では画面上のチェックが保存されず、既定値の有効に戻ってしまう。その場合はfunctions.phpのフィルターで強制的に無効化する。
functions.phpを直接編集せずに対処する方法はあるか
コードスニペットプラグインを使ってフィルターを追加する方法がある。いずれも親テーマを直接編集しないこと。親テーマを更新するとコードが消えるため、子テーマかスニペットプラグインを使う。
フロントエンドは表示されるのに編集画面だけ壊れるのはなぜか
ACFブロックの公開ページはサーバー側で描画されるため、React 19の影響を受けない。編集画面のプレビューだけはReactで組み立てられるため、互換性の問題が表面化する。
ACF以外のブロックが同じエラーを出す場合はどうすればよいか
同じReact error #130がコアブロックや他のプラグインブロックでも出る場合は、React 19実験だけでなくブロックの登録方法やプラグインの競合も確認する。一旦全プラグインを無効化して切り分けるのが早い。
フィルターを入れたままACFをアップデートしても問題ないか
問題はないが、ACFがReact 19に対応した後もフィルターが残っていると、React 18に固定され続ける。ACFの更新履歴を確認し、対応が完了したらフィルターを外して動作を再確認する。
この記事のポイント
- React 19実験の有効化でACFブロックの編集画面プレビューがエラーになる
- フロントエンドは影響を受けず、編集画面だけに症状が出る
- 管理画面のチェックが保存されない環境ではfunctions.phpから強制する
- ACFがReact 19に対応したらフィルターを外して再確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
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制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
AI PufferでGPT 6.1 Solを選ぶとtop_pエラーが出る時の直し方
AI Puffer で GPT 6.1 Sol を選択した直後に「top_pはこのモデルでは使えない」という趣旨の英語エラーが出る場合、原因はプラグインが temperature（温度）と top_p（トップP）というパラメータを自動送信していることにある。AI Puffer をバージョン 2.4.98 以降へ更新すれば、GPT 6.1 Sol 向けには不要なパラメータが自動で省略され、エラーは解消する。
なぜ GPT 6.1 Sol で top_p エラーが発生するのか
AI Puffer を含む WordPress 向けチャットボットプラグインは、AI モデルに問い合わせを送るとき、文章のランダム性を調整する temperature（温度）と、次の単語の候補を絞る top_p（トップP）という2つの値を自動で付与してきた。これは旧モデルでは広く使われていた標準的なパラメータだ。
ところが GPT 6.1 Sol は仕様が大きく変わり、これら2つのパラメータを一切受け付けなくなった。古い AI Puffer はモデルごとの違いを区別せず、どのモデルにも同じパラメータを送っていたため、API 側が「このモデルでは使えない値だ」と拒否してエラーになった。
上の図のように、修正後のプラグインはモデル名を判別して temperature と top_p の送信自体をやめる。チャットボットの設定画面でそれらの値を操作していなくても、プラグイン内部のデフォルト動作が変わることで自動的に解決する。
AI Puffer を更新してエラーを解消する手順
AI Puffer のバージョン 2.4.98 では、GPT 6.1 Sol 向けに temperature と top_p を送信しないようコードが修正された。まずはこのバージョンへの更新を実行する。
このデモは更新から動作確認までの一連の流れを示している。以下で各ステップの詳細を説明する。
バックアップを取得する
プラグイン更新の影響でサイト全体が動かなくなる可能性は低いが、万が一に備えてバックアップを取っておく。UpdraftPlus などのバックアッププラグインや、サーバー側の自動バックアップ機能を利用すれば数クリックで完了する。
管理画面から AI Puffer を更新する
WordPress 管理画面の「プラグイン」ページを開き、AI Puffer に更新通知が出ていることを確認して「今すぐ更新」を押す。更新通知が表示されない場合は、公式ページから最新版の ZIP をダウンロードし、管理画面の「プラグイン → 新規追加 → プラグインのアップロード」から上書きできる。
バージョンを確認して応答テストをする
更新後にバージョンが 2.4.98 以上になっていることを確認する。「プラグイン」ページの AI Puffer の行に表示されるバージョン番号を見ればよい。続いてチャットボットを新規作成し、モデルに GPT 6.1 Sol を選んで応答テストを行う。
新規作成でテストするのは、既存のチャットボットが古いパラメータ設定を保存している可能性があるためだ。新規作成で正常に動けば、既存のチャットボットも削除して作り直すと確実である。
更新後もエラーが続く場合のチェックポイント
キャッシュを削除する
WordPress のキャッシュプラグインやブラウザキャッシュに古いスクリプトが残っていると、更新後もエラーが表示され続けることがある。キャッシュプラグインの設定から全キャッシュを削除し、ブラウザでもスーパーリロード（Ctrl + Shift + R キー）を実行する。
既存のチャットボットを再作成する
更新前から存在するチャットボットは、内部に古いパラメータ設定を保持していることがある。削除して新規作成し、同じ設定でテストすれば、プラグイン側の修正が正しく反映される。
API キーの権限と接続先を確認する
エラー内容がパラメータ関連から認証関連に変わった場合は、API キーの有効期限や権限、接続先のエンドポイント設定を確認する。AI Puffer の設定画面で API キーが正しく保存されているか、モデル一覧に GPT 6.1 Sol が表示されるかを見る。
他の AI モデルでも同様のエラーが出た場合の考え方
GPT 6.1 Sol に限らず、AI プラグインでモデルを切り替えた直後に「サポートされていないパラメータ」というエラーが出るケースは今後も起こり得る。モデルの仕様変更とプラグインの対応にはどうしてもタイムラグが生まれるためだ。
プラグインの更新履歴を定期的に確認する
AI モデル側の仕様変更にプラグインが追従するには、プラグインの更新が欠かせない。WordPress 管理画面で「更新」バッジが表示されていないか定期的に確認し、AI 関連プラグインはリリースから数日以内に適用する。
新しいモデルはテスト用チャットボットで試す
新しい AI モデルがリリースされた直後は、主要プラグインがまだ対応していないことがある。本運用中のチャットボットで新モデルを試す前に、テスト用のチャットボットを別途作成して動作を確認すると安全だ。
エラー全文を記録して報告する
エラーメッセージには原因となるパラメータ名が含まれていることが多い。スクリーンショットとエラー全文を保存しておけば、サポートに報告する際に問題解決が早くなる。temperature や top_p といった具体的な単語が重要な手がかりになる。
よくある質問
GPT 6.1 Sol 以外のモデルでも同じエラーが出ますか
モデルごとにサポートするパラメータが異なるため、GPT 6.1 Sol だけに限らない。新しいモデルに切り替えたときに同様のエラーが出た場合は、プラグインの更新有無をまず確認する。
temperature と top_p は今後のモデルでも使えなくなりますか
GPT 6.1 Sol では使えなくなったが、他のモデルで同様の仕様になるとは限らない。モデルごとに仕様が異なるため、エラーが出た時点でそのモデルの対応状況を確認する必要がある。
エラーが出てもサイトの他の部分には影響がありますか
このエラーはチャットボット機能内に限定され、記事表示や管理画面の他の操作には影響しない。ただしチャットボットを本運用している場合は、問い合わせが機能しなくなるため早めの更新が欠かせない。
AI Puffer を手動で更新する方法を教えてください
公式ページから最新版の ZIP ファイルをダウンロードし、管理画面の「プラグイン → 新規追加 → プラグインのアップロード」から上書きすればよい。FTP を使う場合は wp-content/plugins ディレクトリ内の該当フォルダを置き換える。
更新ができない場合はどうすればよいですか
サーバー側の制約やファイル権限の問題で更新が失敗することがある。WordPress 管理画面の「サイトヘルス」ページから PHP バージョンやファイル権限の状態を確認し、必要ならサーバー管理画面で調整する。
この記事のポイント
- AI Puffer で GPT 6.1 Sol を選ぶと発生する top_p エラーは、プラグインが不要なパラメータを送信していることが原因
- AI Puffer をバージョン 2.4.98 以降に更新すれば、GPT 6.1 Sol 向けに temperature と top_p が自動で省略される
- 更新後はキャッシュ削除と新規チャットボットでの応答テストを忘れない
- AI モデルの仕様変更にプラグインが追従するまでタイムラグがあるため、新モデル採用時はテスト運用が重要
- エラー全文とスクリーンショットを保存しておくと、サポート報告時の解決が早い
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている