スタートアップ分析
ABMの進化形｜インテントデータ×データエンリッチメントの設計メモ
日本のBtoB企業でよく見る構図がある(仮想の例として書く)。展示会で数百枚の名刺を集め、業界や役職でフィルタをかけてABM(アカウントベースドマーケティング。特定企業を狙い撃ちする営業・マーケティング戦略)ツールに取り込み、スコアリングで「ターゲット企業100社」を作る。マーケティング部門はカスタマイズしたメールを送り、電話をかけ、セミナーに招待する。数ヶ月後、商談化はごくわずかにとどまり、営業部門は「マーケが出すリスト、ピンと来ない」とこぼし、結局いつもの顧問ルートで商談を作る。ABMツールの導入が、むしろマーケと営業の溝を深める。日本のBtoB企業で繰り返されがちな失敗パターンだ。
この構図をもう少し分解すると、3つの変奏に集約できる。ある製造業のケースでは、FORCASで抽出した300社のリストが更新責任者不在のまま半年以上放置される。あるIT企業のケースでは、マーケティング部門がSlackでターゲット企業群を共有しても、営業はそれを一度見て自分の既存パイプラインに戻ってしまう。別のケースでは、属性スコア90点の大企業が「今期はIT投資を凍結している」と即答する一方、スコア40点の中堅企業が実はシステムのリプレースを検討している、という逆転が起きる。共通しているのは、リストが止まっている間、営業は代わりに顧問経由の紹介や既存の商社ルートで商談を作り続けていることだ。いずれも特定の1社の実話ではなく、冒頭同様、日本のBtoB企業で繰り返し観測される典型パターンを合成した仮想の構図として書いている。
問題は、ABMという型そのものではない。問題は、ターゲットリストが「静的」だったことにある。3ヶ月前に選んだ100社のうち、購入テーマが動き出している企業が何社あるかは、誰も知らない。リストは選定した瞬間から古びはじめるのに、多くの運用は最初のスナップショットのまま止まっている。
ABMの進化｜静的リストからシグナルベースへ
この記事の立場
私は、日本のBtoB企業がABMを立て直す最初の一手は、インテントデータツールの新規契約ではないと考えている。むしろ、gBizINFOとEDINETという2つの公開データに、自社のGA4・MAデータを重ねた最小のData Waterfallを自前で組むことだ。
理由は日本のIP環境にある。大企業はプロキシ経由でIPが1つに集約され、中小企業は共有IPで企業特定そのものが難しい。リモートワークが広がれば、社員が自宅からアクセスした瞬間に記録上は「個人」でしかなくなる。この環境では、サードパーティ・インテント単体の精度を過信できない。検知根拠を説明できる公開データと自社接点データの掛け合わせのほうが、営業は実際に動ける、というのが私の立場だ。
もちろん、エンタープライズ向けの高単価商材で専任の運用者を置ける組織なら、最初から有料のインテントツールを重ねる選択もありうる。しかし、その条件を満たさない会社がツール契約から入るのは、順序が逆だというのが本記事の立場である。
この記事はネクサフローのGTMエンジニアリングシリーズの一部として書く。実装の詳細、EDINET APIでの事業リスク抽出やgBizINFO APIでの企業属性取得は、すでに日本企業のためのGTMエンジニアリング実践で公開した。この記事はそちらに実装を委譲し、なぜその順序で組むべきかという診断と設計思想に絞る。
前提: 3つの言葉を先に定義する
以降で繰り返し使う3つの概念を、使う前に定義しておく。定義がなければ、後段の主張は検証できない。
Data Waterfall: 複数のデータソースを段階的に重ねて、リードの精度を上げる設計。本記事では層番号を次のように固定し、以降すべての節・図表でこの並びに従う。
第1層 企業選定(gBizINFO) → 第2層 財務・事業リスク分析(EDINET) → 第3層 インテント検知(Sales Marker等) → 第4層 キーパーソン特定(Eight/Sansanなど) → 第5層 自社行動データ(GA4/MA)
Signal-based selling: 顧客のシグナルを人が見て毎回判断するのではなく、シグナルの組み合わせそのものをトリガーとして、事前に設計された営業アクションが自動的に起動する状態。「インテントデータを見て営業する」との違いは、判断の主体が営業担当者かワークフローかという一点にある。
インテントデータの3分類: 取得経路によって次の3つに分かれる。ファーストパーティ(自社が直接取得するデータ)、セカンドパーティ(パートナー企業やメディアから共有されるデータ)、サードパーティ(外部プロバイダーが収集・提供するデータ)。精度はファースト>セカンド>サードの順で高く、コストは逆順になりやすい。
ABMが「導入しただけ」で止まる3つの構造
日本のBtoB企業のABM運用を見ていくと、同じ3つの構造的原因に行き着くことが多い。
構造1: ターゲットリストが静的である
ABMのターゲットリストは、ある時点のスナップショットだ。ICP(理想の顧客像)に合致する企業を選んだ瞬間から、企業の状況は動き続ける。予算策定期を過ぎれば検討は止まり、決裁者が交代すれば合意は白紙に戻る。3ヶ月前に選んだ100社のうち、いま動いている企業が何社あるかを追う仕組みがなければ、リストは選定した日から劣化する一方だ。これは担当者の能力の問題ではなく、手法そのものに組み込まれた限界である。
構造2: 企業属性しか見ていない
業界、規模、売上高、所在地といった企業属性(firmographics)は、どのサイズの企業なら単価が高いかを教えてくれる。しかし「今、検討しているか」は教えてくれない。スコア90点のICP適合企業が「今期はIT投資を凍結している」一方で、スコア40点の中堅企業が実はシステムのリプレースを検討している、という逆転は珍しくない。属性データだけでスコアリングする限り、この逆転を検知できない。
構造3: マーケティング部門で完結している
ABMの「M」はMarketingだが、成約には営業・カスタマーサクセスの連携が要る。「マーケが戦略を設計し営業に引き渡す」モデルは、構造的に引き渡しの断絶を生む。インテントデータが「この企業は今検討中です」と示しても、営業が「で、何を言えばいいのか」で止まれば意味がない。日本企業でよくある「ABM推進室」は、リストを渡すところまでは責任を持つが、そのリストで商談を作るのは営業の仕事、という分業が断絶を組織構造として固定してしまう。この断絶を解く役割は、後述するGTMエンジニアリングが担う。
設計: 日本市場でのData Waterfall
3つの構造的原因のうち、構造1と2はData Waterfallで直接突破できる。1つのデータプロバイダーだけに頼るのではなく、前提で定義した5つの層を順に通し、企業を絞り込んでいく。
Data Waterfall｜複数データソースを段階的に重ねる
具体例(仮想の試算): 製造業向けIoT企業のData Waterfall
数値はすべて仮想の試算であり、実測値ではない。層の重ね方のイメージをつかむためのものとして読んでほしい。
- 第1層 企業選定(gBizINFO): 「製造業 × 従業員500人以上」で抽出 → 1,200社
- 第2層 財務・事業リスク分析(EDINET): 有価証券報告書の事業リスク欄に「サプライチェーン」「DX」等の記述がある企業に絞る → 340社
- 第3層 インテント検知(Sales Marker等): 直近30日に「IoT」「予知保全」関連の検索行動がある企業 → 90社
- 第4層 キーパーソン特定(Eight/Sansan等): 製造部門長・情シス部門長の連絡先を補完 → 45社
- 第5層 自社行動データ(GA4/MA): 料金ページや事例ページを閲覧した企業 → 8社
1,200社から8社まで絞り込めば、営業がその日にアプローチする理由を説明できる状態になる。重要なのは、1つのツールで全層をカバーする必要がないことだ。複数のデータソースをどう組み合わせるか、その設計そのものが競合との差になる。
日本市場でのData Waterfall実装例
層 データソース 取得できる情報 コスト 第1層: 企業選定 gBizINFO(経済産業省) 企業基本情報・補助金・認定情報 公開データ 第2層: 財務分析 EDINET(金融庁) 有価証券報告書・事業リスク 公開データ 第3層: インテント Sales Marker Web行動データ・検索キーワード 有料 第4層: 人物情報 Eight/Sansan 名刺DB・人脈マップ 有料 第5層: 行動履歴 自社GA4/MA サイト閲覧・メール開封 既存ツール 注目すべきは、第1-2層が公開データだけで組めることだ。gBizINFOでは法人番号・業種・補助金採択情報を、EDINETでは有価証券報告書の事業リスク欄を確認できる。APIの叩き方、前年差分での変化抽出、PoCコードといった実装レベルの詳細は日本企業のためのGTMエンジニアリング実践に譲る。この記事の役割は実装ではなく、なぜこの順で重ねるべきかという設計判断のほうだ。
実際にAPIを叩いたときの中身は、委譲先の実装ガイドにすでに書いてある。EDINET APIはdocuments.jsonエンドポイントに日付とtype=2を渡し、docTypeCodeが120かつxbrlFlagが1の文書だけを有価証券報告書として絞り込む。取得したXBRLはjpcrp_cor名前空間のBusinessRisksTextBlock要素から事業等のリスク本文を抜き出すが、この要素は文書様式によって空振りすることがあり、そうした文書は自動処理ではなく手動レビューのキューに回す設計にしている。gBizINFO APIは法人番号を指定してhojin/v1エンドポイントを叩き、subsidy(補助金)・certification(認定)・procurement(調達)という3つのサブリソースを個別に取得する構成だ。この実装手順を示した日本企業のためのGTMエンジニアリング実践の内容を実際に組もうとすると、詰まりやすいのは認証や項目の粒度よりも、前年差分でキーワードが「新しく増えたか」を判定するロジックの設計のほうだと考えている。
第3層を厚くする: インテントデータの3分類の使い分け
第3層に何を通すかによって、Data Waterfallの精度は大きく変わる。前提で定義した3分類のうち、組み合わせる順序として効果が高いのは次の流れだ。
サードパーティ(広域の検索行動)で候補を絞り、セカンドパーティ(業界メディアの閲覧)で関心の深さを測り、ファーストパーティ(自社サイトの行動)で購買意欲を確認する。
ただし、サードパーティの精度をどこまで信じてよいかについては、境界を明確にしておく必要がある。それは後の節で改めて扱う。
インテントデータの3分類
運用: Signal-based sellingの設計
Data Waterfallでリストの精度を上げても、営業がそれを見て毎回判断していては運用が回らない。ここで効いてくるのがSignal-based sellingだ。前提で定義した通り、シグナルの組み合わせそのものをトリガーに、事前設計された営業アクションが自動的に起動する状態を指す。
「インテントデータを見て営業する」との違いは、判断の主体にある。前者は営業担当者がリストを見て毎回判断する。後者は、どのシグナルの組み合わせにどのアクションを割り当てるかを先に設計しておき、シグナルが発生した瞬間にワークフローが動く。
設計イメージ(仮想例): HRテック企業の場合
シグナルの重なりに応じてアクションの深さを変える設計は、次のようなイメージになる。実在の企業の運用ではなく、設計パターンを示す仮想例として読んでほしい。
| シグナルの組み合わせ | アクション |
|---|---|
| 「勤怠管理」関連の検索を検知 + 自社事例ページ閲覧2回 | インサイドセールスが24時間以内に架電 |
| 上記 + gBizINFOで「くるみん認定」取得を確認 | 営業マネージャーが直接対応し、業界特化の事例資料を送付 |
| 上記 + EDINETの事業リスク欄で「人的資本経営」への言及を確認 | 経営層向けホワイトペーパー送付後、役員アポを打診 |
シグナルが1つならライトタッチ、複数重なればフルコミット。営業リソースの配分を、担当者の勘ではなく事前設計に委ねる。
この設計を担うのは、マーケでも営業でもない「売上を生むシステム全体を設計する」役割であり、日本企業のためのGTMエンジニアリング実践で扱った受け渡しレイヤー(なぜ今か・何を聞くか・誰から入るか・何を残すか)と同じ骨格を持つ。
道具の配置: FORCAS × Clay × Sales Marker
Data Waterfallの各層に、どのツールを充てるかを整理する。
| 観点 | FORCAS(スピーダ顧客企業分析) | Clay | Sales Marker |
|---|---|---|---|
| Data Waterfall上の層 | 第1層: 企業選定、業界分類、既存顧客との照合 | 複数層をまたぐ: enrich、分岐、AI生成、CRM連携 | 第3層: インテント検知、優先順位づけ |
| 見るべき強み | 日本企業データの粒度、SPEEDA等との連携 | 外部データ接続の自由度、ワークフローの再現性 | 国内向けのシグナル検知、営業通知 |
| 導入前の確認項目 | 更新頻度、既存CRMとの突合精度 | 日本企業データのカバレッジ、運用できる人の有無 | 検知根拠の説明可能性、誤検知率 |
FORCASだけで運用している企業は、Data Waterfallの第1層で止まっていることになる。企業属性は分かっても、「今、何を検討しているか」は見えない。
Clayは複数のデータプロバイダーをノーコードで束ね、Data Waterfallを柔軟に構築できる。ただしClay完全ガイドで整理した通り、成果を分けるのはClayの機能そのものではなく、provider mixを設計し運用し続ける人がいるかどうかだ。RevOpsやGTM Opsの専任者を置ける成長企業には向くが、その運用責任を負えない組織がいきなり導入すると、「便利な表」で終わりやすい。
Sales Markerは日本企業のWeb行動データを営業アクションに変える入口として使いやすい。ただしインテントセールスとは？で整理した通り、サードパーティデータ特有の精度問題を、Sales Marker単体で解消できるわけではない。
私が勧める順序
この3つは競合ではなく補完関係にある、という両論併記でこの節を終わらせるつもりはない。私が勧める順序は次の通りだ。
- まず公開データ(gBizINFO)と自社データ(GA4/MA)だけで、Waterfallの第1層と第5層を組む
- その運用が週次で回り始めてから、FORCASのような企業データベースで第1層の粒度を上げる
- 専任の運用者を置ける予算と体制が整って初めて、Sales MarkerやClayで第3層以降を厚くする
専任運用者を置けない会社がこの順序を飛ばし、いきなりツール契約から入ると、契約は残るが運用は誰もしていない状態に陥りやすい、というのが私の見立てだ。
境界をもう少し具体的に引くなら、私は従業員規模そのものより、「シグナルの当たり外れを毎週ルールに戻す」作業を役割として持つ人が社内に1人でもいるかどうかで判断している。Clay完全ガイドで触れた通り、Clayのようなツールの成果を分けるのは機能ではなく、provider順序を決めコストの上限を置いて運用し続けるOps担い手の有無であり、その担い手がいない組織にはClayを最初の一手に据えることは勧められない、というのが同記事での私の立場だ。同じ基準は本記事のツール選択にも当てはまるとみている。営業担当の全員が商談化にフル稼働していて、週次のルール改善に工数を割ける人が誰もいない組織では、専任運用者を置ける条件を満たしていないと判断していい。逆に、規模が小さくても、RevOpsやセールスイネーブルメントの肩書を持つ1名が「当たり外れの確認」を明示的な役割として持っているなら、条件は満たせると考えている。
ツール3軸比較｜FORCAS・Clay・Sales Marker
限界と境界: サードパーティ・インテントの懐疑論をどう読むか
インテントデータの精度に対する懐疑は、遠い国の話ではない。Reddit r/salesでは、6senseのようなABM/インテント系ツールについて「データは見えるが商談創出にはつながらなかった」という趣旨の投稿が繰り返し出ている(Reddit r/sales: What's going on at 6sense?)。GTMエンジニアという役割自体への懐疑論もある(Reddit r/sales: Anyone here an actual GTM Engineer?)。これらの投稿は事実の裏取りではなく、利用者が実際に詰まっている論点として扱う。インテントセールスとは？で整理した「導入後に起きる不満」と同じ構造がここにも見える。
懐疑の中身を分解すると、IPアドレスベースの企業推定の限界、インテントの定義のあいまいさ、企業単位への集約バイアス、ベンダーのインセンティブ構造(シグナルの量が商品価値になるため精度より検出量が優先されやすい)という4つの原因に行き着く。
日本のIP環境ではこの問題がさらに深刻になる、というのが私の見立てだ。大企業はプロキシ経由でIPが1つに集約され、中小企業は共有IPで企業特定自体が難しい。在宅勤務が広がれば、社員が自宅からアクセスすることは、記録上ただの「個人」でしかない。
この見立ては日本固有の推測だけに基づくものではない。インテントセールスとは？で整理した通り、サードパーティのインテントデータはそもそもIPアドレスから企業を推定する手法に依存しており、在宅勤務やVPN経由のアクセス増加によって推定精度が年々下がっているという構造的な限界がすでに指摘されている。日本のプロキシ集約・共有IP環境は、この限界がより極端な形で表れたケースだと位置づけるのが妥当だと考えている。
だからこそ、本記事の立場は明確にしておく。サードパーティ・インテント単体のスコアを信じてアプローチするのではなく、検知根拠を説明できる公開データ(第1-2層)と自社接点データ(第5層)を先に固め、その掛け合わせでシグナルを検証する。全員が同じサードパーティデータを買う市場では、差別化はどのデータを買うかではなく、どう掛け合わせるかの設計力にかかる。この論点はGTM Alphaとは？で詳しく展開した。
結び: 私ならこの順で始める
まとめは書かない。代わりに、判断の材料を残しておく。私自身が今日どこかの会社でABMを立て直すなら、次の順で手を付ける。
- まず、自社CRM/MA/GA4のデータ品質を棚卸しする。ここでコケていると、後段の公開データを重ねても意味がない
- 次に、gBizINFOとEDINETで第1-2層を組む。法人番号・業種・補助金採択情報と、有価証券報告書の事業リスク欄の前年差分。ここまでは無料で、週次更新に耐える
- その2層と自社GA4/MAの行動データ(第5層)を突合し、「公開データ+自社接点」だけのシグナルで営業がどこまで動けるかを2〜3ヶ月試す
インテントデータツールを追加するのは、この後でいい。判断条件は3つある。(1) 第1・2・5層のシグナルだけで営業が実際に動けている、(2) それでも捕捉できていない「自社との接点がまだない検討企業」の存在を営業側が言語化できている、(3) その企業を捕捉するための運用工数を、専任の担当者に払う余力がある。この3つが揃わないままツール契約から入るのは、私には順序が逆に見える。
もっとも、これは一つの意見に過ぎない。エンタープライズ向けの高単価商材で、そもそも専任のGTM Opsを最初から置ける組織なら、話は変わってくる。
次に検証したいのは、この最小構成のData Waterfallを実際に週次で回したとき、シグナルの「当たり外れ」がどれくらいの頻度でルール改善に戻るかだ。それは診断ではなく実装の話であり、日本企業のためのGTMエンジニアリング実践に譲る。
関連記事
日本企業のためのGTMエンジニアリング実践｜EDINET・gBizINFO・顧問ネットワークで営業優位を作る
本記事のData Waterfall第1-2層(gBizINFO・EDINET)の実装詳細を担う記事。本記事は「なぜその順序で組むか」の診断と設計理由を扱い、実装手順はこちらに委譲している。
インテントセールスとは？Sales Marker・FORCAS・6senseの実力と限界
Sales Marker等インテントツールの実力と限界をReddit r/salesの出典付きで整理した記事。本記事の懐疑論の節は、この記事の出典に接続して書いている。
GTM Alphaとは？同じツールを使っても勝てない理由とデータ戦略の作り方
「同じデータを全員が買うと差がつかない」論の展開先。本記事の結論(差別化はデータの掛け合わせ設計)が何を前提にしているかを補強している。
本記事はネクサフローのGTMエンジニアリングシリーズの一部です。
