# 競合インテリジェンスツールは、候補全社を同じ条件で検証する 候補全社を同じ競合セット、期間、作業、根拠の条件、正式に許可された情報源で試し、開始前に選定基準を合意します。 URL: https://www.hiresteve.ai/ja/blog/competitive-intelligence-pilot 最終更新: 2026-10-12 検証を始める前に検証条件を一つ書き、候補全社に対してその内容をそのまま実行します。競合のセット、期間、作業、そして出力を見る前に合意した合否の選定基準を揃えます。デモで分かるのはベンダーが見せたい場面です。この手順の検証なら、自社の競合と情報源に対して各ツールが何をするかを比較し、導入判断の材料にできます。 2026年9月に確認した英語のチェックリストは、競合インテリジェンス（CI）プログラムが追うべき項目の一覧（[1upのCIチェックリスト](https://1up.ai/blog/competitive-intelligence-checklist/)、[RivalBeamのPMM向けチェックリスト](https://rivalbeam.com/blog/pmm-competitive-intelligence-checklist)）か、ソフトウェア全般のPoCの進め方（[Worthwhileの「PoC成功の9つの鍵」](https://www.worthwhile.com/blog-posts/9-essential-keys-for-a-successful-proof-of-concept-evaluation)）のどちらかでした。Worthwhileの進め方は転用できます。課題を定義し、測れる結果を決め、実データで確かめ、事前に決めた基準で評価する流れです。ただし、確認した3記事は、このPoCの進め方をCIの情報源と作業に当てはめていません。 ## 競合、期間、情報源を最初に固定する すでに追っている競合から、変化のパターンが異なる対象を含む最小のセットを選びます。開始日と終了日は、各ベンダーと事前に合意したうえで、全ベンダーで揃えます。競合の変化を予定することはできません。期間中に重要な変化が起きなければ、モニタリングの結果は「未観測」と記録します。 次に、ツールに渡せる情報源を一覧にします。競合の特定ページ、レビューサイト、料金ページ、ニュース、通話記録やCRMのメモなどの社内資料です。非公開の情報源については、会社の方針、適用される契約や法令に基づき、このベンダー利用を承認できる役割または手続を記録します。顧客、本人同意、録音に関する制限があれば、それも明記します。それとは別に、ベンダーとの契約がデータの保存や別用途での利用を認めるか、保存期間、再委託先も記録します。これらを確認できない情報源は除外してください。読める範囲と必要な許可はベンダーごとに違うため、情報源の一覧そのものが検証項目です。ツールが届かない情報源は、結果として記録します。 検証条件、情報源の一覧、採点表は、[PMM業務向けに設定したClaudeのプロジェクト](/ja/blog/claude-project-setup)にまとめておくと、各社の出力を同じ基準の隣に置けます。Anthropicの[プロジェクトの説明](https://support.claude.com/ja/articles/9517075-プロジェクトとは何ですか)では、ファイルをナレッジとして追加し、プロジェクト指示を設定できると説明されています。共有ドキュメントでも構いません。最初の検証より前に、検証条件が一か所にそろっていれば十分です。 ## 全ベンダーに同じ3つの作業を与える **モニタリングの通知を1件。** 対象の競合と、自社にとって意味のある変化の種類（料金の変更、新しい連携ページなど）を指定します。採点するのは通知そのものです。届いた時刻、内容、変更されたページへのリンクの有無を見ます。 **バトルカードの1項目。** 営業が今よく受ける反論を1つ選び、全社の検証で同じ競合について作らせます。採点するのは、生成された項目と添えられた出典です。 **ダイジェストを1本。** その競合について期間中の要約を各ツールに求め、営業担当や経営層が受け取る形のまま、ベンダーが提案するチャネルで受け取ります。 3つの依頼文は一度だけ書き、各社の検証に変えずに貼り付けます。ベンダーが自社の強みを示す4つ目の作業を提案してきたら、全社に追加するか、採用しないかのどちらかです。 ## 出力が存在する前に、必要な根拠を決める 作業ごとに、出力が有効と認められる条件を書きます。3つに共通して勧めるのは、出典ページへのリンク、情報源を読んだ日付、そのページと照合できる文言です。出典のないバトルカードの主張は、文章の出来にかかわらず不合格です。どのページを要約したかを示さないダイジェストは検証できません。 そのうえで、CIツールが静かに失敗する形を挙げておきます。デモでは見えない部分です。 - 古い主張の引き継ぎ。競合が機能を廃止したり価格を変えたりしたのに、カードには以前の内容が残っている。 - 実際の変化の見落とし。期間中に監視対象ページが変わったのに、通知が届かない。人がページを確認していなければ気づけないため、後述の対照作業が必要です。 - 主張を裏づけない出典。リンクは存在し、ページも開けるが、隣の文はそのページに書かれていないことを述べている。 失敗の形ごとに、ベンダーごとの確認担当を1人決めます。見落としの確認には最も時間がかかるため、担当者が期間中に監視対象ページを開く頻度も検証条件に書き込んでください。 **Claudeは貼り付けた出力だけを採点します** Claudeは検証条件を採点表に変換し、貼り付けられた出力を基準に照らして評価できます。この貼り付け式のプロジェクトは、ベンダーの製品にログインしたり、連携を試したりしません。Coworkのブラウザ操作やPC操作を許可する場合は、実際に観測した内容を記録したうえで、情報源の対応範囲とセキュリティの根拠は人が確認します。 ## 合否の選定基準を文書で合意する 最初の検証の前に選定基準を書き、購入を承認する人の合意を取ります。すべてのベンダーを同じ条件で評価できるよう、基準は固定してください。重みを使う場合も、結果を見る前に決めます。 - モニタリングの通知が、実際の変化から合意した時間内に、合意したチャネルへ届き、変更されたページにリンクしていた。 - バトルカードの項目は事実の主張ごとに出典を示し、各出典ページが隣の文を裏づけている。 - ダイジェストは要約した情報源をすべて明記し、読み手がそれぞれを開ける。 - 許可一覧の情報源すべてにツールが到達できた。または、到達できないものと理由をベンダーが書面で示した。 - 3つの静かな失敗がいずれも起きなかった。または、確認担当が見つける前にツール側が開示した。 - 検証に参加していない営業担当が、質問せずにバトルカードの項目を使えた。 - ベンダーごとに、人が行った初期設定の時間を記録した。 各項目を合格か不合格で採点し、根拠を一文添えます。不合格の項目があるベンダーを選んでも構いませんが、どの項目が不合格で、なぜ許容したかを決定の記録に残します。 ## 同じ条件で、自社での対照作業を行う ベンダーの検証の前か並行して、同じ3つの作業を自社で行います。監視対象ページを決めた頻度で確認し、見つけた内容からバトルカードの項目を書き、ダイジェストを手作業かClaudeで作ります。[競合調査計画の立て方](/ja/blog/competitive-research-plan)、[競合の変化を通知する方法](/ja/blog/competitor-alerts)、[競合ダイジェストの作り方](/ja/blog/competitor-digest)で、ベンダーなしでの各作業を扱っています。 対照作業を行うと、期間中に実際に何が変わったかが分かり、ツールの見落としを判断する直接の手がかりになります。手作業の工数も分かるので、導入の判断を、導入しない場合の作業と比べて下せます。 ## 全社の出力を同一の基準で採点する **各社の出力を、日付と作業名を付けてプロジェクトに貼り付ける** 通知の本文、バトルカードの項目、ダイジェストを、届いた形のまま出典も含めて貼り付けます。転記で失われた出典は、ベンダーの責任ではない不合格になります。 **選定基準の一覧に照らした採点をClaudeに依頼する** 項目ごとに合否と、判断の根拠となる出力中の文を返してもらいます。不合格はすべて読み、引用されたページを自分で開きます。この貼り付け式の方法で主張と引用箇所を照合させるには、両方を渡します。 **失敗の形を対照作業の記録と突き合わせる** 各社の通知を、対照作業で記録した変化と比べます。対照作業で見つかり、ベンダーが通知しなかった変化は見落としです。ページと日付を添えて記録します。 **ベンダーと作業ごとに1行ずつ書き、決定する** ベンダーごとに、選定基準の結果、出力の根拠、初期設定の時間を要約した簡潔な採点表を作ります。根拠を残すのに必要なら、ページ数は増やしてください。採点表は契約更新時の比較の基準として保管します。 検証で裏づけの取れた主張は、選んだツールにかかわらず、出典と日付を付けて[競合の主張台帳](/ja/blog/competitive-claim-ledger)に移せます。2社が同点なら、検証では測れない継続的な作業量を[内製か導入かの判断](/ja/blog/build-vs-buy-competitive-intelligence)で比べてください。 Steveを候補に加える場合は、ベンダーにデモを依頼し、同じ検証条件、採点基準、対照作業を持ち込んでください。[Steveの競合リサーチの製品ページ](/ja/products/research)は対象とする製品領域を説明しています。 ## よくある質問 ### 検証の期間はどのくらい必要ですか？ 全ベンダーと事前に合意したうえで、同一の期間を設定します。期間中に重要な変化が起きなければ、結果を作らず、通知の検証は「未観測」と記録します。初期設定、情報源の対応範囲、バトルカードの出力は評価できます。 ### 対象にする競合は何社にすべきですか？ 変化のパターンが異なる競合を含む最小の共通セットにし、全ベンダーに同じ対象を与えます。検証に必要なのは、選んだ作業を試せる違いであり、恣意的な社数ではありません。 ### Claudeにベンダー検証を任せられますか？ この貼り付け式の方法では、人が各ベンダーの製品を操作し、観測した出力を渡します。許可されたCoworkのブラウザ操作やPC操作でサイトを扱える場合でも、それだけで情報源の対応範囲、連携、セキュリティ上の主張を証明できるわけではありません。 ### ベンダーから自社製品に合わせた条件変更を求められたら？ 条件は変えず、要望を記録します。作業の追加は可能ですが、その場合は全ベンダーに同じ作業を追加します。会社ごとに条件を変えると、デモが3回増えるだけで、検証を行う意味がなくなります。