Apollo が Deep Agents と LangSmith で GTM AI を実現

Deep Agents を活用して AI アシスタントを再構築し、GTM ループ全体を推進する Apollo の取り組み

Apollo は、見込み客の特定から顧客情報の充実、アウトリーチシーケンスの実行、商談管理、そして分析に至るまで、営業活動全体をカバーするプラットフォームです。同社は AI アシスタントの基盤として Deep Agents を採用し、追跡・評価・可視化には LangSmith を活用しています。

課題：製品が多すぎ、手順が複雑すぎる

Apollo は約 10 年にわたり、最も包括的な GTM（Go-To-Market）プラットフォームの構築に注力してきました。しかし、製品のラインナップが広がりすぎてしまったことが新たな問題を生みました。最近の実施した調査では、顧客から「製品が多すぎて圧倒される」「単一の目標を達成するために必要なモジュールや手順が多すぎる」といった声が寄せられました。

新しい見込み客へのアウトリーチキャンペーンを開始するには、リードの特定のために別々のモジュールをクリックし、顧客情報の充実を行い、シーケンスのドラフトを作成した上で、結果を測定するために別のダッシュボードへ移動する必要があります。

Claude や ChatGPT といった最新の AI エージェントは、ユーザーに「何をしたいか」を伝えるだけで、その実現方法をエージェントが自ら考え実行する体験を定着させました。Apollo も同様のユーザー体験を、プラットフォームが提供する豊富な文脈データやツール群全体に広げることを目指しました。そこで生まれたのが「Apollo AI Assistant」です。これはチャットベースのインターフェースで、ユーザーは自然言語で GTM（Go-To-Market）の目標を伝えるだけで、アシスタントが見つけ・情報追加・リーチ・測定という一連のループをエンドツーエンドで実行してくれます。

監督者型階層からディープエージェントへ：ゴールベースの実行に向けた再設計

Apollo のマルチエージェントシステムの最初のバージョンは、LangGraph を用いた「監督者（supervisor）ベース」のアーキテクチャで構築されていました。主要なエージェントがタスクを複数の専門サブエージェントに振り分け、それぞれがワークフローの一部を担うという仕組みです。確かに機能はしていましたが、LangGraph の決定論的なグラフ構造は、チームが目指すような柔軟なエージェント体験には適していませんでした。

「新しいユースケースごとに新たなサブエージェントを作成し、それを監督者に接続し、指定されたパスに従わせる必要がありました」と、Apollo のエンジニアリングマネージャーである Anshul Pahwa 氏は振り返ります。

このアーキテクチャは、ユーザー側では頻繁に意図確認のプロンプトが表示される体験につながっていました。

Apollo は今後の方向性として「Deep Agents」と「Anthropic の Claude Agent SDK」の 2 つを比較検討しました。その結果、モデルに依存しない（モデルニュートラル）という点で優れていた Deep Agents を採用することを選びました。

「Claude SDK を利用すれば、Anthropic のモデルに限定されてしまいます。それは永久的に選択肢を閉ざすことになりかねません。Deep Agents なら、複数の LLM ベンダーに対応できる扉を開いたままにできます」と Anshul は説明します。

新しい Deep Agents アーキテクチャでは、アシスタントはユーザーが明示した目標に基づいて動的に選択されたスキルライブラリによって駆動されます。エージェントは独自の計画を合成し、適用可能なスキルを使って実行しますが、Apollo のエンジニアが事前に経路を指定する必要はありません。

現在利用可能なスキルには、見込み顧客の特定、シークエンス作成、企業や担当者に関するリサーチ、配信可能性の確保、分析、アカウントスコアリング、意図信号の検出などがあります。

新しいアーキテクチャにより、応答遅延が改善され、ユーザーが表示される確認プロンプトの数も大幅に減少しました。「まるで自然な対話になっていると感じます」と Anshul は言います。

開発サイクルも短縮されました。スーパーバイザー型アーキテクチャでは、新しいエージェントを構築するには、まずサブエージェントを作成し、スーパーバイザーと統合した上で、本番リリース前の精度を最初の試行で 20〜30% から Apollo が目標とする 80% の閾値まで引き上げるための広範な評価フェーズが必要です。

フラットなスキルアーキテクチャを採用したことで、チームは内部メタスキルの構築にも成功しました。これは、問題文を入力するとエージェントがアーキテクチャ計画を生成し、シニアエンジニアがそれをレビュー、別のエージェントが実際にビルドを実行するという仕組みです。

「初期開発からローンチまでの工程にかかる工数が約 80〜85% 削減されました」とアンシュル氏は語っています。

AI Watchtower: LangSmith を基盤とした 6 レイヤー評価戦略

Apollo は、独自の観測ツールの限界に直面したことをきっかけに、LangSmith の利用を開始しました。もともとマルチエージェントアーキテクチャでは、特定のスレッド内で何が起こっているのかを把握することが極めて困難でした。具体的には、どのツールが呼び出されたか、その順序はどうか、レイテンシはどうだったか、そしてどこで失敗したのかといった情報が追跡できなかったのです。

現在、LangSmith は AI チームのすべてのエンジニアにとってデバッグの標準的なインターフェースとなっています。本番環境でタイムアウトやエラーが発生した場合、エンジニアはスレッド ID を取得し、GCS ログや Mongo データ、複数の下流システムを相互参照する手間をかけずに、どのステップで失敗したのかをトレースで特定できます。

Apollo はこの 6 レイヤー評価フレームワークを「AI Watchtower」と名付けています。

• 品質評価基準：コード記述の前に、チームは「精度」「トーン」「関連性」など 3〜5 の評価軸を定義し、それぞれ 1〜5 点で採点する具体的な例を示したルブリックを作成します。本番リリース前には、2 名の独立したレビュアーが 50〜200 件の出力を検証する事前評価を実施することが必須です。
• 完全な品質テスト：「必ず通らなければならない」ゴールデンシナリオを定義し、プロンプトやモデル設定を変更するすべてのプルリクエスト（PR）と、あらゆるデプロイで自動実行します。
• リアルタイムトレース：信号が発生した際、LangSmith を活用して、各リクエストごとの完全なプロンプト、コンテキスト、ツール呼び出し、出力結果、レイテンシを記録・デバッグします。新製品の運用初日からこの仕組みは必須です。
• リアルタイムインサイト：サンプリングされたトラフィックを集計した品質指標により、「LLM による評価スコア」「拒否率」「レイテンシの推移」を時系列で把握できます。有意な低下を検知した場合、カテゴリ→サブカテゴリ→セグメントという 3 段階の詳細分析を開始し、同時に対象範囲のサンプリング率を一時的に 50〜100% に引き上げます。
• パルスレポート：週次で全層を統合したスナップショットを作成します。プランティア、企業規模、業界別などのコホートごとの内訳を含みます。
• カスタマーフィードバック：製品内の「いいね」「いまいち」ボタンによるユーザーフィードバック機能は、新機能を実装するプルリクエストと同時にリリースされます。「いまいち」のイベントは数分以内に日次トリアージキューへ転送され、7 日間移動平均で拒否率が 8% を超える状態が継続した場合、最優先（P1）インシデントとして扱います。

すべての画面にまたがるアサスタント：ヘッドレス化への拡張

AI アサスタントは当初、UI ネイティブなプロダクトとして登場しました。ユーザーがどのページにいるかという文脈を読み取り、Apollo 内のアクションを実行する仕組みでした。しかし、ゴール指向でスキル駆動型のアーキテクチャへ移行したことで、アサスタントを UI から完全に切り離すことが可能になりました。

Apollo はこのアサスタントをヘッドレスエージェントへと拡張し、API や MCP サーバーを通じて公開しています。製品内のチャット体験を支えている同じアサスタントが、Claude、ChatGPT、Perplexity 上の Apollo の MCP サーバー連携や、MCP ベースのやり取りにおけるコンテキストサイズのコスト削減を目指して構築された「Apollo CLI」でも活用されています。

"誰も、この MCP サーバーへの取り組みがこれほど爆発的な広がりを見せるとは予想していなかった」と、Apollo のエンジニアリング VP である Himanshu Gahlot は語ります。「私たちは異なる配信チャネルの実験を行っており、MCP もその一つでした。しかし、その普及ぶりは驚異的です。これは、Apollo の GTM（Go-To-Market）オペレーターとしてのユースケースが、私たちが想定していたよりも技術的であることを示しています」。

現在、4 万チーム以上が Apollo MCP を活用して構築を進めており、月間 2.3 億回以上の API コールを処理する Apollo の API を利用する 50 万チーム超に迫る勢いです。

今後の展望：自律型 GTM エージェント

同チームは、2 つの主要な拡張分野へ投資を進めています。

アシスタントのスキルライブラリにおける深度と幅広さを強化し、既存スキルの実行精度を高めつつ、新たなユースケースへの対応範囲を広げます。

自律型エージェントについては、アシスタントがヘッドレス API として提供されるため、Apollo ユーザーはスケジュールに基づいてエージェントを実行したり、常時稼働するバックグラウンドプロセスの処理を任せることができます。例えば、Slack や他の連携ツールを通じて、「毎朝トップ 50 の ICP（理想顧客像）に合致したリードを配信してほしい」と指示すれば、Apollo の UI を開くことなく自動的に実行可能です。

「私たちは、AI アシスタントが既存のツールのなかで共働者として振る舞う場所にいることを目指しています」と、Anshul は結びました。

エージェントの実際の動作を確認する

LangSmith は、エージェントエンジニアリングを支援するプラットフォームです。開発者はこれにより、すべてのエージェント判断のデバッグや評価変更の実行、ワンクリックでのデプロイを可能にします。