GTMエンジニアとは？Clayが広めた「売上の仕組みを組む」職種と、日本企業での置き方

米国のスタートアップの求人で、ここ2年ほどで急に目立つようになった職種があります。GTMエンジニア（Go-To-Market Engineer）です。 GTMは「Go-To-Market」の略で、製品やサービスを市場に届けるための戦略や活動全体を指します。GTMエンジニアは、その戦略を実行するための仕組みを、データ、CRM（顧客管理システム）、AI、自動化ツールを組み合わせて自分の手でつくる人です。営業やマーケティングの担当者でもなく、プロダクトを開発するエンジニアでもない。その間に立って「売上が生まれる流れ」そのものを設計し、実装します。 日本でもこの言葉を目にする機会が増えてきましたが、「結局、何をする人なのか」「RevOpsと何が違うのか」「日本の会社に置くとしたらどうするのか」は、まだ整理されていません。この記事では、海外の調査データと先行企業の事例をもとに、GTMエンジニアの定義、急増の背景、他の職種との違い、具体的な仕事の中身、そして日本企業での置き方までを解説します。

GTMエンジニアとは何か

Clayが広めた「売上の仕組みを組む」役割

GTMエンジニアという言葉を使い始め、広めたのは、営業データの収集と自動化のツールを提供する米国のClay（クレイ）です。Clayは2023年からこの呼び名を使っており、自社のブログでGTMエンジニアを次のように定義しています。

GTM engineers build revenue engines using AI and automation.
（GTMエンジニアは、AIと自動化を使って売上を生むエンジンをつくる人である）

Clay「GTM Engineering」

もう少し具体的には、AI、データエンリッチメント（企業情報や担当者情報を外部データで補うこと）、ワークフローの自動化を使って、売上を生む仕組みを自動で回るようにつくることが仕事です。Clayによれば、この役割はCursor、Lovable、Webflowといった急成長企業の中で生まれ、職種名として広がっていきました。

仕事は3つの段階で整理できる

Clayは、GTMエンジニアの仕事を3つの段階に分けて説明しています。

• データの土台づくり：CRMの重複を消し、欠けている情報を補い、信頼できる顧客データにする
• データのモデル化：「どの企業が買いそうか」を点数化したり、理想の顧客像（ICP：Ideal Customer Profile）の条件を定義したりする
• データの活用：整えたデータをもとに、アプローチや社内連携を自動で動かす

順番に意味があります。1段目のデータが汚れたままでは、2段目の点数は当てにならず、3段目の自動化は間違った相手に大量のメールを送る仕組みになってしまいます。GTMエンジニアの価値は、派手な自動化そのものより、自動化が正しく動く前提を整えるところにあります。

GTM戦略を「実行の仕組み」に落とす人

GTMエンジニアを理解するうえで、GTM戦略との関係を押さえておくと整理しやすくなります。

GTM戦略は「誰に、何を、どう届けるか」を決めるものです。一方、GTMエンジニアは、決まった戦略を毎日、自動で、再現性をもって実行するための仕組みをつくります。戦略が設計図だとすれば、GTMエンジニアはその設計図どおりに水が流れる配管を引く人です。

GTM戦略そのものの考え方や設計の手順については、こちらの記事で詳しく解説しています。

なぜ今、米国で急増しているのか

求人は1年で約3倍に

GTMエンジニアの専門メディアGTME Pulseが2026年3月に公表した調査（32カ国・3,342件の求人分析と228人へのアンケート）によると、GTMエンジニアの求人は2024年から2025年にかけて205%増、つまり約3倍になりました。2026年3月時点で、主要な求人サイトに3,000件を超える募集が出ています。Clay自身も、毎月およそ100件の新しい求人が出ていると説明しています。

同じ調査では、求人に書かれた要件の出現率も集計されています。

• Clayの利用経験：69%
• CRMの扱い：55%
• アウトバウンド（企業側から接触する営業）用の配信ツール：45%
• PythonまたはSQL：30%
• API連携：25%

プログラミングを要件にしている求人は3割にとどまります。コードを書けることより、ツールとデータを組み合わせて仕組みにできることが重視されている職種だと読めます。経験年数では2〜5年の中堅層が約55%を占め、未経験に近い層は約20%でした。

報酬の水準は「定義の幅」も映している

報酬は、出典によってかなり差があります。GTME Pulseの調査では求人の年収の中央値が約13.2万ドル、サンフランシスコでPythonを使う職では15〜18万ドルでした。一方、求人サイトZipRecruiterの集計（2026年9月時点）では平均が約9.5万ドルです。

この差は、GTMエンジニアという肩書きが、スタートアップの中核で売上の仕組み全体を設計する人にも、配信ツールの設定を担う実務者にも使われていることを示しています。職種名がまだ固まりきっていない、立ち上がり期の職種らしい特徴です。

Clayの評価額71億ドルが示すもの

職種としての広がりを裏づけるのが、言葉を広めたClay自身の成長です。Clayは2026年9月9日、評価額71億ドルで1億1,500万ドルの資金調達を発表しました。2025年8月の前回調達時の評価額は31億ドルで、約13カ月で2倍以上になっています。顧客は1万7,000社を超えるとされます。

Clayはこの発表にあわせて、GTMエンジニアを育成するための100万ドルの奨学金も打ち出しました。ツールを売るだけでなく、そのツールを使いこなす職種そのものを育てようとしている点に、この職種の広がり方がよく表れています。

背景にある3つの変化

GTMエンジニアが求められるようになった背景には、営業やマーケティングの現場で起きている3つの変化があります。

• データが「買える・つなげる」ものになった：企業情報や担当者情報、採用や資金調達の動きといったデータを、APIで取得して自社のCRMに流し込めるようになった
• 生成AIで、人手の作業が仕組みに置き換わった：企業ごとの調査、メール文面の下書き、商談記録の要約など、これまで営業担当者が手でやっていた作業をAIに任せられるようになった
• 「人を増やして売上を伸ばす」が効きにくくなった：一斉配信のメールや電話の反応が落ち、営業担当者を増やすだけでは成果が比例しなくなった

3つが重なった結果、「人を増やす」より「仕組みをつくる」ほうが割に合う場面が増えました。その仕組みをつくる担い手として、GTMエンジニアという職種が立ち上がったと見ることができます。

RevOps・SDR・BizDevとの違い

GTMエンジニアは、隣り合う職種と仕事が重なる部分があります。違いを整理しておきます。

RevOps（レベニューオペレーション）との違い

RevOpsは、営業、マーケティング、カスタマーサクセスの数字や業務プロセスを横断して管理する役割です。GTMエンジニアと最も近い職種で、実際にClayも、GTMエンジニアはRevOpsのチームの中に置かれることが最も多いと説明しています。

違いは、手を動かして実装する深さです。RevOpsが運用ルールの設計や数字の管理、レポートを中心にするのに対し、GTMエンジニアはAPIの接続、データの加工、AIを組み込んだワークフローの構築まで自分で行います。Clayはこの変化を、従来のオペレーション担当が「データの配管工」だったのに対し、GTMエンジニアは「成長の設計者」になる、と表現しています。

SDR（インサイドセールス）との違い

SDR（Sales Development Representative）は、見込み客に接触して商談の機会をつくる担当者です。SDRが自分でアプローチする人であるのに対し、GTMエンジニアはアプローチが自動で回る仕組みをつくる人です。

「GTMエンジニア1人でSDR数人分」という言い方を見かけることがありますが、これは後で触れるとおり注意が必要です。実際には、SDRが本来の商談づくりに時間を使えるよう、調べものや入力作業を仕組みに置き換える役割と捉えるほうが実態に近いでしょう。

BizDev（事業開発）との違い

BizDevは、新しい市場や提携先、収益の柱をつくる役割です。「どこで、どう稼ぐか」を見つけるのがBizDev、見つけた稼ぎ方を毎日回るようにするのがGTMエンジニア、と分けると整理しやすくなります。

ただ、新規事業の立ち上げ期には、この2つが1人の中で重なることも少なくありません。仮説を立てて売り先を探しながら、反応のあった顧客層への接触を自動化していく。そうした働き方は、事業開発の担い手にとっても身につけておきたい力になりつつあります。

PLGやPLSとの関係

プロダクトの利用データをもとに営業がアプローチするPLS（プロダクト・レッド・セールス）も、GTMエンジニアの仕事と相性のよい考え方です。「無料プランで特定の機能を使い始めた企業を、営業に自動で知らせる」といった仕組みは、まさにGTMエンジニアがつくるものです。

仕事の中身：代表的な5つの仕組み

GTMエンジニアが実際に何をつくるのか。Clayが紹介している先行企業の事例をもとに、代表的な5つの仕組みを紹介します。

1. 問い合わせの自動振り分け

資料請求や問い合わせが入った瞬間に、その企業の規模や業種、既存の取引の有無を外部データで補い、優先度を判定して適切な担当者に自動で割り振る仕組みです。関心が最も高いうちに連絡できるよう、「問い合わせから初回連絡までの時間」を縮めることが狙いです。

2. 購買の兆しの要約

見込み客の企業で起きた変化、たとえば資金調達、役員の交代、関連職種の採用開始、自社サイトの料金ページの閲覧などを集め、営業担当者に毎日まとめて届ける仕組みです。「属性」ではなく「今、買う気配があるか」でアプローチ先を選ぶ考え方は、シグナルベースド・マーケティングと呼ばれます。

3. 商談記録からのCRM自動更新

商談の録画や文字起こしをAIで読み取り、決裁者、予算、導入時期、懸念点といった項目をCRMに自動で書き込む仕組みです。営業担当者の入力の手間が減るだけでなく、CRMのデータが埋まること自体が、ほかの仕組みの精度を上げるという効果があります。

4. 大量の施策の自動生成

業種や地域、顧客の課題ごとに、アプローチの文面や紹介ページを自動で作り分ける仕組みです。人手では数パターンしか用意できなかったものを、対象ごとに出し分けられるようになります。

5. 解約リスクの早期通知

既存顧客の利用状況の低下や問い合わせ内容の変化を検知し、カスタマーサクセスの担当者に知らせる仕組みです。GTMエンジニアの仕事は新規獲得だけではありません。既存顧客の継続と拡大まで含めた「売上の流れ全体」が対象になります。

日本企業での置き方

ここからは、日本企業がGTMエンジニアの役割を取り入れるときの考え方を整理します。

置き場所は「オペレーション部門から始める」

Clayは、先行企業での置き方を2つの型に分けています。

• RevOpsの中に置く型：最も多い型。データとCRMを預かる部門の中で、仕組みをつくる担当を置く。試作をする人と、それを本番運用に乗せる人に役割を分ける企業もある
• グロースチームの中に置く型：Ramp（米国の法人カード企業）やVerkada（クラウド型の防犯カメラ企業）などが採用。新しい獲得施策を試す部隊の中に置く

そのうえでClayが共通の教訓として挙げているのが、「まずオペレーション部門から始め、あとで各部門に広げる（Start in ops, federate later）」という考え方です。最初から各部門にGTMエンジニアを散らすと、データの持ち方がばらばらになり、1段目の土台づくりが崩れてしまうためです。

日本企業では、RevOpsという部門自体がない会社がまだ多いのが実情です。その場合は、CRMやMA（マーケティング自動化）ツールの管理をしている人やチームを起点に考えるとよいでしょう。営業企画、マーケティング企画、インサイドセールスの責任者の近くが現実的な置き場所になります。

最初の1人を社員で採るのは難しい

日本でもGTMエンジニアを名乗る求人は出始めていますが、まだ数は多くありません。経験者の数そのものが少なく、「GTMエンジニアの経験者」を正社員で採用しようとすると、候補者がほとんど見つからないという状況になりがちです。

また、GTMエンジニアの仕事は、最初の数カ月に負荷が集中する傾向があります。データの土台づくりと主要な仕組みの構築が終わると、その後は運用と改善が中心になります。立ち上げの山と、その後の運用の量が大きく違うことも、最初から正社員1人を置く判断を難しくしています。

外部人材で「仕組みだけ先につくる」という選択肢

そこで現実的な選択肢になるのが、業務委託や副業の形で、外部の人材に仕組みの立ち上げを任せる方法です。週1〜2日程度の関わり方でも、データの整備、優先度の判定、主要な自動化の構築といった土台は進められます。週1〜2日の業務委託で外部のプロ人材に仕事を任せるときの、業務の切り出し方や稼働量・成果の決め方は、週1〜2日の業務委託でプロ人材を活用する方法で整理しています。

経営の機能を必要な分だけ外部から取り入れる「フラクショナル」という考え方は、経営層だけでなく、こうした専門職にも広がりつつあります。

外部人材に任せる場合に大切なのは、つくった仕組みを社内で運用できる状態で引き継ぐことです。仕組みの中身を外部の人しか理解していない状態では、その人が離れた瞬間に止まってしまいます。設計の記録を残すこと、社内の担当者が並走することを、最初の段階で依頼内容に含めておくとよいでしょう。

任せる前に社内で決めておくこと

社員で置く場合も外部に任せる場合も、事前に社内で決めておきたいことがあります。

• 何の数字を動かしたいか：商談数なのか、商談化率なのか、解約率なのか。目的が曖昧なままだと、仕組みづくりが「便利なツールの導入」で終わる
• 理想の顧客像が言葉になっているか：どの企業に売りたいかが決まっていないと、優先度の判定も自動化もつくれない
• CRMの持ち主は誰か：データの項目を変えたり、入力のルールを決めたりする権限がどこにあるか
• 営業現場との接点：仕組みが出した結果を受け取って動くのは営業担当者。現場の責任者が関わらないと、つくった仕組みは使われない

見極めは「つくれるか」より「何をつくるべきか分かるか」

Clayは、GTMエンジニアに求める資質として、技術を扱う力、商売の感覚、好奇心、試して学ぶ姿勢の4つを挙げています。選考では、事業の課題を調べさせる、仕組みの全体図を描かせる、小さな仕組みを実際につくらせる、という3段階で見極める方法を紹介しています。

特に重要なのは2番目の「商売の感覚」です。ツールを使いこなせる人は増えていますが、どの課題を仕組みで解くと売上に効くのかを判断できる人は多くありません。外部の人材に依頼する場合も、ツールの経験より、営業やマーケティングの数字に責任を持った経験があるかを確かめることをおすすめします。事業開発を担う人を外部から迎えるときの、フェーズ別の要件と見極め方は、BizDev（事業開発）人材を外部から確保する方法で詳しく解説しています。

懐疑論とつまずき方

GTMエンジニアには期待が集まる一方で、慎重な見方もあります。導入でつまずきやすい点を整理します。

ツールの導入が目的になる

GTMエンジニアの求人の約7割がClayの利用経験を求めていることは先に触れたとおりです。それだけ特定のツールと結びついた職種だということでもあります。「GTMエンジニアを置く」が「新しいツールを入れる」とほぼ同じ意味になってしまうと、使われない自動化が増えるだけで終わります。

データの土台がないまま自動化する

最も多いつまずきは、CRMのデータが整っていないまま、配信や連絡の自動化から始めてしまうことです。重複した顧客情報や古い担当者情報をもとに自動でアプローチすると、同じ相手に何度も連絡が届いたり、退職した人に宛てたメールが送られたりします。自動化は、データの質の問題を一気に表に出すものだと考えておく必要があります。

「SDRの代わり」という誇張

「GTMエンジニアを1人置けば、SDRを何人も減らせる」という宣伝文句には注意が必要です。仕組みが置き換えるのは、主に調べものや入力、定型の連絡といった作業の部分です。顧客と信頼関係を築き、相手の事情を聞き出して商談に進める部分は、引き続き人が担います。

人を減らすことを目的にすると、仕組みの評価が「何人分の作業を削れたか」になり、売上への効果が見えにくくなります。人を減らすためではなく、人が本来の仕事に時間を使えるようにするためと位置づけたほうが、結果的に成果につながりやすいはずです。

肩書きが先行する

報酬の幅で見たとおり、GTMエンジニアという肩書きが指す仕事の範囲は、まだ会社によってばらばらです。社内で置く場合も外部に依頼する場合も、肩書きで判断せず、「これまでにどんな仕組みをつくり、どの数字がどう動いたか」を具体的に確かめることが欠かせません。

まとめ

GTMエンジニアは、GTM戦略を実行するための仕組みを、データ、CRM、AI、自動化ツールを組み合わせて自分の手でつくる職種です。言葉を広めたClayの急成長とともに、米国では求人が1年で約3倍に増えました。 この記事のポイントを整理します。

• 仕事は3段階：データの土台づくり、データのモデル化、データの活用。土台が崩れていると上の段は機能しない
• 隣の職種との違い：RevOpsより実装が深く、SDRのように自分でアプローチするのではなく仕組みをつくる。稼ぎ方を見つけるのがBizDev、それを毎日回すのがGTMエンジニア
• 置き場所：まずオペレーション部門から始め、あとで各部門に広げる
• 日本での現実解：経験者が少なく、立ち上げに負荷が集中するため、外部人材で仕組みを先につくり、社内に引き継ぐ方法が有力
• つまずき方：ツール導入の目的化、データ整備の後回し、「人を減らす」ことへの過度な期待

日本では、GTMエンジニアという職種名が定着するまでにはまだ時間がかかるかもしれません。ただ、「売上を人の頑張りではなく仕組みで伸ばす」という考え方そのものは、営業組織の規模にかかわらず取り入れられます。まずは、自社の売上の流れのどこに手作業と待ち時間がたまっているのかを書き出すところから始めてみてはいかがでしょうか。