競合インテリジェンス

競合ダイジェストは変更ごとに示唆・未確認事項・担当者を一行で書く

検証済みの競合の変更を、意思決定に使える週次の更新にまとめる方法。事実、示唆、未確認事項、担当者を一行ずつ書き、示唆の下書きにClaudeを使います。

Steve最終更新

競合ダイジェストは、その週に検証した競合の変更を、判断できる形にまとめた短い更新です。変更ごとに一行を書き、出典付きの事実、自社の商談やロードマップへの示唆、未確認の点、次に動く担当者の四つを入れます。示唆の文章はClaudeに下書きさせ、検証と担当者の決定は自分で行います。

検証済みの変更から始める

入力になるのは、自分で開いて日付を記録した変更の一覧です。価格ページの改定、リリースノートの新機能、新しい連携、方向性を示す求人などが対象で、各項目に確認したURLと確認日を添えます。まだ通知の流れをそのまま眺めている段階なら、通知の絞り込みの記事で人が見るべき変更に絞り、ページ変更の記録の記事で日付付きの変更前後を残せます。どちらも前提条件ではありません。一行にリンクと日付を一つずつ書いた手作りの一覧で十分です。

その一覧は、競合の仕事に使っているClaudeプロジェクトに置いておくと、会社の情報や承認済みの訴求を踏まえて下書きできます。このダイジェストでは、検証済みのメモだけを使い、示唆は推測だと明示するようClaudeに指示します。出典の一覧にない事実が加わったら削除してください。

変更ごとに、事実と示唆を分けて一行で書く

一行は二つの文で構成します。最初の文は出典が示していることを、次の文はそれが自社にとって何を意味しそうかを推測として書き、出典の内容がどこで終わり自分の解釈がどこから始まるかを読み手が判断できるようにします。国内の競合分析レポートの解説でも、事実と考察を分けて書くことが勧められています。

次の表は、架空の競合名を使った練習用の例で、二種類の文を並べて見せるためのものです。

事実(出典から)示唆(自社の推測)
Acmeの価格ページに、従来の最下位プランより安いセルフサーブのプランが追加された(9月12日確認)。価格で勝っている小規模チーム向けの商談を狙った動きと考えられ、今四半期の比較検討で営業が遭遇する可能性があります。
Emcaのリリースノートで、Salesforceとの同期機能が発表された(9月11日確認)。営業が大企業向けの検討で使っている反論材料が一つ使えなくなると考えられ、バトルカードの連携の行が古くなっています。

Claudeが役に立つのは、最初の文を確定した後の二つ目の文です。短いプロンプトで、検証済みのメモだけを使うよう制約します。

プロンプト:検証済みの変更ごとに示唆を一文ずつ書く

以下は、私自身が検証した競合の変更の一覧です。各項目に出典と確認日があります。
それぞれの変更について、[自社製品]の[市場]における意味合いを、
「〜と考えられます」または「〜の可能性があります」で終わる一文で書いてください。
事実の言い直しはせず、一覧にない事実を加えず、断定もしないでください。
自社への明確な示唆がない変更には「明確な示唆なし」と書いてください。

出来上がった示唆を、対応する事実と照らして読みます。一覧にない価格、日付、顧客名、機能が示唆に入っていたら削除します。示唆は推測として扱い、出典はダイジェストに入れる前に確認してください。

未確認の点は、示唆に混ぜずに書く

未確認事項とは、示唆の前提になっているのに、出典で確認していないことです。示唆の後ろに独立した文として書きます。「未確認:新プランが日本で販売されるかどうか。」示唆の文の中に含みを持たせて書くと、転送された時点で事実として読まれます。

前週の未確認事項は、誰かが解消するまで残しておきます。黙って消えた未確認事項は、解決したものとして受け取られます。

担当者と次の行動を一人一つ決める(「対応不要」も可)

各行に担当者と次の行動を書き、意図した対応を明確にします。「担当:[営業責任者]、金曜までにEmcaのバトルカードの連携の行を更新。」「今週は対応不要」も有効です。次回の確認に向けた判断の記録になります。

Arcadeの競合分析テンプレート(英語)は、モニタリングの側から同じことを述べています。競合ごとに担当者を決め、通知は具体的な行動につなげる、という考え方です。その行動を書き留める場所がダイジェストです。

Claudeは、渡したチーム情報から担当者を提案できます。ただし、実際の担当は人が確認してください。

残りは末尾の補足欄にまとめる

示唆も行動もない変更は、末尾の「その他の動き」の欄に移し、事実とリンクだけを書きます。本文には次の行動が明記された行だけが残るため、短く保てます。

補足欄が本文より長い状態が続くなら、前段の絞り込みを見直します。これは編集上の確認項目で、計測した基準ではありません。

送る前に確認する

  • 事実の行はすべて、自分で開いた出典と確認日につながっている。
  • 示唆はすべて推測の形で書かれ、一覧にない事実を加えていない。
  • 未確認事項はすべて独立した文で、示唆の中のぼかした表現になっていない。
  • 各行に担当者一人と行動一つがあるか、「今週は対応不要」と書かれている。
  • 補足欄には事実とリンクしかない。

読み手が普段見ている場所に送ります。多くの場合は営業のSlackチャンネルか、短いメールです。送ったダイジェストはプロジェクトにも保存し、翌週に参照できる正確な日付付きの記録を残してください。チャット検索やメモリが有効なら以前の文脈を取得できる場合もありますが、利用可否と範囲は異なり、保存したダイジェストの代わりにはなりません。公式のプロジェクト管理ガイドでは、プロジェクトのナレッジを同じプロジェクト内のチャットで使う仕組みを説明しています。

定期実行にする場合と、それでも残る作業

毎週自分でClaudeを開くことが、この方法の弱点です。Claude Coworkの定期タスク(日本語、2026年9月16日確認)では、タスクを毎時、毎日、毎週、平日のみ、または手動で実行でき、通常のCoworkタスクと同じ連携ツール、スキル、プラグインを使えます。対象は有料プラン(Pro、Max、Team、Enterprise)です。クラウドで利用できる情報源を使うタスクはパソコンの電源が切れていても実行できますが、ローカルのファイルやアプリが必要なタスクはローカルで実行されます。検証済みの変更には必ず出典を付けてください。Claudeは渡したチーム情報から担当者を提案できますが、実際の担当は人が確認します。

手作業の週次まとめでは追いつかなくなったら

情報源の一覧を最新に保ち、再確認を継続できるなら、手作業の方法でも進められます。継続的な作業量の比較には内製と購入の比較の記事を使えます。収集と配信が繰り返し遅れるなら、Steveの競合リサーチ製品も検討対象です。

よくある質問

競合ダイジェストはどのくらいの長さが適切ですか?

変更ごとに一行と末尾の補足欄で構成します。これは短く保つための編集形式で、計測した読了時間ではありません。スクロールが必要になったら、行動が不要な行を補足欄に移すか、入力する変更の絞り込みを見直します。

誰に送るべきですか?

担当者として名前を挙げた人と、価格、ロードマップ、バトルカードを判断する人です。営業のSlackチャンネルなど、普段から読んでいる場所に送ります。短い形を保てば、経営層にも同じものを送れます。

競合の変更の検証をClaudeに任せられますか?

Claudeは渡したメモを扱えます。Web検索が有効なら、指定したURLにアクセスできる場合もあります。ただし、取得したページやメモも、ダイジェストに入れる前に出典と日付を確認してください。

送る頻度はどのくらいが適切ですか?

週次を基本にし、営業チームの会議の周期に合わせることを勧めます。進行中の商談に影響する値下げなど、待てない行動を伴う変更があるときだけ、臨時の連絡を送ります。

あわせて読みたい

記事一覧

Steveの競合インテリジェンスを見る

Steveが競合を追跡し、チームに情報を届ける仕組みをご覧ください。