WordPress│カスタムタクソノミーの内部名を変更する手順と注意点

2023.03.082026.10.21

カスタムタクソノミーの内部名は、登録コードと保存済みの分類データの両方で使われます。

データベースの文字置換だけでは移行が完了せず、登録設定、URL、テンプレート、キャッシュも確認する必要があります。

内部名・表示名・URLスラッグを区別する

表示ラベルだけの変更ならlabels、URLだけの変更ならrewriteの設定を確認し、内部名を変える必要があるか先に判断します。

登録済みという警告は名前の競合を示し、それだけで予約語の使用と断定できません。

新しい内部名には、既存のタクソノミー・投稿タイプ・予約されたクエリ変数と衝突しない名前を選びます。32文字以内とし、小文字の英数字、ハイフン、アンダースコアを使います。

変更前に控えるもの

データベース全体と登録コードをバックアップし、検証環境へ複製します。

旧名に属するterm_taxonomy_id、term_id、parent、countと投稿の紐付け件数、現在の分類URLを保存します。

分類名そのものはterms、タクソノミーへの所属はterm_taxonomy、投稿との関連はterm_relationshipsで管理されます。

検証環境で登録設定を変更する

旧登録の引数と対象投稿タイプを維持して内部名だけを変更し、同じ機能を登録するコードが重複していないか確認します。

以下は旧名waza_old_kindから新名waza_new_kindへ移す場合のSQL例であり、そのまま本番へ貼り付けないでください。

wp_はデータベース名ではなくテーブル接頭辞なので、実際の接頭辞へ変更します。

SELECT taxonomy, COUNT(*) AS rows_count
FROM wp_term_taxonomy
WHERE taxonomy IN ('waza_old_kind', 'waza_new_kind')
GROUP BY taxonomy;

新名の行がすでにある場合はここで止め、既存分類への統合を別途設計します。

対象テーブルがトランザクションに対応し、同時更新がない検証環境で次を実行します。

START TRANSACTION;
UPDATE wp_term_taxonomy
SET taxonomy = 'waza_new_kind'
WHERE taxonomy = 'waza_old_kind';
SELECT ROW_COUNT() AS changed_rows;
-- 控えた旧名の行数と一致するか確認
ROLLBACK; -- 最初は戻して件数を確認する

ロールバックまで行って変更件数を確認した後、バックアップ・停止時間・復元方法を用意して本実行を計画します。

本実行では最後のROLLBACKをCOMMITへ変更しますが、件数や対象が想定と異なる場合はコミットしません。

データ更新後の確認

対象分類のキャッシュを更新し、パーマリンク設定は移行時に一度だけ保存して再生成します。

毎アクセスflush_rewrite_rulesを実行するコードは追加しません。

旧名を参照するtax_query、テンプレート名、管理画面設定、REST連携を新名へ合わせます。ナビゲーションメニューに登録した分類リンク、タクソノミーを指定するブロック・ウィジェット、プラグイン独自の設定も点検します。このSQLはterm_taxonomyだけを変更するため、これらの保存済み参照は自動では更新されません。シリアライズされた設定をデータベース全体の文字置換で変更せず、対応する管理画面やAPIで個別に移行してください。

分類URLが変わる場合は旧URLと新URLの対応を作り、必要な転送を個別に設定します。

投稿との紐付け、親子関係、件数、分類一覧、個別投稿とREST出力を確認します。

分類データの一致とURLの動作を別々に判定する

確認対象	比較するもの
投稿の割り当て	変更前後のterm_taxonomy_idと投稿IDの組み合わせ
親子の分類	term_idとparent。名前の行数だけで判定しない
公開側の絞り込み	新しい内部名を指定したtax_queryの投稿ID
分類URL	各タームの変更前・変更後のURLと実際のHTTP応答
RESTなどの連携	登録設定のshow_in_rest・rest_baseと利用側の参照名

独立した検証用WordPressで、専用の旧・新タクソノミーと投稿を使い、変更件数、ロールバック、コミット後の投稿との紐付け・親子関係・新名での絞り込みを確認しています。

2026年10月3日には、WordPress 7.1.2 / SWELL 2.19.0の基本パーマリンクで、分類URLのHTTP応答とRESTの匿名取得・編集拒否を追加確認しました。

実際のサイト全体の移行や転送設定の動作確認は別途必要です。

パーマリンクが基本設定の場合は、rewriteのスラッグが同じでもURLのクエリ変数名が変わる場合があります。「URLスラッグを変えていないから旧リンクもそのまま動く」と判断せず、保存したURL対応表で確認してください。

旧URLの200応答だけで移行成功を判定しない

隔離環境での確認	結果
新しい内部名の分類URL	200。対象の分類名と投稿を表示
登録を外した旧内部名の分類URL	200だがトップページを表示。新分類への自動転送はない
新しいREST経路の分類取得	200。タームIDと親IDを維持
旧REST経路へのアクセス	404。新しい経路へ自動転送されない
新分類でRESTの投稿一覧を絞り込む	割り当て済みの公開投稿を取得。非公開投稿は含まれない
未ログインで分類をcontext=editとして取得	401。編集用の取得を拒否

基本パーマリンクでは、登録を外した分類のクエリ変数が解釈されず、旧URLがトップページとして200を返す場合があります。

URL対応表の各行について、応答コード・転送先・分類名・表示された投稿を照合してください。

この検証では独自の転送コードを追加していません。

URLやREST経路を維持する設計が必要な場合は、内部名とは別にrewrite・query_var・rest_baseの設定と利用側の参照を確認し、検証環境で旧経路を試してください。

戻し方と検証範囲

戻す場合はバックアップからデータと登録設定を同じ時点へ戻し、キャッシュとパーマリンクを再確認します。

この記事のSQLは移行手順の例で、本サイトの分類データを変更したり実データ移行を検証したりしたものではありません。

参照：register_taxonomyの登録条件と予約語。

ローカルの独立した一時テーブルでは、2行の変更、対象外行の維持、ID・親・件数の維持、ロールバックを確認しました。

このSQL試験はWordPress全体の分類移行やURL動作の検証とは別です。

よくある質問：WordPressでカスタムタクソノミーの内部名を変更するとき

カスタムタクソノミーの内部名は、データベースの文字置換だけで変えられますか？

変えられません。記事では、内部名は登録コードと保存済みの分類データの両方で使われるため、データベースの文字置換だけでは移行が完了せず、登録設定、URL、テンプレート、キャッシュも確認する必要があります。

内部名を変える前に、表示名やURLだけの変更で足りないか確認しますか？

確認します。記事では、表示ラベルだけの変更ならlabels、URLだけの変更ならrewriteの設定を確認し、内部名を変える必要があるか先に判断します。

新しい内部名は、どう選びますか？

既存のタクソノミー・投稿タイプ・予約クエリ変数と衝突しない32文字以内の名前を選び、小文字の英数字・ハイフン・アンダースコアを使います。「登録済み」という警告だけで予約語の使用とは断定できません。

変更する前に、何を控えますか？

記事では、データベース全体と登録コードをバックアップし、検証環境へ複製します。旧名に属するterm_taxonomy_id、term_id、parent、countと投稿の紐付け件数、現在の分類URLを保存します。

記事のSQL例は、本番にそのまま実行してよいですか？

実行しないでください。記事では、SQLは旧名から新名へ移す場合の例であり、そのまま本番へ貼り付けないでください。wp_はデータベース名ではなくテーブル接頭辞なので、実際の接頭辞へ変更します。新名の行がすでにある場合はここで止め、既存分類への統合を別途設計します。対象テーブルがトランザクションに対応し、同時更新がない検証環境で実行します。

変更したあと、何を確認しますか？

記事では、投稿の割り当て（変更前後のterm_taxonomy_idと投稿IDの組み合わせ）、親子の分類（term_idとparent）、公開側の絞り込み、分類URL、RESTなどの連携（show_in_rest・rest_baseと利用側の参照名）を確認します。件数、分類一覧、個別投稿とREST出力も確認します。

旧URLが200を返せば、移行は成功していますか？

成功とは限りません。記事では、基本パーマリンクでは、登録を外した分類のクエリ変数が解釈されず、旧URLがトップページとして200を返す場合があります。URL対応表の各行について、応答コード・転送先・分類名・表示された投稿を照合します。

旧URLや旧REST経路は、自動で新しい経路へ転送されますか？

されません。記事の検証では、旧内部名の分類URLは新分類への自動転送がなく、旧REST経路へのアクセスは404で新しい経路へ自動転送されませんでした。URLやREST経路を維持する設計が必要な場合は、rewrite・query_var・rest_baseの設定と利用側の参照を確認し、検証環境で旧経路を試します。なお、この記事のSQLは移行手順の例で、実データ移行を検証したものではありません。