WooCommerce 11.1で注文撤回機能が登場、14日以内の自己対応を実現
WooCommerce 11.1に注文撤回（Order Withdrawal）機能が追加された。EU域内の消費者が持つ14日間の契約撤回権に対応するための仕組みで、顧客が店舗にメールや電話で問い合わせることなく、注文から14日以内であれば自分で撤回リクエストを送信できるようになる。
この機能は既定では無効化されている。すべてのストアに必要な機能ではないため、事業者が設定画面から明示的に有効化する方式だ。顧客向けのリクエストフォーム、自動確認メール、店舗側の通知まで一連のフローが組み込まれている。
本記事では注文撤回機能の概要、有効化の手順、顧客と店舗それぞれの画面で何が起きるのかを解説する。EU向けに販売するストア運営者は特に確認しておきたい内容だ。
注文撤回機能とは何か
注文撤回機能は、EUの消費者保護規則で定められた「注文撤回権」に対応するための機能だ。EU域内の消費者は、商品やサービスを注文した日から14日以内であれば、理由を説明せずに契約を撤回する権利を持つ。従来はこの手続きをメールや電話で行う必要があり、店舗側も個別に対応する必要があった。
EUの14日間撤回権とは
14日間の撤回権はEU消費者権利指令に基づく制度で、オンライン購入を含む通信販売に適用される。消費者は商品を受け取った日から14日以内に撤回を申し出ることができ、事業者は返金に応じる義務を負う。この規則はEU域内の消費者との取引に適用されるため、日本からEU向けに販売するストアも対象になりうる。
重要なのは、注文撤回機能は法的手続きの自動化ツールであって、コンプライアンスを保証するものではないという点だ。WooCommerce Developer Blogの記事でも、事業の内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。
従来の対応との違い
従来のフローでは、顧客がメールや電話で撤回の意思を伝え、店舗担当者が手動で注文を確認し、返金処理を行っていた。この方式には対応漏れや記録不足のリスクが伴う。注文撤回機能は、顧客が自己対応フォームからリクエストを送信し、システムが自動で記録と通知を行う。
このデモで示した違いは大きい。顧客からの撤回リクエストがシステムに記録され、確認メールが自動送信されることで、店舗と顧客の双方に証跡が残る。対応の属人化を防ぎ、処理の一貫性を保てる。
有効化の手順
注文撤回機能は既定では無効化されている。EU向け販売を行っていないストアでは不要な機能のため、必要な事業者だけが有効化する設計だ。設定はWooCommerceの管理画面から数ステップで完了する。
設定画面での操作
WooCommerceの設定画面を開き、詳細設定タブから機能セクションに移動する。そこに注文撤回のオプションが表示されるので、有効化して変更を保存するだけだ。設定完了後、顧客向けのリクエストフォームが /my-account/withdraw-order というURLで公開される。
エンドポイントのカスタマイズ
リクエストフォームのURLは変更できる。詳細設定のページ設定セクションでエンドポイントを編集すれば、自社の導線に合わせたURLに調整できる。標準のURLは /my-account/withdraw-order だ。
もう1つの重要な特徴として、このページはログイン状態に関わらず動作する。ゲスト購入した顧客でもフォームにアクセスしてリクエストを送信できる。EUの撤回権はゲスト購入者にも適用されるため、この設計は実務上欠かせない。
顧客から見た注文撤回フロー
顧客が注文撤回ページにアクセスすると、短いリクエストフォームが表示される。必要な情報を入力し、送信前に内容を確認する画面を経てから送信する。送信後は確認画面が表示され、入力した内容を含む確認メールが自動的に届く。
この4ステップのフローは、顧客が自分の操作だけで撤回リクエストを完了できることを示している。確認メールには顧客が入力した内容が含まれるため、顧客はリクエストの記録を残せる。店舗側への電話やメールが不要になり、双方の手間を削減する。
確認メールが自動送信される点は法的にも意味がある。撤回権の行使を顧客が証明できる記録が残るため、後日のトラブルを防ぐ効果が期待できる。
店舗運営者から見た通知と管理
顧客がリクエストを送信すると、店舗運営者には2つの経路で通知が届く。1つは撤回リクエストを知らせるメール通知、もう1つはWooCommerceホーム画面のインボックス通知だ。この二重の仕組みにより、リクエストの見落としを防ぐ。
リクエスト内容に含まれる注文番号と請求先メールアドレスが既存の注文と一致する場合、リクエストは自動的にその注文に紐付けられ、注文メモが追加される。これにより、店舗担当者は注文詳細画面からリクエストの存在を確認できる。
一致する注文が見つからない場合でも、リクエスト自体は受け付けられ、顧客には確認メールが送信される。通知には手動確認が必要であることを示すフラグが付けられ、注文へのリンクはスキップされる。この設計により、注文番号の入力ミスやゲスト購入の注文でも、リクエストが拒否されることはない。
重要な点として、撤回リクエストの送信は注文ステータスを変更しない。注文が自動的にキャンセルされたり、返金が実行されたりすることもない。リクエストはあくまで「撤回の申し出」であり、その後の対応（返金の承認、商品返送の依頼、追加情報の確認など）は店舗側の判断に委ねられる。
導入前に確認すべき注意点
注文撤回機能は店舗運営の効率化に寄与するが、いくつかの注意点がある。まず、この機能がEUの法的要件への準拠を保証するわけではないという点を理解しておく必要がある。WooCommerce Developer Blogの記事でも、事業内容や顧客の所在地に応じて法律専門家に相談するよう明記されている。
リクエスト処理のワークフロー設計
撤回リクエストが届いた後の対応フローは、店舗自身で設計する必要がある。返金を承認するのか、商品の返送を求めるのか、追加情報を確認するのか。これらの判断基準を事前に決めておかないと、リクエストが届いてから担当者が迷うことになる。
特に、注文ステータスが自動変更されない点は運用上のポイントだ。リクエストが届いても注文は「処理中」などの状態のまま残るため、店舗側で明示的に注文をキャンセルする処理が必要になる。この部分を社内で共有しておかないと、注文が放置されるリスクがある。
ゲスト購入への対応
ログインしていない顧客でもリクエストを送信できる設計は、ゲスト購入が多いストアにとって重要な特徴だ。ただし、ゲスト購入の注文は注文番号とメールアドレスの照合が手動になる可能性がある。手動確認フラグが付いたリクエストを担当者が見逃さないよう、通知の確認ルールを決めておく必要がある。
実務的には、EU向け販売を行うストアにとって注文撤回機能は顧客対応の手間を大幅に減らす可能性がある。メールや電話での個別対応から、システム化されたリクエスト処理へ移行することで、対応の一貫性と記録の完全性が向上する。一方で、リクエスト受信後のワークフローが未整備のままでは、かえって対応が遅れるリスクもある。
注文撤回機能は、WooCommerce 11.1の新機能としてEU対応ストアに実用的な選択肢を提供する。導入を検討する場合は、機能の有効化だけでなく、社内の対応フローまで含めて計画することをおすすめする。
この記事のポイント
- WooCommerce 11.1に注文撤回機能が追加され、顧客が自己対応で撤回リクエストを送信できる
- EUの14日間撤回権に対応する仕組みで、既定では無効化されている
- 顧客はフォーム入力から確認メール受信まで自動フローで完了できる
- 店舗にはメールとインボックスの二重通知が届き、注文への自動リンクも行われる
- 注文ステータスは自動変更されないため、受信後のワークフロー設計が必要
WooPaymentsでカード追加ページが真っ白になる原因と解消手順
WooCommerceでWooPaymentsを使っているサイトで、購入時のカード保存は正常に動くのにマイアカウントのカード追加ページだけが真っ白になる場合、多くはJavaScriptエラーかプラグインによるテンプレート競合が原因だ。開発者ツールでエラーの実体を特定し、プラグインとテーマの切り分けを順に行うと短時間で解消できる。
なぜカード追加ページだけが真っ白になるのか
WooPaymentsのカード入力フォームは、チェックアウト画面でもマイアカウント内でもJavaScriptで動的に描画される。特にカード追加ページでは、WooPaymentsが提供するStripe Elementsという入力部品を読み込んでフォームを生成する仕組みだ。
このとき、他のプラグインが読み込むスクリプトと衝突したり、テーマがマイアカウントのテンプレートを上書きしてフォームの置き場所が消えたりすると、ページが真っ白に見える。PHPの致命的エラーが起きている場合も同様の症状になる。
保存済みカードの一覧表示は正常なのにカード追加だけが空になるのは、表示に異なる読み込み経路が使われるためだ。一覧はすでにデータベースへ保存された情報をPHPだけで描画できるが、カード追加フォームはJavaScriptの実行が必須になる。だからこそ、スクリプトエラーが症状としてそのページだけに出やすい。
また、WooPaymentsのアップデート時にファイルの一部が欠けた場合もフォームが表示されない。エラーがどこにも出ないまま空白だけになるケースでは、プラグイン本体の再インストールも選択肢に入る。
ブラウザの開発者ツールでエラーを特定する手順
まず最初に、ブラウザの開発者ツールを使って実際に何が止まっているのかを確認する。エラーが特定できれば、その後の切り分けが大幅に短くなる。
このデモは、エラー特定までの基本フローを示している。コンソールとネットワークの両方を確認すると原因ファイルが見つかりやすい。
コンソールでJavaScriptエラーを確認する
カード追加ページを開いた状態でF12キーを押し、「コンソール」タブを開く。赤い文字で表示されるエラーが1件以上あれば、その内容を控えておく。英語表示の場合は「Uncaught TypeError」や「Failed to load resource」のような記述が手がかりになる。
エラーの右側に表示されるファイル名も重要だ。どのプラグインのスクリプトが失敗しているかが分かれば、無効化の対象を特定できる。たとえば `woocommerce.js` や `stripe.js` が読み込めていなければ、キャッシュやプラグイン本体の問題を疑う。
ネットワークタブで読み込み失敗を確認する
同じく開発者ツールの「ネットワーク」タブを開き、ページを再読み込みする。ステータスが「404」や「500」になっているファイルがないかを確認する。404はファイルが存在しない、500はサーバー処理の失敗を意味する。
とくにカードフォームの描画に必要なJavaScriptファイルが404になっていると、ページが白いまま何も表示されない。この場合はWooPaymentsのファイルが不完全な可能性が高い。
プラグインとテーマの競合を切り分ける手順
開発者ツールで原因が特定できない場合は、定番の切り分け作業を順に行う。目的は、どのプラグインまたはテーマがカード追加ページの表示を妨げているかを絞り込むことだ。
切り分け前
全プラグインが有効のまま「カード追加」を開くと
ページが真っ白でフォームが表示されない
どのプラグインが影響しているか不明
切り分け後
WooCommerceとWooPaymentsだけを有効にすると
カード入力フォームが正常に表示される
原因プラグインをひとつずつ有効化して特定できる
このデモは、プラグイン競合の切り分け前後で何が変わるかを示している。競合元を特定しなければ恒久的な解決にはならない。
全プラグインを無効化してWooCommerce系だけ有効化する
管理画面の「プラグイン」へ移動し、(WooCommerceとWooPayments以外の)すべてのプラグインを無効化する。この状態でカード追加ページを開いてフォームが表示されるか確認する。
フォームが表示された場合は、無効化したプラグインをひとつずつ有効化して、どのプラグインを有効にした時点で再発するかを確認する。マイアカウントの表示をカスタマイズするプラグインや、管理画面用のスクリプトを全ページに読み込むプラグインが原因になりやすい。
この作業で一時的にサイト機能が変わるため、アクセスの少ない時間帯に行うか、ステージング環境があればそちらで再現させる。WooCommerceとWooPaymentsは必ず有効のままにして検証する。
標準テーマに切り替えてテーマの影響を除外する
プラグインをすべて無効化しても症状が続く場合は、テーマが原因の可能性がある。管理画面の「外観」→「テーマ」で、Twenty Twenty-FourなどのWordPress標準テーマへ一時的に切り替える。
標準テーマでカード追加フォームが表示されるなら、元のテーマがマイアカウントのテンプレートを上書きしていることになる。テーマに含まれる `woocommerce` フォルダの `myaccount` 関連ファイルが、カード追加ページの表示を妨げているケースが多い。
テーマを切り替えるとウィジェットやカスタマイズ設定が変わることがあるため、検証後は必ず元のテーマへ戻す。できればステージング環境での検証を推奨する。
WooPaymentsの設定とパーマリンクを再確認する
切り分けを行っても原因が見つからない場合、WooCommerceの設定とパーマリンクを再確認する。設定が正しくても保存し直すだけで直るケースがある。
カード追加エンドポイントの設定を保存し直す
管理画面の「WooCommerce」→「設定」→「詳細設定」タブを開き、「アカウントエンドポイント」欄を確認する。カード追加の項目が正しく入力されていることを確認し、入力内容そのものに変更がなくても一度「変更を保存」を押す。
パーマリンクの内部マップがずれていると、ページ自体は存在してもWooCommerceがエンドポイントを認識できないことがある。保存し直すだけでマップが再構築されるため、手軽に試せる。
保存済みカード決済の設定を確認する
「WooCommerce」→「設定」→「決済」タブでWooPaymentsを開き、「カード決済」が有効であることと「保存済みカードによる支払いを有効にする」にチェックが入っていることを確認する。購入時のカード保存は正常でも、この設定が外れるとマイアカウントからの追加だけが動作しないことがある。
パーマリンクを更新してエンドポイントを再マップする
管理画面の「設定」→「パーマリンク」へ移動し、設定を変更せずそのまま「変更を保存」を押す。これでリライトルールが再生成され、マイアカウントの各エンドポイントが正しく認識されるようになる。
パーマリンク更新後は必ずキャッシュプラグインのキャッシュを全削除する。キャッシュが残っていると、古い状態のページが配信されて症状が続いているように見える。
再発を防ぐための更新前チェックとログ確認
根本解決できたら、次回のアップデートで同じ問題が起きないように更新前チェックの習慣をつけておく。WooPaymentsは更新頻度が高いプラグインのため、更新後に特定のページだけが壊れるリスクは常にある。
WooCommerceのログでPHPエラーを確認する
管理画面の「WooCommerce」→「ステータス」→「ログ」タブを開き、直近のエラーログに「fatal-errors」のようなファイルがないかを確認する。PHPの致命的エラーが記録されていれば、その内容から原因ファイルを特定できる。
ログが存在しない場合は、WooPaymentsの「ログ」タブから決済関連の動作記録を確認する。カード追加フォームの読み込みに失敗した形跡がないかを探る。
WooPaymentsのファイルを再アップロードする
アップデート時にファイルの一部が欠けた疑いがある場合は、管理画面からプラグインを削除して再インストールする。その際、決済データはサーバー側に保存されているため、プラグインの削除で売上情報や顧客情報が消えることはない。
FTP接続でWooPaymentsのフォルダだけを最新版のファイルで上書きする方法もある。管理画面に入れる状態なら「プラグイン」→「プラグインの新規追加」からWooPaymentsを検索して入れ直す方が確実だ。
マイアカウント系ページをキャッシュ対象から除外する
キャッシュプラグインの設定で、マイアカウント関連のURLをキャッシュ対象から除外しておく。具体的には `/my-account/` で始まるパスを除外リストへ追加する。これにより、カードフォームや認証情報が古いキャッシュで表示される問題を防げる。
よくある質問
カード追加ページだけが真っ白になるのはなぜ？
そのページだけテンプレートやJavaScriptが干渉されている可能性が高い。WooPaymentsのカード入力フォームはJavaScriptで描画されるため、他のプラグインのスクリプトが衝突するとフォームが生成されず真っ白に見える。
開発者ツールにエラーが表示されない場合は？
コンソールにエラーが出ない場合、PHPの処理途中で止まっている可能性を疑う。wp-config.phpでデバッグを有効にしてエラーを可視化するか、WooCommerceのログを確認する。あわせてテーマのマイアカウント用テンプレートが正しいかも調べる。
WooPaymentsのバージョンを一つ前へ戻すと直る？
互換性が問題の場合は直ることがある。バージョン固定のダウングレードは応急処置として有効だが、セキュリティ更新を含む場合は推奨しない。まず競合の特定を優先し、どうしても手がかりがない場合に実施する。
キャッシュプラグインが原因になることはある？
ある。特にマイアカウント系のページをキャッシュしてしまう設定だと、カードフォームの読み込みだけが古い状態で配信されることがある。キャッシュ対象からマイアカウントを除外する設定も併せて確認する。
マイアカウントの表示をカスタマイズするプラグインは原因になりやすい？
なりやすい。カード追加ページのテンプレートやフックを書き換えるタイプのプラグインは、WooPaymentsのフォーム表示に直接影響する。無効化して症状が消えるかどうかを最初の切り分けで確認する。
この記事のポイント
- 開発者ツールのコンソールでJavaScriptエラーを特定する
- 全プラグインを無効化してWooCommerce系だけ有効化して切り分ける
- 標準テーマに切り替えてテーマ競合を除外する
- パーマリンクとエンドポイント設定を保存し直す
- WooPaymentsを再インストールしてファイルの健全性を回復する
- マイアカウント系ページをキャッシュ対象から除外する
Cloud Run instances登場！AIエージェントを月額6ドル弱で常時稼働
Google Cloudが2026年8月27日、常時稼働するAIエージェント向けの新サービス「Cloud Run instances」をプレビュー公開した。サーバーレスの利便性を保ちながら、単一インスタンスを長期間動かし続けるための専用ランタイムだ。
1vCPU・1GiBメモリの構成なら、30日間連続稼働して月額5.70ドル。従来の専用VMと比較すると運用コストと管理負担を大幅に抑えられる。
パーソナルAIエージェントを自宅のPCや専用サーバーで動かしていた開発者にとって、クラウド移行の有力な選択肢になる。本記事ではCloud Run instancesの特徴、料金構造、実際のデプロイ手順までを解説する。
Cloud Run instancesの基本と既存サービスとの違い
Cloud Run instancesは、Google Cloudのサーバーレスコンテナ基盤であるCloud Runの新しい実行モードだ。既存のCloud Run servicesが高スループットなWebサービス向けに設計されているのに対し、Cloud Run instancesは「1つのインスタンスを確実に動かし続ける」ことに特化している。
主な特徴は次の4つにまとめられる。
- オートスケーリングなしの単一インスタンスのみを実行する
- 最大7日間の連続実行と自動再起動ポリシーを標準で備える
- 更新や再起動後も変わらない固定HTTPS URLが発行される
- 使わないときは停止し、必要なときに再開できる
3つの実行環境の違いを比較した図だ。Cloud Run instancesは既存Cloud Runと専用VMの中間的な位置づけで、サーバーレスの手軽さと常時稼働の確実性を両立している。
既存のCloud Run servicesとの決定的な違い
Cloud Run servicesは、リクエストが途絶えるとインスタンスがスケールゼロになる。これは高トラフィックなWeb APIには効率的だが、常に1つのコピーが動き続けることを期待するAIエージェントには不向きだ。一方、Cloud Run instancesはオートスケーリングを行わず、指定した設定のインスタンスを1つだけ動かし続ける。これが最大の設計上の違いになる。
なぜAIエージェントに最適なのか
OpenClawやHermesといったパーソナルAIエージェントは、継続的に動作し、通常は一度に1人のユーザーにしかサービスしない。これらの特性は、ステートレスな高スループットWebサービスとはインフラ要件が大きく異なる。
OpenClawは、ユーザーの代わりにさまざまなタスクを実行するオープンソースのパーソナルAIエージェントだ。使うほど学習して賢くなる。多くのOpenClawユーザーは最初に自分のノートPCで実行し始めるが、ノートPCがスリープするたびに停止してしまう問題に直面する。ここでクラウド上の常時稼働環境が必要になる。
従来の選択肢の問題点
専用VMを借りる方法もあるが、24時間365日の課金、OSのアップデート管理、ファイアウォールのポート開放、HTTPSエンドポイントの構築といった手間が発生する。Cloud Run instancesはこれらの管理タスクをクラウド側に任せつつ、低コストで常時稼働を実現する。
ここでのポイントは、AIエージェントのワークロードが「バースト型」であることだ。普段は待機状態でCPUをほとんど使わず、ユーザーが指示を出した瞬間だけ計算リソースを消費する。共有vCPUとバーストバジェットによる課金モデルは、このバースト型の特性と相性が良い。常時フルパワーのCPUを確保する必要がないため、価格を抑えられる。
料金とコスト構造の分析
1vCPU・1GiBメモリのCloud Run instanceを30日間連続稼働させた場合のコストは5.70ドル。共有vCPUとvCPUバーストバジェットを利用して、低く予測可能な価格で連続実行を実現している。
従来の専用VMと比べると、クラウド料金に大きな差がある。30日間連続稼働でわずか5.70ドルという価格は、個人開発者が気軽に試せる水準だ。
価格設定の分析
5.70ドルという価格は、パーソナルAIエージェントの利用シーンを想定した戦略的な設定だ。個人開発者がノートPCの代わりにクラウドでAIエージェントを常時稼働させるには、月額10ドル以下という心理的なハードルが大きい。Cloud Run instancesはこの価格帯を実現したことで、パーソナルAIエージェントのクラウド移行を加速する可能性がある。
OpenClawデプロイの実践手順
OpenClawをCloud Run instancesにデプロイする手順はシンプルだ。設定ファイルをCloud Storageバケットにアップロードした後、1つのコマンドを実行するだけでデプロイが完了する。
デプロイ後のOpenClawは、使いたい限り動かし続けられる。メッセージングアプリと接続してタスクを任せることも、必要なツールと連携させることも可能だ。
SSHアクセスと今後のアップデート
Cloud Run instancesとCloud Run servicesの両方で、SSHアクセス機能が近日中に提供される予定だ。これにより、実行中のコンテナに直接ログインしてデバッグや設定変更ができるようになる。詳しい手順はCloud Runのcodelabで公開されている。
ユーザー事例と今後の展望
OffDeal社の導入効果
中小企業向けのAI投資銀行を提供するOffDealは、Cloud Run instancesを長期間稼働するエージェントの主要インフラとして利用している。OffDeal社のLuis Ruiz Morel氏によれば、コールドスタートが88%削減され、実装も非常にシンプルで信頼性が高いとのことだ。
コールドスタート88%削減とは、エージェントが待機状態からタスクを開始するまでの起動時間が大幅に短縮されたことを意味する。AIエージェントの応答性がビジネス成果に直結するユースケースでは、この改善は大きな価値となる。
プレビューからGAへ
Cloud Run instancesは現在プレビュー段階で、パフォーマンスを犠牲にせずに新しい種類のワークロードをコスト効率よく実行する手段として提供されている。今後、GA（一般提供）への移行とともに、より多くのAIエージェントワークロードがこの基盤に集約される可能性がある。
Cloud Run instancesの登場は、サーバーレスコンピューティングの適用範囲を「常時稼働するステートフルなワークロード」にまで広げる動きとして捉えられる。従来のサーバーレスは「イベント駆動・ステートレス・短期実行」が前提だったが、AIエージェントのような新しいワークロードの台頭が、この前提を変えつつある。Google Cloudがこのニーズに素早く応えた形だ。
この記事のポイント
- Cloud Run instancesは常時稼働するAIエージェント向けの新しいサーバーレス実行環境
- 単一インスタンスのみ、オートスケーリングなし、最大7日間連続実行
- 1vCPU・1GiBメモリで30日間連続稼働して月額5.70ドル
- 固定HTTPS URLが提供され、停止・再開も自由
- OpenClawを1コマンドでデプロイ可能
- 近日中にSSHアクセス機能が追加予定
hCaptcha 5.2.0更新後にログインできない時の対処法とダウングレード手順
hCaptcha プラグインを 5.2.0 に更新した直後からログイン画面に「Bad hCaptcha signature!」と表示され、管理画面へ入れない場合は、5.1.0 へのダウングレードと全キャッシュの削除で解決する。この不具合は 5.2.0 の署名検証リグレッションが原因で、サイトキーやシークレットキーの設定ミスではない。
なぜhCaptcha 5.2.0への更新後にログインエラーが起きるのか
hCaptcha 5.2.0 はログイン時の署名形式を変更している。署名とは、データが改ざんされていないことを証明する値のことだ。この変更が原因で署名検証フローにリグレッション（回帰不具合、以前は正常だった機能が更新によって壊れること）が混入した。
WordPress のログイン統合と別のログイン統合が、同じ wp-login.php エンドポイントを通じて送信される際に署名の検証が失敗する。複数のプラグインがログイン画面に同時に作用する構成で、この問題が顕著に現れる。
「Bad hCaptcha signature!」というエラーは、プラグインがローカルで生成している。hCaptcha API にリクエストを送る前の段階で発生するため、サイトキーとシークレットキーの検証が成功していてもエラーが消えない。この点が原因の切り分けを難しくしている。
「ログイン試行前のhCaptcha」の設定値を 0 にしている場合、この不具合はすべてのログイン試行で発生する。0 に設定すると署名検証を回避する余地がなくなり、毎回エラーに遭遇する。
ログイン不能な状態から管理画面へ入る手順
管理画面に入れない状態でも、FTP や SSH でサーバーへ接続すれば hCaptcha プラグインを一時停止できる。プラグインを停止するとログイン経路が確保されるため、その後は通常どおり管理画面へアクセスできる。
この手順で管理画面へ入り、ダウングレードの準備を整える。
FTPまたはSSHでプラグインを停止する
FTP クライアントでサーバーへ接続し、wp-content/plugins ディレクトリへ移動する。hcaptcha というフォルダを見つけたら、フォルダ名を「hcaptcha-disabled」のように変更する。WordPress はプラグインを読み込まなくなるため、ログイン画面からキャプチャが消えて通常のログインフォームが表示される。
SSH を使える環境なら、wp-content/plugins ディレクトリで mv コマンドを実行する方法が速い。コマンドラインでの操作に慣れている場合は、この選択肢が確実だ。
管理画面に入ったらhCaptcha設定を確認する
プラグインを停止してログインできたら、WordPress 管理画面の「プラグイン」を開く。hCaptcha が停止状態になっていることを確認し、これから行うダウングレードに備えて現在の設定メモを残しておくとスムーズだ。
hCaptcha 5.2.0を5.1.0へダウングレードする手順
管理画面へ入れるようになったら、hCaptcha 5.2.0 を削除して 5.1.0 をインストールする。設定データは削除しても保持されるため、サイトキーとシークレットキーを再入力する必要はない。
5.1.0 へ戻すと署名検証の不具合が解消され、ログインできるようになる。
5.2.0を削除して5.1.0をインストールする
WordPress 管理画面の「プラグイン」から hCaptcha 5.2.0 を削除する。削除しても設定はデータベースのオプションテーブル（デフォルトでは wp_options）に残るため、サイトキーやシークレットキーが消えることはない。
次に 5.1.0 の ZIP ファイルを公式リポジトリなどから入手する。「プラグイン」メニューの「新規追加」を開き、「プラグインのアップロード」から ZIP ファイルを選択してインストールする。インストール完了後に有効化する。
サイトキーとシークレットキーを再確認する
インストール後、hCaptcha の設定画面を開き、サイトキーとシークレットキーに値が入っていることを目視で確認する。5.2.0 から戻しても設定は残っているはずだが、念のため両方のフィールドをチェックしておく。
キーの検証ボタンを押して成功すれば、API との通信自体は正常ということだ。ただしこの不具合は通信前にローカルで発生するため、検証成功の表示が出ても油断はできない。あくまでキーの有効性を確認するだけの操作だと理解しておく。
モードをLiveに設定して保存する
設定画面でモードが Live になっていることを確認し、変更があれば保存する。サイズが invisible になっているかも確認する。設定を保存したら、次のキャッシュ削除の手順へ進む。
キャッシュを削除してエラーを完全に解消する
バージョンを 5.1.0 に戻しただけではエラーが残ることがある。5.2.0 が署名形式を変更した影響で、以前のバージョンが生成したログイン HTML が各種キャッシュに残っていると、同じエラーが引き続き表示される。
ページキャッシュとサーバーキャッシュを削除する
使用しているキャッシュプラグイン（WP Super Cache や W3 Total Cache など）の管理画面を開き、ページキャッシュとオブジェクトキャッシュを削除する。サーバー側のキャッシュ機能（Varnish や LiteSpeed Cache など）が有効な場合も、同じく削除操作を行う。
CDNのキャッシュを削除する
Cloudflare やその他の CDN を利用している場合、CDN の管理画面からキャッシュをパージする。ログインページの HTML がエッジサーバーに残っていると、WordPress 側の設定が正しくても古い署名形式のページが配信され続ける。
プライベートウィンドウで動作確認する
キャッシュ削除後、通常のブラウザタブではなくプライベートウィンドウ（シークレットウィンドウ）でログインページを開く。ブラウザのローカルキャッシュや Cookie も残っていると、修正後のページを正しく読み込めないことがある。
プライベートウィンドウでログインを試み、キャプチャを通過して管理画面に入れればダウングレードは成功だ。通常のブラウザタブでまだエラーが出る場合は、ブラウザのキャッシュと Cookie を個別に削除して再試行する。
自動更新を止めて再発を防ぐ
修正版がリリースされるまで、自動更新で 5.2.0 に戻らないようにしておく。プラグインの自動更新は個別に無効化できるため、hCaptcha だけ更新を止めておくのが安全だ。
hCaptchaの自動更新を無効化する
WordPress 管理画面の「プラグイン」一覧で hCaptcha の行を確認し、自動更新を無効にする。プラグインごとの自動更新設定はプラグイン一覧画面から切り替えられる。WordPress 本体の自動更新とは別の設定なので、本体は更新を継続したまま hCaptcha だけを固定できる。
修正版のリリースを確認する方法
プラグインの公式ページやリポジトリを定期的に確認し、5.2.1 以降の修正版がリリースされたかをチェックする。修正版が出るまでは 5.1.0 のまま運用し、更新前には必ずテスト環境でログイン動作を確認する。
本番環境へ修正版を適用する際も、まずステージング環境でログイン、キャプチャ表示、ユーザー登録、パスワードリセットの一連の動作を検証してからリリースするのが安全だ。
よくある質問
プラグインを削除するとhCaptchaの設定は消えますか
いいえ、消えない。プラグインを削除しても設定はデータベースに保持される。アンインストール時にデータを削除するクリーンアップ設定を事前に有効化していた場合のみ、削除される仕組みだ。ダウングレードでサイトキーを再入力する必要はない。
ダウングレード後に「インストールが不正です」と表示されます
5.2.0 から 5.1.0 へ手動で戻す際、WordPress が古いバージョンのインストールを「不正」と判定することがある。この場合は一度 5.2.0 を完全に削除してから 5.1.0 を新規インストールする。設定が残っているため、再設定の手間はかからない。
サイトキーとシークレットキーの検証は成功するのにエラーが続きます
「Bad hCaptcha signature!」は、プラグインが API へリクエストを送る前のローカル段階で生成される。キーの検証は API との通信が正常であることを示すだけで、署名検証の不具合とは無関係だ。そのためキーが正しくてもエラーは消えない。
ログイン時にキャプチャテストが表示されるのは正常ですか
「サイズ」を「invisible」に設定しているにもかかわらず画像選択テストが表示される場合、設定が正しく反映されていない可能性がある。ダウングレード後にキャッシュを削除し、プライベートウィンドウで再度確認するとよい。それでも表示される場合は、ログイン試行前の設定値や他のログイン系プラグインとの競合を調べる。
自動更新で勝手に5.2.0に上がるのを防げますか
防げる。WordPress 管理画面の「プラグイン」一覧から hCaptcha の自動更新を個別に無効化できる。また、複数のプラグインを一元管理している場合は、更新ポリシーで hCaptcha を除外する設定を行う。
この記事のポイント
- 5.2.0 の署名検証リグレッションがログインエラーの原因
- エラーはAPI通信前のローカル処理で発生する
- 5.1.0 へのダウングレードが確実な対処法
- プラグイン削除後も設定データは保持される
- 全キャッシュ削除とプライベートウィンドウでの確認が必須
ForminatorでStripe決済は通るのに送信履歴が残らない時の対処法
Forminator のフォームに必須の Stripe 決済フィールドを設置したサイトで、カード決済は成功しているのに送信履歴（エントリー）が保存されず、管理者への通知メールも届かない場合は、ページキャッシュとフォーム保存処理の競合をまず疑うべきだ。「AJAX を使用してフォームを読み込む」を有効にし、送信後のリダイレクトを一時的に外して切り分けるのが最短の対処になる。
なぜ Stripe 決済は成功するのにフォーム送信履歴が残らないのか
送信ボタンを押すと、Stripe への決済実行と、WordPress データベースへのエントリー保存という2つの処理がほぼ同時に走る。この2つは経路が完全に独立しているため、片方だけが成功する状態が起こり得る。決済は Stripe の画面で完結するが、送信履歴の保存は WordPress 側のセキュリティトークン（nonce）検証を通らないと書き込まれない。
このデモは、決済が成功してもフォーム保存だけが別経路で失敗する仕組みを示している。保存に失敗する典型的な原因は、ページキャッシュに取り残された古いセキュリティトークンだ。フォームの HTML が静的キャッシュとして配信されると、トークンの有効期限が切れたまま送信され、非同期保存だけが拒否される。
送信後に別の URL へリダイレクトする設定にしている場合は、保存処理が終わる前にページ遷移が始まり、データベースへの書き込みが中断されることがある。3D Secure（本人認証）でカード会社の認証画面を挟む決済では、フォームへ戻ってから保存が再開されるため、この競合が断続的に発生しやすい。
まず「AJAX を使用してフォームを読み込む」を有効にする
Forminator のフォーム編集画面を開き、「動作」タブ（英語環境では Behavior）の「レンダリング」セクションに「AJAX を使用してフォームを読み込む」チェックボックスがある。これが無効のままだと、フォームの HTML がそのままキャッシュされ、トークン劣化の引き金になる。
このオプションを有効にすると、フォーム部分だけが非同期で最新の状態に置き換わる。キャッシュされたページにアクセスしても、フォーム内部のトークンはその都度更新され、送信履歴の保存処理が正しく通る。設定を保存したら、必ずサイトのページキャッシュをクリアしてから動作確認する。
既に有効にしていても症状が出る場合はどこを確認する？
チェックが既に付いていた場合は、AJAX 読み込みだけでは競合を防ぎきれていない。次に、送信後のリダイレクトを一時停止して症状が消えるか確認する。それでも直らない場合は、Stripe 側の本人認証フローとキャッシュの二重がけを順に調べる。
送信後のリダイレクトを一時停止して切り分ける
Forminator の「送信後動作」（英語環境では After Submission Behavior）設定では、複数の動作を追加しても先に登録した1つだけが処理される。インラインメッセージのあとにリダイレクトを設定していた場合は、実質インラインメッセージだけが動いていた状態になる。そこからリダイレクトだけに変えると、保存完了を待たずにページが遷移し、送信履歴が残らなくなることがある。
このデモのように、まずリダイレクト設定を外してインラインメッセージだけにし、数回テスト送信する。これで全ての送信履歴が残れば、リダイレクトが引き金になっていたと判断できる。
リダイレクトを使いたい場合はどうすればいい？
保存処理を追い越さない順序に組み直す必要がある。具体的には、まずインラインメッセージで送信完了を知らせ、その画面からページ遷移する導線にする。これが難しい場合は、当面リダイレクトなしで運用し、症状が出ないことを確認してから設定を戻す。保存処理の完了を待たずに遷移させる構成は、たとえ短い間隔でも断続的な欠損を招く。
3D Secure（本人認証）経由の決済かどうかを確認する
Stripe の 3D Secure（カード会社がワンタイムパスワードやアプリ認証を求める仕組み）が発動する取引では、認証画面や銀行アプリへの切り替えが入る。この認証が終わってフォーム画面に戻るとき、Forminator 側の保存処理が正しく再開されず、決済だけ記録される事例がある。
まず Stripe ダッシュボードの「支払い」から該当の取引を検索し、決済金額と顧客情報が残っているか確認する。決済は残っているのにフォームのエントリーだけ欠損している場合、症状が一致する。続けて、症状が特定のカードブランドや発行会社に偏っていないかを支払い方法別に絞り込む。3D Secure の認証フローが絡む場合は、Forminator と Stripe の API 連携上の問題になるため、プラグインを最新版へ更新した上で、フォームのエクスポートを開発元サポートに渡して再現確認を依頼する。
キャッシュプラグインとフォームページを除外設定にする
サイトでページキャッシュを使っている場合は、フォームを設置しているページをキャッシュ対象外にする。特に決済フォームのある固定ページやランディングページは、静的な HTML 配信をやめて、常に WordPress が生成する最新の画面を返す設定にする。
利用しているキャッシュプラグインの除外設定で、対象ページの URL パスや、フォームの ID を含むクエリを指定する。あわせて、ログイン状態のユーザーにはキャッシュを返さない設定が有効かも確認する。サーバー側のキャッシュ（共用サーバーの高速化機能など）が二重にかかっている場合は、管理画面やホスティングの設定から該当ページのキャッシュを無効化する。これで、AJAX 読み込みを有効にしていても起きる断続的な症状を防げる。
よくある質問
Stripe の決済が通っているのに送信履歴が残らないのはなぜ？
決済と送信履歴の保存は別経路で処理されている。ページキャッシュでフォームのセキュリティトークンが古くなると、決済は Stripe 側で成功しても、WordPress 側のエントリー保存だけが拒否されることがある。送信後のリダイレクトが保存処理を追い越すのも原因の一つだ。
AJAX 読み込みを有効にするとデザインや表示速度に影響はあるか？
フォームの HTML が非同期読み込みに変わるため、ページ表示後すぐにフォームが出ず、一瞬だけ空の枠が出ることがある。見た目はほとんど変わらず、速度も体感できる差はない。キャッシュされたページとの相性は大幅に改善する。
送信履歴が残っていないのに決済は成功している場合、二重請求を防げるか？
顧客が送信を繰り返すと二重決済のリスクがある。該当期間の Stripe ダッシュボードで同一顧客の複数決済を確認し、重複が疑われる場合は返金対応を行う。フォーム側では二重送信防止の設定を確認しておく。
送信履歴が消えた分のデータは復元できるか？
WordPress のデータベースに送信エントリーが書き込まれていないので、Forminator の管理画面上では復元できない。一方、Stripe 側には支払いデータが残っているため、決済情報と顧客メールアドレスを照合して注文内容を再構成することになる。メール通知が届いていない分は、Stripe のレシートが顧客との連絡手段になる。
決済後に送信履歴が残らない確率はなぜ回によって違うのか？
ページキャッシュの状態とトークンの有効期限の関係で、キャッシュが新しければ保存が通り、古ければ失敗する。3D Secure の認証が挟まる場合は、戻り方のタイミングでさらにバラつく。そのため同じフォームでも数回に1回だけ失敗するような断続的な症状になる。
この記事のポイント
- Stripe 決済と送信履歴の保存は別経路で処理される
- まず「AJAX を使用してフォームを読み込む」を有効にしてキャッシュ競合を減らす
- 送信後のリダイレクトを一時停止して保存処理の追い越しを切り分ける
- 3D Secure が絡む決済かどうかを Stripe ダッシュボードで確認する
- フォーム設置ページをキャッシュ対象外にして再発を防ぐ
WooCommerceで小数数量の購入が通らない時の原因と対処法
WooCommerceのチェックアウトで小数数量（1.5kgや0.8mなど）を指定すると、line_itemsパラメータが無効というエラーが表示され、注文が完了できなくなる。原因はWooCommerceのデフォルト仕様でカート内の数量が整数として扱われるため。数量単位を変えて整数にするか、小数数量対応のプラグインを導入すれば解決できる。
なぜWooCommerceで小数数量を購入できないのか
WooCommerceの商品数量フィールドは、標準状態では1、2、3といった整数しか受け付けない。ところが、計量販売や布地・配線材など小数単位で売りたい商品は多く、小数を入力できるよう改造したサイトも存在する。
問題が表面化するのは、チェックアウトブロックを使っている場合だ。このブロックはStore APIと呼ばれるREST APIを通じて注文データをサーバーに送る。Store APIは送られてきた注文明細（line_items）を検証する際に、数量を整数としてチェックする。ここで小数が混ざっていると「line_itemsパラメータが無効」というエラーを返す。
従来のクラシックチェックアウト（ショートコード方式）では別の仕組みで注文を送るため、同条件でもエラーが出ないことがある。つまり「カートには小数で入るのに、チェックアウトブロックだけ失敗する」という症状になりやすい。
このデモは、小数数量がAPI検証で拒否される流れと、単位を変換して整数にした場合の成功フローを示している。エラーの根本原因はフロント側の表示ではなく、APIが受け取る数量の形式にある。
数量単位を変えて整数だけで販売する手順
もっとも手軽で確実な方法は、商品の販売単位そのものを細かくして、顧客が常に整数で数量を入力できるようにする方法だ。たとえば1.5kgの商品を売るなら、販売単位を「kg」から「100g」に変更し、顧客には15と入力してもらう。
食品・重量商品の場合
コーヒー豆や精肉、チーズなど重量で売る商品では、単位をグラムに切り替えるだけで解決できる。商品名に「100gあたり」と明記し、価格も100g単位で設定する。1.5kg買いたい顧客は数量欄に15と入力すればよい。
布地・ロープ・配線材の場合
メーター単位で切売りする商品は、センチメートル単位に変換するのが有効だ。1.5mは150cmとして、数量欄には150と入力してもらう。商品タイトルに「1cm単位で販売」と明記すれば混乱も防げる。
在庫管理とSKUの見直し
単位を変えたら在庫数とSKUも新しい単位に合わせて更新する必要がある。1kgの在庫は1000gとして記録し、SKUも単位が分かる番号に変更しておくと後の運用が楽になる。既存の注文データには影響しないので、商品単価と在庫だけを慎重に更新する。
小数数量対応のプラグインで解決する方法
どうしても小数数量を維持したい場合は、小数数量に対応したプラグインを導入する方法がある。WooCommerce公式のエクステンションストアには、数量の刻み幅を小数で設定できる拡張が複数配布されている。
プラグインを選ぶ際の確認ポイントは、次の3点だ。まず、チェックアウトブロック（Store API）に対応していること。フロント側の数量入力だけを変更しても、API検証で拒否されれば同じエラーが再発する。次に、在庫管理でも小数を扱えること。最後に、WooCommerceの最新バージョンで動作確認されていること。
導入後は、商品編集画面に小数ステップの設定欄が追加される。数量の刻み幅を0.1に設定し、最小数量も小数で指定する。設定を保存したら、必ずテスト注文で小数数量が通るか確認する。カートに入れる段階とチェックアウト実行の両方でエラーが出ないことを確かめる。
開発者向けカスタムコードで数量の小数を許可する方法
自作テーマやカスタムプラグインで対応する場合は、数量入力フィールドの引数をフィルターで変更する。以下のコードは、テーマのfunctions.phpやCode Snippetsプラグインに追加する想定だ。
add_filter( 'woocommerce_quantity_input_args', 'allow_decimal_quantity', 10, 2 );
function allow_decimal_quantity( $args, $product ) {
$args['step'] = '0.1';
$args['min_value'] = '0.1';
return $args;
}ただし、このコードだけではフロント側の入力欄が小数に対応するだけで、Store APIの検証までは通過しないことがある。チェックアウトブロックを使う場合は、API側のスキーマを拡張する追加のフィルターが必要になる。Store APIのline_itemsで数量の型を変更するには、より深い層への対応が求められる。
実務では、Store API対応を自前で実装するより、小数数量対応をうたうプラグインを利用する方がリスクが小さい。APIスキーマの変更はアップデートで挙動が変わる可能性があり、受注データの整合性にも関わるためだ。
小数数量が必要な商品の販売方法を再設計する
エラーの対処と並行して、そもそも小数数量を使わずに済む販売設計を検討するのも有効だ。商品の性質によっては、属性（バリエーション）を使う方がシンプルで顧客にも分かりやすい。
よく買われるサイズをバリエーションで用意する
布地やケーブルなら「50cm」「1m」「1.5m」「2m」のように、よく注文されるサイズをあらかじめバリエーションとして登録する。顧客は数量1を選ぶだけで済み、小数入力は不要になる。在庫管理も単位が明確になるため、発注ミスも減らせる。
計量販売プラグインの活用
重量や長さに応じて価格を自動計算する計量販売向けの拡張を使う手もある。顧客が重さや長さを入力すると、対応する価格が自動で表示される仕組みだ。この方式なら小数数量を直接カートに入れる必要がなく、エラーの発生を回避できる。
よくある質問
小数数量を使うと必ずこのエラーになりますか
いいえ。従来のクラシックチェックアウト（ショートコード方式）では、フロント側で小数を許可していれば通ることがある。エラーが起きやすいのはチェックアウトブロックを使っており、Store API経由で注文を送信する構成だ。
商品ごとに小数数量を許可できますか
できる。小数数量対応プラグインの多くは商品単位で設定を持っており、小数を許可する商品と整数のみの商品を混在させられる。カスタムコードでも商品IDやカテゴリを条件にフィルターを適用できる。
数量単位をgに変更すると在庫管理はどうなりますか
在庫数も新しい単位に合わせて記録し直す必要がある。1kgの在庫は1000gとして登録し、SKUも単位が分かる体系に変更するのが望ましい。既存の注文履歴には影響しないため、商品単価と在庫数を慎重に更新すればよい。
すでに小数数量で登録した商品がある場合はどうすればよいですか
商品データを確認し、数量の刻み幅や単位設定を見直す。複数商品を一括で変更するなら、WooCommerce標準の商品CSVエクスポート・インポート機能を使うと効率的だ。変更後はテスト注文で必ず動作を確認する。
チェックアウトブロックだけでエラーになるのはなぜですか
チェックアウトブロックはStore APIというREST API経由で注文データをサーバーに送信する。このAPIがline_itemsを検証する際、数量を整数としてチェックするため、小数が混ざると検証エラーになる。クラシックチェックアウトは別の送信方式のため、同じ条件でも通ることがある。
この記事のポイント
- 小数数量の購入エラーはStore APIのline_items検証が原因
- もっとも手軽な対処は数量単位を変えて整数で販売すること
- 小数数量を維持したい場合は対応プラグインの導入が有効
- チェックアウトブロック対応の有無を確認してからプラグインを選ぶ
- カスタムコードはフロント側だけでは不十分でAPI側の対応も必要
- 属性や計量販売方式への再設計も検討価値がある
GitHubが8月17日の大規模障害を報告。CTOが原因分析と再発防止策を公表
2026年8月17日、GitHubで大規模なサービス障害が発生した。障害から3日後の8月20日、GitHubのCTO（最高技術責任者）であるVlad Fedorov氏が公式ブログで報告記事を公開し、原因分析と今後の再発防止策について言及した。
本記事では、今回の障害から読み取れる大規模プラットフォームの運用課題と、GitHubが示した今後の方向性を整理する。開発者やDevOps担当者にとって、自社システムの信頼性を見直す材料になるはずだ。
障害の概要とCTOによる報告
2026年8月17日に発生した障害は、GitHubの主要サービスに広範な影響を及ぼした。具体的な原因や影響範囲の詳細は記事内で段階的に明らかにされているが、CTO自らが報告に乗り出した点が今回の特徴だ。
CTO Vlad Fedorov氏について
報告記事の著者であるVlad Fedorov氏は、GitHubのCTOとして開発者ツールの未来を率いる立場にある。GitHub入社前はFacebook（現Meta）で上級副社長を12年間務め、プライバシー・広告・プラットフォーム分野で2,000人を超えるエンジニア組織を統率した経験を持つ。さらに前職ではUserCloudsというデータガバナンス関連のスタートアップを共同創業しており、Microsoftでの勤務経験もある。
大規模インフラの運用経験が豊富な人物が障害報告の筆を取ったこと自体、GitHubが今回の障害を単なるインシデントとしてではなく、プラットフォーム全体の信頼性に関わる重要事案として扱っていることを示している。
障害報告のタイミングが示すもの
障害発生は8月17日、報告記事の公開は8月20日。この3日間の間隔は、原因の切り分けと分析に十分な時間をかけたうえで、断定的な情報をまとめてから公表したことを示唆する。大規模障害では初期対応中に誤った情報を出さないことが重要であり、GitHubは原因を確定させたうえで報告に踏み切ったと見られる。
このデモは障害前後の状態を示した概念図である。実際の影響範囲についてはGitHubの公式報告を確認してほしい。
大規模プラットフォーム障害が浮き彫りにする運用課題
GitHubのような大規模プラットフォームの障害は、単一のサービス停止にとどまらない。世界中の開発チームが日々のワークフローをGitHubに依存しているため、障害の影響は連鎖的に広がる。コードのプッシュ、プルリクエストのレビュー、CI/CDパイプラインの実行、ドキュメントの更新など、あらゆる工程が停止する。
依存の集中が生むリスク
開発インフラの集中化は利便性をもたらす一方で、単一障害点を生み出す。多くの企業がGitHubを中心に開発プロセスを構築しているため、GitHubが停止すると自社の開発活動も止まる。この依存関係の深さは、今回の障害でも改めて認識されたはずだ。
インシデント対応における透明性の重要性
CTOが公式ブログで詳細な報告を行う姿勢は、インシデント対応における透明性の重要性を示している。障害の原因を隠さず、技術的な分析結果を公開することで、利用者の信頼を維持する狙いがある。GitHubのこの対応は、他社のインシデント報告の手本にもなるだろう。
上図は大規模障害から得られる一般的な教訓を整理したものだ。GitHubの報告でも、これらの要素がどのように現れたのかが焦点となる。
GitHubが示す今後の取り組み
記事タイトルにある「the work ahead（今後の取り組み）」という表現から、GitHubは今回の障害を教訓として、具体的な改善策を打ち出していることが読み取れる。詳細な技術的対策は記事内で段階的に説明されているものとみられるが、大規模プラットフォームの再発防止策として、以下の方向性が考えられる。
インフラの冗長化と障害分離
大規模障害の再発防止には、インフラの冗長化が不可欠だ。特定のコンポーネントに障害が発生しても、他のコンポーネントが機能を維持できる構成が求められる。GitHubのような複数のサービスが連携するプラットフォームでは、障害の影響を局所化するための仕組みも重要になる。
監視・検知体制の強化
障害の早期検知は被害を最小限に抑える鍵を握る。異常をリアルタイムで検知し、自動的にフェイルオーバーを実行する仕組みは、大規模プラットフォームの必須要件だ。今回の障害を踏まえ、GitHubは監視体制の見直しにも着手していると考えられる。
上図は大規模プラットフォームにおける障害対応の理想的なフローを示している。GitHubの報告では、今回の障害でどのステップに課題があったのかが分析されていると考えられる。
開発者と企業が取るべき対策
GitHubの障害は、プラットフォームに依存するすべての開発者と企業に影響を与える。自社の開発インフラを見直す契機として、いくつかの対策が有効だ。
外部依存のリスク評価
まず自社の開発プロセスがどの外部サービスに依存しているかを洗い出す必要がある。GitHubだけでなく、CI/CDツール、クラウドサービス、パッケージレジストリなど、開発ワークフローの各段階で外部依存が存在する。それぞれのサービスに障害が発生した場合の影響を評価し、必要に応じて代替手段を用意しておくことが重要だ。
バックアップと代替ワークフローの整備
GitHubが停止した場合でも開発を継続できるよう、ローカルリポジトリの保持やミラーの活用を検討する価値がある。完全な代替は難しくても、緊急時の手順を文書化しておくだけで、障害発生時の混乱を大幅に減らせる。
この記事のポイント
- GitHubで2026年8月17日に大規模障害が発生し、CTOのVlad Fedorov氏が3日後に報告記事を公開した
- CTO自らが報告に乗り出したことは、GitHubが信頼性を最優先事項と位置づけていることの表れである
- 大規模プラットフォームの障害は単一障害点のリスクと透明性の重要性を改めて示した
- GitHubは「今後の取り組み」としてインフラの冗長化と監視体制の強化を進めると見られる
- 開発者と企業は外部依存のリスクを評価し、緊急時の代替ワークフローを整備しておくべきだ
WordPress 7.1で標準サイトマップが404になる原因と解消手順
WordPress 7.1 に更新した後、プラグインなしのサイトで標準 XML サイトマップが 404 になる場合は、パーマリンク設定の再保存でリライトルールを再生成する。同じ環境で 7.0.4 では正常だった場合は WordPress 7.1 本体のリグレッションの可能性が高いため、急ぎなら 7.0.4 へ戻すのが確実だ。
WordPress 7.1 で標準サイトマップが 404 になる原因
標準 XML サイトマップは WordPress 5.5 から搭載された機能だ。パーマリンク設定に基づき wp-sitemap.xml という URL でインデックスを出力し、wp-sitemap-posts-page-1.xml のように投稿タイプ別・ページ番号別の子サイトマップを生成する。検索エンジンがサイトを巡回する入り口の役割を持つ。
WordPress 7.0.4 から 7.1 へ更新した直後から wp-sitemap.xml と wp-sitemap-posts-page-1.xml の両方が 404 を返す場合は、プラグインの競合やテーマの影響を疑う前に、WordPress 本体のリライト処理と更新後のルール再生成状況を確認する。特に Nginx を Apache の前段に置くリバースプロキシ環境では、拡張子 .xml を静的ファイルとして振り分ける設定や、Apache 側の .htaccess にリクエストが届かない構成が原因になることがある。
同じ環境・同じテーマ・プラグインなしで 7.0.4 に戻すと直る場合、WordPress 7.1 の標準サイトマップ機能に起因する不具合の可能性が高い。設定を見直しても直らないときは、コア側の更新によるリグレッションを視野に入れる。
最初に試すパーマリンク再保存とキャッシュ確認
WordPress はバージョン更新後に、パーマリンクのリライトルールが内部にキャッシュされたままになることがある。最初に管理画面の「設定」→「パーマリンク」を開き、内容を変更せずに「変更を保存」を押す。これによって .htaccess やデータベース上のルールが再生成される。
保存後は、ブラウザのシークレットウィンドウか curl で wp-sitemap.xml の HTTP ステータスコードを確認する。キャッシュ系プラグインを入れていなくても、レンタルサーバーや Nginx、CDN がレスポンスをキャッシュしている可能性があるため、まずキャッシュを削除する。
この切り分けで、リライトルールの再生成だけで直るのか、Nginx と Apache の設定まで必要なのかが区別できる。
ここで 200 OK に戻れば、更新によるリライトルールの再生成漏れが原因だったことになる。それでも 404 なら次の転送設定の確認へ進む。
Nginx リバースプロキシと Apache の転送設定を確認する手順
Nginx をリバースプロキシとして Apache の前に置く構成では、location / が proxy_pass で Apache へ向いているかを確認する。もし location ~* \.(xml)$ のような拡張子判定があり、Nginx が XML を静的ファイルとして処理してしまうと、WordPress に到達せず 404 になる。
Apache 側の .htaccess は、# BEGIN WordPress から # END WordPress の間に標準の mod_rewrite.c ブロックがあるかを確認する。独自の RewriteCond や RewriteRule を追記していないこと、RewriteBase / がサイトの設置パスに合っていることが重要だ。
curl で example.com/wp-sitemap.xml と example.com/?sitemap=posts&sitemap-subtype=page&paged=1 をそれぞれ確認する。クエリ形式でも 404 なら、WordPress がサイトマップを出力できていないか、Nginx から Apache への転送が正しくない可能性がある。
WordPress 7.1 から 7.0.4 へ戻す一時対処と注意点
設定変更でも症状が変わらない場合は、バックアップを取得したうえで WordPress 7.0.4 へ戻す。公式パッケージの 7.0.4 でコアファイルを置き換え、管理画面にデータベース更新の案内が出た場合はそれを実行する。
このデモは 7.1 で 404 を返していたサイトマップが、7.0.4 へ戻すと 200 OK に変わることを示している。
ファイルとデータベースのバックアップを取らずにダウングレードすると、予期しない不整合からの復旧が難しくなる。WP Downgrade のようなダウングレード用プラグインを使う場合も、更新前のスナップショットが必須になる。
7.0.4 へ戻すと、同じ URL wp-sitemap.xml が正常に XML を返すようになる。ただし 7.1 の修正版がリリースされたら、そのまま使い続けずに安全なタイミングで更新する。
Google Search Console の再読み込みと標準サイトマップの再送信
サイトマップが正常に戻ったら、Google Search Console の「サイトマップ」で登録済みの wp-sitemap.xml を確認する。「取得できませんでした」と表示されていた場合は再読み込みを行い、ステータスが「成功しました」に変わるのを待つ。
古いレポートが残っている場合は、一度サイトマップを削除してから wp-sitemap.xml を再送信する。フェッチが完了するまで数分かかることがあるため、すぐに結果が出なくても時間を置いて再確認する。
再発防止と WordPress 7.1 の修正状況の追い方
WordPress 7.1 の後続リリースで標準サイトマップの修正が含まれるかは、ダッシュボードの更新通知と WordPress のリリース情報で確認する。本番環境へメジャー更新を適用する前には、ステージング環境で wp-sitemap.xml が 200 OK を返すことを必須のチェック項目にする。
Nginx と Apache を併用している構成では、更新前後の curl の応答コードを記録しておくと、今回のような更新起因のリグレッションを素早く特定できる。SEO プラグインのサイトマップで代替することも一時的には可能だが、パーマリンク全体の不具合を隠す可能性があるため、先に WordPress 本体とサーバー設定の切り分けを行う。
よくある質問
標準サイトマップが404になったらまず何をすればいい？
管理画面の「設定」→「パーマリンク」を開き、内容を変えずに保存してリライトルールを再生成する。これで直らない場合は、Nginx の静的ファイル判定や Apache の .htaccess を確認し、それでも再現するなら WordPress 7.0.4 へ戻して切り分ける。
Nginx リバースプロキシだと何が問題になる？
Nginx が .xml のリクエストを静的ファイルと判断すると、Apache へ渡さずに 404 を返す。Apache の前段で location 設定を見直し、WordPress の index.php までリクエストが届く構成になっているか確認する。
WordPress 7.1 に更新しない方がいい？
通常の単純な LAMP 構成では問題が起きにくいが、標準サイトマップを運用中のサイトで更新直後の 404 が許容できないなら、修正版が出るまで 7.0.4 を使う判断も現実的だ。本番更新前にステージングで確認するのが基本になる。
7.0.4 に戻した後、Google Search Console で何をすればいい？
サイトマップの再読み込みを行い、ステータスが成功に変わるのを確認する。エラーが残っている場合は一度削除して wp-sitemap.xml を再送信し、数分後にもう一度確認する。
SEO プラグインのサイトマップに切り替えてもいい？
切り替え自体は可能だが、WordPress 標準のサイトマップが壊れた原因を残したままだと、他のパーマリンクでも同様の不具合が出る可能性がある。一時的な代替には使えるが、本体側の切り分けを先に行う。
この記事のポイント
- WordPress 7.1 更新後に標準サイトマップが 404 になる場合、最初にパーマリンクを再保存する
- Nginx と Apache の組み合わせでは静的ファイル判定や .htaccess を確認する
- 7.0.4 で同じ環境が正常なら WordPress 本体のリグレッションを疑う
- 急ぐ場合はバックアップを取って 7.0.4 へ戻すのが確実
- 修正版のリリースと Google Search Console のステータスを確認する
WooCommerce 11.1ベータ版が公開！EU注文撤回と返金APIの全容
WooCommerce 11.1のベータ版が公開された。今回のリリースではEU顧客向けの注文撤回フロー、REST APIの新しい返金計算エンドポイント、バリエーション商品のパフォーマンス改善が柱となる。正式版は2026年9月1日にリリース予定だ。
この記事では開発者向けブログの情報を基に、主要な変更点と実務への影響を解説する。ストア運営者とエクステンション開発者の双方が押さえておくべきポイントをまとめた。
WooCommerce 11.1の全体像
WooCommerce 11.1には大きく4つの改善領域がある。EU消費者保護に対応する注文撤回機能、返金計算を自動化するREST APIエンドポイント、商品CSVのインポートとエクスポートのバグ修正、そしてバリエーション商品の表示速度向上のためのパフォーマンス修正だ。
これらに加え、エクステンション開発者向けの互換性修正も複数含まれる。ブロック登録のスキップによる管理画面の負荷軽減、エディタアセットの統合実験など、開発者向けの変更も見逃せない。なお、この段階ではあくまでベータ版であり、フィードバックが募集されている。
この図はWooCommerce 11.1の4つの柱を示している。それぞれの詳細を順に見ていこう。
EU顧客向けの注文撤回フローが登場
WooCommerce 11.1では、EU消費者保護指令に基づく注文撤回権（right of withdrawal）に対応する機能が追加された。顧客はマイアカウントの専用ページから注文撤回を申請できる。EU圏では消費者が契約後一定期間内に理由なく注文を取り消せる権利が法律で定められている。この機能はその権利をストア運営者がスムーズに扱うための仕組みだ。
顧客が注文撤回を申請すると、ストア運営者にメール通知と管理画面のインボックス通知が届く。加盟店はその通知を確認して返金手続きを進める流れだ。申請時に認証は不要で、顧客は管理画面のワードプレスログインを必要としない。これはEUの消費者保護の原則に沿った設計である。
注文撤回の申請から返金までの流れはこの3ステップで完結する。ストア運営者は通知を確認してから対応すればよいため、顧客とのやり取りを記録しやすい。
この機能はデフォルトでは無効化されている。利用するにはWooCommerceの設定画面から「設定 → 詳細 → 機能」と進み、注文撤回機能を有効化する必要がある。EU圏向けにストアを運営している場合は導入を検討したい。
REST APIの返金エンドポイントが強化された
返金処理を外部システムから操作する開発者にとって大きな変更が入った。WooCommerce REST APIの返金フローが更新され、サーバー側で返金額を自動計算できるようになった。従来は返金額を手動で計算してリクエストに含める必要があったが、その手間を省ける。
既存の返金エンドポイントに compute_totals フィールドが追加された。このフィールドに true を指定すると、WooCommerceサーバーが商品代金、送料、税を自動的に計算して返金額を確定する。計算ミスによる返金誤りを防げるのが利点だ。
POST /wc/v3/orders/123/refunds
{
"compute_totals": true
}この例では注文番号123に対して返金リクエストを送信している。ボディに compute_totals を指定するだけで、あとはWooCommerceが注文の明細を基に返金額を算出する。手動で計算する必要がなくなった。
さらに新しいプレビューエンドポイントも追加された。POST /wc/v3/orders/123/refunds/preview を使うと、実際に返金を実行せずに計算結果だけを確認できる。返金額を事前に検証したいケースや、顧客に返金額を提示する前に確認したいケースで重宝する。
POST /wc/v3/orders/123/refunds/previewこのプレビューエンドポイントは、返金処理を自動化するシステムを構築する際にデバッグと金額確認を容易にする。実際に返金を実行せずに結果を確認できるため、開発環境でのテストにも適している。
compute_totals を true にするだけでサーバーが自動計算この比較が示すように、返金処理の負担が大きく軽減された。外部システムから返金を自動化する際の堅牢性も向上している。
Store APIのチェックアウト金額チェック
Store APIにも改善が入った。チェックアウトエンドポイントに expected_total というオプションフィールドが追加された。このフィールドには顧客が画面上で確認した合計金額を整数で指定する。サーバー側で計算した金額と一致しない場合、リクエストは失敗し、新しい 409 エラーレスポンスが返される。
このエラーレスポンスのコードは woocommerce_rest_checkout_total_mismatch で、金額の不一致が発生したことをシステムが判別できる。顧客が画面で見た金額と実際に請求される金額が食い違う事故を未然に防ぐための仕組みだ。
この仕組みはチェックアウトの金額改ざんや画面表示の不整合を検出するために有効だ。決済処理を独自に実装している場合は特に注目したい。
バリエーション商品のパフォーマンス改善
バリエーション商品を多数抱えるストアでは、商品編集画面や店舗フロントの表示が遅くなる問題があった。WooCommerce 11.1ではこの問題に対処する複数のパフォーマンス修正が含まれている。主な改善は、バリエーションと属性の読み込み時に発生するN+1クエリの削減だ。
N+1クエリとは、1つの親データを取得した後、子データを1件ずつ追加で取得してしまう非効率なデータベースアクセスのことだ。たとえば100件のバリエーションがあると、101回のクエリが実行される。修正後は必要なデータをまとめて取得するため、クエリ回数が大幅に減る。
加えて価格キャッシュの処理も改善された。変動価格商品の価格計算ではキャッシュを活用してクエリを削減している。管理画面とフロントエンドの両方で、商品数の多いストアほど体感できる差が生まれるはずだ。
ブロック登録の条件付きスキップ
WooCommerce 11.1では、ブロックタイプとパターンの登録処理が見直された。従来はほぼすべてのリクエストでブロックが登録されていたが、新しい BlockRegistrationContext ガードを導入し、cron、AJAX、REST APIリクエストでは登録をスキップするようになった。
フロントエンド、管理画面、エディタの動作は従来通り維持される。つまり、実際にブロックを描画または編集する場面でのみ登録が走り、不要な場面では処理を省く。これにより管理画面のバックエンド処理が軽くなる。
1つ例外がある。商品やバリエーションの説明文にWooCommerceブロックが含まれている場合、woocommerce_short_description フィルターを通じて必要に応じてブロックタイプが登録される。商品REST API、Store API、バリエーションAJAXエンドポイント、商品ウェブフックでも説明文が正しく描画される。
エクステンション開発者への影響もある。すべてのリクエストでブロック登録が走ることを前提にした実装は修正が必要になる。新しい woocommerce_should_register_blocks フィルターで、スキップされたコンテキストでもブロックを登録するようにオプトインできる。
メールエディタの更新
ブロックベースのメールエディタにも機能追加があった。core/embed ブロックが、クリック可能なサムネイルを描画するプロバイダーで挿入できるようになった。対象はYouTube、Vimeo、VideoPress、TikTok、Dailymotion、そしてWordPressの埋め込みだ。WordPressの埋め込みはリッチなリンクカードとして表示される。
オーディオプロバイダーは対象外だ。また、未対応のプロバイダーからの埋め込みは貼り付けることはできるが、エディタが警告を表示し、配信時にはリンクとして送信される。メールに動画サムネイルを入れたい場合は、対応プロバイダーのURLを使うとよい。
パーソナライゼーションタグのコールバックにも改善が入った。タグが送信先のコンテンツタイプを受け取れるようになり、HTML、プレーンテキスト、href 属性のそれぞれに適切にエスケープできるようになった。新しいパラメータはオプションで、デフォルトはHTMLだ。自動エスケープは新しく登録されたテキスト型タグにのみ適用される。
実験的機能のプレビュー
WooCommerce 11.1には2つの実験的機能が含まれている。1つは統合ブロックエディタアセットだ。ブロックごとに個別のスクリプトとスタイルを読み込む代わりに、共有のJavaScriptとCSSバンドルに置き換える仕組みである。
テストによると、エディタのアセット数が91.7%削減され、ネットワーク転送サイズが48.3%減少、スタイルバンドルは62.3%小さくなった。フロントエンドのアセットには変更がない。デフォルトでは無効で、WooCommerceの設定画面から「詳細 → 機能 → 実験的機能」と進んで有効化できる。
この実験的機能が正式採用されれば、ブロックエディタの読み込み速度が大きく改善される。開発段階の指標ではあるが、かなり有望な結果だ。
もう1つの実験的機能は商品ギャラリービデオの内部ストレージだ。商品ギャラリーに動画を追加する第一歩として、動画データを保存する内部構造がフラグの後ろに実装された。設定画面から「商品ギャラリービデオ（ベータ）」を有効化すると使える。
開発者向けの互換性注意事項
WooCommerce 11.1では開発者が把握しておくべき互換性修正が複数含まれている。is_rest_api_request() 関数は、これまで /wp-json/ のパーマリンクパスのみでRESTリクエストを検出していた。今回の修正で、空でない rest_route クエリパラメータもRESTリクエストとして扱うようになった。クエリ形式のRESTルートを使う実装では挙動が変わる可能性がある。
ProductGalleryUtils::get_product_gallery_image_count()は非推奨となり、get_product_gallery_media_count()に置き換えられた。旧メソッドは非推奨通知を出すシムとして復元されている- 数量ステッパーのDOM順序が視覚的な順序と一致するように修正された。旧DOM順序に依存するCSSを書いているテーマは再テストが必要だ
WC_Order_Item_Product::set_product()はvariation_idをリセットするようになった。部分的なREST注文更新ではproduct_idが変わらない場合、variation_idが保持されるsearch_products()はORグループの結合を括弧で囲むようになった。これにより include、exclude、status、type の条件が全グループに適用される。結果セットが変わる- 新しい
GET /wc-analytics/activity-panel/countsエンドポイントが3つの従来エンドポイントを統合し、管理画面のページ読み込みあたり6回のリクエストを1回に削減する - アナリティクスページの出力からリクエスト由来のプロパティが除去された。キャッシュされたページが別の訪問者のリクエストデータを漏洩する事故を防ぐ
@woocommerce/entitiesはwindow.wc.wcEntitiesで内部ユーティリティを公開しなくなった。これらはもともと公開APIではない- 通貨記号の出力がMOP（P から MOP$）とZMW（ZK から K）で変更された。既存の記号オーバーライドフィルターは引き続き動作する
この記事のポイント
- WooCommerce 11.1ベータ版は2026年9月1日に正式リリース予定
- EU顧客向けの注文撤回フローが追加され、デフォルトでは無効
- REST APIに返金自動計算とプレビューエンドポイントが登場
- Store APIの
expected_totalによりチェックアウト時の金額不一致を検出 - バリエーション商品のN+1クエリ削減で管理画面とフロントの表示が高速化
WP-Stagingサイトが重大なエラーで表示されない原因と直し方
WP-Stagingの複製サイトにアクセスすると「このサイトで重大なエラーが発生しました」と表示され、デバッグログに call_user_func_array の TypeError が記録される場合、PHP 8系ではコアファイルの欠落や混在が致命的エラーへ変わる。PHP 7.4系へ一時的に切り替えて管理画面へ入り、WordPressコアの再インストールとプラグイン更新を行えば根本から直る。
WP-Stagingサイトが重大なエラーになる原因
デバッグログの最終行には call_user_func_array() が「Argument #1 ($callback) must be a valid callback」という趣旨の TypeError を投げ、_wp_register_default_icon_collections という関数が見つからないことが記録される。この関数は WordPress 本体の wp-includes/theme.php で定義されるもので、本来は必ず存在しているはずだ。
WP-Staging はライブサイトのファイルとデータベースをコピーしてステージングサイトを作る。このとき wp-includes 内のファイルが不完全にコピーされていたり、旧バージョンのコアファイルと新バージョンが混在したりすると、関数が未定義のまま WordPress の読み込み処理が進み、このエラーが発生する。
PHP 8.0 以降は call_user_func_array() に存在しない関数を渡すと、警告ではなく TypeError を投げて処理を停止する。PHP 7.4 までは警告を出して読み込みが続いたため、バージョンを下げると画面が復帰する。ただし原因であるコアファイルの欠落は残ったままなので、根本解決にはならない。
同じログに Wordfence や ThemeWhizzie の Deprecated 警告も出ている。これらは PHP 8 で廃止予定になった古い記法への警告で、単体ではサイトを落とさない。ただ PHP 8 非対応の古いコードが残っている証拠なので、更新で片付けておく必要がある。
debug.logに記録されたエラーを読み分ける
WordPress のデバッグ情報は wp-content/debug.log に保存される。今回のログには Deprecated 警告が数件並び、最後に Fatal error が1件出ている。サイトが落ちる直接原因は Fatal error の1件だけだ。まだログを有効にしていない場合は、wp-config.php を編集して次の3行を追加する。
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );Fatal error の内容は「呼び出そうとした関数が見つからない」という意味だ。_wp_register_default_icon_collections が WordPress 本体に無いことから、コアの関数定義が不足していると判断できる。Wordfence の Non-canonical cast や ThemeWhizzie の Creation of dynamic property は、PHP 8 で非推奨となった書き方を警告しているにすぎない。
PHP 7.4系へ切り替えて管理画面に戻る
最初の応急処置として、サーバーの PHP バージョンを 7.4 系へ変更する。ホスティングの管理画面にある「PHP バージョン管理」や「PHP Selector」などから選択するのが一般的だ。IIS 10 で FastCGI を使っている場合は、php-cgi.exe のパスを 7.4 系へ変更する。切り替え後はステージングサイトを再読み込みして、管理画面に入れるか確認する。
PHP 8 系ではコールバック不足が TypeError で致命化し、PHP 7.4 系では警告として読み込みが継続する。この違いにより、バージョンを下げると一時的にサイトが復帰する。
ただし PHP 7.4 系はセキュリティサポートが終了している。常用するのは避け、次の手順で WordPress 本体とプラグインを整えた後、PHP 8 系へ戻すのが安全だ。
WordPressコアを再インストールして欠落ファイルを戻す
根本原因は WordPress 本体のファイルが不完全なことだ。管理画面に戻れたら、ダッシュボードの「更新」画面から現在のバージョンを再インストールするのが最も簡単だ。ファイルの欠落や破損が解消され、関数が再び見つかるようになる。
復旧手順の全体像は上のとおり。各ステップの詳細を以下に示す。
ダッシュボードからコアを再インストールする
管理画面の「ダッシュボード」→「更新」を開くと、「WordPress の最新バージョンを実行しています」の下に「バージョン XX を再インストール」というボタンが表示される。ここを押せば、同じバージョンのコアファイルが公式配布パッケージから取得され、欠落している wp-includes 内のファイルが上書きされる。
再インストール後にステージングサイトを更新し、重大なエラーが消えたかを確認する。もし管理画面にも入れない状態なら、次の FTP で対処する方法を試す。
管理画面に入れないなら FTP で wp-includes を上書きする
ステージングサイトにアクセスできない場合、FTP または SFTP でサーバーへ接続する。WordPress の公式サイトから同じバージョンのパッケージを取得し、その中の wp-includes と wp-admin フォルダを、壊れているステージング側へ上書きアップロードする。
wp-content フォルダは上書きしない。ここにはテーマやプラグイン、アップロード画像が入っており、上書きすると設定が消える危険がある。あくまでコアのファイルだけを入れ替えるのが安全だ。
ステージングサイトを作り直す判断
破損の範囲が広い場合や、エラーが複数回繰り返される場合は、WP-Staging でステージングサイトを作り直すのも有効だ。その際、除外設定やファイルコピーの途中で止まっていないか、保存容量が十分かを確認する。ライブサイト側が正常なら、再作成のほうが速く済むことも多い。
Wordfenceと使用テーマをPHP 8対応版へ更新する
Fatal error とは別に、Wordfence と ThemeWhizzie から Deprecated 警告が出ている。これは今すぐサイトを落とすものではないが、PHP 8 系で廃止された書き方を使っており、将来の PHP 更新で同じく致命的エラーへ変わる可能性がある。根本解決の段階でまとめて更新しておく。
Wordfence はプラグインの更新画面から最新版へ更新できる。テーマが市販テーマで更新が止まっている場合は、PHP 8 非対応の警告が出続けるため、テーマの差し替えや該当するウィザード機能の無効化を検討する。更新が終わったら PHP を 8 系へ戻し、ステージングサイトが表示されるか、デバッグログに Fatal error が出ないかを確認する。
よくある質問
PHP 7.4に戻すだけで問題は解決するのか
サイトは一時的に復帰するが、コアファイルの欠落や混在という原因は残る。PHP 7.4 系はセキュリティサポートが終了しているため、WordPress コアの再インストールで根本解決してから PHP 8 系へ戻すのが正しい流れだ。
管理画面にも入れないときはどうするのか
FTP または SFTP でサーバーへ接続し、WordPress 本体の wp-includes と wp-admin を公式パッケージから上書きする。その前に wp-config.php でデバッグログを有効にしておくと、上書き後もエラーが出る場合に原因を特定しやすい。
WordPressコアの再インストールでデータは消えるのか
ダッシュボードからの再インストールでは wp-content を触らないため、テーマやプラグイン、アップロード画像、データベースの内容は消えない。念のため実行前にバックアップを取るのが安全だ。
ステージングサイトを作り直した方が速いのか
ファイル破損の範囲が広い場合や再発を繰り返す場合は、WP-Staging で作り直す方が確実だ。その際は除外設定と保存容量を確認し、ライブサイト側が正常であることを先に確かめておく。
Wordfenceの警告をPHP 8のままで消せるのか
Wordfence を最新版へ更新すれば大半の Deprecated 警告は消える。テーマ側の警告が残る場合は、該当するウィザード機能を無効化するか、PHP 8.1 系を選んで一時的に警告を抑える方法もある。ただし警告を無理に隠すより、コードを更新する方が安全だ。
この記事のポイント
- call_user_func_array の TypeError はコアファイル欠落が PHP 8 で致命化したもの
- PHP 7.4 への切り替えは応急処置で根本解決ではない
- 管理画面から WordPress コアを再インストールして欠落ファイルを戻す
- Wordfence とテーマを更新し PHP 8 へ戻して確認する
- ステージング作成時の除外設定やファイルの完全性も確認する