blog-cluster

Blog Cluster（セマンティックトピッククラスタエンジン）

以下のバンドルされたパスでは、ホスト側の Markdown 置換で ${CLAUDE_SKILL_DIR} を使用します。 これはエクスポートされたシェル変数ではありません。実行前にパスを解決して引用符で囲み、絶対パスでないオーバーライドは拒否してください。${CLAUDE_SKILL_DIR}/../blog/references から解決した blog_reference_root、${CLAUDE_SKILL_DIR}/../blog/templates から解決した blog_template_root、および必要な兄弟ルートをエージェントに渡してください。 プロジェクトのコンテキストを読み込む前に、メインリファレンスの orchestration-details.md を読み込んでください。下流のエージェントには、ヘルパーで囲まれた出力のみを渡してください。

1つのシードキーワードから、相互にリンクしたコンテンツエコシステム全体を計画して実行します。3つのレイヤーで構成されます。セマンティッククラスタリング（頭脳）、クラスタアーキテクチャ（構造）、実行エンジン（機械）です。

Lutfiya Miller による semantic-cluster-engine の投稿をもとにしています （AI Marketing Hub Pro Challenge 優勝者、2026年3月、95/100 Exemplary）。 元のリポジトリ：2026-10-12 時点で利用不可 この移植版では、Plan + Execute アーキテクチャとクラスタコンテキストの革新的な仕組みを維持し、 ブランド固有（ScienceExperts.ai）のスタイルと画像プロンプトを取り除き、claude-blog の既存サブスキルを経由します。

コマンド

コマンド	機能
/blog cluster	対話形式で、計画するか実行するかを尋ねます。
/blog cluster plan <seed-keyword>	SERP ベースのセマンティック分析を行います。クラスタ計画とマップを出力します。
/blog cluster plan --from strategy [path]	既存の blog-strategy クラスタ構築計画をインポートし、SERP データに照らして検証します。
/blog cluster execute [path-to-plan]	クラスタコンテキストを付与した blog-write の呼び出しを順次実行し、自動で相互リンクします。

主なリファレンス（必要に応じて読み込み）

• ${CLAUDE_SKILL_DIR}/references/semantic-clustering.md（SERP の重複分析、検索意図の分類、キーワード群の拡張）
• ${CLAUDE_SKILL_DIR}/references/cluster-architecture.md（ハブ・アンド・スポークの仕様、スキーマ戦略、リンク密度のルール）
• ${CLAUDE_SKILL_DIR}/references/execution-workflow.md（実行順序、コンテキストの注入、スコアカード、障害対応）

既存の claude-blog スキルとの相互参照

スキル	このスキルが呼び出すタイミング
/blog strategy	上流の計画時です。plan --from strategy は、同スキルの Cluster Build Plan テーブルを使用します。
/blog write	記事ごとの実行時です。各スポークとピラーは、クラスタコンテキストブロックを先頭に追加した blog-write によって作成されます。
/blog chart	インライン SVG チャートを作成するため、blog-write が内部的に呼び出します。このスキルから直接呼び出すことはありません。
/blog image	このスキルからは呼び出しません。各記事のヒーロー画像は、blog-write の納品契約によって（generate_hero.py 経由で）一度だけ作成されます。ステップ 4 を参照してください。
/blog seo-check	実行後に、記事ごとのオンページ検証を行うことを推奨します。
/blog cannibalization	実行後に、クラスタ内でキーワードの重複がないことを確認するために推奨します。
/blog schema	実行後に、BreadcrumbList、ItemList、Article スキーマを追加することを推奨します。

このスキルは、他のスキルに属するファイルを変更しません。Task ツールまたはオーケストレーションされたサブスキルを介して呼び出します。

コマンドのルーティング

1. ユーザーのコマンドを解析して、サブコマンドを判定します。
2. ユーザーが /blog cluster のみを入力した場合は、次のように尋ねます。「新しいクラスタを計画しますか、それとも既存の計画を実行しますか？」
3. 次のようにルーティングします。
   • plan <keyword> は Plan Phase（以下）へ
   • plan --from strategy [path] は Strategy Import フロー（以下）へ
   • execute [path]、build、または run は Execute Phase（以下）へ

---

Plan Phase：/blog cluster plan <seed-keyword>

リファレンス：${CLAUDE_SKILL_DIR}/references/semantic-clustering.md

ステップ 1. シードキーワードの拡張

WebSearch を使って、シードキーワードを30〜50個のフレーズからなるキーワード群へと拡張します。

1. <seed>を直接検索し、関連検索と「他の人はこちらも質問」を収集します。
2. ロングテールキーワードの拡張：<seed> guide、<seed> tips、<seed> tools、<seed> examples、<seed> vs、best <seed>、how to <seed>。
3. 質問の抽出：what is <seed>、how does <seed> work、why <seed>、<seed> for beginners。
4. 検索意図のバリエーション：商用の修飾語（best、top、review、comparison、pricing）、情報収集の修飾語（guide、tutorial、explained、examples）、取引の修飾語（buy、download、tool、software、service）を追加します。
5. 年の新しさ：<seed> <current year>。年はシステムの日付から取得し、固定の年を決して使わないでください。

ステップ 2. セマンティッククラスタリング

${CLAUDE_SKILL_DIR}/references/semantic-clustering.mdの優先順位ルールを参照して、拡張したキーワードをグループ化します。

1. SERP の重複分析を主要なシグナルとして扱います。上位10件の検索結果のうち4件以上が共通するキーワードは、通常、同じ検索意図を対象としているため、1つの記事にまとめることを検討します。
2. 検索意図の分類では、各キーワードを情報収集、商用、取引、ナビゲーションのいずれかに分類します。
3. エンティティのマッピングでは、Google がトピックに関連付けている人物、製品、フレームワーク、組織を特定します。
4. グループ化では、検索意図とトピック上の近さが共通するキーワードをまとめます。各グループがハブ＆スポーク構成の1つのブランチになります。

ステップ 3. クラスター構成の設計

参照先：${CLAUDE_SKILL_DIR}/references/cluster-architecture.md

ハブ＆スポークを構成します。

• ピラー（ハブ）：最も広範なキーワードを対象にします。文字数は2,500〜4,000語です。テンプレートはpillar-pageです。すべてのスポークへリンクします。
• スポーク：それぞれがロングテールのクラスターを対象にします。文字数は1,200〜1,800語です。テンプレートは検索意図に応じて自動選択されます。ピラーへのリンクと、同階層のスポーク間のリンクを設けます。

クラスターの形成ルール：

• 通常モード：ピラーごとに2〜5個のクラスター、クラスターごとに2〜4個のスポーク、合計でピラー1つとスポーク5〜15個。
• 小規模クラスター・モード：対象範囲が狭いシードの場合は、ユーザーに警告し、確認を求めた後に限り、ピラー1つとスポーク2〜4個を許可します。
• 各スポークは、重複のない固有の主要キーワードを対象にします。

ステップ 4. 内部リンクマトリックス

各スポークSについて：

• Sからピラーへリンクします（必須。アンカーテキストにはピラーの主要キーワードを使用します）。
• ピラーからSへリンクします（必須。アンカーテキストにはSの主要キーワードを使用します）。
• Sから同じクラスター内の他のスポークへリンクします（それぞれ2〜3件。文脈に合ったアンカーテキストを使用します）。
• Sから隣接するクラスターのスポークへリンクします（0〜1件。意味的に関連する場合に限ります）。

各スポークに少なくとも2件のインバウンドリンクがあることを確認します。計画した内部リンクの総数を数えます。

ステップ 5. 出力ファイルの生成

計画と実行に関する成果物はすべて、現在の作業ディレクトリ内の1つのサブディレクトリに保存します。出力ディレクトリを正規化し、シンボリックリンクを拒否して、クラスターのディレクトリ外への書き込みを拒否します。スラッグは小文字、数字、ハイフンのみで構成される必要があります。絶対パス、..、スラッグ内のパス区切り文字、非表示の制御文字は拒否します。

<cwd>/
└── cluster-<seed-keyword-slug>/
    ├── cluster-plan.json
    ├── cluster-map.html
    ├── pillar-<slug>.md       (Execute Phase)
    ├── <spoke-slug>.md        (Execute Phase, one per spoke)
    └── cluster-scorecard.md   (Execute Phase)

cluster-plan.jsonのスキーマ

{
  "seed_keyword": "<seed>",
  "generated_at": "YYYY-MM-DDTHH:MM:SSZ",
  "pillar": {
    "id": "P",
    "title": "Title of the pillar",
    "primary_keyword": "broadest keyword",
    "secondary_keywords": ["..."],
    "search_volume_estimate": "high|medium|low",
    "template": "pillar-page",
    "word_count_target": 3000,
    "cluster": "pillar"
  },
  "clusters": [
    {
      "name": "Cluster A: Theme",
      "intent": "informational|commercial|transactional",
      "color": "#2563eb",
      "posts": [
        {
          "id": "A1",
          "title": "Post title",
          "primary_keyword": "long-tail keyword",
          "secondary_keywords": ["..."],
          "search_volume_estimate": "high|medium|low",
          "template": "how-to-guide",
          "word_count_target": 1500,
          "links_to": ["P", "A2"],
          "links_from": ["P", "A2"]
        }
      ]
    }
  ],
  "total_posts": 9,
  "total_interlinks": 23,
  "estimated_total_words": 18000
}

注：検索ボリュームの推定値は、正確な検索ボリュームではなく、SERP のシグナルから導き出した相対的な指標（高、中、低）です。正確なデータを確認するには、Ahrefs、SEMrush、またはDataForSEOを参照してください（claude-blogには、関連するコンパニオンプロジェクトのseo-dataforseoがあります）。

cluster-map.html（XSS 対策済み）

SVG ビジュアライゼーションを埋め込んだ、静的で自己完結型の HTML ファイルです。作成時の厳守事項：

• インラインの <script> ブロックは禁止です。ドキュメント内のどこにも、onclick、onmouseover、または on* イベント属性を含めないでください。
• 外部スクリプトの <src> 参照は禁止です。
• SVG に描画するすべてのテキストラベル（タイトル、キーワード、クラスター名）はエスケープする必要があります。挿入前に & を & に、< を < に、> を > に、" を " に、' を ' に置き換えてください。
• ホバー効果には CSS の :hover のみを使用してください。JavaScript は使用しないでください。
• アクセシブルなツールチップには、SVG ノード内に <title> 子要素を使用してください（ブラウザー標準機能であり、スクリプトは不要です）。

マップには、中央の柱となるノード、外側に放射状に広がる色分けされたクラスターグループ、各クラスター内のスポークノード、関連ノードをつなぐリンク線が表示されます。

ステップ 6. 計画をユーザーに提示する

クラスターと投稿の概要、内部リンクの合計数、推定ワード数、ファイルパスをまとめた表を表示します。実行に進む前に、ユーザーに確認を求めてください。明示的な承認を待ちます。自動実行しないでください。

---

戦略のインポート：/blog cluster plan --from strategy [path]

blog-strategy の出力をクラスター計画に変換します。

1. 戦略の出力を探します。現在のディレクトリ（またはユーザーが指定したパス）をスキャンし、Cluster Build Plan テーブルと、# | Spoke Topic | Template | Target Keyword | Word Count | Internal Links の列を含むファイル（/blog strategy が生成する形式）を探します。
2. テーブルを解析します。ピラー行（P のマーク付き）、スポーク行、テンプレートの割り当て、ターゲットキーワード、ワード数、リンク関係を抽出します。
3. 検証して情報を補完します。各キーワードに対して SERP 重複検証（計画フェーズのステップ 2）を実行します。検索ボリュームの推定値を追加し、クラスターのグループ分けが意味的に妥当か確認します。
4. SERP データが戦略テーブルと矛盾する場合は、競合を明示してください。ユーザーの戦略的意図を黙って上書きしてはいけません。
5. 標準の計画フェーズと同じ出力を使用して、cluster-plan.json と cluster-map.html を生成します。
6. SERP に基づく調整箇所を強調表示したうえで、変換後の計画を提示し、ユーザーの確認を待ちます。

---

実行フェーズ：/blog cluster execute [path-to-plan]

参照：${CLAUDE_SKILL_DIR}/references/execution-workflow.md

ステップ 1. 計画を読み込む

ユーザーが指定したパス、または作業ディレクトリ内で最新の cluster-*/cluster-plan.json から cluster-plan.json を読み込みます。JSON 構造を検証します。計画が見つからない場合は、次を返します：「クラスター計画が見つかりません。まず /blog cluster plan <seed-keyword> を実行してください。」

ユーザーが指定した計画パスを読み込む前に、現在の作業ディレクトリを基準に正規化します。絶対パス、..、シンボリックリンク、ファイル名が cluster-plan.json 以外のパス、選択したクラスターのディレクトリ外にあるパスは拒否してください。生成する投稿、画像、マップ、スコアカードの出力先はすべて、そのクラスターのディレクトリ内に制限してください。

ステップ 2. 実行順序を決定する

1. まずピラーページを作成します（スポークから既知のファイル名にリンクできるようにするためです）。
2. 次にスポークを作成し、(cluster priority, search_volume_estimate desc, post id alphabetical) の順に並べます。クラスターの優先度は、クラスター内の推定検索ボリュームの合計です（高い順）。
3. クラスターが 2 つを超える場合は、クラスターを交互に処理し、初期コンテンツの広がりを多様化します。

ステップ 3. 各投稿について：クラスターコンテキストを作成し、blog-write を呼び出す

一度限りの費用に関する確認（最初の投稿の前）。 実行は一括で行われ、有料です。一度だけ確認し、明確な「はい」を待ちます：「このプランには N 件の投稿があります。各投稿では、blog-write の完全な処理を 1 回、blog-reviewer の処理を 1 回（ゲートでブロックされた場合は追加で実行し、最大 3 回まで）、ヒーロー画像を 1 枚作成します。Gemini のヒーロー画像を使う場合、投稿ごとに有料画像生成を 1 回行います（現在の画像 1 枚あたりの料金で約 N 倍です：https://ai.google.dev/gemini-api/docs/pricing）。Gemini のヒーロー画像で進めるか、無料のストック画像のみを使うか、停止しますか？」回答をクラスターコンテキストに HERO: gemini または HERO: stock-only として記録します。stock-only の場合は、Gemini キーを設定せずに generate_hero.py を実行します（env -u GOOGLE_AI_API_KEY）。「はい」はヒーロー画像 N 枚分に限られます。ループで再生成してはいけません。フォールバックまたはスキップ（ストック画像のヒーロー画像、投稿のスキップ）は、それぞれ最終レポートの「フォールバックとスキップ」に 1 行で報告します。

クラスターコンテキストブロック（完全なスキーマは ${CLAUDE_SKILL_DIR}/references/execution-workflow.md）を作成し、blog-write を呼び出す Task ツールに渡すトピックプロンプトの先頭に追加します。このコンテキストでは、クラスター名、投稿の役割（ピラーまたはスポーク）、主要キーワードと副次キーワード、選択したテンプレート、目標文字数、執筆済み投稿の一覧（リンクを付ける）、今後の投稿の一覧（[INTERNAL-LINK] プレースホルダーを使う）、およびこの投稿のリンク要件を blog-write に伝えます。

エビデンスの出典情報の引き継ぎ。 クラスターコンテキストには、すべてのスポークとピラーについて、次の指示を含めます：「重要な主張は、それを裏付ける情報源まで追跡できるようにしてください。情報源の特定や解釈に役立つ場合は、日付、発行元／タイトルの詳細、取得時の注記、方法論、制約を記録してください。発行元の引用スタイルを使用してください。検証できない統計は削除し、反証された統計は差し替えてください。」

この引き継ぎによって、固定された出典記録形式をスコアやゲートに変えることなく、一括実行全体でエビデンスに関する規律を維持できます。${CLAUDE_SKILL_DIR}/../blog/references/flow-alignment.md を参照してください。

また、このコンテキストでは、blog-write に自律的に実行するよう指示します。トピックの確認とアウトラインの承認を省略し、テンプレートの自動検出を行わず、一時停止しないでください。

各投稿は、blog-write の完全な納品契約（標準の手順：下書き、ビジュアルの解決、レンダリング、nonce の初期化、レビュー、ゲート）に従います。クラスターの [INTERNAL-LINK: anchor -> filename.md] マーカーは下書き専用です。オーケストレーターはレンダリング前のビジュアル手順ですべて解決します。リンク先がすでに執筆済みのマーカーは、実際のリンクになります。リンク先がプラン内の後続投稿であるマーカーは、その投稿の PLANNED ファイル名への相対リンクになります（プランではすべてのファイル名が確定しています）。このリンクはクラスターの完了後に解決され、スコアカードのリンク監査で、すべてのリンク先が存在することを確認します。プラン内にリンク先がないマーカーは削除します。納品される投稿にマーカーを残してはいけません。

出力形式：blog-write の既定値に合わせ、標準の Markdown（.md）を既定で使用します。ユーザーが HTML を明示的に求めた場合は、それに応じてプラットフォームの出力先を設定します。ブランド固有の CSS やワードマークを適用しないでください。後続の処理はユーザーの責任です。

ステップ 4. ヒーロー画像（別途 blog-image を呼び出さない）

このスキルから /blog image を呼び出さないでください。blog-write の納品契約ではすべての投稿にヒーロー画像が必要です。投稿の下書きフォルダーに generate_hero.py を使って 1 回だけ作成するため、2 回目の呼び出しは費用を二重にし、競合するファイルを生成します。したがって、ヒーロー画像は任意ではなく必須です。投稿のヒーロー画像を作成できない場合、その投稿は契約を満たさず、バッチはステップ 6 に従って停止します。ステップ 3 で回答された HERO: を遵守し、各投稿について、スコアカードに画像の出典とモデル（hero-credit.txt の記載内容）を記録します。

Step 5. バックリンクの挿入

後続の投稿へのリンクを先行する投稿に追加する必要がありますが、配信契約を通過した投稿はその場で編集してはいけません。Markdown、HTML、PDF、またはヒーロー画像に変更を加えると、レビュー用 nonce と各ゲートが無効になります。各ケースを明示的に処理してください。

1. ほとんどの編集を防ぐ。 前方リンクマーカーは予定ファイル名に解決されるため（Step 3）、先行する投稿には、計画で指定されているすべての後続投稿へのリンクがすでに含まれています。計画の links_to と links_from を確認してください。
2. 対象がまだ下書きの場合（たとえば、対象の契約がまだ実行されておらず、直前に書いた投稿の後ろにキューされている場合）：契約の実行前に、Markdown 内の該当する [INTERNAL-LINK: keyword -> filename.md] マーカーを [keyword](filename.md) に置き換えます。再レビューは不要です。
3. 対象がすでに配信済みで、リンクがまだ不足している場合： ファイルには手を加えないでください。cluster-<slug>/cluster-link-patches.md に編集案（ファイル、アンカーテキスト、変更する文、対象ファイル名）を追記し、最終レポートに一覧を表示してください。ユーザーが明示的にパッチの適用を希望した場合は、Markdown を編集したうえで、その投稿について正規の手順を再実行します。再レンダリング、レビュー用 nonce の再初期化、再レビュー、--strict によるプリフライトの再実行を行ってください（最大 3 回）。事前に、追加でレビューを実行する回数をユーザーに伝えてください。
4. クラスターのメタデータ（cluster:、cluster_role:、cluster_group:、cluster_position:）は、各投稿の下書き作成時（Step 3）に、その投稿のフロントマターへ記述します。後から追加してはいけません。

Step 6. 失敗時の処理

いずれかの投稿で blog-write が品質ゲートの失敗を返した場合は、バッチを直ちに停止してください。進捗を保存し、失敗した投稿と残りのすべての投稿をスキップとして記録し、続行する前に失敗した投稿を手動で確認または再試行するようユーザーに伝えてください。品質の問題が発生した後も 5～15 件の投稿の生成を続けてはいけません。大規模なコンテンツ生成による不正利用のリスクが生じる可能性があります。

タイムアウトまたはランタイムエラーにより、コンテンツが生成される前に blog-write が失敗した場合は、スコアカードに失敗を記録し、原因を確認したうえでユーザーが明示的に再開を指示しない限り停止してください。

ユーザーが実行の途中でキャンセルした場合は、進捗を保存し、完了した投稿を記録してください。次回の /blog cluster execute では、すでに書き込まれたファイルを検出し、次に未作成の投稿から再開してください。

Step 7. cluster-scorecard.md の生成

試行したすべての投稿が完了したら、次の内容を含む Markdown のスコアカードを作成してください。

• 投稿ごとのステータス（作成済み、失敗、スキップ）、ファイルパス、単語数。
• 投稿ごとの品質スコア（Task を介して各投稿で /blog analyze を並列実行）とクラスターの平均スコア。
• クラスターの一貫性スコア：リンクの相互性、検索意図の多様性、テンプレートの多様性、キーワードの網羅率を組み合わせた 0～100 のスコア（計算式は ${CLAUDE_SKILL_DIR}/references/execution-workflow.md）。
• 内部リンクの監査：投稿ごとの発信リンク数と受信リンク数、孤立フラグ、未解決の [INTERNAL-LINK] マーカー。
• カニバリゼーションの確認：主キーワードが重複する投稿の組み合わせ、またはキーワードの重複率が 70% を超える投稿の組み合わせ。より詳細な確認のため、/blog cannibalization の実行を推奨してください。
• ヒーローの概要：hero-credit.txt に記載された投稿ごとのヒーロー画像のソースとモデル、およびストック素材へのフォールバック。
• リンクパッチ：cluster-link-patches.md の内容（存在する場合）。
• 推奨される次のアクション：スキーマの生成（/blog schema）、投稿ごとの SEO 検証（/blog seo-check）、コンテンツの再利用（/blog repurpose）。

Step 8. 最終レポート

合計件数、スコアカードのパス、次のアクションで使用するコマンドを含む簡潔な概要をユーザーに返してください。

出力成果物（概要）

ファイル	フェーズ	形式
cluster-plan.json	計画	JSON
cluster-map.html	計画	静的 HTML + インライン SVG、JavaScript なし
pillar-<slug>.md	実行	Markdown（またはプラットフォームが検出した形式）
<spoke-slug>.md	実行	Markdown（またはプラットフォームが検出した形式）
cluster-link-patches.md	実行（納品された投稿に計画済みのリンクがない場合のみ）	Markdown のパッチリスト
cluster-scorecard.md	実行	Markdown

---

品質ゲート

ゲート	チェック項目	不合格時の対応
クラスターの最低条件	それぞれ2件以上の投稿を含むクラスターが少なくとも2つあること	計画時に警告し、拡張を提案します
カニバリゼーション	どの2つの投稿も主要キーワードが重複しないこと	実行をブロックし、計画の調整を求めます
リンクの完全性	すべての投稿に2つ以上の内部リンクが向けられていること	スコアカードで警告します
長さの見積もり	ピラーには、スポークよりも深い内容が必要になることがよくあります	任意の計画コンテキストとして blog-write に渡します。単純な文字数の最低基準は決して課しません
検索意図の多様性	クラスター全体で、少なくとも2種類の異なる検索意図があること	スコアカードで警告します
テンプレートの多様性	クラスター全体で、少なくとも3種類の異なるテンプレートがあること	スコアカードで警告します

---

エラー処理

状況	対応
シードキーワードの範囲が広すぎる（キーワードのバリエーションが50件を超える）	クラスタリングの前に対象を絞るよう提案します。
シードキーワードの範囲が狭すぎる（キーワードのバリエーションが5件未満）	小規模なクラスター（ピラー1件とスポーク2～3件）を提案するか、対象を広げるよう提案します。
WebSearch が利用できない	下書きの計画のみを作成し、実行前にユーザーの確認、インポートしたキーワードデータ、または SERP データを求めます。
blog-write が品質ゲートまたはコンテンツ生成に失敗する	バッチを停止し、進捗を保存して、残りの投稿をスキップとして記録し、手動での確認または明示的な再開を求めます。
blog-write がインストールされていない	次のメッセージを返します："blog-cluster requires claude-blog. Install it before running this skill."
cluster-plan.json の形式が不正	JSON を検証し、行番号付きで解析エラーを報告します。
ユーザーが実行をキャンセルする	進捗を保存します。次回の呼び出し時に、すでに作成済みの投稿を自動検出して再開します。
投稿用のヒーロー画像を作成できない	納品要件で必須のため、その投稿は失敗となり、バッチを停止します（ステップ6）。ストック画像のみを使ったヒーロー画像を提案します。

---

関連する claude-blog スキルとの違い

スキル	役割	blog-cluster が追加する機能
blog-strategy	コンテンツの柱を3～5つ計画し、戦略的な演習としてハブ・アンド・スポーク図を作成します	SERP に基づいてセマンティッククラスタリングを行い、その後、計画を実際の相互リンクされた投稿に仕上げます。
blog-calendar	トピッククラスターを軸に公開日をスケジュールします	クラスターの構築も投稿の執筆も行いません。このスキルはその両方を行います。
blog-cannibalization	既存コンテンツ内のキーワードの重複を検出します	診断のみを行います。blog-cluster は計画段階でカニバリゼーションを防ぎます。
blog-write	一度に1件の投稿を執筆します	blog-cluster は、共有されたクラスターコンテキストと双方向リンクを用いて、複数回の blog-write 呼び出しを統括します。
blog-outline	SERP の情報を反映したアウトラインを1つ作成します	blog-cluster はクラスター全体にわたるアウトライン相当の内容を作成し、その後、投稿を執筆します。

blog-cluster はゼネコンとして、トピックを分析し、データに基づく計画を作成し、1つのシードキーワードから構造全体を構築します。