月別アーカイブ 2026年6月27日

W3 Total Cache 2.10.0 更新後に動的コンテンツが表示されない時の直し方

W3 Total Cache 2.10.0 更新後に動的コンテンツが表示されない時の直し方

W3 Total Cache 2.10.0 へのアップデート後、動的コンテンツが表示されず「W3TC dynamic mfunc tag refused: missing call:slug + hmac envelope.」と表示される場合、根本原因はバージョン 2.10.0 で導入された HMAC 署名検証の仕様変更である。プラグインを 2.9.x 系に戻すか、動的ブロックの呼び出しコードに正しい slug 属性と HMAC 署名を付与すれば直る。

どんな症状が発生しているのか

どんな症状が発生しているのか

W3 Total Cache(以下 W3TC)のページキャッシュを有効にしたサイトを更新したあと、AdRotate Pro など mfunc タグを使って動的コンテンツを部分キャッシュしていた箇所が、エラーメッセージに置き換わる。日本語環境では英文のまま「W3TC dynamic mfunc tag refused: missing call:slug + hmac envelope.」という文言が表示されるケースが多い。この文言は「mfunc 呼び出しが拒否された。slug と HMAC エンベロープが不足している」という意味だ。

対象になるのは、W3TC のページキャッシュ機能と「後期キャッシング(Late Caching)」や「動的 mfunc ブロック」を組み合わせて使っていたサイトである。具体的には、固定ページ全体をキャッシュしつつ、広告ブロックやログイン状態表示などの一部だけを非キャッシュで差し込んでいた構成だ。更新前は問題なく動いていたのに、2.10.0 にした途端に該当箇所だけエラー文言に化ける。

なぜ W3TC 2.10.0 でエラーが起きるのか

なぜ W3TC 2.10.0 でエラーが起きるのか

W3TC 2.10.0 では、動的 mfunc タグのセキュリティ強化として HMAC(ハッシュベースのメッセージ認証コード)による署名検証が必須になった。これは不正な動的コードの注入を防ぐための仕組みだが、従来の呼び出しコードには slug 属性と HMAC 署名が含まれていなかったため、検証に失敗し、一律で拒否されるようになった。

W3TC の動的 mfunc ブロックは、PHP 関数をページキャッシュ内に埋め込んでおき、キャッシュから配信される直前に実行する仕組みだ。これまでは単純なコールバック名だけで動作していたが、2.10.0 からは「どのスラッグから呼び出されたか」と「正当な呼び出し元であることを証明する HMAC 署名」のセットがなければ mfunc タグが無効化される。

この仕様変更は W3TC 本体のセキュリティアップデートであるため、AdRotate Pro など W3TC 互換モードを持つ他プラグインの側が新しい署名形式に対応していないと、もれなくエラーになる。結果的に、更新後は互換モードで動的コンテンツを提供しているほとんどすべてのサイトで同じ問題が発生している。

W3TC 2.10.0 の動的 mfunc 呼び出し変化
Before
<!– mfunc callback_name –>
slug・HMAC なし → 拒否される
After
<!– mfunc callback_slug –><!– mfunc hmac_signature –><!– /mfunc –>
slug・HMAC 付き → 正常動作
エラー状態(旧形式)  2.10.0 の要求仕様

すぐにサイトを元に戻す応急処置

すぐにサイトを元に戻す応急処置

W3 Total Cache を 2.9.x 系にダウングレードする

最も短時間で確実に直す方法は、W3TC を 2.10.0 より前のバージョンに戻すことだ。ダウングレード手順は以下のとおり。

  1. 管理画面の「プラグイン」から W3 Total Cache を停止する
  2. 「プラグイン」→「プラグインの追加」→「プラグインのアップロード」を使うか、FTP で古いバージョンの ZIP を展開して上書きする
  3. プラグインを再有効化し、すべてのキャッシュを削除する

古いバージョンの ZIP ファイルは WordPress.org のプラグインページにある「以前のバージョン」セクションから入手できる。バージョン 2.9.8 や 2.9.9 であれば HMAC 署名検証が存在しないため、従来どおり動的 mfunc タグが動作する。

ダウングレードしたあとは、W3TC の自動更新を一時的に停止することを推奨する。管理画面の「プラグイン」で個別に自動更新をオフにするか、wp-config.php に define( 'AUTOMATIC_UPDATER_DISABLED', true ); を追加してサイト全体の自動更新を止めておけば、意図しない再アップデートを防げる。

他プラグインの W3TC 互換モードを一時的に無効化する

もし AdRotate Pro など、W3TC 互換モードを個別にオン・オフできるプラグインを使っているなら、当該プラグインの設定で互換モードをオフにする手もある。ただしこの場合、ページキャッシュの影響で広告がローテーションしなくなったり、動的コンテンツが静的になってしまったりする副作用がある。あくまで「エラー表示を消す」ための一時的な回避策と位置づけるのが安全だ。

2.10.0 を使い続ける場合の恒久対応

2.10.0 を使い続ける場合の恒久対応

W3TC 2.10.0 のセキュリティ修正を活かしたまま動的コンテンツを動作させるには、呼び出しコードに正しい slug と HMAC 署名を付与する必要がある。この修正は、動的 mfunc タグを生成している側(多くの場合は広告管理プラグインや自作のテーマ関数)に手を入れることになる。

W3TC の HMAC 署名の仕組みを理解する

mfunc タグはページキャッシュの HTML 内に PHP コード片を残し、キャッシュ配信時に W3TC がそれを検出して実行する。2.10.0 ではこのとき、呼び出しパラメータとして「call:slug」と「hmac」の両方がエンベロープに含まれていなければならない。slug は処理を一意に識別する任意の文字列、hmac は W3TC 内部で生成される署名ハッシュだ。

生成ルールは公開されているが、実際には W3TC が提供する API 関数を使って動的ブロックを登録するのが現実的だ。自作テーマであれば w3tc_fragmentcache_register フィルターを使い、コールバックと slug を W3TC に登録すれば、あとは W3TC 側が自動で HMAC 署名を計算してくれる。

AdRotate Pro での対応状況を確認する

AdRotate Pro は W3TC 互換モードを有効にしている場合、内部的に mfunc タグを生成している。今回のエラーは、AdRotate Pro が生成する mfunc タグが 2.10.0 の新形式に対応していないために発生している。AdRotate Pro の開発元がこの問題に対応したアップデートをリリースするまでは、互換モードの使用が難しい。

AdRotate Pro の管理画面にある「W3 Total Caching compatibility」設定をオフにし、代わりに JavaScript による非同期広告読み込み(AdRotate のダイナミックモード)を使うか、広告ブロックを iframe で埋め込む形に切り替えると、ページキャッシュ機構に依存せず動的広告を配信できる。

自作テーマで動的ブロックを登録し直す

テーマの functions.php などで自作の動的コンテンツを mfunc タグで埋め込んでいた場合は、W3TC のフラグメントキャッシュ API を使った正式な登録に切り替える。基本的な流れは次のとおりだ。

  1. w3tc_fragmentcache_register フィルターで、slug とコールバック関数のペアを W3TC に登録する
  2. テンプレート内では w3tc_fragmentcache_output 関数を使い、slug を指定して動的出力を行う
  3. W3TC が自動で HMAC 署名を計算し、mfunc タグとしてページキャッシュに埋め込む

この方法なら、W3TC のバージョンが上がっても署名方式の変更に W3TC 本体側が追随するため、サイト側のコードを再度修正する必要がなくなる。フラグメントキャッシュ API の具体的な記述例は W3TC の公式ドキュメントに掲載されている。

Late Caching 設定の確認と調整

W3TC の pgcache.late_caching 設定(後期キャッシング)が有効かどうかも、動作に影響を与える要素のひとつだ。この設定が true の場合、ページ生成の最終段階で mfunc タグを処理するため、プラグイン間の競合が減る傾向がある。すでに true でもエラーが出ている場合は今回の本質的な原因ではないが、念のため設定値を確認しておく。

wp-content 内の w3tc-config/master.php を直接確認するか、管理画面の「パフォーマンス」→「一般設定」からエクスポートした設定ファイルで pgcache.late_caching の値を確認できる。false であれば true に変更し、キャッシュを全削除してから表示を再確認する。

再発を防ぐための注意点

再発を防ぐための注意点

W3TC のような深くサイト機構に組み込まれるプラグインをメジャーバージョンアップする前には、必ずステージング環境で検証する習慣をつける。とくに mfunc やフラグメントキャッシュといった、通常のキャッシュとは異なる高度な機能を使っている場合は、本番適用前に動的コンテンツの全パターンをテストする必要がある。

また、W3TC の設定をエクスポートしてバックアップしておけば、問題が起きたときに設定ごと以前のバージョンに戻せる。管理画面「パフォーマンス」→「一般設定」の下部にある「設定のダウンロード」ボタンで、JSON 形式の設定ファイルを定期的に保存しておくとよい。

更新前の準備と検証フロー
STEP 1 W3TC 設定を JSON でダウンロードしてバックアップ
STEP 2 ステージング環境で W3TC を更新し動作確認
STEP 3 動的コンテンツ全種をテストし問題なければ本番に適用
STEP 4 本番反映後すぐにキャッシュ全削除して再チェック

よくある質問

「W3TC dynamic mfunc tag refused」はサイト全体が真っ白になるのか

サイト全体が真っ白になるわけではない。ページの大部分は正常にキャッシュ配信されるが、mfunc タグで差し込まれていた動的コンテンツの部分だけがエラー文言に置き換わる。レイアウトが崩れることはあるが、PHP 致命的エラーによる白画面とは異なる。

キャッシュを削除しても直らないのはなぜか

キャッシュ削除はあくまで「現在保存されているキャッシュファイルを消す」行為であり、mfunc タグの生成コード自体を修正するものではない。新しいキャッシュが生成されるときに、同じく新形式に対応していない mfunc タグが再度埋め込まれるため、キャッシュ削除だけでは根本解決にならない。

W3TC 無料版でも同じ問題は起きるのか

起きる。HMAC 署名検証は W3TC のコア機能の一部として Pro 版・無料版の両方に実装されている。フラグメントキャッシュや mfunc タグを使っているサイトは、Pro 版かどうかに関係なく影響を受ける。

このエラーを放置してもサイトには大きな問題はないか

動的コンテンツが表示されないという機能面の問題に加え、エラー文言が来訪者にそのまま見える状態はサイトの信頼性を損なう。また広告が表示されなければ収益にも直結するため、実質的には早期解決が必要な重大トラブルに分類される。

他に W3TC 2.10.0 で影響を受けるプラグインはあるか

AdRotate Pro 以外にも、W3TC 互換モードで動的コンテンツを埋め込む仕組みを持つプラグイン全般が影響を受ける可能性がある。具体的には、動的ウィジェットやパーソナライズ表示を行うキャッシュ対応プラグインが該当する。該当プラグインの更新情報を注視し、開発元が W3TC 2.10.0 対応を表明するまではアップデートを保留するのが安全だ。

この記事のポイント

  • W3TC 2.10.0 の HMAC 署名検証強化で mfunc タグが拒否される
  • ダウングレードで即時解決するがセキュリティ面は旧版に戻る
  • 互換プラグイン側の対応アップデートを待つか公式 API で再実装する
  • キャッシュ削除だけでは再発するため mfunc コード自体の修正が必要
  • メジャーアップデート前のステージング検証と設定バックアップが再発防止の鍵
Googleが6月スパムアップデート公開、AI応答の操作もスパム対象に

Googleが6月スパムアップデート公開、AI応答の操作もスパム対象に

Googleは2026年6月24日、新しいスパムアップデートの展開を開始した。今回のアップデートでは、生成AIの応答を意図的に操作しようとする行為もスパムポリシー違反とみなされることが明確化された。

同時期に、サーチコンソールのAIレポートにおけるインプレッションの数え方について新たな情報が公開された。また、Advanced Web Rankingの調査ではデスクトップのCTRが上昇する一方、モバイルのトップポジションでクリック率が低下していることが判明。Similarwebのレポートからは、AIの推奨がブランド検索を経由してサイト訪問につながる構図が浮かび上がった。

この記事では、これらの動きを一つひとつ整理し、今後のSEO戦略にどう活かすかの視点を提供する。

AI応答の操作行為もスパムポリシーの対象に

AI応答の操作行為もスパムポリシーの対象に

6月24日より展開が始まったスパムアップデートは、従来のリンクスパムやキーワードスタッフィングのような旧来型の不正だけでなく、AI OverviewsやAI Modeといった生成AI検索機能に対する操作行為にも範囲を拡大した。

Googleは2026年5月にスパムポリシーを改定し、生成AIの回答に表示される引用やリンクを不正に購入する行為、情報を書き換える行為がスパムに該当すると明示していた。今回のアップデートはその方針に沿ったアルゴリズムの強化にあたる。

ランキング変動への向き合い方

スパムアップデートは数日かけて完全に適用されるため、ランキングの上下が一過性のものかそうでないかを見極める必要がある。突然順位が下がったとしても、それだけでコンテンツが「質の低いスパム」と判定されたわけではない。

SEOコンサルタントのShushrita M.氏は、変動が起きた際にはまず影響を受けたページタイプやクエリ、ディレクトリを特定し、一貫したパターンを見つけることが回復への第一歩だと指摘している。パニックに陥らず、データに基づいた診断を進める姿勢が求められる。

AIインプレッションはリンクの表示回数、クリックデータはまだない

AIインプレッションはリンクの表示回数、クリックデータはまだない

サーチコンソールの生成AIレポートで示されるインプレッションは、AI OverviewsやAI Modeの中で自社ページへのリンクが表示された回数を指す。ただし、回答内で折りたたまれているリンクは、ユーザーが開かない限りカウントされない仕組みである。

Googleのサーチ アドボケートJohn Mueller氏が明らかにしたところによると、現時点ではこのレポートにクリック数は含まれておらず、純粋に表示機会の指標として扱う必要がある。AI回答の中で自社コンテンツが参照されていても、必ずしもユーザーがクリックするとは限らない点を考慮しなければならない。

低い数値が問題とは限らない

折りたたまれたリンクのインプレッションが少ないからといって、コンテンツがAIに無視されているわけではない。ユーザーが積極的に展開しなければカウントされないため、実際の露出機会よりも数字が小さく見える可能性がある。インプレッション数はあくまで最低限の目安として捉え、他の指標と組み合わせて評価することが重要だ。

デスクトップCTRが上昇、モバイルはトップで減速

デスクトップCTRが上昇、モバイルはトップで減速

Advanced Web Rankingが公開した2026年第1四半期のベンチマークによると、デスクトップ検索のクリック率は上昇傾向にある一方、モバイル検索では1位のCTRが約2.2ポイント低下した。デスクトップの伸びは3位以下のポジションで顕著に見られた。

これは単純な「復調」ではない。モバイルの軟調が続いているなかでのデスクトップの一時的な上昇であり、両者を合算した数値だけを見ると実態を見誤る恐れがある。自社のデータをデバイス別に切り分けて分析し、それぞれの傾向を別々に把握することが欠かせない。

デバイス別の分析が必須

モバイルでCTRが下がる背景には、AI Overviewsの拡大や検索結果画面の構成変化が影響している可能性がある。デスクトップとモバイルではユーザーの行動や画面占有のされ方が異なるため、両方を一緒くたに評価せず、施策もデバイスごとに最適化していく姿勢が有効だ。

AIの推奨がブランド検索を呼び、サイト訪問数が2.5倍に増加

AIの推奨がブランド検索を呼び、サイト訪問数が2.5倍に増加

Similarwebのレポートは、ChatGPTなどのAIが特定のブランドを推奨した場合、その後のユーザー行動の55.9%がブランド検索を経由してサイト訪問につながっていると示した。AIが直接リンクをクリックされる以上に、ブランド名を覚えさせて後から検索させる流れが主流になりつつある。

ここで、AI推奨がもたらすユーザー導線の変化をBefore/Afterで視覚化してみる。

従来の検索導線(Before)
ユーザー 一般的なクエリで検索 サイト訪問
※ユーザーが能動的に検索し、表示されたリンクをクリックして訪問する
AI推奨後の導線(After)
AIがブランドを推奨 ユーザーがブランド名で検索
サイト訪問
※AIの回答を見たユーザーは、リンクを直接クリックするよりもブランドを覚えて後から検索する割合が高い
AI  ユーザー行動  成果(訪問)

上記の図のAfter側では、AIがブランドを推奨した後にユーザーが改めて検索し、最終的にサイトを訪れるという2段階のプロセスが示されている。この流れが全体の55.9%を占めているというデータは、AI検索時代のブランド力の重要性を裏付けるものだ。

ブランド検索ボリュームをKPIに加える

AIが自社名に言及した際、ユーザーはリンクを直接クリックするよりも、ブランド名を検索してからサイトを訪れる傾向が強い。そのため、従来のオーガニック検索の流入数だけでなく、ブランド検索のボリュームそのものを追跡することがAI時代の重要指標になる。

SEOコンサルタントのAleyda Solís氏も、AIの影響はクリックを伴わない形で現れるため、AIリファラルだけを見ていては実態を捉えきれないと警鐘を鳴らしている。ブランド名での検索数や、直接流入・検索流入の増加をAIの露出と結びつけて評価する視点が不可欠だ。

Googleは外部SEOツールを評価せず、内部指標へのアクセスもない

Googleは外部SEOツールを評価せず、内部指標へのアクセスもない

Googleの検索・コマース担当VPであるBrendon Kraham氏は、効果的なSEOの取り組みはそのまま生成AI検索(GEO)にも通用すると述べた。同時に、Googleは第三者のSEOツールやベンダーを評価しておらず、そうしたツールがGoogle内部の指標にアクセスすることも一切ないと明言している。

この発言は、一部のツールが「AI検索に特化した独自のランキング指標」を謳うことに対して釘を刺すものだ。AIが絡む検索環境でも、基本はこれまで通り、ユーザーにとって価値あるコンテンツを提供するというSEOの原則に立ち返る必要がある。

「良いSEOは良いGEO」だが逆は成り立たない

Zyppy SEOの創設者Cyrus Shepard氏は、この「良いSEOは良いGEO」というスローガンにおおむね同意しつつも、AIが存在しなければ絶対にしなかったであろう施策をAIに詳しいSEO担当者がすでに行っていると指摘している。生成AI検索に過度に最適化することは、検索エンジンの変化に振り回されるリスクを高めるため、注意が必要だ。

この記事のポイント

  • 6月のスパムアップデートはAI応答の操作行為もスパムと認定。ランキング変動は数日間の経過を見守りながらパターン分析を
  • サーチコンソールのAIインプレッションはリンク表示回数のみでクリックデータは未提供。低い数値は過小評価の可能性も
  • デスクトップCTRは上昇したがモバイルはトップで低下。デバイス別の分析と施策の切り分けが重要
  • AI推奨の55.9%がブランド検索を経由して訪問。ブランド検索ボリュームをAI時代の重要KPIに
  • Googleは外部SEOツールの評価や内部指標へのアクセスを否定。AI検索でも基本は質の高いコンテンツ作り
WooCommerce納品書印刷で致命的エラーが出た時の直し方

WooCommerce納品書印刷で致命的エラーが出た時の直し方

WooCommerce の「Print Invoice & Delivery Notes for WooCommerce」プラグインで納品書や請求書を印刷しようとしたとき、管理画面に「このサイトで重大なエラーが発生しました」と表示され、PDF が生成されない問題は、PDF 生成に使う Dompdf ライブラリのクラスが見つからないことが原因だ。プラグインを再インストールし、サーバーのキャッシュをクリアすればほぼ解決する。

なぜ納品書印刷で致命的エラーが発生するのか

なぜ納品書印刷で致命的エラーが発生するのか

エラーログを確認すると「PHP Fatal error: Uncaught Error: Class “Dompdf\Options” not found」というメッセージが記録されている。これはプラグインが PDF を生成するために依存している Dompdf ライブラリを読み込めず、クラスが存在しない状態で呼び出されたことを意味する。原因は主にふたつに集約される。

ひとつはプラグインのインストールやアップデート時に、Dompdf のファイルを含む vendor ディレクトリが正しく配置されなかったケース。FTP アップロードの中断やパーミッションの問題でライブラリが欠落すると、このエラーが起きる。もうひとつは OPcache やプラグインのクラス自動読み込み(オートローダー)の不具合だ。管理画面の Ajax 経由で印刷を実行する際、特定の条件下でオートローダーが動かず、クラスが見つからないと判断される。一括印刷(Bulk Actions)が正常に動作するのも、別のコード経路でライブラリが読まれるためで、単票の印刷だけが失敗する典型的なパターンになっている。

エラーの切り分けと再インストール手順

エラーの切り分けと再インストール手順

エラーを解消するには、まずプラグインのファイルが完全に揃っている状態に戻し、キャッシュの影響を断ち切るのが確実だ。以下のステップで順に進めると、根本原因を速やかに取り除ける。

STEP 1 エラーログの確認で原因を絞り込む
STEP 2 プラグインを完全に再インストール
STEP 3 OPcache やサーバーキャッシュをクリア
STEP 4 納品書印刷を再度実行して確認

STEP 1 エラーログを確認して確実に特定する

WordPress の wp-config.php に define('WP_DEBUG', true); define('WP_DEBUG_LOG', true); が記述されていれば、/wp-content/debug.log に今回のような致命的エラーが記録される。ログを開き「Dompdf\Options not found」という行が含まれていることを確かめる。もしログが取れていなければ、上記の定数を一時的に有効にしてから問題の印刷操作をもう一度試す。この情報があると、単なる画面の白化や汎用エラーと区別でき、対応を誤らない。

STEP 2 プラグインを完全に再インストールする

管理画面の「プラグイン」→「インストール済みプラグイン」から「Print Invoice & Delivery Notes for WooCommerce」を探し、一度「無効化」をクリックしてから「削除」を実行する。その後、改めて「プラグイン」→「新規追加」で同じプラグインを検索し、最新バージョンをインストールして有効化する。これで vendor ディレクトリ以下の Dompdf ライブラリが確実に揃う。

もしなんらかの事情で管理画面から削除できない場合は、FTP またはサーバーのファイルマネージャーを使って /wp-content/plugins/woocommerce-delivery-notes/ ディレクトリを丸ごと削除し、再度アップロードする。その際、ディレクトリ名やパーミッションが正しいことを確認しておく。

STEP 3 サーバー側のキャッシュをリセットする

PHP 8.2 環境では OPcache が有効になっており、古いクラスパスの情報がキャッシュに残っていると再インストール後もエラーが続く場合がある。レンタルサーバーの管理画面から PHP の OPcache をクリアするか、php.ini などで opcache_reset(); を一時的に実行する。また、nginx の fastcgi キャッシュを使っている場合はそちらも削除しておく。WordPress 側で WP Rocket や W3 Total Cache などのキャッシュプラグインを利用していれば、すべてのキャッシュを完全にクリアする。

❌ Before

管理画面で「印刷」を押すと「このサイトで重大なエラーが発生しました」と表示され PDF が生成されない

✅ After

納品書や請求書の PDF が問題なく生成され、印刷も正常に動作する

エラー状態  修正後

STEP 4 納品書印刷を再度実行して検証する

WooCommerce の注文一覧から該当の注文を選び、「印刷」ボタンをクリックして PDF が開くことを確認する。もしこれでも同じエラーが出る場合は、別の PDF 出力系プラグイン(例 「PDF Invoices & Packing Slips for WooCommerce」など)との競合も疑い、それらを一時的に無効化して原因を絞り込む。Dompdf クラスを上書きするようなカスタマイズや、異なるドキュメント生成ライブラリが同じ名前空間を使っているケースでは、片方のプラグインを停止する必要がある。

キャッシュや競合プラグインの対処をもう少し深掘りする

キャッシュや競合プラグインの対処をもう少し深掘りする

OPcache の影響は想像以上に大きい。特に PHP のバージョンを上げたり、プラグインを一括更新したあとは、古いオートロードマップが残ってしまい、クラス不存在のエラーが続くことがある。サーバーが共用の場合でも、管理パネルに「PHP 設定」「PHP 再起動」などの項目があればそこから OPcache をクリアするか、何もなければレンタルサーバー会社のサポートに依頼する。

また、Kinsta や WP Engine のようなマネージドホスティングでは独自のキャッシュレイヤーを持っているため、管理画面のキャッシュクリア機能を使ってオブジェクトキャッシュやページキャッシュを完全に削除する必要がある。自前で nginx の fastcgi_cache を組んでいる場合は、fastcgi_cache_path のディレクトリを空にするか、キャッシュ無効化のパラメータを追加してから再度有効化する。

複数の PDF プラグインが有効になっていると、同じ Dompdf ライブラリを異なるバージョンで読み込もうとしてクラス衝突が起きることもある。このプラグインのバージョン 7.2.0 が特に最新の Dompdf に追従していない場合、他のプラグインが読み込んだ後に自前のオートローダーが正しいパスを指せず、今回のエラーになる。こうしたケースでは、問題のプラグイン以外の PDF 関連プラグインをすべて無効化し、一つずつ原因を特定していく。最悪の場合は代替プラグインへの乗り換えも選択肢になる。

よくある質問

プラグインを再インストールしても直らない場合は?

管理画面の「ツール」→「サイトヘルス」でループバックリクエストのエラーや REST API の異常がないかを確認する。Ajax 通信自体がブロックされていると Dompdf の読み込み以前に失敗する。また、サーバーのエラーログで open_basedir 制限や disable_functions の影響が出ていないかもチェックする。

一括印刷は動くのに単票だけ失敗する理由は?

一括印刷は admin-post.php 経由か、直接テンプレートを呼び出す仕組みで動いており、admin-ajax.php を使う単票印刷とは異なるコードパスになる。結果としてオートローダーの読み込みタイミングが変わり、エラーが出たり出なかったりする。根本的には再インストールで解消するが、どうしても直らなければプラグインの設計上の不具合の可能性もある。

エラーログに Dompdf のクラスがないと出るが、ファイルはサーバーに存在している

FTP などで /wp-content/plugins/woocommerce-delivery-notes/vendor/dompdf/dompdf/src/Options.php が実在するのにエラーが出る場合、PHP の OPcache か、nginx のファイルキャッシュが古い状態を返している可能性が高い。OPcache の再起動やサーバーキャッシュのクリアで直ることがほとんどだ。それでも変わらないときは、ファイルのパーミッションが読み取り不可になっていないかも確認する。

ほかの PDF プラグインと同時に使えるか?

同じ Dompdf を内部で使うプラグイン同士は、名前空間の解決順序によってクラスが見つからなくなるリスクがある。実際に複数の PDF 出力系プラグインを有効にしている場合は、トラブルシューティングのために一度すべて無効化し、必要なものだけを再び有効化することを推奨する。

PHP のバージョンを上げた後に起きたが関係あるか?

PHP 8.2 以上ではクラス自動読み込みの挙動が厳格になり、以前は暗黙的に読めていたファイルが読めなくなることがある。プラグインが最新バージョンで PHP 8.2 に対応しているかどうかを開発元の Tyche Softwares のドキュメントで確認し、対応済みであれば再インストールで問題は解消する。

この記事のポイント

  • 致命的エラーは Dompdf ライブラリのクラスが読み込めないことが原因
  • プラグインをいったん完全に削除し、最新版を再インストールするのが最も確実
  • サーバーの OPcache や各種キャッシュを必ずリセットする
  • 複数の PDF プラグインの同時利用が競合を引き起こしている可能性も疑う
  • 一括印刷が動作していても単票でのエラーは起こり得る
WooCommerce 10.9で「あとで買う」「ほしいものリスト」が実験搭載

WooCommerce 10.9で「あとで買う」「ほしいものリスト」が実験搭載

WooCommerce 10.9が2026年6月にリリースされ、ログイン顧客向けの実験的なショッピングリスト機能「Shopper Lists」が導入された。カート画面に表示される「あとで買う(Save for Later)」と、商品ページに追加される「ほしいものリスト(Wishlists)」の2機能が含まれている。

いずれもデフォルトでは無効化されており、店舗運営者が明示的にオンにして使うオプトイン方式だ。今回は WooCommerce のブロックベースショッピング体験を前提に設計されており、従来のショートコードベースの店舗では動作が保証されない点に注意が必要だ。

両機能は同じ Shopper Lists バックエンドを共有しており、今回の実験リリースを経て、将来的にはさらに多くのリスト系機能へ拡張される可能性がある。

2つのショッピングリスト機能の詳細

2つのショッピングリスト機能の詳細

Save for Later(あとで買う)

「Save for Later」はカートブロックの各商品行に「あとで買う」というアクションを追加する。ログイン顧客がこのボタンを使うと、その商品はカートから取り除かれ、カートブロックの下部に新設された「あとで買う」セクションへ移動する。

顧客はあとで買うセクションから商品をカートに戻したり、リストから削除したりできる。バリエーション商品(サイズや色を選択する商品)の場合、選択済みの属性情報が保持されるため、「どのサイズを保存したか」をあとで確認できるのが実務上の利点だ。

従来のカート(Before)
Tシャツ(Mサイズ) ¥2,980 数量 1
購入する か 削除する の二択しかない
購入する 削除
※「迷っている商品」を置いておく場所がない
Save for Later 導入後(After)
カート内
マグカップ ¥1,200 購入する
あとで買うセクション
Tシャツ(Mサイズ) ¥2,980 カートに戻す 削除

現時点ではカートブロックのみ対応で、ミニカートには未対応。WooCommerce 開発チームの発表によれば、ミニカート対応は今回の実験リリースのスコープ外とされている。

Wishlists(ほしいものリスト)

「Wishlists」は Add to Cart with Options ブロックを使っている商品ページに「ほしいものリストに追加」ボタンを表示する。単純商品だけでなく、選択済みのバリエーション商品も保存できる。

保存した商品はマイアカウントの「ほしいものリスト」セクションから一覧表示され、そこからカートへの移動や削除が可能だ。店舗運営者は Wishlist ブロックを任意の固定ページに配置することで、顧客が自分専用のほしいものリストページを持てるようになる。

Wishlists のデータフロー
顧客 商品ページで「ほしいものリストに追加」をクリック
WooCommerce Store API 経由で shopper-lists に保存
顧客 マイアカウント > ほしいものリスト で確認
顧客 「カートに追加」または「削除」を選択

技術的基盤

技術的基盤

Save for Later と Wishlists は、どちらも同一の Shopper Lists バックエンドを土台にしている。Store API、Interactivity API ストア、共有データ構造の3層で構成されており、今後のリスト系機能追加を見据えた拡張性の高い設計だ。

共有 Store API エンドポイント

両機能のデータ操作は、すべて以下の共通エンドポイント群を通じて行われる。

/wc/store/v1/shopper-lists/

Store API は WooCommerce のブロックベースショッピング体験を支える REST API 層で、カートやチェックアウト、商品データの取得を担う。今回の Shopper Lists 実装により、この API 層にリスト操作の機能が追加された形だ。

Developer WooCommerce Blog の発表によると、この API 表面はメイン機能マージ(#65263)で導入され、Wishlist ボタンは Add to Cart with Options ブロックへのレンダリング時注入(#65765)によって復帰したとされている。

Interactivity API との統合

Interactivity API は WordPress 6.5 で導入された、ブロックにインタラクティブなフロントエンド動作を追加するための公式 API だ。Shopper Lists では、カートブロック内での「あとで買う」への移動や、商品ページでの「ほしいものリストに追加」といった操作が、ページ遷移なしで即座に反映される。

この API を利用することで、従来の WooCommerce で課題だった「操作のたびにページ全体がリロードされる」問題が解消され、顧客体験が大きく向上する。とくに商品数が多い店舗では、体感速度の差が顕著になるだろう。

機能の有効化手順

機能の有効化手順

これらの機能はカートの挙動、商品ページの表示、マイアカウント、ブロックテンプレート、ログイン顧客データ、Store API との通信と、多岐にわたる領域に影響を与える。そのため WooCommerce チームは「本番環境ではなく、ステージング環境かローカルテストサイトで検証してほしい」と呼びかけている。

有効化に必要な条件

  • WooCommerce 10.9.1 以降がインストールされていること
  • ステージング環境またはローカルのテストサイトであること
  • カートページが Cart ブロックで構築されていること
  • 商品詳細ページのテンプレートが Add to Cart with Options ブロックを使用していること
  • テスト用の顧客アカウントが用意されていること

設定手順

管理画面の WooCommerce > 設定 > 高度な設定 > 機能 に移動し、以下の2つの実験的機能を有効化するだけだ。

  • Save for Later in Cart(カート内のあとで買う)
  • Wishlists(ほしいものリスト)

テスト用の商品構成としては、単純商品を1点以上、選択式属性を持つバリエーション商品を1点以上用意しておくと、両機能の動作を網羅的に確認できる。

テストすべきポイント

テストすべきポイント

WooCommerce チームはデベロッパーや制作会社、店舗構築者に対し、実際の店舗構成に近い環境でのフィードバックを求めている。とくにカスタマイズされたブロックテンプレートや多数の拡張機能を導入したサイトでの動作報告が重視されている。

Save for Later のテスト項目

  • カート内の商品に対して「あとで買う」ボタンが表示されるか
  • ボタン押下後、商品が「あとで買う」セクションに正しく移動するか
  • バリエーション商品の選択属性(サイズや色)が保持されているか
  • 「カートに戻す」で商品がカートに復帰するか
  • 「削除」でリストから消えるか

Wishlists のテスト項目

  • 商品ページに「ほしいものリストに追加」ボタンが表示されるか
  • 単純商品とバリエーション商品の両方が保存できるか
  • マイアカウント > ほしいものリスト に保存商品が正しく表示されるか
  • ほしいものリストからカートへの移動が正常に動作するか
  • Wishlist ブロックを任意の固定ページに配置して表示できるか

無効化時のクリーンアップ確認

両方の実験的機能を無効化したあと、カート、商品ページ、マイアカウントを再訪問し、Shopper Lists の UI が完全に消えるかを確認する必要がある。無効なブロックが残ったり、テンプレート出力が崩れたりしないことが、安定版への移行条件のひとつになる。

テストフロー概要
STEP 1 ステージング環境に WooCommerce 10.9.1 以降をインストール
STEP 2 両方の実験的機能を有効化し、テスト商品と顧客アカウントを準備
STEP 3 Save for Later と Wishlists の全操作を顧客目線でテスト
STEP 4 機能を無効化し、UI が完全に消えることを確認
STEP 1(青)  STEP 2(緑)  STEP 3(橙)  STEP 4(紫)

実務への影響と今後の展望

実務への影響と今後の展望

Shopper Lists の登場は、WooCommerce 店舗における顧客維持の選択肢を大きく広げる。従来の「その場で買うか、離脱するか」という二択から、「いったん保存して後日判断する」という選択肢が加わることで、カート放棄率の低減につながる可能性がある。

とくにアパレルや家具など、購入までに検討期間が長い商材を扱う店舗にとっては、ほしいものリスト機能の価値は高い。顧客が複数回にわたって同じ商品を閲覧する行動パターンがある場合、リスト保存によってコンバージョンまでの導線が短縮される。

ただし現時点では実験的機能であり、本番環境での利用は推奨されていない。カスタマイズされたブロックテーマや拡張機能との競合が発生する可能性があるためだ。WooCommerce チームが特に求めているのは、まさにそうした「実店舗に近い複雑な環境」でのテスト報告である。

フィードバックは Developer WooCommerce Blog の該当記事コメント欄、または GitHub ディスカッション(#66038)で受け付けている。制作会社やデベロッパーにとっては、正式リリース前に自社のクライアント店舗との相性を把握できる貴重な機会といえる。

この記事のポイント

  • WooCommerce 10.9 が Shopper Lists 機能を実験的に導入した
  • 「Save for Later」はカートブロックに商品を一時保存する機能
  • 「Wishlists」は Add to Cart with Options ブロックと連携するほしいものリスト
  • 両機能はデフォルト無効で、管理画面の「高度な設定 > 機能」から有効化する
  • 本番環境ではなくステージング環境でのテストが強く推奨されている
OpenAIとBroadcomがLLM専用推論チップJalapeñoを発表

OpenAIとBroadcomがLLM専用推論チップJalapeñoを発表

Jalapeño 発表の背景とフルスタック戦略

OpenAIはこれまで、ChatGPTやAPI製品といった「モノを売る」領域と、GPT-5.3に代表される「頭脳を鍛える」領域に注力してきた。今回発表されたJalapeñoは、その下の「足腰を作る」領域、つまり物理的な計算基盤への本格参入を意味する。

従来、大規模言語モデル(LLM)の計算には、NVIDIA製GPUを中心とした汎用アクセラレータが広く使われてきた。汎用性が高い反面、LLMの推論処理に特化させるとデータ移動のオーバーヘッドが生じ、本当に出せるはずの理論性能を引き出しきれない場面があった。Jalapeñoはこの制約を根本から解消する狙いがある。

従来の汎用アクセラレータ型
汎用GPU 行列演算 メモリ転送 結果出力
⚠️ データ移動が多く、理論ピーク性能の60〜70%程度の実効利用率に留まりやすい
Jalapeño の専用設計型
Jalapeño LLM専用演算 最小限のデータ移動 高速出力
💡 アーキテクチャの最適化により、理論ピーク性能に近い実効利用率を達成

OpenAIのブログ記事は、Jalapeñoを「フルスタックの優位性」の象徴と呼ぶ。モデルを作り、製品を届け、その下のチップまで自前で設計する一貫体制が、性能とコストの両面で差別化要因になるとの考え方だ。

フルスタック体制が生む「AIのフライホイール」

OpenAIが示す好循環の構図はこうだ。専用チップで推論コストが下がる。コストが下がれば、より多くのユーザーに安価でサービスを届けられる。利用が拡大すれば収益が増え、その収益を次世代チップの研究開発に再投資できる。

STEP 1 Jalapeñoによる推論の高速化とコスト低減
STEP 2 ChatGPTやAPIの低価格化・信頼性向上
STEP 3 ユーザー数・開発者・収益の拡大
STEP 4 次世代チップ開発への再投資

この循環は、単に「速いチップを作りました」以上の構想だ。物理的な計算資源の制約そのものを押し広げる試みであり、OpenAIがインフラ企業へと変貌を遂げる宣言でもある。

9か月で仕上げた設計速度とAIの自己適用

9か月で仕上げた設計速度とAIの自己適用

Jalapeñoの開発期間は、初期設計から製造テープアウトまでわずか9か月だった。OpenAIのブログによれば、これは高性能先端半導体のASIC開発サイクルとして過去最速と考えられている。一般的に、フルスクラッチの専用チップを起こすには数年を要する。それを1年未満でまとめ上げた点は、技術面以上に開発プロセスそのものの革新を示している。

この速度を支えた要素は大きく3つある。第1に、OpenAIのソフトウェアチームとBroadcomのシリコン実装部隊が深く連携した「ソフト・ハード共創」の手法。第2に、Broadcomのネットワーク技術やCelesticaのシステム統合ノウハウを組み合わせたモジュール化。そして第3に、OpenAI自身のモデルを設計プロセスの一部に活用し、最適化や検証を加速させたことだ。

従来のASIC開発 要件定義 6か月 設計 12〜18か月 検証 6か月 テープアウト
※総期間 24〜36か月が標準的
Jalapeño の開発 OpenAI モデル で検証加速 Broadcom が並列実装 わずか9か月
※史上最速クラスの高性能ASIC開発サイクル

「AIがAI向けチップの設計を加速する」という構図は、OpenAIにとって象徴的な意味合いが強い。ユーザーに提供しているモデルと同じ技術が、次のモデルを動かすインフラを改善するという自己強化のループが、すでに動き始めている。

性能の初期テスト結果と技術的詳細

性能の初期テスト結果と技術的詳細

OpenAIの発表時点では、Jalapeñoの最終的な性能値は確定していない。今後数か月以内に詳細な技術報告があるとしている。とはいえ、すでにラボ内でエンジニアリングサンプルが稼働しており、GPT-5.3-Codex-Sparkを含むMLワークロードを本番相当の動作周波数と電力で実行している。

現時点で明かされている初期テストの所見は「性能あたりの消費電力が現行の最先端アクセラレータよりも大幅に優れる」というものだ。具体的な数値こそ伏せられているが、ここで注目すべきは単なるワットパフォーマンスの良さだけではない。

「実効利用率」を高める設計思想

Jalapeñoのアーキテクチャの中心には、データ移動の最小化と、計算・メモリ・ネットワーク資源のバランスがある。汎用チップでは、どうしても実際に使える計算能力(実効利用率)が理論ピーク性能を大きく下回る。OpenAIのハードウェア責任者であるRichard Ho氏は、Jalapeñoが「最重要ワークロードをハードウェアの理論限界近くで効率的に実行する」と述べている。

理論ピーク性能と実効利用率のイメージ
汎用アクセラレータ
65%
※データ移動のオーバーヘッド大
Jalapeño
90%以上
※専用設計で限界近くまで引き出す
無駄になる計算能力  実際に使える計算能力

この設計方針は、LLM推論のワークロードが想定する「カーネル」や「サービングパターン」に深く根ざしている。特定の行列演算パターンや注意機構の計算をハードウェアレベルで効率化することで、同じワット数でもより多くの推論リクエストを捌ける見込みだ。

汎用チップとの差別化とLLM専用設計

Jalapeñoは「過去のAIワークロードから流用した汎用アクセラレータ」ではない。ChatGPT、Codex、API、さらに将来のエージェント製品まで見据え、LLM推論という一点に向けて設計を白紙から起こした専用品だ。OpenAIが日常的に運用している推論システムの実測データが、設計の随所に織り込まれている。

狙いは、現行の主力AIアクセラレータが持つ処理能力と、最速の専用推論システムが持つ低遅延性を、1つのパッケージで両立させることだ。対話型の大規模LLM製品に求められるのは、大量のリクエストを高速で処理するスループットと、1つ1つの応答が体感できるほど速いレイテンシの両方である。Jalapeñoはこの2軸を同時に引き上げる設計になっている。

データセンター規模の展開計画とパートナーシップ

データセンター規模の展開計画とパートナーシップ

Jalapeñoは1枚のチップで完結する話ではない。OpenAIとBroadcomは複数世代にわたる計算プラットフォームの共同開発を掲げており、2026年末からの初期展開を皮切りに、ギガワット級のデータセンターへと拡大していく予定だ。

Broadcomの社長兼CEOであるHock Tan氏は、OpenAIとの提携を「AIの今後10年に必要な物理インフラをスケールさせるための根本的なコミットメント」と表現する。Microsoftをはじめとするデータセンターパートナーと連携し、2026年から巨大規模の展開を始める計画が明言されている。

物理的なチップができても、それを数十万台単位で安定的に動かすには、ボード設計やラック統合、高性能ネットワーク、冷却、電源管理まで含めた総合力がいる。Celesticaはこの領域でOpenAIとBroadcomを支えるパートナーとして参加している。

Jalapeño のサプライチェーンと役割分担
OpenAI チップアーキテクチャ設計、LLM要件定義
Broadcom シリコン実装、Tomahawkネットワーク技術
Celestica ボード・ラック・システム統合
Microsoft 他 データセンターパートナー、電力・冷却・運用

OpenAIの社長兼共同創業者であるGreg Brockman氏は「世界は計算主導の経済へと移行している」と述べ、Jalapeñoがその長期戦略の一部であることを強調する。同氏の言葉を借りれば、スタックのより多くの部分を自前で設計することで、より多くの知能を、より高い効率で提供できるようになるという。

Jalapeño がAI利用者にもたらす具体的変化

Jalapeño がAI利用者にもたらす具体的変化

このチップの話は、一見するとデータセンターや半導体産業だけの話題に思える。しかし、Jalapeñoの恩恵は最終的にエンドユーザーと開発者に届く。

  • ChatGPTの応答速度が体感できるほど速くなる
  • Codexによるコード生成や修正が、待ち時間の少ないままより複雑なタスクを処理できる
  • APIの利用料金が下がり、スタートアップや個人開発者でも高度なAI機能を組み込みやすくなる
  • 需要が集中する時間帯でも、タイムアウトや遅延に悩まされにくくなる

「推論はAIが人に届く場所だ」とOpenAIのブログは述べる。コスト、速度、信頼性の改善はすべて、最終的に製品体験の改善に直結する。Jalapeñoはそのための物理的基盤を刷新するプロジェクトだ。

この記事のポイント

  • JalapeñoはOpenAI初のLLM推論専用アクセラレータで、Broadcomと共同開発
  • 白紙設計によりデータ移動を最小化し、理論ピーク性能に近い実効利用率を実現
  • 設計からテープアウトまで9か月の最速開発。OpenAIのモデルが設計加速に貢献
  • 2026年末からギガワット級データセンターでの展開を計画
  • ChatGPT、Codex、APIの低価格化と高速化に直結するフルスタック戦略の核心
WordPressを構築する人材は誰なのか、市場縮小の実態

WordPressを構築する人材は誰なのか、市場縮小の実態

数字が物語る市場の縮図

数字が物語る市場の縮図

まずは客観的な立場から現状を整理する。データはシェアの緩やかな縮小を示しているが、これは崩壊ではなく「選択されなくなる」局面への移行を意味する。

全ウェブサイトに占めるWordPressのシェアは、2024年の約43.6%をピークに、2026年6月時点で41.5%まで低下した。CMS市場に限っても、ピークの61.7%から59.3%へとダウンしている。だが、この数値を額面通り受け取るのは早計だ。絶対数ベースで見ればWordPressサイトの総数は依然として増加しており、シェア低下の主因は、ウェブ全体の成長スピードにWordPressの新規サイト獲得が追いついていない点にある。

つまり、既存ユーザーが脱出しているわけではない。リスクは「新しくサイトを作る人がどこから始めるか」という新規獲得市場に潜んでいる。WP Mayorの記事はこれを「維持率は堅いが、新規参入の指標が危険信号を灯している」と総括する。この見立ては、プラットフォームの将来を占う上で極めて重要だ。

シェア低下の構造的要因

シェア低下はWordPressの魅力が失われたというより、ウェブの主戦場とプレイヤーが多様化した結果だ。かつてはサイト構築のデファクトだったWordPressも、今やShopifyやSquarespaceといったホステッドプラットフォーム、SubstackやLinktreeのような単機能サービスと住み分ける局面に入った。WixとShopifyだけで、WordPressが失ったシェアとほぼ同規模の成長を示している。

これはWordPressの「万能性」が、一部の層にとっては「複雑性」として映り始めている証左でもある。ウェブ制作の民主化は確かに進んだが、その民主化を担うツールの主役が交代しつつあるのだ。

変わりゆく作り手の肖像

変わりゆく作り手の肖像

WordPressを支えるコア人材の年齢層は、確実に上がっている。この構造変化は、エコシステムの将来における最大の不安要素の一つだ。

2003年の誕生から20年以上が経過し、黎明期を支えた開発者やエージェンシー経営者の多くは40代から50代に差し掛かっている。WP Mayorの記事が参照する2023年の公式調査では、回答者の約半数が40歳以上であり、30歳未満は23%に過ぎなかった。この調査は英語圏のコアコミュニティに偏っているという限界はあるが、プロフェッショナル層の高齢化を如実に示している。

より広範な開発者コミュニティに目を向けても傾向は同じだ。Stack Overflowの調査では、35歳以上の開発者の割合が2019年の約4分の1から2025年には47%にまで上昇している。PHP自体の新規学習者も少なく、若年層の関心はJavaScriptやノーコードツール、あるいはWebflowやFramerといった直感的なサイトビルダーに流れている。

新興市場という希望と現実

反論として、インドやブラジル、インドネシアといった新興国での成長を挙げる声は根強い。実際、これらの地域の若年層がWordPressの新たな利用者層を形成している可能性は高い。WP Mayorの記事も「世界全体で見れば、新規ユーザーの中心年齢はむしろ若いかもしれない」と指摘する。

だが、問題はその層が「エコシステムの構築者」、すなわちプラグインを開発し、コミュニティを牽引し、WordPressの未来を形作る人材なのか、という点にある。現状、西側諸国を中心とした従来の強力なコントリビューター層の高齢化と、新たな才能の流入不足は、イノベーションの停滞に直結する構造的な弱点だ。

「WordPressを構築する方法」の終焉

「WordPressを構築する方法」の終焉

ウェブ制作の前提そのものが根本的に変化し、WordPressが前提としてきた「自分で積み上げる」モデルは、もはや唯一の選択肢ではなくなった。

かつてのように、サーバーを借り、CMSをインストールし、テーマを選び、プラグインを探し、セキュリティを自衛するという一連の体験は、多くの個人やスモールビジネスにとって、もはや過剰な負担でしかない。WP Mayorの記事が指摘する通り、ウェブの消費行動が「所有から利用へ」と移行する中で、この参入障壁の高さは深刻なコストとして認識されるようになった。

公開データが示す調査結果も興味深い。2026年1月の調査では、スモールビジネスの68%がソーシャルメディアと有料広告を成長の最大のドライバーと見なしていた。自社サイトは、かつての「最初の一歩」から「信頼性を担保する二の次の存在」へと役割を変えたのだ。

参入障壁という名のジレンマ

WordPressの柔軟性は、それを楽しめる人にとっては未だ最大の武器だ。しかし、スピードと簡便さを求める一般人にとって、WordPressが要求する「技術的なリテラシー」は、単なる面倒くささでしかない。最近のAIサイトビルダーがこれほど急速に支持を集めているのは、この「面倒くささ」をゼロにしたからに他ならない。

WP Mayorの記事は、この点について「いじくり回すことを楽しむ人が減ったとき、柔軟性はアドバンテージからコストに変わる」と明確に断じている。この変化は、WordPressがターゲットとすべき市場が「手間をかけてでも理想を追求する層」へと限定されつつあることを示唆している。

悪化するブランドパーセプション

悪化するブランドパーセプション

構造的な問題に加え、WordPressにはイメージ面での逆風も吹いている。「遅い」「セキュリティが脆弱」というレッテルは、時に誤解を含みつつも、新規ユーザーの選択を阻害する強力な要因だ。

セキュリティに関して言えば、「WordPressコアに重大な脆弱性が多い」という認識は、データに基づくと不正確だ。Patchstackのレポートによれば、2025年に報告されたコアの脆弱性はわずか6件で、いずれも重要度は低かった。問題の91%はサードパーティ製プラグインに集中しており、脆弱性の公開から悪用開始までの時間は中央値で5時間にまで短縮されている。WP Mayorの著者はこの状況を「WordPressコアは安全だが、無数のプラグインで構成される現実のサイトは危険」と評する。

表示速度も同様の構図だ。Core Web Vitalsの合格率は改善傾向にあるものの、モバイルでの合格率は約45%と、Shopify(68〜75%)などに大きく水をあけられている。だが、これは技術的な限界というより、安価なホスティングや無秩序なプラグインの重ねがけによる「運用の問題」が大きい。WP Mayorの記事は「速度問題はWordPressというソフトウェアには不公平だが、典型的な導入実態には妥当な批判」と表現している。

「オープンソース」という逆説

今、オープンソースはAIブームによってかつてない隆盛を極めている。GitHub上では大規模なオープンソースAIプロジェクトが何十万ものスターを集め、コードを公開し合う文化が再び脚光を浴びている。WP Mayorの記事はここにこそ痛烈な皮肉があると指摘する。かつてオープンソースの大衆化を象徴したWordPressは、この新しい潮流から完全に取り残されているのだ。

新しい才能はWordPress.orgではなく、モダンなAIツールやJavaScriptフレームワークのリポジトリに集まっている。知名度はあっても、もはや「カッコよくない」プラットフォーム、それがWordPressの直面するイメージ上の課題だ。

AIが侵食する「すそ野」市場

AIが侵食する「すそ野」市場

WP Mayorの記事が最も深刻に捉えているのがこの問題だ。AIによるWebサイト構築の民主化は、WordPressが伝統的に得意としてきた「シンプルなサイト」の市場を根底から解体しつつある。

「サイトが欲しい」というニーズに対する解答は、もはやツールの習得ではない。LovableやCursor、Vercelのv0、WixのAIビルダーといったサービスは、ユーザーがやりたいことを自然言語で伝えれば、数分で動作するサイトを生成する。これらのツールは既に巨大なビジネスに成長しており、単なるバズワードではない。雇用主AIビルダーは、この流れが本物であることを証明している。

WP Mayorの記事は、AIの影響を「底上げ」と「天井上げ」の2つに分類する。すなわち、技術的でない人が簡単なサイトを作れるようにする底上げと、技術者がWordPressではなくCursorやAstroで高度なカスタムサイトを構築する天井上げだ。このうちWordPressにとって脅威なのは、市場規模が大きい前者の「底上げ」部分であり、これはWordPressがこれまで無意識に吸収してきた客層と完全に重なる。

プラグイン市場への波及

シンプルなサイトの需要が減退すれば、それを支えてきたプラグイン市場も連動して縮む。問い合わせフォーム、簡単なSEO対策、ギャラリー表示、ちょっとしたレイアウト変更。これまで無数のプラグインが提供してきたこれらの機能は、今やAIがその場で生成できるものだ。

WP Mayorの記事は、まだAIによるプラグイン収益減少を示す確定的なデータは存在しないと慎重に留保しつつも、「WordPressサイトでなくても済むようになったサイト群」を支えてきたプラグインこそが、エコシステムの中で最大のリスクに晒されている、という明確な見解を示している。これは、WordPressビジネスに携わる者なら誰しも直視すべき未来予測だろう。

従来のプラグイン戦略(消えゆくモデル)
シンプルな機能を提供する単機能プラグイン
機能 問い合わせフォーム
機能 シンプルなSEOテキスト生成
機能 画像ギャラリー
これからの生存戦略(生き残るモデル)
AIで簡単に複製できない「堀」を持つビジネス
データ 独自の脅威インテリジェンス
サービス リアルタイムAPI提供
流通 巨大なインストールベース

プラグインゴールドラッシュの終焉

プラグインゴールドラッシュの終焉

WP Mayorの記事が最も具体的に警鐘を鳴らすのが、プラグイン開発者の未来だ。AIによるコーディング支援は、プラグイン開発の参入障壁を劇的に下げた。2025年には12,713件のプラグインが新たに審査され、前年比で40%以上も急増した。WP Mayorはこれを「コードという防壁が消え去った状態」と表現する。

この状況下では、コードの機能だけが売りのプラグインに未来はない。誰でもAIを使えば、有料プラグインと同等の機能を一から構築できてしまうからだ。残るのは、コードだけでは再現できない「堀(Moat)」、すなわち、独自に蓄積したデータ、ライセンス認証やアップデート配信といったインフラ、あるいはユーザーからの信頼とブランド力である。

加速する寡占とデータの重要性

この変化を敏感に察知し、行動に移しているのが大手プラグイン企業だ。Awesome Motiveは多数のプラグインを買収し、そのデータと流通網を掌握することで巨大な堀を築いている。2026年5月にはLiquid WebがStellarWPブランドを統合し、傘下のプラグイン群を単一製品ラインに再編した。これらの動きは、企業価値の源泉が「コード」から「データと顧客基盤」へ完全にシフトしたことを示している。

WP Mayorの記事は、「AIは模倣者だけでなく、既存の勝者をも強力にする」と冷静な分析も加えている。すでに巨大なインストールベースを持つ企業は、AI機能を自社製品に迅速に組み込むことができるからだ。重要なのは、自身のビジネスがこの「バーベル」のどこに位置するのかを、今のうちに見極めておくことだろう。

ガバナンス不在が招く開発者離れ

ガバナンス不在が招く開発者離れ

WP Mayorの記事は、技術や市場の変化以上に深刻な問題として「プロジェクトのガバナンス」を挙げる。開発者がリスクを感じて去っていく最大の要因が、ここにあると断じている。

事の発端は、WordPressの共同創設者であるMatt Mullenweg氏が、ホスティング会社WP Engineを公の場で「WordPressのがん」と非難した2024年秋の出来事だ。WP Mayorの著者は、その後の一連の行為、すなわちWP Engineのアップデートサーバーアクセス遮断、ログイン時の「WP Engineと無関係である」という宣誓チェックボックスの設置、そして200万サイト以上で使われていたプラグインの無断フォークと乗っ取りを、「商標権の行使」の枠を超えた、統治機構の欠如を示すデモンストレーションだったと批判する。

連邦裁がAutomattic社に仮差し止め命令を出す事態にまで発展したこの騒動は、コミュニティに深い傷を残した。WP Mayorの記事は、これが単なる企業間紛争ではなく、優秀な開発者に対して「このプラットフォームに貢献する真のコスト」を知らしめる出来事だった、と厳しく指摘している。

構造的欠陥は何も変わっていない

WP Mayorの記事が最も憂慮するのは、問題の根本が2026年半ばの現在まで全く変わっていない点だ。WordPress.orgの配信インフラとプラグインディレクトリは、非営利財団ではなく、Mullenweg氏個人の資産であるという構造的な事実。そこには監視委員会も、コミュニティがリーダーの決定を覆すメカニズムも存在しない。

ガバナンス改革を主導したコミュニティリーダーのアカウントが停止され、代替リポジトリを目指したプロジェクトは出資者を得られず頓挫した。WP Mayorの記事は、この一連の出来事を「才能ある人々は皆、結論を出した。何かが変わるまでは、才能の流出は止まらない」と総括している。これは、WordPressの未来を左右する、極めて政治的な、しかし避けては通れない核心的な課題だ。

この記事のポイント

  • WordPressの市場シェア低下は緩やかであり、エコシステムが崩壊しているわけではない。しかし、かつてのように「誰でも最初に選ぶツール」ではなくなりつつある。
  • ユーザー層と開発者コミュニティの高齢化は深刻で、若い才能の流入不足が長期的な競争力を削いでいる。
  • シンプルなサイト構築需要はAIに奪われつつあり、単機能プラグインの市場は決定的に縮小する公算が大きい。
  • 生き残るには、コード以外の独自データや流通網といった「堀」が不可欠だ。ビジネスは二極化し、中間層は消える。
  • プラットフォームのガバナンス問題は、今後もエコシステム最大の不安定要因であり続ける。その影響は技術的な課題よりも根深い。
PayPal Standard終了、WooCommerce事業者が知るべき移行の全容

PayPal Standard終了、WooCommerce事業者が知るべき移行の全容

PayPal Standard終了がもたらすWooCommerce決済の転換点

PayPal Standard終了がもたらすWooCommerce決済の転換点

WooCommerceで長年使われてきたPayPal Standardが、2026年6月に正式に役目を終える。PayPal Payments 4.1.0のリリースに伴い、条件を満たすと自動的に無効化され、管理画面からも非表示になる仕組みだ。すでにPayPal Standardを使っている場合でも、すぐに決済が止まるわけではない。しかし移行計画を立てるべきタイミングが来たことは間違いない。

WooCommerce Developer Blogの記事によれば、この動きは突然の発表ではない。2021年から段階的に縮小されてきた流れの最終段階にあたる。今回のアップデートでは、事業者の操作ミスを防ぎつつ、定期購入(サブスクリプション)の継続性を守る配慮が組み込まれている。

本記事では、PayPal Standard終了の背景、PayPal Payments 4.1.0の具体的な動作、移行を安全に進めるツールの使い方、そしてなぜこの変更が事業者にとってプラスになるのかを整理する。

従来の決済体験(PayPal Standard)
外部サイトへ遷移 離脱リスク高
カスタマイズが難しく、最新機能に非対応
新しい決済体験(PayPal Payments)
サイト内で完結 離脱防止
Pay Later・Venmo・カード入力に対応し、継続的に改善

上の図は、決済フローがどう変わるかの概念を示したものだ。外部サイトへの遷移がなくなるだけで、購入完了率は大きく変わる可能性がある。

これまでの経緯とPayPal Standard廃止の必然性

これまでの経緯とPayPal Standard廃止の必然性

2021年から始まった段階的縮小

WooCommerceがPayPal Standardを新規店舗向けに非表示にし始めたのは2021年7月のことだ。WooCommerce 5.5では、コアに同梱されていた決済ゲートウェイが新規インストール時にデフォルトで読み込まれなくなり、必要ならばフィルターで再有効化する形に切り替わった。

このフィルターと同梱ゲートウェイ自体が完全に削除されたのはWooCommerce 8.9(2024年5月リリース)である。これ以降、PayPal Standardは「古い設定が残っている店舗」か「回避策のプラグイン」でしか生き延びられなくなっていた。今回のPayPal Payments 4.1.0は、その残存ケースを安全にアップグレードへ誘導する最終段階だ。

なぜこのタイミングなのか

PayPal StandardはAPIの進化に追随できない状態が続いていた。PayPal側が提供する最新のコンバージョン向上施策(Pay Later、Venmo、カード直接入力フィールドなど)を利用するには、PayPal Paymentsへの移行が不可避だった。事業者の売上機会を損なわないためにも、古い統合方式を整理する判断は合理的といえる。

PayPal Payments 4.1.0が実際に行うこと

PayPal Payments 4.1.0が実際に行うこと
STEP 1 PayPal Payments 4.1.0へアップデートするだけでは何も変わらない
STEP 2 事業者がPayPalアカウントをPayPal Paymentsに接続する(ここがトリガー)
STEP 3 PayPal Standardが自動的に無効化され、チェックアウト画面から消える
STEP 4 ただし有効な定期購入がある場合は、例外的にPayPal Standardが維持される

上記の流れで最も重要なのは、アップデート自体が自動的に何かを変えるわけではない点だ。事業者が自らアカウント接続を行うまでは、従来のPayPal Standardはそのまま動作し続ける。

サブスクリプション保護の設計

WooCommerceの開発チームは、特に継続課金への影響を慎重に設計している。店舗に「アクティブ」または「キャンセル保留中」の定期購入が存在し、それがPayPal Standardで稼働している場合、プラグインはそれを検知し、無効化をスキップする。購読者は引き続き請求を受け、事業者には「影響を受けるサブスクリプションの数と所在」が通知される仕組みだ。

この「まず守る、その後に通知する」という順序は、事業者の売上を止めないための実務的な配慮といえる。移行操作を急ぐあまり、課金が途切れるリスクを負う必要はない。

アップグレード準備ツールで事前確認を徹底する

アップグレード準備ツールで事前確認を徹底する
アップグレード準備ツールがチェックする項目
現在のPayPal統合方式 StandardかPaymentsか
バージョンの新しさ 古いままだと競合が発生する可能性
既知の競合 他のプラグインとの相性問題
サブスクリプションの有無 定期購入の追加注意が必要か
統合方式  バージョン  競合  定期購入
結果に基づく安心材料
読み取り専用でサイトに変更を加えない
問題があればサポートへ詳細を直接送信できる
自分で移行するか、サポートに任せるかを選べる

長期運用してきた店舗ほど、設定変更に対する不安は大きい。このツールはWordPress管理画面から操作でき、サイトには一切の変更を加えない読み取り専用設計だ。事前に「移行がどの程度スムーズに進むか」を把握してから行動に移せる点が最大の強みとなる。

なぜPayPal Paymentsへの完全移行が好機なのか

なぜPayPal Paymentsへの完全移行が好機なのか

現代のオンライン購入者は、決済ステップでのストレスにきわめて敏感だ。サイトから離れずに支払いを完了できるかどうかが、コンバージョン率を大きく左右する。PayPal Paymentsは、まさにこの「離脱させない体験」を軸に設計されている。

単一プラグインで得られる最新機能群

Pay Later(後払い)、Venmo(米国向け送金・支払いサービス)、カード情報の直接入力フィールドといった機能は、PayPal Standardでは利用できなかった。これらはすべて、単一のプラグインで管理できる。PayPalのAPI変更やWooCommerceのアップデートにも同期してメンテナンスされるため、事業者が個別に対応する手間は大幅に減る。

コアからの分離で保守性が向上

WooCommerce 8.9以降、PayPal Standardはコアに戻る道を完全に断たれた。これは一見すると制約に感じるが、実際には「今後改善されない古いコードに依存し続けるリスク」を取り除く意味がある。PayPal Paymentsに集約することで、決済まわりのコードベースはシンプルになり、トラブルシューティングもしやすくなる。

PayPal Standard利用者が今すぐ着手すべき3つのアクション

  • アップグレード準備ツールを実行し、現状のPayPal統合方式と注意点を把握する
  • WooCommerce用のPayPal Paymentsプラグインをインストールし、事業者アカウントを接続する
  • 定期購入を販売している場合、またはツールの結果に不明点があれば、WooCommerceサポートに相談する

アカウント接続が完了すれば、PayPal Standardからの移行はプラグインが安全に処理してくれる。人の手で設定を削除したり、手動で切り替えたりする必要はない。ツールの結果を踏まえて、確実に行動に移すことが重要だ。

この記事のポイント

  • PayPal Standardは2026年6月のPayPal Payments 4.1.0で役目を終え、条件を満たすと自動無効化される
  • アップデートだけでは何も変わらず、事業者が自らアカウントを接続するまでは安全に動作し続ける
  • 有効な定期購入がある場合は無効化がスキップされ、売上停止のリスクを回避する設計になっている
  • アップグレード準備ツールを使えば、サイトに変更を加えずに移行の準備状況を事前確認できる
  • PayPal Paymentsへの集約により、最新のコンバージョン機能と継続的なAPI同期の恩恵を受けられる
SiteGuard WP Pluginでwp-loginが表示される原因とMultiViewsの無効化手順

SiteGuard WP Pluginでwp-loginが表示される原因とMultiViewsの無効化手順

なぜ /wp-login/ でログイン画面が表示されてしまうのか

なぜ /wp-login/ でログイン画面が表示されてしまうのか

この現象は SiteGuard WP Plugin の仕様ではなく、サーバー環境に由来する問題だ。Apache の MultiViews 機能が有効になっていると、/wp-login/ へのアクセスが内部的に /wp-login.php にマッチしてしまい、ログイン画面が表示される。

MultiViews は Apache のコンテンツネゴシエーション機能の一部で、リクエストされたパスに拡張子がない場合に、サーバー側で適切なファイルを探し出して提供する仕組みだ。/wp-login(もしくは末尾スラッシュ付きの /wp-login/)を要求すると、Apache は wp-login.php という実ファイルを見つけて実行してしまう。これが根本の原因であり、ログインページ変更機能で隠しパラメータを追加しても、このフィルタをすり抜けてしまうケースが生まれていた。

実際に WordPress.org フォーラムで報告され、プラグイン開発者によってバージョン 1.8.4 で対策が施された。しかし /wp-login/任意の文字列(例:/wp-login/test)に対しては、引き続き MultiViews の影響でログイン画面が表示される可能性が残っている。完全に防ぐには、Apache 側で MultiViews を無効化する必要がある。

アクセスパターンと挙動の比較
Before(MultiViews 有効+SiteGuard 1.8.0〜1.8.3)
/wp-login/ → ログイン画面が表示される
/wp-login/test → ログイン画面が表示される
After(MultiViews 無効化+SiteGuard 1.8.4)
/wp-login/ → 404 ページが表示される
/wp-login/test → 404 ページが表示される
問題のある状態(MultiViews 有効)  対策後(MultiViews 無効)

このデモは MultiViews の有無によるアクセス結果の変化を示している。

SiteGuard WP Plugin 側の対策と残る課題

SiteGuard WP Plugin 側の対策と残る課題

バージョン 1.8.4 で /wp-login/ はブロック対象に

SiteGuard WP Plugin 1.8.4 では、内部的に /wp-login/ へのアクセスを捕捉し、ログインページ変更機能で指定した独自 URL 以外からのアクセスをブロックする処理が追加された。これにより、多くの環境で「/wp-login/」を直接叩かれてもログイン画面が表示されなくなった。

/wp-login/任意の文字列 は依然としてすり抜ける

しかし URL の末尾にさらにパスを付け足した /wp-login/something のようなアクセスは、プラグイン側の正規表現やルールでは補足しきれず、Apache の MultiViews がマッチする限りログインページを返してしまう。これはプラグインのバグというより、Web サーバーのモジュールが優先してしまう構造的な問題だ。

Apache で MultiViews を無効化する手順

Apache で MultiViews を無効化する手順

最も確実な対策は、Apache の設定で MultiViews を無効にすることだ。レンタルサーバーを利用している場合でも、.htaccess ファイルで制御できるケースが多い。

MultiViews 無効化の手順
STEP 1 FTP やファイルマネージャーで WordPress ルートの .htaccess を開く
STEP 2 ファイルの先頭付近に Options -MultiViews を追加
STEP 3 保存してサーバーにアップロード
STEP 4 シークレットウィンドウで /wp-login/ にアクセスし、404 になるか確認

この手順により、Apache が MultiViews を使ったファイルの自動解決を行わなくなり、/wp-login//wp-login/何らかのパス へのアクセスでログイン画面が表示されることはなくなる。

.htaccess の記述例

WordPress の標準的な .htaccess に組み込む場合は、以下のような形になる。Options -MultiViews はリライトルールよりも手前に書くのがセオリーだ。

# BEGIN WordPress
Options -MultiViews

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index\.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

MultiViews 無効化ができない場合の代替策

レンタルサーバーの制限で Options -MultiViews が許可されていない環境もまれにある。その場合は、より直接的なリダイレクトルールを追加して、/wp-login/ へのアクセスを 404 ページやトップページに飛ばす方法がある。

RewriteRule ^wp-login/ - [R=404,L]

このルールを .htaccess の RewriteEngine On の直後に追記すれば、/wp-login/ というパスで始まるリクエストすべてを 404 で返す。ただしリライトの優先順位によっては、他のルールと競合しないか必ずテストすること。

404 ページをブラウザ標準から WordPress テーマのものに切り替える

404 ページをブラウザ標準から WordPress テーマのものに切り替える

質問の中で「ブラウザ標準の 404 ページではなく、WordPress テーマ側の 404 ページに遷移させたい」という要望があった。SiteGuard WP Plugin 1.7.x 系では、ログインページ変更機能が動作すると WordPress の 404 テンプレートを表示する挙動だった。これが 1.8.x 系で Apache の標準エラー応答に変わったのは、プラグインの内部ロジックがより低レイヤーでリクエストを遮断するように再設計されたためだ。

WordPress テーマの 404 ページを表示させたい場合は、プラグイン任せにせず、Apache の ErrorDocument ディレクティブを利用する方法がある。ただし完全に同一の外観を保つのは難しく、セキュリティ上の観点からも、404 ページの表示にこだわるよりも「不正なアクセスをいかに早く遮断するか」に注力したほうが実用的だ。

よくある質問

SiteGuard WP Plugin のログインページ変更だけでは不十分なのか

ログインページ変更機能は、ボットによる辞書攻撃や自動スキャンの大半を防ぐ効果がある。しかしサーバー側の MultiViews のような特殊な設定が残っていると、その穴を突かれる可能性がゼロではない。基本はプラグイン任せ、より強固にしたい場合は MultiViews の無効化を組み合わせるのが現実的な落としどころだ。

MultiViews を無効にすると他の機能に影響はあるか

WordPress は基本、PHP ファイルを直接呼び出すスタイルで動作しているため、通常の運用で MultiViews が必須になることはほぼない。静的ファイルの MIME タイプや言語ネゴシエーションを使っている特殊なカスタマイズがなければ、影響は出ないと考えてよい。

Nginx 環境でも同じことは起きるのか

Nginx には Apache の MultiViews に相当する機能は標準で存在しないため、この問題は発生しない。Nginx の場合は try_files ディレクティブの設定ミスによって似た現象が起こることがあるが、原因はまったく異なる。

プラグインを最新にしたのに管理画面が 404 になることがある

SiteGuard WP Plugin の「管理ページアクセス制限」を有効にしていると、未ログイン状態で /wp-admin/ にアクセスするとサイトトップにリダイレクトされる。また「管理者ページからログインページへリダイレクトしない」設定を ON にしている場合のリダイレクト先も確認しておくと混乱が少ない。

この記事のポイント

  • /wp-login/ からのログイン画面表示は MultiViews が原因
  • SiteGuard WP Plugin 1.8.4 で基本対策は完了している
  • 根本解決には Apache の MultiViews 無効化が必要
  • .htaccess に Options -MultiViews を追加するだけで対処可能
  • 404 表示にこだわるより、アクセス遮断の仕組みを優先する
NextGEN GalleryでTrying to access array offset on null警告の原因と直し方

NextGEN GalleryでTrying to access array offset on null警告の原因と直し方

NextGEN Gallery(管理画面では「NextGEN Gallery」と表示)で「Trying to access array offset on null」というPHP警告が繰り返し出力される場合、原因はテンプレートファイル内で $thumb_size 変数がnullのまま配列としてアクセスされていることにある。テーマのfunctions.phpに一時的なnullチェックを追加するか、プラグインの該当テンプレートを直接修正することで警告を止められる。

なぜ「Trying to access array offset on null」が発生するのか

なぜ「Trying to access array offset on null」が発生するのか

この警告はPHP 7.4以降で追加された「配列オフセットへのnullアクセス」に関するエラーレベル通知だ。NextGEN Galleryの /templates/Thumbnails/index.php 110行目周辺では、サムネイル画像の幅と高さを次のように取得しようとしている。

$thumb_size['width']
$thumb_size['height']

通常 $thumb_size にはサムネイルサイズの設定が格納された配列が入るが、特定の条件下(ギャラリー設定の不整合、画像メタデータの欠落、プラグイン内部の処理順序による変数未代入)でnullになる。nullの変数に対して配列のキーでアクセスしようとすると、PHPは警告を発行する仕組みだ。

エラーの発生箇所を特定する手順

エラーの発生箇所を特定する手順

警告メッセージにファイルパスと行番号が含まれているため、どこで問題が起きているかは一目瞭然に思える。しかし実際には以下の点を確認しておくと、修正後の再発防止に役立つ。

Before エラー発生時の状態
$thumb_size = null;
echo $thumb_size[‘width’]; // PHP Warning
After nullチェック追加後
if (is_array($thumb_size)) {
  echo $thumb_size[‘width’];
}
エラー状態  修正後

上図のように、変数が配列であることを確認する is_array() チェックを入れるだけで警告は出なくなる。以下に具体的な修正方法を3つのレベルで示す。

デバッグモードで警告を可視化する

本番サイトでは警告が非表示設定になっていることも多い。問題を見逃さないために、一時的に wp-config.php を編集してデバッグモードを有効にする。

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);

WP_DEBUG_DISPLAY をfalseにすれば画面には警告が出ず、/wp-content/debug.log に記録される。警告の再現性を確認したら、必ず WP_DEBUG をfalseに戻すことを忘れないようにしよう。

管理画面からプラグインのバージョンを確認する

「プラグイン」画面でNextGEN Galleryのバージョンが最新かどうかを確認する。2026年6月現在、NextGEN Galleryはバージョン3系が主流で、多くのnull関連の警告はバージョンアップで修正されている。更新が可能であれば、まずプラグインの更新を実行するのが最も安全な対処法だ。

エラーログで発生頻度とパターンを見極める

警告が散発的なのか、特定のページ表示時のみなのかによって対応の緊急度が変わる。デバッグログを確認し、同じ警告が何度も出ているなら恒久的な修正が必要だ。特定のギャラリーページだけなら、そのギャラリーの設定に問題がある可能性が高い。

警告を止める3つの修正アプローチ

警告を止める3つの修正アプローチ

NextGEN Galleryのコアファイルを直接編集する方法、子テーマから上書きする方法、functions.phpでフィルターフックを使う方法の3つがある。サイトの運用方針に合わせて選んでほしい。

STEP 1 プラグインを最新版に更新する(最も安全)
STEP 2 それでも直らなければ index.php にnullチェックを追加
STEP 3 更新で上書きされるため、必要なら子テーマやフィルターで恒久対応

アプローチ1 プラグインのコアファイルを直接修正する

最も短期的で簡単な方法だ。ただしNextGEN Galleryが更新されると修正が上書きされるため、恒久的な対応にはならない。該当ファイルは以下にある。

wp-content/plugins/nextgen-gallery/templates/Thumbnails/index.php

110行目と111行目付近の $thumb_size['width']$thumb_size['height'] を、以下のように is_array() で囲む。

if (is_array($thumb_size)) {
    $width  = $thumb_size['width'];
    $height = $thumb_size['height'];
} else {
    $width  = 240; // デフォルトの幅
    $height = 160; // デフォルトの高さ
}

デフォルト値には、NextGEN Galleryの「ギャラリー設定 → サムネイル設定」で指定されているサイズを入れておくと、画像が崩れずに表示される。

アプローチ2 子テーマでテンプレートを上書きする

NextGEN Galleryはテーマによるテンプレート上書きをサポートしている。修正した index.php を以下のパスに配置すれば、プラグイン更新後も修正が維持される。

wp-content/themes/your-child-theme/nggallery/thumbnails/index.php

元の /templates/Thumbnails/index.php をコピーし、該当行にnullチェックを追加して保存するだけだ。子テーマを使っていない場合は、この機会に作成しておくと今後のカスタマイズにも役立つ。

アプローチ3 functions.phpで警告を抑制する(非推奨)

どうしてもテンプレートを修正できない事情がある場合は、警告そのものを表示させない方法もある。ただし根本解決ではないため、最終手段として理解しておくといい。

add_action('init', function() {
    if (defined('WP_DEBUG') && WP_DEBUG) {
        error_reporting(E_ALL & ~E_WARNING);
    }
});

このコードはWordPressのデバッグモードが有効な場合のみ警告レベルを下げる。しかし他の重要な警告も見逃すリスクがあるため、あくまで一時的な回避策として考えてほしい。

修正後も警告が消えない場合の追加チェック

修正後も警告が消えない場合の追加チェック

上記の修正を適用してもまだ警告が出るなら、キャッシュのクリアを試す。NextGEN Galleryは独自の画像キャッシュを持っており、テンプレートの変更がすぐに反映されないことがある。

NextGEN Galleryのキャッシュをクリアする

管理画面の「ギャラリー → その他のオプション → 画像オプション」にある「キャッシュをクリア」ボタンを実行する。さらにWordPress全体のキャッシュ(プラグインやCDNを使用している場合はそれらも含めて)をクリアすると、テンプレートの変更が確実に反映される。

nullが発生する根本原因を探る

$thumb_size がnullになるのは、ギャラリー設定や画像のアップロード時にメタデータが正しく生成されなかった場合に多い。管理画面から該当ギャラリーを開き、各画像の「メタデータを更新」を実行する。また、ギャラリー設定で「サムネイルサイズ」が未設定になっていないかも確認してほしい。

よくある質問

この警告を放置してもサイトは壊れないか

警告(Warning)はエラー(Fatal Error)と異なり、スクリプトの実行は継続される。サムネイル画像が一部表示されない可能性はあるが、サイト全体が停止することはない。ただし警告が大量に出力されるとデバッグログが肥大化し、サーバーのディスク容量を圧迫する原因になる。

NextGEN Gallery以外のプラグインでも同様の警告は出るのか

PHP 7.4以降では配列アクセスの扱いが厳格化されたため、古いプラグインやテーマで同様の警告が発生することがある。対象プラグインが更新されていない場合は、今回紹介したnullチェックの手法を応用して修正可能だ。

警告が debug.log に出続けて容量がいっぱいになりそうだ

WP_DEBUG_LOG をtrueにしたまま長期間放置すると、ログファイルが数GBに膨れ上がることがある。問題を特定したら速やかに WP_DEBUG をfalseに戻す。どうしてもデバッグを続ける必要があるなら、定期的にログローテーションを行うか、WP_DEBUG_LOG'/path/to/custom-debug.log' のように指定して管理しやすくするといい。

プラグインを更新したくない(カスタマイズが消えるのが怖い)

NextGEN Galleryのテンプレートを直接編集している場合、プラグイン更新で修正が上書きされる不安は理解できる。今回紹介した子テーマによるテンプレート上書きを使えば、プラグイン本体には手を加えずに済む。カスタマイズを維持したまま、コアのバグ修正やセキュリティアップデートだけを取り込める。

NextGEN Galleryの代わりになるプラグインはあるか

標準の「メディアとカテゴリー」を使ったギャラリー機能でも十分な場合や、Envira GalleryやFooGalleryといった代替プラグインも選択肢になる。ただしNextGEN Galleryは長年の実績があり、ギャラリー数が多いサイトでは移行コストを考慮する必要がある。

この記事のポイント

  • 「Trying to access array offset on null」はPHP 7.4以降の厳格化による警告
  • NextGEN Galleryの /templates/Thumbnails/index.php$thumb_size がnullになるのが原因
  • is_array() によるnullチェックで警告を止められる
  • 子テーマでテンプレートを上書きすればプラグイン更新後も修正が維持される
  • 修正後はNextGEN GalleryのキャッシュとWordPress全体のキャッシュをクリアする
ドイツ裁判所、GoogleのAI回答に責任認定。SEO業界に衝撃

ドイツ裁判所、GoogleのAI回答に責任認定。SEO業界に衝撃

ドイツのミュンヘン地方裁判所が2026年5月28日、GoogleのAI Overviewが生成した虚偽の内容についてGoogle自身に責任があるとの仮処分を下した。AIが生成した回答は「プラットフォーム自身の発言」であり、単なる検索結果の羅列ではないという判断だ。この判決はSEOの前提を変える可能性を秘めている。

問題の核心は「AIがビジネスについて語るとき、誰が責任を負うのか」という問いだ。今回の判断は、AI回答が単なる情報の仲介ではなく「独自の編集行為」であると認定した点で画期的だ。つまり検索エンジンは自らが生成した文章に対して法的責任を問われうる時代に入った。この変化は企業のAI対策に根本的な再考を迫る。

裁判所がAI回答を「独自の編集物」と認定した意味

裁判所がAI回答を「独自の編集物」と認定した意味

ミュンヘン地方裁判所が下した仮処分(事件番号26 O 869/26)は、GoogleのAI Overviewが2つの地域出版社について虚偽の説明を生成したことを問題視した。AI Overviewはこれらの出版社を詐欺やサブスクリプション詐欺と結びつける文章を生成していたが、引用元として示された情報源のどこにもそのような記述は存在しなかった。

AI Overview(AIによる検索結果の概要表示)とは、検索クエリに対してGoogleが従来のリンク一覧ではなく、AIが生成した要約文を画面上部に表示する機能だ。複数の情報源を読み込んで独自の文章を合成する仕組みで、2024年から本格展開が始まっている。

裁判所はこのAI Overviewについて「独立した新規の実質的な主張を生成している」と評価し、通常の検索結果一覧に適用される免責保護の対象外だと判断した。Google側は「ユーザー自身が回答の正確性を確認すべき」と主張したが、裁判所はこれを退けた。機械が文章を書くなら、その機械の所有者が責任を負うという理屈だ。

従来の検索結果表示(Before)
検索エンジン リンク一覧を提示 ユーザー 自身で情報を判断
プラットフォームは「情報の仲介者」として免責されていた
AI Overview表示(After)
Google AIが独自の文章を生成 虚偽情報 を提示
裁判所「これはプラットフォーム自身の発言であり免責対象外」
免責なし(AI生成は自己責任)  免責あり(従来の検索結果一覧)

このデモが示すように、AI Overviewは従来の検索結果一覧とは法的な位置づけが根本的に異なる。裁判所は情報を「編集し合成する行為」を著作行為とみなし、そこに責任を紐づけたのだ。

この判決が持つ射程の広さ

今回の判断はあくまでドイツの一地裁による仮処分であり、EUの法的枠組みの中で下されたものだ。米国の裁判所が同じ事案を扱えば、プラットフォームを免責された仲介者とみなす従来の考え方から異なる結論に至る可能性は十分にある。ただ方向性は明確だ。AIが自律的に文章を生成する時代において、単なる「情報の受け渡し役」という位置づけは成立しなくなりつつある。

Search Engine Journalの記事では、この判決を1週間前に発表された別の調査結果と並べて論じている。その調査とは「AIに名前を挙げられることと、AIに信頼されることは別である」という分析だ。AI回答におけるビジネスの表現は、信頼の問題であると同時に説明責任の問題でもある。両方の視点が重なったとき、企業に求められる対応の輪郭が浮かび上がる。

責任を負うAIは「慎重になる」という構造的変化

責任を負うAIは「慎重になる」という構造的変化

法的責任を問われる可能性があるAIは、リスクを避けるために振る舞いを変える。これが今回の判決がもたらす最大の二次的影響だ。

AI回答が自社の発言として扱われるなら、プラットフォームが取る合理的な行動は「突然正確になること」ではない。「慎重になること」だ。確実に裏付けが取れるビジネスだけを安全圏として提示し、曖昧な存在は言及そのものを避けるようになる。この変化はすでに兆候を見せている。小規模な企業や評価が分かれる事業についてAIに質問すると、回答が急に歯切れが悪くなり、公式情報源に委ねたり、企業の特徴づけを完全に回避したりするケースが増えている。

AIが確信を持てないビジネス(リスクあり)
Q「〇〇社は信頼できますか?」
AI回答「複数の情報源がありますが、公式な確認が取れません。ご自身での確認をお勧めします」
← 言及そのものを回避する傾向が強まる
AIが確信を持てるビジネス(安全圏)
Q「△△社の主力製品は?」
AI回答「△△社は〇〇を提供しています。公式サイトではXXと記載されています」
← 一貫した情報があれば積極的に言及される
AIが言及を回避する領域  AIが積極的に言及する安全圏

この変化は「どうやってAIに正しく自社を引用させるか」という問いを「AIが自信を持って名前を出せるビジネスかどうか」という一段上の問いに引き上げる。機械可読なアイデンティティの整備は、もはやSEOの一手ではなく参加資格そのものに近づく。

AIがビジネスを「疑う」4つの原因

Search Engine Journalの記事でCarlo Daniele氏が指摘するように、大半のビジネスはAIに疑念を抱かせる材料を少なくとも一つは抱えている。具体的には以下の4パターンだ。

  • 法的実体の不一致:自社サイト、SNSプロフィール、過去のプレス記事で会社名や事業者名が微妙に異なる。AIはどれが正規情報か判断できない
  • 役職表記のズレ:会社概要ページと過去のインタビュー記事で創業者の役職表記が食い違っている
  • テキスト化されていない重要情報:製品の具体的な機能説明が画像やPDFの中にしか存在せず、AIのパーサーが読み取れない
  • カテゴリの曖昧さ:人間が読めば事業内容が明確でも、マークアップ上でカテゴリが明示されておらず機械が判断できない

これらはいずれも従来のコンテンツSEOの発想では見過ごされてきた問題だ。記事が指摘するように、これはコンテンツの問題ではなくアイデンティティの問題である。1万語のコンテンツがあっても自己矛盾した情報を発信していればAIはそのビジネスを「検証困難」と判定する。一方で簡潔でもあらゆる読み取り経路で同一の事実を返すビジネスはAIにとって「引用可能」と判断される。

AIに「確信されるビジネス」になるための実践手順

AIに「確信されるビジネス」になるための実践手順

この変化に対応するために法律家は必要ない。必要なのはAIに「このビジネスは確かだ」と判断させるための基盤整備だ。Search Engine Journalの記事で提示された3ステップを具体的に見ていく。

ステップ1 AIが自社をどう語っているか監査する

まずは自社ブランド名、製品名、事業カテゴリを実際に顧客が使うAI検索エンジンに投入し、生成される回答を第三者の目で読む。AI OverviewだけでなくChatGPTやClaudeなど複数のエンジンで確認することが重要だ。エンジンごとに回答は異なり、そのズレの大きさこそが自社のアイデンティティ監査の出発点になる。

チェックすべき項目は以下の4つだ。AIが自社のカテゴリを正しく述べているか、正しい製品を帰属させているか、正しい人物名を挙げているか、そして実際には無関係なネガティブ情報と結びつけていないか。Search Engine Journalの記事によれば、大半の企業はこのような監査を一度も実施したことがないという。

STEP 1 ブランド名・製品名・カテゴリをAI検索に入力
STEP 2 複数エンジンで回答を比較(Google・ChatGPT・Claude等)
STEP 3 カテゴリ・製品・人物・ネガティブ情報の4項目を検証
STEP 4 エンジン間のズレを監査レポートとして記録

この監査は企業のAI上の立ち位置を可視化する最初の一歩だ。自社がどのように語られているかを把握せずに対策を立てることはできない。

ステップ2 AIが判断の根拠にする事実情報を整備する

監査で発見されたズレを修正するには、AIが参照する基盤情報の整備が不可欠だ。Search Engine Journalの記事で提唱されているMachine-First Architecture(機械優先アーキテクチャ)の考え方では、以下の3つが中核となる。

第一に、Organization構造化データの実装だ。自社が誰で、何をしており、どこで確認できるかを機械可読な形式で明示する。構造化データ(Schema.orgに準拠したマークアップ)とは、HTMLに埋め込む形で検索エンジンに情報の意味を伝える仕組みであり、AIが情報を正確に抽出するための土台となる。

第二に、全情報発信チャネルでの表記統一だ。自社サイト、Googleビジネスプロフィール、主要SNS、業界ディレクトリで社名・住所・事業内容の表記を完全に一致させる。バリエーションがあるたびにAIは「どれが正しいか」の判断を強いられ、リスク回避のために言及を控える方向に傾く。

第三に、テキスト化の徹底だ。画像やPDFに埋め込まれた重要情報をHTMLテキストとしても提供し、AIのパーサーが確実に読み取れる形にする。特に事業内容の明示的な説明は、人間向けのデザイン性よりも機械向けの明快さを優先すべき局面に入っている。

ステップ3 監査を習慣化する

企業情報は時間とともに変化し、周囲のウェブ環境も変わり、AIモデルも再学習を繰り返す。一度整備して終わりではなく、定期的にAIが自社をどう語っているかを確認する習慣が必要だ。Search Engine Journalの記事はこれを「自社のアナリティクスを確認するのと同じ感覚で」行うべきだと提案している。

訴訟そのものは稀であり管轄も限られる。しかし構造的な影響はゆっくりと確実に広がる。AI回答にリスクが伴うとき、エンジンは慎重になり、慎重なエンジンは裏付けの取れるビジネスだけを積極的に提示する。企業に求められるのは「機械に確信される存在」になるための継続的な努力だ。

この記事のポイント

  • ミュンヘン地方裁判所がAI OverviewをGoogle自身のコンテンツと認定し免責を否定した
  • AI回答に法的責任が生じるとプラットフォームは「慎重になり言及を避ける」方向に動く
  • 企業名・役職・事業内容の表記不一致がAIの信頼を損ねる主要因である
  • 構造化データの実装と全チャネルでの情報統一がAI時代の基盤対策となる
  • AIによる自社の語られ方を定期的に監査する習慣が不可欠だ