WooCommerceの集計処理で「既知の注文IDを指定すると取得できるのに、注文一覧は0件になる」という症状があります。この時、管理画面に注文が見えるからAPIの問題、一覧が空だから注文データが消えた、と一足飛びに判断すると原因を見失います。
結論：個別取得と一覧取得を別経路として切り分ける
最初に確認するのは、注文の有無ではなく取得経路の差です。wc_get_order()やRESTの個別注文が成功し、wc_get_orders()や注文一覧RESTだけが0件なら、注文オブジェクトの復元よりもコレクションクエリ側へ原因範囲を狭められます。その後にHPOSかCPTか、権限、検索条件、追加フィルターの順で確認します。
なぜ「注文がない」とは限らないのか
WooCommerceには、1件の注文をIDから復元する処理と、条件に合う注文をまとめて検索する処理があります。個別取得は対象IDが分かっていれば注文オブジェクトを返せます。一覧取得は状態、作成日、並び順、件数、データストア、追加されたクエリ条件を通って対象を探します。したがって片方だけ成功することがあります。
実際の検証では、複数の既知IDは個別RESTで取得でき、注文の投稿実体も存在しました。一方で、既知IDのinclude指定、特定日、状態を広げた最新一覧のすべてが0件でした。管理権限も確認済みだったため、注文不存在、日付範囲、単純な権限不足だけでは説明できず、CPTの一覧クエリ層に入るフィルターまたは互換性問題まで原因範囲を絞れました。
確認手順1：読み取りだけで差分を固定する
- 管理画面で存在を確認できる注文を1件選び、注文番号や顧客情報は公開ログへ残さない
- 同じ認証で個別注文REST、
wc_get_order()、注文一覧REST、wc_get_orders()を比較する - HTTPステータスだけでなく、返却件数、ヘッダーの合計件数、注文オブジェクトの有無を記録する
- 修正前は設定変更、HPOS切替、プラグイン停止を行わず、再現条件を保存する
WordPressマルチサイトでは、ユーザー情報に表示されるroleだけで実効権限を判断できない場合があります。権限の見方はアプリケーションパスワードの権限確認手順も参考になります。
確認手順2：HPOSとCPTを先に確定する
WooCommerceの注文保存方式は、HPOSの専用注文テーブルと、WordPressの投稿・メタを使う従来CPTで調べる場所が変わります。先に現在のデータストアを確定しないと、存在しないテーブルや関係のないフックを追うことになります。
| 確認点 | HPOS | 従来CPT |
|---|---|---|
| 主な保存先 | WooCommerce専用注文テーブル | shop_order投稿とメタ |
| 独自条件の主な確認先 | woocommerce_order_query_argsなど | woocommerce_order_data_store_cpt_get_orders_queryなど |
| 見るべき差 | 専用テーブルと同期状態 | 投稿実体とWP_Queryへ渡る条件 |
WooCommerce公式もwc_get_orders()とWC_Order_Queryを標準の注文取得方法とし、HPOSと従来方式で拡張フックを分けています。まずは公式の注文クエリ仕様と現行バージョンの引数を照合してください。
確認手順3：条件を最小化して0件化する場所を探す
一覧クエリは一度に多くの条件を付けず、全件に近い最小条件から1項目ずつ戻します。状態をcompletedだけにした結果が0件でも、他の状態に注文がある可能性があります。日付もサイトのタイムゾーンとUTCの混同があるため、まず日付なし、次に広い範囲、最後に本来の範囲へ狭めます。
- 状態指定なし、またはWooCommerceが認識する全状態
- 日付指定なし
- 取得件数を小さくし、戻り値はIDだけにする
- 既知IDの
includeを単独で試す - 独自のmeta条件、除外条件、管理画面用フィルターを外して比較する
一覧0件でも確定売上0とは扱わない
集計APIが一覧クエリに依存している場合、その0件は「取得できなかった」可能性があります。個別注文、決済、ライセンス、管理画面など別の現物と一致するまで、売上0、購入0、注文0へ確定しないことが重要です。
確認手順4：追加フィルターと互換性問題を特定する
最小条件でも一覧だけ0件なら、テーマ、プラグイン、mu-plugin、スニペットが注文クエリへ条件を追加していないかを調べます。停止試験を行う場合は、本番で無差別に無効化せず、バックアップと保守時間を確保した検証環境で一つずつ比較します。
従来CPTでは、注文一覧の条件が最終的にWordPress側のクエリへ変換されます。独自フィルターが投稿タイプ、状態、日付、メタ条件を書き換えると、既知IDを含むはずの一覧まで空になることがあります。HPOSでは確認するフックとSQL層が異なるため、保存方式をまたいで同じ修正を流用しません。
フォールバックを入れる時の条件
標準wc_get_orders()を外して最初から独自SQLへ置き換えるのは避けます。WooCommerceの保存方式変更へ追従しにくくなるためです。必要なら標準クエリを優先し、空だった時だけ、保存方式と再現条件を確認した限定フォールバックを使います。
- 従来CPTであることを実行時に確認する
- 注文ID、状態、作成日時など集計に必要な最小項目だけを扱う
- 取得したIDは
wc_get_order()で正式な注文オブジェクトへ復元する - 顧客名、住所、メール、決済情報をログや独自RESTへ返さない
- 標準クエリが復旧したらフォールバックが発火しない自動テストを用意する
修正後の二重集計や旧処理の残存も確認してください。処理の切替は定期タスクの二重実行を防ぐ確認手順、更新後に動かない場合はWordPressプラグイン更新失敗の切り分けが関連します。
向いている対応と、専門家へ任せたい対応
自分で確認しやすい範囲
- 個別取得と一覧取得の比較
- HPOS/CPTの確認
- 状態・日付・件数条件の最小化
- 認証ユーザーの実効権限確認
慎重に進めたい範囲
- 本番データストアの切替
- 注文テーブルや投稿メタの直接更新
- 稼働中プラグインの一括停止
- PIIを含む独自注文APIの追加
よくある質問
Q. 注文一覧が0件なら注文データは消えていますか？
A. いいえ。既知IDの個別取得や管理画面で注文が確認できるなら、一覧クエリの条件やフィルターだけが0件化している可能性があります。個別取得と一覧取得を分けて確認してください。
Q. HPOSを有効にすれば直りますか？
A. 原因を特定せずに本番の保存方式を切り替えるのは避けてください。HPOSとCPTでは保存先と拡張フックが異なります。現行方式、同期状態、互換性を確認してから検証環境で判断します。
Q. 注文を直接SQLで集計してもよいですか？
A. 標準APIを優先します。限定フォールバックが必要な場合も、保存方式を確認し、最小の注文IDを取得してwc_get_order()で復元し、顧客情報を返さない設計にします。
Q. 修正後は何をテストしますか？
A. 標準一覧が成功する場合はフォールバックが動かないこと、標準一覧が空の再現条件では既知注文を取りこぼさないこと、日別件数・金額・商品集計が個別注文と一致することを確認します。
まとめ
WooCommerceで個別注文は取れるのに一覧が0件になる時は、注文不存在と決めつけず、取得経路、HPOS/CPT、権限、検索条件、追加フィルターの順で切り分けます。標準APIを正とし、独自フォールバックは再現条件が固定できた時だけ、PIIを扱わない最小構成にしてください。
WordPressで記事販売や投げ銭の導線を構築する場合はACS WooCommerce Content Pro、自分の状況に合う相談先を整理する場合はACSサービス選択診断も確認できます。
この記事は役に立ちましたか？
ありがとうございます！
