シグナルベースのセリングが3つのスタックに分岐、Salesforceの6月15日リリース前に

残り13日です。6月15日にSalesforceのSummer 26リリースが一般提供（GA）となるまで、市場にある意味のあるシグナルベースのセリングの動きがすべて3つのプラットフォームのいずれかに集約されます。GTMのテックスタックがインテントデータ、アカウントエンリッチメント、アウトリーチ、パイプライン分析の4社以上の個別ベンダーで動いているなら、その調達モデルはもはや正当化が難しくなっています。今週の問いは、どのベンダーが最も優れているかではありません。3つのバンドルのうち、自チームのレバレッジが実際に存在する場所にどれが最も合致するかです。

過去12週間に実際に起きたこと

2026年3月中旬から6月中旬にかけて、3つの主要なプラットフォームの動きが重なりました。それぞれ単独で見れば製品アップデートです。しかし合わせて見れば、マルチベンダーのシグナルスタックがSales Opsのデフォルトアーキテクチャでなくなった転換点を示しています。

Apollo + Pocus（2026年3月19日）

2026年3月19日、ApolloはApollo PR NewswireリリースによりPocusの買収を発表しました。Apolloはこの取引の時点でARR約2億ドル、プラットフォームで60万以上の企業・200万ユーザーを抱えており、有料顧客は10万社以上です。エンタープライズアカウントの成長は過去12ヶ月で400%を記録しました。

Pocusがもたらしたのは特定の機能です。CRMのシグナル、行動データ、購買シグナルを優先度付きのアカウントビューに集約するレベニューインテリジェンス層です。買収前のPocusの顧客にはAsana、Canva、Monday.comなど、製品主導（PLG）または製品支援型のGTMモーションを運用し、行動シグナルが主要なトリガーとなる企業が含まれていました。PocusはCoatueがシリーズAをリードし、総額4,310万ドルを調達していました。Apolloが買収後に示した方向性は、シグナルのソーシング、アウトリーチ実行、パイプラインインテリジェンスを一つのプラットフォームにまとめた「AIネイティブのGTMオペレーティングシステム」です。

HubSpot Spring 26 スポットライト（2026年4月14日）

2026年4月14日に発表されたHubSpotのSpring 2026スポットライトは、Sales Opsの実務担当者向けの目玉機能としてSmart Deal Progressionを導入しました。Smart Deal Progressionは通話の文字起こしと全ての商談履歴を読み込み、フォローアップメールの下書きとCRMフィールド更新の提案を行います。Prospecting Agentも見込み客開拓のライフサイクル全体をカバーするよう拡張され、HubSpotは業界ベンチマークの2倍の返信率を報告しています。

両機能に対するHubSpotのフレーミングは「コンテキストアドバンテージ」です。次のステップの推奨において、シグナルの幅広さよりも商談固有の深い知識の方が優れているという主張です。これは、アカウントごとのコンテキストの深さではなくシグナルカバレッジの幅広さで訴求するインテントデータベンダーへの直接的なポジショニングです。

Salesforce Summer 26（GA：2026年6月15日）

Salesforceのニュースストーリーによると、Salesforce Summer 26リリースは6月15日に一般提供されます。Sales Ops向けの主要機能には、AgentforceとのCollections（売掛金請求書に予測AIスコアを適用して優先度付けと督促ワークフローを実行）、複雑なパイプラインアクションに対応したマルチエージェントオーケストレーション、商談シグナルをコミュニケーションスレッド内に表示するSlackファーストのセールスワークフロー、そして営業プレイに直接紐付けられたリアルタイムのCDP（Customer Data Platform）アクティベーションが含まれます。

Slackファーストのワークフローは、担当者の主な作業画面がすでにSalesforce UIではなくSlackとなっているSales Opsチームにとって特に重要です。リアルタイムCDPアクティベーションとは、対象アカウントが行動イベントをトリガーした際、夜間バッチ処理ではなく同じセッション内で営業プレイにシグナルをルーティングできることを意味します。

主要データ

• Apolloは2026年3月19日のPocus買収後、60万以上の企業にサービスを提供するARR約2億ドルのプラットフォームです（Apollo PR Newswire）
• HubSpotのProspecting AgentはSpring 2026スポットライト（2026年4月14日）によると業界ベンチマークの2倍の返信率を達成しています
• Salesforce Summer 26は2026年6月15日にGA予定で、マルチエージェントオーケストレーション、Slackファーストのワークフロー、リアルタイムCDPアクティベーションが搭載されます（Salesforce News Stories）

「ベストオブブリードのシグナルスタック」が正当化できなくなった理由

2022年から2024年の大半まで、ベストオブブリードのシグナルスタックは理にかなっていました。BomboraやG2 Buyer Intentのようなインテントベンダーは、CRMベンダーがネイティブで提供できるものよりも精度が高かったです。ZoomInfoやClayのようなエンリッチメントベンダーは、HubSpotやSalesforce内で利用可能な機能を上回る深さを持っていました。GongやChorusのような会話インテリジェンスプラットフォームはCRMの外に存在していました。そこにデータがあったからです。そしてOutreachやSalesloftのようなアウトリーチプラットフォームは独立して動作していました。ネイティブのCRMメールツールが競争力を持っていなかったからです。

Sales Opsチームが5社、6社、時に7社のベンダースタックを構築したのは、単一のプラットフォームが統合を正当化できるほどの面積をカバーしていなかったからです。統合コストは高かったですが、機能のギャップはそれ以上でした。

その計算が2024年後半から変化し始め、2026年6月時点では逆転しています。3つのプラットフォームがそれぞれ、以前はマルチベンダーの組み合わせが必要だったシグナルからアクションまでの面積の約70〜80%をカバーしています。PocusのインテリジェンスレイヤーとのApolloは、サードパーティのインテント、アカウントエンリッチメント、製品利用の行動シグナル、アウトリーチ実行をカバーします。Breeze AI、Smart Deal Progression、Prospecting AgentとのHubSpot Smart CRMは、ファーストパーティの商談コンテキスト、メールレベルのパーソナライゼーション、見込み客開拓の自動化をカバーします。CDP、Agentforce、Slack連携のSalesforceは、エンタープライズグレードのファーストパーティデータアクティベーション、マルチエージェントオーケストレーション、収益全体にわたるワークフロールーティングをカバーします。

3つのうちどれも面積の100%はカバーしていません。しかし、これらのプラットフォームのいずれかと複数ベンダーを組み合わせたスタックとの機能ギャップは、統合のメンテナンス、データ同期の遅延、アトリビューションの複雑さ、そして1ユーザー当たりのコスト積算をもはや正当化できないほど縮小しています。問いはもはや統合するかどうかではありません。どのプラットフォームを中心に統合するかです。

シグナルスタックの判断（4つの問い）

Sales OpsはRevOpsリードと30分でこの監査を実施できます。4つの問いがそれぞれ3つのスタックのいずれかを指し示します。下の表がその適合性を要約しており、各問いの後の説明が表のセルに収まらない細かいニュアンスを補足します。

Q1：現在、最も価値の高いシグナルはどこから来ていますか？

最良のシグナルがサードパーティのインテントプラットフォームやコールドデータエンリッチメントのフィードから来ている場合、Apolloのデータの深さが重力の中心となります。Pocusの行動レイヤーはアカウント調査やエンリッチメントデータの上に乗っており、ファーストパーティのCRM履歴ではなくそのデータに価値を加えるからです。

最良のシグナルがCRM履歴、クローズドディールのパターン、製品全体の顧客行動から来ている場合、HubSpot Smart CRMの「コンテキストアドバンテージ」というフレーミングは的確です。Smart Deal Progressionはその履歴を読み込んで実行します。シグナルをインポートするのではなく、すでに持っているものを増幅させます。

最良のシグナルがファーストパーティのCDPを通じてルーティングされ、Slackベースのワークフローに紐付いているか、すでにSalesforceの契約下で複数のクラウドプラットフォームにまたがっている場合、SalesforceのCDPとAgentforceのループが適合します。

Q2：現在、シグナルからアクションまでのループを誰が担っていますか？

Apolloの実行モデルはアウトリーチファーストです。Sales Opsがシグナルからシーケンスへのワークフローの中心的な担い手であり、チームがプラットフォームから直接シーケンスを実行している場合、Apolloのモデルが適合します。HubSpotのマーケティングからセールスへのハンドオフモデルは、Marketing Opsがリードとアカウントのジャーニーの共同オーナーである場合に最も機能します。Smart Deal ProgressionとProspecting Agentはどちらもそのハンドオフの境界に位置しているからです。Salesforceは、RevOpsが両機能をまたいでマーケティング、セールス、カスタマーサクセスのデータ全体で単一の信頼できる情報源を必要とする場合のプラットフォームの選択肢です。

Q3：データの保管場所とガバナンスの制約は何ですか？

Apolloのモデルはコールドデータとメールリスト型のソーシングを中心とし、明確に区分されたデータ境界を持ちます。法務チームがサードパーティのインテントデータ利用を承認しており、GDPR規制の厳しい環境でない場合、Apolloのデータモデルは運用上クリーンです。ファーストパーティのみで運用しているか、厳格なGDPR要件下で運用している場合、HubSpotまたはSalesforceがより安全な選択肢です。入力データと処理チェーンを自社でコントロールできるからです。

Q4：更新の窓はいつ開きますか？

この問いは、監査を理論的なものではなく緊急性のあるものにするタイミングのプレッシャーを加えます。SalesforceまたはHubSpotの更新が今後90日以内に迫っているなら、Summer 26とSpring 26の機能ロードマップは今や調達の根拠です。署名する前に新機能を評価できます。6月15日以降にSummer 26のリリースノートを読むのは、ほとんどのH2更新サイクルではすでに契約が締結された後に待つことになります。

Apolloの契約が開く場合、Pocusの統合タイムラインが機能リスト以上に重要です。Apolloのチームに具体的に確認してください：Pocusのどの機能が現在製品に組み込まれていて、どれが6〜12ヶ月のロードマップ上にあるのか、と。買収は3月19日にクロージングしており、取引後の最初の四半期にすべてのPocus機能がリリースされるわけではありません。

Sales Opsが失敗するパターン

誤ったスタックを選択することは単なる機能の選択ミスではありません。数ヶ月にわたって積み重なるシグナルの負債を生み出します。

ファーストパーティのCRM行動が最も価値の高いシグナルである時にApollo + Pocusを選ぶ場合。 Apolloの強みはサードパーティのデータの深さとコールドからウォームへのエンリッチメントです。担当者の最も実行可能なシグナルが商談履歴、顧客エンゲージメントパターン、CRM内のクローズドウォン分析から来ている場合、ApolloのPocusレイヤーは製品利用の行動シグナルを追加しますが、自社の商談履歴からのシグナルではありません。チームが実際に信頼するシグナル源と並行して動くデータレイヤーに費用を支払うことになり、CRM由来のシグナルに基づいて行動するための別のツールが依然として必要です。

Salesforceが運用に深く組み込まれたエンタープライズ規模の企業でHubSpotを選ぶ場合。 HubSpotのコンテキストアドバンテージはCRMがHubSpot自体である時に有効です。Salesforceをシステムオブレコードとして運用しながら、その上にHubSpotのAI機能を追加しようとすると、アカウントデータの2つ目の信頼できる情報源を導入することになります。Smart Deal ProgressionはHubSpotの商談履歴を読み込むものであり、Salesforceのものではありません。2つのCRMにわたってデータモデルが断片化されると、ハンドオフモデルは機能しなくなります。これは数年前にマーケティング側でHubSpotを追加し、今Sales Opsへ全移行なしに拡張しようとしている企業で最も多く見られる失敗です。

6月15日のGA初日にマルチエージェントオーケストレーションの準備ができていないのにSalesforceを選ぶ場合。 Summer 26のマルチエージェントオーケストレーション機能は本物であり重要ですが、本番の営業プレイで実行する前に設定、テスト、ガバナンスが必要です。Agentforceを検証なしにライブのpipeline管理に組み込んだチームは、実際にクロージング中の商談に自動化エラーを持ち込むことになります。Salesforceの顧客にとって適切な対応は、Q3はサンドボックスでSummer 26機能を実行し、まず影響の小さいワークフローで検証してから、Q4にメインのpipeline作業へ展開することです。詳細なシーケンスガイドはSalesforce Summer 26マルチエージェントオーケストレーション監査をご参照ください。

今週すべきこと

アクション1：6月15日前にRevOpsリードと4つの問いの監査を実施する。 このステップは更新が差し迫っていなくても必要です。GAの機能が顧客の手に渡ってしまうと、監査の問いは陳腐化します。競合他社のSales Opsチームが今まさに同じ分析を行っているからです。6月15日前にスタックの方針を決めておくことで、すでに動いてしまった市場に反応するのではなく、現在のレバレッジで交渉できます。このようなスタック統合の問いに直接適用できる分析的な基礎の構築については、AIセールスオペレーションのbuy vs. buildフレームワークが参考になります。

アクション2：現在のシグナルベンダーの請求書リストを抽出し、各ベンダーをソースタイプで分類する。 インテントシグナル（サードパーティの行動シグナルまたは検索ベース）、エンリッチメント（企業・コンタクトデータ）、ファーストパーティCRM由来（商談履歴、エンゲージメント、製品利用）、アウトリーチ実行の4カテゴリーを使ってください。カテゴリーの内訳が、3つのスタックのうちすでに自社の実際のデータ状況に最も近いものを教えてくれます。請求額の60%がサードパーティのインテントとエンリッチメントに向かっているなら、Apolloが重力の中心です。60%が自社のCRMデータを読み込んで実行するツールに向かっているなら、HubSpotまたはSalesforceです。シグナルソースの信頼性と実行可能性によって分類するフレームワークはバイヤーインテントシグナルの合成をご覧ください。また、2026年のAIセールスオペレーションベンダーランドスケープもカテゴリー全体の現在のポジショニングについて参考になります。

アクション3：SalesforceまたはHubSpotの更新が今後90日以内に迫っているなら、Summer 26とSpring 26の機能ロードマップを製品ニュースとしてではなく調達の根拠として扱う。 更新担当者はあなたが機能発表を見たことを知っています。確認すべき問いは、シグナルスタックのユースケースに関連する特定機能の実装タイムラインがどのようなものかです。6月15日のGA日付は、6月16日に自社スタックで本番稼動できることを意味しません。署名前に現実的なアクティベーションタイムラインを書面で入手してください。RevOpsツールとテックスタックのプレイブックはその交渉で提起すべき契約と評価の問いを網羅しています。

関連記事

• Salesforce Summer 26マルチエージェントオーケストレーション：Sales Ops監査：Summer 26のAgentforce機能とSales Opsチームのシーケンスの問いの詳細監査。
• HubSpotカスタマーエージェント、解決率70%達成：Sales Opsが実際にテストすべきこと：HubSpotのエージェント機能が見込み客開拓を超えてCSに隣接したワークフローにも拡張される方法。
• バイヤーインテントシグナルの合成：信頼性の高いシグナル層の構築：プラットフォームを選択する前にシグナルソースを分類・重み付けするための基礎フレームワーク。
• AIセールスオペレーションベンダーランドスケープ2026：シグナルベースのセリングカテゴリーにおける現在のポジショニング（2026年Q2更新版）。

---

FAQ

シグナルベースのセリングとは何ですか？また、Sales Opsにとってなぜスタックの構造が重要なのですか？

シグナルベースのセリングとは、静的なリードスコアや担当者の手動判断ではなく、行動シグナル、インテントシグナル、またはCRM由来のシグナルに基づいてアウトリーチと優先度付けの意思決定をトリガーする手法です。シグナル自体が異なる場所に存在するため、スタックの構造が重要です。サードパーティのインテントデータ（G2、Bombora、TechTarget）、ファーストパーティのCRM行動（商談ステージの変化、メールエンゲージメント、製品利用）、プラットフォーム由来のCDPシグナル（Salesforce Data Cloudのイベント、HubSpotの行動トラッキング）。どのプラットフォームを中心に統合するかによって、どのシグナルカテゴリーが主要なトリガーになるかが決まります。これを誤ると、最も価値の高いシグナルが常に持っていないプラットフォームに存在し、恒久的な統合のギャップが生まれます。

Sales Opsはスタックの決定前に独立したベンチマークを待つべきですか？

独立したベンチマークを待つことは、モデルレベルのインフラ決定（例：新しいAI推論モデルの評価）では正しい判断です。6月とQ3の更新サイクルを伴うプラットフォーム統合の決定では、待つことで調達の窓を過ぎてしまいます。よりスマートなアプローチは、自社でQ1スタイルのベンチマークを実施することです。最も量の多い3つのシグナルワークフローを選び、候補プラットフォームのサンドボックスまたはトライアル環境で実行し、公開レビューを待つのではなく方向性の品質を評価してください。30日間のトライアルでテストする価値のある評価基準についてはAIアカウントリサーチフレームワークをご覧ください。

ApolloによるPocusの買収は、AsanaやMonday.comのような既存のPocus顧客にどのような影響を与えますか？

既存のPocus顧客にとって、実際の短期的な問いは統合のタイムラインです。どのPocus機能が買収後の最初の2四半期でApolloプラットフォームに組み込まれ、どれが別のロードマップに残るのか。Apolloの明確な方向性は、PocusのインテリジェンスレイヤーとApolloのアウトリーチ・エンリッチメントプラットフォームを組み合わせたAIネイティブのGTMオペレーティングシステムです。現在ApolloのユーザーでないPocus顧客にとっては、この買収が決断を迫ります。Apolloの広範なプラットフォームへ移行するか、この買収を次の契約更新前に3スタック全体を評価するシグナルとして受け取るか。移行評価中にどのプラットフォームにでも問うべきデータポータビリティの問いについてはリードデータエンリッチメントガイドをご参照ください。