GTMデータ基盤｜AIが正しく動くための土台づくり

AIに分析を任せてみたら、それらしい答えは返ってくるのに、どうも数字が合わない。

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

原因をモデルの賢さに求めたくなりますが、多くの場合、問題はもっと手前にあります。渡しているデータの意味が揃っていないのです。

同じ問い合わせ完了でも、送信ボタンのクリックを数えている場所と、完了ページの表示を数えている場所がある。人間なら文脈で読み替えますが、AIは書いてあるとおりに集計します。

この記事は、GTM（Go To Market、作った製品を市場に届けて売るまでの一連の活動）の自動化を進める前に作っておくべき土台の話です。イベント設計、指標定義、ナレッジ整備。

どれも地味です。でも、この順番を守ったチームだけが、あとから効いてきます。

賢いモデルより、揃った意味が先に要る

GTM自動化がうまく回る形は、だいたい決まっています。AIを画面の中のボタンとして足すのではなく、業務フローそのものを描き直して、その中にAIを埋め込むという形です。

CRM（顧客管理システム）、Slack、ヘルプデスク、データ基盤。これらをまたいで、出来事が起きたら動くワークフローとして組む、ということです。

ここで効いてくるのが土台です。ツールをまたぐということは、同じ言葉がすべてのツールで同じ意味を指している必要がある、ということだからです。

商談化という言葉が、営業では初回商談の実施を、マーケでは資料請求の完了を指していたとします。それを横断するワークフローは、静かに壊れます。

エラーは出ません。ただ、間違った相手に間違ったタイミングで動くだけです。

RevOps（Revenue Operations、マーケ・営業・カスタマーサクセスの分断をなくして、収益の流れを一本で運用する役割）が最初に手をつけるのが、この意味の統一なのはそのためです。

もう一つ。AIは、間違った答えを自信満々に返します。

人間の担当者なら、この数字おかしくないですか、と確認してくれます。自動化されたワークフローは確認しません。

だから土台の粗さが、そのまま出力の粗さになって外へ出ていきます。

土台は三つの層でできている

土台と一言でいっても、中身は三層に分かれます。下から順に、イベント設計、指標定義、ナレッジです。

それぞれ何を揃えるものなのか、崩れているとどうなるのかを並べてみます。

順番は下からです。記録されていないものは定義できませんし、定義できていない指標は判断の材料になりません。

上の層から手をつけたくなる気持ちは、よく分かります。ナレッジベースを作るほうが、成果が目に見えやすいですから。

でも足元が抜けていると、そのナレッジは半年で嘘になります。

第一層：イベントは、名前の規約から決める

イベントとは、ユーザーがサイトやアプリで何かをしたという出来事の記録です。ページを見た、ボタンを押した、フォームを送った。

まず決めるのは、記録の中身ではありません。名前の付け方の規約のほうです。

ここを最初に決めないと、pricing_view と view_pricing と PricingView が同時に存在する状態になります。実際、よく起きます。

規約は短くしてください。長い規約は守られません。

イベント名: 対象_動作 の順／すべて小文字／アンダースコア区切り
  例) pricing_view / demo_form_submit / trial_start

属性(プロパティ)も小文字とアンダースコア。値は選択肢を決めて自由記述にしない
  plan:   free | pro | scale
  source: search | ad | email | social | referral | direct

禁止1: 氏名・メール・電話などの個人情報をイベント属性に入れない
禁止2: ボタンの文言が変わってもイベント名は変えない（役割で命名する）

禁止1は、あとから効いてきます。イベントに個人情報を入れると、それを触るすべてのワークフローが個人情報を扱う仕組みへ格上げされてしまうからです。

匿名の行動と、個人に紐づく情報。この二つは別の層に置いて、必要なところだけでつなぐのが、結局いちばん扱いやすくなります。

見た目ではなく、役割で名前を付ける

禁止2について補足します。無料ではじめるというボタンを free_start と名付けると、文言をトライアルを開始するに変えた瞬間、名前と実体がずれます。

しかも、ずれたことに誰も気づきません。半年後に、なぜかこのイベントだけ意味が通らない、という状態で発掘されます。

だから名前は役割で付けます。位置が変わっても文言が変わっても、同じ役割なら同じ名前のままにしておく。

流入元にも同じ発想が要ります。手で付けるUTMパラメータの値がばらつくと、そこから先の集計はすべてばらつきます。

流入元の名前も、イベント名と同じルールで固定してしまうのが早いです。sourceの値は自由記述にせず、あらかじめ決めた一覧から選ぶ運用にしてください。

ウェブサイト側の匿名の行動をこの規約どおりに拾う層としては、Cookieを使わず個人情報を集めない計測ツールを置く選択肢もあります。私たちのStrideもその位置づけで、ファネルや流入元の自動分類、訪問者ひとりの行動をセッションをまたいで追うN1分析までをサイト側で扱います。

ただし、この層で測れるのは匿名の行動までです。個人を特定してリードに紐づけることも、メール配信も、スコアの書き戻しもできないので、そこはCRMやMAツールの役割だと割り切って層を分けておくほうが、結局きれいに収まります。

イベントは、増やしすぎないほうがいい

もう一点。網羅しようとすると、まず失敗します。

念のため取っておこう、で作ったイベントは、誰も使わないまま残ります。そして使われないイベントは、名前だけが似ていて中身の違う地雷として残り続けます。

最初は20個前後で十分です。目安として、収益に至る一本の道筋の上にあるものだけを拾ってください。

到着、興味、意思表示、申し込み。この四つの段階に一つずつ代表イベントを置いて、あとから足りないものを足すほうが、確実に長持ちします。

道筋の描き方と、どの段階でどれだけ落ちているかの読み方はファネル分析の基本｜離脱ポイントの見つけ方と改善の進め方にまとめてあります。イベントを選ぶ前に、この一本の道を紙に描いておくと迷いません。

第二層：指標定義は、集計できる文で書く

イベントが揃ったら、次はそれをどう数えるかです。ここで最も多い事故は、言葉どまりの定義で合意した気になることです。

有効リードを増やす。この一文で、全員がうなずいたとします。

三ヶ月後、たとえばマーケの資料には有効リード480件、営業の資料には210件、といった食い違いが表に出ます。よくある光景ではないでしょうか。

定義は、そのまま集計できるところまで書き切ります。

指標名: MQL（マーケが営業に渡してよいと判断したリード）

条件: 直近30日以内に、以下をすべて満たす
  1) 料金ページの閲覧が1回以上         … pricing_view
  2) 資料請求または問い合わせの完了が1回 … doc_request / contact_submit
  3) 会社ドメインのメールアドレス（フリーメールは除外）
除外: 自社IP、既存顧客ドメイン、採用・営業目的の問い合わせ
判定: 条件を満たした時点で即時（日次バッチではない）
所有者: マーケティング（定義の変更はRevOpsの承認を必要とする）

MQLはMarketing Qualified Leadの略で、マーケ側が見込みありと判断して営業に渡すリードを指します。この判定がずれると、営業は使えないリストを追いかけることになります。

定義書に必ず入れてほしいのは、除外条件と所有者の二つです。除外がないと数字が膨らみ、所有者がいないと誰にも直せません。

指標がなぜ食い違うのか、部門をまたいだすり合わせをどう進めるかはKPI定義のすり合わせ｜同じ指標なのに数字が食い違う理由で詳しく扱っています。

そしてもう一つ、変更履歴を残してください。定義は必ず変わります。

変わること自体は問題ありません。困るのは、数字が動いたのか定義が動いたのか分からなくなることです。

定義書の末尾に、いつ誰が何をどう変えたかを一行ずつ足していくだけで構いません。四半期の振り返りで、この一行が議論を救います。

仮の数字で、定義のズレの重さを見る

定義の話は抽象的になりがちなので、仮の数値で試算してみます。あくまで説明用の想定です。

月間の資料請求が500件、うち3割がフリーメールだとします。営業はフリーメールを除いて数え、マーケは含めて数えている。

マーケの見え方は500件、営業の見え方は350件。同じ月の同じ活動が、1.4倍ちがって見えます。

ここに商談化率が乗ります。営業が350件から35件の商談を作ったとすると、営業側の商談化率は10.0%、マーケ側の分母で割ると7.0%です。

この3ポイントの差で、広告予算の増減が議論されます。定義のズレは、地味に見えて意思決定を直接動かします。

第三層：ナレッジは、人の判断手順を写したもの

三層目がいちばん軽視されます。そして、AIを入れたときに差がつくのは、たいていここです。

ここでやるべきなのは、社内でいちばん判断の的確な担当者の手順を、先に文章にすることです。そのうえで、その手順をエージェント（自律的に一連の作業をこなすAI）へ写していきます。

順番が逆になると、うまくいきません。手順が曖昧なままAIに任せると、AIは一般論を返します。

一般論は、だいたい正しくて、まったく役に立ちません。

書き出すのは、大げさなマニュアルでなくて構いません。優秀な担当者に、この問い合わせが来たとき最初に何を見ますか、と聞いて、その答えを順番に並べるだけです。

たとえば返信の優先順位を決めるとき、その人は何を見ているのか。訪問回数か、見たページか、会社規模か、前回接触からの日数か。

聞くと、驚くほど具体的な基準が出てきます。料金ページを2回以上見ていたら先に返す、といった類のものです。

こうした手順書、指標の定義集、用語の対応表をまとめたものが、いわゆるセマンティックレイヤー（意味の層）です。データそのものではなく、そのデータをどう読むかという合意を置いておく場所だと考えてください。

AIが読める場所に置く

書いただけで散らばっていると、結局使われません。人が探せて、AIも参照できる形にしておきます。

最近は、AIから直接データへ問い合わせられる仕組みが整ってきました。MCP（Model Context Protocol、AIツールが外部のデータやツールへ接続するための共通規格）に対応した解析ツールなら、Claudeのようなチャットから自然文で聞けます。

先週の申し込みはどの流入元が多かったか、料金ページを見た人の離脱はどこか。Strideも対応していて、こうした問いをそのまま投げられます。

このとき効いてくるのが、まさに一層目と二層目です。イベント名が揃っていて指標の定義が書いてあれば、AIは正しい列を正しく数えます。

揃っていなければ、AIは近い名前の列を適当に拾います。そして、もっともらしい嘘を返します。

人間の承認を、どこに残すか

土台ができると、自動化を一気に広げたくなります。ここで急ぐと事故ります。

現実的なのは、要所に人間の承認を残したまま広げることです。全部を自動にしない。

実務的には、まずシャドーモードから始めます。AIには判断させるけれど、その出力は外へ出さず、人間の判断と並べて記録するだけの期間を置く方法です。

一〜二週間ぶん貯めて、人間の判断と一致した割合を見ます。ずれた事例は、なぜずれたかを一件ずつ読む。

この読む作業が、そのままナレッジの穴を教えてくれます。

どこまで自動にするかは、判断の重さで分けるのが現実的です。目安を表にしておきます。

線引きの基準は、間違えたときに取り返せるかどうかです。取り返せない側は、精度が上がっても人を残しておきます。

評価の指標も先に決めます。一致率だけでは足りません。

見逃しと誤検知のどちらが痛いのかを決めて、痛いほうを主指標に置いてください。優良リードの見逃しが痛いなら、多少の誤検知は許容する側に倒す。

このあたりの設計はGTMにAIエージェントを入れる｜人間承認とガードレールの設計で具体的に整理しています。

着手の順番と、最初の一ヶ月

最後に、どこから手をつけるかです。全社一斉にやらないこと、これに尽きます。

対象を選ぶ条件は三つです。順に確かめてください。

• 頻度が高い（週に何度も発生する）
• 手順が毎回ほぼ同じ（例外処理が主役でない）
• 遅れると損が出る（対応の遅さが失注に直結する）

問い合わせの一次対応、トライアル登録直後のフォロー、失注理由の記録。このあたりは、多くの会社で三条件を満たします。

狭く選んで、深く入れる。この考え方そのものはGTM自動化はどこから始めるか｜浅く広くより、深く狭くで扱っています。

最初の一ヶ月の進め方としては、こんな配分が現実的です。

• 1週目：対象業務を一つ決め、担当者の判断手順を聞き取って文章にする
• 2週目：その業務に必要なイベントだけを規約に沿って整え、抜けを埋める
• 3週目：関係する指標を2〜3個、除外条件と所有者つきで定義書に書く
• 4週目：シャドーモードで動かし、人間の判断と突き合わせる

全部のイベントを整理しようとしないでください。その業務に必要な範囲だけで十分です。

ここで、もう一つ効き方の順序があります。入力作業をなくすと、結果としてデータが貯まる、という順序です。

営業に入力を頼んでも、忙しい人ほど入力しません。逆に、入力しなくても記録される仕組みを先に作れば、データは勝手に貯まっていきます。

順番を逆にしないでください。データを貯めるために入力を増やす施策は、ほぼ必ず形骸化します。

そして最後に、自動化で浮いた時間をどこへ再投資するかで差がつきます。空いた時間を放っておくと、成果は変わりません。

浮いた時間で顧客と話すのか、失注の分析に充てるのか。ここまで決めて、はじめて自動化のプロジェクトです。

土台づくりは、正直おもしろい仕事ではありません。イベント名を揃える、定義書を書く、判断手順を聞き取る。

でも、この三つが揃った組織だけが、AIを入れたときに実際に速くなります。逆に言えば、いま整えておけば、次にどんなモデルが来ても乗り換えるだけで済みます。