GTM自動化はどこから始めるか｜浅く広くより、深く狭く

AIでGTMを自動化しよう、という話をこの一年で何度も聞きました。

それなのに、実際に入れてみると売上の数字は動かない。便利そうな機能が増えただけで終わってしまう。

心当たりはありませんか。

先に言葉を整理しておきます。GTM（Go To Market）は、作ったものを市場に届けて売上に変えるまでの活動全体を指し、マーケティング・インサイドセールス・営業・カスタマーサクセスをまたぎます。

そしてRevOps（レベニューオペレーションズ）は、分断しがちなその部門群を同じデータと同じ手順で運営するための役割です。

この記事では、GTM自動化をどこから始めるかを扱います。結論から書くと、浅く広く配るより、深く狭く入れたほうが先に成果が出ます。

機能を点で足しても、業務は変わらない

いま、ほとんどの業務ツールにAI機能が乗っています。メールの下書き、議事録の要約、リードの点数づけ。

ひとつずつは確かに便利です。それでも成果が出にくいのは、業務の順序と判断がそのまま残っているからです。

たとえば返信の下書きが自動で作られても、確認して送るまでの流れが変わらなければ、短くなるのは数分だけ。手前の情報集めと、後段の記録入力はそっくり残ります。

時間の面でも似たことが起きます。下書きを読んで直す作業が新しく増えれば、削れた分と相殺されて手応えが残りません。

手応えが出るのは、機能を足したときではありません。業務フローそのものを引き直して、その中にAIを埋め込んだときです。

違いは、導入したあとに業務手順書を書き換えたかどうかに出ます。手順書が前のままなら、それは自動化ではなく便利機能の追加です。

ここが最初の分かれ目。ツールを増やす話なのか、仕事の順番を変える話なのかを、社内で先にはっきりさせてください。

深く狭くを決める三つのものさし

全社一斉にAIを入れる計画は、たいてい途中で止まります。対象が広いほど、例外処理と部門間の合意に時間を取られるからです。

広く配る計画が魅力的に見えるのは、部門ごとの不公平が出ないからでしょう。ただ、全員が少しずつ関わる形は、裏を返せば誰も本気で面倒を見ない形でもあります。

代わりに、最初の一つを選びます。見るのは、頻度・再現性・遅延コストの三つです。

頻度は、その業務が月に何回起きるか。再現性は、手順と判断基準を文章で書き切れるかです。

遅延コストは、対応が遅れるとどれだけ失われるか。ここは業務によって桁がまるで変わります。

三つとも高い業務から入ると、投じた労力がいちばん早く戻ってきます。逆にどれかが極端に低ければ、そこは後回しで構いません。

社内でよく候補に挙がる業務を、この三つで並べてみます。

数字を入れると、判断はもっと簡単になります。仮の例で計算してみます。

たとえば一次返信が月400件あり、1件あたり平均12分かかっているとします。そのうち7割が定型的な内容なら、対象は280件で月56時間分です。

一方、大型案件の提案書は月8件で1件90分、合計12時間。仮に半分を自動化できても、浮くのは6時間です。

しかも提案書のほうは判断が案件ごとに違い、手順を書き出すだけで何週間もかかります。投下する労力と戻りが釣り合わないわけです。

遅延コストの読み方はスピード・トゥ・リード｜初回接触までの時間を縮めるで詳しく扱っています。着手順そのものの決め方は開発の優先順位づけ｜RICEとICEをデータで運用するの考え方がそのまま流用できます。

深く入れるとは、どういう状態か

深く狭くと言ったとき、深いの定義が曖昧だと結局は浅くなります。目安は、その業務の最初から最後まで一本でつながっているかです。

一次返信なら、問い合わせの受信、過去の類似案件の参照、返信文の作成、送信、記録の更新まで。途中で人が別のツールを開いて手で埋める箇所が残っていれば、それはまだ半分です。

もちろん、途中に承認を挟むのは構いません。承認と、手作業の穴埋めはまったく別物です。

誰と合意してから始めるか

対象が決まったら、実装より先に合意を取ります。自動化される側の部門があとから知ると、たいてい静かな抵抗が始まります。

順番はシンプルで、まずその業務の担当者、次に上長、最後に隣接部門。担当者を飛ばして上から降ろすと、肝心の判断基準を掘り起こす段階で協力してもらえません。

話を切り出すときは、削減できる工数より先に、その業務のどこがつらいかを聞くほうが進みます。工数の話から入ると、人を減らす前振りだと受け取られやすいからです。

合意の場で決めるのは三点だけです。どこまでAIがやるか、どの条件で人に戻すか、うまくいかないときに誰が止められるか。

三つ目を現場に渡しておくと、導入のハードルはぐっと下がります。いつでも止められると思えるから、試してみようという話になるのです。

人の判断手順を、先に言葉にする

自動化がうまくいかない原因の多くは、AIの性能ではありません。そもそも正解の手順が社内で言語化されていないことです。

成果を出している人は、頭の中で細かい条件分岐を回しています。それを本人に聞いても、経験ですと返ってくることが多い。

だから、先にその手順を掘り起こします。上位の担当者に横で作業してもらい、なぜ今そう判断したのかをその場で聞いていくのが確実です。

書き出す内容は、この四つに絞ると散らかりません。

• 入力として何を見ているか（画面、資料、過去のやり取り）
• 分岐の条件と、その境目の値
• 迷ったときに優先する順番
• やってはいけないこと

四つ目が意外と大事です。禁止事項を書いておかないと、エージェントは平気で踏み越えます。

書けたら、そのまま渡せる形に整えます。文章の羅列ではなく、条件と処理が対応した形にしてください。

【一次返信の判断基準 v1.2】

分類:
  A 料金・プランの質問   → テンプレA ＋ 該当プラン表を添付
  B 技術的な不具合       → テンプレB ＋ 直近の障害情報を確認して追記
  C 導入相談・見積依頼   → 返信せず、営業チャンネルへ通知（人が対応）
  D 上記以外・判断不能   → 人へエスカレーション

優先順位（複数該当時）: C > B > A

禁止事項:
  - 値引き、納期、契約条件には言及しない
  - 未公開機能のリリース時期を答えない
  - 送信者が既存顧客か不明なときは個別の設定内容に触れない

エスカレーション条件:
  - 分類の確信度が低い
  - 同一送信者から24時間以内に3通以上
  - 文面に解約・返金・法務のいずれかが含まれる

この一枚が、あとの全工程の設計図になります。ここが曖昧なまま実装へ進むと、どこを直せばよいのかわからないシステムができあがります。

AIはUIの外に置く

ここまで書けたら実装ですが、置き場所で成果が変わります。チャット画面を開いて指示する形にすると、人が思い出したときにしか動きません。

そこで、AIはUIの外に置きます。つまり、何かの出来事をきっかけに自動で走るワークフローとして組む、ということです。

きっかけになるのは、フォーム送信、メール受信、商談ステージの変化、契約更新日の接近といった出来事。人の操作ではなく、データの変化が起点になります。

書き方のイメージは、こんな形です。

// 資料請求フォームの送信をきっかけに走らせる
on("form.submitted", async (e) => {
  const lead = await crm.upsertLead(e.email, e.company);
  const web  = await analytics.getJourney(e.anonymousId); // 匿名の閲覧履歴
  const memo = await ai.summarize({
    prompt: PLAYBOOK_V1_2,                    // 明文化した判断基準
    context: { lead, web, past: await crm.similarDeals(lead) },
  });
  if (memo.confidence < 0.7 || memo.flags.includes("legal")) {
    return slack.post("#inbound-review", { memo, needsApproval: true });
  }
  await crm.addNote(lead.id, memo.text);
  await slack.post("#inbound", { memo, assignee: memo.owner });
});

大事なのは、AIが複数のシステムを横断して文脈を集めている点です。CRMだけ、あるいはウェブ解析だけを見ても、次の一手は決まりません。

ここでよく詰まるのが、ウェブ側の行動をどう持ってくるかです。どのページを見て、どこで迷っていたのかがわからないと、返信文はどうしても一般論になります。

Strideが担うのは、まさにこの部分。サイト上の匿名の行動を正しく測る層です。

ファネルの通過と離脱、流入元の自動分類、訪問者ひとりの行動をセッションをまたいで追うN1分析までは扱いますが、氏名やメールを集めて個人と紐づける機能はありません。

個人との紐づけ、メール配信、商談の管理はCRMやMAの仕事です。どの層が何を持つのかを最初に決めると、あとの設計が驚くほど楽になります。

つまずきやすいのは、ひとつのツールで全部をまかなおうとする発想です。行動データ、顧客データ、配信の履歴は生まれる場所が違うので、無理にまとめるほど更新が止まります。

必要なのは統合ではなく、どこを見れば正しい値が取れるかの合意です。ワークフローの中でAIが参照する先が一つに定まっていれば、それで十分に動きます。

どこまで自律化し、何を人に残すか

全部を任せるか、全部を人がやるか。この二択で考えると、たいてい導入は止まります。

実際には、業務ごとに自律度の段階を決めます。同じ社内でも、業務によって段階が違って構いません。

段階の目安を整理すると、こうなります。

いきなり三段目から始めないでください。下書き段階で二〜四週間走らせ、人がどれくらい手を入れたかを記録します。

その修正率が十分に下がってから、次の段階へ上げる。これがいちばん事故の少ない進め方です。

本番の前に、影で走らせる

シャドーモードという方法があります。AIに実際の案件を処理させながら、出力は誰にも届けず記録だけ残すやり方です。

人が実際に出した結果と並べれば、どこがずれるのかが一目でわかります。顧客に迷惑をかけずに精度を測れるのが利点です。

あわせて、過去の案件から30〜50件を選んでテストセットを作っておきます。判断基準を書き換えるたびに同じセットを流せば、直した結果でほかが壊れていないかを確かめられます。

注意したいのは、影で走らせる期間を延ばしすぎないことです。本番に出さないかぎり、想定していなかった入力は最後まで出てきません。

何を評価するかを先に決める

精度が高いという言葉は、人によって意味が違います。だから、数字で決めておきます。

評価項目は、この三つを押さえておけば十分です。

• 分類やスコアが人の判断と一致した割合
• 人が出力に手を入れた割合と、その修正箇所
• 見逃してはいけない案件を取りこぼした件数

仮に、一致率90%以上かつ見逃しゼロを二週間続けたら次の段階へ、と先に決めておく。こう書いておけば、上げるかどうかで揉めません。

承認をどこに置くかとガードレールの設計は、GTMにAIエージェントを入れる｜人間承認とガードレールの設計で掘り下げています。

土台づくりと、浮いた時間の使い道

自動化を進めると、必ず同じ壁にぶつかります。AIに渡す情報のほうが、そもそも整っていないという壁です。

よくあるのは、同じ指標なのに部門で数字が違う状態。マーケが数えるMQL（マーケティングが見込みありと判断して営業へ渡すリード）の件数と、営業が受け取ったと認識している件数が合わない、というやつです。

この状態でエージェントを走らせると、間違った前提のまま高速に間違います。人がやっていたときは現場の勘で吸収されていたずれが、そのまま増幅されます。

だから先に、指標の定義を一枚に書き切ります。除外条件と集計期間まで含めて書いて、全員が同じ場所から読めるようにしてください。

このあたりの土台づくりはGTMデータ基盤｜AIが正しく動くための土台づくりにまとめました。セマンティックレイヤー、つまり社内の言葉と実データの対応表を用意しておくと、AIが指標を取り違えにくくなります。

アトリビューション（どの接点が売上にどれだけ効いたかを配分して考えること）も同じです。完璧な配分は誰にも作れないので、社内で合意した一つのルールを決めて、それを人もAIも同じように使うほうが実務は回ります。

もう一つ見落とされやすいのが、エージェントに与えるアクセス範囲です。読めるデータと書き込めるデータを最初に線引きしておかないと、あとから絞り込むのは想像以上に骨が折れます。

入力をなくすと、データが貯まる

順序として効くのが、まず入力作業をなくすことです。CRMへの記録が自動で入るようになると、担当者が面倒で飛ばしていた項目まで埋まります。

その結果、翌月から分析に使えるデータの質が上がる。データを整えてから自動化するのではなく、自動化した結果としてデータが整うという順番です。

ウェブ側も同じで、計測が担当者の手作業に依存していると続きません。StrideはMCPに対応しているので、先月の広告経由の訪問がどのページで落ちているか、といった依頼をClaudeなどのAIへ自然言語で投げられます。

ワークフローの中でAIに最新の行動データを参照させたいときも、この経路がそのまま使えます。誰かが手でCSVを書き出す運用は、忙しい週から順に止まります。

浮いた時間を、どこへ戻すか

ここがいちばん差のつくところです。浮いた時間をそのまま人員の削減に振ると、成果は横ばいのまま終わります。

おすすめしたいのは、その時間を顧客と直接話す時間へ戻すことです。一次返信が自動になった分、既存顧客への深掘りヒアリングを増やす、といった形になります。

だから着手の前に、浮く時間の行き先まで決めておいてください。決めていないと、その時間は静かにほかの雑務で埋まります。

最初の一つが終わったら

深く狭く入れる進め方には、二つ目をどうするのかという続きがあります。一つ目が安定して回り出したところで、次の業務へ移ります。

このとき持ち出すのは、できあがった仕組みそのものではありません。判断基準の書き方、合意の取り方、検証の回し方といった型のほうです。

型が残っていれば、二つ目の立ち上げはずいぶん軽くなります。逆に勢いだけで一つ目を通していると、二つ目でまた同じところから始めることになります。

社内へ広げるときも、見せるべきは削減した工数より進め方です。ほかの部門が自分の業務に置き換えて考えられる形になっていれば、声をかけられる回数が変わってきます。

まとめ

GTM自動化は、機能を広く配るほど成果が出にくくなります。頻度が高く、手順を書き切れて、遅れると損が大きい業務をひとつ選び、そこだけ最初から最後までつなぐ。

順番としては、人の判断手順を文章にする、AIをUIの外でイベント駆動に置く、自律度を段階的に上げる、という流れです。シャドーモードとテストセットで先に確かめれば、顧客に迷惑をかけずに精度を上げられます。

土台となるKPIの定義とナレッジは、後から足そうとすると必ず作り直しになります。そして浮いた時間の行き先を先に決めておくことが、半年後の差になって現れます。

まずは自分たちの業務を、三つのものさしで並べるところから。いちばん上に来た一つだけを、最後までつないでみてください。