
WooCommerce 11.0で配送クラスが非公開タクソノミーに変更
WooCommerce 11.0が2026年7月28日にリリースされる。このアップデートでは、商品の送料計算に使われる「product_shipping_class」タクソノミーが非公開に変更される。これまで明示的に設定されていなかった公開フラグが、WordPress のデフォルトで true 扱いとなっていた状態が解消され、内部データとしての扱いが明確になる。
多くの店舗や拡張機能では特別な対応は不要だが、配送クラスを公開タクソノミーとして利用していたコードは見直しが必要だ。この変更の背景と、開発者が確認すべきポイントを整理する。
WooCommerce 11.0で配送クラスのタクソノミーが非公開になる

配送クラス(product_shipping_class)は、商品を送料計算のグループに割り当てるための仕組みだ。たとえば「大型商品」「冷蔵商品」といったクラスを作り、各商品に紐づけることで、配送方法ごとに異なる送料を設定できる。
これまでの動き(Before)
WooCommerce 11.0 より前のバージョンでは、配送クラスをタクソノミーとして登録する際に public 引数が指定されていなかった。WordPress のタクソノミー登録関数は public が省略されるとデフォルトで true を適用する。そのため、配送クラスは「公開タクソノミー」として扱われ、is_taxonomy_viewable() が true を返していた。
この状態では、サイトマップ生成、タクソノミーアーカイブの処理、パブリックタクソノミーを列挙するクエリなどに配送クラスが意図せず含まれることがあった。
変更後の動作(After)
WooCommerce 11.0 からは、タクソノミー登録時に 'public' => false が明示的に設定される。これにより is_taxonomy_viewable( 'product_shipping_class' ) は false を返すようになり、WordPress の各種 API で配送クラスが非公開タクソノミーとして扱われる。
この変更はデータそのものを削除するものではない。すでに登録された配送クラスのタームや商品との紐づけ、送料ルールはそのまま維持される。
なぜこの変更が必要だったのか

配送クラスは本来、商品カテゴリーやタグのように顧客に見せるためのカタログ用タクソノミーではない。あくまでも送料計算のための内部データである。ところが公開タクソノミーとして振る舞うことで、サイトマップに配送クラスのアーカイブ URL が含まれたり、SEO ツールが意図しないページを認識したりといった副作用が生じていた。
一部のストアでは、この挙動を避けるために手動で除外設定を行なっていた。WooCommerce コアの修正により、根本的な原因を取り除き、特に設定をしなくても配送クラスが公開面に漏れ出さないようになる。
また、WordPress の public フラグが false になると、publicly_queryable も自動的に false を継承する。つまり、URL で配送クラスの一覧ページに直接アクセスすることもできなくなる。こうした一貫した内部データとしての扱いが、開発者にとっても予測しやすい動作につながる。
影響を受けるコードのチェックポイント

WooCommerce Developer Blog の案内に沿って、以下のようなコードを含むテーマやプラグインは変更後の動作を確認する必要がある。
is_taxonomy_viewable( 'product_shipping_class' )が true を返すことを前提にしている- 配送クラスのアーカイブページへのリンクをフロントエンドに生成している
- サイトマップや SEO、ナビゲーションの生成時に
product_shipping_classを public タクソノミーとして含めている get_taxonomies()などで公開タクソノミー一覧を取得し、その中に配送クラスが含まれることを期待している- タクソノミーの公開ステータスをもとに REST API や GraphQL のスキーマ、検索、フィルタリングをカスタマイズしている
- 送料計算以外の汎用的な商品グルーピングに配送クラスを流用している
ごく単純に、配送クラスを送料計算だけに使っている場合は影響を受けない。商品編集画面で配送クラスを設定したり、フックで送料を分岐させたりするコードはそのまま動作する。
開発者が取るべき具体的な対応

基本は何もしなくてよい
配送クラスを送料計算のみに使っているのであれば、コードの修正は不要だ。WooCommerce のコア変更がそのまま適用され、配送クラスは内部タクソノミーとして適切に管理される。
どうしても公開が必要な場合のフィルターフック
特定のサイトや拡張機能で、あえて配送クラスを公開タクソノミーとして扱い続けたいケースもあるだろう。たとえば、配送クラスのアーカイブページをカスタムデザインで用意している場合などだ。
そのような場合は、WooCommerce が用意している register_product_shipping_class_taxonomy_args フィルターを使って、登録時の引数を上書きできる。
add_filter(
'register_product_shipping_class_taxonomy_args',
function ( $args ) {
$args['public'] = true;
$args['publicly_queryable'] = true;
return $args;
}
);ただし、この方法はあくまで例外的な対応である。WooCommerce Developer Blog も述べているように、公開タクソノミーとして再利用するのではなく、本来の目的に合ったカスタムタクソノミーを新たに用意するほうが長期的に健全だ。
長期的にはカスタムタクソノミーへの移行を
商品を顧客向けにグルーピングしたい場合は、商品カテゴリー、商品タグ、商品属性、あるいは専用のカスタムタクソノミーを利用すべきだ。配送クラスはあくまで内部の送料計算用と割り切り、公開用の分類とは役割を分けることで、サイト構造が整理され、SEO の観点からも無駄なアーカイブページが生まれなくなる。
この変更はデータ移行を伴わない「公開状態の切り替え」であり、既存の設定には一切手が加えられない。しかし、今回のバージョンアップをきっかけに、配送クラスを公開タクソノミーとして使っていたコードがあれば、設計を見直す良い機会になるだろう。
この記事のポイント
- WooCommerce 11.0 で配送クラスのタクソノミーが非公開になり、サイトマップやアーカイブに現れなくなる
- 送料計算だけに使っているストアや拡張機能は特別な対応不要
is_taxonomy_viewable()や公開タクソノミーの一覧に依存しているコードは見直しが必要- どうしても公開が必要な場合はフィルターフックで復活できるが、長期的にはカスタムタクソノミーの利用を推奨

・ 複数業界における17年間のデジタルビジネス開発経験
・ ウェブサイト開発のためのHTML、PHP、CSS、JavaScript等の実用的知識
・ 15ヶ国語対応の多言語SaaSの開発経験
・ 17年間にも及ぶ、Eコマース長期運営経験
・ 幅広い業界でのSEO最適化の豊富な経験
