Speedixでプロファイリング用カスタムページを追加できない時の対処法
Speedixのプロファイリング設定で3つ目以降のページを追加するには、設定画面上部の検索フィールドに測定したいページのタイトルやスラッグを入力し、表示される候補から選択する。バージョン2.1.7以降ではこの操作が明確化され、追加ボタン代わりに機能する。
なぜ設定画面に「追加」ボタンがないのか
SpeedixはWordPressサイトのパフォーマンスプロファイリングに特化したプラグインで、任意のページ読み込み時間やクエリを詳細に計測できる。設定画面（「ツール」→「Speedix」）を開くと、デフォルトでホームページと1つの主要ページがプロファイリング対象として登録されている。そこへ新たなページを増やしたい場合、画面内に明示的な「追加」ボタンや「新規ページ」リンクは存在しない。このUI設計が混乱を招きやすい。
実際の追加手段は、画面上部にある検索フィールドだ。ここに任意の文字列を打ち込むと、既存の公開ページ・投稿・固定ページの中から、タイトルやURLスラッグに一致するものがオートコンプリートで候補表示される。目的のページをクリックするだけで、即座にプロファイリングリストへ追加される仕組みになっている。
バージョン2.1.6以前はこの検索フィールドの役割が説明されておらず、「どうやって追加するのか」という問い合わせが多発していた。最新バージョンへアップデートすると、入力欄のプレースホルダー文言や補助テキストが改善され、直感的に理解しやすくなっている。
プロファイリング対象のページを実際に追加する手順
設定画面を開き現在の登録状況を確認する
WordPress管理画面の左メニューから「ツール」を選び、「Speedix」をクリックする。するとプロファイリングの設定ページが表示され、現在登録されているページ一覧が上部にリスト表示される。初期状態ではホームページ（フロントページ）と、直近でアクセスの多いページなどが2件ほど表示されているはずだ。
この画面で、リストのすぐ上に配置されているのが追加用の検索フィールドである。テキスト入力欄と虫眼鏡アイコンが表示されているので、ここが操作の起点となる。
検索フィールドにページ情報を入力する
フィールドに、追加したい固定ページや投稿のタイトルをそのまま入力してみる。たとえば「会社概要」や「キャンペーン特設ページ」といった日本語タイトルで問題ない。スラッグ（URLの最後の部分）がわかっているなら、「about」「campaign」のように英数字で絞り込んでもよい。
何文字か打ち込むと、その文字列を含む公開済みのページ群が検索され、フィールドの下にドロップダウン形式で候補が表示される。このオートコンプリート機能は、投稿タイプ（固定ページ・投稿）を問わず、公開ステータスが「公開」になっているものだけが対象だ。
候補をクリックして追加する
目的のページが候補に出てきたら、その行をクリックする。クリックした瞬間、画面下部のプロファイリングリストに新しい行が追加される。追加と同時にバックグラウンドで最初の計測が走るため、数秒後に読み込み時間やクエリ数などのデータが表示される。
検索候補に出てこない場合は、そのページが本当に公開状態かを確認する。非公開や下書きのページは計測対象にできない。また、カスタム投稿タイプで作成されたページ（例：WooCommerceの商品ページ）も、テーマやプラグインが適切に公開ステータスを返している限りは候補に表示される。
追加したプロファイリングページを管理・削除する
登録したページが不要になったり、計測を停止したい場合は、リスト右端に表示されるゴミ箱アイコンまたは「削除」リンクをクリックする。確認ダイアログは出ないものの、即座にリストから消え、それ以降の計測は行われなくなる。
削除しても過去の計測データはデータベースに蓄積されたままになる。完全に履歴を消去したい場合は、Speedixが提供する「データリセット」機能を使うか、プラグインを一度無効化して再有効化する方法もある。ただし再有効化するとすべてのカスタムページ設定が初期化されるため、必要なページは再度追加し直す必要がある。
よくある質問
検索しても目的のページが候補に出てこないのはなぜか
公開状態でない（下書き・非公開・パスワード保護）ページは候補に表示されない。また、何らかのキャッシュプラグインがREST APIの応答を妨げていると、検索機能自体が動作しない場合がある。その場合はキャッシュを一時的にクリアするか、プラグインの競合を切り分けるために他のプラグインを停止してから試すとよい。
一度に登録できるプロファイリングページ数の上限はあるか
Speedixに明示的な上限は設けられていない。ただし計測対象が増えるほどバックグラウンド処理の負荷が上がり、サイト全体のパフォーマンスに影響を与える可能性がある。数ページから十数ページ程度に絞って運用するのが現実的だ。
追加したページの計測頻度は変更できるか
デフォルトでは1時間に1回程度の間隔で自動計測される。この頻度は設定画面の「計測間隔」項目から変更可能で、最短15分から24時間まで選択できる。ただしあまり短い間隔にするとサーバーリソースを消費するため、必要なページだけ短く設定するといった使い分けが推奨される。
バージョン2.1.6以前の古いSpeedixを使っている場合はどうすればよいか
まずはプラグインを最新版（2.1.7以上）に更新する。検索フィールドの補足説明やプレースホルダーが改善され、操作方法が一目でわかるようになる。更新が何らかの理由でできない場合は、画面上部のテキスト入力欄が追加機能を兼ねていると理解して、前述の手順でページを追加すれば問題ない。
この記事のポイント
- Speedixのプロファイリングページ追加は検索フィールドから行う
- ページタイトルやスラッグの一部を入力すると候補が表示される
- 候補をクリックするだけで即座に追加され計測が始まる
- 公開状態のページのみが検索対象なので下書きなどは追加不可
- 最新バージョンではUIが改善され操作が直感的になった
・ Reddit、Stack Overflow、WordPress.org フォーラムを日々巡回し、現場の悩みを拾い上げて記事化
・ WordPress、WooCommerce、Next.js などモダンWeb制作領域のトラブルシューティングが専門
・ 「検索しても答えが見つからなかった」を一つでも減らすことが目標
・ エラーメッセージから根本原因にたどり着く粘り強い調査が得意
・ 初心者がつまずきやすい箇所を先回りで解決する記事作りを心がけている
WooCommerce Subscriptions Health Checkリリース、定期購入の健全性をチェック
WooCommerce Subscriptionsプラグインに、サブスクリプションの支払い状態を可視化する「Subscriptions Health Check」ツールが追加された。WooCommerce Developer Blogの2026年4月30日の記事で発表されている。
このツールは、本来は自動更新されるべき定期購入が手動更新のまま止まっていないか、あるいは次回支払日が欠落していないかを店舗管理者がすぐに把握できるようにするものだ。WooCommerce 3.0以降のサブスクリプションストアであれば、過去のバグの影響有無にかかわらず利用できる。
リリースの直接のきっかけは、定期購入が意図せず手動更新に切り替わる可能性がある4件のバグが公に報告されたことだ。しかし開発チームは、原因がバグに限らず、決済ゲートウェイの変更やインポート時の設定など、同じような「自動更新されない」状態はさまざまな要因で起こり得ると判断。特定のバグ被害者を探すのではなく、潜在的に問題を抱えるサブスクリプションを幅広くリストアップする仕組みを選んだ。
サブスクリプション健全性チェックツールの登場背景
サブスクリプション型ビジネスでは、決済の自動継続が収益の柱になる。そのため、意図せず手動更新に設定されたまま放置されると、気づかないうちに売上を失うリスクがある。開発チームはもともとこうした健全性チェック機能をロードマップに載せていたが、公のバグ報告を受けて開発を前倒しした。
報告されたバグは、WooCommerceの高性能オーダーストレージ（HPOS）環境で、定期購入の作成時に_requires_manual_renewalフラグが誤ってtrueのままになるというものだ。調査の過程で、キャッシュの不整合やデータ同期の欠落といった根本原因がいくつか特定された。しかしチームは、これらが修正済みであっても「自動更新されない定期購入」という状態は他の経路でも発生し得ると考えた。
たとえば、店舗管理者が手動更新設定に切り替えた、決済トークンが削除された、他社のカートシステムからインポートした際に手動扱いになった、カスタムコードやサードパーティ連携がフラグを書き換えた、といったケースだ。これらをすべて機械的に区別するのは難しい。そこで最終的には、自動更新が可能な支払い方法を持ちながら手動更新になっているサブスクリプションをすべて可視化し、その判断をマーチャントに委ねる設計が採用された。
4つのバグが与えた影響の実態
WooCommerce開発者ブログの記事では、公表された4件のバグすべてがすでに修正済みであることが明かされている。しかし、修正当時はこれらのバグが「定期購入をサイレントに手動更新へ切り替える」というマーチャント目線での影響まで認識されていなかった。
バグの組み合わせが実際に問題を引き起こしていたのは、HPOSを有効にしたストアで、かつ特定のバージョンのWooCommerce Subscriptionsを動かしていた期間に限られる。バグ1（期限切れHPOSキャッシュ）は2024年3月に修正済み。バグ2（HPOSバックフィルメソッド欠落）は2023年中に解消。バグ3（再取得による不整合）は2024年5月に修正された。独立して「手動更新化」を引き起こすわけではなく、バグ1とバグ3が同時に存在する環境で、購入手続き時にフラグが誤設定されるという経路だった。
影響を受けた可能性が最も高いのは、2023年10月から2024年3月の間にHPOSを有効化し、かつWooCommerce Subscriptions 6.1.0未満を利用していたストアだ。2024年5月以降にサブスクリプションを開始したストアは、今回のバグの影響を受けていない。ただし、開発チームはこのツールをバグの有無にかかわらず定期購入全体の監視に役立ててほしいとしている。
ツールの使い方と主要機能
Health Checkツールは、WordPress管理画面の「WooCommerce」→「ステータス」→「サブスクリプション」タブに設置されている。ステータスページには、最終スキャン日時と、手動スキャンの実行ボタンが表示される。
「今すぐ実行」ボタンでオンデマンドのスキャンが可能だ。スキャンはバッチ処理で行われ、サーバーやデータベースに過負荷がかからないようスロットリングが組み込まれている。定期的な自動スキャンも、WooCommerce設定で有効にすれば夜間に実行され、結果が保存される。保存された結果はページを開くたびに即座に表示されるため、毎回重いクエリを待つ必要はない。
3つのタブで状態を整理
ツールを開くと、「すべて」「自動更新をサポート」「更新漏れ」の3つのタブが表示される。
「すべて」タブでは、ストア内の全サブスクリプションが一覧できる。特定の条件で絞り込みたい場合の全体像把握に使う。
「自動更新をサポート」タブは、今回のツールの中核となる部分だ。次の条件をすべて満たすサブスクリプションが表示される。ステータスが「有効」「保留中」「キャンセル保留」のいずれかである、_requires_manual_renewalフラグがtrueである、支払い方法が自動更新をサポートしている、かつ顧客がそのゲートウェイに有効な支払いトークンを保存している。つまり、自動更新できるのに手動扱いになっているサブスクリプションが浮かび上がる。
「更新漏れ」タブには、次回支払日が空欄のまま更新が止まっているものや、過去の支払日から24時間以上経過しても対応する更新注文が生成されていないサブスクリプションが表示される。これらはスケジュールされたアクションの不具合やサーバー移行時の問題など、さまざまな原因で発生し得る。
表示される項目とフィルター
各行には、サブスクリプションID、作成日、顧客名、請求サイクル、ステータス、請求モード（手動/自動）、自動更新の設定（顧客がMy Accountでオプトアウトしたかどうか）、支払い方法、次回支払日、最新の更新注文ステータス、直近の成功支払日が表示される。他社システムから手動更新としてインポートされたものは「インポート（手動）」と明示され、フィルターで除外されるのではなく、タグ付けされる。
フィルターとして、ステータス別、請求モード別、更新注文ステータス別、自動更新オプトアウトの有無別、IDやメールアドレスによる検索が用意されている。列のソートも可能で、デフォルトでは新しいサブスクリプションが先頭に来る。
このツールは、あえて自動修復を行わない設計になっている。たとえば、手動更新に切り替わっているサブスクリプションを自動で「自動更新」に戻したり、店舗全体で「自動支払いを無効化」しているストアのサブスクリプションを非表示にしたりはしない。すべての判断は店舗の文脈を知るマーチャントに委ねられている。
バグの詳細とマーチャントへの影響
公表された4件のバグのうち、定期購入の手動更新化に直接つながったのはバグ1とバグ3の組み合わせだ。バグ2はスケジュールメタデータの不整合を引き起こしたもので、更新日に更新処理そのものが発火しないという別の症状となる。バグ4はゲートウェイ変更時の復旧ギャップで、単体では不具合を生み出さない。
バグ1とバグ3の組み合わせで何が起きたか
HPOS環境で注文が作成されると、バグ1によって定期購入の日付更新後にキャッシュがクリアされず、バグ3の再取得処理がキャッシュ経由で古い状態を読み取ってしまう。その結果、メモリ上でクリアしたはずの_requires_manual_renewalフラグが、保存時に古い値（true）のままデータベースに書き込まれるというものだ。
このフラグが誤ってtrueになると、最初の更新日に定期購入は「保留中」になり、保留中の更新注文が作成され、顧客に「手動で支払いを」というメールが送られる。このメールはデフォルトで有効になっていることが多く、開発チームのオプトインデータによれば約91.8%のストアで送信されていたという。つまり、ほとんどのケースで顧客には支払いを促す通知が届いており、完全にサイレントで見逃される状態ではなかった。
ただし、顧客がそのメールに気づかずに放置すると、更新が止まったままになる。マーチャントにも通知が行かないケースがあったため、結果として気づかないうちに収益機会を失う可能性があった。今回のHealth Checkツールは、まさにこの「更新されていない状態」を検出するためにある。
バグ2の異なる影響
バグ2はスケジュール関連のメタデータがHPOS互換モードで同期されない問題で、更新日時がずれたり、更新イベントが発火しなかったりした。影響範囲は2023年8月から12月にデータ移行が行われた一部のストアに限られる。このケースでは更新注文自体が生成されず、通知の記録すら残らないため、「更新漏れ」タブで初めて表面化する。
今後の展開とマーチャントへの推奨事項
今回のHealth Checkツールは、あくまで「第1弾」と位置づけられている。WooCommerce開発チームは、すでに次のバージョンでツール画面から直接サブスクリプションを修正できる機能の開発に着手している。たとえば、一括で自動更新に戻す、手動更新であることを明示的に確定させるといった操作が、ツール上で完結するようになる見込みだ。
また、今回の一連のバグ対応を受けて、チェンジログの書き方も改善された。今後は、バグ修正がマーチャントの収益や顧客体験に影響を与える可能性がある場合、その内容をチェンジログに明記し、必要に応じて影響を受けるストアに直接連絡する方針だ。これは単なるコミュニケーションギャップの解消ではなく、エコシステム全体での透明性を高める取り組みといえる。
ストア管理者が今すぐやるべきこと
まず、WooCommerce Subscriptionsを最新バージョン（8.6.1以降）にアップデートする。そのうえでHealth Checkツールを実行し、「自動更新をサポート」タブと「更新漏れ」タブの内容を確認してほしい。特に、HPOSを有効にしていて、かつ2024年3月以前からサブスクリプション販売を行っているストアは重点的なチェックが推奨される。
もし手動更新にすべきでないサブスクリプションが見つかった場合は、手動で編集して自動更新に戻すか、WooCommerceサポートに問い合わせてサポートを受けることができる。開発チームは今回のツール公開に合わせてサポート体制を強化しており、結果の解釈に迷った場合でも相談しやすくなっている。
この記事のポイント
- WooCommerce Subscriptionsに定期購入の健全性を可視化するHealth Checkツールが追加された
- 自動更新可能なのに手動更新設定になっているサブスクリプションや、更新日が欠落しているものを一覧できる
- 過去のバグ（HPOS環境でのキャッシュ不整合など）の影響を受けていなくても、すべてのストアで活用できる汎用機能
- ツールは自動修復せず、判断はすべてマーチャントに委ねられる。次のバージョンで一括操作機能が追加予定
- バグの影響が最も疑われるのは2023年10月〜2024年3月にHPOSを有効にしていたストア。2024年5月以降のストアは今回のバグの直接影響なし
・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験