competitor-positioning

競合のポジショニング

Nimble のウェブデータ API を活用した、マーケティングに特化した競合ポジショニング分析です。 競合がどのように自社を打ち出しているか（メッセージ、価値提案、コンテンツのテーマ、価格設定）と、 それが時間とともにどのように変化しているかを把握したいマーケティングチーム向けに設計されています。

出力はマーケティングブリーフィングであり、シグナルフィードではありません。すべてのインサイトは、次の問いに答える必要があります。 「これは、私たちのメッセージやポジショニングにとって何を意味するのか？」

ユーザーのリクエスト：$ARGUMENTS

引数の解析 — 何を実行するかを、何かを実行する前に判断します。

• 引数なし → ワークフロー全体を実行します（ステップ 2 でスコープを確認）
• 競合名（例：「Exa, Tavily」）→ 指定された競合のみを調査し、スコープ確認をスキップします
• 「battlecard [competitor]」→ メモリ内の既存スナップショットを使用して、バトルカードの生成（後述）に進みます
• 「delta」／「what changed」→ 実行時期に関係なく、デルタモードを強制します

コマンドを実行する前に、references/nimble-playbook.md を読んで、Claude Code の制約（シェル状態なし、&／wait の禁止、サブエージェントの権限、コミュニケーションスタイル）を確認してください。

---

手順

ステップ 0：事前確認

references/nimble-playbook.md のトランスポート選択と標準の事前確認に従ってください。セッション開始時に CLI または MCP を選択し、標準の事前確認呼び出し（日付計算、今日、プロファイル、メモリインデックス）を並行して実行します。

結果に基づいて、次のように対応します。

• CLI がない、または API キーが未設定 → references/profile-and-onboarding.md を参照し、停止します
• nimble CLI 呼び出しにはすべて次のタグを付けます：nimble --client-source nimble-agent-skills <subcommand>。MCP リクエストはトランスポートレベルで帰属が記録されます。詳しくは references/nimble-playbook.md を参照してください。
• プロファイルがある → 次の 2 つのソースから過去のデータを読み込みます。
  • ~/.nimble/memory/positioning/*.md — 過去のポジショニングスナップショット（ステップ 4 と 5 の差分検出に使用）
  • ~/.nimble/memory/competitors/*.md — competitor-intel の実行で得られたビジネスシグナル（資金調達ラウンドや経営陣の変更など、ポジショニングが変化した背景を把握するために使用） モードを判断します。
  • フルスナップショット： 初回実行、または過去のポジショニングデータがない場合、または前回の実行から 14 日を超えている場合
  • デルタモード： 前回の実行から 14 日未満の場合。変更点のみを提示します
  • 同日再実行： last_runs.competitor-positioning が今日の日付の場合、~/.nimble/memory/reports/competitor-positioning-[today].md に既存のレポートがあるか確認します。 見つかった場合は、「今日はすでに実行済みです。最新データを取得するためにもう一度実行しますか？」と尋ねます。確認せずに再実行しないでください。
  • ステップ 2 に進みます
• プロファイルがない → ステップ 1

ステップ 1：初回実行時のオンボーディング（最大 2 つの質問）

このスキルは、競合リストを competitor-intel と共有します。競合が登録されたプロファイルがすでにある場合は、オンボーディングをすべてスキップしてください。

プロファイルがない場合は、オンボーディング全体の流れについて references/profile-and-onboarding.md に従ってください。ここで作成したプロファイルと競合リストは、すべてのビジネススキルで共有されます。

ステップ 2：スコープの確認

$ARGUMENTS ですでに競合が指定されている場合は、その競合を使用してこのステップをスキップします。

それ以外の場合は、プロファイル内の競合数を確認します。

• 4 社以下 → 確認せずにすべてを対象に進めます

• 4 社を超える → どの競合に焦点を当てるかを尋ねます（AskUserQuestion を使用）。

  追跡している競合は [N] 社です。どの競合を分析しますか？

  • すべて [N] 社（Nimble API クレジット約 [3-5 × N]、所要時間約 [N × 2] 分）
  • [Category A]：[names]（プロファイルの category に基づく分類）
  • [Category B]：[names]
  • 選択する — 競合を挙げます

  自然言語での回答も受け付けます。「AI 検索関連だけ」のような回答は、プロファイルのカテゴリに基づいて解釈します。

これにより、ユーザーが今は関心を持っていない競合への API クレジットや処理時間の浪費を防げます。競合 1 社あたりのコストは Nimble API クレジット約 3～5（マップ 1 回＋抽出 3～4 回＋検索 2～3 回）です。

ステップ 3：WSA の検出

競合ドメインとユーザーのドメインごとに、利用可能な WSA を検出します。

nimble extract:templates list --limit 100  # then filter items for "{domain}"

各ドメインについて検索を 1 回ずつ同時に実行します。SERP/PDP WSA に絞り込み、managed_by: "nimble" を優先し、nimble extract:templates get --extract-template-name {name} で検証します。検出した名前とパラメーターをキャッシュします。より充実したデータ抽出のため、ステップ 5 で競合エージェントに渡します。WSA が見つからない場合は、nimble search/extract/map を続けます。

ステップ 4：ユーザー自身のポジショニングを把握する（ベースライン）

競合を分析する前に、メッセージングマトリックスのベースラインとして、ユーザー自身のポジショニングを把握します。

まず、サイト構造を検出して、データ抽出に適したページを見つけます。

nimble --transform "links.#.url" map --url "https://[company-domain]" --sitemap only --limit 200

返された URL から、機能／製品ページと料金ページを特定します（/features、/product、/platform、/pricing、/plans を含むパスを探します）。

次に、主要なページを同時に抽出します（ホームページと、map で見つかった該当ページ）。

• nimble extract --url "https://[company-domain]" --format markdown → ホームページのメッセージング、タグライン、ヒーローコピー、CTA
• nimble extract --url "[features-page-url]" --format markdown → 機能ページの構成と強調点（map で該当ページが見つからなかった場合はスキップします）
• nimble extract --url "[pricing-page-url]" --format markdown → 料金体系の構成とプラン名（map で該当ページが見つからなかった場合はスキップします）

ページの抽出結果が意味をなさない場合は、「ページにアクセスできません」と記録して続行します。ベースラインは一部だけでも、ないよりは有用です。

ステップ 5：競合ごとの並列調査（サブエージェント）

エージェントの完全なプロンプトテンプレートについては、references/positioning-agent-prompt.md を読みます。references/nimble-playbook.md のサブエージェント起動ルール（bypassPermissions、最大 4 件のバッチ、Bash の明示的な指示、失敗時のフォールバック）に従います。

呼び出し数の見積もりとスケール実行： エージェントを起動する前に、API 呼び出しの合計数を見積もります。競合 1 社あたり、map 約 1 回＋抽出 3 回＋検索 3 回＝約 7 × N 回（ステップ 3 のベースライン分を除く）です。競合が 2 社以上（14 回以上）の場合、ページ抽出では個別の呼び出しではなく extract-batch を使うようエージェントに指示します。階層の選択については、references/nimble-playbook.md のスケール実行パターンを参照してください。

対象範囲内の競合ごとに、mode: "bypassPermissions" を指定した general-purpose サブエージェントを起動し、references/positioning-agent-prompt.md のプロンプトをインラインで指定します。各競合の名前、ドメイン、開始日、メモリから読み込んだ以前のポジショニングスナップショット（ステップ 0 で読み込み）、およびより充実したデータにアクセスするためのステップ 3 で検出した WSA 名を使って、プロンプトをカスタマイズします。

agents/nimble-researcher.md は使用しないでください。このエージェントは生データの収集に限定され、分析を明示的に禁止していますが、このスキルでは解釈を伴う作業（オーディエンスの兆候の特定、ポジショニングスナップショットの比較、構成がもたらす影響の評価）が必要です。

各エージェントは、競合 1 社について一連の調査をすべて担当します。

1. nimble map でサイトの実際のページ構造を検出します
2. ホームページ、機能ページ、料金ページを抽出します（検出した URL を使用）
3. 最近のブログ記事を検索して抽出します（詳しく分析する記事を 2～3 件）
4. ソーシャルプルーフを分析します（導入事例、推薦文）
5. 以前のスナップショットと比較して変化を確認します

エージェントは、構造化されたポジショニングスナップショットを返します。出力形式の詳細については、プロンプトテンプレートを参照してください。ブログ記事を別途抽出する必要はありません。エージェントが処理します。

エージェントによるブログ記事の抽出が不十分な場合（抽出した記事が 2 件未満）、エージェントの検索結果にある URL を使って、必要に応じてメインコンテキストから追加の記事を抽出します。

フォールバック： エージェントが完全に失敗した場合は、同じプロンプトテンプレートの手順を使って、メインコンテキストから直接抽出します。

ステップ 6：分析と出力

マーケティングチーム向けに、すべてをまとめてください。メッセージングの優先順位、シェア・オブ・ボイス、バトルカードのインプット、コンテンツカレンダーへの影響など、チームで使う用語を使用してください。

エージェントの結果からブログコンテンツを分析する際は、次の点を確認してください。

• 繰り返し登場するナラティブ — この企業は、どのようなストーリーを繰り返し伝えていますか？
• オーディエンスのターゲティング — 投稿は開発者、経営幹部、実務担当者の誰を対象にしていますか？
• 競合への言及 — 競合の名前を挙げていますか。それともカテゴリーとの対比で自社を位置付けていますか？
• SEO のパターン — タイトルや見出しでは、どのキーワードをターゲットにしていますか？
• コンテンツの成熟度 — 独自調査、ソートリーダーシップ、それとも一般的なハウツーですか？

全体スナップショットモード（初回実行時、または前回から 14 日以上経過している場合）：

• マーケティング向け要約 — マーケティングチームが対応すべき、ポジショニングに関する重要なインサイトを 3〜5 件挙げ、それぞれに具体的な影響を示します（例：「競合 X はタグラインを開発者向けからエンタープライズ向けに変更しました。自社のメッセージングで引き続き差別化できているか検討してください」）

• メッセージングマトリックス — すべての競合と自社について、タグライン、主要 CTA、価値提案、ターゲットオーディエンス、価格モデルを行にした比較表を作成します。タグラインと CTA は一字一句そのまま引用してください。

• 競合ごとのポジショニングプロファイル：

  • サイト構成のシグナル（存在するページ／存在しないページ、サブドメイン）
  • ホームページのメッセージングの内訳（タグライン、ヒーロー、CTA、価値提案）
  • 機能ページの分析（強調している内容、差別化の主張）
  • 価格設定のポジショニング（モデル、ティア戦略、エンタープライズ向けのシグナル）
  • コンテンツ戦略（ブログのテーマ、投稿頻度、対象オーディエンス、コンテンツの種類）
  • ソーシャルプルーフ戦略（紹介している顧客、強調している成果）

• コンテンツギャップ分析 — 競合が公開していて、自社が公開していないコンテンツ：

  • 競合が取り上げていて、自社が取り上げていないトピック
  • 競合が使用しているコンテンツ形式（ケーススタディ、ベンチマーク、ROI 計算ツール）
  • コンテンツで取り上げているオーディエンスセグメント

• ポジショニングのホワイトスペース — どの競合も強く打ち出していないメッセージングの切り口：

  • まだ主張されていない価値提案
  • 十分に対応されていないオーディエンスセグメント
  • ナラティブのギャップ

• 推奨アクション — マーケティングチームが次に取るべき、具体的で実行可能なアクション （例：「競合 X の新しいエンタープライズ向けポジショニングに対抗するメッセージング案を作成する」、「3 社の競合がすでに存在感を確立しているため、[segment] を対象にしたケーススタディを優先する」）

差分モード（前回の実行から 14 日未満の場合） — 変更点のみ：

• 変更点 — 競合ごとに、変化した内容を変更前／変更後で示します：

  • 「タグライン：『[old]』→『[new]』」
  • 「新しい機能カテゴリーを追加：[name]」
  • 「価格モデルを [old] から [new] に変更」
  • 「新しいブログテーマが登場：[topic]（直近 2 週間で 3 件の記事）」

• 変更なし — ポジショニングに変化がなかった競合を列挙します

• マーケティングへの影響 — 変更がチームの優先事項にとって何を意味するかを示します

基本ルール：

• すべての主張に出典ページへのリンクを付けてください。
• ~/.nimble/memory/positioning/*.md と照合して重複を除いてください。差分モードでは、本当に新しい変化のみを提示します。
• 内容を水増しせず、「ポジショニングの変更は検出されませんでした」と記載してください。
• タグライン、CTA、価値提案は言い換えず、一字一句そのまま引用してください。

WSA による情報補完： ステップ 3 で WSA が見つかった場合、より豊富なページデータを取得するため、エージェントは nimble map／nimble extract と併用してください。

ステップ 7：メモリを保存・更新する

すべての書き込み呼び出しを同時に実行します。

• レポート → ~/.nimble/memory/reports/competitor-positioning-[date].md （要約ではなく、ブリーフィング全体を保存します。これはローカルの信頼できる唯一の情報源です）

• 競合他社ごと → 次の形式を使って、ポジショニングのスナップショットを ~/.nimble/memory/positioning/[name].md に保存します。 references/positioning-snapshot-format.md の形式を使います。History セクションに日付付きのエントリーを追記し、今後の実行で変更点と時期を検出できるようにします。ポジショニングのスナップショットと競合他社のインテリジェンスファイルを関連付けるため、[[competitors/name]] の 相互参照を追加します。

• プロフィール → ~/.nimble/business-profile.json の last_runs.competitor-positioning を更新します。

• references/memory-and-distribution.md の wiki 更新パターンに従います。影響を受けるすべてのエンティティファイルについて index.md の行を更新し、今回の実行について log.md にエントリーを追記します。

ステップ 8：共有・配布する

必ず配布を提案してください。このステップを省略しないでください。 コネクターの検出、共有のフロー、ソースリンクの適用については、 references/memory-and-distribution.md に従ってください。特にマーケティングチームは、ポジショニングのワークショップやコンテンツ計画で参照できる、共有された Notion ページを活用できます。

バトルカードの生成

"battlecard [competitor]" 引数、または後続のリクエストによって開始します。

入力： 競合他社のポジショニングスナップショットを ~/.nimble/memory/positioning/[name].md から、ユーザー独自のベースラインを最新のレポートから読み込みます。スナップショットが存在しない場合（または 14 日を超えて古い場合）は、先にその競合他社についてステップ 4～5 を実行し、その後ここに戻ります。

出力形式：

# Battlecard: [Your Company] vs [Competitor]
## As of [date]

### Competitor Overview
- Tagline: [verbatim]
- Primary CTA: [verbatim]
- Target audience: [who their messaging speaks to]
- Pricing model: [type and entry price if known]

### Their Key Claims
[List each value prop / differentiator they emphasize, verbatim with source URL]

### Our Counter-Positioning
[For each claim above: our response, proof points, and messaging angle]

### Feature Comparison
| Capability | Us | Them | Advantage |
|---|---|---|---|

### Where They Win (acknowledge honestly)
[Areas where their positioning is stronger or they have genuine advantages]

### Where We Win
[Our unique advantages, with evidence]

### Objection Handling
| Prospect Says | Respond With |
|---|---|

### Recommended Talking Points
[3-5 concise talking points for sales/marketing conversations]

---

ステップ 9：後続の対応

• 競合他社のバトルカードを生成する → 上記のバトルカード生成を実行
• 特定の競合他社の主張に対する対抗メッセージを作成する → 別の切り口と根拠を提案
• コンテンツカレンダーを比較する → 自社の公開予定を競合他社の公開ペースと照らし合わせる
• 競合他社をさらに詳しく調べる → 追加ページ（概要、採用情報、パートナー、事例）を抽出
• 新しい競合他社を追跡する → competitors を更新し、ポジショニングスナップショットを作成
• 競合他社をスキップする → preferences.skip_competitors を更新
• 「問題ありません」 → 完了

関連スキルの提案：

次のステップ：

• competitor-intel を実行して、事業に関するシグナル（資金調達、採用、製品のローンチ）を調べる
• company-deep-dive を実行して、任意の競合他社の全方位的なプロフィールを作成する
• 競合他社の担当者と会う場合は、meeting-prep を実行する

---

エージェントチームモード（デュアルモード）

起動時に確認します：echo $CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS

チームモード（フラグが設定されている場合）：

• name: パラメーターを指定して Agent ツールを使い、チームメイトを指定可能にします
• チームメイトは SendMessage を使って、発見した競合他社間の傾向を共有できます （例：「今月、2 社が従量課金制に移行しました」）
• すべての競合他社担当のチームメイトが戻った後、すべての調査結果を入力として マーケティングアナリストのチームメイトを起動します。コンテンツのギャップ分析とポジショニングの空白領域だけに注力させます。これにより、データ収集と戦略分析を分離できます
• リードエージェントが、相互検証済みの最終的なマーケティングブリーフィングをまとめます

ソロモード（フラグが設定されていない場合）：

• 標準の fire-and-forget サブエージェントを使用します（SendMessage と name: は使用しません）
• エージェントの戻り後、すべての分析をメインコンテキストで実行します

---

エラー処理

標準的なエラーテーブル（API キーの欠落、429、401、空の検索結果、抽出データの破損）については、references/nimble-playbook.md を参照してください。このスキル固有のエラーは次のとおりです。

• 検索で 500 エラーが発生した場合： --focus フラグを付けずに 1 回再試行します。それでも失敗する場合は、クエリを簡略化して（検索語を短くし、日付フィルターを外して）再試行します。失敗を記録しますが、競合他社の分析は省略しません。
• 検索がタイムアウトした場合： 1 回再試行し、その後はその呼び出しをスキップして続行します。これはプレイブックのタイムアウトポリシーに準じます。
• ページの抽出に失敗した場合（404／データの破損）： マップの手順で実際の URL を先に特定するため、ほとんどの 404 は防げるはずです。それでも抽出に失敗した場合は、「ページにアクセスできません」と記載して続行します。部分的なデータでも、データがないよりは有用です。
• マップの結果が空の場合： サイトによってはサイトマップへのアクセスがブロックされます。その場合はホームページを直接抽出し、一般的なパス（/features、/pricing、/blog）を推測します。
• ブログの検索結果が空の場合： ブログを運営していない企業もあります。「有効なブログは検出されませんでした」と記載し、ページベースのポジショニングに注目します。