競合インテリジェンスツールは、候補全社を同じ条件で検証する

2026年9月に確認した英語のチェックリストは、競合インテリジェンス（CI）プログラムが追うべき項目の一覧（1upのCIチェックリスト、RivalBeamのPMM向けチェックリスト）か、ソフトウェア全般のPoCの進め方（Worthwhileの「PoC成功の9つの鍵」）のどちらかでした。Worthwhileの進め方は転用できます。課題を定義し、測れる結果を決め、実データで確かめ、事前に決めた基準で評価する流れです。ただし、確認した3記事は、このPoCの進め方をCIの情報源と作業に当てはめていません。

競合、期間、情報源を最初に固定する

すでに追っている競合から、変化のパターンが異なる対象を含む最小のセットを選びます。開始日と終了日は、各ベンダーと事前に合意したうえで、全ベンダーで揃えます。競合の変化を予定することはできません。期間中に重要な変化が起きなければ、モニタリングの結果は「未観測」と記録します。

次に、ツールに渡せる情報源を一覧にします。競合の特定ページ、レビューサイト、料金ページ、ニュース、通話記録やCRMのメモなどの社内資料です。非公開の情報源については、会社の方針、適用される契約や法令に基づき、このベンダー利用を承認できる役割または手続を記録します。顧客、本人同意、録音に関する制限があれば、それも明記します。それとは別に、ベンダーとの契約がデータの保存や別用途での利用を認めるか、保存期間、再委託先も記録します。これらを確認できない情報源は除外してください。読める範囲と必要な許可はベンダーごとに違うため、情報源の一覧そのものが検証項目です。ツールが届かない情報源は、結果として記録します。

検証条件、情報源の一覧、採点表は、PMM業務向けに設定したClaudeのプロジェクトにまとめておくと、各社の出力を同じ基準の隣に置けます。Anthropicのプロジェクトの説明では、ファイルをナレッジとして追加し、プロジェクト指示を設定できると説明されています。共有ドキュメントでも構いません。最初の検証より前に、検証条件が一か所にそろっていれば十分です。

全ベンダーに同じ3つの作業を与える

モニタリングの通知を1件。 対象の競合と、自社にとって意味のある変化の種類（料金の変更、新しい連携ページなど）を指定します。採点するのは通知そのものです。届いた時刻、内容、変更されたページへのリンクの有無を見ます。

バトルカードの1項目。 営業が今よく受ける反論を1つ選び、全社の検証で同じ競合について作らせます。採点するのは、生成された項目と添えられた出典です。

ダイジェストを1本。 その競合について期間中の要約を各ツールに求め、営業担当や経営層が受け取る形のまま、ベンダーが提案するチャネルで受け取ります。

3つの依頼文は一度だけ書き、各社の検証に変えずに貼り付けます。ベンダーが自社の強みを示す4つ目の作業を提案してきたら、全社に追加するか、採用しないかのどちらかです。

出力が存在する前に、必要な根拠を決める

作業ごとに、出力が有効と認められる条件を書きます。3つに共通して勧めるのは、出典ページへのリンク、情報源を読んだ日付、そのページと照合できる文言です。出典のないバトルカードの主張は、文章の出来にかかわらず不合格です。どのページを要約したかを示さないダイジェストは検証できません。

そのうえで、CIツールが静かに失敗する形を挙げておきます。デモでは見えない部分です。

• 古い主張の引き継ぎ。競合が機能を廃止したり価格を変えたりしたのに、カードには以前の内容が残っている。
• 実際の変化の見落とし。期間中に監視対象ページが変わったのに、通知が届かない。人がページを確認していなければ気づけないため、後述の対照作業が必要です。
• 主張を裏づけない出典。リンクは存在し、ページも開けるが、隣の文はそのページに書かれていないことを述べている。

失敗の形ごとに、ベンダーごとの確認担当を1人決めます。見落としの確認には最も時間がかかるため、担当者が期間中に監視対象ページを開く頻度も検証条件に書き込んでください。

合否の選定基準を文書で合意する

最初の検証の前に選定基準を書き、購入を承認する人の合意を取ります。すべてのベンダーを同じ条件で評価できるよう、基準は固定してください。重みを使う場合も、結果を見る前に決めます。

• モニタリングの通知が、実際の変化から合意した時間内に、合意したチャネルへ届き、変更されたページにリンクしていた。
• バトルカードの項目は事実の主張ごとに出典を示し、各出典ページが隣の文を裏づけている。
• ダイジェストは要約した情報源をすべて明記し、読み手がそれぞれを開ける。
• 許可一覧の情報源すべてにツールが到達できた。または、到達できないものと理由をベンダーが書面で示した。
• 3つの静かな失敗がいずれも起きなかった。または、確認担当が見つける前にツール側が開示した。
• 検証に参加していない営業担当が、質問せずにバトルカードの項目を使えた。
• ベンダーごとに、人が行った初期設定の時間を記録した。

各項目を合格か不合格で採点し、根拠を一文添えます。不合格の項目があるベンダーを選んでも構いませんが、どの項目が不合格で、なぜ許容したかを決定の記録に残します。

同じ条件で、自社での対照作業を行う

ベンダーの検証の前か並行して、同じ3つの作業を自社で行います。監視対象ページを決めた頻度で確認し、見つけた内容からバトルカードの項目を書き、ダイジェストを手作業かClaudeで作ります。競合調査計画の立て方、競合の変化を通知する方法、競合ダイジェストの作り方で、ベンダーなしでの各作業を扱っています。

対照作業を行うと、期間中に実際に何が変わったかが分かり、ツールの見落としを判断する直接の手がかりになります。手作業の工数も分かるので、導入の判断を、導入しない場合の作業と比べて下せます。

全社の出力を同一の基準で採点する

1. 各社の出力を、日付と作業名を付けてプロジェクトに貼り付ける

   通知の本文、バトルカードの項目、ダイジェストを、届いた形のまま出典も含めて貼り付けます。転記で失われた出典は、ベンダーの責任ではない不合格になります。

2. 選定基準の一覧に照らした採点をClaudeに依頼する

   項目ごとに合否と、判断の根拠となる出力中の文を返してもらいます。不合格はすべて読み、引用されたページを自分で開きます。この貼り付け式の方法で主張と引用箇所を照合させるには、両方を渡します。

3. 失敗の形を対照作業の記録と突き合わせる

   各社の通知を、対照作業で記録した変化と比べます。対照作業で見つかり、ベンダーが通知しなかった変化は見落としです。ページと日付を添えて記録します。

4. ベンダーと作業ごとに1行ずつ書き、決定する

   ベンダーごとに、選定基準の結果、出力の根拠、初期設定の時間を要約した簡潔な採点表を作ります。根拠を残すのに必要なら、ページ数は増やしてください。採点表は契約更新時の比較の基準として保管します。

検証で裏づけの取れた主張は、選んだツールにかかわらず、出典と日付を付けて競合の主張台帳に移せます。2社が同点なら、検証では測れない継続的な作業量を内製か導入かの判断で比べてください。

Steveを候補に加える場合は、ベンダーにデモを依頼し、同じ検証条件、採点基準、対照作業を持ち込んでください。Steveの競合リサーチの製品ページは対象とする製品領域を説明しています。