competitive-intel-watch

競合インテリジェンス・ウォッチ

目的

前回の実行以降に起きた重要な変化を競合状況から見つけます。前回のスナップショットと現在の状況を比較し、変化した点だけを根拠とともに報告して、更新が必要な下流の成果物にフラグを立てます。このスキルは、競合調査を文書から定期的な運用へと変えるものです。融合サイクルにおける週次の SIGINT 調査と月次の OSINT ダイジェストは、ここで扱います。ウォッチが報告するのは変化であり、現状ではありません。同じレポートを毎週作り直すのは見せかけにすぎず、「今サイクルに重要な変化はありませんでした」という結果にも価値があります。

入力

最も効果を発揮する入力： 前回の競合調査スナップショット（貼り付けまたは添付）。今回の実行で比較する基準となります。また、競合他社のリストも指定できます（デフォルトではスナップショットに記載された競合他社を使います）。 ほかに役立つ情報： 今サイクルで特に注目したい項目と、デフォルトの重要性の基準を厳しく、または緩くする必要がある場合の調整内容。

呼び出し時にインラインで渡された入力（スキル名の後に続くテキスト、貼り付けられたコンテキストのダンプ、または追記された ARGUMENTS: 行）は、すでに回答済みの情報として扱います。質問数の上限に含めてください。改めて質問しないでください。

何も用意できていなくても問題ありません。 以前のスナップショットがない場合、このスキルはベースラインモードに切り替わります。competitive-research-snapshot の構成を使って初回のスナップショットを作成し、そこで終了します。差分が得られるのは2回目の実行からです。

呼び出し例： 競合インテリジェンス・ウォッチ — 以下に前回のスナップショットを貼り付けます。今サイクルは特に価格の変更を注視します。[snapshot]

主要な概念

• 準拠するプロトコル： autonomous-investigation の契約を遵守します。質問数の上限は2（このスキルで最も厳しい上限）、検索計画のゲート、Fact／Inference／Assumption のラベル、Just Enough Mode、安定したスキーマ、4つの選択肢からなる Final Step が含まれます。
• 規律の組み合わせ： まず SIGINT（サイトの差分、価格ページ、求人情報など、最も鮮度の高い情報層）を確認します。OSINT と HUMINT のシグナルは月次、FININT は四半期ごとの確認で扱います。これらが融合サイクルにおける intelligence-collection-disciplines の運用リズムです。
• 重要性の基準。 営業担当者、価格設定の責任者、またはロードマップの責任者が実際に対応する可能性のある変化だけを報告します。価格設定やパッケージの変更、ローンチや廃止、ポジショニングの変化、経営幹部の異動、資金調達や M&A、大口顧客の獲得や喪失、信頼できるロードマップのシグナルなどが該当します。基準に満たないものとして、サイトの外観上の変更、定例のコンテンツマーケティング、小規模なリリースがあります。重要な理由： 誤報ばかりのウォッチは3サイクル目には無視されます。この基準があるからこそ、読者の関心を保てます。
• 差分を徹底する。 検索を始める前に前回のスナップショットを最後まで読み、そこからの差分を確認します。スナップショットを作り直してはいけません。変更履歴が空であることも、正式な結果の1つです。
• 更新フラグでフィードバックループを閉じる。 調査は、変更対象となる成果物を明示して初めて完了します。重要な変化ごとに、陳腐化した競合比較カード、ポジショニング、価格設定、またはロードマップの各セクションを対応付けます。
• 捏造してはならない項目： 競合他社、機能、価格設定、市場シェア、顧客の獲得実績、ロードマップ項目、製品の主張。変更を報告する場合は、必ず URL と日付を付けます。
• 使用しないケース： ベースラインがなく、詳細な調査が必要な場合は、まず competitive-research-snapshot を実行します。調査範囲そのものが変わった場合（新しいセグメント、ピボット）は、古い範囲との比較ではなく、最初からスナップショットを作成します。

アプリケーション

1. モードを決定します。 前回のスナップショットが提供されている場合は差分モードです。提供されていない場合はベースラインモードです。competitive-research-snapshot スキーマに従ってスナップショットを作成し、終了します。
2. インラインのコンテキストを考慮してから、未回答の質問だけを尋ねます（最大2つ）。
   1. 前回のスナップショットはありますか？それともベースラインを作成しますか？
   2. 今回、特に注目している点はありますか？ 回答がない場合は、そのまま進めます。スナップショットがなければベースラインモード、そうでなければデフォルトの重要度基準を適用します。
3. 検索を始める前に、前回のスナップショットをすべて読みます。 差分の対象は市場に関する記憶ではなく、ドキュメントです。
4. 3項目の検索計画を提示します — 競合ごとに確認する内容、情報源の種類（企業サイト、料金ページ、リリースノート、報道発表、投資家向け資料、信頼できるニュース、レビューサイト、求人情報）、事実と推論の区別方法を示します。変更を求められない限り続行します。
5. 重要度基準に照らして調査し、絞り込みます。 基準を満たすものがなければ、その旨を明確に伝えます。
6. 以下のスキーマを正確に出力します — 実行結果を差分比較できるようにします。

出力スキーマ（順序を変更しないでください）

# Competitive Watch Report

## 1. Run Header
**Scope (from prior snapshot):** | **Prior snapshot date:** | **This run date:** | **Competitors checked:**

## 2. Changelog (Material Shifts Only)
For each material shift:
### [Competitor] — [4 to 8 word change summary]
- **What changed:** [1-2 bullets, labeled Fact/Inference]
- **Evidence:** [URL, date]
- **So what:** [why it clears the materiality bar]
- **Confidence:** [high / medium / low]

If nothing cleared the bar: "No material shifts this cycle." List
anything on the watchlist for next run.

## 3. Update Flags
| Downstream artifact | Sections needing update | Driven by |
|---|---|---|
| Battle card | | |
| Positioning statement | | |
| Pricing/packaging analysis | | |
| Roadmap assumptions | | |
Only rows with real updates; omit the rest.

## 4. Watchlist for Next Run
- [Signals below the bar but trending]
- [Open questions this run could not resolve]

### Assumptions to Validate
- [Assumption 1] / [Assumption 2] / [Assumption 3]

品質チェック付きの、このスキーマのコピー＆ペースト用記入版は template.md にあります。

最終ステップ（選択肢をちょうど4つ提示）

1. 上記でフラグが付いたバトルカードのセクションを更新する（battle-card-builder）
2. 最も重要な変化を詳しく調査する
3. 更新した完全版スナップショット（新しいベースライン）を作成する
4. 次回実行に向けて重要度基準または競合リストを調整する

1、2、3、4、1 and 2、Verbose Mode、またはカスタムパスを受け付けます。スケジュールに基づく無人実行では、レポートを保存して終了します — 選択肢への対応は人間が行います。

例

基準を満たす変更履歴の項目（架空の例）：

Ledgerline — 中価格帯プランが料金ページから削除

• 変更内容： 49ドルの「Team」プランが表示されなくなり、機能リストは上位プランに再配分された — 事実（料金ページとアーカイブ版の比較、7月2日と6月1日）
• 根拠： URLとアーカイブの差分、日付付き
• 影響： 実質的に最安価格が2倍になりました。「より安く始められる」という当社の訴求点は一段と強まり、同社のSMB顧客の解約が急増する可能性があります — 営業と料金設定の両担当者にとって基準を満たします
• 確信度： 高

適切な空の変更履歴：

今回、重要な変化はありません。傾向把握のため、基準未満の動きは記録しました。[Competitor B] がコンプライアンス自動化に関するソートリーダーシップ記事を3件公開しました（ウォッチリスト：同社の製品ページにも反映されれば、ポジショニングの変化の可能性あり）。また、シニアエンジニアの求人情報2件に、同社の技術スタックではこれまで見られなかった言語が記載されていました（ウォッチリスト：意味のある変化と判断するには、TECHINT による裏付けが必要です）。

架空のFSMソフトウェア市場を題材に、competitive-research-snapshot のベースライン例との差分（ベースラインの前提が差分によって確認されたケースを含む）を示した、最初から最後までの実行例は examples/sample.md をご覧ください。四半期ごとに実施する工業分野向けの例は examples/sample-industrial.md をご覧ください。こちらでは、上位のリスクが 格下げ され、それが重要な変化として報告されています。

よくある落とし穴

• 再生成の見せかけ。 実行のたびに新しい完全版レポートを作成し、それをウォッチと呼ぶことです。 読者が知りたいのは「何が変わったのか」です。その点だけに答えてください。
• 重要性の水増し。 生産的に見せるために、ブログ記事や小規模なリリースを報告することです。基準に満たない項目を報告するたびに、本当に必要なアラートの信頼性を損ないます。
• 変更のない変更履歴を恐れること。 静かなサイクルをノイズで埋めることです。実際に調査したうえでの「重要な変更なし」は、健全なウォッチであれば多くのサイクルで出てくる結果です。
• 日付のない根拠。 URLと日付の両方がない変更の主張は、検証できず、次回実行時に差分を確認することもできません。日付も根拠の一部です。
• 古い範囲の差分を確認すること。 市場が方向転換し、新しいセグメントに参入したのに、ウォッチでは古い枠組みとの比較を続けてしまいます。範囲が変わったら基準を設定し直し、実行ヘッダーにその旨を記載してください。
• 対応につながらないインテリジェンス。 更新フラグのない変更履歴です。更新が必要な成果物がないのであれば、その変化はおそらく基準に達していません。調査をアクションにつなげるのが更新フラグです。

参考資料

• autonomous-investigation（ワークフロー） — 全体を統制するプロトコル
• intelligence-collection-disciplines（コンポーネント） — このウォッチの基盤となる情報統合のサイクル
• competitive-research-snapshot（ワークフロー） — このスキルが差分を確認する基準を作成
• battle-card-builder（ワークフロー） — 更新フラグを利用
• pestel-analysis（コンポーネント） — 競合レベルのこのウォッチに対応するマクロ環境分析
• https://github.com/deanpeters/product-manager-prompts リポジトリの market-intelligence/competitive-intel-watch-prompt.md を基にしています。