WPC Linked Variation 更新で管理画面の依存スクリプトエラーを修正する方法
WooCommerceの商品バリエーションを扱うプラグイン「WPC Linked Variation」（WooCommerce用）を使っていると、管理画面のあらゆるページで「依存関係にあるスクリプトが登録されていません」という警告が表示される場合がある。これはバージョン4.4.3以前の不具合であり、最新版4.4.4以降へアップデートすればすぐに消える。
エラー「正しく呼び出されていません」の中身と発生原因
管理画面の任意のページで、「依存関係 wc-enhanced-select, selectWoo が登録されていない」という警告が表示される
プラグイン更新後、または正しい画面チェック付きで読み込まれれば警告は消え、管理画面がすっきりする
上記のようなデモの流れで、管理画面の上部やQuery Monitorに突然エラーが出現する。
WooCommerceは商品編集画面や注文編集画面といった限定された管理ページにのみ、wc-enhanced-selectやselectWooといった選択UIを拡張するためのスクリプトを登録している。ところがWPC Linked Variation 4.4.3は、admin_enqueue_scriptsアクションの中で画面を一切絞り込まずに、これらに依存するwpclv-backendを読み込もうとしていた。
その結果、WooCommerceがスクリプトを用意していない「割引プラグインの設定画面」や「ユーザープロフィール」など、まったく関係のないページで依存先が見つからず、WordPressが「WP_Scripts::add の呼び出しが正しくない」と警告を出す。フロントエンドの表示や動作には影響しないが、管理画面の見通しが悪くなり、Query Monitorなどのデバッグツールを使っていると特に目立つ。
プラグイン更新でエラーを消す手順
プラグイン一覧に更新通知が表示されない場合は、WooCommerce公式マーケットプレイスまたはCodeCanyonから最新版を手動でダウンロードし、FTP経由で上書きする方法もある。いずれの場合も、更新前に必ずサイト全体のバックアップを取得しておく。
バージョン4.4.4では、開発者がadmin_enqueue_scripts内に適切な画面チェックを実装し、WooCommerceの商品編集画面でのみ依存スクリプトを読み込むように修正された。そのため、他のプラグインの設定画面や投稿一覧などで無用な警告が出ることはなくなる。
すぐにアップデートできない場合の一時しのぎ
プロジェクトの都合ですぐにプラグインを更新できない場合、応急処置としてQuery Monitorを一時的に無効化するか、プラグインファイルを手動で編集する方法がある。後者は更新時に上書きされてしまうため、あくまで次のアップデートまでのつなぎと考えてほしい。
コードを直接修正する開発者向け手順
WPC Linked Variationのプラグインフォルダ内にある wpc-linked-variation.php を開き、admin_enqueue_scripts にフックしている関数を以下のように変更する。現在の管理画面オブジェクトを取得し、投稿タイプが product の場合だけスクリプトを読み込む条件を追加する。
// 修正前（問題のあるコード）
add_action('admin_enqueue_scripts', 'wpclv_enqueue_scripts');
function wpclv_enqueue_scripts() {
wp_enqueue_script('wpclv-backend', plugins_url('assets/js/backend.js', __FILE__), array('wc-enhanced-select', 'selectWoo'), WPC_Linked_Variation::VERSION, true);
}
// 修正後（画面チェックを追加）
add_action('admin_enqueue_scripts', 'wpclv_enqueue_scripts_fixed');
function wpclv_enqueue_scripts_fixed($hook) {
$screen = get_current_screen();
if ($screen && $screen->post_type === 'product') {
wp_enqueue_script('wpclv-backend', plugins_url('assets/js/backend.js', __FILE__), array('wc-enhanced-select', 'selectWoo'), WPC_Linked_Variation::VERSION, true);
}
}この修正により、商品の編集・新規追加画面でのみスクリプトが読み込まれ、それ以外の管理画面ではエラーが発生しなくなる。修正後は管理画面をリロードして警告が消えることを確認する。本体のアップデートが可能になった時点で、必ず公式の最新版に差し替えることを推奨する。
よくある質問
このエラーはサイトのフロントエンドに影響しますか
影響しない。あくまで管理画面内でQuery MonitorやWordPressのデバッグ表示が警告を出すだけであり、来訪者が見る商品ページやチェックアウト画面の動作は変わらない。
プラグインを更新する以外の簡単な対処法はありますか
Query Monitorプラグインを無効化すればエラー表示自体は消えるが、あくまで表示上の回避に過ぎない。管理画面のパフォーマンスや他のスクリプト競合のリスクが残るため、プラグイン本体の更新が確実な解決策になる。
ほかのプラグインでも同様の「正しく呼び出されていません」エラーが出ます
多くのプラグインが管理画面用のスクリプトを読み込む際、WooCommerceや他のプラグインが提供するライブラリを依存関係に指定することがある。読み込むページを限定していない場合、同様の依存エラーが発生する。該当プラグインの開発者に報告するか、バージョンアップ情報を確認するのが近道だ。
バージョン4.4.4に更新してもまだエラーが消えない場合は
まずブラウザキャッシュとWordPressのキャッシュ（サーバーキャッシュやプラグインキャッシュ）をすべてクリアする。それでも消えなければ、別のプラグインが同様の問題を起こしている可能性があるため、すべてのプラグインを一時停止し、一つずつ有効化して原因を特定する。WooCommerce本体も常に最新版に保つ。
この記事のポイント
- WPC Linked Variation 4.4.3以前に起因する管理画面のスクリプト依存エラー
- プラグインを4.4.4以降にアップデートすれば完全に解消する
- エラーはフロントエンドに影響せず、管理画面の表示だけの問題
- 応急処置としてQuery Monitor無効化やコード修正も可能だが、公式更新が最も安全
- 他プラグインでも同様の警告が起きる場合、画面チェックの有無を疑う
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Shopify×Vercel、Hydrogenフレームワークを再構築。マルチフレームワーク対応とAIエージェント導入
ShopifyとVercelが、ヘッドレスコマースフレームワーク「Hydrogen」の全面的な再構築に着手した。2026年7月30日にVercel Blogが発表した内容によると、新バージョンはオープンソース化され、Next.js以外のフレームワークでも動作するランタイム非依存型へと生まれ変わる。
この刷新により、開発者は型安全なAPIクライアントやカート状態管理をワンインポートで利用でき、ストアフロントの構築が大幅に効率化される。さらに「Standard Actions」と呼ばれるエージェント型コマース機能が追加され、AIが購入支援や在庫確認などを自律的に処理する仕組みが提供される。
Hydrogenとは何か？
HydrogenはShopifyが提供するヘッドレスコマース専用のフロントエンドフレームワークだ。従来のShopifyストアはテーマで構築するが、Hydrogenを使うとReactコンポーネントで自由にカスタマイズした店舗を開発し、Shopifyのバックエンドとシームレスに連携できる。つまり「自由な画面デザイン」と「Shopifyの堅牢なバックエンド」を両立させる架け橋と言ってよい。
これまでHydrogenはNext.jsに最適化された形で展開されていたため、開発者はReact/Next.jsのエコシステムに縛られていた。NuxtやSvelteなど別のフレームワークを使う場合は、独自にAPI連携や状態管理を実装する必要があり、それが導入障壁になっていた。
何が変わるのか？
今回の再構築では、Hydrogenの根本的な設計が刷新される。具体的には以下の3つの大きな変化がある。
この比較から分かる通り、新しいHydrogenではフレームワークの選択肢が広がり、面倒な共通処理はフレームワークが肩代わりしてくれる。結果として、開発者はビジネスロジックに集中できる。
オープンソース化とランタイム非依存
最大の変更点は、Hydrogenが完全オープンソースになり、ランタイムにも依存しなくなったことだ。旧バージョンは実質的にNext.jsアプリとして動作する設計だったが、新しいHydrogenは@shopify/hydrogenパッケージをブラウザ用JavaScriptで動作するように再実装し、@shopify/storefront-api-clientと共に利用する形になる。
これにより、開発者はNext.jsはもちろん、Nuxt、SvelteKit、あるいは純粋なViteアプリケーションなど、好みのフレームワーク上でHydrogenストアフロントを構築できる。Vercelの発表ブログでは「cart.query()やcart.lineItems()といったAPIをインポートするだけで、カートの操作や状態管理が完了する」と説明されており、従来のようにフレームワークごとに接着コードを書く手間が不要になる。
標準Actionsとエージェントコマース
もうひとつの目玉は「Standard Actions」の導入だ。これはAIエージェントがショッピング行動を自立支援するための統一インターフェースであり、店舗の様々な操作（検索、商品詳細の取得、カート追加、購入）をアクションとして定義する。
ユーザーが自然言語で要望を伝えると、AIエージェントが最適なアクションを選択して結果を返す。この仕組みを利用すれば、「オススメの夏用ジャケットを見せて」「先週買おうとした商品をカートに戻して」といった会話型の購買体験をストアフロントに組み込める。
Standard Actionsは、AIモデルが商品データや在庫情報にアクセスしやすい形で提供されるため、自前で複雑なAIパイプラインを構築する必要がない。ChatGPTやClaudeといった外部AIと統合する場合も、アクション定義を合わせるだけで済む設計だ。
なぜこのパートナーシップが重要なのか
ShopifyとVercelの連携強化は、単なるコードのリファクタリングではない。ここには二つの大きな戦略的意義があると考えられる。
一つは「Shopifyのバックエンドをあらゆるフロントエンドから利用可能にする」という方向性だ。ヘッドレスコマース市場では、各ブランドが独自のデザインシステムや技術スタックを持つことが当たり前になってきた。Hydrogenがランタイム非依存になることで、React以外のスタックを使っている企業も無理なくShopifyに移行できるようになる。
もう一つは「AI時代のコマース体験の標準化」だ。Standard Actionsは、AIエージェントが安全かつ一貫した方法で店舗操作を行えるプロトコルを定義する。これが広く採用されれば、どんなストアフロントでも同じ仕組みでAIアシスタントを動かせるようになるため、エコシステム全体のAI対応速度が上がる。
さらに、オープンソース化によってコミュニティの貢献が期待でき、Hydrogen自体の開発スピードも加速する。プラットフォームに閉じない設計は、長期的なベンダーロックインの回避にもつながる。
実務への影響と開発スピード
Vercel Blogの記事では、ファッションブランド「Paige」の事例が紹介されている。新しいHydrogenを採用した結果、それまで数か月かかっていた新機能の開発が1週間に短縮されたという。これは単にコード量が減っただけでなく、標準化されたAPIクライアントと状態管理によって、チームが細かい実装に悩まなくなり、ビジネスロジックの試行錯誤に集中できるようになった成果だ。
中小規模のECサイト運営者にとっては、これまで「ヘッドレス」と聞くだけで専門のReactエンジニアが必要だと思われていた壁が下がる。HydrogenがNuxtやSvelteでも動くため、社内のフロントエンドチームが使い慣れたフレームワークをそのまま活かせる。さらに型安全なクライアントが用意されているため、APIの仕様変更に伴う不具合もコンパイル時に検出しやすくなる。
パフォーマンス面でも、ランタイムの最適化が進んだことで、ストアフロントの表示速度が向上する。Vercelのエッジネットワークとの組み合わせにより、世界中のユーザーに高速な体験を提供できるのも大きな強みだ。
この記事のポイント
- Hydrogenがオープンソースかつランタイム非依存となり、Next.js以外のフレームワークでも動作する
- 型安全なAPIクライアントとカート状態管理が標準提供され、開発効率が飛躍的に向上する
- Standard Actionsによって、AIエージェントが自然言語でショッピングを支援する仕組みが組み込まれる
- ファッションブランド「Paige」では開発期間が数か月から1週間に短縮された事例が報告されている
- 中小規模のECサイトでも、ヘッドレスコマースの導入ハードルが大きく下がる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
埋め込みチャットでNS_ERROR_DOM_COEP_FAILEDエラーが出た時の直し方
サイトに埋め込んだ Teams やその他のチャットウィジェットをクリックした時に NS_ERROR_DOM_COEP_FAILED と表示されて開けない場合、サーバーが返している COEP（Cross-Origin Embedder Policy）ヘッダーが原因だ。htaccess で Cross-Origin-Embedder-Policy を credentialless に変更するか、不要なヘッダーであれば削除することで解決する。
NS_ERROR_DOM_COEP_FAILEDとは何か
COEP は「Cross-Origin Embedder Policy」の略で、ページが他オリジン（別ドメイン）のリソースを読み込む際のセキュリティルールを定める HTTP レスポンスヘッダーだ。このヘッダーが require-corp に設定されていると、埋め込む側のリソースすべてに CORP（Cross-Origin Resource Policy）ヘッダーが付与されていることをブラウザが要求する。
Teams のチャットウィジェットをはじめ、多くのサードパーティ製ウィジェットは自社の配信サーバーから JavaScript や画像を読み込むが、それらのリソースに CORP ヘッダーが付与されていないことが多い。結果としてブラウザが読み込みをブロックし、NS_ERROR_DOM_COEP_FAILED というエラーをコンソールに出力する。
このエラーは Firefox や Chrome などのモダンブラウザで発生し、ウィジェットのボタンは表示されるがクリックしてもチャット画面が開かない、または読み込み中のまま固まるといった症状が出る。
COEPヘッダーを require-corp で返している
配信する JS や画像に CORP ヘッダーが付いていない
NS_ERROR_DOM_COEP_FAILED を出力しウィジェットが開かない
この図のとおり、自サイトのサーバー設定と外部ウィジェットの配信仕様が噛み合わず、ブラウザが安全側に倒して読み込みを拒否するのが根本的な原因だ。
自サイトにCOEPヘッダーが設定されているか確認する手順
まずは自サイトが実際に COEP ヘッダーを返しているかどうかを確認する。ブラウザの開発者ツールを使えば数分で特定できる。
Chrome や Firefox の開発者ツールでレスポンスヘッダーを確認する
サイトの任意のページを開き、F12 キーで開発者ツールを起動する。NetWork タブを開いてページを再読み込みし、先頭のドキュメントリクエスト（多くの場合はページURLそのもの）をクリックする。Response Headers セクションに Cross-Origin-Embedder-Policy という項目があれば、その値が現在の設定だ。
値が require-corp になっている場合、厳格な制限がかかっている状態で、これがエラーの直接原因になる。値が credentialless であればクロスオリジンの埋め込みは許可されているため、別の要因を探す必要がある。ヘッダー自体が存在しない場合は、COEP 以外の原因（CORS 設定やウィジェット側のスクリプトエラーなど）を疑う。
セキュリティプラグインやCDNが自動付与しているケース
WordPress サイトの場合、セキュリティ系プラグインが HTTP レスポンスヘッダーを自動で追加していることがある。また Cloudflare などの CDN サービスを経由していると、CDN 側のセキュリティ設定で COEP ヘッダーが付与されるケースもある。
該当しそうなプラグインを一つずつ無効化してヘッダーの変化を確認するか、CDN の管理画面で「ヘッダー設定」や「セキュリティヘッダー」といった項目をチェックすると原因を絞り込める。
htaccessでCOEPヘッダーを修正してエラーを解決する
原因が COEP ヘッダーの require-corp 設定にあると特定できたら、htaccess ファイルを編集して修正する。Apache サーバーを使っている国内レンタルサーバーの大半は htaccess による上書きが可能だ。
上記 STEP 3 で追記するコードは以下のとおりだ。htaccess の末尾にこのブロックを追加する。
<IfModule mod_headers.c>
Header set Cross-Origin-Embedder-Policy "credentialless"
</IfModule>この設定により、COEP ヘッダーが credentialless モードに切り替わる。credentialless はクロスオリジンのリソース読み込みを許可しつつ、認証情報（Cookie や HTTP 認証）を送信しないモードだ。Teams のチャットウィジェットは認証に Cookie を使わず独自のトークンで認証するため、credentialless モードでも問題なく動作する。
COEPヘッダーを完全に削除する方法
セキュリティ上の要件が特にないサイトであれば、COEP ヘッダー自体を削除する選択肢もある。以下のコードを htaccess に追記すればヘッダーが除去される。
<IfModule mod_headers.c>
Header unset Cross-Origin-Embedder-Policy
</IfModule>どちらの方法を選ぶかはサイトのセキュリティポリシー次第だ。COEP ヘッダーが元々セキュリティプラグインや CDN の自動設定で付与されていたのであれば、credentialless への変更が無難だ。手動で require-corp を指定していた場合は、その意図を再確認した上で削除または変更を判断する。
htaccess編集後に変更が反映されない場合の確認ポイント
ファイルをアップロードしてもヘッダーが変わらない場合、mod_headers モジュールがサーバーで有効になっていない可能性がある。また、CDN を経由しているサイトでは CDN のキャッシュをパージしないと変更がすぐに反映されない。WordPress のキャッシュプラグインを使っている場合も、プラグインの設定画面からキャッシュを全削除する。
変更後は必ず開発者ツールの NetWork タブでレスポンスヘッダーを再確認し、Cross-Origin-Embedder-Policy の値が credentialless に変わっているか、ヘッダー自体が消えているかを検証する。
htaccessが使えないサーバー環境での対処法
Nginx を使っている VPS やクラウド環境では htaccess が使えない。また一部の共用サーバーでは mod_headers が無効化されている場合もある。そうしたケースでの対処法をまとめる。
Nginxの場合
Nginx の設定ファイル（nginx.conf またはサイト単位の conf ファイル）の server ブロック内に以下の行を追加する。
add_header Cross-Origin-Embedder-Policy "credentialless";記述後は nginx -t で設定ファイルの文法チェックを行い、問題がなければ nginx -s reload で設定を再読み込みする。sudo 権限が必要な操作のため、レンタルサーバーではサポートに依頼する必要がある。
CDNやWAFでヘッダーを操作する
Cloudflare を使っている場合、ダッシュボードの「ルール」から「HTTP レスポンスヘッダーを変更」ルールを作成し、Cross-Origin-Embedder-Policy を credentialless に上書きできる。サーバー側の設定を一切触らずに済むため、htaccess 編集に不安がある場合の現実的な代替手段になる。
PHPでヘッダーを直接出力する
WordPress のテーマの functions.php に以下のコードを追加する方法もある。テーマ更新時に消えないよう、必ず子テーマを使う。
function my_set_coep_header() {
header('Cross-Origin-Embedder-Policy: credentialless');
}
add_action('send_headers', 'my_set_coep_header');この方法はサーバー設定に依存せず、WordPress の仕組みだけでヘッダーを制御できる。ただし、テーマの functions.php を編集するため、誤った記述があるとサイトが表示できなくなるリスクを伴う。編集前に必ず functions.php のバックアップを取る。
よくある質問
COEPエラーは特定のブラウザだけに出るのか
Firefox と Chrome 系ブラウザ（Chrome、Edge、Brave など）で発生する。Safari は COEP への対応が遅れていたが、Safari 17.2 以降はサポートしている。ブラウザによってエラーメッセージの文言は異なるが、根本原因は同じ COEP ヘッダーだ。
WordPressのセキュリティプラグインが原因になることはあるか
ある。HTTP セキュリティヘッダーを自動付与する機能を持つプラグイン（セキュリティ全般を扱うプラグインやヘッダー専用プラグイン）が、COEP を含むヘッダーを一括で設定しているケースは多い。プラグインの設定画面で「セキュリティヘッダー」や「HTTP ヘッダー」項目を探し、COEP の値を変更または無効化する。
credentiallessとrequire-corpの違いは何か
require-corp は埋め込み先の全リソースに CORP ヘッダーを必須とする厳格モードだ。一方 credentialless は CORP ヘッダーなしでもクロスオリジン読み込みを許可するが、認証情報（Cookie など）は送信しない。Teams チャットのような独自認証を使うウィジェットでは credentialless で十分動作する。
埋め込みウィジェット側の設定で回避できるか
原則として難しい。COEP エラーは「読み込む側（自サイト）」の制限によって発生するため、ウィジェット提供元（Teams など）の設定で回避する手段はない。ウィジェット提供元が自社の全配信リソースに CORP ヘッダーを付与すれば解決するが、それを個別の利用者が依頼して実現するのは現実的ではない。
htaccess編集に自信がない場合はどうすればよいか
サーバーの管理画面からファイルマネージャーで操作する場合は、編集前に必ず htaccess をコピーしてローカルに保存する。ミスでサイトが表示できなくなったら、そのバックアップをアップロードし直せば元に戻る。どうしても不安な場合は、CDN のヘッダー変更機能や PHP の functions.php で対応する方法を検討する。
この記事のポイント
- NS_ERROR_DOM_COEP_FAILED はサーバーの COEP ヘッダーが require-corp の時に発生する
- Teams など多くの外部ウィジェットは CORP ヘッダーを返さないためブロックされる
- htaccess で COEP を credentialless に変更するかヘッダーを削除すれば解決する
- Nginx 環境や CDN 経由の場合は別の設定手順が必要になる
- 修正後は必ず開発者ツールでレスポンスヘッダーが変わったか確認する
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.1ベータ公開、ノート機能の大幅強化とCSS不要のレスポンシブ編集
WordPress 7.1のベータ版が7月下旬に公開され、編集体験に大きな改善が盛り込まれた。ノート機能がチームでの共同編集に本格対応し、CSSを一行も書かずに端末ごとの見た目を調整できるようになる。正式版はWordCamp USが開催期間中の8月19日にリリースされる予定だ。
今回の目玉は「ノート機能の強化」「レスポンシブスタイリング」「ホバーやフォーカス状態の視覚編集」の3本柱である。さらに、かねてから要望の多かったタブブロックとプレイリストブロックが追加され、管理画面の使い勝手も向上する。テスト段階のため本番環境への適用は避ける必要があるが、正式版までに知っておきたいポイントを詳しく見ていこう。
ノート機能がチーム編集ツールに進化
WordPress 6.9で導入されたノート機能は、ブロック単位の簡素なコメント機能だった。WordPress 7.1ではそれが一変し、複数人でのフィードバックに耐える本格的なツールへと変わる。
@メンションで担当者を直接指名
ノートの入力欄で「@」を打ち込むと、サイトの共同編集者の一覧が検索候補として表示される。目的のメンバーを選択すれば、その人を指名したノートが作成される。これにより「この修正は誰に伝えればいいのか」という迷いがなくなり、チーム内でのやり取りが格段にスムーズになる。
インラインノートで誤解を減らす
これまでのノートはブロック全体に対してしか付けられなかったため、長文の中で「ここを直してほしい」と書いても具体的な箇所が伝わりにくかった。WordPress 7.1では、文章内の特定の語句や文を選択し、その部分だけにノートを付けられる。該当部分はハイライト表示されるため、どの言葉に対する指摘なのかが一目でわかる。WP Beginnerの記事でも「『この部分を言い換えてほしい』という指示が、長い段落の中のどの単語を指すのかを推測する必要がなくなった」と評価されている。
このように、修正箇所と指示がピンポイントで結びつくため、レビューにかかる時間が劇的に短縮される。
その他の改善点
- 同じブロックに対して複数のノートスレッドを立てられる。議題ごとに会話を分離できる
- ノート本文に太字、斜体、コード、リンク、絵文字を使ったリッチテキストが可能
- 長いノートは初期状態で折りたたまれ、サイドバーが散らからない
CSS不要のビジュアルスタイリングが編集画面で完結
WordPress 7.1で最もインパクトが大きいのが、レスポンシブデザインのビジュアル操作である。これまではスマホやタブレット用の見た目を調整するには、CSSメディアクエリを手書きするか、テーマの設定に頼るしかなかった。今回のアップデートで、ブロックエディタ上でプレビューを切り替えながら、直感的にスタイルを設定できるようになる。
端末別のスタイル設定
エディタ上部のプレビュー切り替えで「デスクトップ」「タブレット」「モバイル」を選択すると、以降のブロックスタイルの操作はその画面サイズにだけ適用される。たとえばモバイル表示を選んで見出しのフォントサイズを小さくすれば、実際のスマホでの表示だけが変わる。デスクトップ表示には影響しない。
さらに、ブロック設定パネルには、現在どの画面サイズを編集中かを示す小さなバッジが表示される。意図しない画面用のスタイルを上書きしてしまうミスを防げる。エディタキャンバス自体も、プリセットの3サイズに縛られず、横幅をドラッグして任意の幅での表示をリアルタイムに確認できるようになった。テーマがtheme.jsonで独自のブレイクポイントを定義していれば、その値に合わせたプレビューも可能である。
CSSを書く必要がなくなり、カスタマイズのハードルが大きく下がる。サイト全体に一括適用したい場合は、グローバルスタイルで設定し、変更内容を選択的にグローバルへ反映させることもできる。
ホバーやフォーカス状態も視覚的に編集
ボタンなどのブロックには新たに「状態」ドロップダウンが追加され、ホバー時やフォーカス時、アクティブ時の見た目をエディタ上で直接編集できる。背景色や枠線、テキスト色を状態ごとに変え、その場でプレビュー確認できる。これまではほんの小さな変更であっても、カスタムCSSを追加せざるを得なかったが、今後は組み込みのデザインオプションで完結する。
待望のタブブロックとプレイリストブロック
これまでプラグインで実装していたタブ切り替えのレイアウトが、ついにコアブロックとして導入される。また、音声ファイルをまとめて再生できるプレイリストブロックも新登場する。
タブブロック
商品の仕様、よくある質問、料金プランの比較など、情報をパネルで区切って見せたい場面で重宝する。クリックでパネルを切り替える形式で、長いページを避けたい場合に効果的だ。既存のプラグインで作成したタブは、自動的にはコアブロックに変換されないため、移行の際は手作業が必要になる点に注意しておきたい。
プレイリストブロック
複数の音声ファイルを一つのプレイヤーにまとめ、タイトルやアーティスト名、カバーアート、波形グラフィックとともに表示できる。ミュージシャンや教会、教育機関、ポッドキャスト運営者にとっては、エピソードをまとめて提供するのに理想的なブロックだ。WordPressだけで手軽に音声配信の体裁を整えられるようになる。
加えて、既存のブロックにも多くの改善が加わっている。背景グラデーションと画像の同時適用、テキストシャドウのtheme.json対応、HTMLブロック内でのブロックネストの編集、装飾画像をスクリーンリーダーに読み上げさせない設定、ショートコードのEmbedブロックへの自動変換、ColumnsやGalleryからのグリッドレイアウト変換、アイコンブロックの回転・反転・アイコンセット登録機能など、日常的な制作を後押しするアップデートが多数含まれている。
画像編集とメディア処理の刷新
WordPressに組み込まれている画像編集機能が大幅に変わる。従来の狭いインライン操作から、専用のモーダルウィンドウでの本格的な編集へと進化した。
専用の画像編集モーダル
画像ブロックの「切り抜き」ボタンを押すと、フルスクリーンに近い編集画面が開く。自由トリミング、アスペクト比のプリセット、回転・反転、メタデータの編集を一か所で行える。カバーブロックにも対応しており、背景画像をその場でトリミングできる。本格的な写真編集ソフトには及ばないものの、サイト運営者が日常的に行う作業としては十分な機能を備えている。
ブラウザで画像を前処理しHEICにも対応
WordPress 7.1では、画像のリサイズや圧縮、サムネイル生成の大部分を、アップロード前にブラウザが処理する仕組みが導入される。これにより、サーバーの負荷が大幅に減り、低スペックなホスティング環境でもアップロードエラーが起きにくくなる。
さらに、iPhone標準の画像形式であるHEICをはじめ、UltraHDR、AVIF、WebPといった最新フォーマットへの対応が強化される。これまではサーバー側のImageMagickのバージョンに依存してHEICの変換が失敗することがあったが、ブラウザが変換を担うことで環境を選ばずに済むようになる。なお、ChromeとEdgeではフル機能が利用でき、Safariでは一部がサーバー処理に委ねられ、Firefoxでは従来通りサーバー側で処理される。
アップロードの堅牢性と細かな改善
アップロード中にネットワークが切断されても、キューが自動で一時停止し、再接続後に中断したところから再開される。一括アップロード時には進行状況が表示される。このほか、投稿に添付された画像を自動で引っ張ってくる動的ギャラリーモード、投稿専用の「添付画像」セクションがインサーターに追加され、メディアライブラリは自動読み込みの無限スクロールに対応する。日々のメディア管理のストレスを確実に減らす改良が詰め込まれている。
管理画面と編集体験の快適化
WordPress 7.1では、編集画面と管理画面の連携を改善する数々の小さな改良も施されている。
管理ツールバーが常に表示される
ブロックエディタやサイトエディタで編集しているときも、管理ツールバーが非表示にならず、画面上部に固定される。これにより、作業中でもサイトの管理メニューに素早くアクセスできる。ツールバーそのものもデザインが整理され、戻るボタンがわかりやすい山形アイコンに変更され、サイトアイコンと丸いプロフィールアバターが表示される。アイコン類も旧来のDashiconsからモダンなSVGに置き換わった。もちろん、集中執筆モードではツールバーが隠れるため、文章だけに集中したい場合も安心だ。
コマンドパレットとアイデンティティ設定の進化
コマンドパレット（Ctrl+K / Command+K）は、最近使ったコマンド、一致する候補、おすすめの3つに分類されるようになった。利用履歴はログインをまたいで保存されるため、よく使う操作に素早くたどり着ける。サイトエディタのサイドバーも、ユーザーが選んだ管理画面のカラースキームを反映するようになり、全体的な統一感が増した。
サイトのタイトル、キャッチフレーズ、ロゴ、サイトアイコンといった基本情報は「デザイン」内の「アイデンティティ」セクションにまとめられ、設定画面とテンプレートを行き来する手間がなくなった。
「あの日何を書いたか」ウィジェットとコメント親変更
ダッシュボードに新たに「On This Day」ウィジェットが追加され、過去の同じ日に公開した記事を表示してくれる。長く続けているブログにとっては、更新のネタを見つけるきっかけになる。また、コメント編集画面では「どのコメントへの返信か」を後から変更できるようになり、誤って違うスレッドにぶら下がったコメントを正しい位置に付け替えられる。対象は同一投稿内に限られるが、コメント管理の柔軟性が向上した。
見送られた機能と開発舞台裏
今回のリリースには含まれなかったが、注目すべき開発項目がいくつかある。
リアルタイム共同編集は次期以降に持ち越し
Googleドキュメントのような複数人同時編集は、WordPress 7.1では搭載が見送られた。Gutenbergプラグイン上では既に動作しており、複数人が同じ投稿を同時に編集できる段階にある。しかし、コアチームは協調編集データの保存方法や、完全な機能を提供するか基盤だけを先にリリースするかといった重要な判断を続けている。コミュニティによるテストも継続中で、時期尚早な投入によるデータ消失リスクを避けるための慎重な判断と見られている。WP Beginnerの記事でも「作業内容を失う共同編集機能ほど最悪なものはない」と指摘されており、この慎重さは妥当だろう。
Unicodeメールアドレス対応も見送り
日本語などの非ラテン文字を含むメールアドレスへの対応も、ベータテスト中に課題が見つかり延期された。互換性とセキュリティの検証をコミュニティプラグインで続けた後、改めてコアへの導入を目指す方針だ。
パフォーマンスと開発者向けの内部改善
投稿エディタは常にiframe内で動作するようになり、管理画面のCSSによる表示崩れを根本的に防ぐ。ただし、旧APIで作られたブロックは影響を受ける可能性があるため、プラグイン開発者はBlock API v3への移行が推奨される。アイコンAPIが公開され、プラグインやテーマが独自のSVGアイコンセットを登録・レンダリングできるようになった。そのほか、デザインシステムの成熟や、外部サービス接続の認証方式拡充など、長期的な安定性と拡張性を見据えた改良も進められている。
この記事のポイント
- ノート機能に@メンションとインラインノートが追加され、チームでのフィードバックが格段に正確になった
- レスポンシブスタイリングとホバー・フォーカス状態の編集がCSS不要で行える
- タブブロックとプレイリストブロックがコアに加わり、コンテンツ表現の幅が広がった
- 画像編集モーダルとブラウザベースの画像処理で、メディアまわりの操作性と安定性が向上
- 管理ツールバーの常時表示やアイデンティティ設定の集約など、管理画面の使い勝手が改善された
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
WordPressサイトがハッキングされた時の難読化PHPコードの見つけ方と完全駆除手順
WordPressサイトのindex.phpなどのコアファイルに難読化された悪意あるPHPコードが埋め込まれ、不審なサイトへリダイレクトされる被害が発生した場合、感染ファイルの完全削除とコアファイルの再インストール、全認証情報の変更を同時に進める必要がある。
この種の改ざんは「goto文」や16進数エンコードした文字列、外部サーバーとの通信機能などを使って巧妙に隠されている。残骸を残さず駆除し、再侵入経路をすべて塞ぐ手順を具体的に追っていく。
なぜWordPressサイトに難読化された悪意あるコードが仕込まれるのか
攻撃者が難読化コードを埋め込む目的は大きく3つある。不正なリダイレクトによるアフィリエイト収益の横取り、サイト訪問者の個人情報やパスワードの窃取（フィッシング）、そしてサイト自体を踏み台にして別のサーバーを攻撃するスパム配信やDDoS攻撃の中継だ。
コードの難読化は、セキュリティプラグインや手動の目視検査をすり抜けるために施される。変数名や関数名をランダムな文字列にし、goto文で処理の流れを複雑に飛ばすことで、実際に何を実行しているのかを読み取りにくくしている。この手のコードは、単独のファイルに留まらず、複数のテーマファイルやアップロードディレクトリに分散して設置されることが多い。
- ● トップページが別ドメインにリダイレクトされる
- ● index.phpの先頭に見慣れない
goto文や16進数文字列のブロックがある - ● 管理画面が重くなり、プラグインの一覧に覚えのない項目が増えている
- ● サイトのURLが正しく表示され、意図しない転送が発生しない
- ● コアファイルが公式のチェックサムと完全一致する
- ● 管理者アカウントやプラグインに不審な追加がない
上記の例は、攻撃者が検索エンジンのボットを判別し、Googleなどのクローラーには元の正常なページを見せ、一般の訪問者だけに不正サイトへ飛ばす「クローキング」という手法の典型的な挙動を示している。
感染したWordPressサイトを手動で完全に駆除する手順
感染が疑われるファイルとディレクトリを優先して検査する
改ざんされたコードは、WordPressのルートディレクトリ直下のindex.phpやwp-config.phpだけでなく、テーマやプラグインのディレクトリ、アップロードディレクトリにも潜む。次の場所を重点的に確認する。
- ルートディレクトリの全
.phpファイル（index.php、wp-load.php、wp-settings.phpなど） /wp-content/themes/配下の全テーマ（特にアクティブなテーマのfunctions.php）/wp-content/plugins/配下の全プラグインファイル/wp-content/mu-plugins/（もし存在すれば）/wp-content/uploads/配下のPHPファイル（本来PHPファイルが存在すべきではないディレクトリ）/wp-includes/配下のコアファイルの改ざん有無（後述のチェックサム検証で判別可能）.htaccessファイル（リダイレクトルールや不正なコードブロックが追記されていないか）
WordPressコアファイルの再インストールとチェックサム検証
wp-content ディレクトリと wp-config.php を除き、WordPressのコアファイルをすべて公式の配布ファイルで上書きするのは安全かつ最も確実な駆除方法だ。管理画面の「ダッシュボード」→「更新」から「再インストール」を実行するか、手動で行う場合は次の手順を踏む。
wp-content ディレクトリと wp-config.php をローカルにバックアップ（退避）するwp-admin と wp-includes を完全に削除し、展開した公式ファイルの同名ディレクトリをアップロード.php ファイル（wp-config.php を除く）を公式ファイルで上書きwp-content と wp-config.php をサーバーに戻し、wp-config.php に手動で追記された不正な行がないか目視確認wp-includes/version.php を確認し、バージョン番号が正しいか検証。その後、プラグイン「WordPress Core Verify」などでチェックサムを検証する管理画面にアクセスできるなら「ダッシュボード」→「更新」の「WordPressを再インストール」ボタンを押すだけで同等の処理が完了する。手動で行う場合も、wp-content と wp-config.php を保護している限り、データ消失の心配はない。
感染源を特定するためにサーバーログとタイムスタンプを照合する
どの脆弱性から侵入されたかを特定するには、改ざんされたファイルのタイムスタンプとサーバーのアクセスログ、エラーログを突き合わせる。ログに「POST /wp-admin/admin-ajax.php」や「POST /xmlrpc.php」への不自然な連続リクエストが記録されていれば、ブルートフォース攻撃やXML-RPCを経由した侵入が疑われる。
ホスティングのコントロールパネルから「Raw Access Logs」や「エラーログ」をダウンロードし、改ざん発生日時の前後を中心に調べる。プラグインやテーマのアップデートを長期間放置していた場合は、脆弱性情報データベース（CVE）で該当バージョンの既知の脆弱性を検索し、侵入経路の仮説を立てる。
適切なファイルパーミッションに設定し直す
ディレクトリは755、ファイルは644を基本とし、wp-config.phpだけは440または400に設定して読み取り権限を厳格にする。特にwp-content/uploads/ 配下にPHPファイルが置かれている場合は、そのディレクトリでPHPの実行を.htaccessで明示的に拒否しておくべきだ。
# .htaccess を wp-content/uploads/ に設置する場合
<FilesMatch "\.(php|php\.)$">
Require all denied
</FilesMatch>プラグインとテーマをクリーンな状態に置き換える
すべてのプラグインとテーマを、公式ディレクトリまたは購入元から再ダウンロードした完全に新しいファイルで上書きする。非公式サイトから入手したプラグインやテーマ、長期間更新が止まっているものは、この機会に削除するか代替に切り替える。
とくに mu-plugins ディレクトリは、手動で設置しない限り通常は存在しない。見慣れないディレクトリ名やPHPファイルがあれば、即座に削除する。
データベース内の不正なコードや管理者アカウントを検査する
phpMyAdminやWP-CLIを使って、wp_options テーブルの「siteurl」や「home」、wp_posts の投稿内容に不審なスクリプトタグやiframeが埋め込まれていないかを調べる。同時に、wp_users テーブルで身に覚えのない管理者アカウントが追加されていないかも必ず確認する。
データベース内の隠し管理者を一括で探すには、WP-CLIで次のコマンドを実行すると早い。
wp user list --role=administrator全認証情報を変更しセキュリティキーを再生成する
駆除作業が完了したら、WordPress管理画面の全ユーザーパスワード、データベースパスワード、SFTP/SSHパスワード、ホスティングのコントロールパネルパスワードをすべて変更する。wp-config.php の「AUTH_KEY」「SECURE_AUTH_KEY」などのセキュリティ用ソルトも、WordPress.orgの公式ソルト生成ツールで新しいものに置き換える。
よくある質問
クリーンなバックアップがない場合、復旧の優先順位はどう決めればよいか
バックアップが存在しない、またはバックアップ自体が感染後のものである場合は、コアファイルの再インストールとプラグイン・テーマの全置き換えを最優先する。データベースの修復はその後で、不正な投稿やユーザーを手動で削除する。サイトのダウンタイムを最小限にするため、メンテナンスモードを有効にして作業するのが安全だ。
無料のプラグインやテーマが感染の原因になることはあるか
公式ディレクトリで配布されている無料プラグインでも、深刻な脆弱性が発見されて更新が滞れば攻撃の糸口になりうる。とくに、公式ディレクトリ以外のサイトから配布されている「nulled（クラック）」版の商用プラグインやテーマは、ほぼ確実にバックドアが仕込まれているため、絶対に使用してはいけない。
データベースを直接編集する際の注意点は何か
phpMyAdminなどでデータベースを直接操作する場合は、必ず事前にデータベース全体のダンプ（エクスポート）を取っておく。wp_options テーブルの「active_plugins」行を誤って削除すると全プラグインが無効化されるため、行の値を直接編集するよりも、WP-CLIのwp optionコマンドを使うほうが安全に操作できる。
cronジョブに疑わしいタスクが仕込まれていないか調べる方法は
WordPressの疑似cron（WP-Cron）はwp_options テーブルの「cron」オプションに格納されている。WP-CLIでwp cron event listを実行すると登録されている全タスクを一覧できる。ホスティング側の本物のcronジョブ（crontab）に不正なエントリが追加されていないかも、ホスティングの管理画面またはSSHで確認する。
攻撃者に検索エンジンのボット判定をすり抜けられた場合の追加対策は
難読化コードがボット判定を行っている場合、駆除後もクローキング用のキャッシュがCDNや検索エンジンに残っている可能性がある。サイト駆除後にGoogleサーチコンソールで「URL検査」→「インデックス登録をリクエスト」を実行し、CDNの全キャッシュをパージする。HTTPヘッダーを改ざんされていないかも、curlコマンドなどで確認しておくべきだ。
この記事のポイント
- 難読化PHPコードは複数ファイルに分散して設置されるため、ルート直下、テーマ、プラグイン、アップロードディレクトリをすべて検査する
- WordPressコアファイルは
wp-contentとwp-config.phpを保護したうえで公式ファイルで完全に上書きする - 改ざんファイルのタイムスタンプとサーバーログを照合し、侵入経路を特定して永続的な対策を講じる
- 全認証情報の変更とソルトの再生成を駆除と同時に行い、再侵入を防ぐ
- クリーンなバックアップがある場合は、全ファイルとデータベースの削除後にバックアップから復元するのが最も確実な方法である
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WordPress 7.0でAIプラグインを作る！Abilities APIとAI Client連携の実際
WordPress 7.0から導入された3つのAI関連コンポーネント、Abilities API、AI Client、そしてMCP Adapterがプラグイン開発の風景を大きく変えようとしている。これらを組み合わせると、AIが画像を解析し、自動で記事を生成するプラグインを驚くほど少ないコードで実装できる。
本記事では、実際に「Photo to Post」というプラグインの構築を通して、各APIの役割と連携方法を具体的に解説する。WordPressの管理画面から画像URLを入力するだけで、AIがビジョンで内容を理解し、下書き投稿を自動生成する流れを追いながら、新しい開発スタイルの全体像をつかんでほしい。
情報源はWordPress Developer Blogのチュートリアル「Build your first AI-Powered WordPress plugin」（2026年7月30日公開）だ。ここで示されるコードと設計思想は、今後のWordPressエコシステムにおけるAI統合の方向性を色濃く反映している。
新しいAI開発基盤の3要素
WordPress 6.9以降で整備されたAbilities API、7.0で正式に取り込まれたAI Client、そしてMCP Adapterは、それぞれ独立して使えるが、組み合わせることで真価を発揮する。まずはこの3つの役割を押さえておく。
Abilities API
Abilities APIは、プラグインが提供する機能を「能力」として登録し、REST APIやAIエージェントなどが統一された方法で発見・実行できる仕組みだ。入力スキーマ、出力スキーマ、パーミッションコールバック、そして実処理を行うコールバックを定義する。これにより、従来のようにエンドポイントを個別に実装する手間が省け、一度登録した能力が管理画面・REST・MCP経由でそのまま利用可能になる。
WordPress AI Client
AI Clientは、プロバイダー（OpenAI、Anthropic、Googleなど）に依存しないPHPライブラリだ。プラグインコードはwp_ai_client_prompt()というフルーエントなビルダーでプロンプトを組み立て、テキスト生成やファイル送信を依頼するだけでよい。プロバイダーの切り替えは管理画面のConnectors API（後述）でAPIキーを設定するだけで済み、コードを一切変更する必要がない。
MCP Adapter
MCP（Model Context Protocol）は、AIエージェント（デスクトップアプリやVS Code拡張など）が外部ツールを呼び出すための標準プロトコルだ。MCP Adapterプラグインをサイトにインストールすると、登録したAbilityがMCPツールとして自動公開される。ClaudeやChatGPTなどのAIクライアントにWordPressの機能を認識させ、「この画像から投稿を作成して」と自然言語で指示するだけで、プラグインの能力が裏側で呼び出される。
同じ能力が3つの入口からシームレスに使える
上の図はAbilities APIの最大のメリットを示している。一度登録すれば、UI、REST、AIエージェントのどこからでも同一の能力を実行できる。エンドポイントごとに別の処理を書く必要はない。
プラグイン「Photo to Post」の仕組み
チュートリアルで構築する「Photo to Post」は、画像URLを入力するとAIが画像の内容を解析し、その説明文をもとにブログ投稿用のタイトルと本文を生成、さらにその画像をアイキャッチに設定した下書き投稿を作成するプラグインだ。
内部では、3つのAbilityが連携している。ここで重要なのは、最後の能力が他の能力を呼び出す「能力の合成（composition）」を実践している点だ。
この合成パターンは、WordPressのフィルターフックやアクションフックで築かれた「小さな機能を組み合わせて大きな機能を作る」という哲学のAI時代バージョンといえる。
実装の流れを追う
ここからはチュートリアルの主要な実装ステップを、要点を絞って解説する。すべてのコードはスタータープラグインをベースにしており、TODOコメントを置き換える形で進められる。AIプロバイダーとしてはOpenAI、Anthropic、Google Geminiなどが利用可能だ。
AIプロバイダーとの接続
WordPress 7.0では、設定メニューに「コネクター」画面が追加された。Connectors APIによって、各プラグインはAPIキーの保存場所を一元管理できる。従来はプラグインごとに設定ページでキーを管理する必要があったが、これで1箇所に集約される。
OpenAI、Anthropic、Googleの公式プロバイダープラグインをインストールし、コネクター画面でAPIキーを登録すれば、あとはAI Clientが自動的にそのプロバイダーを使う。ビジョンモデルを使う場合は、Anthropicのように画像をBase64で送る必要があるが、AI Clientが吸収するためコード上の差異はほとんど生じない。
能力の登録
Abilities APIにおける能力の登録は、wp_register_ability()関数にラベル、説明、入出力スキーマ、パーミッション、コールバックを渡すだけだ。ここで定義したスキーマが、RESTやMCP経由で能力を呼び出す際の「説明書」になる。
チュートリアルでは、describe-image（画像URL → テキスト説明）、generate-post-from-description（説明文 → 投稿タイトルと本文）、create-post-from-photo（画像URL → 下書き投稿）の3つを登録する。
能力を登録したら、wp_abilities_api_initアクションにフックし、RESTで表示するためにメタ情報にshow_in_rest => trueを指定する。これだけでアプリケーションパスワードを使ったcurlで能力の一覧を取得できる。
AI Clientによる画像解析とテキスト生成
最初の能力describe-imageのコールバックでは、wp_ai_client_prompt()でプロンプトを構築し、with_text()とwith_file()で画像のデータURIを渡してgenerate_text()を呼ぶ。戻り値はWP_Errorの可能性があるため、必ずチェックする。
画像はwp_remote_get()で取得しBase64エンコードしたデータURIにして送る。これにより、URLでの画像指定を受け付けないプロバイダーでも動作する。
2つ目の能力generate-post-from-descriptionでは、AIに「画像説明文から魅力的なブログ投稿を生成し、JSONで返す」よう指示する。プロンプトには「markdownコードフェンスで囲まない」と明示するが、AIは非決定論的なため、念のためpreg_replace()でフェンスを除外し、JSON文字列の中からオブジェクトを抽出する防御的なパース処理を入れている。
能力の合成
3つ目の能力create-post-from-photoがこのプラグインの心臓部だ。ここでwp_get_ability()を使って自分自身以外の能力を取得し、execute()で実行する。最初にdescribe-imageを実行して画像説明を取得し、次にその説明を使ってgenerate-post-from-descriptionを実行、最後に得られたタイトルと本文からwp_insert_post()で下書きを作成する。
このように、能力を「LEGOブロック」のように組み合わせられることがAbilities APIの真骨頂だ。各能力は単独でテスト可能であり、後から新しい能力を追加して組み合わせることも容易である。
管理画面の拡張
スタータープラグインに付属するDataFormベースの設定画面を、実際の能力と連携させる。JavaScript側からは@wordpress/abilitiesパッケージのgetAbility()とexecuteAbility()を使い、先ほどPHPで登録したcreate-post-from-photo能力を呼び出す。
スクリプトをモジュールとして読み込み、readyプロミスでAPIが利用可能になるのを待ってから実行する。これで管理画面から画像URLを入力し「投稿を生成」ボタンを押すだけで、一連のAI処理が走り、下書きが作成される。成功すると編集画面へのリンクが表示される。
MCP対応でAIエージェントにも開放
能力の登録時にメタに'mcp' => array( 'public' => true )を追加し、MCP Adapterプラグインを有効化するだけで、その能力がMCPサーバー経由で外部AIエージェントに公開される。
例えばClaudeデスクトップアプリの設定ファイルにWordPressサイトのURLとアプリケーションパスワードを記述すれば、「この写真から投稿を作成して」と話しかけるだけで、create-post-from-photoが自動的に呼ばれる。REST、管理画面、MCPという3つの入口を同じコードで実現できるのは、Abilities APIの設計の妙だ。
実装から見える将来性
WordPressのコアに組み込まれたこれらAIビルディングブロックは、単なる補助機能ではない。プラグイン開発のパラダイムを「単一の機能提供」から「再利用可能な能力の提供と合成」へとシフトさせる可能性を秘めている。
さらに、Connectors APIによるAPIキーの一元管理は、複数プラグイン間の設定のばらつきを解消し、サイト管理者の負担を大きく下げる。開発者は「どのAIモデルを使うか」を気にせず、ビジネスロジックに集中できる環境が整いつつある。
注意点として、AI呼び出しには時間がかかるため、デフォルトのHTTPタイムアウトでは処理が中断される可能性がある。チュートリアルではwp_ai_client_default_request_timeoutフィルタでタイムアウトを120秒に延長する対処が示されている。このような実運用の勘所も押さえておきたい。
プラグイン開発者がこうした基盤を活用し始めれば、WordPressエコシステム全体のAIリテラシーが一気に加速する。非エンジニアでも「写真から投稿を作って」と指示するだけでコンテンツ制作が進む未来は、すぐそこまできている。
この記事のポイント
- WordPress 7.0のAbilities API・AI Client・MCP Adapterにより、AI搭載プラグインを少ないコードで構築できる
- 能力を1回登録すればREST・管理画面・AIエージェントの3経路で同一機能を提供可能
- AI Clientはプロバイダー非依存で、Connectors APIがAPIキー管理を集約
- 能力の合成で「LEGOブロック」のように複雑な自動化を実現
- 実運用ではタイムアウト延長フィルタなど、実装上の注意点も必要
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
Yoast SEOとLearnDashの競合でコースが表示されないときの解決策
LearnDash 5.1.8 と Yoast SEO を同じサイトで動かすと、コースやレッスンの本文領域が空白になり、マークアップも生成されなくなる問題は、Yoast SEO の解析エンジンが LearnDash のコンテンツ出力に干渉しているのが原因だ。Yoast SEO 側の設定で特定の投稿タイプの解析を無効化するか、LearnDash を最新バージョンに更新すれば回避できる。
なぜ Yoast SEO と LearnDash で本文が消えるのか
この不具合は、両プラグインが吐き出す HTML の構造やフックの衝突に起因する。Yoast SEO はコンテンツ解析のために内部で出力バッファを操作し、記事本文の前後に独自の HTML コメントや隠し div を挿入する。一方 LearnDash はコースやレッスンを表示する際に、独自のテンプレート階層とコンテンツフィルターを使って本文を組み立てる。この組み合わせで、Yoast SEO の解析プロセスが LearnDash のメインコンテンツ領域のレンダリングを途中で止めてしまい、結果的に空の div だけが出力される状態になる。
多くのケースでは、PHP のエラーログにもブラウザのコンソールにもエラーは出力されない。この「痕跡のない空白」がトラブルシューティングを難しくしている。問題が表面化するのは、LearnDash が 5.1.8 にアップデートされ、かつ Yoast SEO がバージョン 21 系や 22 系など新しいエンジンを搭載した組み合わせだ。同様の競合は LearnDash のサポートフォーラムでも複数報告されており、開発チームも認識している。
上図は典型的な症状の遷移を表している。次項から実際の修正手順を説明する。
設定変更で競合を解消する 3 つの手順
手順の詳細は以下のとおりだ。この操作に FTP やコード編集は不要で、管理画面の中だけで完結する。
Yoast SEO の検索アピアランスを開く
WordPress 管理画面の左メニューから「Yoast SEO」→「検索アピアランス」へ進む。ここでサイト全体の表示設定と、カスタム投稿タイプごとの解析可否を管理できる。
コンテンツタイプタブで LearnDash 項目を無効化する
「検索アピアランス」画面の上部には「一般」「コンテンツタイプ」「メディア」「タクソノミー」「アーカイブ」などのタブが並んでいる。「コンテンツタイプ」をクリックすると、登録されているすべての投稿タイプが一覧表示される。ここで LearnDash に該当する Courses（sfwd-courses）、Lessons（sfwd-lessons）、Topics（sfwd-topic）、Quizzes（sfwd-quiz） などの項目を探す。各項目の右側にある「Yoast SEO の分析を有効にする」スイッチをすべてオフにする。また、すぐ下の「読みやすさの分析を有効にする」も同様にオフにする。
設定を保存してキャッシュをクリアする
画面下部の「変更を保存」ボタンをクリックする。保存後、サイトキャッシュやサーバーキャッシュを利用している場合は、念のため全キャッシュを削除する。管理画面から再度 LearnDash のコースページにアクセスし、本文が正しく表示されるようになっていれば完了だ。
LearnDash のバージョンアップで根本解決を図る
上記の設定変更は対症療法であり、Yoast SEO の解析機能を一部犠牲にする方法だ。根本的には、LearnDash 側で Yoast SEO との互換性を高めたバージョンがリリースされるのを待ち、アップデートするのが望ましい。実際、LearnDash 5.1.8 のリリース後に同様の競合が複数報告されており、開発チームが修正パッチを準備している可能性が高い。
LearnDash の最新バージョンを確認する
WordPress 管理画面の「ダッシュボード」→「更新」、あるいは「プラグイン」→「インストール済みプラグイン」で LearnDash に更新通知が出ていないかチェックする。5.1.9 以降のバージョンが利用可能であれば、適用してから Yoast SEO の解析を再度有効に戻してみるとよい。なお、更新前に必ずサイト全体のバックアップを取ることは大前提だ。
それでも改善しない場合の追加チェック
まれに、Yoast SEO の「カスタム投稿タイプごとの noindex 設定」が一部影響しているケースもある。先ほどの「検索アピアランス」→「コンテンツタイプ」で、LearnDash の投稿タイプを「検索エンジンに表示する（index）」に設定し直すと、内部のフラグがリセットされて競合が解消したという報告もある。設定をいったんデフォルトに戻してから再度解析をオフにする、という手順を試してみる価値はある。
よくある質問
Yoast SEO を無効化せずに済ませたいが他に方法はあるか
Yoast SEO 全体を無効化するより、上記のとおり LearnDash の投稿タイプだけ解析をオフにする方法が最も手軽で影響が小さい。コースやレッスンの SEO タイトルやメタディスクリプションは Yoast SEO の「検索アピアランス」とは別の編集画面から入力できるため、最低限の SEO 対策は維持できる。
LearnDash 以外の LMS プラグインでも同じことが起きるのか
LifterLMS や LearnPress など他の LMS でも、Yoast SEO の解析がカスタム投稿タイプのテンプレートと干渉する事例は報告されている。いずれも Yoast SEO のコンテンツタイプ設定から解析をオフにすることで対処可能だ。
コンソールやログに何も出ないのはなぜか
PHP の致命的エラーが発生しているわけではなく、Yoast SEO が出力バッファ内でコンテンツの一部を誤ってカットしているだけだからだ。そのため WordPress のエラーログやブラウザの開発者ツールにも痕跡が残らない。
設定を変えても直らない場合はどうすればよいか
テーマや他のプラグインとの三重競合も考えられる。一度すべてのプラグインを停止し、標準テーマ（Twenty Twenty-Five など）に切り替えて LearnDash と Yoast SEO だけを有効にして再現するか確認する。原因を特定したら、該当プラグインのサポートに問い合わせるか、LearnDash のバージョンダウンを検討する。
LearnDash をダウングレードするのは安全か
緊急避難として 5.1.7 以前に戻す方法もあるが、セキュリティや機能面で後退するリスクを伴う。どうしても表示をすぐに復旧させたい場合に限り、バックアップを取ったうえで実施する。長期運用には上記の設定変更と最新版へのアップデート待ちを推奨する。
この記事のポイント
- LearnDash 5.1.8 と Yoast SEO の組み合わせでコース本文が空白になる不具合は、Yoast SEO の解析エンジンが原因
- 管理画面の「Yoast SEO」→「検索アピアランス」→「コンテンツタイプ」で LearnDash の投稿タイプの解析をオフにすれば即座に解消
- PHP ログやコンソールにエラーが出ないため、見落としやすい
- 根本対応は LearnDash の最新バージョンへのアップデートだが、緊急時は上記の設定変更でしのぐ
- 他の LMS プラグインでも同様の競合が起きる可能性があるので、同じ手順で対処可能
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
米国でオンライン販売者保護法案が提出。アカウント停止と在庫保留に30日ルール
2026年7月21日、米国下院に「オンライン販売者の権利章典法（Online Sellers’ Bill of Rights Act of 2026）」が提出された。AmazonやWalmartといった巨大マーケットプレイスで商品を販売する事業者を、突然のアカウント停止や資金凍結から守る内容だ。
この法案が成立すれば、プラットフォーム側は販売者に対してペナルティの理由を詳細に説明し、30日以内に在庫や売上金を解放しなければならなくなる。異議申し立ての手続きも明文化される。越境ECで米国市場に進出している日本の事業者にとっても、大きな追い風となる可能性がある。
法案の概要と背景
なぜマーケットプレイス事業者は保護を必要としているのか
AmazonやWalmartのマーケットプレイスは、小規模事業者でも数百万の顧客にリーチできる強力な販路だ。しかし、ひとたび売上が立ち始めると、そのプラットフォームへの依存度は高まる。突然のアカウント停止や資金凍結は、事業そのものを脅かしかねない。
現状では、規約違反が疑われた販売者に対し、プラットフォームは十分な説明なしにアカウントを停止し、売上金や在庫を長期間にわたって留め置くことがある。違反の詳細が分からないまま数ヶ月に及ぶ保留状態に陥り、事業をたたまざるを得なくなるケースも報告されている。
「オンライン販売者の権利章典法」の中身
下院司法委員会で審議中のこの法案（H.R. 9799）は、マーケットプレイスが販売者に対してとる執行措置に、連邦レベルでの手続きを義務付けるものだ。偽造品や不正販売の排除は引き続き認めつつ、在庫保留や支払い停止、規約変更、調査、異議申し立てに一連の基準を設ける。
主な規定
法案は、マーケットプレイスの執行措置に対し以下の保護を提供する。いずれも「30日」という期限が大きな軸となっている。
在庫保留の制限
偽造品の疑いで在庫が倉庫に留め置かれる場合、これまでは数ヶ月単位で放置されることがあった。法案では、在庫保留と制限の期間を暦日30日以内に制限する。30日を超えて保留を続けるには、当該商品が明らかに不正であることをプラットフォーム側が証明しなければならない。
支払い保留の制限
売上金の凍結についても同様に、30日間の上限が設けられる。それを超えて資金を保持するには、違法な取引であったことを証拠によって示す必要がある。単なる疑いだけでは長期保留は認められなくなる。
ゲート製品への対応
ある商品が一度はフルフィルメントネットワークに受け入れられた後、新たに販売制限がかけられる「ゲート製品」に関する規定もある。プラットフォームが製品カテゴリに新たな制限を課す場合、販売者に対して少なくとも30日間の猶予を与え、残った在庫を販売するか、送料負担なしで返却する権利を保証する。
事前通知義務
商品掲載の適格条件やコンプライアンス要件、手数料などに実質的な変更がある場合、プラットフォームは30日前までに書面で通知しなければならない。この猶予があれば、販売者は梱包の変更や書類の準備、価格改定、在庫の移動といった対策をとれる。
異議申し立て手続きの明確化
アカウント停止やリスティングの差し止めに際して、プラットフォームは疑われる違反内容を個別具体的に通知する義務を負う。どのポリシーに違反したのか、関連する事実や資料は何か、科されるペナルティの内容、そして異議申し立ての方法と解決までの見込みスケジュールを提示しなければならない。テンプレートの定型文だけでは要件を満たさない。
上図は現状と法案が求めるプロセスの違いを概念化したものだ。実際の条文では、虚偽の申告や偽造品の販売には厳しい対応が続けられる一方、正当な事業者には適正な手続きが保証される枠組みになる。
販売者にとってのメリット
この法案の本質は、プラットフォームによる一方的な執行から「商業デュープロセス」を確立することにある。詐欺的な出品や危険な商品を排除する権限は維持しながら、そのプロセスに説明責任と異議申し立ての機会を組み込む。
プラットフォームの説明責任強化
個別具体的な通知義務により、販売者は「なぜ停止されたのか」を理解し、問題を速やかに是正できるようになる。テンプレートの返答ではなく、事実と根拠に基づいた対応が求められるため、曖昧な理由でビジネスが断たれるリスクが減る。
ビジネス継続性の確保
在庫や支払いの30日ルール、ゲート製品への猶予期間は、キャッシュフローと在庫回転の予測可能性を高める。突然の政策変更で売れなくなった商品があっても、少なくとも1ヶ月の対応期間が与えられるため、損失を最小限に抑えられる。
法的効果と執行
法案が成立した場合、FTC（連邦取引委員会）は施行から180日以内に規則を制定する。その規則違反は、連邦取引委員会法上の不公正な競争方法として扱われる。さらに、州の司法長官も居住者を代表して民事訴訟を起こす権限を持つ。
最も強力なのは、被害を受けた販売者が連邦裁判所に直接訴えを起こせることだ。プラットフォームの利用規約に仲裁条項があったとしても、この法律に基づく訴訟は妨げられない。勝訴した販売者は、実際の損害額の3倍の賠償と、裁判費用・相当額の弁護士費用を請求できる。単なる通知義務にとどまらず、強力な抑止力を持つ設計になっている。
法案の不確実性と課題
一方で、この法案には適用範囲の曖昧さという弱点も指摘されている。保護の対象となる「第三者の販売者」は「支配的プラットフォーム」上で事業を行う企業と定義されているが、支配性を判断する売上高や取引量、ユーザー数、市場シェアといった具体的な基準は明記されていない。
AmazonとWalmartが主な標的であることは明白だが、eBayやEtsy、Poshmarkといった特化型マーケットプレイスにまで一律に適用されるかは不透明だ。FTCの規則制定で一部は明確化される可能性があるが、数値基準がないことは法廷闘争の引き金にもなりうる。
日本から海外マーケットプレイスを利用する事業者への影響
Amazon.comやWalmart.comで越境ECを行っている日本の事業者にとって、この法案が成立すれば大きな後ろ盾となる。米国内の法律である以上、適用対象はこれらのプラットフォームに限られるが、日本国内で販売する場合と異なり、海外の巨大プラットフォーム相手に身を守る手段が大幅に強化されるからだ。
また、こうした立法の動きはグローバルな潮流になる可能性もある。すでにEUではプラットフォームと販売者の関係を規律するルールが整備されつつある。日本の事業者としても、海外販路を拡大する際のリスク判断にこの法案の行方を加味しておく価値は高い。
この記事のポイント
- 米国下院で「オンライン販売者の権利章典法」が提出され、審議中である
- アカウント停止時の在庫・支払い保留は30日が上限となり、理由の個別通知と異議申し立て手続きが義務化される
- ゲート製品への事後規制には30日の販売猶予か無償返却の機会が与えられる
- 販売者は連邦裁判所に直接訴訟を起こせ、勝利すれば3倍賠償を得られる
- 日本の越境EC事業者にも、Amazon.comなどでの販売リスクを減らす追い風となる
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
決済手数料プラグイン更新後に商品ページがエラーで崩れる場合の対処法
WooCommerce サイトで Payment Gateway Based Fees and Discounts といった決済手数料プラグインをバージョン 3.2.0 に更新した直後から、商品ページを開くと「このサイトで重大なエラーが発生しました」と表示され、レイアウトが中央に縮まってしまう症状が起きた。このケースはプラグイン内部のクラス読み込み不具合が原因であり、該当プラグインを安全な旧バージョンにロールバックすれば即座に解決する。
なぜプラグイン更新後に商品ページが重大エラーになるのか
エラーログには「Uncaught Error: Class “TycheSoftwares\PaymentGatewayFees\Lite\WC_Tax” not found」というメッセージが記録されている。これは、プラグインのアップデートで参照している PHP クラスが適切に読み込まれていないことを示す。WooCommerce 本体やほかのプラグインとの同時アップデートが引き金になることもあるが、切り分けテストで当該プラグインを無効化すると正常に戻るなら、原因はそのプラグインの新バージョンにあると断定できる。
エラーを安全に切り分ける手順
問題が発生したら、むやみに設定を触らず、まず以下の手順で原因を特定する。同時にアップデートしたプラグインが複数ある場合も、この順序で一つずつ無効化していくと確実だ。
上記の操作は管理画面にアクセスできない場合でも使える。プラグインを無効化するだけなら、PHP の動作を変更しないため、エラーが解消された後に管理画面から安全にアンインストールや再インストールが可能だ。
旧バージョンにロールバックしてサイトを元に戻す
原因が特定できたら、問題のない旧バージョンに置き換える。ロールバックの方法は大きく分けて3つある。状況に応じて選ぶとよい。
プラグイン「WP Rollback」を使って管理画面から戻す
WordPress 管理画面にアクセスできる状態なら、無料プラグインの WP Rollback をインストールすると、プラグイン一覧から直接任意の旧バージョンに切り替えられる。操作は数クリックで完了し、面倒なファイル操作が不要なため最も簡単だ。ロールバック後は念のためキャッシュを全削除し、エラーが出なくなったことを確認する。
公式 ZIP ファイルを手動でアップロードする
管理画面に入れない場合は、WordPress 公式プラグインディレクトリの旧バージョン ZIP を直接ダウンロードし、FTP やサーバーのファイルマネージャーで上書きする。対象プラグインの開発者ページにアクセスし、右下の「Advanced View（詳細を表示）」から目的のバージョンを選んで ZIP を取得する。その後、/wp-content/plugins/ ディレクトリに解凍して配置すれば完了だ。このとき、既存のプラグインフォルダは必ずリネームしてから新しく解凍するか、上書きする前にバックアップを取っておく。
WP-CLI でコマンド操作する
サーバーに SSH 接続できる上級者向けの方法だ。WP-CLI が使える環境であれば、以下のようなコマンドでプラグインをダウングレードできる。公式 ZIP の URL を指定してインストールし、有効化するだけだ。
wp plugin install https://downloads.wordpress.org/plugin/checkout-fees-for-woocommerce.3.1.0.zip --activateロールバック後は自動更新を一時的に停止し、修正版がリリースされるまでバージョンを固定することを推奨する。 具体的には、プラグイン編集画面か wp-config.php で該当プラグインの自動更新フィルターを無効化するか、プラグイン一覧から手動更新に切り替えておく。
開発者が修正するまでに取るべき応急処置
問題のバージョンに致命的な不具合がある場合、修正版がリリースされるまでは旧バージョンでの運用が必須だ。その間、以下の点に気をつける。
- サポートフォーラムや公式リポジトリを定期チェックする。 同じ不具合が報告され、ベータ版や修正版が先に出ることがある。
- ステージング環境で新バージョンを検証する。 いきなり本番環境に適用せず、テストサイトで動作確認してから更新する習慣をつける。
- WooCommerce 本体と関連プラグインの同時更新を避ける。 依存関係の競合を避けるため、数日ずらして様子を見ながら更新するのが安全だ。
よくある質問
エラーログの確認方法がわからない
サーバーコントロールパネルのエラーログ機能を使うか、wp-config.php に define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); を追記すると、/wp-content/debug.log にエラーが記録される。本番環境ではデバッグ表示を無効にしておき、ログだけ有効にする設定が推奨される。
ロールバック中に「インストールに失敗しました」と出る
多くの場合、既存のプラグインフォルダが残っていることが原因だ。FTP で対象フォルダを削除またはリネームし、空の状態にしてから ZIP を解凍するか、WP Rollback が自動で処理するのを待つ。
プラグインを無効化すると手数料計算が狂わないか
決済手数料を動的に追加しているサイトでは、プラグインを無効化すると手数料が適用されなくなる。ロールバックが完了するまでの間は手数料の表示が消えることを顧客に通知するか、保守モードを有効にして注文自体を一時停止する判断も必要だ。
今後同じようなアップデート事故を防ぐには
WooCommerce サイトでは、本番適用前にステージング環境でプラグインの更新テストを行うのが最も確実な防止策だ。また、更新前に必ずサイト全体のバックアップを取得し、自動更新設定を重要なプラグインでは「手動」に切り替えておくことも有効である。
この記事のポイント
- Payment Gateway Based Fees and Discounts 3.2.0 の更新後、クラス未定義エラーで商品ページが崩れる
- 原因はプラグイン内部のクラス読み込み不具合で、同プラグインを旧バージョン（3.1.0）に戻せば直る
- ロールバックには WP Rollback プラグインか、公式 ZIP を手動アップロードする方法が使える
- 修正版が配布されるまでは自動更新を停止し、本番環境での同時更新を避ける
- 更新前のステージング環境テストとサイト全体のバックアップが最も有効な予防策
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
Nuxt 4.5.1／3.21.10セキュリティパッチ公開。サーバーRCEや認証バイパスを修正
Nuxt開発チームは2026年7月27日、メジャーバージョン4系の4.5.1と3系の3.21.10をセキュリティパッチとして公開した。今回のリリースでは、深刻度が高いサーバーサイドのリモートコード実行（RCE）や認証バイパスなど、6つの脆弱性が修正されている。
Nuxtを利用しているプロジェクトはただちにアップグレードすることが推奨される。開発環境限定の脆弱性も含まれており、本番環境で影響を受けない場合でも、安全のため最新版への更新が求められる。
修正内容には、特定条件でのサーバー上での任意コード実行や、大文字を含むルートルールの認証バイパスなどが含まれている。また、キャッシュページで他ユーザーのデータが漏洩する問題（4.xのみ）や、DevTools経由のRCEも併せて修正された。
セキュリティパッチの全体像と影響範囲
今回のセキュリティリリースは、Nuxt 4.xと3.xの両系統にまたがる。4.xユーザーは4.5.1へ、3.xユーザーは3.21.10へアップグレードする必要がある。修正対象の脆弱性は、サーバーサイドRCE（深刻度：高）、未承認コンポーネントの生成（中）、ルートルール認証バイパス（高）、DoS（高）、キャッシュ時のクロスユーザー情報漏洩（高、4.xのみ）、開発サーバーのパス開示（低）、DevToolsのRCE（緊急、開発時限定）の7件だ。
いずれの脆弱性も、GitHubのアドバイザリを通じて報告され、複数のセキュリティ研究者の協力によって特定された。NuxtチームはVercel、Netlify、Cloudflareの各社とも協力し、一部の脆弱性については公開前に緩和策を展開している。
サーバーサイドを狙う深刻な脆弱性
サーバーアイランドProps経由のRCE
この脆弱性（CVE-2026-53721）は、vue.runtimeCompilerが有効になっている場合に発動する。デフォルトでは無効化されているため、大半のプロジェクトは影響を受けない。しかし、該当する設定では、サーバーコンポーネントやアイランドのPropsにtemplateキーを注入されることで、サーバー（Nitro）上で任意のコードが実行される可能性があった。
攻撃が成立するには、<component :is>やresolveDynamicComponent、h()といったVueの動的コンポーネント解決にPropsが渡る必要がある。@nuxt/uiが提供するreka-uiのasプロパティのようなパターンも該当する。実務上は、動的コンポーネントとサーバーアイランドを併用する設計で注意が必要だ。
このデモは、vue.runtimeCompilerが有効な場合の攻撃の流れを概念的に示している。実際には、同設定をオフにしているプロジェクトは影響を受けず、また4.5.1／3.21.10で根本的な修正が行われている。
未承認コンポーネントのインスタンス化
RCEほどではないが、こちらはvue.runtimeCompilerが無効でも影響を受ける。サーバーアイランドが宣言していないPropsを転用して、asプロパティに攻撃者が任意のHTML要素名やコンポーネント名を渡すことで、意図しない要素を生成できてしまう。
たとえば{ "as": "iframe" }のようなデータを渡されると、iframe要素が生成される可能性がある。コード実行には至らないが、予期しないDOM構造を作られてしまう点は脅威だ。Propsの宣言やinheritAttrs: falseで防ぐこともできるが、フレームワーク側での修正により、今後はこうした不正なインスタンス化はブロックされる。
認証バイパスとリソース消費攻撃
ルートルールの認証バイパス（大文字・小文字の不一致）
NuxtではrouteRulesにappMiddlewareを指定することで認証ゲートを設けられる。しかし、ルールキーに大文字が含まれる場合、リクエストのパスとケースインセンシティブにマッチせず、認証ミドルウェアがスキップされる問題があった。
これは4.4.7／3.21.7で修正された問題（CVE-2026-51354）に起因するリグレッションだ。当時の修正が逆にこの不具合を生んだ。具体的には、pages/Admin.vueのようなファイルやrouteRules: { '/Admin': ... }のような明示的なキーで、/adminへのアクセスがルールを迂回してしまう。
今回のパッチでは、ルートルールのマッチングがVue Routerと同様にケースインセンシティブに統一された。これにより大文字小文字の混在があっても、正しくミドルウェアが適用される。もし意図的にケースセンシティブなマッチングを利用していた場合は、router.options.sensitive: trueの設定が必要だ。
この図は、/Adminというルールに対して/adminがアクセスされるケースを示している。修正前はルールが適用されなかったが、4.5.1／3.21.10以降はケースを問わず認証ミドルウェアが動く。
サーバーコンポーネントへのDoS攻撃
サーバーコンポーネントやアイランドのエンドポイント（/__nuxt_island）に対して、v-forに巨大なPropsを渡すなどしてサーバーをクラッシュさせるDoS攻撃が可能だった。また、巨大なリクエストボディの解析でCPUを浪費させる問題も確認されている。どちらも認証不要で実行でき、サービス停止につながる。
修正では、こうしたPropの展開やリクエストのバリデーションが強化され、攻撃が成立しないようになった。
キャッシュページにおけるクロスユーザー情報漏洩（4.x限定）
Nuxt 4.x（4.4.0以上）で、cache、swr、isrのルートルールを認証付きページに適用している場合、キャッシュされた_payload.jsonが別のユーザーに提供される可能性があった。HTML自体は正しくユーザーごとに分離されていたが、ペイロードデータのキャッシュが意図せず共有されていたのだ。
この脆弱性は3.xには存在しない。修正バージョンにアップグレードしても、既にキャッシュされている不正なペイロードは削除されないため、別途キャッシュのパージ（CDNやブラウザキャッシュのクリア）が必要になる。
開発環境限定の脆弱性
Nuxt DevToolsのリモートコード実行（緊急）
この問題（GHSA-279x-mwfv-vcqv）は、nuxt devを実行している開発マシンに影響する。DevToolsが有効な状態で、Vite HMRソケット上で認証不要のRPCメソッドが露出しており、攻撃者が任意のコマンドを実行できる可能性があった。攻撃経路としては、同一ホスト上の別プロセス、--hostオプション使用時のLAN内の他端末、あるいは悪意あるWebサイトへの訪問が考えられる。
この脆弱性は@nuxt/devtools@3.3.1で修正されており、Nuxt本体のアップグレードに加えてロックファイルからこのバージョンが解決されることを確認する必要がある。
本番ビルドではDevToolsとHMR自体が含まれないため、この問題が本番環境に影響することは決してない。しかし、開発者が攻撃を受けるとソースコード漏洩やシステム侵害につながるため、早急な更新が推奨される。
開発サーバーのパス開示（低）
nuxi dev --hostでネットワークインターフェースにバインドしている場合に限り、Chrome DevToolsのワークスペースエンドポイントを経由して、プロジェクトの絶対パスとワークスペースUUIDがLAN上のクライアントに漏洩する問題があった。信頼できないネットワークで開発サーバーを公開している環境は注意が必要だ。
アップグレード手順と注意点
アップグレードは以下のコマンドで実行できる。ロックファイルの更新とともに、依存解決を最新化するために--dedupeオプションを付与する。
npx nuxt upgrade --dedupeこれにより、@nuxt/devtoolsも最新の3.3.1に引き上げられ、DevToolsのRCEも同時に修正される。
キャッシュ関連の脆弱性が悪用されていた場合に備え、本番環境のCDNキャッシュやブラウザキャッシュをクリアすることも推奨する。アップグレードだけでは過去にキャッシュされた不正なペイロードは消えないからだ。
また、ケースセンシティブなルートルールを意図的に使っている場合は、nuxt.config.tsでrouter.options.sensitiveを明示的に設定する必要がある点に注意してほしい。
謝辞と安全な報告体制
これらの脆弱性は、GitHubのプライベートアドバイザリやVercel OSS Bug Bountyプログラムを通じて報告された。Nuxtチームは、問題を責任をもって開示した以下のセキュリティ研究者に謝意を表している。
- Pig-Tail
- sec-reex
- DavidCarliez
- manop55555
- dinhvaren
- quantumshiro
- Saku0512
- TazmiDev
また、サーバーRCEについては、Vercel、Netlify、Cloudflareの各社と連携し、公開前に緩和策を配備する準備が整えられた。
Nuxtのセキュリティ脆弱性を発見した場合は、GitHub Security Advisoryから非公開で報告するか、security@nuxtjs.orgへメールすることが推奨されている。
この記事のポイント
- Nuxt 4.5.1と3.21.10は緊急度の高いセキュリティパッチであり、即時アップグレードが推奨
- サーバーアイランド経由のRCEは特定条件でのみ発生するが、影響度は高い
- ルートルールの大文字・小文字の不一致による認証バイパスは、4.4.7/3.21.7の修正に起因するリグレッション
- キャッシュ時のクロスユーザー情報漏洩は4.xにのみ存在し、キャッシュの手動クリアが必要
- DevToolsのRCEは開発環境限定だが、開発端末の侵害を防ぐためロックファイルの更新を忘れずに
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験