build-competitive-brief

競合比較ブリーフの作成

検証済みの事実、現場からの情報、推論を分けた、営業担当者がそのまま使える競合比較ブリーフを作成します。デフォルトでは、単独で完結するHTML成果物と簡潔なチャットでの要約を作成します。ユーザーが明示的に希望した場合に限り、チャットまたはMarkdownのみで作成します。このスキルの対象は、調査、情報の統合、ブリーフの成果物の作成であり、外部への投稿やCRMへの書き込みは対象外です。

共通スキルの指示

必須：まだコンテキストにない場合は、plugins/sales/skills/index/SKILL.md## Cross-Skill Best Practicesを読み、厳密に従ってください。

主な依存カテゴリ

依頼に実質的に関係するカテゴリを使用してください。利用可能な情報源があるというだけで、検索範囲を広げないでください。

• ~~CRM：アカウント、商談、連絡先、担当、把握済みの競合、進行中の案件に関する事実の確認
• ~~ナレッジとファイル：バトルカード、競合関連資料、アカウントプラン、製品のポジショニング、実績を示す情報、過去のブリーフ
• ~~社内メッセージ：最近の現場情報、アカウントチームの所見、異議の例、社内情報が重要な場合の信頼できる情報源への誘導
• ~~会議の文字起こし：過去の異議、競合への言及、購入者の言葉、決定事項、コミットメント
• ~~営業インテリジェンス：競合の特定、企業情報、または具体的な証拠の不足を補う場合に限り使用

最新の公開競合情報には、公開情報を調査してください。公式の製品、価格、発表、顧客事例、投資家向け、規制関連の情報源を優先し、一次情報だけでは不十分な場合に限り、二次報道を使用してください。

参照資料の読み込み

SKILL.mdには、通常の調査フロー、HTMLをデフォルトとする動作、証拠に関するガードレールが記載されています。追加の詳細が必要な場合に限り、以下の参照資料を読み込んでください。

• 構造化入力、モードの正規化、またはマトリックスの上限には、references/request-schema.yamlを使用してください。
• 情報源の食い違い、信頼性の優先順位、公開情報に基づく証拠の格下げが不明確な場合は、references/source-priority.mdを使用してください。
• 正確なセクション順、簡潔なブリーフの形式、または機械可読性との互換性には、references/output-contract.mdを使用してください。

用語

• **バトルカード：**競合に対するポジショニングを説明する、営業担当者向けの簡潔なガイドです。競合が優位な点、劣る点、伝えるべき内容を含みます。
• **防御的な準備：**進行中の商談で競合が実際に関与していると断定するだけの証拠がない場合でも、その競合が関係する可能性に備えることです。

ワークフローのガイダンス

1. 比較の基準を定める

• 有用な基準を少なくとも1つ特定してください。具体的には、競合の名称、競合に関する情報を含むアカウントまたは商談の名称、あるいは比較対象となる製品、ワークフロー、セグメント、市場カテゴリが明確であることです。
• ユーザーが指定した営業担当者、競合、アカウント、異議の表現はそのまま維持してください。信頼できる場合に限り、プロンプトまたは提供資料から営業担当者を推定してください。そうでない場合は、的を絞った質問を1つしてください。
• ユーザーが明確な製品、ワークフロー、セグメント、市場カテゴリを示しているものの、競合名を挙げていない場合は、営業担当者の状況、購入者の状況、製品の範囲、継続的に管理されている競合資料、公開情報から、有力な競合を特定してください。候補を絞り、不確実性を明示してください。
• ユーザーが提供した情報ではなく、情報源から推定した必須の基準については、ユーザーの確認が必要です。
• 基準が曖昧な場合は、質問する前に範囲を限定して候補を調べてください。情報源の確認は最大3回までとし、理由を1行添えて具体的な候補を最大5件提示するために必要な分だけ行ってください。
• 企業名のような名称が競合とも顧客とも解釈できる場合は、利用可能であれば範囲を限定して~~CRMを確認してください。顧客だと判明し、ユーザーが競合として明確に指定していない場合は、アカウントの情報として扱うか、ユーザーに選択を求めてください。
• ユーザーが推定した必須の基準を確認するまでは、広範な情報収集を行わないでください。

2. 権威性の高い順に証拠を集める

ユーザーが対象範囲をより狭く指定していない限り、次の順序を使用します。

1. ユーザー提供のメモ、資料、文字起こし、過去のブリーフ、リンク先の資料
2. ~~Knowledge & Files の競合関連資料、バトルカード、アカウントプラン、ポジショニング
3. ~~CRM による、特定アカウントまたは商談に関する事実
4. トークトラックに大きく影響する場合の ~~Meeting Transcripts および ~~Internal Messaging
5. 競合他社および販売側の公式公開情報
6. 投資家向け資料、規制関連資料、その他の一次公開資料
7. 特定の不足情報を補うための ~~Sales Intelligence および信頼できる二次報道

• 一般的なウェブ調査を、より信頼性の高いユーザー提供資料や社内資料の代わりにしないでください。
• 販売側が明らかな場合は、販売側が管理する情報源から販売側の基準情報を確立します。ポジショニング、製品ライン、ターゲットセグメント、顧客事例、最近のローンチ、比較に関する表現を確認します。
• 現在のポジショニング、ローンチ、価格設定、パートナーシップ、公開実績に関する主張は、公開されている一次情報で検証します。
• 競合他社のみを対象とする調査では、入手可能な場合、異なる複数の証拠単位を探します。アカウントを対象とする調査では、ユーザーから提供された場合、または接続された情報源から範囲を絞って取得できる場合に、アカウントの証拠を追加します。
• 社内の現場情報は、アカウントの証拠、整備された資料、または公開情報で裏付けられない限り、参考情報として扱います。
• 重要な情報源ごとに、具体的な証拠単位を抽出します。主張されていること、確認されたこと、買い手が関心を持つ可能性がある理由、反論または捉え直しの方法、過度な主張を避けるべき点を整理します。
• 重要な主張には、可能な場合、クリック可能なリンクを付けて出典を示します。情報源が利用できない、古い、情報が不十分、または内容が矛盾している場合は、その旨を伝え、入手できる最も信頼性の高い証拠を使って続けます。

3. 統合する前に競合他社ごとの資料を作成する

対象となる競合他社ごとに、入手可能な関連事実を記録します。

• プロフィール、ターゲット市場、販売している製品やサービス
• ポジショニングと買い手にとっての魅力
• 根拠がある場合に限り、価格設定または価格に関するトークトラック
• 最近のローンチ、リリース、パートナーシップ、公開実績
• 優位に立てる領域と、販売側が差別化できる領域
• 想定される異議、ディスカバリー質問、トークトラック、注意すべき落とし穴

競合他社をひとまとめにして、一般化した説明にしないでください。それぞれ異なる証拠と不確実性を維持してください。

4. アカウントの状況を慎重に加味する

• アカウント名が示されている場合は、まずユーザー提供のアカウントメモを使用し、アカウントと商談に関する事実の確認には ~~CRM を使用します。
• 実際のアカウントに関する示唆を明確にする場合に限り、~~Knowledge & Files、~~Meeting Transcripts、~~Internal Messaging を選択して使用します。
• 公開調査や一般的な現場の話から、アカウントの状況、競合他社の存在、商談の状況を推測して作り上げないでください。
• 商談で競合他社が活動しているという直接的な証拠がない場合は、アカウントのセクションを「防御的な準備」と明記します。

5. 販売側の回答をまとめる

• 簡潔さを基本とし、依頼に応じて、異議への対応、ポジショニング、または account_overlay を使い、より絞った形式にします。
• ユーザーが明示的にそれ以上を求めない限り、1つの比較表で比較する競合は最大5社にします。
• 1対1の比較では「領域 | 販売側 | 競合 | 評価」を使います。1対複数の比較では「領域 | 販売側の見解 | 状況 | 主な圧力」を使います。
• 「リード」「[競合名]からの圧力」「混在」「未確定」などの状況を使い、証拠が裏付けていない場合は勝者を無理に決めないでください。
• 事実に基づいた冷静なトーンを保ちます。何を話すか、何を確認するか、どの証拠を使うか、何を過剰に主張しないかを含めます。依頼がない限り、機能だけの比較は避けてください。
• 提案内容では、各競合が何をしているか、どこで脅威となるか、なぜ勝つのか、なぜ負けるのか、どう競うか、販売担当者または戦略担当者が次に何を伝えるべきかに答えます。

1対1の比較例：

領域	MyCompany	Competitor Alpha	評価
導入適合性	ガバナンスの効いたエンタープライズ展開に強い	チーム単位で迅速に導入する用途に強い	混在。購入者のガバナンス要件を確認する

1対複数の比較例：

領域	MyCompany の見解	状況	主な圧力
購入者にとってのシンプルさ	購入者が責任の所在が明確な単一のプラットフォームを重視する場合に強い	Competitor Beta からの圧力	部門内の限定的な用途では、Competitor Beta のほうがシンプルに見える可能性がある

6. 成果物を作成して検証する

• デフォルトの出力は、インライン CSS を含み、外部アセットを使わない、自己完結型の UTF-8 HTML ブリーフとし、その後、簡潔なチャット要約を提示します。ユーザーがチャット、プレーンテキスト、または Markdown のみを明示的に求めた場合は、HTML を使わず、同じ内容をチャットで提示します。
• ユーザーが保存先を指定した場合は、その保存先を使用します。指定がなければ、現在のワークスペースに sanitized-seller-compintel-date.html ファイルを作成します。ワークスペース内のファイルが適切でない場合は、安全な一時ディレクトリを使用します。ユーザーが確認できる既存ファイルを上書きする前に、許可を求めます。
• ユーザーがブランド規定を提示しない限り、控えめで中立的な、プレゼンテーション資料を思わせるレイアウトにします。会社の配色、ロゴ、製品名、ビジュアルシステムをハードコードしないでください。
• 最上位のセクションまたはタブとして、「概要」「競合」「ガイダンス」「情報源」を含めます。
• 汎用的なツールチップやカードのラベルには、「きっかけ」「ディスカバリー質問」「ポジショニング」「検証済みのシグナル」「競合が優位な点」「販売側が差別化できる点」「これが有効な理由」「根拠」「使用する場面」「注意点／言ってはいけないこと」などがあります。
• 情報源には、クリック可能な出典情報、証拠の限界、使用した依存関係のカテゴリ、利用できなかったカテゴリ、該当しなかったカテゴリを表示します。
• 生成したファイルを読み戻し、必須セクション、出典情報、埋め込みスタイルが含まれていることを確認します。ブラウザーまたは Playwright 系のレンダラーが利用できる場合は、一度レンダリングし、空白ページ、レイアウト崩れ、読みにくいコントラスト、CSS の欠落があれば修正してからリンクを返します。
• クリック可能な成果物リンクを最初に返し、その後に簡潔な要約と、役立つ次のステップの提案を続けます。通常のユーザー向けの文面で HTML の仕組みを説明しないでください。

次のステップの選択肢

最初の出力後、以下の選択肢から最も関連性の高いフォローアップを提案します。選択肢を並べるのではなく、明確な次のステップを1つ提案してください。別の選択肢のほうが明らかに有用だと確信できる場合を除き、以下のみを提案してください。

• 確認済みの商談証拠と防御的な準備を切り分けた、アカウント固有のオーバーレイを追加する。
• 目の前の販売担当者のニーズに合わせて、異議対応のみ、またはポジショニングのみのバージョンを作成する。
• 競争上のリスクとディスカバリー質問を用いた、会議用ブリーフを作成する。
• 簡潔な社内向けイネーブルメント情報またはアカウントチーム向け更新を作成し、レビューに回す。
• 同じ競合、製品、カテゴリ、またはアカウントの範囲で、この build-competitive-brief スキルを再実行する対応する週次自動化がすでにあるか確認する。なければ、販売担当者が繰り返し使える競合ダイジェストを提供する自動化の作成を提案する。
• 競争上の証拠に残る、最も小さいながら重要な不足を解消する。

避けるべき次のステップ：

• 裏付けのない競合に関する主張を送信、投稿したり、顧客向けの断定的な説明にしたりすること。

自動化の提案に関するガードレール

競合、カテゴリ、製品、またはアカウントに固有の継続的な競合調査スコープでは、単発のバトルカードよりも繰り返し利用できる営業現場向けのインテリジェンスが役立つ場合、週次の競合ダイジェストを自動化の提案として優先します。価値は営業向けの表現で伝えます。競争環境で何が変わったのか、買い手がそれを気にする理由、売り手が差別化できるポイント、伝えるべきこと、確認すべきこと、過度な主張を避けるべき点を示します。

自動化では、別個のカスタム調査ダイジェストではなく、このスキルをスケジュールに従って再実行する必要があります。自動化を作成または説明する際は、プロンプトからこのスキルを直接呼び出し、同じ競合調査スコープとモードを維持するようにします。

Use the Sales `build-competitive-brief` skill.
Rerun it weekly for the same competitive scope: [competitor, product, workflow, category, segment, region, or account].
Return the standard competitive brief output, including source posture and landmines.

seller_company_name: "[seller company when known]"
product_scope: "[same product scope]"
workflow_scope: "[same workflow or buyer problem]"
competitor_scope: "[same competitor category or market category]"
competitor_names: [same named competitors when used]
account_name: "[same account when account-specific]"
mode: "[brief, objections, positioning, or account_overlay]"
known_objections: [same recurring objections when used]

スキルによって競合他社が特定される幅広いカテゴリまたは製品のスコープでは、安定したスコープを平易な言葉でプロンプトに記載し、通常の比較対象に関するガイダンスに従って、このスキルに有力な競合他社を特定させます。狭い範囲の単発の反論、特定の会議に向けた準備、または証拠が乏しい場合には、ユーザーが継続的な競合ウォッチを明確に希望していない限り、この自動化を提案しないでください。

定期的な出力は、このスキルの競合ブリーフの要件に従う必要があります。具体的には、背景、売り手側の基準、競争環境の概要、競合他社の概要、比較から得られる要点、対応戦略、過度な主張を避けるべき点、情報源を含めます。読み取り専用にしてください。トークトラック、ディスカバリー質問、証拠、レビュー用の社内更新を提案してもかまいませんが、ユーザーが別途依頼して承認しない限り、投稿、送信、共有したり、根拠のない競合他社に関する主張を顧客向けの断定的な表現に変えたりしてはいけません。

週次の競合ダイジェストを提案する前に、ユーザーが一致するローカル自動化をすでにインストールしていないか確認してください。$CODEX_HOME/automations/*/automation.toml 内のローカル自動化レコードを調べます。CODEX_HOME が設定されていない場合は、~/.codex/automations/*/automation.toml を調べます。名前、プロンプト、スキル名、頻度、競合他社、製品、カテゴリ、セグメント、アカウント、モード、既知の反論、その他の安定したスコープの詳細を照合してください。有効な一致と一時停止中の一致は、どちらもインストール済みとして扱います。

• 一致する自動化がある場合は、別の自動化の作成を提案しないでください。次に関連性の高い、自動化以外のフォローアップに進みます。
• 一致する自動化がない場合は、同じスコープでbuild-competitive-briefを毎週再実行する自動化を確認・作成することを、明確な提案として最後に一つだけ示します。定期的な出力は、何が変わったのか、なぜ重要なのか、何を伝えるのか、どの証拠を使うのか、どの落とし穴を避けるのかを含む、営業担当者向けの競合ダイジェストとして説明します。ユーザーが明示的に同意するまでは、自動化を作成または更新しないでください。
• 自動化機能を利用できない場合は、ツールの詳細には触れず、自動化が利用可能になった際に、定期的な競合ダイジェストの設定を支援できると提案してください。

モード

• brief — デフォルト。標準の競合ブリーフ、比較表、対応ガイダンス、情報源
• objections — 買い手の反論、証拠、ディスカバリー質問、トークトラック、言ってはいけないことに関するガイダンス
• positioning — 比較の切り口、注意すべき領域、差別化要因、対応戦略
• account_overlay — アカウント固有の影響。確認済みの商談情報と防御的な準備を明確に分ける
• chat_or_markdown_only — 明示的に依頼された場合に限り、HTML成果物なしで同じ証拠要件に従う

出力形式

HTML成果物とMarkdownのみの代替出力では、次の内容要件を維持してください。

# [Seller] Competitive Brief

## Context
[Scope, buyer/account context, mode, and evidence posture]

## Seller Baseline
[Seller positioning and relevant proof]

## Competitive Landscape Summary
[What matters most and why]

## Competitor Snapshot
### [Competitor]
- **What they claim:** [Grounded claim]
- **What is confirmed:** [Evidence-backed fact]
- **Why buyers may care:** [Buyer appeal]
- **Where they win:** [Supported strength]
- **Where we can separate:** [Supported response]
- **Landmine / do not say:** [Overclaim to avoid]

## Comparison Matrix Takeaways
[Matrix plus the few implications that change seller behavior]

## Response Strategy
- **Say:** [Talk track]
- **Clarify:** [Discovery question]
- **Prove:** [Evidence]

## What Not To Overclaim
- [Uncertainty, conflict, or unsupported claim]

## Sources
- [Clickable source + what it supported]
- [Dependency category status and material gaps]

{Follow the instructions and output format/conditions in [Limitations and Improvements](../index/SKILL.md#limitations-and-improvements)}

{Follow the instructions and output format/conditions in [Next Steps](../index/SKILL.md#4-next-steps)}

account_overlayでは「アカウントへの影響」を追加し、根拠のない競合他社の参入情報には「防御的な準備」とラベルを付けます。

プロンプト例

• MyCompanyとCompetitor Alphaの競合ブリーフを作成してください。
• 金融サービス業界における、MyCompany対Competitor AlphaおよびCompetitor Betaのバトルカードを作成してください。
• 規制対象の買い手向けに、MyCompanyのエンタープライズワークフロープラットフォームと有力な代替製品3つを比較してください。
• Competitor Alphaが商談に参加している可能性があるExampleCorp向けに、アカウント固有の防御的な準備ブリーフを作成してください。
• MyCompanyとCompetitor Alphaの共有可能なHTML競合ブリーフを作成してください。

ルール

• 競合他社の機能、価格、顧客の実績、アカウントの状況、情報源へのリンクを決して捏造しないでください。
• 事実、現場から得た情報、推論を明確に分けてください。
• 証拠が少ない場合は、概要の範囲を絞り、内容を改善するために必要な最小限の証拠を挙げてください。
• ユーザーが後から、別途サポートされているアクションを明示的に依頼しない限り、このワークフローから投稿、送信、共有、システムの更新を行わないでください。
• 情報源で裏付けられた重要な主張には、役立つリンクがある場合、必ずハイパーリンクを付けてください。