competitor-intel

競合インテリジェンス

Nimble のウェブデータ API を活用したリアルタイムの競合インテリジェンスです。

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

コマンドを実行する前に、Claude Code の制約について references/nimble-playbook.md を読んでください （シェルの状態管理なし、&／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 を参照してください。
• プロフィールがある → ~/.nimble/memory/competitors/index.md を読み込み、存在する競合ファイルと最終更新日を確認します。インデックスがない場合（初回実行またはアップグレード）、代わりに ~/.nimble/memory/competitors/*.md をすべて直接読み込みます。インデックスは最適化のためのものであり、必須ではありません。次に、既知のシグナルに関連する競合ファイルを読み込みます （ステップ 3 と 5 で重複排除に使用します）。相互参照（[[path/entity]] リンク）をたどって関連するコンテキストを読み込みます。references/nimble-playbook.md のスマートな日付範囲設定に従ってモードを判定します。
  • フルモード： 初回実行、または前回の実行から 14 日を超えている場合
  • クイック更新： 前回の実行から 14 日未満の場合
  • 同日再実行： last_runs.competitor-intel が今日の日付の場合、~/.nimble/memory/reports/competitor-intel-[today].md にレポートがすでに存在するか確認します。存在する場合は、「今日はすでに実行済みです。最新のデータを取得するため、もう一度実行しますか？」と尋ねます。黙って再実行しないでください。
  • ステップ 2 に進みます。
• プロフィールがない → ステップ 1 に進みます。

注： ステップ 2（WSA の検出）は、オンボーディングの後、調査を始める前に実行します。

ステップ 1：初回オンボーディング（質問は最大 2 回）

質問 1 — プレーンテキストで尋ねます（選択肢付きの AskUserQuestion は使用しません）。

「会社のウェブサイトのドメインを教えてください。（例：acme.com）」

確認 — 次の 2 つの Bash 呼び出しを同時に実行します。

• nimble search --query "[domain]" --include-domain '["[domain]"]' --max-results 3 --search-depth lite
• nimble search --query "[domain] company" --max-results 5 --search-depth lite

質問 2 — 会社を確認し、競合の調査方法を選んでもらいます（AskUserQuestion を使用）。

[Company]（[domain]）は、[brief description] であると判明しました。 これは正しいですか？また、競合はどのように調べればよいですか？

• はい — 競合を調べてください
• はい — 自分で競合をリストアップします
• 会社が違います — 補足します

「競合を調べてください」の場合、次の 3 つの Bash 呼び出しを同時に実行します。

• nimble search --query "[Company] competitors" --max-results 10 --search-depth lite
• nimble search --query "[Company] vs" --max-results 10 --search-depth lite
• nimble search --query "[Company] alternatives" --max-results 5 --search-depth lite

リストを提示します。ユーザーの確認後、プロフィールを作成してステップ 2 と 3 を開始します。 プロフィールの作成時に、各競合のドメインとユーザーの業界キーワードについても尋ねるか、推定してください。プロフィールの完全なスキーマ（company、ドメイン／カテゴリを含む competitors、industry_keywords、integrations、preferences）については、references/profile-and-onboarding.md を参照してください。

ステップ 2：WSA の検出

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

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

ドメインごとに検索を 1 回ずつ、同時に実行します。結果から、entity_type が SERP または PDP に一致する WSA を絞り込み、managed_by: "nimble" を優先して、nimble extract:templates get --extract-template-name {name} でそれぞれを検証します。検出した WSA 名とパラメーターは、この実行中にキャッシュします。より豊富なデータを得るため、ステップ 3～4 では検出した WSA と nimble search を併用します。WSA が見つからない場合は、nimble search のみで続行します。

Step 3: ユーザーの会社を調査する

一般的な会社名によるノイズを避けるには、--include-domain を使用します。Bash 呼び出しを 2 回実行します。

• nimble search --query "product updates OR changelog OR releases" --include-domain '["[company-domain]"]' --start-date "[start-date]" --max-results 5 --search-depth lite
• nimble search --query "[UserCompany] news" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite

結果が 3 件未満の場合のフォールバック： nimble search --query "blog" --include-domain '["[company-domain]"]' --max-results 5 --search-depth lite

Step 4: 競合他社ごとに並行して調査する（サブエージェント）

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

mode: "bypassPermissions" を指定して、agents/nimble-researcher.md の nimble-researcher エージェントを起動します。プロンプトテンプレートには、各競合他社の 名前、ドメイン、start-date、メモリ（Step 0 で読み込み済み）にある既知のシグナル、および Step 2 で判明した WSA 名を設定し、エージェントがそれらを情報の補強に利用できるようにします。

呼び出し回数の見積もりとスケール実行： エージェントを起動する前に、API 呼び出しの合計を 見積もります（競合他社 1 社あたり検索約 6 回 × 競合他社数 N 社 ＋ 業界検索約 2 回 ＋ 抽出）。 競合他社が 2 社以上（呼び出し 12 回以上）の場合、ページの抽出には個別の呼び出しではなく extract-batch を使うようエージェントに指示します。ティアの選択については、 references/nimble-playbook.md の「スケール実行」パターンを参照してください。

また、industry_keywords を使って、業界検索もサブエージェント内ではなく直接実行します。

• nimble search --query "[industry_keyword] AI agents OR automation" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite
• nimble search --query "[industry_keyword] regulation OR compliance OR pricing" --focus news --start-date "[start-date]" --max-results 5 --search-depth lite

Step 5: 詳細抽出

日付の確認、またはより詳しい情報が必要なシグナルを抽出します。詳しいルールについては、 references/nimble-playbook.md → 「シグナルの日付検証」→「検証予算」を参照してください。

必ず抽出するもの：

• P1 のシグナル（資金調達、M&A、経営陣）— 詳細の確認と日付の検証が必要です
• DATE_CONFIDENCE: LOW のシグナル — ページ本文に基づくイベント日の検証が必要です
• SOURCE_TYPE: DERIVATIVE のシグナル — 実際のページ本文からイベント日を確認します

有用であれば抽出するもの：

• スニペットに日付または重要な詳細がない P2 のシグナル

スキップするもの： DATE_CONFIDENCE: HIGH の P3 のシグナル。

URL ごとに Bash 呼び出しを 1 回実行し、すべて同時に実行します。

nimble extract --url "https://..." --format markdown

抽出に失敗した場合は、references/nimble-playbook.md のフォールバックに従います。

抽出したコンテンツを読む際は、ページヘッダーの日付だけでなく、記事本文から実際のイベント日を 特定します。イベントと結び付いた明示的な日付、「昨年 9 月」や「第 3 四半期に」といった時期を示す 表現、日付行を確認します。

Step 5.5: シグナルの検証

レポートを作成する前に、すべてのシグナルの鮮度を検証します。完全なパターンについては、 references/nimble-playbook.md →「シグナルの日付検証」を参照してください。

Step 3 の各シグナルを分類します：

チェック	結果	アクション
EVENT_DATE が鮮度ウィンドウ内にあり、メモリにも存在しない	NEW	含める
EVENT_DATE がウィンドウ内にあり、既知のシグナルを更新する	UPDATED	更新として含める
EVENT_DATE が鮮度ウィンドウ外にある	STALE	除外 — 古いイベント、新しい記事
DATE_CONFIDENCE: LOW で、Step 4 でも確認できなかった	UNCERTAIN	注記を付けて除外

P1 の裏付け（必須） — NEEDS_CORROBORATION: true の P1 シグナルは、レポートに含める前に必ず裏付けを取る必要があります。これは提案ではなく、必須の条件です。

フラグが付いた各 P1 について、次を実行します：

nimble search --query "[Company] [event summary]" --max-results 5 --search-depth lite

一次情報源（企業ブログ、プレスリリース、公式提出書類）を探します。一次情報源の日付が鮮度ウィンドウ外であれば、STALE に再分類します。 一次情報源が見つからない場合は、UNCERTAIN に再分類して除外します。

除外ルール：

• イベントの日付が鮮度ウィンドウ外にある → STALE
• 裏付けとなる一次情報源または主要メディアがなく、派生サイト／アグリゲーターサイトのみを情報源とする → UNCERTAIN。抽出によって確認できない限り除外
• コンテンツが明らかに過去のイベントを示しており（「昨年」「第 3 四半期に」「数か月前」などの時間表現）、イベントの日付がウィンドウ外にある → STALE

検証後は、NEW および UPDATED のシグナルのみを含むクリーンなリストができているはずです。

Step 6: 分析と出力

フルモード（初回実行、または前回から 14 日超）— 構造化されたブリーフィング：

• TL;DR — P1 シグナルを 3～5 件、最新のものから順に並べ、各項目に日付と情報源を記載
• 競合他社別 — 「最近」と「過去の背景」のサブセクション、「競合他社が優位な点と自社が優位な点」の表、「これが意味すること」（1～2 文）
• 業界のトレンド — 業界検索から得られたシグナル
• 自社の更新情報 — Step 2 のリリース／ニュース
• 競合他社間の傾向 — 収束するトレンド
• [Company] にとっての意味 — 戦略的な影響と推奨アクション

クイック更新モード（前回実行から 14 日未満）— 短縮形式：

• 新しいシグナル — 日付、競合他社名、優先度、クリック可能な情報源 URL を記載
• 新しい情報なし — 新しいシグナルがない競合他社を列挙
• アクション項目 — 対応が必要な場合のみ

基本ルール：

• すべてのシグナルには、検証済みのイベント日付が必須です。鮮度ウィンドウ内に発生したイベントのみが新しいシグナルの条件を満たします。より古いイベントは背景情報です。
• Step 5.5 で NEW または UPDATED に分類されたシグナルのみを含めます。STALE および UNCERTAIN のシグナルはすでに除外されています。
• ~/.nimble/memory/competitors/*.md と照合して重複を排除し、NEW の調査結果のみを提示します。
• 内容を水増しするのではなく、「この期間に特筆すべきことはありません」と伝えます。
• P3 シグナルは簡潔に触れるか、レポートが長い場合は省略します。

Step 7: メモリの保存と更新

Step 5.5 の検証に合格したシグナル（NEW または UPDATED に分類されたもの）のみを保存します。 STALE または UNCERTAIN のシグナルは、競合他社のメモリファイルに書き込まないでください。

すべての Write 呼び出しを同時に行います：

• レポート → ~/.nimble/memory/reports/competitor-intel-[date].md（要約ではなく、ブリーフィング全文を保存します。これがローカルの信頼できる情報源です）
• 競合他社ごと → 検証済みのシグナルを ~/.nimble/memory/competitors/[name].md に追記します （references/memory-and-distribution.md に記載された形式を使用）。調査で判明した関係性については、[[path/entity]] の相互参照を追加します （例：主要人物 → [[people/name]]、関連する競合他社 → [[competitors/name]]）。
• プロファイル → ~/.nimble/business-profile.json の last_runs.competitor-intel を更新します
• references/memory-and-distribution.md の wiki 更新パターンに従います。影響を受けるすべてのエンティティファイルについて index.md の行を更新し、この実行に関するエントリを log.md に追記します。

ステップ 7.5：統合ページの生成

今回の実行で調査した競合他社が3社以上いる場合、または既存の ~/.nimble/memory/synthesis/competitive-landscape.md のソースタイムスタンプが古い場合 （生成後にソースとなるエンティティファイルが更新されている場合）、統合ページを生成または更新します。

nimble-analyst エージェント（agents/nimble-analyst.md）を mode: "bypassPermissions" で使用し、すべての競合他社ファイルにまたがるパターンを統合します。エージェントは すべての ~/.nimble/memory/competitors/*.md ファイルを読み込み、 references/memory-and-distribution.md の形式に従って competitive-landscape.md を作成します。内容には、市場マップ、機能比較、価格比較、主要なパターン、 および戦略的な示唆を含めます。ソースとなるエンティティファイルは [[competitors/name]] リンクで引用します。

未回答の質問があれば、~/.nimble/memory/backlog.md に追記します （例：価格や資金調達などの重要なデータが欠けている競合他社）。

生成後、index.md を更新し、統合ページのエントリーを追加します。

ステップ 8：共有と配布

配布は必ず提案してください。このステップを省略しないでください。 コネクターの検出、共有フロー、 およびソースリンクの適用については、references/memory-and-distribution.md に従ってください。

ステップ 9：フォローアップ

• 競合他社をさらに詳しく調べる → より焦点を絞った検索を実行します
• 競合他社を除外する → preferences.skip_competitors を更新します
• 競合他社を追加する → competitors を更新し、メモリのひな形を作成します
• 「問題ありません」 → 完了です

関連スキルの提案：

次のステップ：

• competitor-positioning を実行して、競合他社がオンラインでどのように自社をアピールしているかを分析します
• company-deep-dive を実行して、このレポートに含まれる競合他社の360度全体像を把握します
• 競合他社の関係者と面談する場合は、meeting-prep を実行します

---

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

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

チームモード（フラグが設定されている場合）：サブエージェントではなく、完全なチームメイトを起動します。

• リード（あなた）：競合他社を割り当て、最終ブリーフィングを統合します
• 競合他社ごとに1人のチームメイト：検出されたWSAを使用して references/competitor-agent-prompt.md を実行します — 重複するシグナルを見つけた場合、チームメイト同士でメッセージをやり取りできます
• デビルズアドボケイト（任意）：調査結果に異議を唱え、見落としがないか探します
• リードが、より信頼性の高い相互検証済みのブリーフィングを統合します

単独モード（フラグが設定されていない場合）：ステップ3の標準的なサブエージェントフローを使用します。

---

エラー処理

標準のエラー表（APIキーの欠落、429、401、結果が空、抽出結果の不備）については、 references/nimble-playbook.md を参照してください。スキル固有のエラー：

• 検索の500エラー： --focus フラグを付けずに1回再試行します。それでも失敗する場合は、 簡略化したクエリ（短い検索語、日付フィルターなし）で再試行します。失敗を記録しますが、 その競合他社をスキップしないでください。
• 検索のタイムアウト： 1回再試行した後、その呼び出しをスキップして続行します。これは プレイブックのタイムアウトポリシーに準拠しています。