GTMエンジニアの主戦場は、自動化ではなくデータ基盤だった。Clay 服部摩耶斗さんが語るAI時代のGTMの正体。
こんにちは！GTM Labのなかむらです。
GTM Lab Podcast 第4回のゲストは、Clay社でエンタープライズCSと日本市場GTMを担当されている服部摩耶斗 ( Mayato Hattori )さんです。
服部さんはHubSpotで3年間カスタマーサクセスを担当しグローバルアワードを受賞後、データドリブンなGTMへの強い関心から2025年8月にClay社に入社。現在はグローバルのエンタープライズ顧客サポートを担いながら、アメリカ本社直轄で日本市場への進出を推進されています。
今回は実際のデモ画面を共有していただきながら、約1時間じっくり話していただきました。「GTMエンジニアとは何者か」という問いから始まり、Clayのプロダクト思想、日本市場の課題まで、現場で起きている変化をリアルに語っていただいています。
ぜひPodcastでフルバージョンをお聴きください！
🎙️ GTM Lab Podcast 🎙️
YouTube | Spotify | Apple | Amazon
以下に各トピックの学びをサマリとしてご紹介します。
まずは文字ベースで確認したいという方はぜひ読んでみてください。
① GTMエンジニアとは何者か。2025年に「プロダクトマーケットフィット」した概念。
「GTMエンジニアという言葉はClayが作ったんですか？」という問いに、服部さんは少しニュアンスのある答えを返してくれました。
もともとClayが提唱した言葉を、CursorやLovableのような初期ユーザーたちが社内でこのジョブタイトルを使い採用を始めていた。既存のカテゴリー（RevOps・マーケティングオペレーション）には収まらない人たちに「GTMエンジニア」と名前をつけたのだと言います。
そして、ClayはGTMエンジニアというジョブタイトルをコミュニティ活動などを通して市場に浸透させていった。
「これまでのカテゴリーに当てはまらない人たちがいることが社内的にもわかってきて、だったら新しいロールとして名付けた方がいいんじゃないかということで、GTMをエンジニアリングするという意味でGTM Engineerという言葉を提唱していった」
という服部さんの言葉通り、この概念はいわば「プロダクトマーケットフィットした言葉」でした。State of GTM Engineeringレポートによると、GTMエンジニアの求人数はこの1年で63件から3,000件へと急増。日本でも3月末にLayerXが採用を開始するなど、急速に動き始めています。
→ 詳細はポッドキャストの 7分頃からをご確認ください。
② なぜ、データがGTMのFoundationなのか
「GTMエンジニア＝AIで営業を自動化する人」というイメージを持っていた私でしたが、服部さんとの対話でその理解が変わりました。
GTMエンジニアが取り組む本当の主戦場は、自動化の手前にあります。
それは、「データ基盤」です。
パーソナライズメール、シグナル検知、AIアウトリーチ、これらはすべて、整備されたデータがあってはじめて機能する。
ICP（理想顧客プロファイル）の判定精度も、スコアリングの正確さも、データの質で決まる。
データが整っていなければ、AIは誤った方向に高速で走るだけです。
服部さんが Clay社が提唱するGTMマチュリティモデルをベースに「まずPhase 1（データ基盤の整備）から始めることを推奨しています」と繰り返していたのは、そういう意味だったのだと改めて腑に落ちました。
GTMにおける競争優位は、ツールの先進性ではなくデータの土台にかかっています。
→ 詳細はポッドキャストの 34分頃からをご確認ください。
③ Clayが体現する「データ分析スピード＝コスト」という思想
デモを見ながら特に印象に残ったのが、服部さんの以下の言葉です。
「Excelの関数を書くのって、調べたり試したりするのに結構時間がかかるじゃないですか。Clayはそのコストも、コストだと考えています」
「データを活用できる状態にするまでの時間」をコストと定義し、それをプロダクトで削る。
これがClayの設計思想です。
自然言語でデータクレンジング指示ができ、150以上の外部データプロバイダーとの接続が内包されていて、エラーハンドリングやレート制限管理もClayが内部で吸収する。
アイデアが浮かんでから仮説検証に至るまでのサイクルを短くすることが、GTMにおける競争優位につながるという思想です。
GTMエンジニアが「詰まない」ために作られたツール、という言い方が最もしっくりきました。
→ 詳細はポッドキャストの 36分頃 からをご確認ください。④ AIをCRMに直結させてはいけない理由。Human in the loopという設計
Clayがもうひとつ重視しているのが「中間レイヤー」としての役割です。
AIが生成したデータをそのままCRMに書き込むことへの抵抗感は、多くの企業が持っています。Clayはその間に入り、Slackを経由して担当者が内容を確認してからCRMに反映するフローを自然に作れるようになっています。
「Claude CodeやCursorで代替できないか」という私の問いに対しても、服部さんの答えは明快でした。
Claude Codeはエラーハンドリングや期待値と異なるデータへの対処に手間がかかる。
Clayはそれらを内包し、GTMの現場担当者がデータで詰まる場面を潰すことに特化している。技術的な正確さよりも「現場の担当者が止まらないこと」を優先した設計は、エンタープライズ利用に耐えるものだと感じました。
→ 詳細はポッドキャストの 45分頃からをご確認ください。
⑤ 日本市場の課題。「誰にデータを渡すか」という問い
日本市場の課題も率直に語っていただきました。
データプロバイダーの少なさ、部門間のデータ連携に必要な組織的合意形成、そしてビジネスとシステムを横断できる人材の不足。
RevOpsという文化がまだ根付いていない日本では、GTMエンジニアリングを進めようとすると必ずこれらの壁にぶつかります。
個人的に一番引っかかったのは、データへのアクセス権限の問題です。
セキュリティの観点からすべての人に開放するわけにはいかない。それは理解できます。
ただ、少なくとも、ローカルのGTM戦略を担う担当者には必要なデータへのアクセスを与えるべきではないかと感じました。
ツールを導入する前に「誰にデータを渡すか」という問いに向き合えているか。これは組織の問いであって、ツールの問いではありません。
→ 詳細はポッドキャストの 56分頃からをご確認ください。
おわりに
「営業もマーケも分かって、多少システムにも明るい人が旗を振らないといけない」
服部さんのこの言葉が、収録後もずっと頭に残っています。GTMエンジニアという職種は、コードを書ける人ではなく、データ起点で戦略を描きながら実装まで動かせる人を指している。
そしてその役割への需要は、AIがGTMに本格的に組み込まれていくこれからの時代に、ますます大きくなっていくはずです。
今回の対話を通じて、GTMエンジニアという像の解像度がぐっと上がりました。
自分自身のGTMへの関わり方を改めて問い直す機会にもなっています。服部さん、お忙しい中本当にありがとうございました。
ぜひPodcastでフルバージョンを聴いてみてください！
🎙️ GTM Lab Podcast 🎙️
YouTube | Spotify | Apple | Amazon
服部さんへのご相談・お問い合わせは、LinkedInよりご連絡ください。
参考情報（番組内で紹介）
いいなと思ったら応援しよう！
よろしければ応援お願いします！
いただいたチップは書籍購入費、ツール費などに使わせていただきます！