「GTMエンジニア」という職種名を、この一年でよく見かけるようになりました。
求人票にも、SNSのプロフィールにも、少しずつ増えています。ただ、それが具体的に何をする人なのかは、まだ輪郭がぼやけたままではないでしょうか。
RevOpsと何が違うのか。ただの名前の付け替えなのか、それとも本当に新しい何かなのか。
先に言葉を置いておきます。GTM（Go To Market）は、作ったものを市場に届けて売上に変えるまでの活動全体を指し、マーケティング・営業・カスタマーサクセスをまたぎます。
この記事の見立てはこうです。GTMエンジニアリングとは、トップ営業が頭の中で暗黙にやっている判断の手順を、そのまま動くワークフローとして作り直す仕事だ、という整理です。
ここでひとつ、ことわりを入れておきます。この見立ては筆者の実務的な枠組みで、確定した業界標準ではありません。
読み進める土台として受け取ってください。
作り直す、という言葉には少し引っかかりがあるかもしれません。営業のやり方を新しくするのではなく、判断の中身は変えずに、それを載せる器だけを人からプログラムへ移す。
ここが今日いちばん伝えたい点です。
「GTMエンジニア」という言葉はどこから来たか
まず、この言葉の出どころを確認しておきます。曖昧な流行語のまま使うと、社内でも話が噛み合わないからです。
GTM Engineerという呼び方は、データ連携ツールを提供するClayが広めた言葉です。Clayの説明によれば、2023年ごろに自社のGTMチームがAIと自動化で収益の仕組みを作り始めたときに、そう呼ぶようになったといいます。
そこから2025年にかけて、業界へ一気に広まりました。誕生の正確な時期には諸説あるので、ここでは細部にはこだわりません。
Clayの定義を要約すると、GTMエンジニアリングとはAI・データエンリッチメント・ワークフロー自動化を組み合わせ、自動化された収益システムを構築する実務です。データエンリッチメントとは、手元のリード情報に外部データを足して厚みを持たせることを指します。
面白いのは、この役割がひとつの部門に収まらない点です。Clayはこれを、RevOps・Growth・カスタマーサクセスの三領域にまたがる職種として位置づけています。
では、既存のRevOpsと何が違うのでしょうか。ここは混同しやすいので、意図的に線を引いておきます。
観点をそろえて並べると、違いがはっきりします。
| 観点 | RevOps | GTMエンジニア |
|---|---|---|
| 主な役割 | 部門をまたいだ運営と整合 | 判断手順そのものの実装 |
| 主な成果物 | 定義・プロセス・レポート | 動くワークフロー |
| 中心スキル | データと業務設計 | それに加えて実装の流暢さ |
RevOpsが部門間の整合とデータの一貫性を担うのに対し、GTMエンジニアはその土台の上で、判断を実際に動くコードへ落とします。RevOpsそのものの着手順はRevOps入門｜マーケ・営業・CSを一本の数字でつなぐに譲りますが、乱暴に言えば、RevOpsが線路を敷き、GTMエンジニアがその上を走る自動運転を組む関係です。
もっとも、小さな組織では同じ人が両方を兼ねます。役割の名前より、どちらの仕事も欠けると片方が空回りするという関係を押さえておけば十分です。
なぜ今、この職種なのか
新しい肩書きが流行っているだけ、と片づけたくなる気持ちはわかります。ただ、背景には無視しにくい構造的な変化があります。
投資会社ICONIQの2025年のGo-to-Market調査は、回答企業の約7割が中程度から全面的なAI導入の段階にあると報告しています。AIは一部の実験ではなく、GTMの標準装備になりつつある、という数字です。
人の配置も動いています。同じ調査によれば、AIネイティブな企業は人員の三割前後をポストセールス、つまり導入後の定着や拡大に割いており、従来型のSaaSより明らかに厚い。
売って終わりではなく、使わせて広げる側に人を寄せているわけです。
ベンチャーキャピタルのa16zは、AI時代の販売では導入スピードが決め手になりやすいと指摘します。同社によれば、買い手の約7割が、導入スピードをベンダー選びで重視する要因の上位に挙げるといいます。
速さが効くなら、人が思い出したときに動く手作業では追いつきません。だからこそ、判断を仕組みに移して常時走らせる担い手が要る。
ここにGTMエンジニアの居場所があります。
構造の核心は、もっと単純です。AIによって、判断を明文化して回し続けるコストが一気に下がったことにあります。
以前は、トップ営業の手順を全リードに24時間当て続けるのは割に合いませんでした。人手では単価が高すぎたからです。
その前提が崩れた瞬間、明文化された判断は、あると便利な資料から、回すと売上になる資産へと性格を変えました。
フォワードデプロイド・エンジニアという隣の系譜
この職種を理解するのに、もうひとつ役立つ補助線があります。フォワードデプロイド・エンジニア（FDE）という、少し前から注目されてきた役割です。
FDEはもともと、データ分析企業パランティアが2010年代前半に始めた働き方が源流とされます。エンジニアが顧客の現場に深く入り込み、本番で動くコードを書いて、成果そのものに責任を持つ。
それがFDEです。
近年はOpenAIなどのAI企業も同様のチームを組み、注目が高まりました。ICONIQの2025年の集計によれば、FDEの求人はソフトウェア業界で最も速く伸びた職種のひとつで、2024年初頭の月およそ30件から2025年春には月およそ375件へと大きく増えたとされます（この数値はICONIQの報告を要約したものです）。
FDEの特徴を三つに整理すると、GTMエンジニアとの近さが見えてきます。
- 現場に埋め込まれる（外から助言するのではなく中に入る）
- 本番で動くものを作る（提案書ではなく、動くコードを納める）
- 成果に責任を持つ（動いたかどうかで評価される）
この三つは、GTMエンジニアにもそのまま当てはまります。違いは、向いている先だけです。
FDEが外の顧客に向くのに対し、GTMエンジニアは自社の収益エンジンという内側の現場に向いたFDEだと考えると腑に落ちます。助言役にとどまるソリューションアーキテクトとは、自分で作って納めるかどうかで線が引けます。
a16zも、AIの販売ではソリューションアーキテクトやエージェント向けのプロダクトマネージャーといった新しい役割が生まれると見ています。肩書きは各社で揺れていますが、商用の目的と技術の実装が一人の中で交わるという方向は共通しています。
「作り直す」と「変更する」は違う
さて、冒頭の引っかかりに戻ります。作り直すと変更する。
似ているようで、ここには決定的な差があります。
多くの現場で起きているのは変更のほうです。既存の手作業の流れを残したまま、下書き生成や要約といったAI機能を差し込む。
手順書は前のまま。これは器も中身も据え置いて、道具だけ新しくした状態です。
GTMエンジニアリングがやるのは、その逆です。判断の中身（＝ロジック）は一切変えず、それを載せる器を人からワークフローへ丸ごと作り直す。
だから作り直すのに、営業のやり方は変えない、という一見矛盾した言い方になります。
大事なのは、器を替えても中身を書き換えないという規律です。トップ営業の勘に、担当者の思いつきで手を入れ始めた瞬間、それは再現ではなく別物の設計になります。
具体例で見てみましょう。あるトップ営業が、資料請求の直後にやっている頭の中の処理を書き起こすと、こうなります。
【同じ判断、器だけが違う】
人がやっていたとき（暗黙）:
受信を見て、この会社は大企業だなと気づく
→ 過去の似た規模の商談を思い出す
→ 導入までが長い層だと判断し、急かさず情報提供から入る
→ 料金には触れず、事例を1本添えて返す
ワークフローにしたとき（明文化）:
トリガー: 資料請求フォームの送信
条件: 従業員数 >= 300 かつ 過去に同規模の受注あり
処理: テンプレA（情報提供型）＋ 類似業種の事例を1本添付
禁止: 料金・値引き・納期には言及しない
例外: 判断の確信度が低ければ人へ渡す
左と右で、判断の中身は同じです。大企業だから急がず情報提供、という営業の読みは一文字も変えていません。
変わったのは、それを実行するのが人か仕組みか、という一点だけ。これが作り直す（変更しない）の意味です。
この作業のいちばんの難所は、実は右側の記述ではありません。左側、つまり本人も言葉にできていない暗黙の判断を掘り起こすことのほうです。
手順の書き出し方そのものはGTM自動化はどこから始めるか｜浅く広くより、深く狭くで具体的に扱っています。
何を明文化し、どこに人を残すか
すべてを作り直せる、と考えると必ず失敗します。判断には、ワークフローに載せてよいものと、人に残すべきものがあるからです。
見分けの目安を、四つの性質で考えます。観察できて、繰り返され、後で取り消せて、そして基準が安定しているか。
この四つがそろう判断ほど、安心して明文化できます。
逆に、関係性に深く依存する、変動が大きい、取り返しがつかない、あるいは基準そのものがまだ動いている判断は、人の側に置きます。
整理すると、境界はこう引けます。
| 性質 | 明文化してよい | 人に残す |
|---|---|---|
| 観察できるか | できる | 空気や間で決まる |
| 繰り返すか | 定型で頻出 | 一点物 |
| 取り消せるか | やり直せる | 不可逆 |
| 基準は安定か | 固まっている | まだ動いている |
四つ目の、基準がまだ動いているという性質は見落とされがちです。動いている的は、そもそも明文化できません。
無理に固定すると、古い判断を高速で量産する装置ができあがります。
具体的にどんな判断が人に残るのか。現場でよく挙がるのは、このあたりです。
- 大口の値引きや契約条件の最終判断（不可逆で、金額が大きい）
- 関係がこじれかけた顧客への一報（空気の読みが要る）
- 勝ちパターンの定まらない新市場での初回提案（基準がまだ動いている）
だからGTMエンジニアの仕事には、固まった判断を実装するだけでなく、どこがまだ固まっていないかを見極める目が要ります。ここは技術というより、営業の解像度の話です。
人を残すと決めた場所には、承認や差し戻しの仕組みを添えます。どこで人に戻し、誰が止められるかの設計はGTMにAIエージェントを入れる｜人間承認とガードレールの設計にまとめました。
段階を一気に上げないことも肝心です。まずは下書きだけ作らせ、人がどれくらい直したかを見てから自律度を上げる。
この進め方なら、事故はぐっと減ります。
なぜ複利で効くのか
最後に、この職種がなぜ効くのかを、お金の言葉で整理します。ここがいちばんの学びどころかもしれません。
トップ営業の技能は、本人にひもづいた資産です。優秀な人が辞めれば一緒に消えるし、隣の担当へ勝手に移りもしません。
言うなれば、価値が目減りしていく個人資産です。
明文化された判断は逆です。一度ワークフローにすれば、全リードに同時に適用され、直すたびに全体が良くなります。
減っていく個人資産ではなく、積み上がる組織資産に変わる。ここが複利という言葉の中身です。
だから採用の意味も変わります。GTMエンジニアを雇うのは、優れた営業を一人足すためではありません。
狙いは、優れた営業の判断を、辞めても消えない形で組織に固定することです。
この複利を回すには、前提となる材料が二つ要ります。判断の入力になるデータと、それを取り違えないための共通の定義です。
同じ商談化という言葉が部門ごとに違う意味を指していれば、ワークフローは間違った前提のまま高速に間違います。指標の定義を一箇所に集めておく考え方はAIエージェントの土台になるセマンティックレイヤー｜指標定義を一箇所にで扱っています。
入力データの一角には、サイト上の行動もあります。どのページで迷い、どこで離脱したか。
これが分からないと、返信文はどうしても一般論になります。
Strideが担うのは、この層です。Cookieを使わず個人情報も集めずに、サイト上の匿名の行動を正しく測ることに絞った解析ツールで、ファネルの通過や離脱、流入元の自動分類までを扱います。
MCPに対応しているので、先月の広告経由の訪問がどこで落ちたか、といった問いをClaudeなどのAIから自然言語で投げられます。ワークフローの中でAIに行動データを参照させたいときも、この経路が使えます。
ただし、個人の特定やメール配信、スコアの書き戻しはできません。そこはCRMやMAの領分で、どの層が何を持つかを最初に決めるほど、あとの作り直しは楽になります。
まとめ
GTMエンジニアリングは、トップ営業の判断を、辞めても消えないワークフローとして作り直す仕事です。器を人からプログラムへ移しても、判断の中身は変えない。
これが作り直す（変更しない）の核心でした。
背景には、AIによって判断を明文化して回し続けるコストが下がったという構造変化があります。顧客の現場に埋め込まれ成果に責任を持つFDEを、内側の収益エンジンへ向けた姿だと考えると、役割の輪郭がつかめます。
実務では、観察でき・繰り返され・取り消せて・基準が安定した判断から明文化し、まだ動いている判断は人に残す。そうして固定した判断は、個人資産から複利で効く組織資産へと変わります。
まずは自社のトップ営業の頭の中を、一つだけ書き起こしてみてください。それが、この職種の最初の一歩です。