ブログタクソノミー

ブログタクソノミー は何をしますか？

CMSプラットフォーム上で、タグ、カテゴリ、トピッククラスターを管理します。

コマンド

コマンド	目的
/blog taxonomy suggest <ファイル>	コンテンツからタグとカテゴリの候補を抽出
/blog taxonomy sync <cms>	認証済みAPIを介してタクソノミーをCMSにプッシュ
/blog taxonomy audit [ディレクトリ]	薄いタグ、孤立タグ、タクソノミーの肥大化をチェック

タグ提案ワークフロー

ステップ1: コンテンツ構造の解析

対象ファイルを読み込み、以下を抽出:

• すべてのH2およびH3見出し（主要トピックシグナル）
• 太字および斜体のフレーズ（強調シグナル）
• 既存のフロントマター内のタグ/カテゴリ（存在する場合）

ステップ2: 頻度分析

本文テキストをスキャンし、高頻度フレーズを特定:

• 1単語の用語: 最低4回出現（ストップワードを除く）
• 2単語フレーズ: 最低3回出現
• 3単語フレーズ: 最低2回出現

一般的な非タグワード（冠詞、前置詞、接続詞、代名詞）は除外。

ステップ3: 意味グループ化

関連する候補をクラスタにグループ化:

• 単数形/複数形のバリアントをマージ（より一般的な形式を維持）
• ハイフンあり/なしの形式をマージ
• 同義語を最も頻度の高い用語の下にグループ化

ステップ4: 重複排除とランク付け

• スラッグ化された名前でファジーマッチング（レーベンシュタイン距離 <= 2）
• 各候補をスコアリング: (頻度 * 2) + (見出しの存在 * 5) + (強調 * 1)
• 上位5〜10の候補をランク付けして返却

出力形式

## タグ提案: [投稿タイトル]

| 順位 | タグ | スコア | ソース |
|------|-----|-------|--------|
| 1 | content-marketing | 18 | H2 + 6回言及 |
| 2 | seo-strategy | 14 | H3 + 4回言及 |
| 3 | keyword-research | 11 | 5回言及 + 太字 |

### 推奨カテゴリ
- プライマリ: [最適なカテゴリ]
- セカンダリ: [オプションの第2カテゴリ]

CMSアダプタ

アダプタ概要

CMS	APIタイプ	認証方法	タグモデル
WordPress	REST	アプリケーションパスワード（base64）	ファーストクラスエンティティ（IDあり）
Shopify	GraphQL (Admin API)	Admin APIアクセストークン	Articleの文字列配列
Ghost	REST (Admin API)	APIキー + JWT署名	ファーストクラスエンティティ
Strapi	REST または GraphQL	APIトークン（Bearer）	ユーザー定義コンテンツタイプ
Sanity	GROQ / ミューテーション	プロジェクトトークン（Bearer）	ドキュメントタイプ

WordPressアダプタ

タグ一覧:

GET {CMS_URL}/wp-json/wp/v2/tags?per_page=100&search={キーワード}
Authorization: Basic {base64(ユーザー名:アプリパスワード)}

タグ作成:

POST {CMS_URL}/wp-json/wp/v2/tags
Body: {"name": "タグ名", "slug": "タグ名", "description": "オプション"}

カテゴリ一覧（階層構造、parentフィールド対応）:

GET {CMS_URL}/wp-json/wp/v2/categories?per_page=100

カテゴリ作成:

POST {CMS_URL}/wp-json/wp/v2/categories
Body: {"name": "カテゴリ名", "slug": "カテゴリ名", "parent": 0}

投稿へのタグ割り当て:

POST {CMS_URL}/wp-json/wp/v2/posts/{id}
Body: {"tags": [1, 2, 3], "categories": [4]}

ページネーション: 完全なリストを取得するには X-WP-TotalPages ヘッダーに従ってください。

Shopifyアダプタ

Shopifyのタグは、Articleオブジェクト上の文字列配列であり、ファーストクラスエンティティではありません。

記事タグの更新 (GraphQL Admin API):

mutation {
  articleUpdate(id: "gid://shopify/Article/123", article: {
    tags: ["tag-one", "tag-two", "tag-three"]
  }) {
    article { id tags }
    userErrors { field message }
  }
}

使用中の全タグ一覧 (GraphQL):

{
  articles(first: 250) {
    edges {
      node { id title tags }
    }
  }
}

認証ヘッダー: X-Shopify-Access-Token: {トークン}

注: REST APIは2024年10月をもってレガシーとされています。2025年4月以降の新規アプリではGraphQLが必須です。

Ghostアダプタ

タグ一覧:

GET {CMS_URL}/ghost/api/admin/tags/?limit=all
Authorization: Ghost {jwt_token}

タグ作成:

POST {CMS_URL}/ghost/api/admin/tags/
Body: {"tags": [{"name": "タグ名", "slug": "タグ名"}]}

JWT生成: 管理APIキー（id:secret形式）で署名、iat = 現在時刻、exp = 5分、audience = /admin/。

Strapiアダプタ

エンドポイントはコンテンツタイプから自動生成されます。典型的な設定:

GET {CMS_URL}/api/tags?pagination[pageSize]=100
POST {CMS_URL}/api/tags
Body: {"data": {"name": "タグ名", "slug": "タグ名"}}
Authorization: Bearer {api_token}

Strapi v4以降では data ラッパーを使用します。フィールド名はコンテンツタイプスキーマを確認してください。

Sanityアダプタ

タグクエリ (GROQ):

*[_type == "tag"] { _id, name, slug }

タグ作成 (ミューテーションAPI):

POST https://{project_id}.api.sanity.io/v2024-01-01/data/mutate/{dataset}
Body: {"mutations": [{"create": {"_type": "tag", "name": "タグ", "slug": {"current": "タグ"}}}]}
Authorization: Bearer {token}

タクソノミー監査ワークフロー

ステップ1: 棚卸し

対象ディレクトリ内のすべての投稿をスキャン（またはCMSから取得）。以下のマップを作成:

• タグ名 -> [そのタグを使用している投稿ファイル/IDのリスト]
• カテゴリ名 -> [投稿ファイル/IDのリスト]

ステップ2: 健全性チェック

チェック	しきい値	アクション
薄いタグアーカイブ	タグあたり投稿数5未満	noindexまたは統合を推奨
孤立タグ	投稿数0	削除を推奨
タグの肥大化	タグ総数50超	統合を推奨
カテゴリの深さ	3レベル超	フラット化を推奨
カテゴリ未設定の投稿	カテゴリなし	適切なカテゴリに割り当て
重複スラッグ	同名スラッグ、異なる名前	正規版に統合

ステップ3: 推奨事項

優先度別に結果をグループ化:

• 致命的: 空のアーカイブページを生成する孤立タグ（クロールの無駄）
• 高: 投稿数3未満の薄いタグ（ユーザー体験の低下、SEOシグナル弱体）
• 中: 50超のタグ肥大化（タクソノミーの希薄化、ナビゲーション困難）
• 低: 命名の不整合（大文字小文字混在、ハイフンとスペースの混在）

出力形式

## タクソノミー監査: [サイト/ディレクトリ]

**タグ総数**: [n] | **カテゴリ総数**: [n]
**健全**: [n] | **薄い**: [n] | **孤立**: [n]

### 致命的な問題
- [孤立タグ一覧]

### 推奨事項
1. [タグa] と [タグb] を統合（同じトピック、統合後 [n] 投稿）
2. 孤立タグを削除: [一覧]
3. 投稿数5未満のタグアーカイブにnoindexを追加

サイト全体のガイドライン

• サイトのメインカテゴリは5〜10を目指す（幅広いトピック）
• タグはアーカイブページを作成する前に最低5つの投稿があること
• スラッグ形式は一貫して小文字、ハイフン区切りを使用
• すべての投稿には正確に1つのプライマリカテゴリを設定
• 投稿あたりのタグ数: 3〜8推奨、最大15を超えないこと

環境変数

変数	目的	例
CMS_TYPE	プラットフォーム識別子	wordpress, shopify, ghost, strapi, sanity
CMS_URL	CMSのベースURL	https://example.com
CMS_API_KEY	認証資格情報	アプリケーションパスワード、APIトークン、またはキー

これらはシェル環境に設定する必要があります。ファイルに資格情報を保存したり、バージョン管理にコミットしたりしないでください。スキルは実行時に $CMS_TYPE、$CMS_URL、$CMS_API_KEY を介して読み取ります。

エラーハンドリング

• 環境変数の欠落: CMS_TYPE、CMS_URL、またはCMS_API_KEYが設定されていない場合、どの変数が欠けているかと期待される形式を報告
• 無効な資格情報: CMS APIが401/403を返した場合、「認証に失敗しました - CMS_API_KEYを確認してください」と報告し、再試行しない
• 接続タイムアウト: 10秒後にCMSエンドポイントに到達できない場合、タイムアウトを報告し、CMS_URLの確認を提案
• 重複タグスラッグ: タグがCMSに既に存在する場合、作成をスキップし「タグは既に存在します: [名前]」と記録
• レート制限: CMS APIが429を返した場合、待機してから1回再試行。制限が続く場合は報告
• サポート外のCMS: CMS_TYPEが5つのサポート対象プラットフォームのいずれでもない場合、有効なオプションをリストして終了