カテゴリーやタグの名前・スラッグ・説明文をまとめて直したいときは、wp_terms テーブルをSQLで直接書き換えるのではなく、WP-CLIの wp term update を一覧ファイルから繰り返し実行するのが安全です。この記事では、テーブルの役割の確認、バックアップ、現在のタームの書き出し、変更表の作成、試し実行、本実行、URL変更後の対応までを順に説明します。
コマンドはサーバーにSSHで入り、WordPressのインストールディレクトリ（wp-config.php がある場所）で実行する前提です。ここに挙げるコマンドは例なので、タクソノミー名やファイル名は自分の環境に合わせて読み替えてください。最初はステージング環境で試し、本番では作業前にデータベースのバックアップを取ってください。
wp_termsだけを書き換えてはいけない理由
タームのデータは複数のテーブルに分かれて保存されています。
wp_terms：タームID・名前（name）・スラッグ（slug）wp_term_taxonomy：どのタクソノミーに属するか、説明文（description）、親ターム（parent）、投稿数（count）wp_term_relationships：どの投稿がどのタームに付いているかwp_termmeta：タームのメタデータ
「カテゴリーの説明文を直したい」場合、実際に書き換える場所は wp_terms ではなく wp_term_taxonomy です。また、SQLで直接 UPDATE すると、WordPressが持っているタームのキャッシュが古いまま残ったり、edited_term などのフックが動かずSEOプラグインやキャッシュプラグインが変更を検知できなかったりします。スラッグの重複チェックも行われません。
wp term update は内部で wp_update_term() を呼ぶため、これらのテーブルの整合、キャッシュの削除、フックの実行、スラッグ重複のチェックをWordPress本体の処理としてまとめて行ってくれます。数千件規模でもこの方法で十分に処理できます。
手順1：WP-CLIの動作とバックアップを確認する
まずWP-CLIが動くこと、対象のサイトを見ていることを確認します。
wp --info
wp option get siteurl
wp taxonomy list --fields=name,label,hierarchicalwp taxonomy list で、作業対象のタクソノミー名（カテゴリーなら category、タグなら post_tag、カスタムタクソノミーならその登録名）を確認しておきます。表示名（ラベル）ではなく name 列の値を使います。
次にデータベースをファイルに書き出します。
wp db export ~/backup-before-terms-$(date +%Y%m%d-%H%M).sql書き出し先はWebから見えない場所（公開ディレクトリの外）にします。ファイルサイズが0でないこと、末尾まで書かれていることを ls -lh や tail で確かめてから次へ進みます。
手順2：現在のタームを書き出す
変更前の一覧をファイルに保存します。これが作業の元データにも、後で戻すときの記録にもなります。
wp term list category --fields=term_id,name,slug,parent,count --format=csv > terms-category-before.csvCSVをスプレッドシートで開くと、名前の表記ゆれ（全角・半角の混在、末尾のスペースなど）や、意味のないスラッグ（日本語名からそのまま作られた長いURLエンコード文字列など）を見つけやすくなります。
手順3：変更表を作る
変更したいタームだけを、タブ区切りのファイルにまとめます。名前にカンマが入ることがあるため、ここではCSVではなくタブ区切り（TSV）にしています。1列目にタームID、2列目に新しい名前、3列目に新しいスラッグを書きます。変えない列には半角の - を入れます。
12 WordPressの基本 wordpress-basics
15 サーバー運用 server
21 - security空欄にせず - を入れるのは、bashの read がタブの連続を一つの区切りとして扱い、空の列を詰めて読んでしまうためです（上の例で3行目を空欄にすると、security が名前として読まれます）。
IDで指定するのは、名前やスラッグは今回の作業で変わるうえ、同じ名前のタームが別の親の下に存在し得るためです。ファイルはUTF-8（BOMなし）・改行LFで保存します。Windowsのエディターで作った場合、改行がCRLFだと末尾に見えない \r が残り、スラッグが意図しない値になることがあります。
手順4：試し実行で内容を確認する
いきなり更新せず、実行されるコマンドを画面に表示するだけのスクリプトで確認します。
#!/usr/bin/env bash
# terms-update.sh 使い方: bash terms-update.sh category changes.tsv [run]
set -euo pipefail
TAX="$1"
FILE="$2"
MODE="${3:-dry}"
while IFS=$'\t' read -r id name slug || [ -n "$id" ]; do
id="${id%$'\r'}"; name="${name%$'\r'}"; slug="${slug%$'\r'}"
[ -z "$id" ] && continue
args=()
[ -n "$name" ] && [ "$name" != "-" ] && args+=(--name="$name")
[ -n "$slug" ] && [ "$slug" != "-" ] && args+=(--slug="$slug")
[ ${#args[@]} -eq 0 ] && continue
if [ "$MODE" = "run" ]; then
wp term update "$TAX" "$id" "${args[@]}" || echo "FAILED: $id" >&2
else
printf 'wp term update %s %s' "$TAX" "$id"
printf ' "%s"' "${args[@]}"
printf '\n'
fi
done < "$FILE"bash terms-update.sh category changes.tsv のように3つ目の引数を付けずに実行すると、コマンドが表示されるだけでデータは変わりません。行数が変更表と合っているか、名前やスラッグが途中で切れていないかを確認します。
wp term update で指定できる主な値は --name、--slug、--description、--parent です（2026年10月現在）。説明文や親タームもまとめて変えたい場合は、変更表に列を足し、同じ要領で引数を追加します。利用中のWP-CLIで使える引数は wp help term update で確認できます。
手順5：本実行する
試し実行の内容に問題がなければ、run を付けて実行します。
bash terms-update.sh category changes.tsv run 2> terms-errors.log成功した行には Success: Term updated. のようなメッセージが表示されます。terms-errors.log に FAILED が残った行は、多くの場合スラッグの重複が原因です。同じタクソノミー内で別のタームがすでにそのスラッグを使っていると、WordPressは更新を拒否します。該当IDを wp term get category 21 で確認し、重複相手のタームを先に変えるか、別のスラッグにします。
実行後に変更後の一覧を書き出し、変更前のファイルと比べます。
wp term list category --fields=term_id,name,slug,parent,count --format=csv > terms-category-after.csv
diff terms-category-before.csv terms-category-after.csv外部のオブジェクトキャッシュ（RedisやMemcachedなど）を使っている場合、wp_update_term() がタームのキャッシュを削除しますが、ページキャッシュ側には古いページが残ることがあります。キャッシュプラグインの機能やCDNの管理画面で、カテゴリーページや記事ページのキャッシュを削除してください。
投稿数（count）がずれている場合
count の値は名前の変更では変わりませんが、過去にSQLで直接データを操作したサイトでは、実際の投稿数と合っていないことがあります。その場合は再集計します。
wp term recount category post_tagスラッグを変えたら301リダイレクトを用意する
スラッグを変えると、カテゴリーページやタグページのURLが変わります。パーマリンク設定でURLにカテゴリーを含めている場合（/%category%/%postname%/ など）は、記事のURLも変わります。古いURLは404になるため、検索エンジンからの訪問や外部サイトからのリンクを失わないよう、変更前後のURLの対応表を作って301リダイレクトを設定します。
リダイレクトは、Redirectionなどのプラグインで管理するか、Webサーバーの設定で行います。手順2で書き出した変更前のCSVと変更後のCSVを term_id で突き合わせれば、対応表を作れます。リダイレクト設定後は、旧URLをいくつか curl -I で開き、301 と新しいURLが返ることを確認します。
あわせて、サイト内のナビゲーションメニューや本文中に旧URLが直書きされていないかも確認します。メニューに追加したカテゴリーはIDで紐づいているためスラッグ変更に追従しますが、「カスタムリンク」として入力したURLや、本文に手で書いたリンクは自動では変わりません。
よくあるつまずき
- タクソノミー名の誤り：カスタムタクソノミーを表示名で指定すると、該当なしのエラーになります。
wp taxonomy listのnameを使います。 - マルチサイト：サブサイトのタームを変えるときは
--url=https://example.com/subsite/を付けます。付けないとメインサイトが対象になります。 - 日本語の文字化け：ターミナルの文字コードがUTF-8でない場合、名前が化けて保存されることがあります。
localeで確認し、まず1件だけ更新して管理画面で表示を確かめてから全件に進みます。 - 戻したいとき：少数なら変更前のCSVから逆の変更表を作って同じスクリプトで戻せます。大きく崩れた場合は、手順1のバックアップを
wp db importで戻します（その時点以降の投稿やコメントも巻き戻る点に注意してください）。
まとめ
- タームの名前・スラッグは
wp_terms、説明文や親子関係はwp_term_taxonomyにあり、SQLの直接更新ではキャッシュやフックが動かない wp term updateはwp_update_term()を通すため、整合性・キャッシュ・重複チェックをWordPressに任せられる- 作業前に
wp db exportでバックアップし、wp term listで変更前の一覧を残す - 変更表はタームIDで指定し、試し実行で内容を確認してから本実行する
- スラッグを変えたら301リダイレクトとキャッシュ削除まで行って作業完了とする