第5章 GTM Engineeringの4つのレイヤー
本章では、GTM Engineeringが構築する対象を、土台から順に4つのレイヤーとして解説する。繰り返しになるが、この4層は下から積み上がる依存関係にある。上位レイヤーの華やかさ（AI、自動化）に目を奪われる前に、足元のレイヤーが成立しているかを常に問う必要がある。
5-1 レイヤー①データ基盤――SSOTをどこに、どう作るか
第3章で述べた通り、データ基盤の要諦は「アカウント（企業）とピープル（人）の一意性担保」と「データが自動的に集まる構造」である。本節では一歩踏み込み、そのSSOTをどこに構築するかというアーキテクチャの選択を論じる。選択肢は大きく2つある。
CRMハブ型。 Salesforce等のCRM/SFAをデータのハブとし、MA・名刺管理・フォーム・ウェビナーツールなどをCRMに接続してSSOTを構成する。マーケティングから営業までのデータが中心で、扱うデータソースが数個程度の企業であれば、この構成で十分に機能する。利点は、営業・マーケの現場が日常的に見る画面とSSOTが一致すること、追加のデータ人材を必要としないこと。多くの日本のBtoB企業にとって、現実的な出発点はここである。
DWH/データレイクハブ型。 Snowflake、BigQueryといったデータウェアハウス（DWH）をハブとし、CRM・MAに加えて、プロダクト利用データ、請求・契約データ、サポート履歴、広告データまでを統合する構成である。海外ではこの「warehouse-native GTM」への移行が進んでおり、顧客データ基盤（CDP）の機能をDWH上に構成する「コンポーザブルCDP」と呼ばれるアプローチも一般化しつつある。利点は、CRMには収まらない大量・多種のデータ（例：日次のプロダクト利用ログ）を扱えること、BI・機械学習・AIエージェントへの供給源を一本化できること。代償は、データエンジニアリングの人材・運用コストである。
重要なのは、どちらが正解かではなく、移行の順序である。判断基準は次の4つ。
- データソースの数：接続すべきソースが数個ならCRMハブ、10を超えて増え続けるならDWHを検討
- プロダクト利用データの有無：PLG要素があり利用ログを営業シグナルに使いたいなら、DWHがほぼ必須
- 分析・AI活用の深度：定型レポートで足りるか、横断的な分析・予測・エージェント供給まで必要か
- データ人材の有無：DWHハブは構築より運用が本番であり、担い手なしに建てたDWHは「誰も見ない倉庫」になる
陥りがちな失敗は両極にある。ひとつは「最初からデータレイクありき」のオーバーエンジニアリング。一意性という原則が確立していない段階で器だけ大きくしても、汚れたデータの置き場が増えるだけである。もうひとつは、CRMハブの限界（ソース増加、ログデータ）に達しているのに増改築を重ねて複雑化させる停滞である。実務的な段階論はこうなる――**まずCRMハブで一意性とSSOTの原則を確立し、データソースと活用要件が閾値を超えた時点でDWHハブへ進化させる。**その際、CRMは「捨てる」のではなく、DWHと双方向同期する現場の操作面として生き続ける。
5-2 レイヤー②シグナル――「今、この企業に話す理由」をデータにする
データ基盤の上に構築するのが、シグナルレイヤーである。シグナルとは、顧客側の行動や状態の変化のうち、「今アプローチすべき理由」を示す兆候を指す。
BtoBの買い手は、売り手が接触するはるか前から自分で情報収集を進めている。物量で網を張るのではなく、変化の瞬間を捕捉して適切に接触する――これがシグナル起点のアプローチであり、第2章で見た「SDR物量モデルからの転換」の中身である。シグナルの例を挙げる。
- 自社への行動シグナル：価格ページの再訪、資料の複数ダウンロード、休眠顧客のサイト再訪、ウェビナー参加
- 企業の変化シグナル：関連職種の求人開始、組織変更・役員就任、資金調達や中期計画での投資テーマ、拠点展開
- 利用状況シグナル（既存顧客）：プロダクト利用の急増・急減、活用範囲の拡大、更新期限の接近
このレイヤーの設計で最も重要な原則は、自社で意味を説明できるシグナルを優先することである。外部ベンダーが提供するブラックボックス化したインテントスコアを盲信するより、「価格ページを1週間に2回見た企業は商談化率が高い」という自社データで検証可能な定義の方が、改善のループを回せる。シグナルは「買う」ものではなく「定義し、検証する」ものだ。
そしてこの検証が成立する前提こそ、レイヤー①の一意性である。同一企業が3レコードに分裂していれば、行動シグナルも3つに分裂し、閾値に達しない。シグナルの精度は、データ基盤の品質の従属変数なのである。
5-3 レイヤー③AI――判断と作業を移植する
第三のレイヤーが、AI（主に生成AI/LLM）の実装である。GTMにおけるAI活用は、2つの方向で急速に実用化した。
第一は、作業の自動化。 接触前の企業リサーチ（事業内容、直近の発信、決算情報の要約）、シグナルと文脈を踏まえたパーソナライズ文面の生成、商談メモの要約とCRMへの記録、リードスコアリング。従来SDRやマーケ担当者の時間を大量に消費していた定型作業が、AIに委譲可能になった。
第二は、判断の移植。 より本質的なのはこちらである。第2章のVercel事例が示した通り、トップパフォーマーの優先順位づけ・文脈の読み方・アプローチの組み立て方を観察し、プロンプトとワークフローに翻訳することで、「優秀な個人の暗黙知」を「組織のシステム」に変換できる。2026年時点の潮流は、単発のルールベース自動化から、ガードレール（許可された範囲・停止条件）の中で自律的に文脈を解釈し実行するAIエージェント型へと移行しつつある。
ただし、このレイヤーには明確な警告が要る。**AIは下位レイヤーの欠陥を増幅する。**汚れたデータの上のAIは、誤った相手に、精巧で丁寧な誤ったメッセージを、高速かつ大量に送る。手作業の時代には1日数十件で済んだ誤りが、自動化によって数千件規模になる。AIレイヤーの導入判断は「AIで何ができるか」ではなく「AIに渡せる品質のデータとシグナルがあるか」から始めなければならない。
5-4 レイヤー④プロセス――部門の狭間を技術で埋める
最後のレイヤーは、部門横断プロセスの実装である。どれだけ良いリードを生み、精巧なAIを組んでも、リードが部門の狭間で消えるなら収益にはならない。ここで実装するのは主に2つである。
ハンドオフの自動化。 第3章の戦術層で定義した引き渡し基準（どの条件を満たしたらマーケからインサイドセールスへ、インサイドセールスから営業へ渡すか）を、人の申し送りではなくシステムの自動判定・自動通知・自動割り当てとして実装する。SLA（対応期限の合意）も、期限超過の検知とエスカレーションまで自動化して初めて実効性を持つ。
定義の共通言語化。 「リード」「商談」「案件確度」の定義を全部門で統一し、システム上の項目とステージとして固定する。地味に見えるが、これはAI時代においてむしろ決定的である。定義がバラバラなデータでは、人間の会議が紛糾するだけでなく、AIも誤った学習と判断をする。第2章で触れた通り、先行企業がデータの用語・定義の統一に投資しているのは、AIに業務を任せるための土台作りに他ならない。
このレイヤーが完成すると、第3章で描いたレベニューモデル（マーケ→IS→営業→CSの連携）は、努力目標ではなく、システムが担保する構造になる。
5-5 4レイヤーの統合――「深く統合された少数」が勝つ
最後に、4レイヤーを貫く統合の原則を確認する。第2章で紹介した通り、12以上の分断されたツールを持つチームは、深く統合された4〜5ツールのチームに一貫して劣後する。レイヤーを増やすことは、ツールを増やすことではない。むしろ逆で、一意なデータ基盤の上に、シグナル・AI・プロセスが同じデータを参照して動く状態を作ることが統合の意味である。
自社の現状を診断する問いはシンプルだ。「わが社のツールたちは、同じ顧客を、同じIDで、同じ定義で見ているか？」――この問いにイエスと答えられないなら、次に投資すべきは新しいツールではなく、レイヤー①である。
