2026年3月11日、「GTMエンジニアが実践する次世代リード創出」をテーマに、Clay Club Tokyo を開催しました。
会場には、SaaS企業やAI活用を進めるサービス事業者の方々などにご参加いただきました。
当日は、AIとデータをGTMの実践に取り入れる「GTMエンジニア」という新しい役割と、それを支えるツールであるClayの実態について、概念から実践まで深く掘り下げることができました。
参加者の皆さまからも、GTMやGTMエンジニアに関する概念的な理解だけでなく、「自社でもすぐに活用できそうだ」「実践のイメージが持てた」といった声を多くいただきました。
当日のプログラムは2部構成で、第1部では Unima CEO の大沢さんに「GTMとGTMエンジニアリング」についてお話しいただき、第2部では Clay の服部より「Clayとは何か」「Clayの具体的な活用事例とデモ」について紹介しました。
GTM（Go-To-Market）は、ひと言でいえば「誰に、何を、なぜ、どこで、どうやって売るのか」を決める全体設計です。
単に営業施策を並べたものではありません。どの市場を狙うのか、どんな顧客にアプローチするのか、どのメッセージを、どのチャネルで届けるのか。さらに、その後の営業活動やマーケティング活動をどう連動させるのかまで含めて考える必要があります。
つまりGTMは、セールス、マーケティング、インサイドセールス、そして一部のRevOpsまでを含んだ「案件創出の設計図」です。
ここが曖昧だと、マーケティングはリードを集めているのに営業では活かしきれない、営業はアプローチしているのに受注につながらない、といったズレが起きます。逆にGTMが明確だと、「なぜこの企業に今アプローチするのか」「なぜこの訴求が必要なのか」が説明できるようになります。
GTMの説明をすると、よく一緒に語られるのがRevOpsです。実際、扱うツールやデータの一部は重なりますが、役割は明確に異なります。
GTMは、新しい案件をどう作るかを考える“攻め”の領域です。どんなデータを使えば新しいターゲットを見つけられるのか、どんなシグナルがあれば商談化しやすいのか、どんな訴求をすれば反応率が上がるのか。常に新しい仮説を立てて、試して、改善していくのがGTMです。
一方でRevOpsは、既存の営業プロセスやデータ連携を整える“守り”の領域です。CRMの管理、マーケとセールスの連携、商談化率やパイプラインの可視化、営業活動の運用ルールづくりなど、組織が安定して回るための基盤を整える役割を担います。
整理すると、GTMは「案件を増やす」ための設計であり、RevOpsは「仕組みとして回す」ための設計です。
もちろん、この2つは完全に切り離されるものではありません。GTMで見つけた勝ちパターンを、あとからRevOpsが仕組み化していく流れになります。ただ、最初からRevOps的な発想で完璧な仕組みを作ろうとすると、GTMで必要なスピードが失われてしまいます。だからこそ、まずはGTMを“探索の領域”として捉えることが重要です。
大沢さんの話の中で一貫していたのが、GTMの本質はデータとAIの掛け合わせにある、という考え方でした。
つまりGTMにおいて重要なのは、ただデータを持つことではありません。データを加工し、意味のあるシグナルに変え、実際の営業活動につなげることです。その変換を加速させるのがAIです。
GTMでは、最初から正解が分かっていることはほとんどありません。どのシグナルが効くのか、どんな訴求が刺さるのか、どの市場で反応があるのかは、実際に試してみないと分からない部分が大きいからです。
だからこそGTMは、たくさん仮説を立てて、その中の一部が当たればよいという発想で進みます。ここで最初から完璧な運用やシステムを作ろうとすると、仮説が外れた時の損失が大きくなります。むしろ重要なのは、AIを活用しながら素早くデータを取り込み、仮説を一気に回せる状態をつくることです。
その上で、うまくいった施策やシグナルが見つかったら、それをRevOps的に仕組み化していく。この順番が、GTMを考える上では非常に重要です。
GTMで成果を大きく左右するのが、GTMアルファです。
金融や投資の世界で「アルファ」が市場平均を上回る超過リターンを指すように、GTMにおけるアルファも、競合より高い成果を生み出す独自の優位性を意味します。
この優位性は、単に良いリストを持っているという話ではありません。本質は、他社が持っていない情報、もしくは他社が同じようには使えていない情報を使って、より精度の高いアプローチを作ることです。
たとえば、
といったことが、GTMアルファの源泉になります。
ここで重要なのは、単一のデータではアルファになりにくいということです。求人データだけ、ニュースデータだけ、テクノロジーデータだけでは、結局ほかの会社も同じものを見ています。取得しやすいデータほど、すぐにコモディティ化します。
だから価値が出るのは、データを掛け合わせた瞬間です。
たとえば日本市場であれば、Wantedlyなどの採用データ、PR TIMESなどのニュースや資金調達データ、企業サイトの公開情報、導入ツールの情報、CRMや商談議事録などの自社データを組み合わせることで、「今この会社が動いている理由」や「今アプローチするべき理由」が見えてきます。
採用を強化している企業が、同時に資金調達を行い、新しい事業部門を立ち上げているとしたら、それは明確なシグナルです。また、競合サービスに対する不満レビューをAIに読み込ませれば、相手がどこに課題を感じているのかを把握できます。そこから、自社がどんな切り口で提案すべきかも見えてきます。
テクノグラフィックデータも同様です。今どんなツールを使っているのかが分かれば、既存環境に合わせた訴求や、競合製品からの置き換え提案ができます。
こうした積み重ねがGTMアルファです。ただし、このアルファに永続的な正解はありません。市場は変わり、競合も同じデータを使い始めます。昨日まで有効だった優位性が、半年後には当たり前になっていることもあります。だからGTMアルファは、一度見つけて終わりではなく、常に探し続けるものです。
GTMエンジニアは、GTMアルファを作り続ける役割です。
より具体的にいえば、売上をつくるためのリサーチと検証を担う、GTMのR&D部門のような役割です。従来の営業やマーケティングの現場では、担当者が個別に企業を調べ、仮説を立て、優先順位をつけていました。GTMエンジニアは、その一連の流れをデータとAIで再設計し、より速く、より再現性のある形に変えていきます。
ここで重要なのは、単に時間が浮くことではありません。本当に価値があるのは、人が作業ではなく仮説に時間を使えるようになることです。GTMエンジニアはまさにそのために存在する役割です。
GTMエンジニアの仕事は、主に4つに整理できます。
最初に必要なのは、「なぜ今この会社にアプローチするのか」を定義することです。
たとえば、採用を強化している、新しい資金調達をしている、新しいプロダクト領域に広がろうとしている、特定のツールを導入している、既存顧客と似た属性を持っている。こうした情報は、すべてアプローチの根拠になり得ます。
重要なのは、こうした情報を単発の事実として終わらせるのではなく、営業やマーケティングが動く理由になる“シグナル”として設計することです。GTMエンジニアは、ファーストパーティデータとサードパーティデータを掛け合わせながら、このシグナルをつくります。
次に必要なのが、どんなデータが存在し、どう組み合わせれば価値になるのかを把握することです。
ここでいうデータは、単なる会社情報に限りません。求人情報、ニュース、プレスリリース、商談議事録、CRMの履歴、Webサイト上の情報、導入ツールの情報など、売上につながる可能性のあるものはすべて対象です。
実際の話の中でも、Wantedlyのような採用データ、PR TIMESのようなニュースデータ、Webサイトの公開情報、さらにツール導入状況を示すテクノグラフィックデータなどを掛け合わせることで、より精度の高いターゲティングが可能になると語られていました。
単一データは多くの場合、すぐにコモディティ化します。一方で、複数データを掛け合わせた瞬間に、自社独自の仮説が生まれます。その組み合わせを柔軟に考えることが、GTMエンジニアの重要な役割です。
集めたデータをもとに、「どの企業が上位に来るべきか」を判断するのもGTMエンジニアの役割です。
ここで大切なのは、営業担当者の感覚だけに頼らないことです。人が手で判断すると、どうしても経験や主観に引っ張られます。ある担当者には良く見える会社が、別の担当者にはそう見えないこともあります。
そのばらつきを減らすために、AIやルールベースのスコアリングを使います。たとえば、特定の役職を採用しているか、特定のツールを導入しているか、資金調達直後か、過去の受注企業と似た特徴があるか、といった条件をもとに、スコアを機械的に付与していきます。
こうすることで、営業が追うべきリードをより明確にできるだけでなく、組織全体で判断基準を揃えやすくなります。
最後に必要なのは、つくった仮説を現場で実際に検証することです。
どれだけよいスコアリングやシグナル設計ができても、営業やマーケティングの実行につながらなければ意味がありません。GTMエンジニアは、スコアリングしたリードをセールスチームに渡し、その結果を短いフィードバックサイクルで回していきます。
どんな企業で反応がよかったのか、どんな訴求が刺さったのか、逆にどの仮説が外れたのか。これを見ながら、シグナルやスコアリングの条件を調整していきます。
つまりGTMエンジニアは、一度仕組みを作って終わる人ではありません。仮説を投げ、学び、改善し、当たったものを広げるところまでが仕事です。
こうしたGTMエンジニアの仕事を実際に回そうとすると、必要になるのが共通の実行基盤です。
やるべきことは多岐にわたります。さまざまなソースからデータを集める。データを整理し、必要な情報を付与する。AIで要約・分類・抽出を行う。スコアリングに落とし込む。CRMや営業チームにつなぐ。これを人手だけで回すのは現実的ではありません。
だからこそ、Clayのようなデータオーケストレーションツールが重要になります。
Clayを“何でもできるツール”として使うのではなく、まずは既存の営業プロセスのどこを効率化・自動化したいのかを明確にすることが重要です。最初から大きな仕組みを作ろうとするのではなく、今のリサーチ業務のどこに時間がかかっているのか、どの情報を集めれば営業の意思決定がしやすくなるのか、どのプロセスを自動化すれば最も効果が出るのかを見極めて、小さく始める。そこから見えてきたパターンを広げていくことが、実際に成果につながる進め方です。
つまり、Clayは単なる便利ツールではありません。無意識に行われていた営業活動を言語化し、構造化し、再現可能な仕組みに変えるための基盤です。
GTMエンジニアリングを始めるうえで最も大切なのは、いきなりツールから入らないことです。
まず考えるべきなのは、自社の営業プロセスは今どうなっているのか、どこに無駄や属人性があるのか、どの判断をデータで置き換えられるのか、ということです。
そこを整理した上で、Clayのようなツールを使って自動化・効率化していく。この順番を守ることで、初めてGTMアルファにつながる仕組みが見えてきます。
ツールはあくまで手段です。重要なのは、自社にとっての勝ちパターンをどう見つけるかです。そして、その探索を支える実装基盤として、Clayがある。大沢さんのパートは、そのことを非常にクリアに示す内容でした。
Clayは、AIとデータを使ってGTMを実行するための基盤です。
見た目はスプレッドシートですが、実際にはその中でデータ取得、データ加工、AI処理、外部ツール連携までを一気通貫で扱えます。
つまり、「GTMの設計」を実際のオペレーションに落とし込むためのデータオーケストレーションツールです。
Clayの特徴のひとつが、扱えるデータの広さです。
たとえば企業データだけでも、企業サイト情報、資金調達、ニュース、求人情報、利用テクノロジー、従業員数、広告出稿情報などを横断的に取得できます。さらに、人物データやSNSプロフィール、言語・地域情報、Googleマップなどの位置情報、HTMLメタデータといったデータまで扱えます。
重要なのは、「データの種類が多いこと」ではなく、それらを1つのテーブル上で組み合わせて扱えることです。
従来は、企業データはA社、人物データはB社、テクノロジーデータはC社、といったように、それぞれ別契約が必要でした。
Clayではこれを、1データ単位で横断的に取得できます。これによって、データのカバー率が上がり、欠損データを補完でき、多面的な企業理解がしやすくなります。つまり、「データが足りないからできない」が大きく減ります。
実際の操作は非常にシンプルです。会社名やドメインを入力するだけで、企業情報、概要、各種データが自動で付与されます。
裏側では複数のデータプロバイダーにアクセスしながら、1つのテーブルとして統合されています。この体験が重要で、データ取得のハードルがほぼゼロになることで、新しいターゲティングのアイデアや、新しいGTM仮説が自然に生まれやすくなります。
これまでのターゲティングは、「手元にあるデータから選ぶ」という発想でした。
Clayを使うと、「理想の顧客から逆算してデータを取りにいく」という発想に変わります。
たとえば、従業員数の増加率、Webトラフィックの変化、広告出稿の増減などを見れば、「今成長している会社」「今投資している会社」が見えてきます。そこからターゲットを定義することで、精度の高いGTMが設計できます。
Clayの大きな強みが、自社独自のシグナルを設計できることです。
たとえば、資金調達した企業、広告出稿が増えている企業、セキュリティ事故が発生した企業などをトリガーに、「今アプローチすべき企業」を定義できます。いわゆるインテントデータを、外部依存ではなく自社で設計できる状態になります。
データは、取れるだけでは意味がありません。
ClayではAIを使って、情報抽出、要約、分類、スコアリング、検証まで行えます。たとえば、求人情報から利用ツールを抽出する、Webサイトから事業内容を要約する、商談ログから課題を抽出するといった処理を、テーブル単位で一括実行できます。
つまり、“生データ”を“意味のあるデータ”へ変換する作業が、自動化されるということです。
さらに特徴的なのがAIエージェントです。
Webサイト、メディア記事、PR TIMES、Wantedlyなど、データプロバイダーにない情報も取得できます。競合の価格変更、新機能リリース、採用トレンドなどもシグナルとして活用できます。ここまで来ると、データの制約はかなり小さくなります。
Clayの本質はここにあります。
データを集める。AIで加工する。CRMや各種ツールに連携する。この一連の流れを、1つの基盤の中でつなげられます。
たとえば、CRMにデータを自動反映する、Slackで営業に通知する、メール配信に連携するといったアクションまで、そのまま実行できます。つまり、分析で終わらず、そのままアクションにつながる構造です。
AI活用で重要なのが精度です。
Clayでは、「AIが生成 → 人が確認 → 再生成」というフローを組み込めます。これにより、ハルシネーション対策や、実運用で使える精度の担保がしやすくなります。
Clayは外部データだけではありません。CRM、プロダクト利用データ、商談ログなどの自社データも統合できます。
これによって、アップセルシグナル、既存顧客の深掘り、リードスコアリングまで一貫して行えるようになります。
整理すると、Clayは「データを集める」「AIで意味をつける」「現場に流す」という流れのすべてを担います。
そして重要なのは、「価値のあるデータを、どれだけ速く現場に届けられるか」という点です。GTMはスピード勝負です。Clayはそのスピードを、構造的に引き上げるツールです。
実際のデモの紹介パートについては割愛をさせていただきます。
受注・失注データからパターンを抽出し、スコアを自動生成できます。営業の「勘」をロジック化できるのが大きな価値です。
役職・部署ごとに最適なアプローチを設計できます。「誰にでも同じ」から脱却し、より刺さる訴求へつなげられます。
Web・求人・ニュースを横断して取得し、要約まで自動化できます。営業は「調べる」から「考える」に変わります。
商談ログから課題やアクションを抽出し、人の確認を経てCRMへ反映できます。実務で使える精度を担保しながら運用できるのがポイントです。
複数データを掛け合わせ、「今アプローチすべき企業」を特定できます。そのままアウトバウンド施策にもつなげられます。
GTMの本質は、データとAIです。
重要なのは量ではなく、どう組み合わせ、どう使うかです。
AIによってスピードは一気に上がりました。その結果、差は「仮説設計」に移っています。
GTMエンジニアリングは、単なる効率化ではありません。成長を再現するための仕組みです。そして、その実装基盤がClayです。