competitor-analysis

競合分析

ユーザーの競合他社を分析します。調査には Browserbase Search API を使用し、情報を拡充するために 4 レーンの Plan→Research→Synthesize パターンを採用します。概要、競合他社ごとの詳細分析、機能と価格の比較表、時系列の言及フィードを含む HTML レポートを出力します。

必須：BROWSERBASE_API_KEY 環境変数と、インストール済みの browse CLI（npm install -g browse）。

初回実行時のセットアップ：初回実行時には、browse cloud fetch、browse cloud search、cat、mkdir、sed などの実行許可を求められます。それぞれについて "Yes, and don't ask again for: browse cloud fetch:*"（または同等の項目）を選択してください。永続的に許可するには、これらを ~/.claude/settings.json の permissions.allow に追加してください：

"Bash(browse:*)", "Bash(bunx:*)", "Bash(bun:*)", "Bash(node:*)",
"Bash(cat:*)", "Bash(mkdir:*)", "Bash(sed:*)", "Bash(head:*)", "Bash(tr:*)", "Bash(rm:*)"

パスのルール：Bash では必ず完全なリテラルパスを使用し、~ や $HOME は使用しないでください。ホームディレクトリを一度解決し、その後は常にその値を使用してください。サブエージェントへのプロンプトを作成する際は、{SKILL_DIR} を完全なリテラルパスに置き換えてください。

出力ディレクトリ：すべての出力は ~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}/ に保存されます。このディレクトリには、競合他社ごとの .md ファイル 1 つと、生成された HTML ビューおよび CSV が含まれます。

重要 — ツールの使用制限（メインエージェントとすべてのサブエージェントに適用）：

• すべてのウェブ検索には browse cloud search を使用してください。WebSearch は絶対に使用しないでください。
• すべてのページ取得には browse cloud fetch --allow-redirects を使用してください（既定では Markdown が返されます。元の HTML が必要な場合は --format raw を追加し、sed ... | tr -s ' \n' にパイプしてテキストを抽出してください）。WebFetch は絶対に使用しないでください。レスポンスの上限は 1 MB です。JS を多用するページの場合は、browse open <url> --remote の後に browse get markdown を使用してください。
• すべての調査結果は、サブエージェントが bash heredoc を使用して {OUTPUT_DIR}/{competitor-slug}.md に競合他社ごとに 1 つの Markdown ファイルとして書き込んでください。Write ツールや python3 -c は絶対に使用しないでください。ファイル形式については references/example-research.md を参照してください。
• レポートのコンパイルには、node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open を使用してください。これにより、index.html、competitors/*.html、matrix.html、mentions.html、results.csv が一度に生成され、概要が開きます。
• URL の重複排除には、node {SKILL_DIR}/scripts/list_urls.mjs /tmp --prefix competitor を使用してください。
• サブエージェントは Bash ツールのみを使用してください。
• メインエージェントは、生の調査結果 JSON バッチファイルを絶対に読み込まないでください。

重要 — 許可プロンプトを最小限に抑える：

• サブエージェントは、連結した heredoc を使用し、すべてのファイル書き込みを単一の Bash 呼び出しにまとめてください。
• && で連結し、すべての検索とすべてのページ取得をそれぞれ単一の Bash 呼び出しにまとめてください。

パイプラインの概要

以下の8つのステップを順番に実行してください。省略したり、順序を入れ替えたりしないでください。

1. ユーザー企業の調査 — ユーザーの企業を深く理解し、precise_category + category_include_keywords + exclusion_list を作成します
2. 深度モード + シード入力 — 深度を選択し、任意のシード競合他社URLを受け付けます
3. 発見（3つの並列ウェーブ） — ウェーブA（代替候補）、ウェーブB（正確なカテゴリ）、ウェーブC（「X vs Y」のタイトル解析による比較ページのグラフ）
4. ゲート — scripts/gate_candidates.mjs が各候補のヒーローテキストを取得し（browse cloud fetch 経由）、カテゴリが異なるURLを除外します
5. ユーザーとエンリッチメント対象を確認 — PASS / UNKNOWN / rejected-brand-matches を AskUserQuestion で提示します。ユーザーに実際の候補を選んでもらい、発見で漏れた候補を追加してもらいます。エンリッチメントはコストが高く（深度予算を使用するサブエージェントが25個）、ゲートも完全ではないため（JSを多用するホームページ、Cloudflareのチャレンジ、意味的なバリエーションを含むタグライン）、このステップを省略すると非効率です
6. 詳細なエンリッチメント（deep/deeper モードでは競合他社ごとに5つのサブエージェント） — マーケティング、ディスカッション、ソーシャル、ニュース、技術の各レーンを個別のサブエージェントが担当し、partials/ に書き込みます。その後、merge_partials.mjs が統合します。deep/deeper モードでは、ステップ5dでステップ5cのファクトチェック完了後に、6つ目のバトルカード統合レーンを追加し、引用付きの根拠に基づいた競合他社ごとの Landmines / Objection Handlers / Talk Tracks を作成します。
7. スクリーンショット — browse CLI 経由で capture_screenshots.mjs を実行し、競合他社ごとにホームページのヒーロー部分を1280×800でキャプチャします
8. HTMLレポート — 概要 + 競合他社別ビュー（ヒーローのスクリーンショットを埋め込み、バトルカードを表示）+ マトリックス + メンションビュー

---

ステップ0：出力ディレクトリの設定

OUTPUT_DIR=~/Desktop/{company_slug}_competitors_{YYYY-MM-DD}
mkdir -p "$OUTPUT_DIR"

{company_slug} をユーザーの企業名（小文字、ハイフン区切り）に、{YYYY-MM-DD} を今日の日付に置き換えます。すべてのサブエージェントに {OUTPUT_DIR} を完全なリテラルパスとして渡してください。

前回の実行で作成された発見バッチファイルを削除します：

rm -f /tmp/competitor_discovery_batch_*.json

再実行は、必ず空の $OUTPUT_DIR から開始してください。 compile_report.mjs はディレクトリ内の すべての {slug}.md を読み込みます。また、merge_partials.mjs は現在の対象に含まれるスラッグのみを上書きし、新しいエンリッチメント対象から外れたスラッグは削除しません。ディレクトリ名には日付が使われるため、同じ日に競合他社の対象を変更して再実行すると、概要、マトリックス、CSV、スクリーンショットに古い競合他社の情報が残ります。新しいディレクトリを使うか、先に競合他社ごとのファイルを削除してください：

rm -f "$OUTPUT_DIR"/*.md && rm -rf "$OUTPUT_DIR"/partials "$OUTPUT_DIR"/screenshots

ステップ 1：ユーザーの会社の調査

このステップでは、「競合」の意味を定める基準を設定し、ステップ 5b のマトリックスで userCompany 行に使用する検証済みデータを作成します。

ルール：ユーザーの会社も、競合と同じ 5 レーンの調査を行います。userCompany を記憶だけに頼って matrix.json に入力しないでください。ユーザー自身のチームに誤った情報を提供することになります。検索 API を使った実行（ユーザー企業 Exa、2026-04-23）でこのステップを省略したところ、Exa に「公開された稼働率 SLA」があるとするマトリックスが作成されました（数値による公開 SLA はなく、ステータスページのみです）。また、MIT ライセンスの Python SDK が open-source: false とされていました（リポジトリは github.com/exa-labs/exa-py で、LICENSE は MIT と確認済みです）。どちらの誤りも、「優位に立っている点」カードに捏造された競争優位性として表示されるところでした。

手順：

1. ユーザーに会社名または URL を尋ねます。

2. {SKILL_DIR}/profiles/{company-slug}.json に既存のプロフィールがあるか確認します。存在する場合は読み込み、ユーザーに「{researched_at} 時点のプロフィールがあります。現在も正確ですか？」と確認します。正確であればステップ 2 に進みます。ただし、マトリックスの統合に新しい機能の根拠が必要なため、以下の部分レーンの補足調査は実施してください。 プロフィール形式は company-research と共通です（同じ構造です）。ユーザーのプロフィールが company-research/profiles/ にすでに保存されている場合は、再調査せずにこのスキルの profiles ディレクトリへコピーしてもかまいません。

3. ユーザーの会社について、5 レーンの補足調査をすべて実施します。ステップ 5 の競合調査と同じパターンです。各レーンについて、Bash のみを使用するサブエージェントを起動し、{OUTPUT_DIR}/partials/{user-slug}.{lane}.md に書き出します。

   • marketing — キャッチフレーズ、ポジショニング、料金プラン、機能、連携、オープンソースのコンポーネント（SDK のリポジトリとライセンス）、提供地域、コンプライアンス（SOC 2／HIPAA／トラストポータル URL）
   • technical — REST およびストリーミング API の対応状況（ドキュメント URL を含む）、SDK の言語、MCP サーバーの URL、ニューラル検索とキーワード検索のモード、再ランキング／ハイライト／ライブクロールの詳細、公開された稼働率 SLA（ステータスページではなく実際の割合）、サードパーティによる検索品質ベンチマーク
   • discussion、social、news — クイックモードでは任意、ディープモード以上では推奨 サブクエスチョンについては references/research-patterns.md →「Self-Research」を参照してください。各調査結果には必ず URL を記載してください。

4. ユーザーの会社の部分調査結果に対しても merge_partials.mjs を実行し、{OUTPUT_DIR}/{user-slug}.md を生成します。これはステップ 5b が userCompany フラグの情報源として読み込む正規ファイルです。

5. プロフィールを統合します。含める項目は Company、Product、Existing Customers、Competitors（候補リスト）、Use Cases、precise_category、category_include_keywords、exclusion_list です。ICP は含めないでください。このスキルでは不要です。

   • precise_category：カテゴリを説明する 1 文。例：「ニューラル検索とキーワード検索に対応した、エージェント向け AI ウェブ検索 API」。 「ツール」や「プラットフォーム」のような曖昧な言葉は避けてください。
   • category_include_keywords：直接の競合企業のマーケティング文言に含まれる可能性が高いフレーズを 8～15 個記載します（ヒーローセクションまたはタイトル）。意味上の類義表現も含めてください。
   • exclusion_list：異なるカテゴリを示すフレーズです。誤検出を排除するためのゲートに使用します（例：antidetect browser、scraping api、screenshot api、residential proxy）。 正確な形式と Exa を使った記入例については、references/research-patterns.md →「Synthesis Output」を参照してください。

6. プロフィールとユーザー企業の .md ファイルをユーザーに提示し、確認を求めます。確認が完了するまで先に進まないでください。

7. 確認済みのプロフィールを {SKILL_DIR}/profiles/{company-slug}.json に保存します。

ステップ 2：深度モードとシード入力

チェックボックス付きの AskUserQuestion で、確認の質問をします。

• 既知の競合他社はありますか？ URL／名前を入力するテキストエリア（任意 — 追加の競合他社は検索で見つかります）。
• 深度モードは？
  • quick — マーケティング情報のみ、多数の競合他社、各社につきツール呼び出し約2～3回
  • deep — 外部シグナル（言及、レビュー、ニュース）も追加、各社につきツール呼び出し約5～8回
  • deeper — 公開ベンチマークとユーザー企業との戦略的な差分も追加、各社につきツール呼び出し約10～15回
• 目標件数は？ 調査する競合他社のおおよその数（例：10／20／50）。

これがユーザーとの唯一のやり取りです。この後は、レポートが完成するまで通知せずに実行します。

モード	競合他社ごとの調査	最適な用途
quick	レーン1のみ（ホームページ＋料金）	競合他社約30～50社をすばやくスキャン
deep	レーン1＋2	外部シグナルを含めて約15～25社を調査
deeper	4つのレーンすべて（＋ベンチマーク＋戦略的な差分）	詳細な情報をもとに約5～15社を調査

ステップ 3：発見（並列で3つのウェーブ）

計算式：ウェーブあたりのクエリ数は ceil(target_count / 20)。フィルターで約40～60％が除外されるため、目標の約3倍を見つけます。

検索 API の実行評価では、3つのウェーブはすべて相補的であり、どれかを省略すると実在する競合他社を見逃すことが示されています。

ウェーブ A — 一般的な代替製品（範囲が広く、アグリゲーターのノイズが多いため、後で除外します）

• "{user_company}の代替製品"
• "{user_company}の競合他社"

ウェーブ B — 正確なカテゴリー（プロファイルの precise_category を使用）

• "{precise_category}" をそのまま使用
• 最も特徴的なトークンを組み合わせて2～3件のクエリを作成（例："AI エージェント向けウェブ検索 API"、"LLM 向け検索 API"）

ウェーブ C — 比較ページのグラフ（最も精度が高い）

• "{user_company} vs"
• "{seed1} vs"、"{seed2} vs"、"{seed3} vs"（シードはプロファイルの competitors リストから取得）
• 検索後、scripts/extract_vs_names.mjs を実行して、結果タイトルから "X vs Y" のパターンを解析します。これにより、URL の検索結果に現れない競合他社を独自に見つけられます。

手順：

1. 1つのメッセージ内で、browse cloud search を実行する Bash 呼び出しを3つ並列で発行します（各ウェーブにつき1つ）。サブエージェントは使用しないでください。各 Bash 呼び出しでは、2～4件のクエリを && で連結します。正確な手順は references/workflow.md →「発見 — サブエージェントではなく並列 Bash」を参照してください。browse cloud search を6～12回呼び出す作業には、サブエージェントは過剰です。
2. すべてのウェーブが完了したら：

   node {SKILL_DIR}/scripts/list_urls.mjs /tmp --prefix competitor > /tmp/competitor_urls.txt
   node {SKILL_DIR}/scripts/extract_vs_names.mjs /tmp --prefix competitor \
     --seed "{user_company},{seed1},{seed2},{seed3}" \
     > /tmp/competitor_vs_names.jsonl
   

3. フィルター /tmp/competitor_urls.txt — ブログ記事、ニュース、AI ツールディレクトリ（seektool.ai、respan.ai、agentsindex.ai、toolradar.com、aitoolsatlas.ai、vibecodedthis.com など）、レビュープラットフォーム（g2.com、capterra.com）、データベース（crunchbase.com、tracxn.com）、ユーザー自身のドメインを削除します。ノイズとなるドメインの完全なリストは references/workflow.md を参照してください。
4. vs_names の項目に解決済みの domain がある場合は、それを追加します。未解決の名前については、必要に応じて browse cloud search "{name}" --num-results 3 を実行し、上位のルートドメインを選びます。
5. ユーザー提供のシード URL と統合します。ホスト名で重複を除去し、/tmp/competitor_candidates.txt に保存します。

ステップ 4：ゲート（カテゴリー適合フィルター）

マーケティング情報から別のカテゴリーだと判明した候補は、エンリッチメントでツール呼び出しを消費する前に除外します。

cat /tmp/competitor_candidates.txt \
  | node {SKILL_DIR}/scripts/gate_candidates.mjs \
      --include "{profile.category_include_keywords joined with commas}" \
      --exclude "{profile.exclusion_list joined with commas}" \
      --concurrency 6 \
  > /tmp/competitor_gated.jsonl

grep '"status":"PASS"' /tmp/competitor_gated.jsonl \
  | node -e 'require("fs").readFileSync(0,"utf-8").split("\n").filter(Boolean).forEach(l => { try { console.log(JSON.parse(l).url); } catch {} })' \
  > /tmp/competitor_passed.txt

ゲートでは、browse cloud fetch --allow-redirects --format raw を使って各候補のホームページを取得し、表示テキストの先頭800文字を抽出して、位置を考慮して分類します。<title> に除外対象が含まれる場合は REJECT、対象カテゴリーが含まれる場合は PASS、混合タイトルの場合は hero200 で判定し、それ以外は次の判定に進みます。

検索 API の実行で評価済み：カテゴリーが混在する候補12件のうち、実在する競合他社7社はすべて合格し、カテゴリー違いの4社はすべて除外され、既知のハイブリッドに関するエッジケース1件も除外されました。

ステップ 4.5：エンリッチメント対象をユーザーに確認する

このステップは必須です。ゲートが実行されたからといって、エンリッチメントに進んではいけません。

エンリッチメントにはコストがかかります。競合他社 5 社 × レーンごとのサブエージェント 5 個で、サブエージェントは合計 25 個、所要時間は約 10～15 分、browse cloud の呼び出しは約 300 回です。対象を間違えて実行すると、そのすべてが無駄になります。また、ゲートには既知の見落としがあります。

• JS を多用したホームページ（例：Tavily、Firecrawl）— browse cloud fetch がほぼ空のテキストを返すため、キーワードに一致するものがなくなり、→ REJECT または UNKNOWN になります
• Cloudflare のチャレンジページ（例：Perplexity）— タイトルが「Just a moment...」になり、カテゴリを示す情報がなくなります
• 意味的な表現のバリエーション — 「search foundation」や「retrieval backbone」は、「search API」を中心にしたリストと語彙的に一致しません
• ドメインの曖昧さ — brave.com（ブラウザー）と api-dashboard.search.brave.com（実際の API 製品）の違いは、分類を混乱させる可能性があります

ユーザーは、そのスキルにないドメイン知識をほぼ必ず持っています。ユーザーに尋ねてください。

手順 — メインエージェントが行います。

1. /tmp/competitor_gated.jsonl を読み込み、行をグループ分けします。

   • PASS バケット：status=PASS のすべての項目。
   • UNKNOWN バケット：status=UNKNOWN（取得に失敗したもの。見落とされやすいため、必ず提示してください）。
   • 却下されたブランドのバケット：REJECT 項目のうち、タイトルに有名ブランドのパターンが含まれる上位約 10 件（例：ユーザーが指定したシードリストのトークンを含む、または Wave C の「X vs Y」グラフに頻繁に登場するもの）。

2. 各バケットについて、URL + タイトル + 理由（却下された項目の場合）を含むテーブルをそれぞれ 1 つ作成し、ユーザーに提示します。

3. 3 つのバケットすべての候補を含むチェックボックスリストと、自由記入式の「追加」欄を用意して、AskUserQuestion を使用します。プロンプトでは、次の内容を明確に伝えてください。

   「ゲートが選んだ項目と、判定に迷った項目をいくつか提示します。ご自身の分野で実際に競合するものにチェックを入れ、見落とした URL があれば（カンマ区切りで）貼り付けてください。エンリッチメントは、チェックされた項目のみを対象に実行されます。」

4. 確認済みの対象を /tmp/competitor_enrichment_set.txt に書き込みます（1 行につき URL を 1 つ）。これはステップ 5 の入力であり、/tmp/competitor_passed.txt ではありません。

ユーザーから応答がない場合、または「そのまま実行して」と明示的に言われた場合は、/tmp/competitor_passed.txt をそのまま使用します。ただし、カテゴリが異なる候補に予算を浪費する可能性があることをチャットで警告してください。

Exa のテスト、2026-04-24：ゲートは候補 101 件のうち 22 件を自動で PASS にしましたが、Tavily（一般的なタイトル）、Jina AI（意味的な不一致 — 「search foundation」）、Firecrawl（JS を多用したサイトでの取得失敗）、Perplexity（Cloudflare のチャレンジ）を見落としました。この 4 社はいずれも実際の直接競合です。このステップで見落としを防げます。

ステップ 5：詳細なエンリッチメント

モードは 2 つあります。プロンプトのテンプレートと Wave の管理については references/workflow.md を、レーンごとの手法については references/research-patterns.md を参照してください。

クイックモード — バッチごとにサブエージェント 1 個

• 入力：/tmp/competitor_enrichment_set.txt（ステップ 4.5 でユーザーが確認した対象）、サブエージェント 1 個につき競合他社約 8 社。
• サブエージェント 1 個でレーン A のみ（マーケティングの表層）を実行します。各社につきツール呼び出しは 2～3 回です。
• {OUTPUT_DIR}/{slug}.md に直接書き込みます。

Deep / Deeper モード — 競合他社ごとに 5 つのサブエージェント（並列レーンへの分岐）

競合他社ごとに、レーンごとに 1 つずつ、5 つのサブエージェントを並列で起動します。

• A. マーケティング（marketing）：料金、機能、ポジショニング、インテグレーション、顧客、チーム、資金調達、本社。正規のフロントマターを担当します。
• B. ディスカッション（discussion）：Reddit、HN、フォーラム、Dev.to、Hashnode。site: を使った検索に限らず幅広く検索します。"{competitor}" review 2026、"{competitor}" issues OR problems、"{competitor}" discussion も検索します。
• C. ソーシャル（social）：LinkedIn の投稿、YouTube の動画、Twitter/X。スニペットのみとし、取得はしません。
• D. ニュースと比較（news）：TechCrunch、Verge、VentureBeat、Forbes、Businesswire、Substack、ブログのレビュー。言及にはすべて日付が必要です。
• E. 技術とベンチマーク（technical）：GitHub のベンチマークリポジトリ／PR、パフォーマンスに関する投稿。ベンチマークと技術的な調査結果を作成します。

レーンあたりの予算：deep はツール呼び出し 5～8 回、deeper は 10～15 回です。 すべての競合他社 × レーンのサブエージェントを、単一の Agent ツールメッセージで起動してください。 競合他社 10 社 × 5 レーンの場合は、50 件の Agent 呼び出しを 1 つのメッセージで並列実行します。競合他社ごと、またはレーンごとに分割してバッチ処理しないでください。実行時間は最も遅い単一エージェント（約 3～5 分）まで短縮されます。実測環境での並列実行は 5 分だったのに対し、10 件ずつ 5 ラウンドに分けると実行時間が 25 分になりました。分割しないでください。

各サブエージェントは {OUTPUT_DIR}/partials/{slug}.{lane}.md に部分ファイルを書き込みます。

重要：すべてのサブエージェントのプロンプトに、ユーザーの会社名、製品名、主要な機能を一字一句そのまま渡し、技術レーンが戦略的な差分分析を行えるようにします。完全なリテラルの {OUTPUT_DIR} パスも、すべてのサブエージェントに渡してください。

部分ファイルを統合 → 競合他社ごとの正規ファイル

すべての競合他社について、すべてのサブエージェントが完了した後：

node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}

競合他社ごとに 5 つの部分ファイルを統合して、1 つの {OUTPUT_DIR}/{slug}.md を作成します。言及は重複を削除して日付の降順に並べ、ベンチマークは重複を削除し、調査結果を統合し、マーケティングレーンの正規フロントマターを使用します。

比較マトリックスを統合する（matrix.json を作成する）

サブエージェントは、key_features と integrations を、パイプ区切りの個別機能ラベルではなく、文章で記述します。そのため、単純に | で分割した軸では、競合他社ごとに項目がひとまとまりになり、重複する項目がありません。生成されるマトリックスは、役に立たない対角線状になります。

メインエージェントは、競合他社全体で共通の分類体系を統合し、{OUTPUT_DIR}/matrix.json に書き込むことでこの問題を解決します。compile_report.mjs はこのファイルを自動検出し、パイプ分割ではなく、このファイルからマトリックスを生成します。

手順 — メインエージェント：

1. ユーザーの会社ファイル {user-slug}.md（ステップ 1 で作成）を含む、すべての {slug}.md ファイルを読みます。マトリックス上ではユーザーを競合他社 #0 として扱い、同じ厳密さで調査します。

2. 12～20 件の正規機能リストを作成します。各項目は、競合他社が持っているかどうかを二択で判定できる原子的な命題にします（例：「MCP サーバー」「SOC 2」「サイトクローラー」「リランカー」）。文のように長い機能名は避けます。1 社だけが持つ機能は避けます。

3. 10～20 件の正規インテグレーションリストを作成します（フレームワーク、マーケットプレイス、SDK 言語）。

4. ユーザーも含む各社について、.md ファイルの調査データに基づき、分類体系の各項目を true / false にします。**すべてのフラグは、URL が引用された「Research Findings」の箇条書きまで追跡できる必要があります。**ユーザーのファイルに「exa-py MIT-licensed (github.com/exa-labs/exa-py)」とあれば、オープンソース機能は、その URL をソースとして true にします。言及がなければ false のままにします。

5. 次の形式で {OUTPUT_DIR}/matrix.json に結果を書き込みます。

   {
     "category": "AI search APIs",
     "features": [{ "name": "Web Search API", "description": "..." }, ...],
     "integrations": [{ "name": "LangChain" }, ...],
     "userCompany": {
       "name": "Exa",
       "winningSummary": "Exa's moats are its first-party neural index and the integrated Research API — no one else in the set ships a semantic/embeddings-native retrieval primitive alongside a multi-step agentic research endpoint. It's also the only provider with a crawler product bundled in, and ties with SerpAPI on breadth of SDK language coverage.",
       "losingSummary": "Exa trails competitors on operational transparency — SerpAPI, Serper, and Tavily all publish hourly throughput SLAs, and Exa lacks a dedicated news endpoint that SerpAPI, Serper, and You.com all ship. Image/visual search is also missing vs 4 of 5 competitors.",
       "features": { "Web Search API": true, "Site crawler": true, ... },
       "integrations": { "LangChain": true, ... }
     },
     "competitors": {
       "tavily": {
         "features": { "Web Search API": true, "Site crawler": true, ... },
         "integrations": { "LangChain": true, "Databricks Marketplace": true, ... }
       },
       "serpapi": { "features": {...}, "integrations": {...} }
     }
   }
   

   userCompany は必須です。概要ページには、「{user} が優位に立つ分野」と「{user} が劣勢にある分野」の 2 枚のカードが表示されます。userCompany.features と userCompany.integrations には、自己調査プロフィール（ステップ 1）の内容を入力します。このフィールドがないと、2 枚のカードは表示されません。

   書き込み順序（2 回に分けて実施することで、以下にある順序の見かけ上の矛盾を解消します）。 このステップ（5b）では、userCompany とすべての競合他社について、features / integrations のすべてのセルを入力し、winningSummary / losingSummary の草案も作成します。草案は、ステップ 5c のファクトチェッカーに重要度の高い主張を知らせるためだけに使われます（ファクトチェッカーは、要約に記載された項目を優先して確認します）。ステップ 5c で検証済みの根拠に基づいてセルを修正した後、事実確認済みのセルだけを反映するよう、2 つの要約を書き直します。上記の JSON 形式は、ファクトチェック完了後の確定オブジェクトを示しています。

   userCompany.winningSummary / losingSummary の記入を強く推奨します（アナリスト形式の文章で、それぞれ 2～4 文）。記入されている場合、カードには箇条書きではなく段落が表示されます。スプレッドシートではなく、ブリーフィングのように読めます。省略した場合、カードには優位な項目／劣位な項目と、それを持つ他社を示す箇条書きが表示されます。

このステップを省略すると、マトリックス表示は未加工のパイプ分割軸にフォールバックし（原子的な比較には役立ちません）、戦略的要約も表示されません。省略しないでください。

マトリックスのファクトチェック — 重要度の高いセルをスポットチェックする（デフォルト）

重要度の高いセルについては、分類パスだけを信頼しないでください。 分類パスは文章からの LLM による推論であり、存在しない競争優位性をでっち上げることがあります。検索 API の実行中（2026-04-23）に確認された例では、matrix.json がユーザーの会社だけが SOC 2 を取得していると主張していましたが、検証したところ、競合他社のうち 3 社も SOC 2 Type II を取得していました。

しかし、すべてのセルを検証するのも逆の誤りです。7 社 × 33 軸のマトリックスには 231 個のセルがあります。2026 年 4 月の検索 API の実行では、割り込み前のファクトチェックでツール呼び出しが 111 回以上に達して行き詰まりました。サブエージェントが、カテゴリ全体で一般的な基本機能（REST API、JSON レスポンス、Python SDK）まで調べ続けたためです。

デフォルトは全件チェックではなく、スポットチェックです。 戦略上の説明を大きく左右するセルだけを検証します。

ファクトチェックを行うサブエージェントを 1 つ起動します（Bash のみ）。呼び出し回数の上限は厳守で 25 回とし、次の重要度の高い軸だけを対象にします。

1. userCompany.features と userCompany.integrations のすべてのセル（ユーザー自身の競争優位性であり、そのまま「優位な点」の説明文に使われます）。通常は 17 + 16 = 33 個のセルですが、多くは明白です（自社製品のことなので）。次の項目を重点的に確認します。

   • winningSummary で競争優位性として主張されているもの
   • losingSummary で不足点として主張されているもの
   • コンプライアンス（SOC 2、HIPAA、ISO 27001、GDPR）
   • オープンソースライセンスに関する主張（MIT／Apache 2.0／AGPL — 競合他社の SDK で誤りが確認されています）
   • 公表されている稼働率 SLA（ステータスページは SLA ではありません）

2. 競合他社については、勝敗の要約に影響するセルだけを対象にします。

   • 「優位な点」の各主張について、ユーザーがその機能を備えていることを検証し、競合他社が備えていないことも検証します。
   • 「劣っている点」の各主張について、名指しされた競合他社がその機能を備えていることを検証します。
   • すべての競合他社を対象に、コンプライアンス、ライセンス、SLA を確認します（信頼性が重要で、誤りもよくあります）。

3. 次の項目は検証しないでください。

   • どのサービスにもある基本機能（REST API、JSON レスポンス、Python SDK、API キー認証）。どの検索 API にもあります。
   • 主張がない false のセル（失った競争優位性も、得た競争優位性もありません）。
   • 勝敗の要約に含まれていないインテグレーションのセル。

You are a matrix spot-check subagent. Budget: 25 browse cloud calls TOTAL across all cells.
Stop and return what you have when you hit the budget — partial fact-check is
better than blocking the rest of the pipeline.

TOOL RULES: Bash ONLY. browse cloud search + browse cloud fetch. Count your calls; stop at 25.

PRIORITY ORDER (highest-stakes first — work down until budget):
1. Every cell that appears in userCompany.winningSummary or losingSummary
2. Compliance cells (SOC 2, HIPAA, ISO 27001) for user + every competitor
3. Open-source / self-hostable + license cells across all competitors
4. Pricing tier numbers ($X/mo, /hr) for user + competitors named in summaries
5. Funding / employee_estimate fields (only if cited in summaries)

Skip:
- Universal cells (REST API, JSON responses, Python SDK, API-key auth, etc.)
- `false` cells where no claim is being made
- Integration matrix cells unless they appear in summaries

For each cell verified:
- If `true` — find one source URL (docs, trust portal, GitHub LICENSE, etc).
- If `false` — one targeted browse cloud search. Flip ONLY on first-party evidence.

Output: matrix.json with `sources: { "Feature": "https://..." }` on the
verified cells (other cells stay as-is). Cells-changed log to
{OUTPUT_DIR}/matrix_fact_check.md with each flip + URL + quoted evidence.
Report back: "spot-check: N cells verified, M flipped, B/25 budget used".

全件チェックモード（任意、時間がかかります）：ユーザーが「完全なファクトチェック」と明示した場合、または重要度の高い成果物（取締役会向け資料、プレスリリース）の場合は、上限を 80 回に設定し、一般的な機能以外のすべてのセルを検証します。デフォルトはスポットチェックです。

サブエージェントの処理が終わったら、matrix.json を読み直して再コンパイルし、matrix_fact_check.md の差分をユーザーに提示します。スポットチェックを行わない場合に比べて、要約の信頼性が大きく高まります。また、パイプラインを停滞させず、3～5 分で完了できます。

ステップ 5d：バトルカードの統合（deep/deeper のみ、ステップ 5c の後）

ステップ 5c でファクトチェック済みの matrix.json が必要です。 これは営業支援の工程です。競合ごとに、Bash のみを使用する統合サブエージェントを起動します（新たな browse cloud 呼び出しは禁止）。サブエージェントは、既存の 5 つの部分ファイルすべて、ユーザーが統合した .md、ファクトチェック済みの matrix.json を読み込み、引用付きの根拠に基づいた競合ごとの Landmines／Objection Handlers／Talk Tracks を作成します。

プロンプトテンプレート：references/battle-card-subagent.md（競合ごとに {COMPETITOR_SLUG}／{COMPETITOR_NAME}／{USER_COMPANY_NAME}／{USER_WINNING_SUMMARY} を置き換えてください）。フォーマット仕様：references/battle-card.md。

出力：{OUTPUT_DIR}/partials/{slug}.battle.md の ## Battle Card セクション。

この工程の完了後に、必ずマージを再実行してください。 ステップ 5 のマージはバトルカードの部分ファイルが作成される前に実行されているため、統合済みの {slug}.md ファイルにはまだ含まれていません。再実行してください：

node {SKILL_DIR}/scripts/merge_partials.mjs {OUTPUT_DIR}

これにより、各 {slug}.battle.md が統合済みの {slug}.md に追加されます（battle 工程は merge_partials.mjs で処理されます）。compile_report.mjs は {slug}.md から ## Battle Card セクションを読み取り、競合ごとの HTML ページにブランドカラーをあしらったカードとして表示します。この再マージを省略すると、レポートにバトルカードが表示されません。

この工程が統合のみである理由 — バトルカードは、ステップ 5c のファクトチェックを通過した事実に基づいて作成する必要があります。サブエージェントに新たな browse cloud 検索を許可すると、ファクトチェック工程が防ごうとしている、ハルシネーションによる競合優位性の問題が再び持ち込まれます。サブエージェントによる敵対的なセルフチェックでは、入力された部分ファイルの箇条書き、または sources に裏付けられた matrix のセルにたどれない主張を明示的に却下します。

並列実行：競合ごとにサブエージェントを 1 つずつ、すべて 1 つの Agent-tool メッセージで実行します（統合は高速で、サブエージェントあたり約 3～5 回の Bash 呼び出しです）。カードを信頼できる形で裏付けるだけの調査の深さがないため、quick モードではこのステップを省略してください。

ステップ 6：スクリーンショット

競合ごとに、ホームページのヒーロー画像のスクリーンショットを撮影します：

node {SKILL_DIR}/scripts/capture_screenshots.mjs {OUTPUT_DIR} --mode remote

browse CLI（npm install -g browse）を使用します。--mode フラグでブラウザーセッションを選択します。remote（デフォルト）は Browserbase セッションを操作します。保護されているホームページやボット検知のあるホームページに最適で、ローカルの Chrome がなくても使える唯一の選択肢です。local は、お使いのマシン上の Chrome を使用します。スクリプトは各 browse コマンドに対応する --remote／--local フラグを渡すため、別途環境設定を行う必要はありません。競合ごとに 1 つの PNG を {OUTPUT_DIR}/screenshots/{slug}-hero.png に書き込みます。ステップ 7 のコンパイル工程で、各競合の HTML ページにヒーロー画像が自動的に埋め込まれます。

所要時間：約 10～20 秒／競合。競合 5 社で約 60 秒です。

ステップ 7：HTML レポート

1. すべてのビューと CSV を生成する（ブラウザーで概要を開きます）：

   node {SKILL_DIR}/scripts/compile_report.mjs {OUTPUT_DIR} --user-company "{user_company}" --open
   

   生成されるファイル：

   • {OUTPUT_DIR}/index.html — 概要：タグライン、価格の概要、主な機能、戦略的な差異をまとめた競合一覧
   • {OUTPUT_DIR}/competitors/{slug}.html — 競合ごとの詳細分析（すべてのセクション）
   • {OUTPUT_DIR}/matrix.html — 機能／価格の比較マトリクス
   • {OUTPUT_DIR}/mentions.html — ソース種別のピルとクライアント側フィルターを備えた時系列フィード
   • {OUTPUT_DIR}/results.csv — フラットなスプレッドシート

2. チャットで概要を提示する：

## Competitor Analysis Complete

- **Competitors researched**: {count}
- **Depth mode**: {mode}
- **Mentions collected**: {total mentions} across {source types count} source types
- **Public benchmarks found**: {count}
- **Opened in browser**: ~/Desktop/{company_slug}_competitors_{date}/index.html

3. チャットで概要表を表示する：

| Competitor | Positioning | Pricing | Key Features | Strategic Diff |
|------------|-------------|---------|--------------|----------------|
| Rival Co | AI-native web search API | $99/mo entry | semantic search, reranking, crawler | Similar retrieval; cheaper entry |

4. 特に興味深い調査結果を上位 3～5 件取り上げます。例：「3 社の競合が公開ベンチマークを実施しています。Rival Co が最安です。Foo Inc は 2 週間前にニュース検索専用のエンドポイントをリリースしました。」特定の競合についてさらに調査するか、別の深さで再実行するかを提案します。