WP-CLIでカテゴリ・タグ・アイキャッチを安全に設定する方法

WordPressへ記事を下書き登録したら、次にカテゴリ、タグ、アイキャッチを設定します。管理画面なら数回のクリックですが、WP-CLIでは「どの投稿へ」「既存設定を残すのか置き換えるのか」を明確にしないと、別の記事を変更したり、必要な分類を外したりするおそれがあります。

この記事では、すでに作成済みの下書き1件に対して、既存のカテゴリとタグを確認し、人が承認した分類と画像だけを設定して、結果を読み直すところまで扱います。コマンド例は架空環境用です。

先に知っておきたい役割

カテゴリ

記事を大きなテーマで分類し、サイト内をたどりやすくします。階層を持てるため、「宿主さん向け」の中へ「AIサイト管理」を置くような構成も可能です。

一つの記事へ多くのカテゴリを付けるより、読者がどの入口から探す記事なのかを決めます。サイトごとの運用ルールを優先してください。

アイキャッチ

記事一覧、SNS共有、関連記事などで代表画像として使われます。本文へ画像を挿入することとは別です。画像をメディアライブラリへ登録しただけでも、記事のアイキャッチにはなりません。

代替テキスト

画像を見られない利用者へ内容を伝える文章です。画像の目的を簡潔に説明し、記事タイトルや検索語を不自然に詰め込みません。装飾だけの画像とは扱いが異なりますが、記事内容を説明するアイキャッチなら、何が描かれているかを伝えます。

この作業で変わるもの

対象投稿とカテゴリ・タグの関係
メディアライブラリ内の添付ファイル
画像の代替テキストなどのメタ情報
対象投稿のアイキャッチ画像ID
テーマによっては記事一覧やプレビュー表示

下書きのままでもデータベースとメディア領域は変わります。画像を間違えて取り込むと、投稿から外してもメディアライブラリには残ります。実行前に対象ID、画像ファイル、既存設定を固定します。

全体の流れ

対象の下書きIDを確認
  ↓
現在のカテゴリ・タグ・アイキャッチを読む
  ↓
既存の分類候補から人が選ぶ
  ↓
画像の権利・内容・サイズ・altを確認
  ↓
対象の1件だけに設定
  ↓
分類・添付ID・アイキャッチID・altを読み直す
  ↓
管理画面でプレビューして停止

1. 対象投稿をIDで確認する

前の記事で返された投稿IDを使います。タイトル検索だけで変更対象を決めません。

wp post get 123 \
  --fields=ID,post_title,post_name,post_status,post_type \
  --format=json

次が一致しなければ停止します。

投稿IDが予定どおり
post_typeがpost
post_statusがdraft
タイトルとslugが対象原稿と一致する

公開済み記事だった場合、この記事の手順では変更しません。公開済み記事の分類変更は、一覧や検索エンジンからの導線にも影響するため、別の承認が必要です。

2. 現在の分類とアイキャッチを読む

変更前の状態を記録します。

wp post term list 123 category \
  --fields=term_id,name,slug,parent \
  --format=json

wp post term list 123 post_tag \
  --fields=term_id,name,slug \
  --format=json

wp post meta get 123 _thumbnail_id

アイキャッチが未設定の場合、_thumbnail_idの取得は値なしまたはエラーになることがあります。ラッパー側では「未設定」を正常な確認結果として扱い、そこで処理全体を誤って中断しない設計が必要です。

出力は実行記録へ残します。後で意図しない置き換えが分かったとき、元のカテゴリ・タグ・画像IDを確認できます。

3. 既存のカテゴリとタグを探す

まずサイトに存在する候補を一覧します。件数と出力項目を限定します。

wp term list category \
  --fields=term_id,name,slug,parent,count \
  --orderby=name \
  --order=asc \
  --format=table

wp term list post_tag \
  --fields=term_id,name,slug,count \
  --orderby=name \
  --order=asc \
  --format=table

AIに名前だけから選ばせず、記事計画と既存カテゴリ構造を人が確認します。カテゴリは同じ名前の子カテゴリが別の親の下に存在する可能性があるため、parentとterm_idも確認します。

新しい分類はこの工程で自動作成しない

候補がないときに、AIが似たタグやカテゴリを自動作成すると分類が増殖します。新設する場合は次を別途検討します。

同じ意味の分類がすでにないか
今後も複数記事で使うか
slugと表示名をどうするか
親カテゴリをどこにするか
カテゴリ一覧を検索対象にするか

この記事では、承認済みの既存分類だけを使います。

4. setは既存の分類を置き換える

WP-CLI公式のwp post term setは、対象投稿に付いているその分類の値を置き換えます。「一つ追加する」という意味ではありません。

たとえば現在のカテゴリを確認せず、次を実行すると、以前付いていたカテゴリが外れる可能性があります。

wp post term set 123 category ai-site-management --by=slug

親カテゴリも記事へ明示的に付けるサイトなら、承認済みの全カテゴリを一度に指定します。

wp post term set 123 category 40 41 --by=id

ここで40と41は架空のterm IDです。実際のIDを事前確認し、順番や件数も含めて承認します。階層カテゴリでは同名の混同を避けるため、IDを使う方が判断しやすいでしょう。

タグもsetなら既存タグを置き換えます。

wp post term set 123 post_tag wp-cli wordpress-operation --by=slug

「既存タグを残して一つだけ追加する」必要がある場合、wp post term addという別の操作があります。ただし、AI用ラッパーでは挙動を増やしすぎず、「変更前の一覧を確認し、承認済みの最終状態に置き換える」と統一すると検証しやすくなります。

5. 画像をサーバーへ送る前に確認する

画像ファイルについて、次を人が確認します。

自分で撮影・制作した画像、または使用条件を満たす画像である
宿泊者の顔、車のナンバー、予約情報などが写っていない
猫や施設について誤解を招く合成・演出ではない
記事の内容を代表している
ファイル形式と容量がサイトの運用ルール内である
ファイル名が内容を表し、秘密情報や個人名を含まない
代替テキストが画像の内容と目的を説明している

画像生成AIを使った場合は、実在施設の写真と誤認させないことも大切です。施設紹介記事なら、許可を得た実際の写真を優先する判断も必要です。

6. アイキャッチを1枚だけ取り込む

WP-CLIのwp media importは、画像をメディアライブラリへ取り込み、--post_idで投稿へ関連付けられます。--featured_imageを指定すると、その投稿のアイキャッチとしても設定します。

wp media import approved-featured-image.webp \
  --post_id=123 \
  --title="記事を説明する画像タイトル" \
  --alt="宿主が記事の分類と画像を確認するイラスト" \
  --featured_image \
  --porcelain

--porcelainで返る添付ファイルIDを記録します。

ローカルの任意ファイルやURLをAIが自由に指定できるようにしません。専用ラッパーでは、次のように制限します。

許可された画像フォルダ内の1ファイルだけ
許可する拡張子と最大容量を限定
..を含むパスや外部URLを拒否
対象は承認済みの下書きIDだけ
--post_id、--featured_image、--porcelainを処理側で固定
altが空なら実行しない
一度に複数ファイルを受け付けない

外部URLから直接取り込むと、出所や内容が後から変わっている可能性があります。いったん手元の許可フォルダへ置き、内容と権利を確認してから使います。

7. 設定結果を読み直す

コマンドの終了コードだけで成功と判断せず、対象投稿から確認します。

wp post term list 123 category \
  --fields=term_id,name,slug,parent \
  --format=json

wp post term list 123 post_tag \
  --fields=term_id,name,slug \
  --format=json

wp post meta get 123 _thumbnail_id

返されたアイキャッチIDが、画像取り込み時に記録した添付ファイルIDと一致するか確認します。次に添付ファイル自体も読みます。

wp post get 456 \
  --fields=ID,post_title,post_mime_type,post_parent,guid \
  --format=json

wp post meta get 456 _wp_attachment_image_alt

ここで456は架空の添付ファイルIDです。確認するのは次の項目です。

対象投稿IDが変わっていない
カテゴリが承認済みの最終一覧と一致する
タグが承認済みの最終一覧と一致する
以前必要だった分類が意図せず消えていない
アイキャッチIDと添付ファイルIDが一致する
MIMEタイプが想定した画像形式である
代替テキストが空でなく、内容と一致する
下書き状態のままである

8. 管理画面でプレビューする

最後に人が管理画面で下書きを開きます。

一覧と記事上部でアイキャッチが意図どおり切り抜かれる
スマートフォンで画像が大きすぎたりぼやけたりしない
画像内の文字が読みにくくない
カテゴリ・タグの表示位置とリンク先が正しい
既存のカテゴリ一覧へ意図どおり掲載される
投稿者とdescriptionが変わっていない
記事はまだ公開されていない

テーマによって、アイキャッチを本文上部にも自動表示します。本文内に同じ画像を置くと二重表示になる場合があるため確認してください。

失敗したときに連続操作しない

画像取り込みがタイムアウトしても、実際にはメディアライブラリへ登録されている場合があります。すぐ同じコマンドを再実行すると、同じ画像が複数できます。

失敗時は次の順に調べます。

対象投稿の_thumbnail_idを確認する
直前に返った添付ファイルIDを確認する
メディア一覧でファイル名と登録時刻を確認する
分類の現在値を読み直す
現状を人へ報告して停止する

重複メディアの削除は、この工程に含めません。削除対象と利用箇所を確認した別の作業にします。

AIへの依頼文

下書き投稿ID 123へ、カテゴリ、タグ、アイキャッチを設定してください。

実行前:
- 投稿ID、タイトル、slug、post_type、post_statusを確認する
- 現在のカテゴリ、タグ、_thumbnail_idを記録する
- 既存カテゴリとタグから候補を示す
- 新しいカテゴリやタグは作らない
- 画像のファイル名、形式、容量、alt、使用条件を確認する
- 変更前と変更予定を示し、人の承認まで停止する

実行時:
- 承認済みの下書き1件だけを対象にする
- カテゴリとタグは承認済みの最終一覧へ設定する
- 許可されたフォルダの画像1枚だけを取り込む
- --featured_imageを使い、添付ファイルIDを記録する
- 公開しない。他の記事や既存メディアを変更・削除しない

実行後:
- カテゴリ、タグ、_thumbnail_id、添付ファイル、altを読み直す
- post_statusがdraftのままであることを確認する
- プレビューで人が確認する項目を報告して停止する

完了報告の例

下書き設定結果
- 対象：投稿ID 123、example-article
- 状態：draftを維持
- カテゴリ：変更前と変更後を確認済み
- タグ：変更前と変更後を確認済み
- アイキャッチ：添付ファイルID 456
- alt：設定・読み直し済み
- 新規分類：作成していない
- 変更していないもの：他の記事、既存メディア、公開状態
- 次の操作：管理画面で人がプレビュー