GTM エンジニアリングの技術的側面 — エバレット・ベリー、クレイ氏

GTM エンジニアリングの核心：AI が営業組織を加速させるための 3 つの技術的課題

GTM（Go-To-Market）エンジニアリングという新たな役割が、営業チームと製品開発チームの速度差を埋める鍵として急成長しています。この分野では、常に変化する顧客データを統合し、複雑なツール間の状態を同期させ、長期にわたる意思決定を行う AI エージェントを実装する 3 つの技術的課題が核心となります。

データの完全性と「ウォーターフォール」手法による市場の再構築

GTM エンジニアリングにおいてデータは生命線です。そのゴールは、ターゲットとする顧客や企業を「完璧な仮想コピー」として再現することにあります。しかし、企業が買収されたり新オフィスを出したり、製品をローンチしたりと常に変化しているため、一度きりのデータ取得では不十分です。

さらに、営業チームがマーケティングや商談を通じて企業の状態を変化させることも多く、これらをすべて追跡する必要があります。多くの企業は最初から必要なデータを保有しておらず、数百あるベンダーから情報を取得する必要があります。しかし、どの単一のベンダーも完全な情報を持っていません。

単一のデータソースに依存せず、複数のプロバイダから情報を取得して穴を埋める「ウォーターフォール」手法が不可欠です。

例えば、ある国の電話番号を取得する場合、一つのツールだけでは半分しか得られないことがあります。そのため、複数のベンダーを組み合わせることでデータを補完し、エンティティ解決（異なるソースの同一人物や企業のデータ統合）を行う必要があります。また、購入コストがかかるため、すべてのフィールドを頻繁に更新するのではなく、重要な情報だけを選択的に更新する戦略も重要です。

複雑なオーケストレーション：分散システムを統制するグラフベースのアプローチ

営業組織では CRM、シーケンサー（メール自動化ツール）、ダイアラー、通話録音、Slack など、数十ものツールが並行して使われています。それぞれのツールは世界の見方が異なり、リアルタイムで一つのレコードを更新する必要がある一方で、バッチ処理が必要なデータもあります。

分散システムでの失敗に対応し、状態を同期させるためには、グラフベースのアプローチによるオーケストレーションが必要です。

従来の方法では、CRM とシーケンサーが独立して同期しており、CRM に連絡先を作成しても、それがシーケンサーに反映されるまで待たなければなりません。この待ち時間を回避し、エラー耐性を高めるために、Clari のようなシステムではグラフベースのアーキテクチャを採用しています。

これは、エージェントを実行するノード、ツールを呼び出すノード、条件分岐を行うノード、コードを実行するノード、そして情報を拡散・集約するマップリデュースシステムを持つノードなど、汎用的なノード群で構成されます。イベントやスケジュールをトリガーに、複数のシステムと対話し、情報を統合して営業担当者が使うインターフェースへプッシュする仕組みです。

長期実行型 AI エージェントの実装：商談サイクル全体を見守る自動化

データ層が整い、オーケストレーションが機能すれば、次は「誰が何をするか」を決定する AI エージェントの役割が大きくなります。GTM の文脈では、数週間から数ヶ月にわたって商談サイクル全体を通じて企業の状態を追跡できる「長期実行型エージェント」の実装が鍵となります。

顧客とのコミュニケーションにおいてエラーが発生すれば壊滅的な結果を招くため、高いエラー許容度が求められます。

また、営業活動は構造化された CRM に未構造化な情報をマッピングする作業も伴います。LLM を使う際の一般的な課題に加え、GTM では「商談サイクル全体での状態管理」と「高信頼性」が特に重要視されます。そのため、各企業（アカウント）ごとに専用のエージェントが存在し、信号の発生やデータ更新、アクションの実行、会議の結果などを継続的に監視・判断するアーキテクチャが有効です。

人間とエージェントの協調：最大の難関は設計にある

技術的な課題を解決しても、最終的な壁となるのは「人間とエージェントの協調」です。ドメインレピュテーション（評判）の維持や、マルチチャネルでの調整など、人間の判断が不可欠な部分において、自動化システムと営業担当者がどう連携するかが最大の課題です。

GTM エンジニアリングは、単なるツールの導入ではなく、AI の進歩を反映した組織の成熟度を測る指標となっています。データ基盤の構築、オーケストレーションの最適化、そして人間との協調設計——これらを体系的に解決できるかどうかが、営業組織が生産性を飛躍させるための分岐点です。