Claude CodeにWordPressブログの運営を手伝わせる：サイト監査とカテゴリ・タグ再設計をやらせてみた

Claude Codeというと、コードを書かせたり、バグを直させたりする使い方を思い浮かべる人が多いはずだ。今回は少し違う使い方の話をしたい。
417記事を抱える本サイト（前菜の備忘録）で、「サイト全体の分析」と「カテゴリ・タグの整理」という、ブログ運営そのものの作業を任せてみた。結果として、自分では気づいていなかった技術的な問題が複数見つかり、放置していた分類の破綻も一括で解消できた。

目次

きっかけ：408記事中374記事（92%）が「プログラミング」1カテゴリに集中

本サイトは408記事あるが、そのうち374記事（92%）が「プログラミング」という1つのカテゴリに集中していた。タグも実質14種類しか使われておらず、約340記事はタグ未設定のままだった。
カテゴリ・タグが分類として機能していない状態だったが、1記事ずつ手作業で見直すには量が多すぎて手をつけられずにいた。

1. サイト全体を分析させる

最初にやったのは、WordPress REST APIを使って全記事のメタデータ（カテゴリ・タグ・文字数・公開日など）とプラグイン構成を棚卸しさせ、サイト全体監査のレポートを作らせることだった。この分析で、次のような自分では気づいていなかった問題が見つかった。

  • テーマ（Cocoon）とSEOプラグイン（AIOSEO）が、meta description・構造化データ（JSON-LD）・canonicalタグをそれぞれ独自に出力しており、同じページに同じ種類のタグが2つ存在していた。後から出力される側が採用されるリスクがあるため、意図通りのSEO設定が実際には反映されていない可能性があった。
  • サイトマップ（/sitemap.xml）を実際に生成していたのは、有効化していたAIOSEOではなく、開発が止まり気味の古いプラグインだった。robots.txtも古いプラグインのURLを参照していた。

どちらも管理画面をひと目見ただけでは気づきにくい類の問題で、「設定した覚えのある機能が、実は別の場所で上書きされている」というパターンだった。
全体を横断的に突き合わせる作業は、人手で1画面ずつ確認するより機械的に洗い出させる方が早く、見落としも少なかった。

2. カテゴリ・タグの再設計を任せる

次に、カテゴリ・タグの再設計に着手した。進め方は次の順序にした。

  • 全408記事のタイトルをキーワードマッチさせ、新しいカテゴリ案（JavaScript/Node.js/TypeScript、フロントエンド（Vue/Nuxt）、AI開発、Docker、Git/GitHubなど14件）への機械的な振り分け案を作らせる
  • 振り分けのルール（優先順位・判断基準）と件数の内訳を、実行前にレポートとしてまとめさせる
  • そのレポートを確認し、分類の考え方に問題がないかレビューしてから、初めてWordPressへの反映を承認する
  • タイトルだけでは判断できなかった記事（29件）は自動分類の対象から外し、本文を個別に確認させたうえで分類を確定する

承認後は、408記事のうち397記事（日本語記事のみ、英語記事11件は別途検討として対象外）に対して、新規カテゴリ14件の作成、タグ17件の新規付与、使われていない重複タグの削除を、WordPress REST API経由で一括反映させた。

参考までに、カテゴリ・タグの反映自体はこの程度のシンプルなAPI呼び出しの繰り返しになる。

import requests

resp = requests.post(
    f"{SITE_URL}/wp-json/wp/v2/posts/{post_id}",
    auth=(WP_USER, WP_APP_PASSWORD),
    json={"categories": [new_category_id], "tags": [tag_id_1, tag_id_2]},
)

処理自体は単純だが、408記事に何を割り当てるかという「判断」の部分をレポートとして可視化し、レビューを挟んでから実行する、という手順を踏んだことが、今回の作業で事故を防げた一番の要因だったと感じている。

3. 「全部自動」にしないためにやった3つのこと

一括処理を安全に進めるために、意識していたことが3つある。

  • 提案と実行を分離する：分類案を作るスクリプトと、実際にWordPressへ書き込むスクリプトを別々にし、間に必ずレビュー（レポートの確認、チャット上での承認）を挟んだ。1つのスクリプトで「考える」と「書き込む」を同時にやらせない。
  • 機械的に判断できない例外は無理に自動化しない：タイトルのキーワードマッチだけでは分類が決まらない記事は、無理にルールを拡張して当てはめようとせず、個別確認が必要な例外として切り分けた。
  • 記録を分けて残す：分析・提案の内容は読み物としてレポートに、実際に反映した変更は変更履歴に、記事単位の細かい対応は別の一覧に、というように書く場所を分けた。あとから「何を根拠にこの分類にしたか」を追えるようにするためだ。

まとめ

Claude Codeは記事本文を書かせる以外にも、ブログ運営そのものの作業でも役に立つ。今回の実例で有効だったのは次の3点だ。

  • 全記事・全設定を横断的に棚卸しさせることで、管理画面をひと目見ただけでは気づけない重複・矛盾を発見できる
  • 大量の記事に対する分類・整理は、判断ルールをレポートとして可視化し、レビューを挟んでから一括反映することで、量の多さに対して安全に対応できる
  • 「提案」と「実行」を別のスクリプトに分け、機械的に判断できない例外は人の確認に回す、という役割分担が事故を防ぐ
タイトルとURLをコピーしました